From report at bugs.python.org Wed Jun 1 00:00:49 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 01 Jun 2016 04:00:49 +0000 Subject: [issue7769] SimpleXMLRPCServer.SimpleXMLRPCServer.register_function as decorator In-Reply-To: <1264337326.51.0.913533963705.issue7769@psf.upfronthosting.co.za> Message-ID: <1464753649.75.0.712971419611.issue7769@psf.upfronthosting.co.za> Berker Peksag added the comment: Here's some quick review comments: * xmlrpc_register_decorator_py33.patch doesn't apply cleanly anymore. * - serv.register_function(my_function) + serv.register_function(_my_function, name='my_function') We should keep ``serv.register_function(my_function)`` as is and add a separate line that uses the new 'name' parameter. * We can now change set([...]) to {...] in test_introspection1 * + add_result, pow_result, div_result, \ + myfunc_result, myfunc2_result = multicall() No need to use the \ character. * The docstring of Lib/xmlrpc/server.py is already too long. It's better not to update it. * Please use the existing code style (name = None -> name=None) * We can make register_function act both as a decorator and as a decorator factory without changing its signature. * We need to add a test to cover TypeError case. * Documentation is missing. See Doc/library/xmlrpc.server.rst. * Please add a note to Doc/whatsnew/3.6.rst. ---------- nosy: +berker.peksag stage: patch review -> needs patch versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 00:04:50 2016 From: report at bugs.python.org (ryan.petrello) Date: Wed, 01 Jun 2016 04:04:50 +0000 Subject: [issue27172] Add skip_bound_arg argument to inspect.Signature.from_callable() Message-ID: <1464753890.83.0.908486465545.issue27172@psf.upfronthosting.co.za> Changes by ryan.petrello : ---------- components: Library (Lib) files: signature-from-callable-skip-bound-arg.patch keywords: patch nosy: ryan.petrello priority: normal severity: normal status: open title: Add skip_bound_arg argument to inspect.Signature.from_callable() type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43078/signature-from-callable-skip-bound-arg.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 00:17:26 2016 From: report at bugs.python.org (ryan.petrello) Date: Wed, 01 Jun 2016 04:17:26 +0000 Subject: [issue27172] Add skip_bound_arg argument to inspect.Signature.from_callable() Message-ID: <1464754646.94.0.12859513052.issue27172@psf.upfronthosting.co.za> Changes by ryan.petrello : ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 02:19:05 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Jun 2016 06:19:05 +0000 Subject: [issue27171] Fix various typos In-Reply-To: <1464753470.11.0.0270588746388.issue27171@psf.upfronthosting.co.za> Message-ID: <1464761945.02.0.200948299448.issue27171@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: typos.py3.patch LGTM. I expect typos.py2.patch is just backported to 2.7. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 03:27:48 2016 From: report at bugs.python.org (Alexander Schrijver) Date: Wed, 01 Jun 2016 07:27:48 +0000 Subject: [issue22232] str.splitlines splitting on non-\r\n characters In-Reply-To: <1408528911.37.0.452679392827.issue22232@psf.upfronthosting.co.za> Message-ID: <1464766068.05.0.358764336249.issue22232@psf.upfronthosting.co.za> Alexander Schrijver added the comment: I appeared to have missed the reference to that issue when I read this issue the first time. Re-opening that issue makes sense to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 03:29:45 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Jun 2016 07:29:45 +0000 Subject: [issue27173] Modern Unix key bindings for IDLE Message-ID: <1464766185.36.0.150155479026.issue27173@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: The "IDLE Classic Unix" key set in IDLE provides Emacs-like key bindings. But modern Linux environments (KDE, Gnome, etc) use different key bindings in standard editors. Proposed patch provides new key set named "IDLE Modern Unix" that uses key bindings common in KDE (and mainly in Gnome). It is more habitual for average user. In additional the patch makes IDLE to use platform-depending key set by default. ---------- components: IDLE files: idle_modern_unix_key_set.patch keywords: patch messages: 266801 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Modern Unix key bindings for IDLE type: enhancement versions: Python 2.7, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43079/idle_modern_unix_key_set.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 03:30:12 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Jun 2016 07:30:12 +0000 Subject: [issue27173] Modern Unix key bindings for IDLE In-Reply-To: <1464766185.36.0.150155479026.issue27173@psf.upfronthosting.co.za> Message-ID: <1464766212.65.0.754524822488.issue27173@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 03:36:16 2016 From: report at bugs.python.org (kulla) Date: Wed, 01 Jun 2016 07:36:16 +0000 Subject: [issue27174] Update URL to IPython in interactive.rst Message-ID: <1464766576.17.0.0548919412603.issue27174@psf.upfronthosting.co.za> New submission from kulla: The file https://docs.python.org/3.6/tutorial/interactive.html has a dead link for IPython to http://ipython.scipy.org/ I guess the right link shall be https://ipython.org/ ---------- components: Devguide messages: 266802 nosy: ezio.melotti, kulla, willingc priority: normal severity: normal status: open title: Update URL to IPython in interactive.rst versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 03:36:23 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Jun 2016 07:36:23 +0000 Subject: [issue24759] Idle: require tk 8.5 and ttk widgets, and drop unneeded code. In-Reply-To: <1438294715.65.0.966229055462.issue24759@psf.upfronthosting.co.za> Message-ID: <1464766583.52.0.824831608625.issue24759@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: My patch in issue24750 makes sense only if we want support Tcl/Tk 8.4. I think that if require Tcl/Tk 8.5+, we can use Ttk directly and unconditionally. I don't think that it can be not working. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 03:37:13 2016 From: report at bugs.python.org (kulla) Date: Wed, 01 Jun 2016 07:37:13 +0000 Subject: [issue27174] Update URL to IPython in interactive.rst In-Reply-To: <1464766576.17.0.0548919412603.issue27174@psf.upfronthosting.co.za> Message-ID: <1464766633.45.0.861085430258.issue27174@psf.upfronthosting.co.za> Changes by kulla : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 03:42:29 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Jun 2016 07:42:29 +0000 Subject: [issue27174] Update URL to IPython in interactive.rst In-Reply-To: <1464766576.17.0.0548919412603.issue27174@psf.upfronthosting.co.za> Message-ID: <1464766949.04.0.457386323557.issue27174@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> docs at python components: +Documentation -Devguide keywords: +easy nosy: +docs at python stage: -> needs patch type: enhancement -> behavior versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 03:48:27 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 01 Jun 2016 07:48:27 +0000 Subject: [issue27164] zlib can't decompress DEFLATE using shared dictionary In-Reply-To: <1464687663.75.0.126366287594.issue27164@psf.upfronthosting.co.za> Message-ID: <1464767307.5.0.134781381751.issue27164@psf.upfronthosting.co.za> Xiang Zhang added the comment: This seems related with the difference between zlib format and raw format. When you do raw inflate, you have to inflateSetDictionary before any inflate. You cannot rely on the first inflate to return Z_NEED_DICT and then do inflateSetDictionary. Although I have the solution with experiment, but there is nothing can be found in the official zlib documentation. It is rather vague. I'll make more research and submit a patch later.. Right now, you can use zlib format (positive wbits) if it can achieve your goal. It's behaviour is right. ---------- nosy: +martin.panter, nadeem.vawda, twouters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 03:51:39 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 01 Jun 2016 07:51:39 +0000 Subject: [issue27171] Fix various typos In-Reply-To: <1464753470.11.0.0270588746388.issue27171@psf.upfronthosting.co.za> Message-ID: <1464767499.71.0.0163450695841.issue27171@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks. The py2 version is partly a back port, but I have searched for the same kind of spelling mistakes and fixed them in different places, e.g. ?overriden? in Lib/bsddb/test/test_all.py, which does not exist in Py 3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 03:55:13 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 01 Jun 2016 07:55:13 +0000 Subject: [issue12855] linebreak sequences should be better documented In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za> Message-ID: <1464767713.18.0.291995761883.issue12855@psf.upfronthosting.co.za> Martin Panter added the comment: Reopening to change the Python 2 documentation. A starting point may be Matthew?s patch and/or Alexander?s patch in Issue 22232. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 03:58:08 2016 From: report at bugs.python.org (SilentGhost) Date: Wed, 01 Jun 2016 07:58:08 +0000 Subject: [issue27172] Add skip_bound_arg argument to inspect.Signature.from_callable() Message-ID: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za> New submission from SilentGhost: This could only go in 3.6, but it needs proper documentation and test(s). ---------- nosy: +SilentGhost, yselivanov stage: -> test needed versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 04:29:46 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Jun 2016 08:29:46 +0000 Subject: [issue25570] urllib.request > Request.add_header("abcd", "efgh") fails with character ":" in first parameter string In-Reply-To: <1446842352.31.0.869437789925.issue25570@psf.upfronthosting.co.za> Message-ID: <20160601082936.27251.35871.82B25B17@psf.io> Roundup Robot added the comment: New changeset 320b9a65ac07 by Martin Panter in branch '3.5': Issue #25570: Add example of customizing User-Agent via add_header() https://hg.python.org/cpython/rev/320b9a65ac07 New changeset 75dc64c8c22b by Martin Panter in branch 'default': Issue #25570: Merge add_header() example from 3.5 https://hg.python.org/cpython/rev/75dc64c8c22b New changeset 3aa49900869b by Martin Panter in branch '2.7': Issue #25570: Add example of customizing User-Agent via add_header() https://hg.python.org/cpython/rev/3aa49900869b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 05:15:30 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 01 Jun 2016 09:15:30 +0000 Subject: [issue27173] Modern Unix key bindings for IDLE In-Reply-To: <1464766185.36.0.150155479026.issue27173@psf.upfronthosting.co.za> Message-ID: <1464772530.88.0.97042299653.issue27173@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Seems reasonable. 3 or more years ago, there was an issue about needing to define pairs like Control-Key-c and Control-Key-C in order to have crtl + c/C-key work the same regardless of the caps lock setting. I also remember that the effect of Caps lock was system dependent. But I forget the details. We should find the issue and document the system dependent rules, perhaps in config.py, perhaps in config-keys.def. Adding a new default key set will likely not be as simple as we wish. The problem is the same one we had when adding a new default color theme last fall. If one selects the new definition, older releases will try and fail to load what is not there. Keys have a different backup logic than themes, including the 'last resort fallback' in IdleConf.GetCoreKeys. With thems the result was errors and or an exit. Have you, or can you check what happens if you select 'Modern Unix' and run an existing release. If necessary, we can use the same workaround we did with theme, which is described in the docstring for IdleConf.CurrentTheme. Part the theme patch was making sure that all of the rest of IDLE accessed the current theme through the rewritten CurrentTheme instead of through GetOption('main', 'Theme', ...). I would like to add some unittests, but a manual test protocol is needed at least to test an existing release. Tests should be run on each of the three systems, and for each backported version. When we have a tested patch ready, we could ask New to test on Mac, or do you have access to one now? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 05:18:04 2016 From: report at bugs.python.org (Antony Lee) Date: Wed, 01 Jun 2016 09:18:04 +0000 Subject: [issue27175] Unpickling Path objects Message-ID: <1464772684.94.0.191025907363.issue27175@psf.upfronthosting.co.za> New submission from Antony Lee: Currently, pickling Path objects lead to issues when working across platforms: Paths (and, thus, objects that contain Paths) created on a POSIX platform (PosixPaths) cannot be unpickled on Windows and vice versa. There are a few possibilities around this issue. - Don't do anything about it, you should use PurePaths if you care about cross-platform compatibility: this would be pretty awkward, as any call to the Path API would require converting back the PurePath to a Path first. - Silently convert Paths to PurePaths during pickling (a solution that seems to have been adopted by http://docs.menpo.org/en/stable/api/menpo/io/export_pickle.html for example): it would be better if Paths at least roundtripped correctly within a single platform. - Convert Paths to PurePaths at unpickling time, only if the platform is different (and possibly with a warning): this is the least bad solution I came up with so far. Note that calls to the Path API on a "converted" PurePath object would be invalid anyways as the PurePath (being of a different platform) cannot be representing a valid path. Thoughts? ---------- components: Library (Lib) messages: 266810 nosy: Antony.Lee priority: normal severity: normal status: open title: Unpickling Path objects versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 05:19:53 2016 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Wed, 01 Jun 2016 09:19:53 +0000 Subject: [issue26739] idle: Errno 10035 a non-blocking socket operation could not be completed immediately In-Reply-To: <1460409859.89.0.789703447955.issue26739@psf.upfronthosting.co.za> Message-ID: <1464772793.68.0.997445121895.issue26739@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Hi there, everyone. I'm sorry for my rash remarks about the state of IDLE, I'm sure it is alive and well and its good to see that fine people like Terry are working on keeping it up to date. Michael, please understand that python developers are volunteers and sometimes need help to fix things. In this case, we have not been able to reproduce the problem, and are not sure what can be causing it. My suggestion for you to modify code would be a step in identifying and diagnosing the problem. Without such feedback it is hard to accomplish anything. Cheers! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 05:21:42 2016 From: report at bugs.python.org (SilentGhost) Date: Wed, 01 Jun 2016 09:21:42 +0000 Subject: [issue27175] Unpickling Path objects In-Reply-To: <1464772684.94.0.191025907363.issue27175@psf.upfronthosting.co.za> Message-ID: <1464772902.12.0.768278338861.issue27175@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +pitrou type: -> behavior versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 05:26:13 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 01 Jun 2016 09:26:13 +0000 Subject: [issue25570] urllib.request > Request.add_header("abcd", "efgh") fails with character ":" in first parameter string In-Reply-To: <1446842352.31.0.869437789925.issue25570@psf.upfronthosting.co.za> Message-ID: <1464773173.58.0.194848804913.issue25570@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 05:44:04 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 01 Jun 2016 09:44:04 +0000 Subject: [issue12855] linebreak sequences should be better documented In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za> Message-ID: <1464774244.34.0.193513064908.issue12855@psf.upfronthosting.co.za> Martin Panter added the comment: Here is an updated patch for Python 2, based on Benjamin?s commit, Matthew?s earlier py27 patch, and Alexander?s backport of related changes from Python 3. Let me know what you think. ---------- nosy: +Alexander Schrijver stage: resolved -> patch review Added file: http://bugs.python.org/file43080/linebreakdoc.v5.py2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 06:52:23 2016 From: report at bugs.python.org (ryan.petrello) Date: Wed, 01 Jun 2016 10:52:23 +0000 Subject: [issue27172] Add skip_bound_arg argument to inspect.Signature.from_callable() In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za> Message-ID: <1464778343.64.0.143268928671.issue27172@psf.upfronthosting.co.za> ryan.petrello added the comment: Thanks, I'll upload a new patch shortly that addresses these. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 06:58:53 2016 From: report at bugs.python.org (ryan.petrello) Date: Wed, 01 Jun 2016 10:58:53 +0000 Subject: [issue27172] Add skip_bound_arg argument to inspect.Signature.from_callable() In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za> Message-ID: <1464778733.48.0.181407669254.issue27172@psf.upfronthosting.co.za> Changes by ryan.petrello : Added file: http://bugs.python.org/file43081/signature-from-callable-skip-bound-arg.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 07:02:41 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 01 Jun 2016 11:02:41 +0000 Subject: [issue27164] zlib can't decompress DEFLATE using shared dictionary In-Reply-To: <1464687663.75.0.126366287594.issue27164@psf.upfronthosting.co.za> Message-ID: <1464778961.99.0.707641240558.issue27164@psf.upfronthosting.co.za> Xiang Zhang added the comment: I think my conclusion in last message is right. A similar bug in CPAN can be found in https://rt.cpan.org/Public/Bug/Display.html?id=36046. And I can find in zlib's changelog inflateSetDictionary starts to support raw inflate from 1.2.2.1. Patch attached now allows Python to decompress raw deflate format with a dictionary. Hope some core devs are willing to review. ---------- keywords: +patch Added file: http://bugs.python.org/file43082/issue27164.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 07:30:56 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Jun 2016 11:30:56 +0000 Subject: [issue27173] Modern Unix key bindings for IDLE In-Reply-To: <1464766185.36.0.150155479026.issue27173@psf.upfronthosting.co.za> Message-ID: <1464780656.02.0.180043618875.issue27173@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > 3 or more years ago, there was an issue about needing to define pairs like Control-Key-c and Control-Key-C in order to have crtl + c/C-key work the same regardless of the caps lock setting. I also remember that the effect of Caps lock was system dependent. Proposed scheme binds different actions on hotkeys with and without Shift: Ctrl-Z/Ctrl-Shift-Z, Ctrl-S/Ctrl-Shift-S. If don't touch CapsLock this is not an issue. Yes, there is a problem with new buildin keys set in old IDLE versions. A lot of warnings is emitted on stderr. The solution for the "IDLE Dark" theme is not complete, since after adding next new theme we will encounter the same problem and should add options "name3", "name4"... Updated patch uses the same solution for new keys set. But it also makes warnings be less annoying. Every warning is emitted just once, and only one warning is emitted for unknown keys set. ---------- Added file: http://bugs.python.org/file43083/idle_modern_unix_key_set2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 07:46:48 2016 From: report at bugs.python.org (ryan.petrello) Date: Wed, 01 Jun 2016 11:46:48 +0000 Subject: [issue27172] Add skip_bound_arg argument to inspect.Signature.from_callable() In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za> Message-ID: <1464781608.59.0.825349326479.issue27172@psf.upfronthosting.co.za> Changes by ryan.petrello : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 10:16:56 2016 From: report at bugs.python.org (Bar Harel) Date: Wed, 01 Jun 2016 14:16:56 +0000 Subject: [issue27176] Addition of assertNotRaises Message-ID: <1464790616.9.0.804772200909.issue27176@psf.upfronthosting.co.za> New submission from Bar Harel: I thought of implementing an assertNotRaises to solve the issue of using try...except...fail in order to prevent showing the tests as an error and instead show them as a failure. Is there anything I should consider while implementing it? ---------- components: Library (Lib), Tests messages: 266816 nosy: bar.harel priority: normal severity: normal status: open title: Addition of assertNotRaises type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 10:20:08 2016 From: report at bugs.python.org (Jeroen Demeyer) Date: Wed, 01 Jun 2016 14:20:08 +0000 Subject: [issue27177] re match.group should support __index__ Message-ID: <1464790808.77.0.698310162067.issue27177@psf.upfronthosting.co.za> New submission from Jeroen Demeyer: ``` >>> class zero(object): ... def __index__(self): ... return 0 ... >>> z = zero() >>> import re >>> p = re.compile('(a)b') >>> m = p.match('ab') >>> m.group(0) 'ab' >>> m.group(z) Traceback (most recent call last): File "", line 1, in IndexError: no such group ``` ---------- components: Regular Expressions files: re_match_index.patch keywords: patch messages: 266817 nosy: ezio.melotti, jdemeyer, mrabarnett priority: normal severity: normal status: open title: re match.group should support __index__ versions: Python 2.7 Added file: http://bugs.python.org/file43084/re_match_index.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 10:31:39 2016 From: report at bugs.python.org (SilentGhost) Date: Wed, 01 Jun 2016 14:31:39 +0000 Subject: [issue27176] Addition of assertNotRaises In-Reply-To: <1464790616.9.0.804772200909.issue27176@psf.upfronthosting.co.za> Message-ID: <1464791499.01.0.92035816404.issue27176@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +ezio.melotti, michael.foord, rbcollins versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 10:37:00 2016 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 01 Jun 2016 14:37:00 +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: <1464791820.91.0.663206185485.issue7105@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Shouldn't the documentation be updated? https://docs.python.org/3.6/library/weakref.html#weakref.WeakKeyDictionary Note Caution: Because a WeakKeyDictionary is built on top of a Python dictionary, it must not change size when iterating over it. This can be difficult to ensure for a WeakKeyDictionary because actions performed by the program during iteration may cause items in the dictionary to vanish ?by magic? (as a side effect of garbage collection). ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 10:59:58 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 01 Jun 2016 14:59:58 +0000 Subject: [issue27164] zlib can't decompress DEFLATE using shared dictionary In-Reply-To: <1464687663.75.0.126366287594.issue27164@psf.upfronthosting.co.za> Message-ID: <1464793198.53.0.00916646265825.issue27164@psf.upfronthosting.co.za> Xiang Zhang added the comment: Forget to add test. Upload a new one with test included. ---------- Added file: http://bugs.python.org/file43085/issue27164_with_test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 11:10:28 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Wed, 01 Jun 2016 15:10:28 +0000 Subject: [issue27176] Addition of assertNotRaises In-Reply-To: <1464790616.9.0.804772200909.issue27176@psf.upfronthosting.co.za> Message-ID: <1464793828.48.0.580584013214.issue27176@psf.upfronthosting.co.za> Steven D'Aprano added the comment: Yes. What does such an assertion actually mean? Why would I write `self.assertNotRaises(ValueError, spam, arg)` rather than just call `spam(arg)`? The only difference is that assertNotRaises will treat one specific exception as a test failure rather than a error, but I don't think that's useful. spam(arg) presumably is supposed to return something, or do something, not merely "don't raise ValueError". Raising ValueError should be no different from raising any other exception: it's a error, not a failure. It makes sense to test for expected exceptions. I don't think it makes sense to test for exceptions that don't happen. Every single successful test of `spam(arg)` shows that ValueError is not raised, as well as every imaginable other exception. I don't think there is any need for an assert method to test for exceptions not being raised. ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 12:18:07 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 01 Jun 2016 16:18:07 +0000 Subject: [issue27176] Addition of assertNotRaises In-Reply-To: <1464790616.9.0.804772200909.issue27176@psf.upfronthosting.co.za> Message-ID: <1464797887.25.0.553246937052.issue27176@psf.upfronthosting.co.za> R. David Murray added the comment: Agreed. I've never used the distinction between errors and failures myself. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 12:35:13 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Jun 2016 16:35:13 +0000 Subject: [issue27177] re match.group should support __index__ In-Reply-To: <1464790808.77.0.698310162067.issue27177@psf.upfronthosting.co.za> Message-ID: <1464798913.99.0.0815295838332.issue27177@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This looks as new feature and can go only in 3.6. ---------- nosy: +serhiy.storchaka stage: -> needs patch type: -> enhancement versions: +Python 3.6 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 12:35:40 2016 From: report at bugs.python.org (Andrey Kislyuk) Date: Wed, 01 Jun 2016 16:35:40 +0000 Subject: [issue1521950] shlex.split() does not tokenize like the shell Message-ID: <1464798940.21.0.310195254529.issue1521950@psf.upfronthosting.co.za> Andrey Kislyuk added the comment: Is there any chance of getting this into 3.6? We are still in a situation where the shlex module misleads developers into believing that it has functionality to parse things the way the shell does. I've had to vendor the copy of shlex with patches from this bug applied (thanks Vinay!) ---------- nosy: +Andrey.Kislyuk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 12:43:05 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 01 Jun 2016 16:43:05 +0000 Subject: [issue27176] Addition of assertNotRaises In-Reply-To: <1464790616.9.0.804772200909.issue27176@psf.upfronthosting.co.za> Message-ID: <1464799385.75.0.638818320605.issue27176@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I concur with David snd Steven, so closing this as rejected. ---------- nosy: +rhettinger resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 12:44:05 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Jun 2016 16:44:05 +0000 Subject: [issue27174] Update URL to IPython in interactive.rst In-Reply-To: <1464766576.17.0.0548919412603.issue27174@psf.upfronthosting.co.za> Message-ID: <20160601164240.17384.89546.AED57B3A@psf.io> Roundup Robot added the comment: New changeset 92fd6935e882 by Berker Peksag in branch '3.5': Issue #27174: Update IPython URL in tutorial https://hg.python.org/cpython/rev/92fd6935e882 New changeset 87d76611470c by Berker Peksag in branch 'default': Issue #27174: Merge from 3.5 https://hg.python.org/cpython/rev/87d76611470c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 12:44:58 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 01 Jun 2016 16:44:58 +0000 Subject: [issue27174] Update URL to IPython in interactive.rst In-Reply-To: <1464766576.17.0.0548919412603.issue27174@psf.upfronthosting.co.za> Message-ID: <1464799498.41.0.927790540202.issue27174@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report, kulla. ---------- nosy: +berker.peksag resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 13:14:18 2016 From: report at bugs.python.org (Upendra Kumar) Date: Wed, 01 Jun 2016 17:14:18 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1464801258.56.0.838528011024.issue27051@psf.upfronthosting.co.za> Upendra Kumar added the comment: @Terry, code updates can be followed on https://github.com/upendra-k14/pip_gui/tree/dump_code Please review the code in dump_code branch. For now, only pip_gui_v3.py is relevant. 1. I had doubt about including a private module from pip ( "pip._vendor" ). As this module contains a lot of important utilites I have included it by copying the "_vendor" module in my package and changed all the package references of "pip._vendor" to "pip_tkinter._vendor" to make it work. Since, it was a private module, I included it by copying it. One more reason is that pip has mentioned this module has immutable. There are very less chances that further changes in this module will be introduced in future. 2. Except a few complex commands like install, I have planned to inherit the pip command classes. For example, I have inherited the pip.commands.SearchCommand class from pip and overrided the "run" method. It helped me to give finer control over the search results. For example, Now we can retrieve all previous versions of a package ( which is not provided by pip ) and search results can be directly obtained in form of tuple lists without parsing the output. But, I think doing something similar for pip.commands.InstallCommand is very difficult. Therefore, for now I have chosen to use "runpip and pip.main" for pip install command. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 13:17:57 2016 From: report at bugs.python.org (Upendra Kumar) Date: Wed, 01 Jun 2016 17:17:57 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1464801477.51.0.0705817865592.issue27051@psf.upfronthosting.co.za> Upendra Kumar added the comment: Actually now we don't need "pip list" command to get list of installed distributions. We can directly get it : from pip_tkinter._vendor import pkg_resources installed_packages = [p.project_name for p in pkg_resources.working_set] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 13:22:29 2016 From: report at bugs.python.org (Nathan Harold) Date: Wed, 01 Jun 2016 17:22:29 +0000 Subject: [issue26589] Add HTTP Response code 451 In-Reply-To: <1458339796.0.0.55641326492.issue26589@psf.upfronthosting.co.za> Message-ID: <1464801749.74.0.50284898653.issue26589@psf.upfronthosting.co.za> Nathan Harold added the comment: Added it to the table at https://docs.python.org/3.6/library/http.html#http-status-codes and put a versionadded notice at the bottom. ---------- nosy: +nharold Added file: http://bugs.python.org/file43086/doctable.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 13:27:06 2016 From: report at bugs.python.org (Ryan Petrello) Date: Wed, 01 Jun 2016 17:27:06 +0000 Subject: [issue27172] Add skip_bound_arg argument to inspect.Signature.from_callable() In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za> Message-ID: <1464802026.28.0.0336924695898.issue27172@psf.upfronthosting.co.za> Changes by Ryan Petrello : Added file: http://bugs.python.org/file43087/signature-from-callable-skip-bound-arg.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 14:10:19 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 01 Jun 2016 18:10:19 +0000 Subject: [issue27172] Add skip_bound_arg argument to inspect.Signature.from_callable() In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za> Message-ID: <1464804619.92.0.797371764693.issue27172@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: test needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 14:11:40 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 01 Jun 2016 18:11:40 +0000 Subject: [issue27173] Modern Unix key bindings for IDLE In-Reply-To: <1464766185.36.0.150155479026.issue27173@psf.upfronthosting.co.za> Message-ID: <1464804700.33.0.939583394706.issue27173@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Original IDLE Dark patch: #24820. Follow-up for cross-version issues (initially for themes, but with a eye to keys, etc): #25313. I intended that 'name2' be future proof (msg252372). I believe my idea was that if it were to point to a future 4th default theme that did not exist, there would be a graceful fallback to 'name', which defaults to IDLE Classic. But I am not sure if I tested this, so I should recheck. If it does not work, a fix should go in all current versions. I believe the patch did achieve no warnings for older versions, as least on my machine. I would have the same goal for keys: no warning, future proof. A test of the latter before committing requires two independent repositories, both with the patch, one with the extra definitions. I currently have two 3.6 repositories and will do such a test once we have code that we think should work. When one selects IDLE Dark as Default Theme, active or not, a subdued red message is displayed: "New theme, see Help". (The latter part should change to a more explicit "click 'Help' below" so there is no possible confusion with the main menu Help. The Highlighting specific part of the popup suggests saving IDLE Dark as a custom theme, with a new name, This makes the theme available to older versions and solves compatibility problems. The same would apply to a new key set. In #24781, Mark Roseman proposed revamping the preferences dialog, both externally and internally. The main idea for the Theme tab is to present users with a single list of available themes and (mostly) hide the builtin versus custom distinction. (It cannot be ignored completely as builtins cannot be deleted and editing requires saving as custom.) https://bugs.python.org/file40111/highlight3.png has an image. We might consider the same idea for key sets. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 14:16:38 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 01 Jun 2016 18:16:38 +0000 Subject: [issue23116] Python Tutorial 4.7.1: Improve ask_ok() to cover more input values In-Reply-To: <1419622934.77.0.489991713093.issue23116@psf.upfronthosting.co.za> Message-ID: <1464804998.38.0.785306512961.issue23116@psf.upfronthosting.co.za> Berker Peksag added the comment: I agree with all of Carol's suggestions. Also, OSError could be replaced with a more appropriate exception such as ValueError. ---------- nosy: +berker.peksag stage: -> needs patch versions: +Python 3.5, Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 14:17:34 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 01 Jun 2016 18:17:34 +0000 Subject: [issue27172] Add skip_bound_arg argument to inspect.Signature.from_callable() In-Reply-To: <1464804619.95.0.766771237674.issue27172@psf.upfronthosting.co.za> Message-ID: <6E6D108A-C15D-4613-BF12-D6E9B0E1BC30@gmail.com> Yury Selivanov added the comment: Please don't commit this without my review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 14:22:00 2016 From: report at bugs.python.org (SilentGhost) Date: Wed, 01 Jun 2016 18:22:00 +0000 Subject: [issue27172] Add skip_bound_arg argument to inspect.Signature.from_callable() In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za> Message-ID: <1464805320.84.0.895097897142.issue27172@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- assignee: -> yselivanov stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 14:22:19 2016 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Wed, 01 Jun 2016 18:22:19 +0000 Subject: [issue23116] Python Tutorial 4.7.1: Improve ask_ok() to cover more input values In-Reply-To: <1419622934.77.0.489991713093.issue23116@psf.upfronthosting.co.za> Message-ID: <1464805339.5.0.327707409651.issue23116@psf.upfronthosting.co.za> Fred L. Drake, Jr. added the comment: +1 for ValueError instead of OSError. ---------- nosy: +fdrake _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 14:27:34 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 01 Jun 2016 18:27:34 +0000 Subject: [issue23116] Python Tutorial 4.7.1: Improve ask_ok() to cover more input values In-Reply-To: <1419622934.77.0.489991713093.issue23116@psf.upfronthosting.co.za> Message-ID: <1464805654.2.0.37188254898.issue23116@psf.upfronthosting.co.za> Berker Peksag added the comment: Here is a patch. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file43088/issue23116.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 14:35:39 2016 From: report at bugs.python.org (Ryan Petrello) Date: Wed, 01 Jun 2016 18:35:39 +0000 Subject: [issue27172] Add skip_bound_arg argument to inspect.Signature.from_callable() In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za> Message-ID: <1464806139.51.0.854173994729.issue27172@psf.upfronthosting.co.za> Changes by Ryan Petrello : Added file: http://bugs.python.org/file43089/signature-from-callable-skip-bound-arg.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 14:43:46 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 01 Jun 2016 18:43:46 +0000 Subject: [issue22558] Missing doc links to source code for Python-coded modules. In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za> Message-ID: <1464806626.76.0.511929547993.issue22558@psf.upfronthosting.co.za> Terry J. Reedy added the comment: [David, could this be a sprint issue?] Here is the difference between python and C coded modules. The x.y docs are for all implementations of x.y. The python-coded modules are intended for use by all implementations, perhaps with minor modifications. In any case, the users of all implementation can presumably read Python code. The C implementations used by CPython are specific to CPython, and not necessarily meaningful to user of Jython, IronPython, PyPy, or any other alternatives. In any case, Guido has unambiguiously pronounced on linking to Python source files. Doing that is enough for one issue. I changed the title to be specific. ---------- title: Missing doc links to source code -> Missing doc links to source code for Python-coded modules. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 15:09:04 2016 From: report at bugs.python.org (Ryan Petrello) Date: Wed, 01 Jun 2016 19:09:04 +0000 Subject: [issue27172] Add skip_bound_arg argument to inspect.Signature.from_callable() In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za> Message-ID: <1464808144.03.0.872807897633.issue27172@psf.upfronthosting.co.za> Changes by Ryan Petrello : Added file: http://bugs.python.org/file43090/signature-from-callable-skip-bound-arg.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 15:43:56 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Jun 2016 19:43:56 +0000 Subject: [issue27173] Modern Unix key bindings for IDLE In-Reply-To: <1464766185.36.0.150155479026.issue27173@psf.upfronthosting.co.za> Message-ID: <1464810236.47.0.170277951067.issue27173@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New patch makes IDLE silently fall back to default key set and adds a note about new key set on Keys configuration tab. ---------- Added file: http://bugs.python.org/file43091/idle_modern_unix_key_set3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 16:17:17 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 01 Jun 2016 20:17:17 +0000 Subject: [issue22558] Missing doc links to source code for Python-coded modules. In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za> Message-ID: <1464812237.77.0.237890123433.issue22558@psf.upfronthosting.co.za> R. David Murray added the comment: You mean someone doing a file review at the sprints? I can add it to the list. No guarantees about it getting committed at the sprints, though. If we are linking to the python version of modules that have both python and C versions, IMO the existence of the C version should be noted as a CPython implementation detail, since otherwise someone might think that the python code was what CPython was actually running. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 16:19:48 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 01 Jun 2016 20:19:48 +0000 Subject: [issue22558] Missing doc links to source code for Python-coded modules. In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za> Message-ID: <1464812388.86.0.1762677869.issue22558@psf.upfronthosting.co.za> R. David Murray added the comment: I meant full review, not file review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 17:09:22 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Jun 2016 21:09:22 +0000 Subject: [issue27025] More human readable generated widget names In-Reply-To: <1463299445.94.0.887025569149.issue27025@psf.upfronthosting.co.za> Message-ID: <1464815362.64.0.519168326509.issue27025@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: You can apply show_widget_names.diff to see all widget names. Run IDLE and open the configuration dialog for example. ---------- Added file: http://bugs.python.org/file43092/show_widget_names.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 17:20:04 2016 From: report at bugs.python.org (Nathan Harold) Date: Wed, 01 Jun 2016 21:20:04 +0000 Subject: [issue27178] Unconverted RST marking in interpreter tutorial Message-ID: <1464816004.4.0.533842963669.issue27178@psf.upfronthosting.co.za> New submission from Nathan Harold: There's a bit of uninterpreted RST markup: 3.6.. _tut-using: at the top of the second section of the tutorial (https://docs.python.org/3.6/tutorial/interpreter.html) in the documentation for 3.6 only. (I can see this in the offline copy I received with 3.6.0a1 as well.) It appears that this originated in 96328:dfe62f685538, which changed various references to Python to say 3.6 instead of 3.5. This line had formerly just said: .. _tut-using: My best guess is that this was just an accident. I can't find a precedent or meaning for the changed notation, and there were no similar changes to any other files, either. I've included a patch for this line. ---------- assignee: docs at python components: Documentation files: fix.diff keywords: patch messages: 266840 nosy: docs at python, nharold priority: normal severity: normal status: open title: Unconverted RST marking in interpreter tutorial type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43093/fix.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 17:28:26 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Jun 2016 21:28:26 +0000 Subject: [issue27178] Unconverted RST marking in interpreter tutorial In-Reply-To: <1464816004.4.0.533842963669.issue27178@psf.upfronthosting.co.za> Message-ID: <20160601212758.37256.15555.E70582A3@psf.io> Roundup Robot added the comment: New changeset a2ffc966363e by Berker Peksag in branch 'default': Issue #27178: Fix markup in tutorial https://hg.python.org/cpython/rev/a2ffc966363e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 17:29:08 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 01 Jun 2016 21:29:08 +0000 Subject: [issue27178] Unconverted RST marking in interpreter tutorial In-Reply-To: <1464816004.4.0.533842963669.issue27178@psf.upfronthosting.co.za> Message-ID: <1464816548.06.0.999139939823.issue27178@psf.upfronthosting.co.za> Berker Peksag added the comment: Good catch! Thanks for patch, Nathan. ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 17:30:16 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 01 Jun 2016 21:30:16 +0000 Subject: [issue27164] zlib can't decompress DEFLATE using shared dictionary In-Reply-To: <1464687663.75.0.126366287594.issue27164@psf.upfronthosting.co.za> Message-ID: <1464816616.3.0.666993581569.issue27164@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- assignee: -> gregory.p.smith nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 18:55:27 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 01 Jun 2016 22:55:27 +0000 Subject: [issue26582] asyncio documentation links to wrong CancelledError In-Reply-To: <1458225953.38.0.399231880747.issue26582@psf.upfronthosting.co.za> Message-ID: <1464821727.45.0.149216422892.issue26582@psf.upfronthosting.co.za> R. David Murray added the comment: ping: Victor or Yuri, do agree that asyncio.CancelledError should be documented? I know that this duality has confused me in the past as well. I don't know if having it documented would have helped me ahead of time, but at least it could have cleared up my puzzlement as to why I was seeing a concurrent.futures exception when I didn't think I was using concurrent.futures :) I do wonder what the OPs actual problem was with catching the exception. ---------- nosy: +r.david.murray, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 19:44:20 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 01 Jun 2016 23:44:20 +0000 Subject: [issue25931] os.fork() command distributed in windows Python27 (in SocketServer module) In-Reply-To: <1450840231.57.0.83917358919.issue25931@psf.upfronthosting.co.za> Message-ID: <1464824660.02.0.142857444956.issue25931@psf.upfronthosting.co.za> R. David Murray added the comment: They aren't currently defined conditionally, though, and haven't ever been, so I'm not sure it is worth chaning that. However, we should probably add an 'availability' line, since they aren't (effectively) available on Windows. ---------- assignee: -> docs at python components: +Documentation -Library (Lib), Windows nosy: +docs at python, r.david.murray stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 19:46:25 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 01 Jun 2016 23:46:25 +0000 Subject: [issue22558] Missing doc links to source code for Python-coded modules. In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za> Message-ID: <1464824785.83.0.780456744315.issue22558@psf.upfronthosting.co.za> Terry J. Reedy added the comment: If someone does a full review (looks at each diff in Rietveld to see if it matches the intended format -- see Yoni's 4-19 message, with :source:`Lib/mod.py` (lib2to3 is an exception) following **Source code:** -- and then downloads patch, applies, builds new html doc, and tests a few of the new links, and find nothing wrong, and says 'ready for commit review) then I may take this, re-check, and commit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 19:59:07 2016 From: report at bugs.python.org (Yoni Lavi) Date: Wed, 01 Jun 2016 23:59:07 +0000 Subject: [issue22558] Missing doc links to source code for Python-coded modules. In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za> Message-ID: <1464825547.01.0.242686554165.issue22558@psf.upfronthosting.co.za> Yoni Lavi added the comment: Thank you for looking at this. David, concerning modules that have multiple sources, are you referring to modules such as `stat` and `heapq`? In these, it's the Python source that tries to import the C module if it's available, so I'd consider it ok to leave just a link to the Python source. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 20:00:25 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 02 Jun 2016 00:00:25 +0000 Subject: [issue19012] urllib2: bad proxy configuration throws "getaddrinfo" error In-Reply-To: <1379098642.08.0.213959473701.issue19012@psf.upfronthosting.co.za> Message-ID: <1464825625.66.0.83368564518.issue19012@psf.upfronthosting.co.za> R. David Murray added the comment: Closing because no reproducer provided. ---------- resolution: -> works for me stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 20:04:05 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 02 Jun 2016 00:04:05 +0000 Subject: [issue16964] Add 'm' format specifier for mon_grouping etc. In-Reply-To: <1358182494.33.0.0372215578091.issue16964@psf.upfronthosting.co.za> Message-ID: <1464825845.37.0.848474077873.issue16964@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: needs patch -> patch review versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 20:11:46 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 02 Jun 2016 00:11:46 +0000 Subject: [issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more In-Reply-To: <1464270042.87.0.0233765451432.issue27130@psf.upfronthosting.co.za> Message-ID: <1464826306.02.0.316899089693.issue27130@psf.upfronthosting.co.za> Martin Panter added the comment: You should be able to use a compression (or decompression) object as a workaround. But calling zlib.compress() multiple times would generate multiple separate deflated streams, which is different. I think it is reasonable for Python to handle larger data sizes for zlib. (In theory, the 4 GiB UINT_MAX limit is platform-dependent.) IMO it is a matter of writing the patch(es), and perhaps depending on the complexity, deciding whether to apply them to 2.7 etc or just the next version of Python 3 (risk vs reward). Alternatively (or in the mean time), I guess we could document the limitation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 20:30:10 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 02 Jun 2016 00:30:10 +0000 Subject: [issue22558] Missing doc links to source code for Python-coded modules. In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za> Message-ID: <1464827410.05.0.962048021123.issue22558@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, those should be OK. I was thinking of _pyio and _pydecimal, but I don't know if you are linking to those. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 20:50:35 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 02 Jun 2016 00:50:35 +0000 Subject: [issue27025] More human readable generated widget names In-Reply-To: <1463299445.94.0.887025569149.issue27025@psf.upfronthosting.co.za> Message-ID: <1464828635.15.0.23712648422.issue27025@psf.upfronthosting.co.za> Terry J. Reedy added the comment: To make the experiment easy to repeat, say after the patch, I wrote this. (Perhaps inspired by Ned Batchelder's 'machete debugging' PyCon talk.) import tkinter as tk from idlelib.configdialog import ConfigDialog _realsetup = tk.BaseWidget._setup def _wrapsetup(self, master, cnf): _realsetup(self, master, cnf) print(self.widgetName, self._w) tk.BaseWidget._setup = _wrapsetup root = tk.Tk() ConfigDialog(roo) ttk.BaseWidget._setup = _realsetup Observations: the longest path rather long: ....... The root to widget paths collectively represent a tree and, sorted, could be used to populate a tree widget, such as a Treeview. With the proposed new names, this would give one a useful overview of the total gui, or a part thereof. If one subclasses a widget, such as class MyFrame(Frame, would the instance .widgetName used in the patch 'Frame' or 'MyFrame'? The latter would make the treeview really useful, and reward judicious subclassing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 20:52:46 2016 From: report at bugs.python.org (=?utf-8?b?RMSBdmlz?=) Date: Thu, 02 Jun 2016 00:52:46 +0000 Subject: [issue27179] subprocess uses wrong encoding on Windows Message-ID: <1464828766.51.0.809606583575.issue27179@psf.upfronthosting.co.za> New submission from D?vis: subprocess uses wrong encoding on Windows. On Windows 10 with Python 3.5.1 from Command Prompt (cmd.exe) > chcp 65001 > python -c "import subprocess; subprocess.getstatusoutput('?')" Traceback (most recent call last): File "", line 1, in File "P:\Python35\lib\subprocess.py", line 808, in getstatusoutput data = check_output(cmd, shell=True, universal_newlines=True, stderr=STDOUT) File "P:\Python35\lib\subprocess.py", line 629, in check_output **kwargs).stdout File "P:\Python35\lib\subprocess.py", line 698, in run stdout, stderr = process.communicate(input, timeout=timeout) File "P:\Python35\lib\subprocess.py", line 1055, in communicate stdout = self.stdout.read() File "P:\Python35\lib\encodings\cp1257.py", line 23, in decode return codecs.charmap_decode(input,self.errors,decoding_table)[0] UnicodeDecodeError: 'charmap' codec can't decode byte 0x81 in position 2: character maps to from PowerShell > [Console]::OutputEncoding = [System.Text.Encoding]::UTF8 > python -c "import subprocess; subprocess.getstatusoutput('?')" Traceback (most recent call last): File "", line 1, in File "P:\Python35\lib\subprocess.py", line 808, in getstatusoutput data = check_output(cmd, shell=True, universal_newlines=True, stderr=STDOUT) File "P:\Python35\lib\subprocess.py", line 629, in check_output **kwargs).stdout File "P:\Python35\lib\subprocess.py", line 698, in run stdout, stderr = process.communicate(input, timeout=timeout) File "P:\Python35\lib\subprocess.py", line 1055, in communicate stdout = self.stdout.read() File "P:\Python35\lib\encodings\cp1257.py", line 23, in decode return codecs.charmap_decode(input,self.errors,decoding_table)[0] UnicodeDecodeError: 'charmap' codec can't decode byte 0x81 in position 2: character maps to As you can see even if consoles encoding is UTF-8 it still uses Windows ANSI codepage 1257 this happens because io.TextIOWrapper is used with default encoding which is locale.getpreferredencoding(False) but that's wrong because that's not console's encoding. I've attached a patch which fixes this by using correct console encoding with sys.stdout.encoding Only note that there's different bug that when python is executed inside PowerShell's group expression then sys.stdout.encoding will be wrong > [Console]::OutputEncoding.EncodingName Unicode (UTF-8) > ([Console]::OutputEncoding.EncodingName) Unicode (UTF-8) > python -c "import sys; print(sys.stdout.encoding)" cp65001 > (python -c "import sys; print(sys.stdout.encoding)") cp1257 it still should be cp65001 and that's why in this case subprocess will still fail even with my patch, but this some different bug. ---------- components: IO, Library (Lib), Unicode, Windows files: subprocess_fix_encoding.patch keywords: patch messages: 266852 nosy: davispuh, ezio.melotti, haypo, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: subprocess uses wrong encoding on Windows type: behavior versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43094/subprocess_fix_encoding.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 20:57:02 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Jun 2016 00:57:02 +0000 Subject: [issue27179] subprocess uses wrong encoding on Windows In-Reply-To: <1464828766.51.0.809606583575.issue27179@psf.upfronthosting.co.za> Message-ID: <1464829022.41.0.496223416618.issue27179@psf.upfronthosting.co.za> STINNER Victor added the comment: What is the ? command? Where does it come from? What is its output? Do you know the encoding of its output? It remembers me the "set" issue in distutils: issue #27048. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 21:03:12 2016 From: report at bugs.python.org (=?utf-8?b?RMSBdmlz?=) Date: Thu, 02 Jun 2016 01:03:12 +0000 Subject: [issue27179] subprocess uses wrong encoding on Windows In-Reply-To: <1464828766.51.0.809606583575.issue27179@psf.upfronthosting.co.za> Message-ID: <1464829392.86.0.21388917679.issue27179@psf.upfronthosting.co.za> D?vis added the comment: there's no such "?" command, it's just used to get non-ASCII output cmd will return: '?' is not recognized as an internal or external command, operable program or batch file. and this will be encoded in consoles encoding (UTF8 in my example or whatever chcp is set to) which Python will fail to read as it will use locale.getpreferredencoding(False) instead of sys.stdout.encoding see attached patch, it fixes this problem, you can try reproduce yourself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 21:16:29 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Jun 2016 01:16:29 +0000 Subject: [issue12243] getpass.getuser works on OSX In-Reply-To: <1307029704.02.0.858553376312.issue12243@psf.upfronthosting.co.za> Message-ID: <20160602011624.79366.6148.4969F37A@psf.io> Roundup Robot added the comment: New changeset c13198a2007e by Berker Peksag in branch '3.5': Issue #12243: Remove redundant availability notes from getpass docs https://hg.python.org/cpython/rev/c13198a2007e New changeset 1bd3daae351d by Berker Peksag in branch 'default': Issue #12243: Merge from 3.5 https://hg.python.org/cpython/rev/1bd3daae351d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 21:18:30 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 02 Jun 2016 01:18:30 +0000 Subject: [issue12243] getpass.getuser works on OSX In-Reply-To: <1307029704.02.0.858553376312.issue12243@psf.upfronthosting.co.za> Message-ID: <1464830310.74.0.780069243914.issue12243@psf.upfronthosting.co.za> Berker Peksag added the comment: See issue 11233 for the availability directive patch. Thanks for the patch, Bryce. ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed type: -> behavior versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 21:20:30 2016 From: report at bugs.python.org (Yoni Lavi) Date: Thu, 02 Jun 2016 01:20:30 +0000 Subject: [issue22558] Missing doc links to source code for Python-coded modules. In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za> Message-ID: <1464830430.0.0.982129800794.issue22558@psf.upfronthosting.co.za> Yoni Lavi added the comment: Ah, thanks for the explanation. I think in this case we're ok too. I linked io.rst to Lib/io.py, which relies on the C version. And in the case of decimal.rst, it was already linked to Lib/decimal.py which very explicitly attempts to load the C version and falls back to _pydecimal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 21:23:18 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Jun 2016 01:23:18 +0000 Subject: [issue12243] getpass.getuser works on OSX In-Reply-To: <1307029704.02.0.858553376312.issue12243@psf.upfronthosting.co.za> Message-ID: <20160602012313.4689.84904.AC566C7C@psf.io> Roundup Robot added the comment: New changeset 98870f27d2ed by Berker Peksag in branch '2.7': Issue #12243: Remove redundant availability notes from getpass docs https://hg.python.org/cpython/rev/98870f27d2ed ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 21:29:56 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 02 Jun 2016 01:29:56 +0000 Subject: [issue27025] More human readable generated widget names In-Reply-To: <1463299445.94.0.887025569149.issue27025@psf.upfronthosting.co.za> Message-ID: <1464830996.04.0.129355924929.issue27025@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Try this instead. import tkinter as tk from idlelib.configdialog import ConfigDialog from idlelib import macosx _realsetup = tk.BaseWidget._setup def _wrapsetup(self, master, cnf): _realsetup(self, master, cnf) print(self.widgetName, self._w) tk.BaseWidget._setup = _wrapsetup root = tk.Tk() macosx._initializeTkVariantTests(root) ConfigDialog(root) tk.BaseWidget._setup = _realsetup ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 21:42:03 2016 From: report at bugs.python.org (=?utf-8?b?RMSBdmlz?=) Date: Thu, 02 Jun 2016 01:42:03 +0000 Subject: [issue27179] subprocess uses wrong encoding on Windows In-Reply-To: <1464828766.51.0.809606583575.issue27179@psf.upfronthosting.co.za> Message-ID: <1464831723.42.0.99461789411.issue27179@psf.upfronthosting.co.za> D?vis added the comment: I looked at #27048 and indeed it's affected by this bug, it happens to me too (I've non-ASCII symbols in %PATH%) and this my patch fixes that. on my system without patch > python -c "from distutils import _msvccompiler; _msvccompiler._get_vc_env('')" Traceback (most recent call last): File "", line 1, in File "P:\Python35\lib\distutils\_msvccompiler.py", line 92, in _get_vc_env universal_newlines=True, File "P:\Python35\lib\subprocess.py", line 629, in check_output **kwargs).stdout File "P:\Python35\lib\subprocess.py", line 698, in run stdout, stderr = process.communicate(input, timeout=timeout) File "P:\Python35\lib\subprocess.py", line 1055, in communicate stdout = self.stdout.read() File "P:\Python35\lib\encodings\cp1257.py", line 23, in decode return codecs.charmap_decode(input,self.errors,decoding_table)[0] UnicodeDecodeError: 'charmap' codec can't decode byte 0x83 in position 50: character maps to with my patch > python -c "from distutils import _msvccompiler; _msvccompiler._get_vc_env('')" > no error ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 21:55:50 2016 From: report at bugs.python.org (Tony Grue) Date: Thu, 02 Jun 2016 01:55:50 +0000 Subject: [issue6443] _winreg.QueryValueEx confused on double null terminated strings In-Reply-To: <1247109670.35.0.187157773378.issue6443@psf.upfronthosting.co.za> Message-ID: <1464832550.85.0.385334345502.issue6443@psf.upfronthosting.co.za> Tony Grue added the comment: I see this was closed,though it sounds like it's because a work around is found, not because the code now handles multiple null values in a row. Looking at code from the github mirror (pasted below); it looks like the issue is that the countStrings function breaks out of iterating in the for loop, even if it hasn't reached the end of the buffer. File PC/winreg.c: static int countStrings(wchar_t *data, int len) { int strings; wchar_t *P; wchar_t *Q = data + len; for (P = data, strings = 0; P < Q && *P != '\0'; P++, strings++) for (; P < Q && *P != '\0'; P++) ; return strings; } ---------- nosy: +Tony Grue versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 21:59:50 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 02 Jun 2016 01:59:50 +0000 Subject: [issue22374] Replace contextmanager example and improve explanation In-Reply-To: <1410296292.35.0.34327651623.issue22374@psf.upfronthosting.co.za> Message-ID: <1464832790.37.0.394024083058.issue22374@psf.upfronthosting.co.za> Berker Peksag added the comment: We also have swap_attr() and swap_item() helpers in Lib/test/support/__init__.py. I've used a simplified version of swap_attr() in my patch. Since this is basically a document improvement I removed Python 2.7 from the versions field. ---------- keywords: +patch nosy: +berker.peksag stage: -> patch review type: -> enhancement versions: +Python 3.6 -Python 2.7, Python 3.4 Added file: http://bugs.python.org/file43095/issue22374.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 22:03:14 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 02 Jun 2016 02:03:14 +0000 Subject: [issue8519] doc: termios and ioctl reference links In-Reply-To: <1272125391.54.0.0119716465224.issue8519@psf.upfronthosting.co.za> Message-ID: <1464832994.51.0.0553012008939.issue8519@psf.upfronthosting.co.za> Berker Peksag added the comment: +1 for using the manpage directives. ---------- keywords: +easy nosy: +berker.peksag stage: -> needs patch type: -> enhancement versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 22:12:19 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 02 Jun 2016 02:12:19 +0000 Subject: [issue20693] Sidebar scrolls down 2x as fast as page content In-Reply-To: <1392854470.16.0.730014647108.issue20693@psf.upfronthosting.co.za> Message-ID: <1464833539.42.0.187155516632.issue20693@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 22:38:26 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 02 Jun 2016 02:38:26 +0000 Subject: [issue27179] subprocess uses wrong encoding on Windows In-Reply-To: <1464828766.51.0.809606583575.issue27179@psf.upfronthosting.co.za> Message-ID: <1464835106.3.0.697918590311.issue27179@psf.upfronthosting.co.za> Martin Panter added the comment: I don?t know much about the conventions for stdout etc encoding on Windows. But in general, the patch does not seem robust. Does it work if sys.stdout is a pipe or file (not a console)? I doubt it will work when sys.stdout has been replaced by e.g. StringIO, and sys.stdout.encoding is None. Maybe you could use sys.__stdout__. But then, what happens when you run Python without any stdout at all, say in a GUI like Idle? On Linux, the patch may have no effect in common cases. But again, it will break if sys.stdout has been replaced, or is set to None. Looking at _Py_device_encoding() in Python/fileutils.c, perhaps you need a Windows-specific interface to GetConsoleCP() and GetConsoleOutputCP() that subprocess can use. ---------- nosy: +martin.panter stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 22:46:18 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 02 Jun 2016 02:46:18 +0000 Subject: [issue18085] Verifying refcounts.dat In-Reply-To: <1369768958.38.0.697954786488.issue18085@psf.upfronthosting.co.za> Message-ID: <1464835578.33.0.107196013603.issue18085@psf.upfronthosting.co.za> Berker Peksag added the comment: Can we now close this as a duplicate of issue 9755? ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 22:55:07 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 02 Jun 2016 02:55:07 +0000 Subject: [issue18384] Add devhelp build instructions to the documentation makefile In-Reply-To: <1373126872.99.0.196855788769.issue18384@psf.upfronthosting.co.za> Message-ID: <1464836107.37.0.252170816055.issue18384@psf.upfronthosting.co.za> Berker Peksag added the comment: I think we should avoid adding distro specific tools into CPython repository (and the another reason to reject this is that the other distros will probably want to add their tools). ---------- nosy: +berker.peksag resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 23:03:39 2016 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Thu, 02 Jun 2016 03:03:39 +0000 Subject: [issue9755] Fix refcounting details in Py3k C API documentation In-Reply-To: <1283514224.53.0.325600320074.issue9755@psf.upfronthosting.co.za> Message-ID: <1464836619.98.0.0909618144409.issue9755@psf.upfronthosting.co.za> Fred L. Drake, Jr. added the comment: As mentioned in issue 18085, the original file was not generated, but crafted by hand (though I don't think that really matters). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 23:07:53 2016 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Thu, 02 Jun 2016 03:07:53 +0000 Subject: [issue18085] Verifying refcounts.dat In-Reply-To: <1369768958.38.0.697954786488.issue18085@psf.upfronthosting.co.za> Message-ID: <1464836873.65.0.268583975721.issue18085@psf.upfronthosting.co.za> Fred L. Drake, Jr. added the comment: I don't think this is a duplicate of issue 9755; this relates to verifying the data, and that revolves around possible process improvements. Whether this issue should be closed is tied to whether the file has been verified, as the issue title suggests. I don't know whether Serhiy verified everything when he made his changes or not; that's not explicit in the issue or commit comments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 23:21:17 2016 From: report at bugs.python.org (James Schneider) Date: Thu, 02 Jun 2016 03:21:17 +0000 Subject: [issue20825] containment test for "ip_network in ip_network" In-Reply-To: <1393766299.38.0.300697561376.issue20825@psf.upfronthosting.co.za> Message-ID: <1464837677.31.0.696353658529.issue20825@psf.upfronthosting.co.za> James Schneider added the comment: I'd like to ask for a status on getting this merged? As a network administrator, these changes would have a magical effect on my code dealing with routing tables and ACL's. ---------- nosy: +James Schneider _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 23:26:40 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 02 Jun 2016 03:26:40 +0000 Subject: [issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more In-Reply-To: <1464270042.87.0.0233765451432.issue27130@psf.upfronthosting.co.za> Message-ID: <1464838000.15.0.375988575926.issue27130@psf.upfronthosting.co.za> Xiang Zhang added the comment: Yes. It's compression object not compress. I find more. The overflow checking is introduced to solve problem in issue8650. It seems the explicit overflow checking is introduced to keep compatibility with py2 (py2 raises the overflowerror in pyargparse). I support loosing the limitation, but now it can only go into the next version of py3. ---------- nosy: +nadeem.vawda _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 1 23:59:46 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 02 Jun 2016 03:59:46 +0000 Subject: [issue27164] zlib can't decompress DEFLATE using shared dictionary In-Reply-To: <1464687663.75.0.126366287594.issue27164@psf.upfronthosting.co.za> Message-ID: <1464839986.26.0.921838425045.issue27164@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for the patches. Maybe Gregory knows more about this than I do (I never used zdict). But I think I have figured it out today, so I left some review comments :) I?m not sure whether this really is a bug fix, although it would have little if any impact on existing code. It seems zdict was implemented with just the non-raw zlib format in mind, so supporting raw deflate mode is a new feature. If we were to add full support of inflateSetDictionary() for raw deflate mode, I imagine it would be a new decompressobj.set_dictionary() method. I did some quick tests with specifying an unnecessary zdict buffer to the decompressor (when zdict not used for compression), and it doesn?t _seem_ to break anything, but I am not 100% sure. Notes from my learning what zdict means: Zdict seems to be a bunch of user data to setup or train the (de)compressor with. It was added by Issue 14684. (Not a Python dictionary, nor any special zlib dictionary format. The Python documentation is confusing, and the Go documentation made more sense, assuming it is equivalent.) See the documentation of in/deflateSetDictionary() in or zlib.h. Looking through the history at can also be useful. ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 00:08:34 2016 From: report at bugs.python.org (Steve Dower) Date: Thu, 02 Jun 2016 04:08:34 +0000 Subject: [issue27179] subprocess uses wrong encoding on Windows In-Reply-To: <1464828766.51.0.809606583575.issue27179@psf.upfronthosting.co.za> Message-ID: <1464840514.34.0.991006575089.issue27179@psf.upfronthosting.co.za> Steve Dower added the comment: Even sys.__stdout__ can be missing. In this context, falling back on the default encoding is probably fine, but for 3.6 I'd like to make everything default to UTF-8 on Windows, and force the console mode on startup (restore on finalize) - apart from the input() implementation it's fairly straightforward. But don't hold up an immediate fix on that change, just be aware that I'm tinkering with a good long-term fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 00:12:30 2016 From: report at bugs.python.org (Eryk Sun) Date: Thu, 02 Jun 2016 04:12:30 +0000 Subject: [issue27179] subprocess uses wrong encoding on Windows In-Reply-To: <1464828766.51.0.809606583575.issue27179@psf.upfronthosting.co.za> Message-ID: <1464840750.67.0.274821080849.issue27179@psf.upfronthosting.co.za> Eryk Sun added the comment: There is no right encoding as far as I can see. If it's attached to a console (i.e. conhost.exe), then cmd.exe uses the console's output codepage when writing to a pipe or file, which is the scenario that your patch attempts to address. But if you pass creationflags=CREATE_NO_WINDOW, then the new console (created without a window) uses the OEM codepage, CP_OEMCP. And if you pass creationflags=DETACHED_PROCESS (i.e. no console), cmd uses the ANSI codepage, CP_ACP. There's also a "/u" option to force cmd to use the native Unicode encoding on Windows, UTF-16LE. Note that the above only considers cmd.exe. Its child processes can write output using any encoding. You may end up with several different encodings present in the same stream. Many, if not most, programs don't use the console's current codepage when writing to a pipe or file. Commonly they default to OEM, ANSI, UTF-8, or UTF-16LE. For example, Windows Python uses ANSI for standard I/O that's not a console, unless you set PYTHONIOENCODING. Even if a called program cares about the console output codepage, your patch doesn't implement this robustly. It uses sys.stdout and sys.stderr, but those can be reassigned. Even sys.__stdout__ and sys.__stderr__ may be irrelevant. Python could be run via pythonw.exe for which the latter are None (unless it's started with non-NULL standard handles). Or python.exe could be run with standard I/O redirected to pipes or files, defaulting to ANSI. Also, the current program or called program could change the console encoding via chcp.com, which is just an indirect way of calling the WinAPI functions SetConsoleCP and SetConsoleOutputCP. There's no common default encoding for standard I/O on Windows, especially not a common UTF encoding, so universal_newlines=True, getoutput, and getstatusoutput may be of limited use. Preferably a calling program can set an option like cmd's "/u" or Python's PYTHONIOENCODING to force using a Unicode encoding, and then manually decode the output by wrapping stdout/stderr in instances of io.TextIOWrapper. It would help if subprocess.Popen had parameters for encoding and errors. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 00:45:47 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 02 Jun 2016 04:45:47 +0000 Subject: [issue27025] More human readable generated widget names In-Reply-To: <1463299445.94.0.887025569149.issue27025@psf.upfronthosting.co.za> Message-ID: <1464842747.81.0.925904521843.issue27025@psf.upfronthosting.co.za> Raymond Hettinger added the comment: +1 I think would be a nice improvement. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 01:25:33 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 02 Jun 2016 05:25:33 +0000 Subject: [issue27179] subprocess uses wrong encoding on Windows In-Reply-To: <1464828766.51.0.809606583575.issue27179@psf.upfronthosting.co.za> Message-ID: <1464845133.28.0.506242608419.issue27179@psf.upfronthosting.co.za> Martin Panter added the comment: I think Issue 6135 has a bit of discussion on adding encoding and error parameters to subprocess.Popen etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 01:59:08 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 02 Jun 2016 05:59:08 +0000 Subject: [issue27164] zlib can't decompress DEFLATE using shared dictionary In-Reply-To: <1464687663.75.0.126366287594.issue27164@psf.upfronthosting.co.za> Message-ID: <1464847148.65.0.593576479364.issue27164@psf.upfronthosting.co.za> Xiang Zhang added the comment: Thanks for your review, Martin. :) I have replied with after thinking and try. Yes, this is more like a feature request. But for the end user, this behaviour is quite like a bug. > If we were to add full support of inflateSetDictionary() for raw deflate mode, I imagine it would be a new decompressobj.set_dictionary() method. I don't support adding a new set_dictionary() method. Right now decompressobj handles raw deflate format, zlib format and gzip format. Adding a set_dictionary() method for raw deflate format seems weird. If we are going to do so, I suggest reorganize the zlib like PHP and nodejs do, separating different formats into different objects. > I did some quick tests with specifying an unnecessary zdict buffer to the decompressor (when zdict not used for compression), and it doesn?t _seem_ to break anything, but I am not 100% sure. This patch only affects raw inflate. You have to set wbits negative. If you are decompressing with an unnecessary zdict, I think it ought to emit an error. With Python background, zlib dictionary is really hard to understand. I think manual doesn't tell much. I understand why zdict is needed until reading https://blog.cloudflare.com/improving-compression-with-preset-deflate-dictionary/. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 02:31:11 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 02 Jun 2016 06:31:11 +0000 Subject: [issue13501] Make libedit support more generic; port readline / libedit to FreeBSD In-Reply-To: <1322579942.3.0.601983912656.issue13501@psf.upfronthosting.co.za> Message-ID: <1464849071.6.0.621275009444.issue13501@psf.upfronthosting.co.za> Martin Panter added the comment: Patch v4 resolves conflicts against the current code. I also used AC_CHECK_DECL invocations instead of AC_COMPILE_IFELSE in the configure script. FTR I think my problems with the prompt and the terminal settings are caused by a line of code that is commented out in the Apple version. See and . Also, the following test fails for me when using Editline: ====================================================================== ERROR: testHistoryUpdates (test.test_readline.TestHistoryManipulation) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/proj/python/cpython/Lib/test/test_readline.py", line 38, in testHistoryUpdates readline.replace_history_item(0, "replaced line") ValueError: No history item at position 0 Third, test_zipimport passes, but messes up the terminal (staircase effect). Probably related to the Apple patch mentioned above. ---------- Added file: http://bugs.python.org/file43096/editline.v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 03:34:51 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Jun 2016 07:34:51 +0000 Subject: [issue27025] More human readable generated widget names In-Reply-To: <1463299445.94.0.887025569149.issue27025@psf.upfronthosting.co.za> Message-ID: <1464852891.51.0.959683151072.issue27025@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I have experimented with different naming schemes. Original output with Terry's example (actually names are longer in IDLE, since the configuration dialog is created as a child of other toplevel widget): label .3070117292.3069168812.3069169068.3069251628.3068822220.3069266540.3068822348.3068839820.3068851532 entry .3070117292.3069168812.3069169068.3069251628.3068822220.3069266540.3068822348.3068839820.3068851628 frame .3070117292.3069168812.3069169068.3069251628.3068822220.3068850604 scrollbar .3070117292.3069168812.3069169068.3069251628.3068822220.3068850604.3068851916 canvas .3070117292.3069168812.3069169068.3069251628.3068822220.3068850604.3068852108 frame .3070117292.3069168812.3069169068.3069251628.3068822220.3068850604.3068852108.3068852428 label .3070117292.3069168812.3069169068.3069251628.3068822220.3068850604.3068852108.3068852428.3068852780 checkbutton .3070117292.3069168812.3069169068.3069251628.3068822220.3068850604.3068852108.3068852428.3068852940 Using Tk command name as a base of a name: label ._toplevel1._frame1._frame2._frame73._labelframe10._frame127._canvas6._frame128._label28 entry ._toplevel1._frame1._frame2._frame73._labelframe10._frame127._canvas6._frame128._entry9 frame ._toplevel1._frame1._frame2._frame73._labelframe10._frame129 scrollbar ._toplevel1._frame1._frame2._frame73._labelframe10._frame129._scrollbar12 canvas ._toplevel1._frame1._frame2._frame73._labelframe10._frame129._canvas7 frame ._toplevel1._frame1._frame2._frame73._labelframe10._frame129._canvas7._frame130 label ._toplevel1._frame1._frame2._frame73._labelframe10._frame129._canvas7._frame130._label29 checkbutton ._toplevel1._frame1._frame2._frame73._labelframe10._frame129._canvas7._frame130._checkbutton11 Using Python class name: label ._configdialog1._tabbedpageset1._frame1._frame61._labelframe10._verticalscrolledframe6._canvas6._frame105._label28 entry ._configdialog1._tabbedpageset1._frame1._frame61._labelframe10._verticalscrolledframe6._canvas6._frame105._entry9 frame ._configdialog1._tabbedpageset1._frame1._frame61._labelframe10._verticalscrolledframe7 scrollbar ._configdialog1._tabbedpageset1._frame1._frame61._labelframe10._verticalscrolledframe7._scrollbar12 canvas ._configdialog1._tabbedpageset1._frame1._frame61._labelframe10._verticalscrolledframe7._canvas7 frame ._configdialog1._tabbedpageset1._frame1._frame61._labelframe10._verticalscrolledframe7._canvas7._frame106 label ._configdialog1._tabbedpageset1._frame1._frame61._labelframe10._verticalscrolledframe7._canvas7._frame106._label29 checkbutton ._configdialog1._tabbedpageset1._frame1._frame61._labelframe10._verticalscrolledframe7._canvas7._frame106._checkbutton11 It is more informative, but names are usually longer. Using an abbreviation (upper letters from Python class name in camel style): label ._cd1._tps1._f1._f61._lf10._vsf6._c14._f105._l32 entry ._cd1._tps1._f1._f61._lf10._vsf6._c14._f105._e9 frame ._cd1._tps1._f1._f61._lf10._vsf7 scrollbar ._cd1._tps1._f1._f61._lf10._vsf7._s13 canvas ._cd1._tps1._f1._f61._lf10._vsf7._c17 frame ._cd1._tps1._f1._f61._lf10._vsf7._c17._f106 label ._cd1._tps1._f1._f61._lf10._vsf7._c17._f106._l33 checkbutton ._cd1._tps1._f1._f61._lf10._vsf7._c17._f106._c18 Names are short, but different classes can have the same abbreviation (e.g. Checkbutton and Canvas). This doesn't cause name clashes, just widget types become non-distinguishable by names. One problem with these schemes is that they change the rule for avoiding name conflicts. Currently you can just use names that are Python identifier -- they never conflict with generated names. With above schemes you should avoid names starting with an underscore. Other problem is that they use sequential numbering for every widget type. If you already created 100 frames, the single frame in new window will have name ._frame101. If use separate count for every parent widget, numbers can be smaller (the number is first because it is the serial number of the child in the parent widget): label .1toplevel.1frame.1frame.5frame.3labelframe.6frame.2canvas.1frame.7label entry .1toplevel.1frame.1frame.5frame.3labelframe.6frame.2canvas.1frame.8entry frame .1toplevel.1frame.1frame.5frame.3labelframe.7frame scrollbar .1toplevel.1frame.1frame.5frame.3labelframe.7frame.1scrollbar canvas .1toplevel.1frame.1frame.5frame.3labelframe.7frame.2canvas frame .1toplevel.1frame.1frame.5frame.3labelframe.7frame.2canvas.1frame label .1toplevel.1frame.1frame.5frame.3labelframe.7frame.2canvas.1frame.1label checkbutton .1toplevel.1frame.1frame.5frame.3labelframe.7frame.2canvas.1frame.2checkbutton If use separate numbering for every child type in a parent: label ._toplevel1._frame1._frame1._frame5._labelframe1._frame6._canvas1._frame1._label4 entry ._toplevel1._frame1._frame1._frame5._labelframe1._frame6._canvas1._frame1._entry2 frame ._toplevel1._frame1._frame1._frame5._labelframe1._frame7 scrollbar ._toplevel1._frame1._frame1._frame5._labelframe1._frame7._scrollbar1 canvas ._toplevel1._frame1._frame1._frame5._labelframe1._frame7._canvas1 frame ._toplevel1._frame1._frame1._frame5._labelframe1._frame7._canvas1._frame1 label ._toplevel1._frame1._frame1._frame5._labelframe1._frame7._canvas1._frame1._label1 checkbutton ._toplevel1._frame1._frame1._frame5._labelframe1._frame7._canvas1._frame1._checkbutton1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 03:43:49 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Jun 2016 07:43:49 +0000 Subject: [issue18085] Verifying refcounts.dat In-Reply-To: <1369768958.38.0.697954786488.issue18085@psf.upfronthosting.co.za> Message-ID: <1464853429.62.0.922279667476.issue18085@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: No, I hadn't verified all names. I'm sure there are API functions not mentioned in refcounts.dat. See also issue23903. It would be nice to have a tool that parses Python source headers and produce lists of all public names in different formats for manual updating python3.def, refcounts.dat, docs, etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 04:42:53 2016 From: report at bugs.python.org (=?utf-8?q?Adam_Biela=C5=84ski?=) Date: Thu, 02 Jun 2016 08:42:53 +0000 Subject: [issue27165] Skip callables when displaying exception fields in cgitb In-Reply-To: <1464689112.02.0.764355408735.issue27165@psf.upfronthosting.co.za> Message-ID: <1464856973.91.0.96026669515.issue27165@psf.upfronthosting.co.za> Changes by Adam Biela?ski : Added file: http://bugs.python.org/file43097/cgitb.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 04:43:23 2016 From: report at bugs.python.org (=?utf-8?q?Adam_Biela=C5=84ski?=) Date: Thu, 02 Jun 2016 08:43:23 +0000 Subject: [issue27165] Skip callables when displaying exception fields in cgitb In-Reply-To: <1464689112.02.0.764355408735.issue27165@psf.upfronthosting.co.za> Message-ID: <1464857003.61.0.315511048021.issue27165@psf.upfronthosting.co.za> Changes by Adam Biela?ski : Removed file: http://bugs.python.org/file43065/cgitb.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 05:14:36 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Jun 2016 09:14:36 +0000 Subject: [issue26582] asyncio documentation links to wrong CancelledError In-Reply-To: <1464821727.45.0.149216422892.issue26582@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > do agree that asyncio.CancelledError should be documented? Yes, I would prefer to get the exception from asyncio, even if it is officially an alias to an exception of a different module. It would be surprising to have to import concurrent.futures in a module written for asyncio, just to catch this exception. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 05:46:05 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 02 Jun 2016 09:46:05 +0000 Subject: [issue16182] readline: Wrong tab completion scope indices in Unicode terminals In-Reply-To: <1349813384.06.0.615857426211.issue16182@psf.upfronthosting.co.za> Message-ID: <1464860765.13.0.103825288176.issue16182@psf.upfronthosting.co.za> Martin Panter added the comment: V3 finishes what I started in v2: * Changed unchecked PyBytes_AsString() ? PyBytes_AS_STRING() * Testing more functions for non-ASCII characters I tried to test it with Editline on Linux (using my patch for Issue 13501). There seem to be many quirks with my version of Editline, some of which are not easy to work around: * Initial CR swallowed when entering non-ASCII * set_completion_display_matches_hook(), set_pre_input_hook(), set_completer_delims() all do nothing useful * get_history_item() not updated straight after read_history_file() I suspect Apple has patched their version of Editline, but if these quirks exist on Apple as well, it might be simplest to skip the test for Editline. ---------- Added file: http://bugs.python.org/file43098/readline_locale.v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 06:41:09 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Jun 2016 10:41:09 +0000 Subject: [issue27171] Fix various typos In-Reply-To: <1464753470.11.0.0270588746388.issue27171@psf.upfronthosting.co.za> Message-ID: <20160602104105.2216.87033.5F05AFDB@psf.io> Roundup Robot added the comment: New changeset ce31ee3b1e69 by Martin Panter in branch '3.5': Issue #27171: Fix typos in documentation, comments, and test function names https://hg.python.org/cpython/rev/ce31ee3b1e69 New changeset c67f1f4ebb32 by Martin Panter in branch 'default': Issue #27171: Merge typo fixes from 3.5 https://hg.python.org/cpython/rev/c67f1f4ebb32 New changeset 0ddba0abab49 by Martin Panter in branch 'default': Issue #27171: Fix typo in exception message https://hg.python.org/cpython/rev/0ddba0abab49 New changeset b0b463760b45 by Martin Panter in branch '2.7': Issue #27171: Fix typos in documentation, code comments, and tests https://hg.python.org/cpython/rev/b0b463760b45 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 07:18:19 2016 From: report at bugs.python.org (Masato HASHIMOTO) Date: Thu, 02 Jun 2016 11:18:19 +0000 Subject: [issue27180] Doc/pathlib: Please describe the behaviour of Path().rename() is depends on the platform (same as os.rename()) Message-ID: <1464866299.22.0.549959469595.issue27180@psf.upfronthosting.co.za> New submission from Masato HASHIMOTO: The behavior of Path().rename() is same as os.rename() (replaces silently if dest file is already existent on Unix) but it's difficult to catch from current pathlib documentation (I found it from source of pathlib) from comparing with replace(). IMHO, it should be described on pathlilb documentation. ---------- assignee: docs at python components: Documentation messages: 266883 nosy: docs at python, hashimo priority: normal severity: normal status: open title: Doc/pathlib: Please describe the behaviour of Path().rename() is depends on the platform (same as os.rename()) type: enhancement versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 07:20:39 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 02 Jun 2016 11:20:39 +0000 Subject: [issue27171] Fix various typos In-Reply-To: <1464753470.11.0.0270588746388.issue27171@psf.upfronthosting.co.za> Message-ID: <1464866439.83.0.380962998631.issue27171@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 08:24:07 2016 From: report at bugs.python.org (Ram Rachum) Date: Thu, 02 Jun 2016 12:24:07 +0000 Subject: [issue27181] Add geometric mean to `statistics` module Message-ID: <1464870247.83.0.633745051899.issue27181@psf.upfronthosting.co.za> Changes by Ram Rachum : ---------- components: Library (Lib) nosy: cool-RR priority: normal severity: normal status: open title: Add geometric mean to `statistics` module type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 08:35:59 2016 From: report at bugs.python.org (Jeroen Demeyer) Date: Thu, 02 Jun 2016 12:35:59 +0000 Subject: [issue27177] re match.group should support __index__ In-Reply-To: <1464790808.77.0.698310162067.issue27177@psf.upfronthosting.co.za> Message-ID: <1464870959.4.0.498494707121.issue27177@psf.upfronthosting.co.za> Jeroen Demeyer added the comment: I would still argue that it's a bug. The intention of PEP 357 is that __index__ should be used whenever some object needs to be converted to a Py_ssize_t, which is exactly what you do here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 08:38:33 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 02 Jun 2016 12:38:33 +0000 Subject: [issue27181] Add geometric mean to `statistics` module Message-ID: <1464871113.64.0.358334106697.issue27181@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 10:00:55 2016 From: report at bugs.python.org (Matthew Barnett) Date: Thu, 02 Jun 2016 14:00:55 +0000 Subject: [issue27177] re match.group should support __index__ In-Reply-To: <1464790808.77.0.698310162067.issue27177@psf.upfronthosting.co.za> Message-ID: <1464876055.04.0.131292954338.issue27177@psf.upfronthosting.co.za> Matthew Barnett added the comment: It would be a bug if it was supported but gave the wrong result. It has never been supported (the re module predates PEP 357), so it's a new feature. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 10:40:53 2016 From: report at bugs.python.org (Klamann) Date: Thu, 02 Jun 2016 14:40:53 +0000 Subject: [issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more In-Reply-To: <1464270042.87.0.0233765451432.issue27130@psf.upfronthosting.co.za> Message-ID: <1464878453.71.0.1005132891.issue27130@psf.upfronthosting.co.za> Klamann added the comment: > You should be able to use a compression (or decompression) object as a workaround. OK, let's see >>> import zlib >>> zc = zlib.compressobj() >>> c1 = zc.compress(b'a' * 2**31) >>> c2 = zc.compress(b'a' * 2**31) >>> c3 = zc.flush() >>> c = c1 + c2 + c3 >>> zd = zlib.decompressobj() >>> d1 = zd.decompress(c) Segmentation fault (core dumped) Seriously? What is wrong with this library? I've tested this using Python 3.5.0 on linux and Python 3.5.1 on Windows. At least with Python 2.7.6 it seems to work as expected... So, splitting the Input in chunks of less than 2^32 byte (less than 2^31 for Python 2.x) seems to work (except for this segfault in Python 3), but it's still annoying that you have to split and concatenate data each time and remember to call flush() or you lose data... imho, it would be best to fix the underlying issue. There is no reason why we should keep the 32 bit limitation. > Alternatively (or in the mean time), I guess we could document the limitation. +1 ---------- Added file: http://bugs.python.org/file43099/_usr_bin_python3.5.1000.crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 11:31:08 2016 From: report at bugs.python.org (=?utf-8?b?RMSBdmlz?=) Date: Thu, 02 Jun 2016 15:31:08 +0000 Subject: [issue27179] subprocess uses wrong encoding on Windows In-Reply-To: <1464828766.51.0.809606583575.issue27179@psf.upfronthosting.co.za> Message-ID: <1464881468.24.0.683604176804.issue27179@psf.upfronthosting.co.za> Changes by D?vis : Removed file: http://bugs.python.org/file43094/subprocess_fix_encoding.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 11:38:44 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 02 Jun 2016 15:38:44 +0000 Subject: [issue27180] Doc/pathlib: Please describe the behaviour of Path().rename() is depends on the platform (same as os.rename()) In-Reply-To: <1464866299.22.0.549959469595.issue27180@psf.upfronthosting.co.za> Message-ID: <1464881924.75.0.347979598406.issue27180@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- keywords: +easy stage: -> needs patch versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 12:01:09 2016 From: report at bugs.python.org (Zahari Dim) Date: Thu, 02 Jun 2016 16:01:09 +0000 Subject: [issue24500] provide context manager to redirect C output In-Reply-To: <1462658671.17.0.304700333649.issue24500@psf.upfronthosting.co.za> Message-ID: Zahari Dim added the comment: Considering Python is used often to interact with lower level languages, it seems interesting to have the ability to control the "real" standard output and error that those languages use. Note that redirecting to /dev/null is only one possible application of this feature. Others would be for example linking the stout to the logging module. Specifically regarding redirecting to /dev/null, in my experience this would be fairly useful In scientific software where low level code tends to be used on scientific merits rather than on how much control it has over verbosity. On Sun, May 8, 2016 at 12:04 AM, Martin Panter wrote: > > Martin Panter added the comment: > > Is it really common to have a C wrapper with undesirable output? I suspect there is not much demand for this feature. Maybe this would be better outside of Python?s standard library. > > ---------- > nosy: +martin.panter > status: open -> languishing > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 12:51:11 2016 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 02 Jun 2016 16:51:11 +0000 Subject: [issue23116] Python Tutorial 4.7.1: Improve ask_ok() to cover more input values In-Reply-To: <1419622934.77.0.489991713093.issue23116@psf.upfronthosting.co.za> Message-ID: <1464886271.4.0.128202283518.issue23116@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I think the patch is okay except for the use of "-=" instead of the more verbose version. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 13:05:51 2016 From: report at bugs.python.org (Nathan Harold) Date: Thu, 02 Jun 2016 17:05:51 +0000 Subject: [issue22558] Missing doc links to source code for Python-coded modules. In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za> Message-ID: <1464887151.38.0.694896564379.issue22558@psf.upfronthosting.co.za> Changes by Nathan Harold : ---------- nosy: +nharold _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 13:06:41 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Thu, 02 Jun 2016 17:06:41 +0000 Subject: [issue13548] Invalid 'line' tracer event on pass within else clause In-Reply-To: <1323275290.33.0.837630531134.issue13548@psf.upfronthosting.co.za> Message-ID: <1464887201.88.0.64983255054.issue13548@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: The reason for this behavior is that the trace function is called whenever execution in the bytecode jumps to a new source line. See ceval.c line 4440 or so: /* If the last instruction falls at the start of a line or if it represents a jump backwards, update the frame's line number and call the trace function. */ Running dis.dis on x in the example file shows that the bytecode for returning None is assigned to the "pass" line. I think the bug here is really with the line number assignment in the bytecode, not with the tracing, but I don't see an obvious way to fix it. ---------- nosy: +Jelle Zijlstra _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 13:08:06 2016 From: report at bugs.python.org (=?utf-8?b?RMSBdmlz?=) Date: Thu, 02 Jun 2016 17:08:06 +0000 Subject: [issue27179] subprocess uses wrong encoding on Windows In-Reply-To: <1464828766.51.0.809606583575.issue27179@psf.upfronthosting.co.za> Message-ID: <1464887286.86.0.463928107843.issue27179@psf.upfronthosting.co.za> D?vis added the comment: There is right encoding, it's encoding that's actually used. Here we're inside subprocess.Popen which does the actual winapi.CreateProcess call and thus we can check for any creationflags and adjust encoding logic accordingly. I would say almost all Windows console programs does use console's encoding for input/output because otherwise user wouldn't be able to read it. And programs which use different encoding it would be caller's responsibly to set used encoding because only it could know which encoding to use for that program. So I think basically Popen should accept encoding parameter which would be then passed to TextIOWrapper. Preferably way to set different encoding for stdin/out/err and then if there's no encoding specified, we use our logic to determine default encoding which would be by using _Py_device_encoding(fd) and this would be right for almost all if not all cases. And if some program changes console's encoding after we got consoles encoding, we could get encoding again after program's execution and then use this new set console's encoding. Anyway while looking more into this I found why we get wrong encoding. looking at subprocess.check_output can see return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, **kwargs).stdout that stdout is set to PIPE and then in subprocess.__init__ if c2pread != -1: self.stdout = io.open(c2pread, 'rb', bufsize) if universal_newlines: self.stdout = io.TextIOWrapper(self.stdout) there c2pread will be fd for pipe (3) when looking inside _io_TextIOWrapper___init___impl fileno = _PyObject_CallMethodId(buffer, &PyId_fileno, NULL); [...] int fd = _PyLong_AsInt(fileno); [...] self->encoding = _Py_device_encoding(fd); [...] we'll set encoding with _Py_device_encoding(3); but there if (fd == 0) cp = GetConsoleCP(); else if (fd == 1 || fd == 2) cp = GetConsoleOutputCP(); else cp = 0; so encoding would be correct for stdin/stdout/stderr but not for pipe and that's why this issue. I see 2 ways to fix this and I've added patches for both options. ---------- Added file: http://bugs.python.org/file43100/subprocess_fix_encoding_v2_a.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 13:08:25 2016 From: report at bugs.python.org (=?utf-8?b?RMSBdmlz?=) Date: Thu, 02 Jun 2016 17:08:25 +0000 Subject: [issue27179] subprocess uses wrong encoding on Windows In-Reply-To: <1464828766.51.0.809606583575.issue27179@psf.upfronthosting.co.za> Message-ID: <1464887305.41.0.519267233576.issue27179@psf.upfronthosting.co.za> Changes by D?vis : Added file: http://bugs.python.org/file43101/subprocess_fix_encoding_v2_b.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 13:13:37 2016 From: report at bugs.python.org (Ethan Furman) Date: Thu, 02 Jun 2016 17:13:37 +0000 Subject: [issue22570] Better stdlib support for Path objects using .path attribute In-Reply-To: <1412609631.43.0.978086278536.issue22570@psf.upfronthosting.co.za> Message-ID: <1464887617.01.0.146059978186.issue22570@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman title: Better stdlib support for Path objects -> Better stdlib support for Path objects using .path attribute _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 13:14:33 2016 From: report at bugs.python.org (Ethan Furman) Date: Thu, 02 Jun 2016 17:14:33 +0000 Subject: [issue26027] Support Path objects in the posix module In-Reply-To: <1452114329.99.0.617690911804.issue26027@psf.upfronthosting.co.za> Message-ID: <1464887673.22.0.431759248037.issue26027@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 13:16:29 2016 From: report at bugs.python.org (Ethan Furman) Date: Thu, 02 Jun 2016 17:16:29 +0000 Subject: [issue27182] PEP 519 support in the stdlib Message-ID: <1464887789.1.0.970652730446.issue27182@psf.upfronthosting.co.za> New submission from Ethan Furman: Meta issue to track adding PEP 519 support in the various stdlib modules. ---------- messages: 266891 nosy: brett.cannon, ethan.furman, serhiy.storchaka priority: normal severity: normal status: open title: PEP 519 support in the stdlib _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 13:18:33 2016 From: report at bugs.python.org (Ethan Furman) Date: Thu, 02 Jun 2016 17:18:33 +0000 Subject: [issue27182] PEP 519 support in the stdlib In-Reply-To: <1464887789.1.0.970652730446.issue27182@psf.upfronthosting.co.za> Message-ID: <1464887913.67.0.0224641351185.issue27182@psf.upfronthosting.co.za> Ethan Furman added the comment: posix module: issue26027 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 13:21:29 2016 From: report at bugs.python.org (Ethan Furman) Date: Thu, 02 Jun 2016 17:21:29 +0000 Subject: [issue27182] PEP 519 support in the stdlib In-Reply-To: <1464887789.1.0.970652730446.issue27182@psf.upfronthosting.co.za> Message-ID: <1464888089.83.0.854170132203.issue27182@psf.upfronthosting.co.za> Ethan Furman added the comment: importlib: issue26667 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 13:21:48 2016 From: report at bugs.python.org (Petr Viktorin) Date: Thu, 02 Jun 2016 17:21:48 +0000 Subject: [issue27183] Clarify that Py_VISIT(NULL) does nothing Message-ID: <1464888108.12.0.251087616908.issue27183@psf.upfronthosting.co.za> New submission from Petr Viktorin: The Py_VISIT macro (in Include/objimpl.h) does nothing if passed NULL (and did this since its introduction). It would be nice to have this formally documented. ---------- assignee: docs at python components: Documentation files: 0001-Doc-c-api-Clarify-that-Py_VISIT-NULL-does-nothing.patch keywords: patch messages: 266894 nosy: docs at python, encukou, eric.araujo, ezio.melotti, georg.brandl priority: normal severity: normal status: open title: Clarify that Py_VISIT(NULL) does nothing type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43102/0001-Doc-c-api-Clarify-that-Py_VISIT-NULL-does-nothing.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 13:23:44 2016 From: report at bugs.python.org (Kushal Das) Date: Thu, 02 Jun 2016 17:23:44 +0000 Subject: [issue21271] reset_mock needs parameters to also reset return_value and side_effect In-Reply-To: <1397681504.34.0.196484984277.issue21271@psf.upfronthosting.co.za> Message-ID: <1464888224.53.0.116221008933.issue21271@psf.upfronthosting.co.za> Kushal Das added the comment: Fixed in https://hg.python.org/cpython/rev/b110dd3d6cea ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 13:26:50 2016 From: report at bugs.python.org (Emanuel Barry) Date: Thu, 02 Jun 2016 17:26:50 +0000 Subject: [issue21271] reset_mock needs parameters to also reset return_value and side_effect In-Reply-To: <1397681504.34.0.196484984277.issue21271@psf.upfronthosting.co.za> Message-ID: <1464888410.56.0.898593260256.issue21271@psf.upfronthosting.co.za> Changes by Emanuel Barry : ---------- resolution: -> fixed stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 13:29:18 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Jun 2016 17:29:18 +0000 Subject: [issue21271] reset_mock needs parameters to also reset return_value and side_effect In-Reply-To: <1397681504.34.0.196484984277.issue21271@psf.upfronthosting.co.za> Message-ID: <20160602172135.4839.4569.03C4F7C5@psf.io> Roundup Robot added the comment: New changeset b110dd3d6cea by Kushal Das in branch 'default': Issue #21271: Adds new keyword only parameters in reset_mock call https://hg.python.org/cpython/rev/b110dd3d6cea ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 13:30:07 2016 From: report at bugs.python.org (Ethan Furman) Date: Thu, 02 Jun 2016 17:30:07 +0000 Subject: [issue27184] Support path objects in the nt module Message-ID: <1464888607.0.0.619919678866.issue27184@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: brett.cannon, ethan.furman, serhiy.storchaka priority: normal severity: normal stage: test needed status: open title: Support path objects in the nt module type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 13:30:33 2016 From: report at bugs.python.org (Ethan Furman) Date: Thu, 02 Jun 2016 17:30:33 +0000 Subject: [issue27182] PEP 519 support in the stdlib In-Reply-To: <1464887789.1.0.970652730446.issue27182@psf.upfronthosting.co.za> Message-ID: <1464888633.83.0.720738170033.issue27182@psf.upfronthosting.co.za> Ethan Furman added the comment: nt module: issue27184 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 13:38:54 2016 From: report at bugs.python.org (Ethan Furman) Date: Thu, 02 Jun 2016 17:38:54 +0000 Subject: [issue27182] PEP 519 support in the stdlib In-Reply-To: <1464887789.1.0.970652730446.issue27182@psf.upfronthosting.co.za> Message-ID: <1464889134.34.0.878762786036.issue27182@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- dependencies: +Support Path objects in the posix module, Support path objects in the nt module, Update importlib to accept pathlib.Path objects type: -> behavior versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 13:39:35 2016 From: report at bugs.python.org (Ethan Furman) Date: Thu, 02 Jun 2016 17:39:35 +0000 Subject: [issue27182] PEP 519 support in the stdlib In-Reply-To: <1464887789.1.0.970652730446.issue27182@psf.upfronthosting.co.za> Message-ID: <1464889175.48.0.128883284369.issue27182@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 13:40:21 2016 From: report at bugs.python.org (Ethan Furman) Date: Thu, 02 Jun 2016 17:40:21 +0000 Subject: [issue27184] Support path objects in the nt module Message-ID: <1464889221.05.0.823540666549.issue27184@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 13:48:33 2016 From: report at bugs.python.org (Kushal Das) Date: Thu, 02 Jun 2016 17:48:33 +0000 Subject: [issue19234] socket.fileno() documentation In-Reply-To: <52597A2F.60807@python.org> Message-ID: <1464889713.78.0.715870060362.issue19234@psf.upfronthosting.co.za> Kushal Das added the comment: Adds more lines to explain the behavior of socket.fileno() in case of error. ---------- keywords: +patch nosy: +kushal.das Added file: http://bugs.python.org/file43103/issue19234.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 13:54:58 2016 From: report at bugs.python.org (Erin Braswell) Date: Thu, 02 Jun 2016 17:54:58 +0000 Subject: [issue27185] Increase Test Coverage for the String Module Message-ID: <1464890098.67.0.933644728591.issue27185@psf.upfronthosting.co.za> Changes by Erin Braswell : ---------- components: Tests files: stringtests.patch keywords: patch nosy: erinspace priority: normal severity: normal status: open title: Increase Test Coverage for the String Module type: enhancement Added file: http://bugs.python.org/file43104/stringtests.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 14:19:23 2016 From: report at bugs.python.org (Brett Cannon) Date: Thu, 02 Jun 2016 18:19:23 +0000 Subject: [issue26359] CPython build options for out-of-the box performance In-Reply-To: <1455445693.01.0.984013993837.issue26359@psf.upfronthosting.co.za> Message-ID: <1464891563.68.0.496123402016.issue26359@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 14:21:35 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Jun 2016 18:21:35 +0000 Subject: [issue23116] Python Tutorial 4.7.1: Improve ask_ok() to cover more input values In-Reply-To: <1419622934.77.0.489991713093.issue23116@psf.upfronthosting.co.za> Message-ID: <20160602182123.10466.67512.0CE51CEE@psf.io> Roundup Robot added the comment: New changeset ef800c30e28c by Berker Peksag in branch '3.5': Issue #23116: Improve ask_ok() example in the Python tutorial https://hg.python.org/cpython/rev/ef800c30e28c New changeset 174eae50b664 by Berker Peksag in branch 'default': Issue #23116: Merge from 3.5 https://hg.python.org/cpython/rev/174eae50b664 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 14:22:21 2016 From: report at bugs.python.org (Ethan Furman) Date: Thu, 02 Jun 2016 18:22:21 +0000 Subject: [issue27186] add os.fspath() Message-ID: <1464891741.78.0.364985745174.issue27186@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: brett.cannon, ethan.furman, serhiy.storchaka priority: normal severity: normal stage: test needed status: open title: add os.fspath() type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 14:22:46 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 02 Jun 2016 18:22:46 +0000 Subject: [issue23116] Python Tutorial 4.7.1: Improve ask_ok() to cover more input values In-Reply-To: <1419622934.77.0.489991713093.issue23116@psf.upfronthosting.co.za> Message-ID: <1464891766.92.0.652160411633.issue23116@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the review. I removed the "-=" part from the patch. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 14:23:01 2016 From: report at bugs.python.org (Ethan Furman) Date: Thu, 02 Jun 2016 18:23:01 +0000 Subject: [issue27182] PEP 519 support in the stdlib In-Reply-To: <1464887789.1.0.970652730446.issue27182@psf.upfronthosting.co.za> Message-ID: <1464891781.84.0.950638367648.issue27182@psf.upfronthosting.co.za> Ethan Furman added the comment: os.fspath(): issue27186 ---------- dependencies: +add os.fspath() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 14:28:25 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 02 Jun 2016 18:28:25 +0000 Subject: [issue27185] Increase Test Coverage for the String Module Message-ID: <1464892105.41.0.770914187896.issue27185@psf.upfronthosting.co.za> New submission from Gregory P. Smith: Can you sign the Python contributor form - https://www.python.org/psf/contrib/contrib-form/? (If you already have, just say so.) ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 14:28:48 2016 From: report at bugs.python.org (Brett Cannon) Date: Thu, 02 Jun 2016 18:28:48 +0000 Subject: [issue26526] In parsermodule.c, replace over 2KLOC of hand-crafted validation code, with a DFA In-Reply-To: <1457600551.84.0.318395917649.issue26526@psf.upfronthosting.co.za> Message-ID: <1464892128.67.0.41779583243.issue26526@psf.upfronthosting.co.za> Brett Cannon added the comment: Are you up for trying to commit this while at the sprints, Fred? If not then assign it back to me and I can eventually commit it (busy w/ a ton of stuff so I can't promise when I will get to it). ---------- assignee: -> fdrake stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 14:32:59 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Jun 2016 18:32:59 +0000 Subject: [issue26526] In parsermodule.c, replace over 2KLOC of hand-crafted validation code, with a DFA In-Reply-To: <1457600551.84.0.318395917649.issue26526@psf.upfronthosting.co.za> Message-ID: <20160602183247.977.6310.C474250E@psf.io> Roundup Robot added the comment: New changeset 4a9159ea2536 by Benjamin Peterson in branch 'default': replace custom validation logic in the parse module with a simple DFA validator (closes #26526) https://hg.python.org/cpython/rev/4a9159ea2536 ---------- nosy: +python-dev resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 14:33:41 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Jun 2016 18:33:41 +0000 Subject: [issue27185] Increase Test Coverage for the String Module In-Reply-To: <1464892105.41.0.770914187896.issue27185@psf.upfronthosting.co.za> Message-ID: <1464892421.7.0.653462172973.issue27185@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: string.Template is tested in Lib/test/test_pep292.py. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 14:36:06 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 02 Jun 2016 18:36:06 +0000 Subject: [issue27185] Increase Test Coverage for the String Module In-Reply-To: <1464892105.41.0.770914187896.issue27185@psf.upfronthosting.co.za> Message-ID: <1464892566.27.0.566897518303.issue27185@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Thanks Serhiy. Given that, I suggest checking if the new tests this adds are already covered in test_pep292.py or not to decide if we should move forward with this patch or not. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 14:36:35 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Jun 2016 18:36:35 +0000 Subject: [issue27183] Clarify that Py_VISIT(NULL) does nothing In-Reply-To: <1464888108.12.0.251087616908.issue27183@psf.upfronthosting.co.za> Message-ID: <20160602183622.70607.53975.1B2227EA@psf.io> Roundup Robot added the comment: New changeset 7c67cb3b54b4 by Benjamin Peterson in branch '3.5': note that Py_VISIT handles NULL (closes #27183) https://hg.python.org/cpython/rev/7c67cb3b54b4 New changeset 42356e44af23 by Benjamin Peterson in branch '2.7': note that Py_VISIT handles NULL (closes #27183) https://hg.python.org/cpython/rev/42356e44af23 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 14:36:55 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Jun 2016 18:36:55 +0000 Subject: [issue27182] PEP 519 support in the stdlib In-Reply-To: <1464887789.1.0.970652730446.issue27182@psf.upfronthosting.co.za> Message-ID: <1464892615.14.0.518657054741.issue27182@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Isn't the nt module just an alias of the posix module? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 14:43:32 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Thu, 02 Jun 2016 18:43:32 +0000 Subject: [issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects. In-Reply-To: <1384516983.26.0.0584971052865.issue19611@psf.upfronthosting.co.za> Message-ID: <1464893012.2.0.283607184635.issue19611@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: This doesn't work in Python 3.6 (current dev version) either. Using Ned's example, I get (snipping some of the ipython stack trace): /home/jelle/cpython-dev/cpython/Lib/inspect.py in __init__(self, name, kind, default, annotation) 2399 if not name.isidentifier(): -> 2400 raise ValueError('{!r} is not a valid parameter name'.format(name)) 2401 ValueError: '.0' is not a valid parameter name print(inspect.Signature.from_callable(setcomp_func).bind(iter(range(5)))) fails with the same error. However, both work if I take out the isidentifier check. In Python 2.7, the bug is actually in inspect.getargs: In [7]: inspect.getargs(setcomp_func.func_code) Out[7]: Arguments(args=[['z']], varargs=None, keywords=None) which assumes that any ".0" argument is a tuple. I'm not sure the bug in 2.7 is worth fixing, since it will require fragile bytecode manipulation to distinguish tuple arguments from set comprehensions, and you can get to this case only by manually creating function objects. I think the Python 3 level bug is worth fixing though, since it's an easy fix (just make the .isidentifier call accept names of the form .0). I'm attaching a patch against master with tests. I have signed the contributor agreement. ---------- keywords: +patch nosy: +Jelle Zijlstra Added file: http://bugs.python.org/file43105/issue19611.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 14:47:21 2016 From: report at bugs.python.org (Christian Heimes) Date: Thu, 02 Jun 2016 18:47:21 +0000 Subject: [issue26798] add BLAKE2 to hashlib In-Reply-To: <1461004812.44.0.872226457841.issue26798@psf.upfronthosting.co.za> Message-ID: <1464893241.19.0.819300064344.issue26798@psf.upfronthosting.co.za> Christian Heimes added the comment: New patch: - I moved the test vectors out of the repos. They are currently hosted on github. I'll move them to pythontest infra later. - I dropped special case for systems w/o uint64. Python 3.6+ requires 64 bit int types to compile. ---------- Added file: http://bugs.python.org/file43106/BLAKE2-hash-algorithm-for-CPython-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 14:50:16 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 02 Jun 2016 18:50:16 +0000 Subject: [issue27164] zlib can't decompress DEFLATE using shared dictionary In-Reply-To: <1464687663.75.0.126366287594.issue27164@psf.upfronthosting.co.za> Message-ID: <1464893416.06.0.940933362563.issue27164@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- assignee: gregory.p.smith -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 14:51:15 2016 From: report at bugs.python.org (Christian Heimes) Date: Thu, 02 Jun 2016 18:51:15 +0000 Subject: [issue16113] Add SHA-3 and SHAKE (Keccak) support In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za> Message-ID: <1464893475.54.0.0323875403919.issue16113@psf.upfronthosting.co.za> Christian Heimes added the comment: New patch: - I moved the test vectors out of the repos. They are currently hosted on github. I'll move them to pythontest infra later. ---------- Added file: http://bugs.python.org/file43107/SHA3-and-SHAKE-support-for-Python-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 14:53:40 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 02 Jun 2016 18:53:40 +0000 Subject: [issue21196] Name mangling example in Python tutorial In-Reply-To: <1397133080.37.0.870141660622.issue21196@psf.upfronthosting.co.za> Message-ID: <1464893620.51.0.853337121316.issue21196@psf.upfronthosting.co.za> Berker Peksag added the comment: I think the text is fine, but the example is not needed. I've updated Chandan's patch to remove the example and tweak the text a bit. ---------- nosy: +berker.peksag versions: +Python 3.6 -Python 3.4 Added file: http://bugs.python.org/file43108/issue21196.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 14:54:05 2016 From: report at bugs.python.org (Emily Morehouse) Date: Thu, 02 Jun 2016 18:54:05 +0000 Subject: [issue13784] Documentation of xml.sax.xmlreader: Locator.getLineNumber() and Locator.getColumnNumber() In-Reply-To: <1326542534.95.0.205057982858.issue13784@psf.upfronthosting.co.za> Message-ID: <1464893645.68.0.444049844146.issue13784@psf.upfronthosting.co.za> Emily Morehouse added the comment: The reported behavior has been verified -- the documented behavior is indeed incorrect for both Locator.getColumnNumber() and Locator.getLineNumber(). The beginning line and column numbers are returned, not the end. This has been tested and verified for Python 2.7, Python 3.5.1 and a local build of the current default branch. ---------- keywords: +patch nosy: +emilyemorehouse versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.6 Added file: http://bugs.python.org/file43109/13784.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 14:59:04 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Thu, 02 Jun 2016 18:59:04 +0000 Subject: [issue25160] Stop using deprecated imp module; imp should now emit a real DeprecationWarning In-Reply-To: <1442559979.71.0.954965412351.issue25160@psf.upfronthosting.co.za> Message-ID: <1464893944.68.0.057180219801.issue25160@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Current status: - 2to3 replaces reload() calls with imp.reload - Lib/modulefinder.py imports imp and uses it 10 or so times, mostly for constants - Lib/xml/sax/__init__.py uses imp on Jython only - Python/makeopcodetargets.py falls back to imp if importlib is not available. - Tools/importbench/importbench.py uses imp a number of times. I'll work on replacing some of these. ---------- nosy: +Jelle Zijlstra _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 14:59:38 2016 From: report at bugs.python.org (Erin Braswell) Date: Thu, 02 Jun 2016 18:59:38 +0000 Subject: [issue27185] Increase Test Coverage for the String Module In-Reply-To: <1464892105.41.0.770914187896.issue27185@psf.upfronthosting.co.za> Message-ID: <1464893978.92.0.876249271578.issue27185@psf.upfronthosting.co.za> Erin Braswell added the comment: Just checked! Apologies for this totally unnecessary patch, didn't know to look elsewhere but now I absolutely do -- looks like all the tests are there and more. Thank you! ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 15:02:07 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 02 Jun 2016 19:02:07 +0000 Subject: [issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects. In-Reply-To: <1384516983.26.0.0584971052865.issue19611@psf.upfronthosting.co.za> Message-ID: <1464894127.82.0.0995415240128.issue19611@psf.upfronthosting.co.za> R. David Murray added the comment: The patch looks reasonable to me. I've added Yuri to nosy since he's responsible for the signature code in inspect, and he might have an opinion on the appriateness of the fix. I think this special case needs to be documented, since currently the name is documented as needing to be a valid python identifier. Sounds like we don't have a good answer to Ned's question about a 2.7 workaround. On the other hand, "fragile byte code inspection" is not really fragile, since the 2.7 bytecode will never change. The real question is if someone cares enough to do the work, since as you say (and Ned admits) the benefit is small. ---------- nosy: +r.david.murray, yselivanov versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 15:02:08 2016 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 02 Jun 2016 19:02:08 +0000 Subject: [issue27185] Increase Test Coverage for the String Module In-Reply-To: <1464892105.41.0.770914187896.issue27185@psf.upfronthosting.co.za> Message-ID: <1464894128.19.0.0338145867588.issue27185@psf.upfronthosting.co.za> Benjamin Peterson added the comment: It probably makes sense to move test_pep292.py tests into test_string.py. Test files named after peps are not very helpful. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 15:04:47 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Jun 2016 19:04:47 +0000 Subject: [issue22374] Replace contextmanager example and improve explanation In-Reply-To: <1410296292.35.0.34327651623.issue22374@psf.upfronthosting.co.za> Message-ID: <1464894287.44.0.500979624604.issue22374@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: swap_attr() looks too general. I think something more concrete would be better. But the documentation already contain other examples for contextmanager. closing() is good example, and redirect_stdout() would be good example. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 15:05:07 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Thu, 02 Jun 2016 19:05:07 +0000 Subject: [issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects. In-Reply-To: <1384516983.26.0.0584971052865.issue19611@psf.upfronthosting.co.za> Message-ID: <1464894307.94.0.801463634578.issue19611@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Thanks for the comment! It is fragile in the sense that I think there is a good chance that a fix (which is going to rely on details of generated bytecode) will have bugs and break someone's working 2.7 code. The patch's tests have a bug, which I'll fix together with a documentation patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 15:05:25 2016 From: report at bugs.python.org (Tommy Beadle) Date: Thu, 02 Jun 2016 19:05:25 +0000 Subject: [issue20973] Implement proper comparison operations for in _TotalOrderingMixin in ipaddress module. In-Reply-To: <1395176069.22.0.2337521372.issue20973@psf.upfronthosting.co.za> Message-ID: <1464894325.32.0.260759422865.issue20973@psf.upfronthosting.co.za> Changes by Tommy Beadle : ---------- keywords: +patch Added file: http://bugs.python.org/file43110/0001-Issue-20973-Add-total-ordering-unit-tests-for-ipaddr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 15:05:50 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Jun 2016 19:05:50 +0000 Subject: [issue27185] Increase Test Coverage for the String Module In-Reply-To: <1464892105.41.0.770914187896.issue27185@psf.upfronthosting.co.za> Message-ID: <1464894350.24.0.30326149361.issue27185@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Or at least add a reference in test_string.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 15:05:51 2016 From: report at bugs.python.org (Erin Braswell) Date: Thu, 02 Jun 2016 19:05:51 +0000 Subject: [issue27185] Increase Test Coverage for the String Module In-Reply-To: <1464892105.41.0.770914187896.issue27185@psf.upfronthosting.co.za> Message-ID: <1464894351.35.0.745565436085.issue27185@psf.upfronthosting.co.za> Erin Braswell added the comment: Oh! I can do that, and resubmit the patch! Good suggestion. Thank you again. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 15:08:10 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Jun 2016 19:08:10 +0000 Subject: [issue16192] ctypes - documentation example In-Reply-To: <1349923369.86.0.516068156992.issue16192@psf.upfronthosting.co.za> Message-ID: <20160602190759.1089.49305.D2AE32C2@psf.io> Roundup Robot added the comment: New changeset 1775abf47061 by Berker Peksag in branch '3.5': Issue #16192: Clarify when c_int is an alias to c_long in ctypes documentation https://hg.python.org/cpython/rev/1775abf47061 New changeset 9954e29b8678 by Berker Peksag in branch 'default': Issue #16192: Merge from 3.5 https://hg.python.org/cpython/rev/9954e29b8678 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 15:09:22 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 02 Jun 2016 19:09:22 +0000 Subject: [issue16192] ctypes - documentation example In-Reply-To: <1349923369.86.0.516068156992.issue16192@psf.upfronthosting.co.za> Message-ID: <1464894562.78.0.729633602051.issue16192@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 15:16:52 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Thu, 02 Jun 2016 19:16:52 +0000 Subject: [issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects. In-Reply-To: <1384516983.26.0.0584971052865.issue19611@psf.upfronthosting.co.za> Message-ID: <1464895012.85.0.918990303371.issue19611@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Fixed patch, added documentation ---------- Added file: http://bugs.python.org/file43111/issue19611.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 15:19:33 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 02 Jun 2016 19:19:33 +0000 Subject: [issue13784] Documentation of xml.sax.xmlreader: Locator.getLineNumber() and Locator.getColumnNumber() In-Reply-To: <1326542534.95.0.205057982858.issue13784@psf.upfronthosting.co.za> Message-ID: <1464895173.73.0.987565893811.issue13784@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks Emily. For some reason the auto update of the tracker doesn't seem to have worked. Maybe it is just delayed, but in case, the commit hashes are 2.7 97b76fe183f4, 3.5 9d6a9e2ae18b, and 3.6 cce04851d2e2. ---------- nosy: +r.david.murray resolution: -> fixed stage: -> resolved status: open -> closed versions: -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 15:20:18 2016 From: report at bugs.python.org (Emily Morehouse) Date: Thu, 02 Jun 2016 19:20:18 +0000 Subject: [issue26829] update docs: when creating classes a new dict is created for the final class object In-Reply-To: <1461333834.83.0.0321229546915.issue26829@psf.upfronthosting.co.za> Message-ID: <1464895218.65.0.163481766099.issue26829@psf.upfronthosting.co.za> Emily Morehouse added the comment: Super straight-forward -- this simply adds to the docs on creating the class object that the values used in creation are copied to the final object (including the namespace). ---------- keywords: +patch nosy: +emilyemorehouse Added file: http://bugs.python.org/file43112/26829.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 15:21:08 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Thu, 02 Jun 2016 19:21:08 +0000 Subject: [issue25160] Stop using deprecated imp module; imp should now emit a real DeprecationWarning In-Reply-To: <1442559979.71.0.954965412351.issue25160@psf.upfronthosting.co.za> Message-ID: <1464895268.71.0.0677593343496.issue25160@psf.upfronthosting.co.za> Changes by Jelle Zijlstra : ---------- keywords: +patch Added file: http://bugs.python.org/file43113/issue25160-2to3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 15:21:18 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Jun 2016 19:21:18 +0000 Subject: [issue24291] Many servers (wsgiref, http.server, etc) can truncate large output blobs In-Reply-To: <1432671481.51.0.762064908488.issue24291@psf.upfronthosting.co.za> Message-ID: <1464895278.03.0.516887927231.issue24291@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It looks to me that there is two opposite ways to resolve this issue. 1. Document the requirement for write() and raise an exception if write() returned not the size of full data. But I think it would be more user-friendly first emit a warning and continue calling write() until full data is written. 2. Don't document any requirement, but just silently handle partial writing. wsgiref-only.patch contains parts from both ways. It documents new requirement, but doesn't deprecate partial writing. What way is chosen? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 15:22:36 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Jun 2016 19:22:36 +0000 Subject: [issue13784] Documentation of xml.sax.xmlreader: Locator.getLineNumber() and Locator.getColumnNumber() In-Reply-To: <1326542534.95.0.205057982858.issue13784@psf.upfronthosting.co.za> Message-ID: <20160602191539.4968.98542.24BA9CCA@psf.io> Roundup Robot added the comment: New changeset 97b76fe183f4 by R David Murray in branch '2.7': #13784: fix xml.sax.reader getColumn/LineNumber docs. https://hg.python.org/cpython/rev/97b76fe183f4 New changeset 9d6a9e2ae18b by R David Murray in branch '3.5': #13784: fix xml.sax.reader getColumn/LineNumber docs. https://hg.python.org/cpython/rev/9d6a9e2ae18b New changeset cce04851d2e2 by R David Murray in branch 'default': Merge: #13784: fix xml.sax.reader getColumn/LineNumber docs. https://hg.python.org/cpython/rev/cce04851d2e2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 15:23:39 2016 From: report at bugs.python.org (Zachary Ware) Date: Thu, 02 Jun 2016 19:23:39 +0000 Subject: [issue26876] Extend MSVCCompiler class to respect environment variables In-Reply-To: <1461866719.82.0.2605655084.issue26876@psf.upfronthosting.co.za> Message-ID: <1464895419.43.0.774887804172.issue26876@psf.upfronthosting.co.za> Zachary Ware added the comment: The patch looks fine to me, but frankly I'm a bit scared to commit anything to distutils :). It would be nice to have tests for this. I'm also not sure if we can backport this to 2.7 and 3.5: this is pretty clearly a new feature, but dips its toes into the grey area of "supporting new platforms". Anyone else have any thoughts? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 15:25:28 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Thu, 02 Jun 2016 19:25:28 +0000 Subject: [issue25160] Stop using deprecated imp module; imp should now emit a real DeprecationWarning In-Reply-To: <1442559979.71.0.954965412351.issue25160@psf.upfronthosting.co.za> Message-ID: <1464895528.02.0.916304424763.issue25160@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: One more: - lib/pkgutil.py in _import_imp (amusingly) uses importlib with silenced warnings to import imp. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 15:25:40 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 02 Jun 2016 19:25:40 +0000 Subject: [issue27185] Clarify Test Coverage for the String Module (test_pep292 is not easily discoverable) In-Reply-To: <1464892105.41.0.770914187896.issue27185@psf.upfronthosting.co.za> Message-ID: <1464895540.3.0.649872255597.issue27185@psf.upfronthosting.co.za> R. David Murray added the comment: Reopening and retitling. ---------- nosy: +r.david.murray resolution: duplicate -> status: closed -> open title: Increase Test Coverage for the String Module -> Clarify Test Coverage for the String Module (test_pep292 is not easily discoverable) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 15:28:31 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 02 Jun 2016 19:28:31 +0000 Subject: [issue25160] Stop using deprecated imp module; imp should now emit a real DeprecationWarning In-Reply-To: <1442559979.71.0.954965412351.issue25160@psf.upfronthosting.co.za> Message-ID: <1464895710.99.0.884617680837.issue25160@psf.upfronthosting.co.za> Berker Peksag added the comment: > - 2to3 replaces reload() calls with imp.reload There is an already open issue for this: Issue 21446. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 15:35:47 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 02 Jun 2016 19:35:47 +0000 Subject: [issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects. In-Reply-To: <1384516983.26.0.0584971052865.issue19611@psf.upfronthosting.co.za> Message-ID: <1464896147.32.0.707302026317.issue19611@psf.upfronthosting.co.za> R. David Murray added the comment: I wonder if we should do the mention of .0 as a footnote, since it won't matter to most users. What do you think, Yuri? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 15:42:32 2016 From: report at bugs.python.org (Erin Braswell) Date: Thu, 02 Jun 2016 19:42:32 +0000 Subject: [issue27185] Clarify Test Coverage for the String Module (test_pep292 is not easily discoverable) In-Reply-To: <1464892105.41.0.770914187896.issue27185@psf.upfronthosting.co.za> Message-ID: <1464896552.15.0.55559061005.issue27185@psf.upfronthosting.co.za> Erin Braswell added the comment: Here is an updated patch adding all the tests from test_pep292.py into test_string.py. After this happens test_pep292.py can be removed! ---------- Added file: http://bugs.python.org/file43114/stringtests.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 15:43:16 2016 From: report at bugs.python.org (Tommy Beadle) Date: Thu, 02 Jun 2016 19:43:16 +0000 Subject: [issue24617] os.makedirs()'s [mode] not correct In-Reply-To: <1436721223.66.0.229120395272.issue24617@psf.upfronthosting.co.za> Message-ID: <1464896596.19.0.672555351258.issue24617@psf.upfronthosting.co.za> Changes by Tommy Beadle : ---------- keywords: +patch Added file: http://bugs.python.org/file43115/0001-Issue-24617-Add-comment-for-os.makedirs-about-certai.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 15:49:16 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 02 Jun 2016 19:49:16 +0000 Subject: [issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects. In-Reply-To: <1384516983.26.0.0584971052865.issue19611@psf.upfronthosting.co.za> Message-ID: <1464896956.94.0.206376221026.issue19611@psf.upfronthosting.co.za> Yury Selivanov added the comment: Jelle, regarding your patch: it would probably be a good idea to only accept ".0"-like names for POSITIONAL_ONLY parameters. Since functions with positional-only parameters can only be created in C, that should make inspect.Parameter less error prone. David, maybe this is something that can be fixed using the Arguments Clinic? I'm not sure how to feel about parsing ".0" for parameter names. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 15:50:20 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Jun 2016 19:50:20 +0000 Subject: [issue27185] Clarify Test Coverage for the String Module (test_pep292 is not easily discoverable) In-Reply-To: <1464892105.41.0.770914187896.issue27185@psf.upfronthosting.co.za> Message-ID: <1464897020.91.0.253312202726.issue27185@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is not so easy. After adding all the tests from test_pep292.py into test_string.py and removing test_pep292.py we will lost all the history of test_pep292.py. Merging two files in Mercurial is not easy. I already did this and can do again if it is worth. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 15:50:33 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Jun 2016 19:50:33 +0000 Subject: [issue20973] Implement proper comparison operations for in _TotalOrderingMixin in ipaddress module. In-Reply-To: <1395176069.22.0.2337521372.issue20973@psf.upfronthosting.co.za> Message-ID: <20160602195012.1045.28326.C7D06DD0@psf.io> Roundup Robot added the comment: New changeset ffaefb20dd06 by R David Murray in branch '3.5': #20973: add total ordering tests for ipaddress https://hg.python.org/cpython/rev/ffaefb20dd06 New changeset 503168ec3d4f by R David Murray in branch 'default': Merge: #20973: add total ordering tests for ipaddress https://hg.python.org/cpython/rev/503168ec3d4f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 15:51:28 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 02 Jun 2016 19:51:28 +0000 Subject: [issue20973] Implement proper comparison operations for in _TotalOrderingMixin in ipaddress module. In-Reply-To: <1395176069.22.0.2337521372.issue20973@psf.upfronthosting.co.za> Message-ID: <1464897088.97.0.630195678845.issue20973@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Tommy. ---------- resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 15:52:46 2016 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 02 Jun 2016 19:52:46 +0000 Subject: [issue27185] Clarify Test Coverage for the String Module (test_pep292 is not easily discoverable) In-Reply-To: <1464897020.91.0.253312202726.issue27185@psf.upfronthosting.co.za> Message-ID: <1464897163.1546995.626286505.6B612387@webmail.messagingengine.com> Benjamin Peterson added the comment: I'm not too concerned about that. git can handle it well, which we will have soon. On Thu, Jun 2, 2016, at 12:50, Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > This is not so easy. After adding all the tests from test_pep292.py into > test_string.py and removing test_pep292.py we will lost all the history > of test_pep292.py. Merging two files in Mercurial is not easy. I already > did this and can do again if it is worth. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 16:04:22 2016 From: report at bugs.python.org (Zachary Ware) Date: Thu, 02 Jun 2016 20:04:22 +0000 Subject: [issue19234] socket.fileno() documentation In-Reply-To: <52597A2F.60807@python.org> Message-ID: <1464897862.7.0.840064945368.issue19234@psf.upfronthosting.co.za> Zachary Ware added the comment: I think the additions are redundant; pick one or the other. The first should be sufficient. ---------- nosy: +zach.ware stage: -> patch review versions: +Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 16:10:21 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 02 Jun 2016 20:10:21 +0000 Subject: [issue26829] update docs: when creating classes a new dict is created for the final class object In-Reply-To: <1461333834.83.0.0321229546915.issue26829@psf.upfronthosting.co.za> Message-ID: <1464898221.11.0.044145661089.issue26829@psf.upfronthosting.co.za> R. David Murray added the comment: Your suggested wording isn't correct, I'm afraid. This subject is complex and somewhat obscure...I checked with Ethan to make sure my interpretation was correct. The problem this issue is addressing is the fact that when type.__new__ is called (as in the metaclass example), whatever is passed in as the namespace has its *contents* copied into a new, standard python dict, and the original namespace object is discarded. The metaclass example does this explicitly (by doing dict(namespace), but in fact type.__new__ does it implicitly (which IMO makes that example a bit confusing). Also, that namespace is the only state. The metaclass example obscures that by doing an attribute assignment after calling type.__new__, but that attribute assignment is actually updating the __dict__ of the new object ('result'), which is that new python dict containing the contents of namespace. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 16:37:11 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Jun 2016 20:37:11 +0000 Subject: [issue21776] distutils.upload uses the wrong order of exceptions In-Reply-To: <1402911209.04.0.940354382674.issue21776@psf.upfronthosting.co.za> Message-ID: <20160602203658.5193.80344.C00DDA1B@psf.io> Roundup Robot added the comment: New changeset 17e7d6c4f082 by Berker Peksag in branch '3.5': Issue #21776: distutils.upload now correctly handles HTTPError https://hg.python.org/cpython/rev/17e7d6c4f082 New changeset 421bc6ae9b6f by Berker Peksag in branch 'default': Issue #21776: Merge from 3.5 https://hg.python.org/cpython/rev/421bc6ae9b6f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 16:43:12 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 02 Jun 2016 20:43:12 +0000 Subject: [issue21776] distutils.upload uses the wrong order of exceptions In-Reply-To: <1402911209.04.0.940354382674.issue21776@psf.upfronthosting.co.za> Message-ID: <1464900192.61.0.873660020213.issue21776@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch, Claudiu. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 16:52:46 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 02 Jun 2016 20:52:46 +0000 Subject: [issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects. In-Reply-To: <1384516983.26.0.0584971052865.issue19611@psf.upfronthosting.co.za> Message-ID: <1464900766.94.0.193124798073.issue19611@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, it feels ugly. I'd rather "fix" the source of the problem (the weird positional attribute name). I have no idea if argument clinic would be of any help here, I haven't looked at how these things come to be. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 16:54:55 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 02 Jun 2016 20:54:55 +0000 Subject: [issue27185] Clarify Test Coverage for the String Module (test_pep292 is not easily discoverable) In-Reply-To: <1464892105.41.0.770914187896.issue27185@psf.upfronthosting.co.za> Message-ID: <1464900895.06.0.899722246938.issue27185@psf.upfronthosting.co.za> R. David Murray added the comment: Benjamin: meaning we should wait for git to merge it, or git will automatically handle the history after conversion? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 16:57:48 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 02 Jun 2016 20:57:48 +0000 Subject: [issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects. In-Reply-To: <1384516983.26.0.0584971052865.issue19611@psf.upfronthosting.co.za> Message-ID: <1464901068.73.0.465157859151.issue19611@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Yes, it feels ugly. I'd rather "fix" the source of the problem (the weird positional attribute name). +1. > I have no idea if argument clinic would be of any help here, I haven't looked at how these things come to be. Me neither. Serhiy, what do you think about this? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 17:02:27 2016 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 02 Jun 2016 21:02:27 +0000 Subject: [issue27185] Clarify Test Coverage for the String Module (test_pep292 is not easily discoverable) In-Reply-To: <1464900895.06.0.899722246938.issue27185@psf.upfronthosting.co.za> Message-ID: <1464901345.2077958.626350377.510AF5D4@webmail.messagingengine.com> Benjamin Peterson added the comment: We should be able to commit it now. git blame can usually figure out this stuff post facto. On Thu, Jun 2, 2016, at 13:54, R. David Murray wrote: > > R. David Murray added the comment: > > Benjamin: meaning we should wait for git to merge it, or git will > automatically handle the history after conversion? > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 17:03:27 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Thu, 02 Jun 2016 21:03:27 +0000 Subject: [issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects. In-Reply-To: <1384516983.26.0.0584971052865.issue19611@psf.upfronthosting.co.za> Message-ID: <1464901407.66.0.446777508346.issue19611@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Since this only comes up with manually created functions (through calling types.FunctionType), I think it wouldn't be unreasonable to just not handle this case in the inspect module and close this as wontfix. Ned, is there a use case for converting comprehension code objects to functions and inspecting them? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 17:04:54 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 02 Jun 2016 21:04:54 +0000 Subject: [issue27181] Add geometric mean to `statistics` module Message-ID: <1464901494.08.0.0111988914026.issue27181@psf.upfronthosting.co.za> New submission from Raymond Hettinger: Steven, this seems like a reasonable suggestion (though I would expect someone else will immediately suggest a harmonic mean as well). Is this within the scope of what you were trying to do with the statistics module? ---------- assignee: -> steven.daprano nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 17:06:42 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 02 Jun 2016 21:06:42 +0000 Subject: [issue27187] Relax __all__ location requirement in PEP 8 Message-ID: <1464901602.05.0.802918160149.issue27187@psf.upfronthosting.co.za> New submission from Barry A. Warsaw: PEP 8 says: Put any relevant __all__ specification after the imports. I don't remember why we wanted __all__ to go after imports. I think we should relax that since other dunders can go before imports. See related PYCQA issue: https://github.com/PyCQA/pycodestyle/issues/394 ---------- messages: 266949 nosy: barry priority: normal severity: normal status: open title: Relax __all__ location requirement in PEP 8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 17:07:12 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 02 Jun 2016 21:07:12 +0000 Subject: [issue27187] Relax __all__ location requirement in PEP 8 In-Reply-To: <1464901602.05.0.802918160149.issue27187@psf.upfronthosting.co.za> Message-ID: <1464901632.05.0.141397961772.issue27187@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 17:07:38 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 02 Jun 2016 21:07:38 +0000 Subject: [issue26589] Add HTTP Response code 451 In-Reply-To: <1458339796.0.0.55641326492.issue26589@psf.upfronthosting.co.za> Message-ID: <1464901658.93.0.186584565844.issue26589@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks Nathan, I'll apply this shortly. ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 17:07:40 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Thu, 02 Jun 2016 21:07:40 +0000 Subject: [issue21446] Update reload fixer to use importlib instead of imp In-Reply-To: <1399369899.96.0.959859751651.issue21446@psf.upfronthosting.co.za> Message-ID: <1464901660.94.0.954092041055.issue21446@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: I couldn't find references in the docs to clarify what version of 3.x 2to3 targets, but it seems reasonable to me that it produces code targeted to the version of CPython it was bundled with. imp is deprecated and presumably will be removed later in 3.x, so it's better not to migrate people's Python 2 code to use it. ---------- nosy: +Jelle Zijlstra _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 17:09:49 2016 From: report at bugs.python.org (Dave Sawyer) Date: Thu, 02 Jun 2016 21:09:49 +0000 Subject: [issue27113] sqlite3 connect parameter "check_same_thread" not documented In-Reply-To: <1464125789.84.0.570004715823.issue27113@psf.upfronthosting.co.za> Message-ID: <1464901789.26.0.473579210948.issue27113@psf.upfronthosting.co.za> Dave Sawyer added the comment: The user probably has a recent enough version. This is guaranteed on Windows since Python bundles 3.6 or later. On mac or Linux it will use the version installed on the machine. I'll make a separate patch to check the version in sqlite3.py so it will give an error if attempted on too early a version. That's better than asking the user to verify ahead of time. The serialized mode is default on both Mac and Windows so we can probably skip validating that. I did like mentioning the user needs to serialize the writes. They could use one thread for writing only or use locking. So, I just said to serialize. ---------- Added file: http://bugs.python.org/file43116/sqlite_patch2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 17:11:39 2016 From: report at bugs.python.org (Ethan Furman) Date: Thu, 02 Jun 2016 21:11:39 +0000 Subject: [issue27182] PEP 519 support in the stdlib In-Reply-To: <1464887789.1.0.970652730446.issue27182@psf.upfronthosting.co.za> Message-ID: <1464901899.71.0.705691754998.issue27182@psf.upfronthosting.co.za> Ethan Furman added the comment: Nope. There is a posixpath.py and an ntpath.py, and they are not the same. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 17:12:53 2016 From: report at bugs.python.org (Dave Sawyer) Date: Thu, 02 Jun 2016 21:12:53 +0000 Subject: [issue27113] sqlite3 connect parameter "check_same_thread" not documented In-Reply-To: <1464125789.84.0.570004715823.issue27113@psf.upfronthosting.co.za> Message-ID: <1464901973.37.0.107360021328.issue27113@psf.upfronthosting.co.za> Dave Sawyer added the comment: Changed doc to note that not only must it be used on 1 thread if true, but that thread must be the thread that created it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 17:14:06 2016 From: report at bugs.python.org (Ian Lee) Date: Thu, 02 Jun 2016 21:14:06 +0000 Subject: [issue27187] Relax __all__ location requirement in PEP 8 In-Reply-To: <1464901602.05.0.802918160149.issue27187@psf.upfronthosting.co.za> Message-ID: <1464902046.71.0.514600714566.issue27187@psf.upfronthosting.co.za> Changes by Ian Lee : ---------- nosy: +IanLee1521 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 17:14:22 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Thu, 02 Jun 2016 21:14:22 +0000 Subject: [issue27113] sqlite3 connect parameter "check_same_thread" not documented In-Reply-To: <1464125789.84.0.570004715823.issue27113@psf.upfronthosting.co.za> Message-ID: <1464902062.5.0.34092859846.issue27113@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Dave, your patch looks good to me. Did you see the comment from Trevor on your first patch? >> According to the sqlite docs (http://www.sqlite.org/threadsafe.html), the default mode is 'serialized', which does the necessary locking for threads to share a connection. Unless Python is overriding this to use one of the less protected modes, it shouldn't be necessary to use extra locks around it. This had prompted me to remove extra line on asking users to take care of synchronization. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 17:18:35 2016 From: report at bugs.python.org (A. Jesse Jiryu Davis) Date: Thu, 02 Jun 2016 21:18:35 +0000 Subject: [issue27136] sock_connect fails for bluetooth (and probably others) In-Reply-To: <1464346938.98.0.196127839357.issue27136@psf.upfronthosting.co.za> Message-ID: <1464902315.03.0.895759204907.issue27136@psf.upfronthosting.co.za> A. Jesse Jiryu Davis added the comment: I can reproduce this. On Ubuntu 14.04 I installed "libbluetooth-dev" and then built Python 3.5.1 from source, confirmed the socket module has AF_BLUETOOTH and BTPROTO_RFCOMM. Running pyptr2's script gives the traceback pyptr2 reported. Yury and I discussed a fix, which I'll propose as a patch in the asyncio GitHub repo. ---------- nosy: +emptysquare _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 17:23:31 2016 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 02 Jun 2016 21:23:31 +0000 Subject: [issue24254] Make class definition namespace ordered by default In-Reply-To: <1432186488.39.0.20621749373.issue24254@psf.upfronthosting.co.za> Message-ID: <1464902611.74.0.62202820261.issue24254@psf.upfronthosting.co.za> Nick Coghlan added the comment: Patch review sent. The motivation for the change is relatively weak without __definition_order__, though :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 17:27:03 2016 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 02 Jun 2016 21:27:03 +0000 Subject: [issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects. In-Reply-To: <1384516983.26.0.0584971052865.issue19611@psf.upfronthosting.co.za> Message-ID: <1464902823.8.0.45665873532.issue19611@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: -> ncoghlan nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 17:29:10 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 02 Jun 2016 21:29:10 +0000 Subject: [issue21864] Error in documentation of point 9.8 'Exceptions are classes too' In-Reply-To: <1403653260.15.0.739232303856.issue21864@psf.upfronthosting.co.za> Message-ID: <1464902950.66.0.935163055153.issue21864@psf.upfronthosting.co.za> Berker Peksag added the comment: I think the "Exceptions Are Classes Too" section can be removed now. Users already learned that exceptions are classes in the previous chapter: https://docs.python.org/3/tutorial/errors.html I'm attaching a patch that removes the "Exceptions Are Classes Too" section and merges some of its content into https://docs.python.org/3/tutorial/errors.html ---------- keywords: +patch nosy: +berker.peksag stage: needs patch -> patch review versions: +Python 3.6 -Python 3.4 Added file: http://bugs.python.org/file43117/issue21864.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 17:36:42 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 02 Jun 2016 21:36:42 +0000 Subject: [issue18751] A manager's server never joins its threads In-Reply-To: <1376590396.18.0.712968689777.issue18751@psf.upfronthosting.co.za> Message-ID: <1464903402.8.0.800565730293.issue18751@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Capturing some notes from looking at this after Dan Sully asked me questions about the issue during today's pycon sprints: within multiprocessing/managers.py serve_forever(): the accepter thread is an infinite loop. i think this issue also wants to join() on the threads that the accepter spawns. which also implies they need to be kept track of and that we should change the accepter's while True: into a "while some event that indicates it should exit is not set"... but we'd also not want a pool keeping track of accepter's infinitely spawned threads to grow forever, so something needs to effectively garbage collect those periodically. ---------- nosy: +gregory.p.smith versions: +Python 3.5, Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 17:39:21 2016 From: report at bugs.python.org (Thomas Kluyver) Date: Thu, 02 Jun 2016 21:39:21 +0000 Subject: [issue27113] sqlite3 connect parameter "check_same_thread" not documented In-Reply-To: <1464125789.84.0.570004715823.issue27113@psf.upfronthosting.co.za> Message-ID: <1464903561.59.0.0560939318757.issue27113@psf.upfronthosting.co.za> Thomas Kluyver added the comment: Having watched the video of Dave's PyCon talk (thanks Dave), I think he's talking about using locking to control transactions, which presumably the sqlite bindings don't handle by themselves. But I don't *think* you need manual locking just to maintain database integrity. If that's the case, it's probably helpful to clarify it. I'd probably suggest that if you want to write from multiple threads and control transactions (i.e. more than just individual INSERTs fired from different threads), it's probably easier to use separate connections and let sqlite handle the synchronisation than to synchronise them yourself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 17:40:13 2016 From: report at bugs.python.org (Thomas Kluyver) Date: Thu, 02 Jun 2016 21:40:13 +0000 Subject: [issue27113] sqlite3 connect parameter "check_same_thread" not documented In-Reply-To: <1464125789.84.0.570004715823.issue27113@psf.upfronthosting.co.za> Message-ID: <1464903613.97.0.350534511097.issue27113@psf.upfronthosting.co.za> Thomas Kluyver added the comment: That comment contained far too much 'probably'. Time for me to sleep... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 17:44:19 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 02 Jun 2016 21:44:19 +0000 Subject: [issue27025] More human readable generated widget names In-Reply-To: <1463299445.94.0.887025569149.issue27025@psf.upfronthosting.co.za> Message-ID: <1464903859.31.0.66808302891.issue27025@psf.upfronthosting.co.za> Terry J. Reedy added the comment: While a widget tree could be constructed using tk's introspection functions, I believe there are other good uses for monkey patching. The attached .py file defines a monkeypatch context manager (does one exist already?). The file uses the c.m. twice to patch ConfigDialog.CreatePageFontTab so it patches tk for the duration of its call. The result is 16 rather than 287 lines of output. >Current (from my program) >.3070117292.3069168812.3069169068.3069251628.3068822220.3069266540.3068822348.3068839820.3068851532 > Using Tk command name as a base of a name: >._toplevel1._frame1._frame2._frame73._labelframe10._frame127._canvas6._frame128._label28 >Using Python class name: >._configdialog1._tabbedpageset1._frame1._frame61._labelframe10._verticalscrolledframe6._canvas6._frame105._label28 In the future, the last line might be shortened to >._config1._notebook1._frame1._frame61._labelframe10._vscrollframe6._canvas6._frame105._label28 which is shorter that the current address-based name. Anyone who cares can either user shorted class names or explicitly gives instances shorter default names. I don't know what to say about numbering, except that I would prefer any of the options to status quo. ---------- Added file: http://bugs.python.org/file43118/tknames.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 17:44:30 2016 From: report at bugs.python.org (Kushal Das) Date: Thu, 02 Jun 2016 21:44:30 +0000 Subject: [issue25548] Show the address in the repr for class objects In-Reply-To: <1446576011.58.0.372024983976.issue25548@psf.upfronthosting.co.za> Message-ID: <1464903870.16.0.562151675014.issue25548@psf.upfronthosting.co.za> Kushal Das added the comment: Attaching the patch for the same. Had to update the test cases for the following tests to have this behavior as expected. test_functools test_cmd_line_script test_ctypes test_defaultdict test_descr test_descrtut test_doctest test_generators test_genexps test_metaclass test_pprint test_reprlib test_statistics test_trace test_wsgiref ---------- keywords: +patch nosy: +kushal.das Added file: http://bugs.python.org/file43119/issue25548.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 17:53:34 2016 From: report at bugs.python.org (Dave Sawyer) Date: Thu, 02 Jun 2016 21:53:34 +0000 Subject: [issue27188] sqlite3 execute* methods return value not documented Message-ID: <1464904414.88.0.548243958784.issue27188@psf.upfronthosting.co.za> New submission from Dave Sawyer: The three execute methods of the connection object return the created cursor. The term "intermediate" implies the cursor is totally handled by the execute method, not that the user will get ownership of the object. When the user doesn't call close() on the returned cursor right away, they hold a lock on the database until the object is garbage collected. ---------- files: execdoc_patch1.txt messages: 266964 nosy: Dave Sawyer priority: normal severity: normal status: open title: sqlite3 execute* methods return value not documented type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43120/execdoc_patch1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 17:55:45 2016 From: report at bugs.python.org (Eryk Sun) Date: Thu, 02 Jun 2016 21:55:45 +0000 Subject: [issue16192] ctypes - documentation example In-Reply-To: <1349923369.86.0.516068156992.issue16192@psf.upfronthosting.co.za> Message-ID: <1464904545.28.0.585672531474.issue16192@psf.upfronthosting.co.za> Eryk Sun added the comment: > ``sizeof(long double) == sizeof(double)`` it is an alias to > :class:`c_double`. This should be "``sizeof(long) == sizeof(int)`` ... :class:`c_long`". ---------- resolution: fixed -> stage: resolved -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 17:55:49 2016 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 02 Jun 2016 21:55:49 +0000 Subject: [issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects. In-Reply-To: <1384516983.26.0.0584971052865.issue19611@psf.upfronthosting.co.za> Message-ID: <1464904549.67.0.428811279778.issue19611@psf.upfronthosting.co.za> Nick Coghlan added the comment: The origin of the ".0" parameter name is the compiler's implicit symbol definition - we use the "." prefix for those to ensure we don't accidentally collide with actual identifiers used in the code. We can see that via dis.dis: >>> def make_set(): ... return {z*z for z in range(5)} ... >>> import dis >>> dis.dis(make_set) 2 0 LOAD_CONST 1 ( at 0x7f54c5b2cd20, file "", line 2>) 3 LOAD_CONST 2 ('make_set..') 6 MAKE_FUNCTION 0 9 LOAD_GLOBAL 0 (range) 12 LOAD_CONST 3 (5) 15 CALL_FUNCTION 1 (1 positional, 0 keyword pair) 18 GET_ITER 19 CALL_FUNCTION 1 (1 positional, 0 keyword pair) 22 RETURN_VALUE >>> dis.dis(make_set.__code__.co_consts[1]) 2 0 BUILD_SET 0 3 LOAD_FAST 0 (.0) >> 6 FOR_ITER 16 (to 25) 9 STORE_FAST 1 (z) 12 LOAD_FAST 1 (z) 15 LOAD_FAST 1 (z) 18 BINARY_MULTIPLY 19 SET_ADD 2 22 JUMP_ABSOLUTE 6 >> 25 RETURN_VALUE It isn't just set comprehensions that will do this - it's all the implicit nested functions that accept a positional argument (list/dict/set comprehensions, generator expressions) I chatted to Brett Cannon about it, and we agree inspect should handle the implicit functions generated by the compiler, even if those signatures can't be expressed in normal Python code. The fact those may be emitted by the affected inspect functions can then be documented as a CPython implementation detail, rather than as a language level behaviour. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 18:03:13 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 02 Jun 2016 22:03:13 +0000 Subject: [issue27185] Clarify Test Coverage for the String Module (test_pep292 is not easily discoverable) In-Reply-To: <1464892105.41.0.770914187896.issue27185@psf.upfronthosting.co.za> Message-ID: <1464904993.92.0.365411705037.issue27185@psf.upfronthosting.co.za> R. David Murray added the comment: All right, I'll go ahead and commit it, then. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 18:03:43 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 02 Jun 2016 22:03:43 +0000 Subject: [issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects. In-Reply-To: <1384516983.26.0.0584971052865.issue19611@psf.upfronthosting.co.za> Message-ID: <1464905023.99.0.666947797716.issue19611@psf.upfronthosting.co.za> Yury Selivanov added the comment: > I chatted to Brett Cannon about it, and we agree inspect should handle the implicit functions generated by the compiler, even if those signatures can't be expressed in normal Python code. Can we make ".0" parameters positional-only then? And rename ".{digit}" into "arg{digit}"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 18:04:12 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Thu, 02 Jun 2016 22:04:12 +0000 Subject: [issue27181] Add geometric mean to `statistics` module In-Reply-To: <1464901494.08.0.0111988914026.issue27181@psf.upfronthosting.co.za> Message-ID: <20160602220300.GR12028@ando.pearwood.info> Steven D'Aprano added the comment: On Thu, Jun 02, 2016 at 09:04:54PM +0000, Raymond Hettinger wrote: > Steven, this seems like a reasonable suggestion (though I would expect > someone else will immediately suggest a harmonic mean as well). Is > this within the scope of what you were trying to do with the > statistics module? Yes, I think it is reasonable too. I'll aim to get this in to 3.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 18:05:34 2016 From: report at bugs.python.org (Kaushik N) Date: Thu, 02 Jun 2016 22:05:34 +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: <1464905134.46.0.719068213078.issue16484@psf.upfronthosting.co.za> Kaushik N added the comment: Applied patch from sean.rodman. Created a test. ---------- nosy: +Kaushik N Added file: http://bugs.python.org/file43121/Issue16484_python3.6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 18:06:53 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Jun 2016 22:06:53 +0000 Subject: [issue27186] add os.fspath() Message-ID: <20160602220647.10416.48472.A244A1B0@psf.io> New submission from Roundup Robot: New changeset 59a52a9dd0dc by Ethan Furman in branch 'default': issue27186 -- initial docs, tests, and python version of os.fspath https://hg.python.org/cpython/rev/59a52a9dd0dc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 18:06:56 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 02 Jun 2016 22:06:56 +0000 Subject: [issue27172] Add skip_bound_arg argument to inspect.Signature.from_callable() In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za> Message-ID: <1464905216.63.0.780587091047.issue27172@psf.upfronthosting.co.za> Yury Selivanov added the comment: Nick, what do you think about this one? I'm +1 to add this, but I'm not sure about the name for the argument. Do you have better ideas, or "skip_bound_arg" is good enough? ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 18:11:39 2016 From: report at bugs.python.org (Emily Morehouse) Date: Thu, 02 Jun 2016 22:11:39 +0000 Subject: [issue26829] update docs: when creating classes a new dict is created for the final class object In-Reply-To: <1461333834.83.0.0321229546915.issue26829@psf.upfronthosting.co.za> Message-ID: <1464905499.2.0.711332698527.issue26829@psf.upfronthosting.co.za> Emily Morehouse added the comment: Second version of patch for this -- more clearly states the process and outcome for class creation. Also adds to https://docs.python.org/3.6/library/functions.html#type to clarify that the dictionary object is copied to a standard dict. ---------- Added file: http://bugs.python.org/file43122/26829-v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 18:18:00 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 02 Jun 2016 22:18:00 +0000 Subject: [issue16113] Add SHA-3 and SHAKE (Keccak) support In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za> Message-ID: <1464905880.04.0.406849695275.issue16113@psf.upfronthosting.co.za> Gregory P. Smith added the comment: comments added to the code review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 18:18:28 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Jun 2016 22:18:28 +0000 Subject: [issue16192] ctypes - documentation example In-Reply-To: <1349923369.86.0.516068156992.issue16192@psf.upfronthosting.co.za> Message-ID: <20160602221801.73204.40546.D6551BBC@psf.io> Roundup Robot added the comment: New changeset dfde53cf07e6 by Berker Peksag in branch '3.5': Issue #16192: Fix copy and paste mistake noticed by Eryk Sun https://hg.python.org/cpython/rev/dfde53cf07e6 New changeset 7f3ebd86464b by Berker Peksag in branch 'default': Issue #16192: Merge from 3.5 https://hg.python.org/cpython/rev/7f3ebd86464b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 18:18:58 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 02 Jun 2016 22:18:58 +0000 Subject: [issue16192] ctypes - documentation example In-Reply-To: <1349923369.86.0.516068156992.issue16192@psf.upfronthosting.co.za> Message-ID: <1464905938.88.0.696012579964.issue16192@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 18:31:55 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 02 Jun 2016 22:31:55 +0000 Subject: [issue27189] configure --with-lto with clang should find the appropriate llvm-profdata tool Message-ID: <1464906715.45.0.48477464544.issue27189@psf.upfronthosting.co.za> New submission from Gregory P. Smith: The --with-lto support added in issue25702 can work with clang, but on a Linux distribution such as ubuntu 16.04 with clang installed you get: $ CC=clang ./configure --with-lto ... $ make profile-opt Error: Cannot perform PGO build because llvm-profdata was not found in PATH Please add it to PATH and run ./configure again Makefile:503: recipe for target 'profile-opt' failed make: *** [profile-opt] Error 1 The llvm-profdata tool exists but is only known as llvm-profdata-3.8. We should have the ./configure script figure this out. I'm not sure what the preferred "right" way to determine this is. Detecting that CC is a clang compiler and using its reported version number? noticing that clang is a symlink into an llvm-X.Y tree and using that number? none of these sound great. hopefully there is a better deterministic way to query clang for this. ---------- components: Build messages: 266976 nosy: gregory.p.smith priority: normal severity: normal stage: needs patch status: open title: configure --with-lto with clang should find the appropriate llvm-profdata tool type: compile error versions: Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 18:46:17 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 02 Jun 2016 22:46:17 +0000 Subject: [issue27179] subprocess uses wrong encoding on Windows In-Reply-To: <1464828766.51.0.809606583575.issue27179@psf.upfronthosting.co.za> Message-ID: <1464907577.59.0.591258072299.issue27179@psf.upfronthosting.co.za> Martin Panter added the comment: Patch B changes _Py_device_encoding() to accept a file descriptor of 3, which seems wrong to me. Patch A is like the earlier patch, but calls os.device_encoding(1) instead of relying on sys.stdout, etc. I think this will still fail when the Python parent?s stdout was never open (then fd 1 will be invalid, or used as something else). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 18:48:00 2016 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 02 Jun 2016 22:48:00 +0000 Subject: [issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects. In-Reply-To: <1384516983.26.0.0584971052865.issue19611@psf.upfronthosting.co.za> Message-ID: <1464907680.45.0.264182028769.issue19611@psf.upfronthosting.co.za> Nick Coghlan added the comment: We definitely can't use a valid identifier in the code generator, since any valid identifier we used might shadow a nonlocal, global or builtin name (and the latter two cases aren't visible to the compiler at compile time). They're also genuinely not positional only: >>> print(setcomp_func(iter(range(5)))) {0, 1, 4, 9, 16} >>> print(setcomp_func(**{".0": iter(range(5))})) {0, 1, 4, 9, 16} ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 18:50:35 2016 From: report at bugs.python.org (Dusty Phillips) Date: Thu, 02 Jun 2016 22:50:35 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1464907835.46.0.194329150463.issue27186@psf.upfronthosting.co.za> Dusty Phillips added the comment: Make os.fsencode and os.fsdecode able to accept a PathLike by calling into fspath. Additionally adds test for PathLike objects. ---------- keywords: +patch nosy: +buchuki Added file: http://bugs.python.org/file43123/issue27186.buchuki.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 18:52:33 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 02 Jun 2016 22:52:33 +0000 Subject: [issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects. In-Reply-To: <1384516983.26.0.0584971052865.issue19611@psf.upfronthosting.co.za> Message-ID: <1464907953.94.0.573093364775.issue19611@psf.upfronthosting.co.za> Yury Selivanov added the comment: > We definitely can't use a valid identifier in the code generator, since any valid identifier we used might shadow a nonlocal, global or builtin name (and the latter two cases aren't visible to the compiler at compile time). I wasn't proposing to fix code generator, but rather to transform the name to something that users will understand in inspect.signature code. ".0" will be extremely hard to google. > They're also genuinely not positional only: > >>> print(setcomp_func(**{".0": iter(range(5))})) > {0, 1, 4, 9, 16} My opinion on this: this is a very low-level implementation detail of CPython. If users start abusing Signature.bind for binding ".0" they will write code that will be hard to port to other implementations, and that will also create a requirement for us (CPython devs) to maintain backwards compatibility here. What I propose, is to rename ".0" args and to classify them as "positional-only". This would still make it possible to use Signature.bind on such callables, but in a safe way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 18:57:05 2016 From: report at bugs.python.org (Eric Snow) Date: Thu, 02 Jun 2016 22:57:05 +0000 Subject: [issue24254] Make class definition namespace ordered by default In-Reply-To: <1432186488.39.0.20621749373.issue24254@psf.upfronthosting.co.za> Message-ID: <1464908225.25.0.984064552002.issue24254@psf.upfronthosting.co.za> Eric Snow added the comment: Thanks. Yeah, I wanted to keep the patches separate for the sake of code review. I'll fold the changes into a single commit once everything's ready. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 19:05:06 2016 From: report at bugs.python.org (Dusty Phillips) Date: Thu, 02 Jun 2016 23:05:06 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1464908706.17.0.494681299861.issue27186@psf.upfronthosting.co.za> Dusty Phillips added the comment: Test __fspath__ returning bytes as well. ---------- Added file: http://bugs.python.org/file43124/issue27186.buchuki.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 19:07:46 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 02 Jun 2016 23:07:46 +0000 Subject: [issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more In-Reply-To: <1464270042.87.0.0233765451432.issue27130@psf.upfronthosting.co.za> Message-ID: <1464908866.54.0.308761645313.issue27130@psf.upfronthosting.co.za> Martin Panter added the comment: Klamann, thanks for crash report. I think your decompress crash is explained by the bug expanding past UINT_MAX I identified above. The key is that length = 0 in zlib_Decompress_decompress_impl(), as if wrapped around, and the return value will have been resized to zero. My suggested fix step 7 would address this. The workaround here would either be to pass compressed data in smaller chunks (4 MB or less), so that no chunk can expand to 4 GiB, or to make use of the max_length parameter. Either way, it will make any code more complicated though. If anyone wants to write a patch (or do testing) to solve any or all of the problems, I am happy to help. But it is not a high priority for me to do all the work, because I am not set up to test it easily. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 19:17:22 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Thu, 02 Jun 2016 23:17:22 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1464909442.95.0.140318629954.issue27186@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: This patch adds the C implementation (copied from the PEP). Some notes: - I added a new .h file in Include/ because there didn't seem to be an obvious existing place to put it. - There was some uncertainty about whether we should Py_INCREF the string or bytes returned when a string/bytes is passed in. Running test -l and -L works with the Py_INCREF in and we're adding a new reference to the module, so I think this is correct. ---------- nosy: +Jelle Zijlstra Added file: http://bugs.python.org/file43125/issue27186.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 19:20:19 2016 From: report at bugs.python.org (Ethan Furman) Date: Thu, 02 Jun 2016 23:20:19 +0000 Subject: [issue26266] add classattribute to enum to handle non-Enum attributes In-Reply-To: <1454430451.09.0.888937739305.issue26266@psf.upfronthosting.co.za> Message-ID: <1464909619.0.0.721902519481.issue26266@psf.upfronthosting.co.za> Ethan Furman added the comment: One possible downside to the `classattribute` route is that we have a descriptor whose only purpose is to shield the item from becoming a member; the up-side is that it's simple to implement. Another possibility is `skip`: class skip: """ Protects item from becaming an Enum member during class creation. """ def __init__(self, value): self.value = value def __get__(self, instance, ownerclass=None): return self.value The advantage is that it is replaced by the metaclass with the stored value, so we have no extraneous descriptor after the Enum is created; the downside is that it requires change in the metaclass to do the right thing. Thoughts? ---------- stage: -> needs patch type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 19:29:02 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 02 Jun 2016 23:29:02 +0000 Subject: [issue24291] Many servers (wsgiref, http.server, etc) can truncate large output blobs In-Reply-To: <1432671481.51.0.762064908488.issue24291@psf.upfronthosting.co.za> Message-ID: <1464910142.89.0.202340851873.issue24291@psf.upfronthosting.co.za> Martin Panter added the comment: I prefer your first solution because it seems to fit in better with how things were intended. I can add in handling of partial writes with a deprecation warning when I get a chance. I guess the documentation would be something like ?Since 3.5.2, partial writes are also handled, but this is deprecated.? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 19:29:38 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 02 Jun 2016 23:29:38 +0000 Subject: [issue26829] update docs: when creating classes a new dict is created for the final class object In-Reply-To: <1461333834.83.0.0321229546915.issue26829@psf.upfronthosting.co.za> Message-ID: <1464910178.82.0.918920241365.issue26829@psf.upfronthosting.co.za> R. David Murray added the comment: I can't get the rietveld review tool to work from this network, so I'll do this in a comment. This looks pretty good to me, but in the following: +It is important to note that during the creation of the class, a copy of the +namespace object is used in the final class object and the original namespace +object is discarded. More explicitly, this means that when ``type.__new__`` is +called, the object provided as the namespace parameter has its contents copied +to a standard Python dictionary. I think it is more in keeping with the style of the rest of the doc to boil this down as much as possible. We can drop the "It is important to note that", and just state the issue once, using the "more explicit" version. I think borrowing your revised language from the type docs would work well here, by adding "which becomes the __dict__ of the class object" to the end of that sentence. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 19:35:36 2016 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 02 Jun 2016 23:35:36 +0000 Subject: [issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects. In-Reply-To: <1384516983.26.0.0584971052865.issue19611@psf.upfronthosting.co.za> Message-ID: <1464910536.37.0.797271942033.issue19611@psf.upfronthosting.co.za> Nick Coghlan added the comment: Oh, I see what you mean, now - we can special case the compiler-generated ".N" names when extracting the signature. I like it - make the claimed parameter something like "implicit0" instead of ".0", mention that in the note on the docs, and folks may have some chance of working out what's going on if they manage to stumble across this behaviour. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 19:37:01 2016 From: report at bugs.python.org (Tommy Beadle) Date: Thu, 02 Jun 2016 23:37:01 +0000 Subject: [issue15476] Index "code object" and link to code object definition In-Reply-To: <1343459471.56.0.370073010984.issue15476@psf.upfronthosting.co.za> Message-ID: <1464910621.71.0.64423620554.issue15476@psf.upfronthosting.co.za> Tommy Beadle added the comment: The attached patch makes it so that 'code object' is its own 'top-level' entry in the index instead of being 'code' with an 'object' sub-item. It also makes the links from the index go to the location in the documents just before the header instead of having the header be off-screen when the user navigates to it. One thing about the ordering of the generated links, though, is that sphinx appears to generate them based on the alphabetical ordering of the path to the files that they're in: c-api/code.rst library/marshal.rst library/stdtypes.rst reference/datamodel.rst If the order is that important, I believe it would require us to create sub-items that could look like this: code object C API built-in type type reference marshaling It didn't seem like other indexed entries follow this breakout pattern, but if that's what's desired for this case, just let me know and I'll submit a different patch. ---------- keywords: +patch nosy: +tbeadle Added file: http://bugs.python.org/file43126/0001-Issue-15476-Make-code-object-its-own-entry-in-the-do.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 19:39:05 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Jun 2016 23:39:05 +0000 Subject: [issue27185] Clarify Test Coverage for the String Module (test_pep292 is not easily discoverable) In-Reply-To: <1464892105.41.0.770914187896.issue27185@psf.upfronthosting.co.za> Message-ID: <20160602233858.72914.65387.E00D80EB@psf.io> Roundup Robot added the comment: New changeset 89abefdebf4d by R David Murray in branch '3.5': #27185: move test_pep292 into test_string. https://hg.python.org/cpython/rev/89abefdebf4d New changeset c2d3d8c3e0bf by R David Murray in branch 'default': Merge: #27185: move test_pep292 into test_string. https://hg.python.org/cpython/rev/c2d3d8c3e0bf ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 19:41:17 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 02 Jun 2016 23:41:17 +0000 Subject: [issue27185] Clarify Test Coverage for the String Module (test_pep292 is not easily discoverable) In-Reply-To: <1464892105.41.0.770914187896.issue27185@psf.upfronthosting.co.za> Message-ID: <1464910877.46.0.389303762099.issue27185@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Erin. ---------- resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 19:42:54 2016 From: report at bugs.python.org (Emily Morehouse) Date: Thu, 02 Jun 2016 23:42:54 +0000 Subject: [issue26829] update docs: when creating classes a new dict is created for the final class object In-Reply-To: <1461333834.83.0.0321229546915.issue26829@psf.upfronthosting.co.za> Message-ID: <1464910974.61.0.19774243616.issue26829@psf.upfronthosting.co.za> Emily Morehouse added the comment: Trimmed down by keeping the more explicit explanation and taking into account suggestions. ---------- Added file: http://bugs.python.org/file43127/26829-v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 19:44:59 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Jun 2016 23:44:59 +0000 Subject: [issue25702] Link Time Optimizations support for GCC and CLANG In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za> Message-ID: <20160602234449.120039.37432.47624650@psf.io> Roundup Robot added the comment: New changeset f710dac07312 by Gregory P. Smith in branch '2.7': Issue #25702: A --with-lto configure option has been added that will https://hg.python.org/cpython/rev/f710dac07312 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 19:48:21 2016 From: report at bugs.python.org (Erin Braswell) Date: Thu, 02 Jun 2016 23:48:21 +0000 Subject: [issue27185] Clarify Test Coverage for the String Module (test_pep292 is not easily discoverable) In-Reply-To: <1464892105.41.0.770914187896.issue27185@psf.upfronthosting.co.za> Message-ID: <1464911301.45.0.173330252178.issue27185@psf.upfronthosting.co.za> Erin Braswell added the comment: Hooray thank you everyone! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 19:52:11 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 02 Jun 2016 23:52:11 +0000 Subject: [issue26589] Add HTTP Response code 451 In-Reply-To: <1458339796.0.0.55641326492.issue26589@psf.upfronthosting.co.za> Message-ID: <1464911531.95.0.581651840696.issue26589@psf.upfronthosting.co.za> Martin Panter added the comment: Don?t forget to fix the RFC number (see review) :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 19:59:11 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Thu, 02 Jun 2016 23:59:11 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1464911951.53.0.556219142333.issue27186@psf.upfronthosting.co.za> Changes by Jelle Zijlstra : Added file: http://bugs.python.org/file43128/issue27186-DirEntry-fspath.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 20:01:12 2016 From: report at bugs.python.org (Susumu Koshiba) Date: Fri, 03 Jun 2016 00:01:12 +0000 Subject: [issue25738] http.server doesn't handle RESET CONTENT status correctly In-Reply-To: <1448583978.87.0.253695569638.issue25738@psf.upfronthosting.co.za> Message-ID: <1464912072.14.0.263239539505.issue25738@psf.upfronthosting.co.za> Susumu Koshiba added the comment: Patched the behaviors when NO_CONTENT and RESET_CONTENT are sent via send_error(). According to RFCs, they aren't actually errors so sending them through send_response() seems to make the most sense, however. send_error()'s behavior changes in this patch are: - Removed content-length field in the header for NO_CONTENT as per the RFC - Removed content-length field in the header for RESET_CONTENT also to comply with option c) mentioned in RFC7321 6.3.6 ---------- keywords: +patch nosy: +Susumu Koshiba versions: +Python 3.6 Added file: http://bugs.python.org/file43129/issue25738_http_reset_content.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 20:06:33 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jun 2016 00:06:33 +0000 Subject: [issue26829] update docs: when creating classes a new dict is created for the final class object In-Reply-To: <1461333834.83.0.0321229546915.issue26829@psf.upfronthosting.co.za> Message-ID: <20160603000629.4951.61511.00256799@psf.io> Roundup Robot added the comment: New changeset 754118f8b3ce by R David Murray in branch '3.5': #26829: Clarify that namespace is copied to a new __dict__ in instance creation. https://hg.python.org/cpython/rev/754118f8b3ce New changeset 5a4ace14b350 by R David Murray in branch 'default': Merge: #26829: Clarify that namespace is copied to a new __dict__ in instance creation. https://hg.python.org/cpython/rev/5a4ace14b350 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 20:07:51 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Jun 2016 00:07:51 +0000 Subject: [issue26829] update docs: when creating classes a new dict is created for the final class object In-Reply-To: <1461333834.83.0.0321229546915.issue26829@psf.upfronthosting.co.za> Message-ID: <1464912471.77.0.26457827332.issue26829@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Emily. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 20:08:29 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Fri, 03 Jun 2016 00:08:29 +0000 Subject: [issue27038] Make os.DirEntry exist In-Reply-To: <1463413415.02.0.145090656269.issue27038@psf.upfronthosting.co.za> Message-ID: <1464912509.23.0.60800186768.issue27038@psf.upfronthosting.co.za> Changes by Jelle Zijlstra : ---------- keywords: +patch Added file: http://bugs.python.org/file43130/issue27038.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 20:16:15 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jun 2016 00:16:15 +0000 Subject: [issue25931] os.fork() command distributed in windows Python27 (in SocketServer module) In-Reply-To: <1450840231.57.0.83917358919.issue25931@psf.upfronthosting.co.za> Message-ID: <20160603001608.4561.66468.C8F1D4AE@psf.io> Roundup Robot added the comment: New changeset d772400a1211 by Gregory P. Smith in branch 'default': Issue #25931: Don't defining socketserver.Forking* names on platforms such https://hg.python.org/cpython/rev/d772400a1211 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 20:18:15 2016 From: report at bugs.python.org (Alexander Liu) Date: Fri, 03 Jun 2016 00:18:15 +0000 Subject: [issue22797] urllib.request.urlopen documentation falsely guarantees that a URLError will be raised on errors In-Reply-To: <1415120697.65.0.296811511924.issue22797@psf.upfronthosting.co.za> Message-ID: <1464913094.92.0.477144617865.issue22797@psf.upfronthosting.co.za> Alexander Liu added the comment: Fixed the docs to specifically note that only protocol related errors raise the UrlError exception. ---------- nosy: +alex_thebear versions: +Python 3.6 -Python 3.4 Added file: http://bugs.python.org/file43131/urlopen_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 20:19:11 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 03 Jun 2016 00:19:11 +0000 Subject: [issue25931] os.fork() command distributed in windows Python27 (in SocketServer module) In-Reply-To: <1450840231.57.0.83917358919.issue25931@psf.upfronthosting.co.za> Message-ID: <1464913151.44.0.856230214506.issue25931@psf.upfronthosting.co.za> Gregory P. Smith added the comment: I made the change to not export the Forking names on Windows or other non-os.fork() supporting platforms in 3.6 only as it is arguably an API change, even though the names it removes would effectively be unusable on those platforms anyways. the docs still need updating. ---------- nosy: +gregory.p.smith versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 20:20:07 2016 From: report at bugs.python.org (Ian Lee) Date: Fri, 03 Jun 2016 00:20:07 +0000 Subject: [issue27187] Relax __all__ location requirement in PEP 8 In-Reply-To: <1464901602.05.0.802918160149.issue27187@psf.upfronthosting.co.za> Message-ID: <1464913207.01.0.0181794500308.issue27187@psf.upfronthosting.co.za> Ian Lee added the comment: I think that it should be updated to specify that all dunders ('__all__', '__version__', '__author__', etc) should be placed after the module docstring and before any imports. See issue-27187-patch1.txt for a possible update. ---------- Added file: http://bugs.python.org/file43132/issue-27187-patch1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 20:22:43 2016 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 03 Jun 2016 00:22:43 +0000 Subject: [issue27137] Python implementation of `functools.partial` is not a class In-Reply-To: <1464367158.87.0.208604382314.issue27137@psf.upfronthosting.co.za> Message-ID: <1464913363.19.0.638181216656.issue27137@psf.upfronthosting.co.za> Nick Coghlan added the comment: As Raymond notes, the main downside here is in terms of code complexity. However, the concrete gain is that APIs that rely on callable pickling, such as concurrent.futures with a ProcessPoolExecutor, would be consistently compatible with functools.partial: >>> from concurrent.futures import ProcessPoolExecutor >>> from functools import partial >>> with ProcessPoolExecutor() as pool: ... pool.submit(print, "hello") ... pool.submit(partial(print, "hello")) ... hello hello At the moment, such code will fail if _functools is unavailable, since closures don't support pickling (unpickling functions involves looking them up by name, which isn't possible with closures) The other main benefit is retaining the custom __repr__ when falling back to the Python implementation: >>> partial(print, "hello") functools.partial(, 'hello') At the moment, the closure-based version instead gives: >>> partial(print, "hello") .newfunc at 0x7f4fd6e0aea0> Preserving those two capabilities seems sufficiently worthwhile to me to justify the extra code complexity and the greater speed penalty when the accelerator module isn't available (I'm assuming that in runtimes using a JIT compiler the speed difference should be negligible in practice) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 20:23:41 2016 From: report at bugs.python.org (Dusty Phillips) Date: Fri, 03 Jun 2016 00:23:41 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1464913421.92.0.934310068007.issue27186@psf.upfronthosting.co.za> Dusty Phillips added the comment: This patch adds fspath protocol and constructor initialization to pathlib.Path. ---------- Added file: http://bugs.python.org/file43133/issue27186-pathlib.buchuki.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 20:23:52 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Jun 2016 00:23:52 +0000 Subject: [issue25931] os.fork() command distributed in windows Python27 (in SocketServer module) In-Reply-To: <1450840231.57.0.83917358919.issue25931@psf.upfronthosting.co.za> Message-ID: <1464913432.29.0.273944339219.issue25931@psf.upfronthosting.co.za> R. David Murray added the comment: Your news entry says "don't defining". The doc note can say that the classes are only defined if the platform supports fork. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 20:24:50 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Jun 2016 00:24:50 +0000 Subject: [issue25931] os.fork() command distributed in windows Python27 (in SocketServer module) In-Reply-To: <1450840231.57.0.83917358919.issue25931@psf.upfronthosting.co.za> Message-ID: <1464913490.82.0.569371901894.issue25931@psf.upfronthosting.co.za> R. David Murray added the comment: Well, defined for 3.6, and "functional" for 2.7 and 3.5 docs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 20:25:16 2016 From: report at bugs.python.org (Dusty Phillips) Date: Fri, 03 Jun 2016 00:25:16 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1464913516.67.0.487282772812.issue27186@psf.upfronthosting.co.za> Changes by Dusty Phillips : Removed file: http://bugs.python.org/file43123/issue27186.buchuki.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 20:27:51 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 03 Jun 2016 00:27:51 +0000 Subject: [issue25702] Link Time Optimizations support for GCC and CLANG In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za> Message-ID: <1464913671.76.0.292232710191.issue25702@psf.upfronthosting.co.za> Gregory P. Smith added the comment: the main part of this issue is done but it can't be closed until the dependencies listed are also dealt with. un-assigning myself. ---------- assignee: gregory.p.smith -> resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 20:31:10 2016 From: report at bugs.python.org (Ian Lee) Date: Fri, 03 Jun 2016 00:31:10 +0000 Subject: [issue27187] Relax __all__ location requirement in PEP 8 In-Reply-To: <1464901602.05.0.802918160149.issue27187@psf.upfronthosting.co.za> Message-ID: <1464913870.27.0.333502495759.issue27187@psf.upfronthosting.co.za> Ian Lee added the comment: I might also suggest that the entire "Version bookkeeping" section could be removed in this case, as it would be covered by my newly added dunder section. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 20:34:21 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 03 Jun 2016 00:34:21 +0000 Subject: [issue27167] subprocess reports signal as negative exit status, not documented In-Reply-To: <1464712500.44.0.979958949461.issue27167@psf.upfronthosting.co.za> Message-ID: <1464914061.76.0.662472421653.issue27167@psf.upfronthosting.co.za> Gregory P. Smith added the comment: docs updated (7b12180481da and 19d77132f38d). working on the error message update. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 20:43:05 2016 From: report at bugs.python.org (Dave Sawyer) Date: Fri, 03 Jun 2016 00:43:05 +0000 Subject: [issue27113] sqlite3 connect parameter "check_same_thread" not documented In-Reply-To: <1464125789.84.0.570004715823.issue27113@psf.upfronthosting.co.za> Message-ID: <1464914585.79.0.966572859692.issue27113@psf.upfronthosting.co.za> Dave Sawyer added the comment: Hi Thomas and Senthil, for the serialized setting I mentioned earlier "The serialized mode is default on both Mac and Windows so we can probably skip validating that. I did like mentioning the user needs to serialize the writes. They could use one thread for writing only or use locking. So, I just said to serialize." to go into more detail, when serialize is set you don't need to worry that using multiple threads will WRECK your database. But, you still need to make sure your own writes get serialized or you will mix transactions together. Each connection only has one transaction in progress so if you share that connection between threads... watch out for your writes. Now if only one thread in your application writes and the other threads read you have no serialization issues to worry about. If two threads make updates without a threading.Lock than you can get 1.5 changes committed (and perhaps 0.5 later or if that had an error you might rollback that 0.5 of a transaction). You could also get the first thread to commit both changes and when the later thread calls commit get an error that is "no transaction in progress." I thought "serialize" neatly encapsulated the two most common strategies here for shared connections - either a dedicated writer thread or using a python lock around your transactions. As Thomas points out you can also opt to give each thread its own connection... but then you don't need the check_same_thread parameter set to False as you are not sharing the connection. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 20:43:16 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Jun 2016 00:43:16 +0000 Subject: [issue15476] Index "code object" and link to code object definition In-Reply-To: <1343459471.56.0.370073010984.issue15476@psf.upfronthosting.co.za> Message-ID: <1464914596.25.0.155882416315.issue15476@psf.upfronthosting.co.za> R. David Murray added the comment: Since the main object of the issue is to have a canonical reference to use for linking 'code object' from elsewhere in the text, I think that can be satisfied by existing _bltin-code-objects 'ref' link as Terry suggests, even though it is a bit awkward to use. The changes to the index position are good, I think, as is having a direct index entry for 'code object'. However, following the model laid down by 'class object', the existing index entries under object should not be lost, but instead the new 'code object' index links should be added. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 20:44:51 2016 From: report at bugs.python.org (Ian Lee) Date: Fri, 03 Jun 2016 00:44:51 +0000 Subject: [issue27187] Relax __all__ location requirement in PEP 8 In-Reply-To: <1464901602.05.0.802918160149.issue27187@psf.upfronthosting.co.za> Message-ID: <1464914691.08.0.145858689913.issue27187@psf.upfronthosting.co.za> Changes by Ian Lee : Added file: http://bugs.python.org/file43134/issue-27187-patch2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 20:47:47 2016 From: report at bugs.python.org (Ian Lee) Date: Fri, 03 Jun 2016 00:47:47 +0000 Subject: [issue23061] Update pep8 to specify explicitly 'module level' imports at top of file In-Reply-To: <1418703864.09.0.281927050653.issue23061@psf.upfronthosting.co.za> Message-ID: <1464914867.95.0.544366592436.issue23061@psf.upfronthosting.co.za> Ian Lee added the comment: Are there any other concerns with the patch that I would be able to clean up? ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 20:53:39 2016 From: report at bugs.python.org (Dave Sawyer) Date: Fri, 03 Jun 2016 00:53:39 +0000 Subject: [issue27190] Check sqlite3_version before allowing check_same_thread = False Message-ID: <1464915219.9.0.729350732197.issue27190@psf.upfronthosting.co.za> New submission from Dave Sawyer: Starting in sqlite version 3.3.1 (Jan 2006) multiple threads can share the same connection. Python allows you do use this with the check_same_thread parameter of sqlite3.connect() method. It's almost certain users have a late enough version of sqlite that they can use this option. While we could document "check your version before using this feature" (see http://bugs.python.org/issue27113) it would be nicer to check the actual database for support. Code can be written and tested on one machine and deployed to another machine. Using this feature on an very old version of sqlite can crash or possibly corrupt the database. ---------- files: sqlite_oldver_issue.txt messages: 267013 nosy: Dave Sawyer priority: normal severity: normal status: open title: Check sqlite3_version before allowing check_same_thread = False type: enhancement Added file: http://bugs.python.org/file43135/sqlite_oldver_issue.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 20:59:26 2016 From: report at bugs.python.org (Ian Lee) Date: Fri, 03 Jun 2016 00:59:26 +0000 Subject: [issue27187] Relax __all__ location requirement in PEP 8 In-Reply-To: <1464901602.05.0.802918160149.issue27187@psf.upfronthosting.co.za> Message-ID: <1464915566.57.0.878195373558.issue27187@psf.upfronthosting.co.za> Ian Lee added the comment: I added a comment on a pull request related to this that shows some of the cases that we probably don't want to allow: https://github.com/PyCQA/pycodestyle/pull/523#issuecomment-223464775 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 21:02:50 2016 From: report at bugs.python.org (Ian Lee) Date: Fri, 03 Jun 2016 01:02:50 +0000 Subject: [issue27191] Add formatting around methods in PEP 8 Message-ID: <1464915770.62.0.255842565692.issue27191@psf.upfronthosting.co.za> New submission from Ian Lee: Noticed a couple methods in the text that aren't backtick quoted. ---------- assignee: docs at python components: Documentation files: rst-formatting.txt messages: 267015 nosy: IanLee1521, barry, docs at python priority: normal severity: normal status: open title: Add formatting around methods in PEP 8 Added file: http://bugs.python.org/file43136/rst-formatting.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 21:03:38 2016 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 03 Jun 2016 01:03:38 +0000 Subject: [issue18751] A manager's server never joins its threads In-Reply-To: <1376590396.18.0.712968689777.issue18751@psf.upfronthosting.co.za> Message-ID: <1464915818.05.0.747839367767.issue18751@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 21:04:19 2016 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 03 Jun 2016 01:04:19 +0000 Subject: [issue15476] Index "code object" and link to code object definition In-Reply-To: <1343459471.56.0.370073010984.issue15476@psf.upfronthosting.co.za> Message-ID: <1464915859.26.0.472728335541.issue15476@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 21:12:54 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Fri, 03 Jun 2016 01:12:54 +0000 Subject: [issue22890] StringIO.StringIO pickled in 2.7 is not unpickleable on 3.x In-Reply-To: <1416210085.6.0.932097721403.issue22890@psf.upfronthosting.co.za> Message-ID: <1464916374.68.0.591027558048.issue22890@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Unless I'm missing something, StringIO doesn't exist as a module in Python 3, as mentioned in https://docs.python.org/3.0/whatsnew/3.0.html#text-vs-data-instead-of-unicode-vs-8-bit. If you're trying to unpickle in 3.x an object pickled by 2.7.x, I'm not sure there is a guarantee that unpickling works for objects in modules that were renamed between 2.x and 3.x. This also doesn't work if you pickle a ConfigParser in 2.7 and unpickle it in 3.x. ---------- nosy: +Jelle Zijlstra _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 21:14:14 2016 From: report at bugs.python.org (Nina Zakharenko) Date: Fri, 03 Jun 2016 01:14:14 +0000 Subject: [issue25812] locale.nl_langinfo() can't decode value In-Reply-To: <1449350345.3.0.205814810685.issue25812@psf.upfronthosting.co.za> Message-ID: <1464916454.8.0.663844698861.issue25812@psf.upfronthosting.co.za> Nina Zakharenko added the comment: Adding the test below to test__locale.py will reproduce the issue under the following conditions: - The locale `uk_UA` is installed on your system. - 'uk_UA': (',', '\xa0') is added to the `known_numerics` dictionary in this test file @unittest.skipUnless(nl_langinfo, "nl_langinfo is not available") def test_lc_numeric_not_char_nl_langinfo(self): # Test nl_langinfo against known values/ # It should still work if there's a mismatch between # String & Numeric Locales tested = False for loc in candidate_locales: try: setlocale(LC_NUMERIC, loc) except Error: continue for li, lc in ((RADIXCHAR, "decimal_point"), (THOUSEP, "thousands_sep")): if self.numeric_tester('nl_langinfo', nl_langinfo(li), lc, loc): tested = True if not tested: self.skipTest('no suitable locales') ---------- nosy: +nnja _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 21:15:36 2016 From: report at bugs.python.org (John Mark Vandenberg) Date: Fri, 03 Jun 2016 01:15:36 +0000 Subject: [issue27187] Relax __all__ location requirement in PEP 8 In-Reply-To: <1464901602.05.0.802918160149.issue27187@psf.upfronthosting.co.za> Message-ID: <1464916536.66.0.45041531038.issue27187@psf.upfronthosting.co.za> Changes by John Mark Vandenberg : ---------- nosy: +jayvdb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 21:15:58 2016 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 03 Jun 2016 01:15:58 +0000 Subject: [issue22890] StringIO.StringIO pickled in 2.7 is not unpickleable on 3.x In-Reply-To: <1416210085.6.0.932097721403.issue22890@psf.upfronthosting.co.za> Message-ID: <1464916558.1.0.790475826385.issue22890@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 21:28:12 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 03 Jun 2016 01:28:12 +0000 Subject: [issue27185] Clarify Test Coverage for the String Module (test_pep292 is not easily discoverable) In-Reply-To: <1464892105.41.0.770914187896.issue27185@psf.upfronthosting.co.za> Message-ID: <1464917292.69.0.61037900275.issue27185@psf.upfronthosting.co.za> Martin Panter added the comment: FWIW I doubt Git is any better at this than Mercurial: Git can automatically pick up file renames and copies when analysing the history, but has no special metadata for this. I understand Mercurial is the opposite (has metadata, but at least by default does not pick up copies and renames from the history). Perhaps that is what Benjamin was thinking of. I understand Git will only pick up movements of the majority of a file, not parts of files (unless something has changed recently). Perhaps Serhiy can clarify, but I imagine he was proposing something like this (which I have not tested): A. Start at revision A B. Remove test_string and rename test_pep292 in its place, giving revision B C. Merge revisions A and B, and manually merge the contents of the two test_string versions, giving the final revision ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 21:36:08 2016 From: report at bugs.python.org (Eryk Sun) Date: Fri, 03 Jun 2016 01:36:08 +0000 Subject: [issue27184] Support path objects in the ntpath module Message-ID: <1464917768.07.0.74753238066.issue27184@psf.upfronthosting.co.za> New submission from Eryk Sun: nt is the module name for posixmodule.c on Windows, so I'm changing the title to reference ntpath instead. Regarding nt, two of its built-in functions are exposed directly in ntpath. _isdir is imported as isdir, so it needs a wrapper to support __fspath__. Only pathlib uses _getfinalpathname, so for now I think it can be handled there. There's also nt._getdiskusage, which is only used by shutil.disk_usage. For some reason the PEP doesn't mention updating shutil to support __fspath__. ---------- components: +Library (Lib), Windows nosy: +eryksun, paul.moore, steve.dower, tim.golden, zach.ware title: Support path objects in the nt module -> Support path objects in the ntpath module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 22:03:29 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jun 2016 02:03:29 +0000 Subject: [issue27191] Add formatting around methods in PEP 8 In-Reply-To: <1464915770.62.0.255842565692.issue27191@psf.upfronthosting.co.za> Message-ID: <20160603020325.103107.35214.E83C5817@psf.io> Roundup Robot added the comment: New changeset bf7f369fb49a by Berker Peksag in branch 'default': Issue #27191: Improve markup of PEP 8, patch by Ian Lee https://hg.python.org/peps/rev/bf7f369fb49a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 22:03:58 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 03 Jun 2016 02:03:58 +0000 Subject: [issue27191] Add formatting around methods in PEP 8 In-Reply-To: <1464915770.62.0.255842565692.issue27191@psf.upfronthosting.co.za> Message-ID: <1464919438.95.0.082247705002.issue27191@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks! ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 22:09:31 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 03 Jun 2016 02:09:31 +0000 Subject: [issue27190] Check sqlite3_version before allowing check_same_thread = False In-Reply-To: <1464915219.9.0.729350732197.issue27190@psf.upfronthosting.co.za> Message-ID: <1464919771.19.0.317174351965.issue27190@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch. I'm not sure we can apply the patch to bugfix branches. You can use SQLITE_VERSION_NUMBER to check sqlite3 version. ---------- nosy: +berker.peksag stage: -> patch review versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 22:09:42 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 03 Jun 2016 02:09:42 +0000 Subject: [issue27190] Check sqlite3_version before allowing check_same_thread = False In-Reply-To: <1464915219.9.0.729350732197.issue27190@psf.upfronthosting.co.za> Message-ID: <1464919782.32.0.944402157385.issue27190@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- components: +Extension Modules _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 22:26:49 2016 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 03 Jun 2016 02:26:49 +0000 Subject: [issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more In-Reply-To: <1464270042.87.0.0233765451432.issue27130@psf.upfronthosting.co.za> Message-ID: <1464920809.48.0.913968432243.issue27130@psf.upfronthosting.co.za> Xiang Zhang added the comment: I'd like to help but it'll need some time. And I'd like to start after issue27164 is solved. zdict now also checks for 4GB limit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 22:31:39 2016 From: report at bugs.python.org (Steve Dower) Date: Fri, 03 Jun 2016 02:31:39 +0000 Subject: [issue27179] subprocess uses wrong encoding on Windows In-Reply-To: <1464828766.51.0.809606583575.issue27179@psf.upfronthosting.co.za> Message-ID: <1464921099.76.0.248800066967.issue27179@psf.upfronthosting.co.za> Steve Dower added the comment: > There is right encoding, it's encoding that's actually used. This is true, but it puts the decision entirely in the hands of the developer(s) of the two processes involved. All IPC on Windows uses bytes, and encodings _always_ need to be negotiated by the processes involved. You can't reliably assume or infer anything. The closest you get is to assume that both processes are using the same MSVCRT version and have not changed the defaults (except Python changes the defaults, from text to binary, so that assumption is easily broken). Using "cmd /u" is one way to negotiate with that process for the shell=True case, but all others basically just require an explicit encoding parameter so that it can be specified. IMHO, if we make Python default to UTF-8 and subprocess use utf_8:errors (mojibake is not acceptable by default) and "cmd /u", we cover enough common cases to minimise the need to explicitly specify. (A close second best is to default to the console CP if available and default locale otherwise.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 22:32:18 2016 From: report at bugs.python.org (=?utf-8?b?RMSBdmlz?=) Date: Fri, 03 Jun 2016 02:32:18 +0000 Subject: [issue27179] subprocess uses wrong encoding on Windows In-Reply-To: <1464828766.51.0.809606583575.issue27179@psf.upfronthosting.co.za> Message-ID: <1464921138.27.0.337598510427.issue27179@psf.upfronthosting.co.za> D?vis added the comment: if there's no console then os.device_encoding won't fail, it will just return None which means that ANSI codepage will be used like it currently is and so here it doesn't change anything, current behavior stays. Also like I showed TextIOWrapper already calls device_encoding even if there's no console. And device_encoding doesn't actually use that fd it just checks if it's valid fd and then calls GetConsoleCP/GetConsoleOutputCP to get encoding. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 22:44:43 2016 From: report at bugs.python.org (Harrison Chudleigh) Date: Fri, 03 Jun 2016 02:44:43 +0000 Subject: [issue27192] Keyboard Shortcuts Consistently Cause Crashes Message-ID: <1464921883.27.0.409167298484.issue27192@psf.upfronthosting.co.za> New submission from Harrison Chudleigh: When trying to add keys to my program, I noticed that using the shortcuts Alt-e, Alt-i, Alt-n and Alt-u caused IDLE to consistently crash. No odd behavior was observed with the corresponding capital letters. ---------- components: Macintosh messages: 267026 nosy: Harrison Chudleigh, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Keyboard Shortcuts Consistently Cause Crashes type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 22:47:02 2016 From: report at bugs.python.org (Harrison Chudleigh) Date: Fri, 03 Jun 2016 02:47:02 +0000 Subject: [issue27193] Tkinter Unresponsive With Special Keys Message-ID: <1464922022.89.0.541400741468.issue27193@psf.upfronthosting.co.za> New submission from Harrison Chudleigh: When working on my program (the same one where I found Issue 27192), I tried adding keyboard shortcuts. I discovered that Tkinter doe not register the keys Alt, Command, Control, Fn, Shift and Caps Lock on a Mac. ---------- components: Macintosh messages: 267027 nosy: Harrison Chudleigh, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Tkinter Unresponsive With Special Keys versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 22:48:24 2016 From: report at bugs.python.org (Tommy Beadle) Date: Fri, 03 Jun 2016 02:48:24 +0000 Subject: [issue15476] Index "code object" and link to code object definition In-Reply-To: <1343459471.56.0.370073010984.issue15476@psf.upfronthosting.co.za> Message-ID: <1464922104.57.0.568920379934.issue15476@psf.upfronthosting.co.za> Tommy Beadle added the comment: This restores the original code -> object items. ---------- Added file: http://bugs.python.org/file43137/0001-Issue-15476-Make-code-object-its-own-entry-in-the-do.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 22:52:53 2016 From: report at bugs.python.org (Emanuel Barry) Date: Fri, 03 Jun 2016 02:52:53 +0000 Subject: [issue27192] Keyboard Shortcuts Consistently Cause Crashes In-Reply-To: <1464921883.27.0.409167298484.issue27192@psf.upfronthosting.co.za> Message-ID: <1464922373.42.0.233239830216.issue27192@psf.upfronthosting.co.za> Changes by Emanuel Barry : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Tkinter Unresponsive With Special Keys _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 22:55:05 2016 From: report at bugs.python.org (Emanuel Barry) Date: Fri, 03 Jun 2016 02:55:05 +0000 Subject: [issue27193] Tkinter Unresponsive With Special Keys In-Reply-To: <1464922022.89.0.541400741468.issue27193@psf.upfronthosting.co.za> Message-ID: <1464922505.32.0.799416389223.issue27193@psf.upfronthosting.co.za> Changes by Emanuel Barry : ---------- components: +Extension Modules stage: -> needs patch type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 23:03:10 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 03 Jun 2016 03:03:10 +0000 Subject: [issue25931] os.fork() command distributed in windows Python27 (in SocketServer module) In-Reply-To: <1450840231.57.0.83917358919.issue25931@psf.upfronthosting.co.za> Message-ID: <1464922990.45.0.268079060104.issue25931@psf.upfronthosting.co.za> Martin Panter added the comment: This broke test_socketserver: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/7709/steps/test/logs/stdio 0:08:57 [193/400/1] test_socketserver failed test test_socketserver crashed -- Traceback (most recent call last): File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_socketserver.py", line 371, in class ForkingErrorTestServer(socketserver.ForkingMixIn, BaseErrorTestServer): AttributeError: module 'socketserver' has no attribute 'ForkingMixIn' I am with David that it may not be worthwhile churning the API like this. Just document the existing (in 3.5) status that even though the classes exist, they need a working os.fork(). Otherwise, everyone that references ForkingMixIn but doesn?t use it (like test_socketserver) will have to update their code for 3.6. ---------- nosy: +martin.panter versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 23:13:27 2016 From: report at bugs.python.org (Luke Taylor) Date: Fri, 03 Jun 2016 03:13:27 +0000 Subject: [issue23670] Modifications to support iOS as a cross-compilation target In-Reply-To: <1426400747.11.0.0527548590348.issue23670@psf.upfronthosting.co.za> Message-ID: <1464923607.93.0.305552153928.issue23670@psf.upfronthosting.co.za> Luke Taylor added the comment: Are you aware of Pythonista? I have no affiliation, but I'm a fan of the app and the community surrounding it. See http://omz-software.com/pythonista/ for details. I'm sure communication with the developer of the app could yield some useful insights. ---------- nosy: +Luke Taylor _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 23:44:31 2016 From: report at bugs.python.org (Matthias Klose) Date: Fri, 03 Jun 2016 03:44:31 +0000 Subject: [issue17500] move PC/icons/source.xar to http://www.python.org/community/logos/ In-Reply-To: <1363820002.7.0.633809398541.issue17500@psf.upfronthosting.co.za> Message-ID: <1464925471.46.0.397179817708.issue17500@psf.upfronthosting.co.za> Matthias Klose added the comment: even for the window builds, I don't see any use of these icons for any build. I filed https://github.com/python/pythondotorg/issues/945 to make these files available as downloadable resources. However even if these are not accepted there, I think we should remove the PC/icons directory for all active branches. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 23:45:12 2016 From: report at bugs.python.org (Matthias Klose) Date: Fri, 03 Jun 2016 03:45:12 +0000 Subject: [issue17500] move PC/icons/source.xar to http://www.python.org/community/logos/ In-Reply-To: <1363820002.7.0.633809398541.issue17500@psf.upfronthosting.co.za> Message-ID: <1464925512.02.0.339231534465.issue17500@psf.upfronthosting.co.za> Changes by Matthias Klose : ---------- nosy: +ned.deily, steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 2 23:53:38 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 03 Jun 2016 03:53:38 +0000 Subject: [issue19489] move quick search box above TOC In-Reply-To: <1383546510.68.0.587653327623.issue19489@psf.upfronthosting.co.za> Message-ID: <1464926018.4.0.50816625322.issue19489@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 00:21:51 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 03 Jun 2016 04:21:51 +0000 Subject: [issue17352] Be clear that __prepare__ must be declared as a class method In-Reply-To: <1362409892.83.0.717786566871.issue17352@psf.upfronthosting.co.za> Message-ID: <1464927711.51.0.683632961937.issue17352@psf.upfronthosting.co.za> Berker Peksag added the comment: This is a duplicate of issue 15243. ---------- nosy: +berker.peksag resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Misleading documentation for __prepare__ _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 00:22:56 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 03 Jun 2016 04:22:56 +0000 Subject: [issue15243] Misleading documentation for __prepare__ In-Reply-To: <1341328118.33.0.670602196671.issue15243@psf.upfronthosting.co.za> Message-ID: <1464927776.43.0.811029036154.issue15243@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- keywords: +easy versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 00:42:04 2016 From: report at bugs.python.org (Steve Dower) Date: Fri, 03 Jun 2016 04:42:04 +0000 Subject: [issue26876] Extend MSVCCompiler class to respect environment variables In-Reply-To: <1461866719.82.0.2605655084.issue26876@psf.upfronthosting.co.za> Message-ID: <1464928924.78.0.810115245437.issue26876@psf.upfronthosting.co.za> Steve Dower added the comment: I still want the behavior I described, since there's no value in overriding just the executable name but not the rest of the path. For 2.7 I think this'll help with long term maintainability enough to be the Right Thing. For 3.5 I'm not as sure, but it's probably worth keeping the implementations consistent as long as we can justify it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 00:53:53 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 03 Jun 2016 04:53:53 +0000 Subject: [issue11501] distutils.archive_util should handle absence of zlib module In-Reply-To: <1300119578.93.0.647722087652.issue11501@psf.upfronthosting.co.za> Message-ID: <1464929633.67.0.488599359157.issue11501@psf.upfronthosting.co.za> Berker Peksag added the comment: Tests are already skipped if zlib is not available in 2.7. To backport test_make_zipfile_no_zlib we also need the 'patch' helper so I'm not sure it's worth it at this point. ---------- nosy: +berker.peksag status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 00:56:33 2016 From: report at bugs.python.org (Jason Fried) Date: Fri, 03 Jun 2016 04:56:33 +0000 Subject: [issue27194] Tarfile superfluous truncate calls slows extraction. Message-ID: <1464929793.77.0.639155899875.issue27194@psf.upfronthosting.co.za> New submission from Jason Fried: With large tar file extracts I noticed that tarfile was slower than it should be. Seems in linux that for large files (10MB) truncate is not always a free operation even when it should be a no-op. ex: File is already 10mb seek to end and truncate. I created a script to test the validity of this patch. It generates two random tar archives containing 1024 files of 10mb each. The files are randomized so disk caching should not interfere. So to extract those 1g tar files the following was observed Time Delta for TarFile: 148.23699307441711 Time Delta for FastTarFile: 107.71058106422424 Time Diff: 40.52641201019287 0.27338932859929255 ---------- components: Library (Lib) files: truncate.patch keywords: patch messages: 267035 nosy: asvetlov, fried, lukasz.langa priority: normal severity: normal status: open title: Tarfile superfluous truncate calls slows extraction. type: performance versions: Python 3.5 Added file: http://bugs.python.org/file43138/truncate.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 00:56:48 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 04:56:48 +0000 Subject: [issue27185] Clarify Test Coverage for the String Module (test_pep292 is not easily discoverable) In-Reply-To: <1464892105.41.0.770914187896.issue27185@psf.upfronthosting.co.za> Message-ID: <1464929808.12.0.3496304341.issue27185@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is even more complex, since you can't merge a revision with its parent. A. Start at revision A. B. Rename test_string to test_string_merged, giving revision B. A. Update back to revision A. C. Rename test_pep292 to test_string_merged, giving revision C. D. Merge revisions B and C, and manually merge the contents of the two test_string_merged versions, giving revision D. E. Rename test_string_merged to test_string, giving the final revision. ---------- resolution: fixed -> stage: resolved -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 00:58:33 2016 From: report at bugs.python.org (Jason Fried) Date: Fri, 03 Jun 2016 04:58:33 +0000 Subject: [issue27194] Tarfile superfluous truncate calls slows extraction. In-Reply-To: <1464929793.77.0.639155899875.issue27194@psf.upfronthosting.co.za> Message-ID: <1464929913.08.0.954858187534.issue27194@psf.upfronthosting.co.za> Jason Fried added the comment: I ran this on Linux ext4. I didn't see much improvement on OSX with SSD. ---------- Added file: http://bugs.python.org/file43139/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 00:59:41 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 03 Jun 2016 04:59:41 +0000 Subject: [issue27195] Crash when RawIOBase.write(b) evaluates b.format Message-ID: <1464929981.41.0.2917772561.issue27195@psf.upfronthosting.co.za> New submission from Martin Panter: $ gdb --args ./python -c ' import io class R(io.RawIOBase): def writable(self): return True def write(self, b): print("About to evaluate {!r}.format".format(b)) b.format print("Never reached") b = io.BufferedWriter(R()) b.write(b"x") b.flush() ' [. . .] (gdb) run [. . .] About to evaluate .format python: Objects/stringobject.c:120: PyString_FromString: Assertion `str != NULL' failed. Program received signal SIGABRT, Aborted. 0x00007ffff71422a8 in raise () from /usr/lib/libc.so.6 (gdb) bt full #0 0x00007ffff71422a8 in raise () from /usr/lib/libc.so.6 No symbol table info available. #1 0x00007ffff714372a in abort () from /usr/lib/libc.so.6 No symbol table info available. #2 0x00007ffff713b1b7 in __assert_fail_base () from /usr/lib/libc.so.6 No symbol table info available. #3 0x00007ffff713b262 in __assert_fail () from /usr/lib/libc.so.6 No symbol table info available. #4 0x000000000046f7b8 in PyString_FromString (str=0x0) at Objects/stringobject.c:120 size = 0 op = 0x7ffff7f9d160 __PRETTY_FUNCTION__ = "PyString_FromString" #5 0x0000000000562fec in memory_format_get (self=0x7ffff6ee4380) at Objects/memoryobject.c:330 No locals. #6 0x00000000005587d5 in getset_get (descr=0x7ffff7fb93a8, obj=0x7ffff6ee4380, type=0x81da40 ) at Objects/descrobject.c:146 res = 0x7ffff7fb5580 #7 0x00000000004611e6 in _PyObject_GenericGetAttrWithDict ( obj=0x7ffff6ee4380, name=0x7ffff7f9d160, dict=0x0) at Objects/object.c:1399 tp = 0x81da40 descr = 0x7ffff7fb93a8 res = 0x0 f = 0x55876a dictoffset = 8675760 dictptr = 0xf74ab600 __PRETTY_FUNCTION__ = "_PyObject_GenericGetAttrWithDict" #8 0x000000000046164a in PyObject_GenericGetAttr (obj=0x7ffff6ee4380, name=0x7ffff7f9d160) at Objects/object.c:1461 No locals. #9 0x0000000000460ab0 in PyObject_GetAttr (v=0x7ffff6ee4380, name=0x7ffff7f9d160) at Objects/object.c:1196 tp = 0x81da40 #10 0x00000000004d0dae in PyEval_EvalFrameEx (f=0x7ffff7e31c00, throwflag=0) at Python/ceval.c:2541 [. . .] #16 0x0000000000421b0e in PyObject_CallMethodObjArgs (callable=0x7ffff7e601e0, name=0x7ffff7fc3820) at Objects/abstract.c:2751 args = 0x7ffff6cb94c0 tmp = 0x7ffff6ee4350 vargs = {{gp_offset = 24, fp_offset = 48, overflow_arg_area = 0x7fffffffddb0, reg_save_area = 0x7fffffffdcf0}} #17 0x00007ffff6a83283 in _bufferedwriter_raw_write (self=0x7ffff6ee1318, start=0x8ff710 "x", '\313' , ..., len=1) at /media/disk/home/proj/python/cpython/Modules/_io/bufferedio.c:1726 buf = {buf = 0x8ff710, obj = 0x0, len = 1, itemsize = 1, readonly = 1, ndim = 1, format = 0x0, shape = 0x7fffffffdde0, strides = 0x0, suboffsets = 0x0, smalltable = {9432288, 140737488346688}, internal = 0x0} memobj = 0x7ffff6ee4380 res = 0x7fffffffde60 n = 5605226 errnum = 0 #18 0x00007ffff6a8360d in _bufferedwriter_flush_unlocked (self=0x7ffff6ee1318) at /media/disk/home/proj/python/cpython/Modules/_io/bufferedio.c:1773 written = 0 n = 1 rewind = 0 #19 0x00007ffff6a7faf6 in buffered_flush_and_rewind_unlocked ( self=0x7ffff6ee1318) at /media/disk/home/proj/python/cpython/Modules/_io/bufferedio.c:756 res = 0x7ffff7fc8700 #20 0x00007ffff6a7fd52 in buffered_flush (self=0x7ffff6ee1318, args=0x0) at /media/disk/home/proj/python/cpython/Modules/_io/bufferedio.c:783 res = 0x7ffff6ee1318 #21 0x00000000004d824c in call_function (pp_stack=0x7fffffffe078, oparg=0) at Python/ceval.c:4334 meth = 0x7ffff6a7fc4f self = 0x7ffff6ee1318 flags = 4 tstate = 0x8461b0 na = 0 nk = 0 n = 0 pfunc = 0x7ffff7f151e8 func = 0x7ffff6cb86f0 x = 0x7ffff6ee1318 w = 0x7ffff7f151e8 [. . .] ---------- components: IO messages: 267038 nosy: martin.panter priority: normal severity: normal status: open title: Crash when RawIOBase.write(b) evaluates b.format type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 01:00:27 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 05:00:27 +0000 Subject: [issue27184] Support path objects in the ntpath module In-Reply-To: <1464917768.07.0.74753238066.issue27184@psf.upfronthosting.co.za> Message-ID: <1464930027.97.0.457887808302.issue27184@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Please don't change os.path until all other module will be changed. It may be that os.path would not need any change at all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 01:03:47 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 05:03:47 +0000 Subject: [issue27195] Crash when RawIOBase.write(b) evaluates b.format In-Reply-To: <1464929981.41.0.2917772561.issue27195@psf.upfronthosting.co.za> Message-ID: <1464930227.07.0.652138751504.issue27195@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +benjamin.peterson, pitrou, serhiy.storchaka, skrah, stutzbach _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 01:07:30 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 05:07:30 +0000 Subject: [issue27194] Tarfile superfluous truncate calls slows extraction. In-Reply-To: <1464929793.77.0.639155899875.issue27194@psf.upfronthosting.co.za> Message-ID: <1464930450.67.0.205660174313.issue27194@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +lars.gustaebel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 01:14:52 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 05:14:52 +0000 Subject: [issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects. In-Reply-To: <1384516983.26.0.0584971052865.issue19611@psf.upfronthosting.co.za> Message-ID: <1464930892.4.0.108036339412.issue19611@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I have no idea what relations Argument Clinic have with this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 01:17:12 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 03 Jun 2016 05:17:12 +0000 Subject: [issue20408] memoryview() constructor documentation error In-Reply-To: <1390823591.54.0.904712473888.issue20408@psf.upfronthosting.co.za> Message-ID: <1464931032.83.0.249228654962.issue20408@psf.upfronthosting.co.za> Berker Peksag added the comment: I think the safest solution is to change 'obj' to 'object' in memoryview documentation. ---------- assignee: -> docs at python components: +Documentation -Interpreter Core keywords: +easy nosy: +berker.peksag, docs at python stage: patch review -> needs patch versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 01:26:25 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jun 2016 05:26:25 +0000 Subject: [issue25931] os.fork() command distributed in windows Python27 (in SocketServer module) In-Reply-To: <1450840231.57.0.83917358919.issue25931@psf.upfronthosting.co.za> Message-ID: <20160603052622.5068.44079.75E6802D@psf.io> Roundup Robot added the comment: New changeset 3145242bc81f by Gregory P. Smith in branch 'default': Issue25931: fix tests broken by the conditional define of socketserver.Forking* https://hg.python.org/cpython/rev/3145242bc81f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 01:31:42 2016 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 03 Jun 2016 05:31:42 +0000 Subject: [issue27185] Clarify Test Coverage for the String Module (test_pep292 is not easily discoverable) In-Reply-To: <1464917292.69.0.61037900275.issue27185@psf.upfronthosting.co.za> Message-ID: <1464931899.2472782.626653321.3D41C695@webmail.messagingengine.com> Benjamin Peterson added the comment: On Thu, Jun 2, 2016, at 18:28, Martin Panter wrote: > > Martin Panter added the comment: > > FWIW I doubt Git is any better at this than Mercurial: > > > Git can automatically pick up file renames and copies when analysing the > history, but has no special metadata for this. I understand Mercurial is > the opposite (has metadata, but at least by default does not pick up > copies and renames from the history). Perhaps that is what Benjamin was > thinking of. I understand Git will only pick up movements of the majority > of a file, not parts of files (unless something has changed recently). git blame -C works quite well in my experience for detecting moved lines of code. In general, I think we shouldn't be afraid to reorganize code for fear of breaking "VCS" history. The tools will catch up. (I think they largely have already.) At worst, one must manually "follow" the move of some code through history. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 01:34:05 2016 From: report at bugs.python.org (Ned Deily) Date: Fri, 03 Jun 2016 05:34:05 +0000 Subject: [issue27192] Keyboard Shortcuts Consistently Cause Crashes In-Reply-To: <1464921883.27.0.409167298484.issue27192@psf.upfronthosting.co.za> Message-ID: <1464932045.05.0.966372982485.issue27192@psf.upfronthosting.co.za> Ned Deily added the comment: You are almost certainly seeing a crash due to a critical bug in the Apple-supplied version of Tk 8.5 on OS X systems up through at least OS X 10.11. See here for more information: https://www.python.org/download/mac/tcltk/#apple-8-5-9. The solution is to use a Python that links with a more, up-to-date third-party version of Tcl and Tk, such as Pythons from python.org OS X installers and current versions of ActiveTcl from ActiveState: https://www.python.org/download/mac/tcltk/ ---------- resolution: duplicate -> third party superseder: Tkinter Unresponsive With Special Keys -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 01:37:55 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 03 Jun 2016 05:37:55 +0000 Subject: [issue25931] os.fork() command distributed in windows Python27 (in SocketServer module) In-Reply-To: <1450840231.57.0.83917358919.issue25931@psf.upfronthosting.co.za> Message-ID: <1464932275.52.0.682262378486.issue25931@psf.upfronthosting.co.za> Gregory P. Smith added the comment: It may be worth rolling back the above two commits. I'm not sure. I'd like to see if anything else falls out of this during the beta phases. There is a chance that some library has code similar to that found in test_socketserver.py that defines classes that inherit from the Forking type(s) but which are conditionally never used on Windows. The above commit would break that. I'm not sure how common that'll be. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 01:42:25 2016 From: report at bugs.python.org (Ned Deily) Date: Fri, 03 Jun 2016 05:42:25 +0000 Subject: [issue27193] Tkinter Unresponsive With Special Keys In-Reply-To: <1464922022.89.0.541400741468.issue27193@psf.upfronthosting.co.za> Message-ID: <1464932545.13.0.863588255402.issue27193@psf.upfronthosting.co.za> Ned Deily added the comment: Tkinter is essentially just a think wrapper around the Tk graphical toolkit. Keyboard modifier mappings are handled by Tk (or OS X), and not Tkinter. Unfortunately, for various reasons, how Tk handles keyboard modifiers varies somewhat among OS platforms (Windows-native, X11-based, and OS X-native) and even between versions of Tk on the same platform. One source for more detailed information about modifier key differences is the following Tk wiki page: http://wiki.tcl.tk/28331 ---------- resolution: -> third party stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 01:43:10 2016 From: report at bugs.python.org (Eryk Sun) Date: Fri, 03 Jun 2016 05:43:10 +0000 Subject: [issue27184] Support path objects in the ntpath module In-Reply-To: <1464917768.07.0.74753238066.issue27184@psf.upfronthosting.co.za> Message-ID: <1464932590.19.0.860958722458.issue27184@psf.upfronthosting.co.za> Eryk Sun added the comment: Sorry, I must have missed or misunderstood something. PEP 519 discusses modifying os.path. For the os module it only discusses adding fspath and updating fsencode and fsdecode. It also discusses a new PyOS_FSPath C API, but without any discussion regarding its use in the implementation of the posix / nt module, or regarding what built-in os functions should support __fspath__. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 01:45:08 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jun 2016 05:45:08 +0000 Subject: [issue25931] os.fork() command distributed in windows Python27 (in SocketServer module) In-Reply-To: <1450840231.57.0.83917358919.issue25931@psf.upfronthosting.co.za> Message-ID: <20160603054505.5454.93988.B6BF7637@psf.io> Roundup Robot added the comment: New changeset 015b86646d8e by Gregory P. Smith in branch 'default': issue25931: document that socketserver.Forking* are unavailable on platforms https://hg.python.org/cpython/rev/015b86646d8e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 01:48:37 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jun 2016 05:48:37 +0000 Subject: [issue25931] os.fork() command distributed in windows Python27 (in SocketServer module) In-Reply-To: <1450840231.57.0.83917358919.issue25931@psf.upfronthosting.co.za> Message-ID: <20160603054832.88921.17483.14C3E500@psf.io> Roundup Robot added the comment: New changeset a4c0208b10df by Gregory P. Smith in branch '2.7': issue25931: document that socketserver.Forking* are unavailable on platforms https://hg.python.org/cpython/rev/a4c0208b10df ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 01:54:53 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Jun 2016 05:54:53 +0000 Subject: [issue25747] test_idle failure in leaks searching mode In-Reply-To: <1448647986.99.0.712792565134.issue25747@psf.upfronthosting.co.za> Message-ID: <1464933293.74.0.447791755776.issue25747@psf.upfronthosting.co.za> Terry J. Reedy added the comment: idlever.py is now gone in 3.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 01:56:57 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 03 Jun 2016 05:56:57 +0000 Subject: [issue25931] os.fork() command distributed in windows Python27 (in SocketServer module) In-Reply-To: <1450840231.57.0.83917358919.issue25931@psf.upfronthosting.co.za> Message-ID: <1464933417.49.0.782188671434.issue25931@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- resolution: -> fixed stage: needs patch -> commit review status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 02:00:58 2016 From: report at bugs.python.org (Ram Rachum) Date: Fri, 03 Jun 2016 06:00:58 +0000 Subject: [issue27181] Add geometric mean to `statistics` module In-Reply-To: <1464901494.08.0.0111988914026.issue27181@psf.upfronthosting.co.za> Message-ID: <1464933658.74.0.28153021882.issue27181@psf.upfronthosting.co.za> Ram Rachum added the comment: To complicate things further... I implemented a geometric mean on my own, and then I figured out what I really want is a *weighted* geometric mean, so I implemented that for myself. If you'd want to include that, that'll be cool. Actually I'm not sure if the goal of the `statistics` module is to be comprehensive or minimal. I'm hoping it's meant to be comprehensive. But then I'd guess there would be a lot of things you'd want to add except my little feature. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 02:05:37 2016 From: report at bugs.python.org (SilentGhost) Date: Fri, 03 Jun 2016 06:05:37 +0000 Subject: [issue2466] os.path.ismount doesn't work for mounts the user doesn't have permission to see In-Reply-To: <1206293428.96.0.660613140218.issue2466@psf.upfronthosting.co.za> Message-ID: <1464933937.55.0.622853177783.issue2466@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- stage: patch review -> commit review versions: -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 02:14:25 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jun 2016 06:14:25 +0000 Subject: [issue27167] subprocess reports signal as negative exit status, not documented In-Reply-To: <1464712500.44.0.979958949461.issue27167@psf.upfronthosting.co.za> Message-ID: <20160603061417.91000.8623.AAF1C537@psf.io> Roundup Robot added the comment: New changeset f2d13349ea5d by Gregory P. Smith in branch 'default': Issue #27167: Clarify the subprocess.CalledProcessError error message text https://hg.python.org/cpython/rev/f2d13349ea5d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 02:17:26 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Jun 2016 06:17:26 +0000 Subject: [issue26885] Add parsing support for more types in xmlrpc In-Reply-To: <1461943983.79.0.576979457392.issue26885@psf.upfronthosting.co.za> Message-ID: <1464934646.51.0.0750233739559.issue26885@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Table: I believe the format is that the second column describes Pyhton objects that can be marshalled into xml for the rpc. Sometimes a note is added about the 'return' type, which I presume is the Python object unmarshalled from xml. From this standpoint, ":class:`int` in range from -2147483648 to 2147483647." is correct, as well as clearer than the replacement. I presume 'tags' are in the xml. "Tag' is meaningless for the returned Python objects. To me "Values get the ```` tag." is more grammatical and at least as clear. --- +The module now supports unmarshalling additional data types used by +Apache XML-RPC implementation for numerics and ``None``. The following is clearer to me, although I am puzzled as the table entry for 'nil' in unchanged. +The module now supports unmarshalling ``None`` and additional data +types used by Apache XML-RPC implementation for numerics. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 02:19:31 2016 From: report at bugs.python.org (Robin Roth) Date: Fri, 03 Jun 2016 06:19:31 +0000 Subject: [issue2466] os.path.ismount doesn't work for mounts the user doesn't have permission to see In-Reply-To: <1206293428.96.0.660613140218.issue2466@psf.upfronthosting.co.za> Message-ID: <1464934771.19.0.92947005894.issue2466@psf.upfronthosting.co.za> Robin Roth added the comment: Based on the review by SilentGhost I removed all refactoring-changes and only left the one line needed for the fix. ---------- Added file: http://bugs.python.org/file43140/minimal_fix_ismount_directory_not_readable.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 02:19:47 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jun 2016 06:19:47 +0000 Subject: [issue27167] subprocess reports signal as negative exit status, not documented In-Reply-To: <1464712500.44.0.979958949461.issue27167@psf.upfronthosting.co.za> Message-ID: <20160603061942.14552.44279.0DE72902@psf.io> Roundup Robot added the comment: New changeset 1022d09d11e5 by Gregory P. Smith in branch 'default': issue27167: make the test not care about the exact signal name in the https://hg.python.org/cpython/rev/1022d09d11e5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 02:24:51 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 03 Jun 2016 06:24:51 +0000 Subject: [issue27167] subprocess reports signal as negative exit status, not documented In-Reply-To: <1464712500.44.0.979958949461.issue27167@psf.upfronthosting.co.za> Message-ID: <1464935091.68.0.509341567194.issue27167@psf.upfronthosting.co.za> Gregory P. Smith added the comment: So this is mostly done... one oddity which may warrant improvement though: signal numbers have multiple names. ie: SIGABRT is also known as SIGIOT, etc. This is likely to be confusing to if the error message is surfaced to the user as most users only know one common name rather than all of them as described in their system headers or the signal(7) man page. I'd rather Python not be in the business of picking which name is more popular, but it can generate different error messages for the same signal across repeated runs due to hash randomization changing the order of the map in the signal.Signals type. run python3.5 -c 'import signal; print(signal.Signals(6))' a handful of times to see this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 02:25:16 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 03 Jun 2016 06:25:16 +0000 Subject: [issue27167] subprocess reports signal as negative exit status, not documented In-Reply-To: <1464712500.44.0.979958949461.issue27167@psf.upfronthosting.co.za> Message-ID: <1464935116.16.0.128613476672.issue27167@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 02:25:53 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 03 Jun 2016 06:25:53 +0000 Subject: [issue20699] Document that binary IO classes work with bytes-likes objects In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za> Message-ID: <1464935153.01.0.266596922354.issue20699@psf.upfronthosting.co.za> Martin Panter added the comment: I agree with avoiding the term ?bytes-like object? in 2.7. It is easy to be specific when talking about concrete classes like BufferedWriter and BytesIO. But the harder question is what to specify for the abstract base classes. In patch v8, I propose to change the documentation to refer to ?sequences of bytes which are usable with ?memoryview? ?. Technically, some of the _pyio implementations assume more than this (e.g. len(), iteration and slice assignment), but I have left them alone. ---------- Added file: http://bugs.python.org/file43141/bytes-like-param.py2.v8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 02:39:21 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jun 2016 06:39:21 +0000 Subject: [issue27185] Clarify Test Coverage for the String Module (test_pep292 is not easily discoverable) In-Reply-To: <1464892105.41.0.770914187896.issue27185@psf.upfronthosting.co.za> Message-ID: <20160603063918.24447.74964.ADA6714A@psf.io> Roundup Robot added the comment: New changeset 27f5eb630499 by Serhiy Storchaka in branch '2.7': Issue #27185: Rename test_string.py to test_string_merged.py. https://hg.python.org/cpython/rev/27f5eb630499 New changeset 8218b1309178 by Serhiy Storchaka in branch '2.7': Issue #27185: Rename test_pep292.py to test_string_merged.py. https://hg.python.org/cpython/rev/8218b1309178 New changeset 7dac80e0dd5e by Serhiy Storchaka in branch '2.7': Issue #27185: Merge test_pep292.py into test_string_merged.py. https://hg.python.org/cpython/rev/7dac80e0dd5e New changeset e2e309fb2b1e by Serhiy Storchaka in branch '2.7': Issue #27185: Rename test_string_merged.py back to test_string.py. https://hg.python.org/cpython/rev/e2e309fb2b1e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 02:41:54 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Jun 2016 06:41:54 +0000 Subject: [issue5150] IDLE to support reindent.py In-Reply-To: <1233736664.4.0.115705275626.issue5150@psf.upfronthosting.co.za> Message-ID: <1464936114.9.0.240103232624.issue5150@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Having occasionally forgotten, and had to do whitespace commits, I agree. For Python code, there is never an absolute need for trailing whitespace. Trailing whitespace in string literals can be done by parse time concatenation. '''\ line 1 line 2 ''' 'line with trailig space ' Indeed, the trick is needed to mark the trailing space in the code. I have thought about removing trailing spaces after each return, but pasting may be a problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 02:47:52 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 06:47:52 +0000 Subject: [issue27185] Clarify Test Coverage for the String Module (test_pep292 is not easily discoverable) In-Reply-To: <1464892105.41.0.770914187896.issue27185@psf.upfronthosting.co.za> Message-ID: <1464936472.84.0.611057204678.issue27185@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Merged test_pep292.py into test_string.py with preserving the history in 2.7. This required following steps: hg mv Lib/test/test_string.py Lib/test/test_string_merged.py hg commit hg update -C -r -2 hg mv Lib/test/test_pep292.py Lib/test/test_string_merged.py hg commit hg update -C -r -2 hg merge # Manually merge the content of former test_string.py and test_pep292.py. hg commit hg mv Lib/test/test_string_merged.py Lib/test/test_string.py hg commit hg push We now should restore deleted test_pep292.py (is it possible with the history?) and repeat above steps in 3.x. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 02:50:17 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jun 2016 06:50:17 +0000 Subject: [issue8519] doc: termios and ioctl reference links In-Reply-To: <1272125391.54.0.0119716465224.issue8519@psf.upfronthosting.co.za> Message-ID: <20160603065007.38660.31374.0428488F@psf.io> Roundup Robot added the comment: New changeset f53a0566a290 by Senthil Kumaran in branch '3.5': issue8519 - Reference termios and ioctl manual pages in the library documentation. https://hg.python.org/cpython/rev/f53a0566a290 New changeset 8db146bec24b by Senthil Kumaran in branch 'default': [merge from 3.5] - issue8519 - Reference termios and ioctl manual pages in the library documentation. https://hg.python.org/cpython/rev/8db146bec24b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 02:51:29 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jun 2016 06:51:29 +0000 Subject: [issue8519] doc: termios and ioctl reference links In-Reply-To: <1272125391.54.0.0119716465224.issue8519@psf.upfronthosting.co.za> Message-ID: <20160603065126.14605.39027.AD1ED4D8@psf.io> Roundup Robot added the comment: New changeset 55886a6aed4b by Senthil Kumaran in branch '2.7': [backport to 2.7] - issue8519 - Reference termios and ioctl manual pages in the library documentation. https://hg.python.org/cpython/rev/55886a6aed4b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 02:52:37 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 03 Jun 2016 06:52:37 +0000 Subject: [issue8519] doc: termios and ioctl reference links In-Reply-To: <1272125391.54.0.0119716465224.issue8519@psf.upfronthosting.co.za> Message-ID: <1464936757.16.0.637140263312.issue8519@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Thanks Angad and Anatoly for the patches discussions. Thank you Berker for review. Made the changes in all active versions of python. Let this issue reset in peace. ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 02:58:48 2016 From: report at bugs.python.org (Russell Keith-Magee) Date: Fri, 03 Jun 2016 06:58:48 +0000 Subject: [issue23670] Modifications to support iOS as a cross-compilation target In-Reply-To: <1426400747.11.0.0527548590348.issue23670@psf.upfronthosting.co.za> Message-ID: <1464937128.22.0.422937925121.issue23670@psf.upfronthosting.co.za> Russell Keith-Magee added the comment: Yes - I'm aware of Pythonista; the author of that app contracted me to develop the 3.5 patch that is attached to this ticket :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 03:00:02 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 03 Jun 2016 07:00:02 +0000 Subject: [issue27113] sqlite3 connect parameter "check_same_thread" not documented In-Reply-To: <1464125789.84.0.570004715823.issue27113@psf.upfronthosting.co.za> Message-ID: <1464937202.2.0.955413093163.issue27113@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Thanks for the explanation, Dave. Completely agree with those points. Let's go ahead with the latest patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 03:04:36 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jun 2016 07:04:36 +0000 Subject: [issue27113] sqlite3 connect parameter "check_same_thread" not documented In-Reply-To: <1464125789.84.0.570004715823.issue27113@psf.upfronthosting.co.za> Message-ID: <20160603070432.24155.48862.CD1A13A2@psf.io> Roundup Robot added the comment: New changeset af1752e51a89 by Senthil Kumaran in branch '3.5': issue27113 - Document "check_same_thread" parameter in sqlite3.connect api. https://hg.python.org/cpython/rev/af1752e51a89 New changeset 17c8da643065 by Senthil Kumaran in branch 'default': [merge from 3.5] - issue27113 - Document "check_same_thread" parameter in sqlite3.connect api. https://hg.python.org/cpython/rev/17c8da643065 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 03:05:05 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 03 Jun 2016 07:05:05 +0000 Subject: [issue27113] sqlite3 connect parameter "check_same_thread" not documented In-Reply-To: <1464125789.84.0.570004715823.issue27113@psf.upfronthosting.co.za> Message-ID: <1464937505.87.0.61217199989.issue27113@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Thanks for your contribution. It's now documented. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 03:14:31 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 03 Jun 2016 07:14:31 +0000 Subject: [issue15476] Index "code object" and link to code object definition In-Reply-To: <1343459471.56.0.370073010984.issue15476@psf.upfronthosting.co.za> Message-ID: <1464938071.58.0.193791125671.issue15476@psf.upfronthosting.co.za> Martin Panter added the comment: I left some minor review suggestions. But a more serious problem is that the change to Doc/reference/datamodel.rst breaks the formatting for me. Instead of a HTML
, I get a

followed by a

. Unfortunately I don?t know of a way to get index entries to point to the definition list heading without breaking up a definition list like this. IMO having entries under both ?code object? and ?code? is redundant, but I see that is debatable. :) If I was looking this up, I would probably look at ?code? first. If it wasn?t there, I might even miss a separate ?code object? entry, considering there is also a second ?code (. . .)? entry as well. ---------- nosy: +martin.panter versions: +Python 2.7, Python 3.5, Python 3.6 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 03:18:49 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 07:18:49 +0000 Subject: [issue20699] Document that binary IO classes work with bytes-likes objects In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za> Message-ID: <1464938329.26.0.923562956212.issue20699@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Since the _pyio implementation doesn't support general memoryview-like objects, I consider using the new buffer protocol in the C implementation an implementation detail. Other implementations can lack this support. I think it would be better to left the wording more general ("preallocated writable array of bytes"), but mention other concrete example (array('b'), are there other examples in the stdlib?). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 03:22:37 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 07:22:37 +0000 Subject: [issue16182] readline: Wrong tab completion scope indices in Unicode terminals In-Reply-To: <1349813384.06.0.615857426211.issue16182@psf.upfronthosting.co.za> Message-ID: <1464938557.42.0.429715430082.issue16182@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your comments and updated patches, and especially for tests Martin. Added some comments on Rietveld. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 03:23:44 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 03 Jun 2016 07:23:44 +0000 Subject: [issue27185] Clarify Test Coverage for the String Module (test_pep292 is not easily discoverable) In-Reply-To: <1464892105.41.0.770914187896.issue27185@psf.upfronthosting.co.za> Message-ID: <1464938624.87.0.586153414626.issue27185@psf.upfronthosting.co.za> Martin Panter added the comment: IMO I wouldn?t bother. David has already done the change a different way, which is simpler to understand commit-by-commit, even if it messes with the Mercurial annotate history. FWIW I guess you could do a similar merge with an old version to restore the deleted file though. ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 03:46:51 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 03 Jun 2016 07:46:51 +0000 Subject: [issue20699] Document that binary IO classes work with bytes-likes objects In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za> Message-ID: <1464940011.11.0.454292635742.issue20699@psf.upfronthosting.co.za> Martin Panter added the comment: Actually this bug report was opened because an implementation that lacked memoryview support was broken by 2.7. The point is to document that (a subset of) memoryview objects may be passed to custom implementations. Does this need a ?changed in 2.7? notice? I am not so familiar with the history of Python 2 or the various buffer APIs to be sure. Also see , where I discovered array('b') does not work with io.BytesIO.write(). It seems you have to wrap it in buffer() first, presumably because array() does not support the ?new? protocol, but buffer() does. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 03:49:08 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jun 2016 07:49:08 +0000 Subject: [issue27185] Clarify Test Coverage for the String Module (test_pep292 is not easily discoverable) In-Reply-To: <1464892105.41.0.770914187896.issue27185@psf.upfronthosting.co.za> Message-ID: <20160603074904.5147.46434.B99B50C0@psf.io> Roundup Robot added the comment: New changeset 70e19b014d2f by Serhiy Storchaka in branch '3.5': Issue #27185: Rename test_string.py to test_string_merged.py. https://hg.python.org/cpython/rev/70e19b014d2f New changeset 0da07e73451d by Serhiy Storchaka in branch '3.5': Issue #27185: Rename test_pep292.py to test_string_merged.py. https://hg.python.org/cpython/rev/0da07e73451d New changeset 14a036c696e8 by Serhiy Storchaka in branch '3.5': Issue #27185: Merge test_pep292.py into test_string_merged.py. https://hg.python.org/cpython/rev/14a036c696e8 New changeset 36f5229e45a6 by Serhiy Storchaka in branch '3.5': Issue #27185: Rename test_string_merged.py back to test_string.py. https://hg.python.org/cpython/rev/36f5229e45a6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 03:51:14 2016 From: report at bugs.python.org (Alecsandru Patrascu) Date: Fri, 03 Jun 2016 07:51:14 +0000 Subject: [issue26359] CPython build options for out-of-the box performance In-Reply-To: <1455445693.01.0.984013993837.issue26359@psf.upfronthosting.co.za> Message-ID: <1464940274.05.0.554258709542.issue26359@psf.upfronthosting.co.za> Alecsandru Patrascu added the comment: I've updated the patch for 2.7 branch to contain the LTO part merged by Gregory. ---------- Added file: http://bugs.python.org/file43142/cpython2_with_optimizations_v02.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 03:52:04 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 07:52:04 +0000 Subject: [issue27185] Clarify Test Coverage for the String Module (test_pep292 is not easily discoverable) In-Reply-To: <1464892105.41.0.770914187896.issue27185@psf.upfronthosting.co.za> Message-ID: <1464940324.5.0.212941173318.issue27185@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Now the history is restored. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 03:54:42 2016 From: report at bugs.python.org (Alecsandru Patrascu) Date: Fri, 03 Jun 2016 07:54:42 +0000 Subject: [issue26359] CPython build options for out-of-the box performance In-Reply-To: <1455445693.01.0.984013993837.issue26359@psf.upfronthosting.co.za> Message-ID: <1464940482.02.0.875048171181.issue26359@psf.upfronthosting.co.za> Alecsandru Patrascu added the comment: The patches in discussions are the v02 ones. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 03:59:36 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Jun 2016 07:59:36 +0000 Subject: [issue24759] Idle: require tk 8.5 and ttk widgets, and drop unneeded code. In-Reply-To: <1438294715.65.0.966229055462.issue24759@psf.upfronthosting.co.za> Message-ID: <1464940776.52.0.593420325425.issue24759@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Given what Serhiy said, the core of this patch is the original patch with a test of TkVersion instead of importing ttk. Code that only ran for 8.4- is removed. Some minimal new tests are added, and I may add some more. None of the changes should depend on OS. I want to apply this in a few days as it is a prerequisite for ttk patches. ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 04:00:07 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Jun 2016 08:00:07 +0000 Subject: [issue27196] Eliminate 'ThemeChanged' warning when running IDLE tests Message-ID: <1464940807.02.0.170350027457.issue27196@psf.upfronthosting.co.za> New submission from Terry J. Reedy: When running "python_d.exe -m test_idle from console or when running test file from IDLE after starting it in either console or by import, the following sometimes appears. can't invoke "event" command: application has been destroyed while executing "event generate $w <>" (procedure "ttk::ThemeChanged" line 6) invoked from within "ttk::ThemeChanged" Serhiy, this is pobably not critical, but it is annoying. Perhaps the 'kill-callbacks' patch would fix this. Still, I try to have IDLE tests cleanup properly. Known repeatable occurrences: * test_configdialog.ConfigDialogTest.test_dialog, when run from IDLE after import, but not when part of suite. * test_replace.ReplaceDialogTest.test_default_command, 3 times, when run as part suite, but not when run from IDLE after import. ---------- components: IDLE, Tkinter messages: 267078 nosy: serhiy.storchaka, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Eliminate 'ThemeChanged' warning when running IDLE tests type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 04:09:47 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 08:09:47 +0000 Subject: [issue20699] Document that binary IO classes work with bytes-likes objects In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za> Message-ID: <1464941387.04.0.895630960918.issue20699@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: array is supported explicitly in the Python implementation of readinto(). What if write not "usable with memoryview", but mention memoryview as an example? The object *b* should be a pre-allocated, writable array of bytes, such as :class:`bytearray`, :class:`array.array` or :class:`memoryview`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 04:12:20 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 08:12:20 +0000 Subject: [issue24759] Idle: require tk 8.5 and ttk widgets, and drop unneeded code. In-Reply-To: <1438294715.65.0.966229055462.issue24759@psf.upfronthosting.co.za> Message-ID: <1464941540.53.0.19075118147.issue24759@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Do you forgot to attach a patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 04:14:30 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 08:14:30 +0000 Subject: [issue27196] Eliminate 'ThemeChanged' warning when running IDLE tests In-Reply-To: <1464940807.02.0.170350027457.issue27196@psf.upfronthosting.co.za> Message-ID: <1464941670.25.0.87991852565.issue27196@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This looks as a duplicate of issue20567. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 04:54:31 2016 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 03 Jun 2016 08:54:31 +0000 Subject: [issue19489] move quick search box above TOC In-Reply-To: <1383546510.68.0.587653327623.issue19489@psf.upfronthosting.co.za> Message-ID: <1464944071.78.0.108977638809.issue19489@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 04:54:58 2016 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 03 Jun 2016 08:54:58 +0000 Subject: [issue15243] Misleading documentation for __prepare__ In-Reply-To: <1341328118.33.0.670602196671.issue15243@psf.upfronthosting.co.za> Message-ID: <1464944098.22.0.780295344311.issue15243@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 04:55:49 2016 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 03 Jun 2016 08:55:49 +0000 Subject: [issue20408] memoryview() constructor documentation error In-Reply-To: <1390823591.54.0.904712473888.issue20408@psf.upfronthosting.co.za> Message-ID: <1464944149.46.0.800975052345.issue20408@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 05:10:13 2016 From: report at bugs.python.org (Stefan Krah) Date: Fri, 03 Jun 2016 09:10:13 +0000 Subject: [issue20408] memoryview() constructor documentation error In-Reply-To: <1390823591.54.0.904712473888.issue20408@psf.upfronthosting.co.za> Message-ID: <1464945013.0.0.379018179679.issue20408@psf.upfronthosting.co.za> Stefan Krah added the comment: Or pretend in the documentation that it's a positional arg and make it one later. There is a slight performance difference. I agree with Damien that probably no one uses the keyword arg. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 05:11:04 2016 From: report at bugs.python.org (Stefan Krah) Date: Fri, 03 Jun 2016 09:11:04 +0000 Subject: [issue20408] memoryview() constructor documentation error In-Reply-To: <1390823591.54.0.904712473888.issue20408@psf.upfronthosting.co.za> Message-ID: <1464945064.78.0.684730761622.issue20408@psf.upfronthosting.co.za> Stefan Krah added the comment: Sorry, I meant *Demian*. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 05:59:13 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 03 Jun 2016 09:59:13 +0000 Subject: [issue20699] Document that binary IO classes work with bytes-likes objects In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za> Message-ID: <1464947953.07.0.919133525553.issue20699@psf.upfronthosting.co.za> Martin Panter added the comment: I don?t see the point of mentioning array() objects at all. It?s hard to support array in a Python 2 implementation, as demonstrated by readinto(). And the special support for array('b') won?t help if you pass in array('B') with values 128?255. I see this as an implementation detail of _pyio, rather than a need for others to follow its lead. The array('b') code was added by r56225. I guess it is experimental code from an early phase of the io module. Also, test_array_writes() is disabled for _pyio in 2.7 (https://hg.python.org/cpython/diff/760a710eb6c1/Lib/test/test_io.py), and in 2.6 (http://svn.python.org/view/python/branches/trunk-bytearray/Lib/test/test_io.py?r1=61775&r2=61774&pathrev=61775&view=patch). I think it is better to avoid ?such as? and be specific about what has to be supported. Perhaps: readinto(b): The object *b* should be a pre-allocated, writable array of bytes, either :class:`bytearray` or :class:`memoryview`. .. versionchanged:: 2.7 Support for :class:`memoryview`. write(b): The object *b* should be an array of bytes, either :class:`str`, :class:`bytearray`, or :class:`memoryview`. .. versionchanged:: 2.7 Support for :class:`memoryview`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 06:06:09 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 10:06:09 +0000 Subject: [issue2466] os.path.ismount doesn't work for mounts the user doesn't have permission to see In-Reply-To: <1206293428.96.0.660613140218.issue2466@psf.upfronthosting.co.za> Message-ID: <1464948369.16.0.0152433519176.issue2466@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What if use os.stat(dirname(path)) instead of os.lstat(parent)? - if isinstance(path, bytes): - parent = join(path, b'..') - else: - parent = join(path, '..') try: - s2 = os.lstat(parent) + s2 = os.stat(dirname(path)) except OSError: return False ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 06:10:01 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 10:10:01 +0000 Subject: [issue20699] Document that binary IO classes work with bytes-likes objects In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za> Message-ID: <1464948601.13.0.667999090206.issue20699@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Why :class:`str` and not :class:`bytes`? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 06:15:54 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 03 Jun 2016 10:15:54 +0000 Subject: [issue20699] Document that binary IO classes work with bytes-likes objects In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za> Message-ID: <1464948954.07.0.53381204945.issue20699@psf.upfronthosting.co.za> Martin Panter added the comment: I thought :class:`str` is better documented in Python 2, but I can write bytes if you prefer. I guess it is more consistent with the rest of io.rst. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 06:35:24 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 10:35:24 +0000 Subject: [issue20699] Document that binary IO classes work with bytes-likes objects In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za> Message-ID: <1464950124.8.0.0916049703055.issue20699@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Current docs use "bytes or bytearray object" (without references). "bytes" is just an alias to "str" in 2.7, but I prefer to use this name, for consistency with 3.x and for accenting the binary nature of the data. Your new wording LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 06:41:23 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 10:41:23 +0000 Subject: [issue2466] os.path.ismount doesn't work for mounts the user doesn't have permission to see In-Reply-To: <1206293428.96.0.660613140218.issue2466@psf.upfronthosting.co.za> Message-ID: <1464950483.86.0.946274225109.issue2466@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ah, forget, this doesn't work with path like "./.". Agreed, using realpath() is the simplest solution. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 07:16:25 2016 From: report at bugs.python.org (Eryk Sun) Date: Fri, 03 Jun 2016 11:16:25 +0000 Subject: [issue27179] subprocess uses wrong encoding on Windows In-Reply-To: <1464828766.51.0.809606583575.issue27179@psf.upfronthosting.co.za> Message-ID: <1464952585.92.0.788765598316.issue27179@psf.upfronthosting.co.za> Eryk Sun added the comment: > I would say almost all Windows console programs does use > console's encoding for input/output because otherwise > user wouldn't be able to read it. While some programs do use the console codepage, even when writing to a pipe or disk file -- such as more.com, reg.exe and tasklist.exe -- it's no where near "all Windows console programs". As a counterexample, here's a list of Microsoft utilities that always use the OEM codepage (CP_OEMCP) when writing to a pipe or disk file: attrib.exe cacls.exe doskey.exe (e.g /history) fc.exe findstr.exe (calls SetFileApisToOEM) hostname.exe icacls.exe net.exe qprocess.exe (also to console) quser.exe (also to console) sc.exe sort.exe (also to console) tree.com To further ensure that we're on the same page, the following demonstrates what happens for creation flags DETACHED_PROCESS, CREATE_NEW_CONSOLE, and CREATE_NO_WINDOW in Windows 10: from subprocess import * DETACHED_PROCESS = 0x00000008 CREATE_NEW_CONSOLE = 0x00000010 CREATE_NO_WINDOW = 0x08000000 cmd = ('python -c "import ctypes;' "kernel32 = ctypes.WinDLL('kernel32');" 'print(kernel32.GetConsoleCP())"') >>> call('chcp.com 65001') Active code page: 65001 0 >>> check_output(cmd, creationflags=0) b'65001\r\n' >>> check_output(cmd, creationflags=DETACHED_PROCESS) b'0\r\n' >>> check_output(cmd, creationflags=CREATE_NEW_CONSOLE) b'437\r\n' >>> check_output(cmd, creationflags=CREATE_NO_WINDOW) b'437\r\n' The test was run with a U.S. locale, so the OEM and ANSI codepages are 437 and 1252. With DETACHED_PROCESS there's no console, so GetConsoleCP() returns 0. That's the value of CP_ACP, so ANSI is the natural default for a detached process. CREATE_NEW_CONSOLE and CREATE_NO_WINDOW cause Windows to load a new instance of conhost.exe, which is initially set to the OEM codepage. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 07:28:23 2016 From: report at bugs.python.org (Eryk Sun) Date: Fri, 03 Jun 2016 11:28:23 +0000 Subject: [issue27179] subprocess uses wrong encoding on Windows In-Reply-To: <1464828766.51.0.809606583575.issue27179@psf.upfronthosting.co.za> Message-ID: <1464953303.17.0.374416790918.issue27179@psf.upfronthosting.co.za> Changes by Eryk Sun : ---------- Removed message: http://bugs.python.org/msg267090 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 07:28:43 2016 From: report at bugs.python.org (Eryk Sun) Date: Fri, 03 Jun 2016 11:28:43 +0000 Subject: [issue27179] subprocess uses wrong encoding on Windows In-Reply-To: <1464828766.51.0.809606583575.issue27179@psf.upfronthosting.co.za> Message-ID: <1464953323.36.0.516715156839.issue27179@psf.upfronthosting.co.za> Eryk Sun added the comment: > I would say almost all Windows console programs does use > console's encoding for input/output because otherwise > user wouldn't be able to read it. While some programs do use the console codepage, even when writing to a pipe or disk file -- such as more.com, reg.exe and tasklist.exe -- it's no where near "all Windows console programs". As a counterexample, here's a list of Microsoft utilities that always use the OEM codepage (CP_OEMCP) when writing to a pipe or disk file: attrib.exe cacls.exe doskey.exe (e.g /history) fc.exe findstr.exe (calls SetFileApisToOEM) hostname.exe icacls.exe net.exe qprocess.exe (also to console) quser.exe (also to console) sc.exe tree.com To further ensure that we're on the same page, the following demonstrates what happens for creation flags DETACHED_PROCESS, CREATE_NEW_CONSOLE, and CREATE_NO_WINDOW in Windows 10: from subprocess import * DETACHED_PROCESS = 0x00000008 CREATE_NEW_CONSOLE = 0x00000010 CREATE_NO_WINDOW = 0x08000000 cmd = ('python -c "import ctypes;' "kernel32 = ctypes.WinDLL('kernel32');" 'print(kernel32.GetConsoleCP())"') >>> call('chcp.com 65001') Active code page: 65001 0 >>> check_output(cmd, creationflags=0) b'65001\r\n' >>> check_output(cmd, creationflags=DETACHED_PROCESS) b'0\r\n' >>> check_output(cmd, creationflags=CREATE_NEW_CONSOLE) b'437\r\n' >>> check_output(cmd, creationflags=CREATE_NO_WINDOW) b'437\r\n' The test was run with a U.S. locale, so the OEM and ANSI codepages are 437 and 1252. With DETACHED_PROCESS there's no console, so GetConsoleCP() returns 0. That's the value of CP_ACP, so ANSI is the natural default for a detached process. CREATE_NEW_CONSOLE and CREATE_NO_WINDOW cause Windows to load a new instance of conhost.exe, which is initially set to the OEM codepage. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 07:37:00 2016 From: report at bugs.python.org (Luke Taylor) Date: Fri, 03 Jun 2016 11:37:00 +0000 Subject: [issue23670] Modifications to support iOS as a cross-compilation target In-Reply-To: Message-ID: Luke Taylor added the comment: Ok, great! On Fri, Jun 3, 2016 at 7:34 AM Luke Taylor wrote: > Ah, cool! > On Fri, Jun 3, 2016 at 2:58 AM Russell Keith-Magee > wrote: > >> >> Russell Keith-Magee added the comment: >> >> Yes - I'm aware of Pythonista; the author of that app contracted me to >> develop the 3.5 patch that is attached to this ticket :-) >> >> ---------- >> >> _______________________________________ >> Python tracker >> >> _______________________________________ >> > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 08:06:15 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 12:06:15 +0000 Subject: [issue27073] redundant checks in long_add and long_sub In-Reply-To: <1463816500.87.0.013124059613.issue27073@psf.upfronthosting.co.za> Message-ID: <1464955575.11.0.514948883869.issue27073@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It would be nice. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 08:09:32 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 12:09:32 +0000 Subject: [issue26915] Test identity first in membership operation of ItemsView, ValuesView and Sequence in collections.abc In-Reply-To: <1462256356.96.0.954300432794.issue26915@psf.upfronthosting.co.za> Message-ID: <1464955772.8.0.333940140717.issue26915@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: fixed -> stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 08:25:17 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 12:25:17 +0000 Subject: [issue20041] TypeError when f_trace is None and tracing. In-Reply-To: <1387634487.03.0.628100767515.issue20041@psf.upfronthosting.co.za> Message-ID: <1464956717.22.0.881683736175.issue20041@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think the code would be simpler if convert the argument of frame_settrace() to NULL if it is Py_None. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 08:27:05 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 12:27:05 +0000 Subject: [issue26293] Embedded zipfile fields dependent on absolute position In-Reply-To: <1454662355.53.0.48718125489.issue26293@psf.upfronthosting.co.za> Message-ID: <1464956825.14.0.467157196361.issue26293@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: spoo, can you confirm that the patch fixes your issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 08:27:52 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 12:27:52 +0000 Subject: [issue26983] float() can return not exact float instance In-Reply-To: <1462801593.23.0.789372695786.issue26983@psf.upfronthosting.co.za> Message-ID: <1464956872.03.0.256864460029.issue26983@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 08:59:45 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 03 Jun 2016 12:59:45 +0000 Subject: [issue24291] Many servers (wsgiref, http.server, etc) can truncate large output blobs In-Reply-To: <1432671481.51.0.762064908488.issue24291@psf.upfronthosting.co.za> Message-ID: <1464958785.85.0.0322733901111.issue24291@psf.upfronthosting.co.za> Martin Panter added the comment: In wsgiref-only.v2.patch I added deprecated support for continuing when a partial write is detected. I don?t think it needs documenting though. ---------- Added file: http://bugs.python.org/file43143/wsgiref-only.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 09:44:30 2016 From: report at bugs.python.org (Oren Milman) Date: Fri, 03 Jun 2016 13:44:30 +0000 Subject: [issue27073] redundant checks in long_add and long_sub In-Reply-To: <1463816500.87.0.013124059613.issue27073@psf.upfronthosting.co.za> Message-ID: <1464961470.95.0.839985591582.issue27073@psf.upfronthosting.co.za> Oren Milman added the comment: All right. The updated diff file is attached. I compiled and ran the tests again. They are quite the same. The test output is attached. ---------- Added file: http://bugs.python.org/file43144/issue27073.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 09:45:13 2016 From: report at bugs.python.org (Oren Milman) Date: Fri, 03 Jun 2016 13:45:13 +0000 Subject: [issue27073] redundant checks in long_add and long_sub In-Reply-To: <1463816500.87.0.013124059613.issue27073@psf.upfronthosting.co.za> Message-ID: <1464961513.62.0.382358723222.issue27073@psf.upfronthosting.co.za> Changes by Oren Milman : Added file: http://bugs.python.org/file43145/patchedCPythonTestOutput2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 09:48:13 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 03 Jun 2016 13:48:13 +0000 Subject: [issue23680] Sporadic freeze in test_interrupted_write_retry_text In-Reply-To: <1426521207.32.0.580722848653.issue23680@psf.upfronthosting.co.za> Message-ID: <1464961693.08.0.395373784291.issue23680@psf.upfronthosting.co.za> Martin Panter added the comment: Here is my suggested change to use setitimer(). I also closed the pipe, which means there is no need to time out the read, speeding the test up a bit more. ---------- keywords: +patch stage: -> patch review versions: +Python 2.7 Added file: http://bugs.python.org/file43146/write-retry.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 09:56:41 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 03 Jun 2016 13:56:41 +0000 Subject: [issue22331] test_io.test_interrupted_write_text() hangs on the buildbot FreeBSD 7.2 In-Reply-To: <1409779908.87.0.4046116696.issue22331@psf.upfronthosting.co.za> Message-ID: <1464962201.26.0.867289055374.issue22331@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch with my suggestion to send the signal only when read() returns, and also closing the read end of the pipe before the write end. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file43147/int-write.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 10:11:05 2016 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 03 Jun 2016 14:11:05 +0000 Subject: [issue26983] float() can return not exact float instance In-Reply-To: <1462801593.23.0.789372695786.issue26983@psf.upfronthosting.co.za> Message-ID: <1464963065.16.0.668759879539.issue26983@psf.upfronthosting.co.za> Mark Dickinson added the comment: float_exact2.patch LGTM ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 10:17:18 2016 From: report at bugs.python.org (Oren Milman) Date: Fri, 03 Jun 2016 14:17:18 +0000 Subject: [issue27145] long_add and long_sub might return a new int where &small_ints[x] could be returned In-Reply-To: <1464451117.45.0.85462287723.issue27145@psf.upfronthosting.co.za> Message-ID: <1464963438.39.0.666069095466.issue27145@psf.upfronthosting.co.za> Oren Milman added the comment: I just realized I had forgotten to check for a failure after using _PyLong_Negate. The updated diff file is attached. ---------- Added file: http://bugs.python.org/file43148/proposedPatches.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 10:44:41 2016 From: report at bugs.python.org (Oren Milman) Date: Fri, 03 Jun 2016 14:44:41 +0000 Subject: [issue27145] long_add and long_sub might return a new int where &small_ints[x] could be returned In-Reply-To: <1464451117.45.0.85462287723.issue27145@psf.upfronthosting.co.za> Message-ID: <1464965080.99.0.598828905697.issue27145@psf.upfronthosting.co.za> Oren Milman added the comment: After giving it some more thought, I feel somewhat uncertain about that check for a failure after using _PyLong_Negate. At first I noticed that after every call to _PyLong_Negate there is such a check. But then I realized that in my patch, and also in long_mul (in the default branch of CPython), the check is unnecessary, as z is just returned after the call to _PyLong_Negate. Is adding such a check anyway (e.g. in long_mul) a convention? Or should such checks be removed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 10:58:56 2016 From: report at bugs.python.org (Ethan Furman) Date: Fri, 03 Jun 2016 14:58:56 +0000 Subject: [issue27184] Support path objects in the ntpath module In-Reply-To: <1464917768.07.0.74753238066.issue27184@psf.upfronthosting.co.za> Message-ID: <1464965936.97.0.0915013223337.issue27184@psf.upfronthosting.co.za> Ethan Furman added the comment: @Serhy: Isn't that backwards? I would think that by doing os.path first most other libraries would not have to change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 11:01:01 2016 From: report at bugs.python.org (Ethan Furman) Date: Fri, 03 Jun 2016 15:01:01 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1464966061.45.0.174755392492.issue27186@psf.upfronthosting.co.za> Ethan Furman added the comment: Note: My schedule changed -- I won't be at the sprints today, but tomorrow. I'll finish reviewing these patches and commit this afternoon if no one beats me to it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 11:36:34 2016 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 03 Jun 2016 15:36:34 +0000 Subject: [issue26915] Test identity first in membership operation of ItemsView, ValuesView and Sequence in collections.abc In-Reply-To: <1462256356.96.0.954300432794.issue26915@psf.upfronthosting.co.za> Message-ID: <1464968194.83.0.956118087957.issue26915@psf.upfronthosting.co.za> Xiang Zhang added the comment: Serhiy, actually the patch(issue26915_s2.patch) I uploaded early has tried to make Sequence.index and Sequence.count consistent. Maybe the issue stage is not right. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 11:39:42 2016 From: report at bugs.python.org (spoo) Date: Fri, 03 Jun 2016 15:39:42 +0000 Subject: [issue26293] Embedded zipfile fields dependent on absolute position In-Reply-To: <1464956825.14.0.467157196361.issue26293@psf.upfronthosting.co.za> Message-ID: <5751A4B8.5030908@zarbosoft.com> spoo added the comment: On 06/03/2016 09:27 PM, Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > spoo, can you confirm that the patch fixes your issue? > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > Yes, sorry, and thank you for looking into this! It may take me a few days to be able to test it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 11:44:19 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Jun 2016 15:44:19 +0000 Subject: [issue24759] Idle: require tk 8.5 and ttk widgets, and drop unneeded code. In-Reply-To: <1438294715.65.0.966229055462.issue24759@psf.upfronthosting.co.za> Message-ID: <1464968659.12.0.113091485859.issue24759@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Trying again. And yes, I would like a review. I don't think there is anything system specific, but some deletions required a minor rewrite. ---------- keywords: +patch Added file: http://bugs.python.org/file43149/require85.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 12:18:38 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Fri, 03 Jun 2016 16:18:38 +0000 Subject: [issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects. In-Reply-To: <1384516983.26.0.0584971052865.issue19611@psf.upfronthosting.co.za> Message-ID: <1464970718.58.0.634879316212.issue19611@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: This new patch makes the inspect module treat .0-type names as positional-only and renames them to implicit0. Includes a documentation patch too. I'm not too happy with the wording in the documentation, so suggestions for better naming are appreciated. ---------- Added file: http://bugs.python.org/file43150/issue19611.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 12:40:32 2016 From: report at bugs.python.org (Kushal Das) Date: Fri, 03 Jun 2016 16:40:32 +0000 Subject: [issue25548] Show the address in the repr for class objects In-Reply-To: <1446576011.58.0.372024983976.issue25548@psf.upfronthosting.co.za> Message-ID: <1464972032.97.0.104059024133.issue25548@psf.upfronthosting.co.za> Kushal Das added the comment: Uploading the new patch with a new test case for the same. ---------- Added file: http://bugs.python.org/file43151/issue25548v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 12:53:50 2016 From: report at bugs.python.org (Upendra Kumar) Date: Fri, 03 Jun 2016 16:53:50 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1464972830.32.0.304357342853.issue27051@psf.upfronthosting.co.za> Upendra Kumar added the comment: @Terry and @Lorenzo, As shown in the GUI of "install_pyPI_v1.png", I needed to add some tkinter widget into treeview. For example, adding a checkbox to the treeview so that multiple selections are possible. In figure "install_pyPI_v1.png", a checkbox in each row of treeview is needed. I am not getting idea about how to implement it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 13:09:46 2016 From: report at bugs.python.org (Tommy Beadle) Date: Fri, 03 Jun 2016 17:09:46 +0000 Subject: [issue24617] os.makedirs()'s [mode] not correct In-Reply-To: <1436721223.66.0.229120395272.issue24617@psf.upfronthosting.co.za> Message-ID: <1464973786.03.0.278629419474.issue24617@psf.upfronthosting.co.za> Changes by Tommy Beadle : ---------- nosy: +tbeadle _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 13:13:15 2016 From: report at bugs.python.org (Emanuel Barry) Date: Fri, 03 Jun 2016 17:13:15 +0000 Subject: [issue25548] Show the address in the repr for class objects In-Reply-To: <1446576011.58.0.372024983976.issue25548@psf.upfronthosting.co.za> Message-ID: <1464973995.6.0.887814064646.issue25548@psf.upfronthosting.co.za> Emanuel Barry added the comment: I'd probably change all instances of ".*" in the regex matches to be "0x.+" instead. For the docstrings that have "..." in them, I would probably make those " at ..." as well (although you get decide if it hinders readability too much). Other than that patch LGTM. ---------- nosy: +ebarry stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 13:18:39 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 03 Jun 2016 17:18:39 +0000 Subject: [issue25548] Show the address in the repr for class objects In-Reply-To: <1446576011.58.0.372024983976.issue25548@psf.upfronthosting.co.za> Message-ID: <1464974319.5.0.592238527617.issue25548@psf.upfronthosting.co.za> Brett Cannon added the comment: Patch LGTM. Just needs doc and What's New updates. ---------- assignee: -> kushal.das nosy: +brett.cannon stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 13:21:05 2016 From: report at bugs.python.org (Clark Breyman) Date: Fri, 03 Jun 2016 17:21:05 +0000 Subject: [issue27197] mock.patch interactions with "from" imports Message-ID: <1464974465.34.0.0106266005771.issue27197@psf.upfronthosting.co.za> New submission from Clark Breyman: Unclear if this is a code bug or a gotcha that should be documented: Cross posted to https://github.com/testing-cabal/mock/issues/365 Since "from"-style imports in modules bind names on the first execution of the import, there is a subtle interaction with patching: _If a name is imported when the source is patched, the imported name will refer to the patched version even after the source is restored_ Test case: ```python # patchbug/__init__.py # ``` ```python # patchbug/a.py # class A(object): def name(self): return "unpatched" ``` ```python # patchbug/b.py # from patchbug.a import A def reference(): return A().name() # patchbug/tests.py # import mock """ patchbug.reference.UnpatchedClass is bound to the value of patchbug.source.UnpatchedClass at the time of the first import of patchbug.reference. If patched at that time it is not repaired. """ def test_unpatched(): import patchbug.a assert patchbug.a.A().name() == "unpatched" """ uncommenting the import causes reference.UnpatchedClass to be bound before the patch, fixing test_reference and breaking test_unpatched """ def test_import_reference(): # import patchbug.b pass def test_patched(): with mock.patch('patchbug.a.A') as P: import patchbug.a, patchbug.b P.return_value.name.return_value = "patched" assert patchbug.a.A().name() == "patched" assert patchbug.b.reference() == "patched" def test_reference(): import patchbug.b assert patchbug.b.reference() == "unpatched" ``` ---------- components: Library (Lib) messages: 267114 nosy: clarkbreyman priority: normal severity: normal status: open title: mock.patch interactions with "from" imports type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 13:27:53 2016 From: report at bugs.python.org (Tommy Beadle) Date: Fri, 03 Jun 2016 17:27:53 +0000 Subject: [issue15476] Index "code object" and link to code object definition In-Reply-To: <1343459471.56.0.370073010984.issue15476@psf.upfronthosting.co.za> Message-ID: <1464974873.43.0.691885529034.issue15476@psf.upfronthosting.co.za> Changes by Tommy Beadle : Added file: http://bugs.python.org/file43152/0001-Issue-15476-Make-code-object-its-own-entry-in-the-do.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 13:33:22 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jun 2016 17:33:22 +0000 Subject: [issue22797] urllib.request.urlopen documentation falsely guarantees that a URLError will be raised on errors In-Reply-To: <1415120697.65.0.296811511924.issue22797@psf.upfronthosting.co.za> Message-ID: <20160603173318.21239.13216.402F3266@psf.io> Roundup Robot added the comment: New changeset aed4b9981fca by R David Murray in branch '3.5': #22797: clarify when URLErrors are raised by urlopen. https://hg.python.org/cpython/rev/aed4b9981fca New changeset d085b4f779af by R David Murray in branch '3.5': Merge: #22797: clarify when URLErrors are raised by urlopen. https://hg.python.org/cpython/rev/d085b4f779af ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 13:33:34 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jun 2016 17:33:34 +0000 Subject: [issue20567] test_idle causes test_ttk_guionly 'can't invoke "event" command: application has been destroyed' messages from Tk In-Reply-To: <1391902578.02.0.588798272285.issue20567@psf.upfronthosting.co.za> Message-ID: <20160603173322.13249.45569.3681A768@psf.io> Roundup Robot added the comment: New changeset 8090931ba850 by Terry Jan Reedy in branch '2.7': Issue 20567: Revise idle_test/README.txt and some tests to match new advice. https://hg.python.org/cpython/rev/8090931ba850 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 13:42:04 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Jun 2016 17:42:04 +0000 Subject: [issue20567] test_idle causes test_ttk_guionly 'can't invoke "event" command: application has been destroyed' messages from Tk In-Reply-To: <1391902578.02.0.588798272285.issue20567@psf.upfronthosting.co.za> Message-ID: <1464975724.51.0.754858518216.issue20567@psf.upfronthosting.co.za> Terry J. Reedy added the comment: This and the followup for 3.x full the TODOs in msg219528, revise README.txt, and in msg221467, change delete order to match new advice. This issue was about conflict between test_idle and test_ttk-guionly and that has apparently been solved. After the 3.x commit, I will close this and follow up on the 'update before destroy' and 'prohibit default root' ideas on #27196. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 13:46:10 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Jun 2016 17:46:10 +0000 Subject: [issue15476] Index "code object" and link to code object definition In-Reply-To: <1343459471.56.0.370073010984.issue15476@psf.upfronthosting.co.za> Message-ID: <1464975970.93.0.820181217798.issue15476@psf.upfronthosting.co.za> R. David Murray added the comment: There are entries for code with object as a subentry? That's not what I was talking about, I was talking about preserving the sub entries for 'code' under the 'object' main entry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 13:47:08 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 03 Jun 2016 17:47:08 +0000 Subject: [issue25548] Show the address in the repr for class objects In-Reply-To: <1446576011.58.0.372024983976.issue25548@psf.upfronthosting.co.za> Message-ID: <1464976028.71.0.983196881659.issue25548@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Kushal. If you don't mind, I would like Nofar to be able to do this patch. She's been working on it since before the sprints and was slowed down by a schoolwork crunch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 13:52:40 2016 From: report at bugs.python.org (Nathan Harold) Date: Fri, 03 Jun 2016 17:52:40 +0000 Subject: [issue22558] Missing doc links to source code for Python-coded modules. In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za> Message-ID: <1464976360.64.0.642590235103.issue22558@psf.upfronthosting.co.za> Nathan Harold added the comment: I'll give this a go, per Terry's instructions in msg266846. I've noticed up front that, due to other changes near the headers of a couple of files (specifically fcntl.rst and termios.rst), the patch doesn't apply cleanly anymore. Is it permissible for me to fix that myself and upload a new version, or is it preferable for a patch's original author to handle such things? In any case, there are plenty of other files for me to look over for now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 13:56:19 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 03 Jun 2016 17:56:19 +0000 Subject: [issue25548] Show the address in the repr for class objects In-Reply-To: <1446576011.58.0.372024983976.issue25548@psf.upfronthosting.co.za> Message-ID: <1464976579.04.0.0750311366395.issue25548@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Nofar is about to upload her patch as well (she's been working on this for a while). Perhaps the two can be compared and reconciled so that both can be credited on the commit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 14:01:09 2016 From: report at bugs.python.org (Kushal Das) Date: Fri, 03 Jun 2016 18:01:09 +0000 Subject: [issue25548] Show the address in the repr for class objects In-Reply-To: <1446576011.58.0.372024983976.issue25548@psf.upfronthosting.co.za> Message-ID: <1464976869.88.0.669232543697.issue25548@psf.upfronthosting.co.za> Kushal Das added the comment: Hey Raymond, I am uploading the patch which I almost committed along with whats new update :) I am also reassigning the ticket to you so that you can decide the next steps. ---------- assignee: kushal.das -> rhettinger Added file: http://bugs.python.org/file43153/issue25548v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 14:01:55 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Fri, 03 Jun 2016 18:01:55 +0000 Subject: [issue27182] PEP 519 support in the stdlib In-Reply-To: <1464887789.1.0.970652730446.issue27182@psf.upfronthosting.co.za> Message-ID: <1464976915.53.0.504609694015.issue27182@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: FYI, I'm working on a patch for builtins.open to call PyOS_FSPath. ---------- nosy: +Jelle Zijlstra _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 14:09:34 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 18:09:34 +0000 Subject: [issue26915] Test identity first in membership operation of ItemsView, ValuesView and Sequence in collections.abc In-Reply-To: <1462256356.96.0.954300432794.issue26915@psf.upfronthosting.co.za> Message-ID: <1464977374.34.0.616355563873.issue26915@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, sorry, I was absentminded. In general the patch LGTM. But I think that using list subclass for tests is not a good idea. If we make a typo in CustomSequence method name (__contain__, inedx, coumt), the test is still passed. It would be better to use a class that doesn't have any sequence-related methods besides explicitly defined. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 14:09:43 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 18:09:43 +0000 Subject: [issue26915] Test identity first in membership operation of ItemsView, ValuesView and Sequence in collections.abc In-Reply-To: <1462256356.96.0.954300432794.issue26915@psf.upfronthosting.co.za> Message-ID: <1464977383.16.0.794502925989.issue26915@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 14:12:58 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 18:12:58 +0000 Subject: [issue27073] redundant checks in long_add and long_sub In-Reply-To: <1463816500.87.0.013124059613.issue27073@psf.upfronthosting.co.za> Message-ID: <1464977578.35.0.352538431304.issue27073@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Maybe add an assert for the second size negation? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 14:20:00 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Jun 2016 18:20:00 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1464978000.64.0.787011438798.issue5124@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I just got a complaint from a Linux user who says IDLE is the only application she uses on Linux that has this augment rather than replace behavior. She also uses IDLE on Windows, so this unique IDLE-Linux behavior is quite annoying. Replace at least needs to be an option. Serhiy (or other current Linux user), what do you know about typical behavior on Linux today? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 14:26:22 2016 From: report at bugs.python.org (Dusty Phillips) Date: Fri, 03 Jun 2016 18:26:22 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1464978382.96.0.577860925056.issue27186@psf.upfronthosting.co.za> Dusty Phillips added the comment: Adding a glossary entry for path-like. The references are all correct except: :class:`os.PathLike` doesn't link to anything because PathLike hasn't been added to the os module yet. Similarly, :meth:`__fspath__` does not link to anything, although I think this is acceptable. ---------- Added file: http://bugs.python.org/file43154/issue27186-glossary.buchuki.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 14:31:52 2016 From: report at bugs.python.org (Dusty Phillips) Date: Fri, 03 Jun 2016 18:31:52 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1464978712.65.0.121591435943.issue27186@psf.upfronthosting.co.za> Changes by Dusty Phillips : Removed file: http://bugs.python.org/file43154/issue27186-glossary.buchuki.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 14:32:16 2016 From: report at bugs.python.org (Dusty Phillips) Date: Fri, 03 Jun 2016 18:32:16 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1464978736.7.0.14596340643.issue27186@psf.upfronthosting.co.za> Changes by Dusty Phillips : Added file: http://bugs.python.org/file43155/issue27186-glossary.buchuki.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 14:35:26 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Jun 2016 18:35:26 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1464978926.89.0.629700903403.issue5124@psf.upfronthosting.co.za> R. David Murray added the comment: For what it is worth, as a dedicated X11 user, *if* the target is already hilighted by the application I expect the replace behavior. But in my usage I never select the target myself, since that would replace my selection buffer. So in essence I'm seeing the "augment" behavior, but it's because I click to place the cursor where I want to paste, I don't select a target block to replace. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 14:43:29 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jun 2016 18:43:29 +0000 Subject: [issue26983] float() can return not exact float instance In-Reply-To: <1462801593.23.0.789372695786.issue26983@psf.upfronthosting.co.za> Message-ID: <20160603184326.21239.14002.673D4B35@psf.io> Roundup Robot added the comment: New changeset 050e5f803999 by Serhiy Storchaka in branch 'default': Issue #26983: float() now always return an instance of exact float. https://hg.python.org/cpython/rev/050e5f803999 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 14:44:27 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 18:44:27 +0000 Subject: [issue26983] float() can return not exact float instance In-Reply-To: <1462801593.23.0.789372695786.issue26983@psf.upfronthosting.co.za> Message-ID: <1464979467.81.0.270080186659.issue26983@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your review Mark. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 14:45:50 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Fri, 03 Jun 2016 18:45:50 +0000 Subject: [issue27182] PEP 519 support in the stdlib In-Reply-To: <1464887789.1.0.970652730446.issue27182@psf.upfronthosting.co.za> Message-ID: <1464979550.0.0.159525110141.issue27182@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: This patch makes the Python and C versions of open()/io.open() support the fspath protocol. ---------- keywords: +patch Added file: http://bugs.python.org/file43156/issue27182-open.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 14:45:52 2016 From: report at bugs.python.org (Ethan Furman) Date: Fri, 03 Jun 2016 18:45:52 +0000 Subject: [issue27182] PEP 519 support in the stdlib In-Reply-To: <1464887789.1.0.970652730446.issue27182@psf.upfronthosting.co.za> Message-ID: <1464979552.19.0.985059869079.issue27182@psf.upfronthosting.co.za> Ethan Furman added the comment: Sorry, Serhiy, I had my module names mixed up. `nt` and `posix` are the same, but `ntpath` and `posixpath` are not (I may have those first two names wrong again, but hopefully you get the idea). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 14:48:32 2016 From: report at bugs.python.org (Chris Barker) Date: Fri, 03 Jun 2016 18:48:32 +0000 Subject: [issue27198] Adding an assertClose() method to unittest.TestCase Message-ID: <1464979712.74.0.398203716413.issue27198@psf.upfronthosting.co.za> New submission from Chris Barker: In py3.5, the math.isclose() function was added to the standard library. It can be used to compare floating point numbers to see if they are close to each other, rather than exactly equal. It's not a lot of code, but there are nuances that not every python user should need to understand. One of the major use cases for isclose() is test code, so it would be good to make it easily available in unitest.TestCase. TestCase.assertAlmostEqual is NOT the same thing, and can only be used properly for values near 1. Enclosed is a patch that adds assertClose and assertNotClose to unittest, as well as tests and additions to the docs. Still pending: should this support complex numbers, there is a cmath.isclose(). If so, but switching on type? Also -- should this be back-ported to 3.5 as well -- math.isclose() was introduced there. Done in the pyCon sprints. ---------- components: Library (Lib) files: assertClose.patch keywords: patch messages: 267133 nosy: ChrisBarker, ezio.melotti, michael.foord, rbcollins priority: normal severity: normal status: open title: Adding an assertClose() method to unittest.TestCase type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43157/assertClose.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 14:54:27 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 18:54:27 +0000 Subject: [issue26983] float() can return not exact float instance In-Reply-To: <1462801593.23.0.789372695786.issue26983@psf.upfronthosting.co.za> Message-ID: <1464980066.99.0.967520692328.issue26983@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 14:55:37 2016 From: report at bugs.python.org (Jason Fried) Date: Fri, 03 Jun 2016 18:55:37 +0000 Subject: [issue27199] TarFile expose copyfileobj bufsize to improve throughput Message-ID: <1464980137.78.0.803567676795.issue27199@psf.upfronthosting.co.za> New submission from Jason Fried: The default of 16k while good for memory usage it is not well suited for all cases. if we increased this to 4MB we saw a pretty large improvement to tar file creation and extraction on linux servers. For a 1gb tar file containing 1024 random files each of 10MB in size. Time Delta for TarFile: 146.3240258693695 Time Delta for FastTarFile 4MB copybufsize: 102.76440262794495 Time Diff: 43.55962324142456 0.2976928975444698 ---------- components: Library (Lib) files: buftest.py messages: 267134 nosy: asvetlov, fried, lukasz.langa priority: normal severity: normal status: open title: TarFile expose copyfileobj bufsize to improve throughput type: performance versions: Python 3.5 Added file: http://bugs.python.org/file43158/buftest.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 14:56:02 2016 From: report at bugs.python.org (Jason Fried) Date: Fri, 03 Jun 2016 18:56:02 +0000 Subject: [issue27199] TarFile expose copyfileobj bufsize to improve throughput In-Reply-To: <1464980137.78.0.803567676795.issue27199@psf.upfronthosting.co.za> Message-ID: <1464980162.69.0.353834816417.issue27199@psf.upfronthosting.co.za> Changes by Jason Fried : ---------- keywords: +patch Added file: http://bugs.python.org/file43159/copybufsize.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 14:56:34 2016 From: report at bugs.python.org (Joshua Jay Herman) Date: Fri, 03 Jun 2016 18:56:34 +0000 Subject: [issue24459] Mention PYTHONFAULTHANDLER in the man page In-Reply-To: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za> Message-ID: <1464980194.44.0.531610453257.issue24459@psf.upfronthosting.co.za> Joshua Jay Herman added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 14:57:15 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Jun 2016 18:57:15 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1464980235.16.0.345718154921.issue5124@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Thank you David, that does help. Your comment emphasizes that on other systems and many other X-11 apps, the user already chooses 'replace' versus 'insert' by selecting a replacement or not. I presume the 'selection buffer' you refer to is different from the 'clipboard' (or whatever linux calls it). Otherwise, Roger's patch would not work and I assume he tested it. Simply applying Roger's patch, in 3.6, would be **MUCH** easier than adding a new option. I could even add a line to the sign-on message: "Paste now replaces selected text. Use undo to correct mistakes." Assuming the patch does work, here is a workaround for releases that lack it. Create in Lib/idlelib a file called, for instance @MYPATCHES.txt and insert with the following, to remind what to do after upgrading to a new bugfix release. --- To make paste replace selection, insert the following 3 lines at the top (after the def line) of EditorWindow.paste, about line 600, in file EditorWindow.py (3.5 and before) or editor.py (3.6 and after). sel = self.text.tag_ranges("sel") if sel: self.text.delete(*sel) # issue5124 --- Save and then follow the instruction to patch the editor file. If doing the edit in IDLE, hit F5 to test the patched EditorWindow. ---------- versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 15:00:17 2016 From: report at bugs.python.org (Kaushik N) Date: Fri, 03 Jun 2016 19:00:17 +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: <1464980417.88.0.937611484356.issue16484@psf.upfronthosting.co.za> Changes by Kaushik N : Removed file: http://bugs.python.org/file43121/Issue16484_python3.6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 15:02:22 2016 From: report at bugs.python.org (Kaushik N) Date: Fri, 03 Jun 2016 19:02:22 +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: <1464980542.08.0.105701245854.issue16484@psf.upfronthosting.co.za> Kaushik N added the comment: Applied patch from sean.rodman. Created a tests. Incorporated comments from rdmurray ---------- Added file: http://bugs.python.org/file43160/Issue16484_rev_python3.6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 15:08:32 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 19:08:32 +0000 Subject: [issue27184] Support path objects in the ntpath module In-Reply-To: <1464917768.07.0.74753238066.issue27184@psf.upfronthosting.co.za> Message-ID: <1464980912.28.0.315576287347.issue27184@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think that if some high-level function uses os.path, it likely should convert Path argument to str either because the path should be saved as a string, or for performance if multiple os.path functions are called with the same argument. Note, that some os.path functions will implicitly support path objects if the posix module support it. Let first find the functions that need path objects support in os.path. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 15:15:01 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Jun 2016 19:15:01 +0000 Subject: [issue27198] Adding an assertClose() method to unittest.TestCase In-Reply-To: <1464979712.74.0.398203716413.issue27198@psf.upfronthosting.co.za> Message-ID: <1464981301.71.0.753266504119.issue27198@psf.upfronthosting.co.za> R. David Murray added the comment: The word description of the meaning of the tolerance attributes told me absolutely nothing. The equation from the math.islcose docs makes it prefectly clear. So I think the formula should be included in the documentation. assertAlomstEqual has a delta attribute now, which is equivalent to abs_tol. Perhaps instead we should add rel_tol to assertAlmostEqual? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 15:15:03 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jun 2016 19:15:03 +0000 Subject: [issue27167] subprocess reports signal as negative exit status, not documented In-Reply-To: <1464712500.44.0.979958949461.issue27167@psf.upfronthosting.co.za> Message-ID: <20160603191459.12970.77788.56828E5F@psf.io> Roundup Robot added the comment: New changeset 365b5e6163a6 by Gregory P. Smith in branch 'default': signal, socket, and ssl module IntEnum constant name lookups now return a https://hg.python.org/cpython/rev/365b5e6163a6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 15:15:10 2016 From: report at bugs.python.org (Dave Sawyer) Date: Fri, 03 Jun 2016 19:15:10 +0000 Subject: [issue27190] Check sqlite3_version before allowing check_same_thread = False In-Reply-To: <1464915219.9.0.729350732197.issue27190@psf.upfronthosting.co.za> Message-ID: <1464981310.67.0.23094445828.issue27190@psf.upfronthosting.co.za> Dave Sawyer added the comment: This can go into bugfix branches. In fact, it's most likely to be helpful there because they are more likely to be running with a version of sqlite 10 years old. I use the sqlite3_libversion_number() call because I'm testing against the version of sqlite actually loaded. The SQLITE_VERSION_NUMBER define is set at compile time. ---------- Added file: http://bugs.python.org/file43161/issue27190_patch2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 15:15:33 2016 From: report at bugs.python.org (Tommy Beadle) Date: Fri, 03 Jun 2016 19:15:33 +0000 Subject: [issue15476] Index "code object" and link to code object definition In-Reply-To: <1343459471.56.0.370073010984.issue15476@psf.upfronthosting.co.za> Message-ID: <1464981333.28.0.594082138719.issue15476@psf.upfronthosting.co.za> Tommy Beadle added the comment: Using .. index:: object: code puts a 'code' entry under 'object' as well as 'object' under 'code'. That's the way it is for every other item that uses "object: XXX". So if you want a new 'code object' top-level item and keep 'object -> code', you're going to get 'code -> object' as well. It would seem to me that the 'code object' top-level item is redundant. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 15:15:46 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 03 Jun 2016 19:15:46 +0000 Subject: [issue27167] subprocess reports signal as negative exit status, not documented In-Reply-To: <1464712500.44.0.979958949461.issue27167@psf.upfronthosting.co.za> Message-ID: <1464981346.73.0.508386957347.issue27167@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 15:17:55 2016 From: report at bugs.python.org (Dave Sawyer) Date: Fri, 03 Jun 2016 19:17:55 +0000 Subject: [issue27113] sqlite3 connect parameter "check_same_thread" not documented In-Reply-To: <1464125789.84.0.570004715823.issue27113@psf.upfronthosting.co.za> Message-ID: <1464981475.8.0.74127650769.issue27113@psf.upfronthosting.co.za> Dave Sawyer added the comment: hurray! My first commit ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 15:22:27 2016 From: report at bugs.python.org (Ethan Furman) Date: Fri, 03 Jun 2016 19:22:27 +0000 Subject: [issue27184] Support path objects in the ntpath module In-Reply-To: <1464917768.07.0.74753238066.issue27184@psf.upfronthosting.co.za> Message-ID: <1464981747.3.0.440188970031.issue27184@psf.upfronthosting.co.za> Ethan Furman added the comment: The expected scenario, and the purpose of os.fspath(), is to enable high-level libraries to not know or care if they receive a pathlib object or a string. In other words, they already have os.path.join() and os.path.split() calls, and currently break noisily if a pathlib.Path is passed in; by enhancing os.path to accept a pathlib.Path object that high-level library can start working with pathlib.Path objects without changing a thing, which means the user of that library can use pathlib.Path painlessly. Unless I have seriously misunderstood something, os.path will be changed to work with __fspath__ objects. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 15:23:53 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 19:23:53 +0000 Subject: [issue24759] Idle: require tk 8.5 and ttk widgets, and drop unneeded code. In-Reply-To: <1438294715.65.0.966229055462.issue24759@psf.upfronthosting.co.za> Message-ID: <1464981833.17.0.984391492022.issue24759@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Did you try to run tests with Tk 8.4? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 15:24:50 2016 From: report at bugs.python.org (Thomas Kluyver) Date: Fri, 03 Jun 2016 19:24:50 +0000 Subject: [issue27113] sqlite3 connect parameter "check_same_thread" not documented In-Reply-To: <1464125789.84.0.570004715823.issue27113@psf.upfronthosting.co.za> Message-ID: <1464981890.5.0.305061277531.issue27113@psf.upfronthosting.co.za> Thomas Kluyver added the comment: Congrats! :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 15:26:11 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Jun 2016 19:26:11 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1464981971.94.0.032253562422.issue27051@psf.upfronthosting.co.za> Terry J. Reedy added the comment: There is apparently no way to insert widgets in a Treeview -- text only. See for instance https://stackoverflow.com/questions/16755176/tkinter-insert-a-combobox-inside-a-treeview-widget. I don't know whether clicks on a row can be pinpointed to a specific field (to pop up a widget), but it should certainly be possible to detect a right click to do the same. Or put treeview in frame with button with command that detect highlighted row. For your particular problem, I believe Treeview has a mode that allows multiple selections, with multiple rows highlighted simultaneously. If not, or in addition, replace proposed boxes with a blank column and insert string 'X' to indicate selection and inclusion in 'Install' or any other action. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 15:32:06 2016 From: report at bugs.python.org (Laura Rupprecht) Date: Fri, 03 Jun 2016 19:32:06 +0000 Subject: [issue17888] docs: more information on documentation team In-Reply-To: <1367412914.06.0.588625037016.issue17888@psf.upfronthosting.co.za> Message-ID: <1464982326.55.0.181995126593.issue17888@psf.upfronthosting.co.za> Laura Rupprecht added the comment: I've updated the patch from Terry with Berker's suggestion. ---------- nosy: +laura Added file: http://bugs.python.org/file43162/issue17888_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 15:42:45 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Jun 2016 19:42:45 +0000 Subject: [issue22558] Missing doc links to source code for Python-coded modules. In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za> Message-ID: <1464982965.38.0.828264274155.issue22558@psf.upfronthosting.co.za> Terry J. Reedy added the comment: For me, the issue is willingness, not permission ;-). Reviewing a patch includes somehow indicating changes needed to apply it 'today', and a revised patch is the best way. Please say whether the header changes are in 3.6 only (in which case a separate 3.5 patch is needed) or in both. 'Commit ready' means that you believe a core dev could (and should) download, apply without issue, and commit when satisfies. I should do so within a week if no one else does. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 15:48:37 2016 From: report at bugs.python.org (Chris Barker) Date: Fri, 03 Jun 2016 19:48:37 +0000 Subject: [issue27198] Adding an assertClose() method to unittest.TestCase In-Reply-To: <1464979712.74.0.398203716413.issue27198@psf.upfronthosting.co.za> Message-ID: <1464983317.7.0.0626724981097.issue27198@psf.upfronthosting.co.za> Chris Barker added the comment: Thanks, I'll add the equation to the docstring and docs. As for adding a rel_tol to assertAlmostEqual -- I think that's a bad idea -- it's a pretty different concept -- overloading the same method would be more confusing than anything else. in isclose(), abs_tol is mostly there to support comparison to zero. delta, on the other hand, is consistent with assertAlmost eual in the sense that you need to know the order of magnitude of your values apriori. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 15:51:00 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jun 2016 19:51:00 +0000 Subject: [issue22797] urllib.request.urlopen documentation falsely guarantees that a URLError will be raised on errors In-Reply-To: <1415120697.65.0.296811511924.issue22797@psf.upfronthosting.co.za> Message-ID: <20160603195057.16579.16176.0567CBB2@psf.io> Roundup Robot added the comment: New changeset 8b6b6add8e47 by R David Murray in branch 'default': psuedo merge: #22797: clarify when URLErrors are raised by urlopen. https://hg.python.org/cpython/rev/8b6b6add8e47 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 15:53:40 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Jun 2016 19:53:40 +0000 Subject: [issue27198] Adding an assertClose() method to unittest.TestCase In-Reply-To: <1464979712.74.0.398203716413.issue27198@psf.upfronthosting.co.za> Message-ID: <1464983620.31.0.46103829653.issue27198@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 15:54:25 2016 From: report at bugs.python.org (Oren Milman) Date: Fri, 03 Jun 2016 19:54:25 +0000 Subject: [issue27073] redundant checks in long_add and long_sub In-Reply-To: <1463816500.87.0.013124059613.issue27073@psf.upfronthosting.co.za> Message-ID: <1464983665.03.0.109159043042.issue27073@psf.upfronthosting.co.za> Oren Milman added the comment: I considered doing that, but I had already opened another issue (http://bugs.python.org/issue27145) in which I had proposed to replace that in-place negate in long_sub with a call to _PyLong_Negate. But I guess I shouldn't worry about my patches colliding. Anyway, the second assert would be 'assert(Py_SIZE(z) == 0 || Py_REFCNT(z) == 1);', because if someone does (in Python) 'x = (-2 ** PyLong_SHIFT) - (-2 ** PyLong_SHIFT)', x_sub would do 'return (PyLongObject *)PyLong_FromLong(0);'. The updated diff file and the new test output are attached. (No idea why test_netrc failed there. I ran it specifically five times right after that, and it passed all of them. Maybe some race condition? (To run the tests, I do 'python_d.exe -m test -j3'.) Anyway, here is the relevant output (I am not sure the last line is relevant): Warning -- files was modified by test_netrc test test_netrc failed -- Traceback (most recent call last): File "C:\Users\orenmn\cpython\lib\test\test_netrc.py", line 52, in test_password_with_trailing_hash """, 'pass#') File "C:\Users\orenmn\cpython\lib\test\test_netrc.py", line 41, in _test_passwords nrc = self.make_nrc(nrc) File "C:\Users\orenmn\cpython\lib\test\test_netrc.py", line 13, in make_nrc with open(temp_filename, mode) as fp: PermissionError: [Errno 13] Permission denied: '@test_3652_tmp' minkernel\crts\ucrt\src\appcrt\lowio\write.cpp(49) : Assertion failed: (_osfile(fh) & FOPEN) ) ---------- Added file: http://bugs.python.org/file43163/issue27073.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 15:54:43 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 03 Jun 2016 19:54:43 +0000 Subject: [issue23306] Within zipfile, use of zlib.crc32 raises OverflowError at argument-parsing time on large strings In-Reply-To: <1422056966.81.0.518971767948.issue23306@psf.upfronthosting.co.za> Message-ID: <1464983683.48.0.772019903566.issue23306@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- dependencies: +zlib: OverflowError while trying to compress 2^32 bytes or more stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 15:54:57 2016 From: report at bugs.python.org (Oren Milman) Date: Fri, 03 Jun 2016 19:54:57 +0000 Subject: [issue27073] redundant checks in long_add and long_sub In-Reply-To: <1463816500.87.0.013124059613.issue27073@psf.upfronthosting.co.za> Message-ID: <1464983697.79.0.453589371729.issue27073@psf.upfronthosting.co.za> Changes by Oren Milman : Added file: http://bugs.python.org/file43164/patchedCPythonTestOutput.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 15:57:58 2016 From: report at bugs.python.org (Chris Barker) Date: Fri, 03 Jun 2016 19:57:58 +0000 Subject: [issue27198] Adding an assertClose() method to unittest.TestCase In-Reply-To: <1464979712.74.0.398203716413.issue27198@psf.upfronthosting.co.za> Message-ID: <1464983878.23.0.390913065833.issue27198@psf.upfronthosting.co.za> Chris Barker added the comment: updated patch with the equation in the docs. ---------- Added file: http://bugs.python.org/file43165/assertClose.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 16:00:04 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Jun 2016 20:00:04 +0000 Subject: [issue24759] Idle: require tk 8.5 and ttk widgets, and drop unneeded code. In-Reply-To: <1438294715.65.0.966229055462.issue24759@psf.upfronthosting.co.za> Message-ID: <1464984004.95.0.0846909936878.issue24759@psf.upfronthosting.co.za> Terry J. Reedy added the comment: No, 3.4 is security fixes only and this is a 3.6 only issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 16:09:43 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 20:09:43 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1464984583.67.0.534368501495.issue5124@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In modern text editors selecting text with a mouse moves text cursor, and moving the cursor by arrow keys cancels the selection (if Shift is not pressed). But in terminal emulators selecting text with a mouse doesn't move text cursor, and moving the cursor doesn't cancel the selection. This might be an initial reason for Tk behavior. Since IDLE editor window is rather a text editor than a terminal emulator, I think 'replace' is more preferable. But I'm not so sure about IDLE shell window. EditorWindow.text is not the only Text widget. There are many other Text and Entry widgets are created. We should change the behavior of all Text and Entry widgets globally. I'll try to write a patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 16:15:08 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 20:15:08 +0000 Subject: [issue24759] Idle: require tk 8.5 and ttk widgets, and drop unneeded code. In-Reply-To: <1438294715.65.0.966229055462.issue24759@psf.upfronthosting.co.za> Message-ID: <1464984908.3.0.937208103718.issue24759@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I meant Tk 8.4, not Python 3.4. Tests should be either passed or skipped, no errors raised. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 16:15:45 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 03 Jun 2016 20:15:45 +0000 Subject: [issue20041] TypeError when f_trace is None and tracing. In-Reply-To: <1387634487.03.0.628100767515.issue20041@psf.upfronthosting.co.za> Message-ID: <1464984945.95.0.2239974213.issue20041@psf.upfronthosting.co.za> Xavier de Gaye added the comment: On a 'call' trace event, the bdb dispatch_call() function returns None when there is nothing to trace in this function (no breakpoints). With the changes made by the patch in ceval.c, the costly maybe_call_line_trace() function is not called on each line in this case since f->f_trace is Py_None. This provides the performance enhancements described in issue 16672 without breaking the _hotshot extension module or other extension modules using PyEval_SetTrace(). I agree that the code would be much simpler when f->f_trace is set to NULL by the frame_settrace() setter or trace_trampoline() when it is Py_None. The performance gain described above by using Py_None may not be worth the complexity. Thanks for looking into this Serhiy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 16:25:55 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 20:25:55 +0000 Subject: [issue20041] TypeError when f_trace is None and tracing. In-Reply-To: <1387634487.03.0.628100767515.issue20041@psf.upfronthosting.co.za> Message-ID: <1464985555.71.0.734960719861.issue20041@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This may be worthwhile optimization, but this is different issue. Let first fix a TypeError, and then open new issue for the optimization. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 16:27:32 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 03 Jun 2016 20:27:32 +0000 Subject: [issue25931] os.fork() command distributed in windows Python27 (in SocketServer module) In-Reply-To: <1450840231.57.0.83917358919.issue25931@psf.upfronthosting.co.za> Message-ID: <1464985652.02.0.228068416331.issue25931@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: commit review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 16:36:47 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 03 Jun 2016 20:36:47 +0000 Subject: [issue24459] Mention PYTHONFAULTHANDLER in the man page In-Reply-To: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za> Message-ID: <1464986207.19.0.0847891982624.issue24459@psf.upfronthosting.co.za> Berker Peksag added the comment: > Hi, I have alphabetized and [...] Can you please de-alphabetize the list to make patch review a little bit easier? Thanks! ---------- nosy: +berker.peksag stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 16:41:26 2016 From: report at bugs.python.org (Robert Collins) Date: Fri, 03 Jun 2016 20:41:26 +0000 Subject: [issue27198] Adding an assertClose() method to unittest.TestCase In-Reply-To: <1464979712.74.0.398203716413.issue27198@psf.upfronthosting.co.za> Message-ID: <1464986486.7.0.889335930268.issue27198@psf.upfronthosting.co.za> Robert Collins added the comment: Thanks for proposing this. I really don't want to add new assertions to unittest, and I certainly don't want to add narrow usage ones like this, nor ones that are confusingly named (this has nothing to do with files, but 'close' is a verb for files, just like equal is a verb for objects. Instead, I suggest a regular function that will raise AssertionError on failure. The only thing you need _formatMessage for is handling long messages, and I don't think thats useful or relevant for a binary numeric test like this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 16:44:35 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Jun 2016 20:44:35 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1464986675.95.0.852954592318.issue5124@psf.upfronthosting.co.za> R. David Murray added the comment: Note that I would find it *very* confusing if the paste took place at some other location than the cursor location. From Serhiy's description I don't think that's an issue in the proposed change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 17:04:32 2016 From: report at bugs.python.org (Robert Collins) Date: Fri, 03 Jun 2016 21:04:32 +0000 Subject: [issue27197] mock.patch interactions with "from" imports In-Reply-To: <1464974465.34.0.0106266005771.issue27197@psf.upfronthosting.co.za> Message-ID: <1464987872.51.0.666150388947.issue27197@psf.upfronthosting.co.za> Robert Collins added the comment: So its a feature of mock that it can mock a module that doesn't exist. And the semantics of the import system are designed to be very cheap when a module is already imported - so when 'patchbug.a' is in sys.modules, import will correctly return it rather than going out to the import path to find if its the same thing. We could possibly have an opt-in check on mock.patch to require that the thing being patched exists, but it would have to be opt-in as so many cases are dealing with optional or pretend instances. I'm not super keen on that though. This is perhaps worth calling out in the docs to avoid confusion. ---------- nosy: +rbcollins _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 17:07:49 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 03 Jun 2016 21:07:49 +0000 Subject: [issue27184] Support path objects in the ntpath module In-Reply-To: <1464917768.07.0.74753238066.issue27184@psf.upfronthosting.co.za> Message-ID: <1464988069.4.0.864073993646.issue27184@psf.upfronthosting.co.za> Brett Cannon added the comment: os.path will be updated to work with __fspath__() as specified by Guido as part of the conversation for PEP 519 (IOW listing os.path as being updated in PEP 519 is not an accident). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 17:08:30 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 21:08:30 +0000 Subject: [issue27073] redundant checks in long_add and long_sub In-Reply-To: <1463816500.87.0.013124059613.issue27073@psf.upfronthosting.co.za> Message-ID: <1464988110.54.0.201955043032.issue27073@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM (except a trailing space in a comment). Thank you for your contribution Oren. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 17:08:57 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jun 2016 21:08:57 +0000 Subject: [issue27073] redundant checks in long_add and long_sub In-Reply-To: <1463816500.87.0.013124059613.issue27073@psf.upfronthosting.co.za> Message-ID: <1464988137.94.0.480835386788.issue27073@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- type: behavior -> performance _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 17:11:56 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jun 2016 21:11:56 +0000 Subject: [issue27073] redundant checks in long_add and long_sub In-Reply-To: <1463816500.87.0.013124059613.issue27073@psf.upfronthosting.co.za> Message-ID: <20160603210702.91250.96204.665A6775@psf.io> Roundup Robot added the comment: New changeset c21bf38a9d07 by Serhiy Storchaka in branch 'default': Issue #27073: Removed redundant checks in long_add and long_sub. https://hg.python.org/cpython/rev/c21bf38a9d07 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 17:13:28 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Fri, 03 Jun 2016 21:13:28 +0000 Subject: [issue27200] make doctest in CPython has failures Message-ID: <1464988408.0.0.840317371896.issue27200@psf.upfronthosting.co.za> New submission from Jelle Zijlstra: I'm going to gather together a patch to fix some of these issues. ---------- messages: 267166 nosy: Jelle Zijlstra, brett.cannon priority: normal severity: normal status: open title: make doctest in CPython has failures _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 17:44:25 2016 From: report at bugs.python.org (Joshua Jay Herman) Date: Fri, 03 Jun 2016 21:44:25 +0000 Subject: [issue24459] Mention PYTHONFAULTHANDLER in the man page In-Reply-To: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za> Message-ID: <1464990265.64.0.253002337569.issue24459@psf.upfronthosting.co.za> Joshua Jay Herman added the comment: Undid alphabetization and added additional missing environment variables including debug mode variables. ---------- Added file: http://bugs.python.org/file43166/addMissingEnvironmentVariables.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 17:51:06 2016 From: report at bugs.python.org (Chris Barker) Date: Fri, 03 Jun 2016 21:51:06 +0000 Subject: [issue27198] Adding an assertClose() method to unittest.TestCase In-Reply-To: <1464979712.74.0.398203716413.issue27198@psf.upfronthosting.co.za> Message-ID: <1464990666.25.0.117799937895.issue27198@psf.upfronthosting.co.za> Chris Barker added the comment: I'm not sure it's confusing --what would "close" mean for an assertion for a file? "assertClosed" would be confusing -- and an even more trivial assert :-). But we can bikeshed the name if we decide to put this in. """ I certainly don't want to add narrow usage ones like this """ well, I can't say I like the unittest API either -- but "this would be just as well served with a function" applies to almost all the asserts in TestCase -- assertTrue? really? So unless we're going to deprecate that API, or at least document that you should be using simpler constructs: assert something rather than: self.assertTrue(something) then we might as well go with it and have a well supported API. """ I suggest a regular function that will raise AssertionError on failure""" where would that go? and what would it be called? and how would it be any better than: assert math.isclose(a,b) ?? The primary reason I think it should be there is discoverability. Folks will be looking through the testCase docs looking for the asserts they need. And they will find assertAlmostEqual -- and it will often be the wrong solution to their problem. Having the right solution be a first-class part of the API is "a good thing" And it does add a bit of useful information to the message -- knowing the tolerances used for the failing test really helps you know if it's a bug or too strict a test. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 17:59:48 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Jun 2016 21:59:48 +0000 Subject: [issue27198] Adding an assertClose() method to unittest.TestCase In-Reply-To: <1464979712.74.0.398203716413.issue27198@psf.upfronthosting.co.za> Message-ID: <1464991188.95.0.342413533948.issue27198@psf.upfronthosting.co.za> R. David Murray added the comment: On the name, I assumed it had something to do with files when I saw the issue title. I'm not sure that's enough of an argument against it, though. There's an issue where Serhiy is proposing a mixin with additional assert methods. If that has any traction then this could possibly go there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 18:03:11 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 03 Jun 2016 22:03:11 +0000 Subject: [issue24459] Mention PYTHONFAULTHANDLER in the man page In-Reply-To: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za> Message-ID: <1464991391.68.0.386796136249.issue24459@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch, Joshua. I did a quick review and it looks good to me. I will review and test it more carefully later today. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 18:04:23 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 03 Jun 2016 22:04:23 +0000 Subject: [issue17888] docs: more information on documentation team In-Reply-To: <1367412914.06.0.588625037016.issue17888@psf.upfronthosting.co.za> Message-ID: <1464991463.44.0.551018006856.issue17888@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks, Laura. I will commit issue17888_2.patch later today. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 18:08:17 2016 From: report at bugs.python.org (Chris Barker) Date: Fri, 03 Jun 2016 22:08:17 +0000 Subject: [issue27198] Adding an assertClose() method to unittest.TestCase In-Reply-To: <1464979712.74.0.398203716413.issue27198@psf.upfronthosting.co.za> Message-ID: <1464991697.19.0.982197458538.issue27198@psf.upfronthosting.co.za> Chris Barker added the comment: thanks, that's Issue27152 if anyone's curious. Though I have no idea why you'd want it in a mixin, rather than just there. But sure, this could be "bundled" in with that. Perhaps it's time for a broader discussion / consensus about the future of the unittest API? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 18:08:42 2016 From: report at bugs.python.org (Nathan Harold) Date: Fri, 03 Jun 2016 22:08:42 +0000 Subject: [issue22558] Missing doc links to source code for Python-coded modules. In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za> Message-ID: <1464991722.91.0.558596729793.issue22558@psf.upfronthosting.co.za> Nathan Harold added the comment: I went through all the diffs in Rietveld, checking it against msg228576 as I went. There were (naturally) more source links added than there are in that list from 2014, and there were also many more files with slight header reorganizations for consistency. Anything in the diffs I don't mention here looked fine to me. I also built the docs to test links in general and to see how some specific things here looked. A number of the new links are to __init__.py files, and others are to folders rather than individual source files. I noticed a precedent for the former in the case of the http module; for the latter I'm less certain, but I can see that it makes sense in some cases, e.g. when __init__.py is empty. I think these are probably good. One thing I particularly noticed was that in imp.rst and optparse.rst, the deprecation notice occurred below the source link, whereas the versionadded notices are always above it. I think it would be more consistent and look more natural to have the deprecation notices above the source links. This could be taken a step farther by suggesting that the source link always be the last visible thing before the horizontal line. The two other cases this would affect here are asyncio.rst (the notice that the module is provisional is between the source link and line) and getopt.rst (the note, now moved above the line, is after the source link). But this is all fairly subjective. Other details for individual files: marshal.rst - Here an index block a bit farther down into the text was moved up into the header. I think these might have been intended to point right where they were, not to the module as a whole; those things occur only in the paragraph (or two, in the case of 'code object') immediately following where the index originally pointed. unittest.mock-examples.rst - A versionadded notice was completely removed from this file. In fact, that was the only change to this file. I think I can see why you did this, since the actual API documentation for the library is in unittest.mock.rst, which has that same version notice. Smaller details: array.rst - -------------- was inserted above .. index: fcntl.rst - Patch appears to apply correctly, but with fuzz. os.path.rst - It might be good to put a space in "WindowsNT" termios.rst - Patch fails to apply because some other text near the header has changed recently. venv.rst - The source code link (to a folder) works, but is missing a trailing slash. Terry, I got the same results when I tried applying it to 3.5, so I think a single patch will do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 18:10:35 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Jun 2016 22:10:35 +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: <1464991835.33.0.987977287742.issue16484@psf.upfronthosting.co.za> R. David Murray added the comment: This patch looks good to me. Note that the reason for the basedir change is that the test would fail if run from a build directory which hadn't been installed. An implication of this is that 'doc_loc' is None most of the time when the other tests are run, meaning that this new test is the only one that consistently tests the body of getdocloc. I think that method could use some more tests, but that is a separate issue. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 18:11:15 2016 From: report at bugs.python.org (Chris Barker) Date: Fri, 03 Jun 2016 22:11:15 +0000 Subject: [issue27152] Additional assert methods for unittest In-Reply-To: <1464535519.92.0.0853489345335.issue27152@psf.upfronthosting.co.za> Message-ID: <1464991875.81.0.975930240099.issue27152@psf.upfronthosting.co.za> Chris Barker added the comment: Why a mixin rather than adding to TestCase? If they are useful they should be easy to find. Also, see Issue27198 for another possible new assert. ---------- nosy: +ChrisBarker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 18:14:00 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Jun 2016 22:14:00 +0000 Subject: [issue27198] Adding an assertClose() method to unittest.TestCase In-Reply-To: <1464979712.74.0.398203716413.issue27198@psf.upfronthosting.co.za> Message-ID: <1464992040.63.0.915385890014.issue27198@psf.upfronthosting.co.za> R. David Murray added the comment: I raised the same point on that issue, and the answer as I understand it is that we want to change the API by making the assert methods independent of the rest of unit test, so I think Serhiy was seeing the mixin as a move in that general direction. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 18:14:59 2016 From: report at bugs.python.org (Demur Rumed) Date: Fri, 03 Jun 2016 22:14:59 +0000 Subject: [issue27140] Opcode for creating dict with constant keys In-Reply-To: <1464381640.82.0.0689379791356.issue27140@psf.upfronthosting.co.za> Message-ID: <1464992099.05.0.857137029059.issue27140@psf.upfronthosting.co.za> Demur Rumed added the comment: When is this intended to be merged? I've been waiting on this before updating the patch @ #27095 with fixes to other code review comments ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 18:17:53 2016 From: report at bugs.python.org (Chris Barker) Date: Fri, 03 Jun 2016 22:17:53 +0000 Subject: [issue27198] Adding an assertClose() method to unittest.TestCase In-Reply-To: <1464979712.74.0.398203716413.issue27198@psf.upfronthosting.co.za> Message-ID: <1464992273.76.0.709412160515.issue27198@psf.upfronthosting.co.za> Chris Barker added the comment: Would that make folks more amenable to adding more "specialized" asserts? If so, then sure. I don't know that it takes a PEP (I hope not) but it would be good to have some guidance as to the direction we want unittest to take written down somewhere. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 18:31:17 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Jun 2016 22:31:17 +0000 Subject: [issue27162] Add idlelib.interface module In-Reply-To: <1464677206.97.0.125904884409.issue27162@psf.upfronthosting.co.za> Message-ID: <1464993077.54.0.978288824827.issue27162@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Import should fail if tk.TkVersion < 8.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 18:33:16 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Jun 2016 22:33:16 +0000 Subject: [issue24759] Idle: require tk 8.5 and ttk widgets, and drop unneeded code. In-Reply-To: <1438294715.65.0.966229055462.issue24759@psf.upfronthosting.co.za> Message-ID: <1464993196.49.0.265621710603.issue24759@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I saw the review comment about adding lines. I do not have 8.4 either, but I get the point: the startup version check does not not guard the unittests. After test.text_idle imports unittest and tkinter (as tk) (line 6), I will add if tk.TkVersion < 8.5: raise unittest.SkipTest("IDLE requires tk 8.5 or later.") I will add a 'private API' and version-required notice to idlelib.idle_test.__init__. I will add version required to the notice already in idlelib.__init__. For similar reasons, the proposed interface module (#27162) would also need an explicit check. (Note added there.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 18:37:22 2016 From: report at bugs.python.org (Matthias Klose) Date: Fri, 03 Jun 2016 22:37:22 +0000 Subject: [issue27201] expose the ABI name as a config variable Message-ID: <1464993442.58.0.656419844053.issue27201@psf.upfronthosting.co.za> New submission from Matthias Klose: Some python extensions provide/rely on support libraries which are shipped in addition to the extension module, and which depend on the Python ABI (version and ABI flags). talloc is such an example, and it currently uses the SOABI as the symbol version for symbols exported in such a support library. In 3.5 and 3.6, the SOABI includes the architecture definition as well, so you end up with different symbol versions and library names across architectures, which is not wanted. Therefore expose just the ABI in a new macro. Now choosen ABINAME, but that could be something different as well. ---------- components: Build files: abiname.diff keywords: patch messages: 267181 nosy: doko, ncoghlan priority: normal severity: normal status: open title: expose the ABI name as a config variable versions: Python 3.6 Added file: http://bugs.python.org/file43167/abiname.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 18:49:33 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 03 Jun 2016 22:49:33 +0000 Subject: [issue15476] Index "code object" and link to code object definition In-Reply-To: <1343459471.56.0.370073010984.issue15476@psf.upfronthosting.co.za> Message-ID: <1464994173.58.0.50538604149.issue15476@psf.upfronthosting.co.za> Martin Panter added the comment: I haven?t tested, but maybe this will do what you want: .. index:: object; code, code object or .. index:: single: object; code single: code object ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 18:55:44 2016 From: report at bugs.python.org (Eric Snow) Date: Fri, 03 Jun 2016 22:55:44 +0000 Subject: [issue24254] Make class definition namespace ordered by default In-Reply-To: <1432186488.39.0.20621749373.issue24254@psf.upfronthosting.co.za> Message-ID: <1464994544.68.0.340805938386.issue24254@psf.upfronthosting.co.za> Eric Snow added the comment: Here's the full patch, including the addition of __definition_order__, tests, and docs. ---------- Added file: http://bugs.python.org/file43168/deforder.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 18:59:37 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Jun 2016 22:59:37 +0000 Subject: [issue22558] Missing doc links to source code for Python-coded modules. In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za> Message-ID: <1464994777.44.0.531870706041.issue22558@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Great report. It appears that the remaining questions are subjective decisions for a core developer: what is the best link, if any, for a package; should the link also be last thing in the section. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 19:09:25 2016 From: report at bugs.python.org (Eric Snow) Date: Fri, 03 Jun 2016 23:09:25 +0000 Subject: [issue24254] Make class definition namespace ordered by default In-Reply-To: <1432186488.39.0.20621749373.issue24254@psf.upfronthosting.co.za> Message-ID: <1464995365.29.0.667967024643.issue24254@psf.upfronthosting.co.za> Changes by Eric Snow : Removed file: http://bugs.python.org/file43168/deforder.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 19:09:41 2016 From: report at bugs.python.org (Eric Snow) Date: Fri, 03 Jun 2016 23:09:41 +0000 Subject: [issue24254] Make class definition namespace ordered by default In-Reply-To: <1432186488.39.0.20621749373.issue24254@psf.upfronthosting.co.za> Message-ID: <1464995381.42.0.323208475828.issue24254@psf.upfronthosting.co.za> Changes by Eric Snow : Added file: http://bugs.python.org/file43169/deforder.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 19:21:07 2016 From: report at bugs.python.org (Robert Collins) Date: Fri, 03 Jun 2016 23:21:07 +0000 Subject: [issue27152] Additional assert methods for unittest In-Reply-To: <1464535519.92.0.0853489345335.issue27152@psf.upfronthosting.co.za> Message-ID: <1464996067.74.0.161397610114.issue27152@psf.upfronthosting.co.za> Robert Collins added the comment: I'm fine with these as a mixin - they are all very generic and unambiguously named. I'd marginally prefer the opt-in mixin over adding them to the base class. Ideally they'd be matchers, but since I haven't ported that upstream yet, thats asking for more work, and we can always migrate later. (https://rbtcollins.wordpress.com/2010/05/10/maintainable-pyunit-test-suites/ and http://testtools.readthedocs.io/en/latest/for-test-authors.html#matchers - sorry about the formatting in the blog post, wordpress changed theme details some time after I wrote the post and it now renders horribly :( ) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 19:29:58 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jun 2016 23:29:58 +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: <20160603232955.23417.92855.F0D335C2@psf.io> Roundup Robot added the comment: New changeset 64e7c8531131 by R David Murray in branch '3.5': #16484: Fix pydoc doc links to modules whose names are mixed case. https://hg.python.org/cpython/rev/64e7c8531131 New changeset 912b9aad0b45 by R David Murray in branch 'default': Merge: #16484: Fix pydoc doc links to modules whose names are mixed case. https://hg.python.org/cpython/rev/912b9aad0b45 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 19:30:13 2016 From: report at bugs.python.org (Robert Collins) Date: Fri, 03 Jun 2016 23:30:13 +0000 Subject: [issue27198] Adding an assertClose() method to unittest.TestCase In-Reply-To: <1464979712.74.0.398203716413.issue27198@psf.upfronthosting.co.za> Message-ID: <1464996613.86.0.0763019971603.issue27198@psf.upfronthosting.co.za> Robert Collins added the comment: Future direction: hamcrest style matchers. You can read more about them in the context of unittest https://rbtcollins.wordpress.com/2010/05/10/maintainable-pyunit-test-suites/ and http://testtools.readthedocs.io/en/latest/for-test-authors.html#matchers - sorry about the formatting in the blog post, wordpress changed theme details some time after I wrote the post and it now renders horribly :(. w.r.t. error messages, a regular function that raises AssertionError with a nice message will be precisely as usable. def assert_math_isclose(first, second, rel_tol=1e-09, abs_tol=0.0, msg=None): if math.isclose(first, second, rel_tol=rel_tol, abs_tol=abs_tol): return standardMsg = ('%s != %s with relative tolerance of %.3g' ' and absolute tolerance of %.3g' % (safe_repr(first), safe_repr(second), rel_tol, abs_tol)) if msg: raise AssertionError("{} : {}".format(standardMsg, msg)) else: raise AssertionError(standardMsg) The reason I'm pushing back on adding methods to TestCase is that every one we add collides with some number of subclasses out in the wild: the TestCase class has multiple distinct APIs in the same namespace - and thats very poor for maintaining compatibility. Long term I want to have entirely separate interfaces for these things, but thats even more radical an overhaul than adding matchers as a stock facility, and I don't currently have a planned timeline for starting on that. All of that said, I see that this isn't the same as assertAlmostEqual in mathematical terms - but in /user/ terms I think it is. So why can't we make assertAlmostEqual be this? Just add the extra parameter needed with a default value and change the implementation? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 19:34:18 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Jun 2016 23:34:18 +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: <1464996858.13.0.918019469886.issue16484@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks Sean and Kaushik. The final patch didn't apply to 2.7. If someone wants to port the patch I'll apply it, but I'm going to close the issue. ---------- resolution: -> fixed stage: test needed -> resolved status: open -> closed type: behavior -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 19:35:07 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 03 Jun 2016 23:35:07 +0000 Subject: [issue15476] Index "code object" and link to code object definition In-Reply-To: <1343459471.56.0.370073010984.issue15476@psf.upfronthosting.co.za> Message-ID: <1464996907.28.0.0900764931165.issue15476@psf.upfronthosting.co.za> Martin Panter added the comment: Not sure why it doesn?t come up in the code review, but in diff --git a/Doc/reference/datamodel.rst b/Doc/reference/datamodel.rst index c0b4930..f34ba9f 100644 --- a/Doc/reference/datamodel.rst +++ b/Doc/reference/datamodel.rst @@ -847,8 +847,10 @@ Internal types Code objects + .. index:: single: bytecode + single: code object object: code Code objects represent *byte-compiled* executable Python code, or :term:`bytecode`. that added blank line seems to also cause the same definition list problem as before :( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 20:04:06 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 04 Jun 2016 00:04:06 +0000 Subject: [issue27202] make doctest fails on 2.7 release notes Message-ID: <1464998646.05.0.234628246633.issue27202@psf.upfronthosting.co.za> New submission from Jelle Zijlstra: Running `make doctest` in the Doc/ repository of master fails on the 2.7 release notes. This patch excludes these files from `make doctest`, because it doesn't seem worth it to try to get these running in Python 3. ---------- assignee: docs at python components: Documentation files: no27doctests.patch keywords: patch messages: 267190 nosy: Jelle Zijlstra, docs at python priority: normal severity: normal status: open title: make doctest fails on 2.7 release notes versions: Python 3.6 Added file: http://bugs.python.org/file43170/no27doctests.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 20:06:24 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 04 Jun 2016 00:06:24 +0000 Subject: [issue22257] PEP 432: Redesign the interpreter startup sequence In-Reply-To: <1408789351.84.0.0171822343712.issue22257@psf.upfronthosting.co.za> Message-ID: <1464998784.49.0.878308364581.issue22257@psf.upfronthosting.co.za> Nick Coghlan added the comment: I merged the current 3.6 dev branch into the BitBucket PEP 432 branch in my CPython sandbox. The attached patch is the diff between that branch and CPython default. All of the proposed changes here should only affect private APIs now, allowing this to be handled as a private refactoring with settings being migrated incrementally, rather than building up a large hard to maintain pending patch. Donald Stufft raised the prospect of potentially using these changes to create a nicer single-file executable builder that provides an alternate binary that just runs itself - statically linking needed extension modules and then prepending the resulting binary to a zip archive with a __main__.py file should support quite a few scenarios. I've also added Thomas Wouters to the nosy list, since Google have been looking at a range of options related to CPython startup and single file executables, which should provide a valuable perspective on the utility of these changes. ---------- keywords: +patch nosy: +dstufft, twouters Added file: http://bugs.python.org/file43171/pep432-startup-redesign-skeleton.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 20:13:38 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 04 Jun 2016 00:13:38 +0000 Subject: [issue25812] locale.nl_langinfo() can't decode value In-Reply-To: <1449350345.3.0.205814810685.issue25812@psf.upfronthosting.co.za> Message-ID: <1464999218.45.0.624790990231.issue25812@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Nina. We do have support in test.support for running a test with a specific locale (run_with_locale), so this could be turned into a unit test patch if you or someone else is willing to do that. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 20:16:14 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 04 Jun 2016 00:16:14 +0000 Subject: [issue24617] os.makedirs()'s [mode] not correct In-Reply-To: <1436721223.66.0.229120395272.issue24617@psf.upfronthosting.co.za> Message-ID: <1464999374.08.0.193240559954.issue24617@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for the patch Tommy. One minor quirk that bugs me: *mode*'s gets marked up with an opening quote rather than an apostrophe. Perhaps we can change it to a Unicode apostrophe (*mode*?s). Another alternative would be: the octal representation of *mode*. But looking at the code, makedirs() just passes ?mode? through to mkdir(). Maybe the mkdir() documentation needs updating too. Maybe it is better to just refer from makedirs() to mkdir(), rather than duplicating everything; I?m not sure. ---------- nosy: +martin.panter stage: -> patch review versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 20:16:40 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 04 Jun 2016 00:16:40 +0000 Subject: [issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects. In-Reply-To: <1384516983.26.0.0584971052865.issue19611@psf.upfronthosting.co.za> Message-ID: <1464999400.93.0.969606799991.issue19611@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Patch adding @cpython_only decorators to the tests. ---------- Added file: http://bugs.python.org/file43172/issue19611-decorators.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 20:18:28 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jun 2016 00:18:28 +0000 Subject: [issue22797] urllib.request.urlopen documentation falsely guarantees that a URLError will be raised on errors In-Reply-To: <1415120697.65.0.296811511924.issue22797@psf.upfronthosting.co.za> Message-ID: <20160604001820.21031.50434.35C63656@psf.io> Roundup Robot added the comment: New changeset b4df20312b78 by R David Murray in branch 'default': Clean up urlopen doc string. https://hg.python.org/cpython/rev/b4df20312b78 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 20:19:22 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 04 Jun 2016 00:19:22 +0000 Subject: [issue22797] urllib.request.urlopen documentation falsely guarantees that a URLError will be raised on errors In-Reply-To: <1415120697.65.0.296811511924.issue22797@psf.upfronthosting.co.za> Message-ID: <1464999562.17.0.456547781542.issue22797@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Alexander. ---------- resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 20:19:52 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 04 Jun 2016 00:19:52 +0000 Subject: [issue27203] Failing doctests in Doc/faq/programming.rst Message-ID: <1464999592.59.0.0136488038508.issue27203@psf.upfronthosting.co.za> New submission from Jelle Zijlstra: Patch attached. Added testsetup for the shared A variable and skipped doctests that rely on the return value of id(). ---------- files: faqdoctests.patch keywords: patch messages: 267197 nosy: Jelle Zijlstra priority: normal severity: normal status: open title: Failing doctests in Doc/faq/programming.rst Added file: http://bugs.python.org/file43173/faqdoctests.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 20:23:33 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 04 Jun 2016 00:23:33 +0000 Subject: [issue27204] Failing doctests in Doc/howto/ Message-ID: <1464999813.26.0.380989633833.issue27204@psf.upfronthosting.co.za> New submission from Jelle Zijlstra: Patch adds some imports, fixes doctests syntax, and skips Py2-only code. ---------- files: doctests-howto.patch keywords: patch messages: 267198 nosy: Jelle Zijlstra priority: normal severity: normal status: open title: Failing doctests in Doc/howto/ Added file: http://bugs.python.org/file43174/doctests-howto.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 20:27:00 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 04 Jun 2016 00:27:00 +0000 Subject: [issue27205] Failing doctests in Library/collections.rst Message-ID: <1465000020.63.0.799580126218.issue27205@psf.upfronthosting.co.za> New submission from Jelle Zijlstra: Mostly due to unspecified sorting order. The patch sorts a few tests and skips others that can't easily be sorted (e.g. most_common and str() output). ---------- assignee: docs at python components: Documentation files: doctests-collections.patch keywords: patch messages: 267199 nosy: Jelle Zijlstra, docs at python priority: normal severity: normal status: open title: Failing doctests in Library/collections.rst versions: Python 3.6 Added file: http://bugs.python.org/file43175/doctests-collections.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 20:33:33 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 04 Jun 2016 00:33:33 +0000 Subject: [issue25738] http.server doesn't handle RESET CONTENT status correctly In-Reply-To: <1448583978.87.0.253695569638.issue25738@psf.upfronthosting.co.za> Message-ID: <1465000413.89.0.903740263994.issue25738@psf.upfronthosting.co.za> R. David Murray added the comment: Well, the reason it makes sense to use send_error, or at least the reason I suspect a lot of people do it, is because then you don't have to call end_headers() yourself. So, acknowleding this, it might be worth mentioning in the docs that the body isn't sent for certain return codes. Especially seeing as we already do it for NO_CONTENT and NOT_MODIFIED. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 20:34:31 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jun 2016 00:34:31 +0000 Subject: [issue26373] asyncio: add support for async context manager on streams? In-Reply-To: <1455708621.94.0.460576626878.issue26373@psf.upfronthosting.co.za> Message-ID: <20160604003425.21718.78519.02BFD978@psf.io> Roundup Robot added the comment: New changeset 883cfb3e28f9 by Gregory P. Smith in branch '3.5': Fixes Issue #26373: subprocess.Popen.communicate now correctly ignores https://hg.python.org/cpython/rev/883cfb3e28f9 New changeset 78e81de6d447 by Gregory P. Smith in branch 'default': merge from 3.5 - Fixes Issue #26373: subprocess.Popen.communicate https://hg.python.org/cpython/rev/78e81de6d447 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 20:35:11 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 04 Jun 2016 00:35:11 +0000 Subject: [issue27206] Failing doctests in Doc/tutorial/ Message-ID: <1465000511.18.0.692311972692.issue27206@psf.upfronthosting.co.za> New submission from Jelle Zijlstra: Patch adds an import. ---------- assignee: docs at python components: Documentation files: doctests-tutorial.patch keywords: patch messages: 267202 nosy: Jelle Zijlstra, docs at python priority: normal severity: normal status: open title: Failing doctests in Doc/tutorial/ versions: Python 3.6 Added file: http://bugs.python.org/file43176/doctests-tutorial.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 20:36:59 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 04 Jun 2016 00:36:59 +0000 Subject: [issue26372] Popen.communicate not ignoring BrokenPipeError In-Reply-To: <1455672512.72.0.551664124622.issue26372@psf.upfronthosting.co.za> Message-ID: <1465000619.3.0.0684862991826.issue26372@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- resolution: -> fixed stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 20:37:54 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 04 Jun 2016 00:37:54 +0000 Subject: [issue27207] Failing doctests in Doc/whatsnew/3.2.rst Message-ID: <1465000673.79.0.877090352163.issue27207@psf.upfronthosting.co.za> New submission from Jelle Zijlstra: Mostly missing imports, some bad syntax, and a few typos. This patch fixes most but not all errors. ---------- assignee: docs at python components: Documentation files: doctests-whatsnew-32.patch keywords: patch messages: 267203 nosy: Jelle Zijlstra, docs at python priority: normal severity: normal status: open title: Failing doctests in Doc/whatsnew/3.2.rst versions: Python 3.6 Added file: http://bugs.python.org/file43177/doctests-whatsnew-32.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 20:38:55 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 04 Jun 2016 00:38:55 +0000 Subject: [issue26372] Popen.communicate not ignoring BrokenPipeError In-Reply-To: <1455672512.72.0.551664124622.issue26372@psf.upfronthosting.co.za> Message-ID: <1465000735.24.0.566031264944.issue26372@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Lukas - cc'ing you just in case this bug is related to the asyncio subprocess race condition-ish problems you were talking about at pycon. ---------- nosy: +lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 20:41:56 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 04 Jun 2016 00:41:56 +0000 Subject: [issue27208] Failing doctests in Library/traceback.rst Message-ID: <1465000916.52.0.195426294226.issue27208@psf.upfronthosting.co.za> New submission from Jelle Zijlstra: Updated to the output of current 3.6. ---------- assignee: docs at python components: Documentation files: doctests-traceback.patch keywords: patch messages: 267205 nosy: Jelle Zijlstra, docs at python priority: normal severity: normal status: open title: Failing doctests in Library/traceback.rst versions: Python 3.6 Added file: http://bugs.python.org/file43178/doctests-traceback.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 20:42:07 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 04 Jun 2016 00:42:07 +0000 Subject: [issue26372] Popen.communicate not ignoring BrokenPipeError In-Reply-To: <1455672512.72.0.551664124622.issue26372@psf.upfronthosting.co.za> Message-ID: <1465000927.93.0.577609954935.issue26372@psf.upfronthosting.co.za> Gregory P. Smith added the comment: the bot hasn't piped up with the changesets. these are the 3.5 and default fixes: remote: notified python-checkins at python.org of incoming changeset 883cfb3e28f9 remote: notified python-checkins at python.org of incoming changeset 78e81de6d447 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 20:43:48 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 04 Jun 2016 00:43:48 +0000 Subject: [issue27209] Failing doctests in Library/email.*.rst Message-ID: <1465001028.4.0.215960647749.issue27209@psf.upfronthosting.co.za> Changes by Jelle Zijlstra : ---------- assignee: docs at python components: Documentation files: doctests-email.patch keywords: patch nosy: Jelle Zijlstra, docs at python priority: normal severity: normal status: open title: Failing doctests in Library/email.*.rst versions: Python 3.6 Added file: http://bugs.python.org/file43179/doctests-email.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 20:44:45 2016 From: report at bugs.python.org (Tommy Beadle) Date: Sat, 04 Jun 2016 00:44:45 +0000 Subject: [issue24617] os.makedirs()'s [mode] not correct In-Reply-To: <1436721223.66.0.229120395272.issue24617@psf.upfronthosting.co.za> Message-ID: <1465001085.78.0.195610089901.issue24617@psf.upfronthosting.co.za> Tommy Beadle added the comment: I've fixed the apostrophe issue by avoiding it's use. I've moved the text about the mode to mkdir and added a link to it from makedirs. ---------- Added file: http://bugs.python.org/file43180/0001-Issue-24617-Add-comment-for-os.makedirs-about-certai.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 20:46:55 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 04 Jun 2016 00:46:55 +0000 Subject: [issue27210] Failing doctests due to environmental dependencies in Lib/*lib.rst Message-ID: <1465001215.61.0.0775726145069.issue27210@psf.upfronthosting.co.za> New submission from Jelle Zijlstra: The difflib test fails because "False" is close enough to "apple". The ftplib and nntplib tests rely on things downloaded from the web that are inherently variable. ---------- assignee: docs at python components: Documentation files: doctests-libs.patch keywords: patch messages: 267208 nosy: Jelle Zijlstra, docs at python priority: normal severity: normal status: open title: Failing doctests due to environmental dependencies in Lib/*lib.rst versions: Python 3.6 Added file: http://bugs.python.org/file43181/doctests-libs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 20:48:01 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 04 Jun 2016 00:48:01 +0000 Subject: [issue27200] make doctest in CPython has failures In-Reply-To: <1464988408.0.0.840317371896.issue27200@psf.upfronthosting.co.za> Message-ID: <1465001281.56.0.569762242567.issue27200@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Added a number of more specific issues with patches. I'll add more patches after the current ones are resolved. ---------- dependencies: +Failing doctests due to environmental dependencies in Lib/*lib.rst, Failing doctests in Doc/faq/programming.rst, Failing doctests in Doc/howto/, Failing doctests in Doc/tutorial/, Failing doctests in Doc/whatsnew/3.2.rst, Failing doctests in Library/collections.rst, Failing doctests in Library/email.*.rst, Failing doctests in Library/traceback.rst, make doctest fails on 2.7 release notes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 20:49:59 2016 From: report at bugs.python.org (Susumu Koshiba) Date: Sat, 04 Jun 2016 00:49:59 +0000 Subject: [issue25738] http.server doesn't handle RESET CONTENT status correctly In-Reply-To: <1448583978.87.0.253695569638.issue25738@psf.upfronthosting.co.za> Message-ID: <1465001399.48.0.192440362942.issue25738@psf.upfronthosting.co.za> Susumu Koshiba added the comment: Thanks, I've added some comments to the doc and updated the patch. ---------- Added file: http://bugs.python.org/file43182/issue25738_http_reset_content_02.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 20:51:19 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jun 2016 00:51:19 +0000 Subject: [issue24225] Idlelib: changing file names In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za> Message-ID: <20160604005115.1095.71689.61BE66E3@psf.io> Roundup Robot added the comment: New changeset 5dcc52d6829f by Ned Deily in branch 'default': Issue #24225: Fix additional renamed module references. https://hg.python.org/cpython/rev/5dcc52d6829f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 20:51:54 2016 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Sat, 04 Jun 2016 00:51:54 +0000 Subject: [issue26372] Popen.communicate not ignoring BrokenPipeError In-Reply-To: <1455672512.72.0.551664124622.issue26372@psf.upfronthosting.co.za> Message-ID: <1465001514.22.0.162414256667.issue26372@psf.upfronthosting.co.za> ?ukasz Langa added the comment: Thanks, I looked at this issue just today :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 21:02:02 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 04 Jun 2016 01:02:02 +0000 Subject: [issue27202] make doctest fails on 2.7 release notes In-Reply-To: <1464998646.05.0.234628246633.issue27202@psf.upfronthosting.co.za> Message-ID: <1465002122.76.0.57233860575.issue27202@psf.upfronthosting.co.za> Martin Panter added the comment: What failures are seeing, and what version of Sphinx are you using? Perhaps this is related to Issue 26638? ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 21:04:04 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 04 Jun 2016 01:04:04 +0000 Subject: [issue27202] make doctest fails on 2.7 release notes In-Reply-To: <1464998646.05.0.234628246633.issue27202@psf.upfronthosting.co.za> Message-ID: <1465002244.49.0.893585270289.issue27202@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- Removed message: http://bugs.python.org/msg267213 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 21:06:21 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 04 Jun 2016 01:06:21 +0000 Subject: [issue27202] make doctest fails on 2.7 release notes In-Reply-To: <1464998646.05.0.234628246633.issue27202@psf.upfronthosting.co.za> Message-ID: <1465002381.74.0.226463373732.issue27202@psf.upfronthosting.co.za> Martin Panter added the comment: Ignore my message; I was thinking of something different :) I presume you are running something like the following, which seems to smoke-test the examples in the documentation: make -C Doc doctest ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 21:14:15 2016 From: report at bugs.python.org (Chris Barker) Date: Sat, 04 Jun 2016 01:14:15 +0000 Subject: [issue27198] Adding an assertClose() method to unittest.TestCase In-Reply-To: <1464979712.74.0.398203716413.issue27198@psf.upfronthosting.co.za> Message-ID: <1465002855.03.0.135007948683.issue27198@psf.upfronthosting.co.za> Chris Barker added the comment: """w.r.t. error messages, a regular function that raises AssertionError with a nice message will be precisely as usable.""" sure -- I totally agree -- but that's not the current unittest API :-( where would you put it? How would people find it and know to use it? """The reason I'm pushing back on adding methods to TestCase is that every one we add collides with some number of subclasses out in the wild""" yup -- but again, the existing API :-( """ Long term I want to have entirely separate interfaces for these things, but thats even more radical an overhaul than adding matchers as a stock facility, and I don't currently have a planned timeline for starting on that. """ that i like -- but yeah, not this week :-). I also think the matchers thing is a nice idea, but still pretty heavy-weight, and it'll be along time before casual users and newbies will latch onto it.. """ So why can't we make assertAlmostEqual be this? Just add the extra parameter needed with a default value and change the implementation? """ That almost sound like your suggesting we actually change the assertAlmostEqual implementation -- that could be disastrous. On the other hand, you could add a relative_tolerance parameter, and if the user sets that, they are indicating that they want a relative test. I don't like that API: setting different optional parameters to select an algorithm, when you really just want a different function. On the other hand, it does keep us from polluting the namespace, and allows the documentation for them all to be in the same place, increasing the likelihood that it will be found when it should be. And if you ask me -- assertAlmostEqual should have had an algorithm like isclose() in the first place ;-) It will present an additional documentation challenge. (and a bit of ugly switching code. Now to find some time to do it -- my sprinting time is done :-( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 21:18:02 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 04 Jun 2016 01:18:02 +0000 Subject: [issue27202] make doctest fails on 2.7 release notes In-Reply-To: <1464998646.05.0.234628246633.issue27202@psf.upfronthosting.co.za> Message-ID: <1465003082.13.0.874073761039.issue27202@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Yes, I've been attempting to get that make to fully succeed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 21:22:45 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 04 Jun 2016 01:22:45 +0000 Subject: [issue25738] http.server doesn't handle RESET CONTENT status correctly In-Reply-To: <1448583978.87.0.253695569638.issue25738@psf.upfronthosting.co.za> Message-ID: <1465003365.71.0.62719325325.issue25738@psf.upfronthosting.co.za> Martin Panter added the comment: I suggest to drop the RESET_CONTENT exception. Content-Length: 0 is explicitly allowed by option a), and is not very different to the general case IMO. Content-Length was added here to help with buggy clients, see Issue 16088. But while we are here, I think we should avoid Content-Length for 304 Not Modified. See . This is a special case a bit like HEAD, where the length would refer to a cached response rather than the ?error?/explanation message. IMO this could be treated as a bug fix for 3.5 and 2.7, and no versionchanged is necessary. What do you think? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 21:28:52 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 04 Jun 2016 01:28:52 +0000 Subject: [issue25738] http.server doesn't handle RESET CONTENT status correctly In-Reply-To: <1448583978.87.0.253695569638.issue25738@psf.upfronthosting.co.za> Message-ID: <1465003732.95.0.85054296865.issue25738@psf.upfronthosting.co.za> Martin Panter added the comment: Ah, forget that bit about RESET_CONTENT. If we include Content-Length, it will probably be non-zero, which will be wrong. So your patch is better in that regard. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 21:37:47 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 04 Jun 2016 01:37:47 +0000 Subject: [issue27203] Failing doctests in Doc/faq/programming.rst In-Reply-To: <1464999592.59.0.0136488038508.issue27203@psf.upfronthosting.co.za> Message-ID: <1465004267.16.0.704060213432.issue27203@psf.upfronthosting.co.za> Martin Panter added the comment: make -C Doc/ suspicious fails: WARNING: [faq/programming:1177] ".. testsetup:" found in ".. testsetup::" Suspicious check complete; look for any errors in the above output or in build/suspicious/suspicious.csv. If all issues are false positives, append that file to tools/susp-ignored.csv. make: *** [suspicious] Error 1 [Exit 2] ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 21:46:25 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 04 Jun 2016 01:46:25 +0000 Subject: [issue27202] make doctest fails on 2.7 release notes In-Reply-To: <1464998646.05.0.234628246633.issue27202@psf.upfronthosting.co.za> Message-ID: <1465004785.38.0.78215139117.issue27202@psf.upfronthosting.co.za> Martin Panter added the comment: Since I stuck my neck out, I will say that this seems reasonable to me. We could probably still run doctest in the actual 2.7 branch to detect any errors there. ---------- stage: -> patch review versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 21:49:20 2016 From: report at bugs.python.org (Steve Dower) Date: Sat, 04 Jun 2016 01:49:20 +0000 Subject: [issue27179] subprocess uses wrong encoding on Windows In-Reply-To: <1464828766.51.0.809606583575.issue27179@psf.upfronthosting.co.za> Message-ID: <1465004960.61.0.396069449492.issue27179@psf.upfronthosting.co.za> Steve Dower added the comment: > so ANSI is the natural default for a detached process To clarify - ANSI is the natural default *for programs that don't support Unicode*. Unfortunately, since "Unicode" on Windows is an incompatible data type (wchar_t rather than char), targeting Unicode rather than a code page requires completely different API calls. This would make Python's implementation much more complicated, as well as breaking some scripts and existing packages. Forcing the use of UTF-8 as the code page is the easiest way for us to support it. I think Eryk clearly proved that we can't reliably assume or infer the right encoding for a subprocess. (When you use the ANSI APIs to print to the console, the console converts to Unicode for rendering. If you use the Unicode APIs there is no conversion, and so any codepage can be used internally without affecting what is displayed to the user.) In short: the best available fix is to expose encoding arguments in subprocess and to fix any calls within the stdlib that need to specify them. (When we decide to separate Python's API from the C Runtime API we can break file descriptors which will let us use Unicode APIs throughout, but that's a little way off.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 21:53:29 2016 From: report at bugs.python.org (=?utf-8?b?RMSBdmlz?=) Date: Sat, 04 Jun 2016 01:53:29 +0000 Subject: [issue27179] subprocess uses wrong encoding on Windows In-Reply-To: <1464828766.51.0.809606583575.issue27179@psf.upfronthosting.co.za> Message-ID: <1465005209.34.0.503048719983.issue27179@psf.upfronthosting.co.za> D?vis added the comment: > qprocess.exe (also to console) > quser.exe (also to console) these are broken (http://i.imgur.com/0zIhHrv.png) >chcp 1257 >quser USERNAME SESSIONNAME d?vis console > chcp 775 > quser USERNAME SESSIONNAME d?vis console we've to decide which codepage to use as default and it should cover most cases not some minority of programs so I would say using console's code page when it's available makes the most sense and when isn't then fallback to ANSI codepage Now for these special cases where our guess is wrong only user can know which encoding would be right and so he must specify that. I also checked that cmd /u flag is totally useless because it applies only to cmd itself not to any other programs and so to use it would need to check if returned output is actual UTF-16 or some other encoding which might even pass as valid UTF-16 for example: cmd /u /c "echo ?" will return ? in UTF-16 but cmd /u /c "sc query" result will be encoded in OEM codepage (775 for me) and no sign of UTF-16 I looked if there's some function to get used encoding for child process but there isn't, I would have expected something like GetConsoleOutputCP(hThread) So the only way to get it, is by calling GetConsoleOutputCP inside child process with CreateRemoteThread and it's not really pretty and quite hacky, but it does work, I tested. anyway even with that would need to change something about TextIOWrapper because we're creating it before process is even started and encoding isn't changeable later. I updated patch which fixes issues with creationflags and also added option to change encoding based on subprocess3.patch (from #6135) so now with my patch it really works for most cases. >python -c "import subprocess; subprocess.getstatusoutput('?')" works correctly for me with correct encoding when console's code page is set to any of 775 (OEM), 1257 (ANSI) and 65001 (UTF-8) it also works correctly with any of DETACHED_PROCESS, CREATE_NEW_CONSOLE, CREATE_NO_WINDOW >python -c "import subprocess; subprocess.getstatusoutput('?', creationflags=0x00000008)" this also works correctly with console's encodings: 775, 1257, 65001 >python -c "from distutils import _msvccompiler; _msvccompiler._get_vc_env('')" and finally > chcp 1257 > python -c "import subprocess; print(subprocess.check_output('quser', encoding='cp775'))" USERNAME SESSIONNAME d?vis console also works correctly with any of console's encoding even if it didn't showed correct encoding inside cmd itself. ---------- Added file: http://bugs.python.org/file43183/subprocess_fix_encoding_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 22:28:24 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jun 2016 02:28:24 +0000 Subject: [issue20567] test_idle causes test_ttk_guionly 'can't invoke "event" command: application has been destroyed' messages from Tk In-Reply-To: <1391902578.02.0.588798272285.issue20567@psf.upfronthosting.co.za> Message-ID: <20160604022821.21761.66185.0274F632@psf.io> Roundup Robot added the comment: New changeset 813bb6a4c693 by Terry Jan Reedy in branch '3.5': Issue 20567: Revise idle_test/README.txt and some tests to match new advice. https://hg.python.org/cpython/rev/813bb6a4c693 New changeset d8e5e3da4d57 by Terry Jan Reedy in branch 'default': Issue 20567: Revise idle_test/README.txt and some tests to match new advice. https://hg.python.org/cpython/rev/d8e5e3da4d57 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 22:31:15 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 04 Jun 2016 02:31:15 +0000 Subject: [issue20567] test_idle causes test_ttk_guionly 'can't invoke "event" command: application has been destroyed' messages from Tk In-Reply-To: <1391902578.02.0.588798272285.issue20567@psf.upfronthosting.co.za> Message-ID: <1465007475.39.0.35872175213.issue20567@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 23:10:39 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 04 Jun 2016 03:10:39 +0000 Subject: [issue27198] Adding an assertClose() method to unittest.TestCase In-Reply-To: <1464979712.74.0.398203716413.issue27198@psf.upfronthosting.co.za> Message-ID: <1465009839.89.0.914867945875.issue27198@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, I find assertClose easy to misinterpret. At first, it looks like an assertion that a file is closed. And once you mentally pronounce it like "close something that is open", it is harder to make the jump to "close as in nearby". Also, I feed there is very little need for this. that we don't need another way to do it, and that the menagerie of specific asserts is getting harder to learn and remember (i.e. is easier to make up new assert methods than it is to remember what someone else wanted to name it). ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 23:14:30 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 04 Jun 2016 03:14:30 +0000 Subject: [issue25548] Show the address in the repr for class objects In-Reply-To: <1446576011.58.0.372024983976.issue25548@psf.upfronthosting.co.za> Message-ID: <1465010070.69.0.700003807331.issue25548@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks Kushal. It looks like we had a race condition ;-) I'll assign it back after Nofar's work is in and reconciled. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 3 23:58:55 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jun 2016 03:58:55 +0000 Subject: [issue27196] Eliminate 'ThemeChanged' warning when running IDLE tests In-Reply-To: <1464940807.02.0.170350027457.issue27196@psf.upfronthosting.co.za> Message-ID: <20160604035850.13681.841.44382D00@psf.io> Roundup Robot added the comment: New changeset 0207c6203f84 by Terry Jan Reedy in branch '3.5': Issue #27196: Stop 'application destroyed' warnings when running IDLE tests. https://hg.python.org/cpython/rev/0207c6203f84 New changeset 2d864ac472f0 by Terry Jan Reedy in branch 'default': Merge issue #27196 from 3.5: Stop IDLE test 'application destroyed' warnings. https://hg.python.org/cpython/rev/2d864ac472f0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 00:15:54 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 04 Jun 2016 04:15:54 +0000 Subject: [issue20567] test_idle causes test_ttk_guionly 'can't invoke "event" command: application has been destroyed' messages from Tk In-Reply-To: <1391902578.02.0.588798272285.issue20567@psf.upfronthosting.co.za> Message-ID: <1465013754.41.0.639575494325.issue20567@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Using update_idletasks msg229182 is #27196; it succeeded in stopping ThemeChanged warnings. Using 'no-default-root' msg229201 is #24137. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 00:17:47 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 04 Jun 2016 04:17:47 +0000 Subject: [issue27196] Eliminate 'ThemeChanged' warning when running IDLE tests In-Reply-To: <1464940807.02.0.170350027457.issue27196@psf.upfronthosting.co.za> Message-ID: <1465013867.17.0.818244774901.issue27196@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I closed #20567 after finishing what I intended to do 3 years ago. I decided make this a separate issue for trying Serhiy's suggestion of updata_idletasks. Pursuing 'no default root' is #24137. 3 other files also gave the warning, once, when run alone. 2 of the 4 'warned with the test suite in 3.5 and 3 of 4 in 3.6. Adding root.update or root.update_idletasks to all 4 fixed all warnings I know of for both versions. It appears to be a coincidence that the warnings consistently appeared where they did. I also added a note about this fix to README.txt. There is no known problem in 2.7. I fixed 3.5 also because the warnings sometimes appear in buildbot reports, and they don't need the noise. ---------- assignee: -> terry.reedy resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 00:26:31 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 04 Jun 2016 04:26:31 +0000 Subject: [issue24225] Idlelib: changing file names In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za> Message-ID: <1465014391.29.0.42319690698.issue24225@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Thanks. Did you grep the whole repository for 'idlelib' or did you think to look for the latter two? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 01:17:56 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jun 2016 05:17:56 +0000 Subject: [issue20567] test_idle causes test_ttk_guionly 'can't invoke "event" command: application has been destroyed' messages from Tk In-Reply-To: <1391902578.02.0.588798272285.issue20567@psf.upfronthosting.co.za> Message-ID: <1465017476.19.0.849416565149.issue20567@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: -To avoid interfering with other GUI tests, all GUI objects must be +To avoid interfering with other gui tests, all gui objects must be destroyed and Why "gui" is in lower case? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 01:18:45 2016 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 04 Jun 2016 05:18:45 +0000 Subject: [issue27211] Heap corruption via Python 2.7.11 IOBase readline() Message-ID: <1465017525.1.0.917023415627.issue27211@psf.upfronthosting.co.za> New submission from Benjamin Peterson: Guido Vranken on PSRT report: Python-2.7.11/Modules/_io/iobase.c iobase_readline(): 531 old_size = PyByteArray_GET_SIZE(buffer); 532 PyByteArray_Resize(buffer, old_size + PyBytes_GET_SIZE(b)); 533 memcpy(PyByteArray_AS_STRING(buffer) + old_size, 534 PyBytes_AS_STRING(b), PyBytes_GET_SIZE(b)); PyByteArray_Resize() relies on realloc(), and thus can fail if there is insufficient memory. However, the return value of PyByteArray_Resize() is not checked in iobase_readline(). So if PyByteArray_Resize() fails, the memory area is too small for the data that memcpy will write. Proof Of Concept ---------------- First create a file with very long lines: with open('out.xxx', 'wb') as fp: fp.write('x' * (1024*1024*64)) fp.write('\n') Zip it: $ zip out.xxx.zip out.xxx Set a smallish memory limit $ ulimit -Sv 70000 Then run: import zipfile zf = zipfile.ZipFile('out.xxx.zip', 'r') f = zf.open('out.xxx') r = "x" * (1024*1024*20) f.readline() r = "" ---------------- For me this configuration resulted in *** Error in `./python': realloc(): invalid next size: 0x00000000024b2f20 *** Aborted You might need to experiment a bit with the parameters (length of lines, size of 'r', ulimit) to get a similar result. But there is a bug there. Let me know if you need more information from me. ---------- messages: 267231 nosy: benjamin.peterson priority: normal severity: normal status: open title: Heap corruption via Python 2.7.11 IOBase readline() type: security versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 01:20:28 2016 From: report at bugs.python.org (Ned Deily) Date: Sat, 04 Jun 2016 05:20:28 +0000 Subject: [issue24225] Idlelib: changing file names In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za> Message-ID: <1465017628.45.0.626406521019.issue24225@psf.upfronthosting.co.za> Ned Deily added the comment: I just tried to run IDLE from the command line as a (UNIX) user would. And then I grepped. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 01:22:23 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jun 2016 05:22:23 +0000 Subject: [issue27211] Heap corruption via Python 2.7.11 IOBase readline() In-Reply-To: <1465017525.1.0.917023415627.issue27211@psf.upfronthosting.co.za> Message-ID: <20160604052220.23373.79572.7B4516C8@psf.io> Roundup Robot added the comment: New changeset afbd4473947a by Benjamin Peterson in branch '2.7': check the result of PyByteArray_Resize in readline() (closes #27211) https://hg.python.org/cpython/rev/afbd4473947a ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 01:31:23 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jun 2016 05:31:23 +0000 Subject: [issue27211] Heap corruption via Python 2.7.11 IOBase readline() In-Reply-To: <1465017525.1.0.917023415627.issue27211@psf.upfronthosting.co.za> Message-ID: <1465018283.44.0.497471741919.issue27211@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This bug was fixed for 3.x in issue18408. Maybe we should backport other Victor's fixes from this issue. Yet one possible bug -- using memcpy instead of memmove. The memory block can be resized without changing the address. ---------- nosy: +haypo, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 01:31:34 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jun 2016 05:31:34 +0000 Subject: [issue22797] urllib.request.urlopen documentation falsely guarantees that a URLError will be raised on errors In-Reply-To: <1415120697.65.0.296811511924.issue22797@psf.upfronthosting.co.za> Message-ID: <20160604053131.119955.79030.D5CA9ADB@psf.io> Roundup Robot added the comment: New changeset 2d69d0419879 by Martin Panter in branch 'default': Issue #22797: Synchronize urlopen() doc string with RST documentation https://hg.python.org/cpython/rev/2d69d0419879 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 01:33:47 2016 From: report at bugs.python.org (alex0307) Date: Sat, 04 Jun 2016 05:33:47 +0000 Subject: [issue27212] Doc for itertools, 'islice()' implementation have unwanted behavior for recipe 'consume()' Message-ID: <1465018426.98.0.63725897135.issue27212@psf.upfronthosting.co.za> New submission from alex0307: In the doc for itertools, the python implementation of islice() doesn't actually perform the iteration when given an empty slice (e.g. islice(it,3,3)). This is not the expected behavior for 'consume()' in the recipe given below, i.e. consume(it,3) couldn't actually advance the iterator for 3 steps ahead. Instead, the iterator stays at its starting position. As a simple fix, in the implementation of islice(), the length of the slice object should be checked first. If it's zero, the iterator should be advanced (slice.start-1) times, and return (See islice_my.py) ---------- assignee: docs at python components: Documentation files: islice_my.py messages: 267236 nosy: alex0307, docs at python priority: normal severity: normal status: open title: Doc for itertools, 'islice()' implementation have unwanted behavior for recipe 'consume()' type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file43184/islice_my.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 01:41:29 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jun 2016 05:41:29 +0000 Subject: [issue27212] Doc for itertools, 'islice()' implementation have unwanted behavior for recipe 'consume()' In-Reply-To: <1465018426.98.0.63725897135.issue27212@psf.upfronthosting.co.za> Message-ID: <1465018889.07.0.997644999415.issue27212@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: docs at python -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 02:33:38 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 04 Jun 2016 06:33:38 +0000 Subject: [issue20567] test_idle causes test_ttk_guionly 'can't invoke "event" command: application has been destroyed' messages from Tk In-Reply-To: <1391902578.02.0.588798272285.issue20567@psf.upfronthosting.co.za> Message-ID: <1465022018.23.0.473364766278.issue20567@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Because I copied from 2.7, which had not been corrected from what I wrote years ago before we started being more consistent and correct. Fixed in all 3 versions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 02:48:58 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 04 Jun 2016 06:48:58 +0000 Subject: [issue24238] Avoid entity expansion attacks in Element Tree In-Reply-To: <1432034279.35.0.728988379999.issue24238@psf.upfronthosting.co.za> Message-ID: <1465022938.73.0.664741683902.issue24238@psf.upfronthosting.co.za> Martin Panter added the comment: Today I discovered that Christian?s defusedxml project already does the same sort of thing. The difference is he calls the parameter forbid_entities. So I have updated my patch and changed the name from reject_entities to forbid_entities for compatibility. ---------- versions: +Python 3.6 -Python 3.5 Added file: http://bugs.python.org/file43185/etree-entities.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 02:56:50 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 04 Jun 2016 06:56:50 +0000 Subject: [issue26779] pdb continue followed by an exception in the same frame shows incorrect frame linenumber In-Reply-To: <1460812092.64.0.640871964672.issue26779@psf.upfronthosting.co.za> Message-ID: <1465023410.28.0.0413618478729.issue26779@psf.upfronthosting.co.za> Xavier de Gaye added the comment: See also issue 24565. ---------- nosy: +xdegaye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 03:06:23 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 04 Jun 2016 07:06:23 +0000 Subject: [issue24617] os.makedirs()'s [mode] not correct In-Reply-To: <1436721223.66.0.229120395272.issue24617@psf.upfronthosting.co.za> Message-ID: <1465023983.84.0.90158643176.issue24617@psf.upfronthosting.co.za> Martin Panter added the comment: I think it would be good to move the sentence about FileExistsError away from your new paragraph about *mode*. Also, I would try to make the hyperlink a bit more explicit and descriptive, maybe The *mode* parameter is passed to :func:`mkdir`; see :ref:`the mkdir() description ` for how it is interpreted. ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 03:45:34 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jun 2016 07:45:34 +0000 Subject: [issue27213] Rework CALL_FUNCTION* opcodes Message-ID: <1465026334.02.0.369802561902.issue27213@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Currently there are 4 opcodes (CALL_FUNCTION, CALL_FUNCTION_VAR, CALL_FUNCTION_KW, CALL_FUNCTION_VAR_KW) for calling a function depending of presenting the var-positional and var-keyword arguments: func(arg1, ..., argN, name1=kwarg1, ..., nameM=kwargM) func(arg1, ..., argN, *args, name1=kwarg1, ..., nameM=kwargM) func(arg1, ..., argN, name1=kwarg1, ..., nameM=kwargM, **kwargs) func(arg1, ..., argN, *args, name1=kwarg1, ..., nameM=kwargM, **kwargs) The number of positional and keyword arguments are packed in oparg, and both numbers are limited by 255. Thus the single keyword argument makes oparg not fitting in 8 bit and requires EXTENDED_ARG. The stack contains first positional arguments, then optional args tuple, then keyword arguments, then optional kwargs dict. For every keyword argument the two values are pushed on the stack: argument name (always constant string) and argument value. I collected a statistic about opcodes in compiled code during running Python tests [1] (maybe it is biased, but this is large and multifarious assembly, and I hope it takes some representation about average Python code). According to it about 90% of compiled function calls are calls with the fixed number of positional arguments (CALL_FUNCTION with oparg < 256), the rest 10% are calls with the fixed number of positional and keyword arguments (CALL_FUNCTION with oparg >= 256), and only about 0.5% are calls with the var-positional or var-keyword arguments. I propose to use the different sets of opcodes that corresponds to these cases: func(arg1, ..., argN) func(arg1, ..., argN, name1=kwarg1, ..., nameM=kwargM) func(*args, **kwargs) 1. CALL_FUNCTION takes the fixed number of positional arguments. oparg is the number of arguments. The stack contains positional arguments. 2. CALL_FUNCTION_KW takes the fixed number of positional and keyword arguments. oparg is the number of all arguments. The stack contains values of arguments (first positional, then keyword), then a tuple of keyword names (as in proposed new opcode BUILD_CONST_KEY_MAP in issue27140). 3. CALL_FUNCTION_EX takes the variable number of positional and keyword arguments. oparg is 0. The stack contains a tuple of positional arguments and a dict of keyword arguments (they are build in the bytecode with using BUILD_TUPLE, BUILD_CONST_KEY_MAP, BUILD_LIST_UNPACK and BUILD_MAP_UNPACK_WITH_CALL). This is the most general variant, others exist just for the optimization of common cases. Benefits: 1. Calling a function with keyword arguments uses less stack and less LOAD_CONST instructions. 2. Calling a function with keyword arguments no longer needs EXTENDED_ARG. 3. The number of positional and keyword arguments is no longer limited by 255 (at least not in the bytecode). 4. The bytecode looks simpler, oparg always is just the number of arguments taken from the stack. This proposition was discussed on Python-Ideas [2]. [1] http://permalink.gmane.org/gmane.comp.python.ideas/39993 [2] http://comments.gmane.org/gmane.comp.python.ideas/39961 ---------- components: Interpreter Core messages: 267241 nosy: serhiy.storchaka priority: normal severity: normal status: open title: Rework CALL_FUNCTION* opcodes type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 03:46:00 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jun 2016 07:46:00 +0000 Subject: [issue27213] Rework CALL_FUNCTION* opcodes In-Reply-To: <1465026334.02.0.369802561902.issue27213@psf.upfronthosting.co.za> Message-ID: <1465026360.45.0.255308714765.issue27213@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Opcode for creating dict with constant keys _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 04:00:31 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 04 Jun 2016 08:00:31 +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: <1465027231.74.0.00782786753165.issue16484@psf.upfronthosting.co.za> Martin Panter added the comment: It seems the test is broken on Windows: http://buildbot.python.org/all/builders/x86%20Windows7%203.5/builds/915/steps/test/logs/stdio ====================================================================== ERROR: test_mixed_case_module_names_are_lower_cased (test.test_pydoc.PydocDocTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\cygwin\home\db3l\buildarea\3.5.bolen-windows7\build\lib\test\test_pydoc.py", line 458, in test_mixed_case_module_names_are_lower_cased self.assertIn('xml.etree.elementtree', doc_link) File "D:\cygwin\home\db3l\buildarea\3.5.bolen-windows7\build\lib\unittest\case.py", line 1076, in assertIn if member not in container: TypeError: argument of type 'NoneType' is not iterable ---------- status: closed -> open versions: +Python 3.6 -Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 04:04:21 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 04 Jun 2016 08:04:21 +0000 Subject: [issue26373] asyncio: add support for async context manager on streams? In-Reply-To: <1455708621.94.0.460576626878.issue26373@psf.upfronthosting.co.za> Message-ID: <1465027461.11.0.421364444795.issue26373@psf.upfronthosting.co.za> Martin Panter added the comment: Above two commits were actuall for Issue 26372 ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 04:05:36 2016 From: report at bugs.python.org (Oren Milman) Date: Sat, 04 Jun 2016 08:05:36 +0000 Subject: [issue27214] a potential future bug and an optimization that mostly undermines performance in long_invert Message-ID: <1465027536.85.0.992865355802.issue27214@psf.upfronthosting.co.za> New submission from Oren Milman: ------------ the current state ------------ long_invert first checks whether v is a single-digit int. If it is, it simply does 'return PyLong_FromLong(-(MEDIUM_VALUE(v) + 1));'. Otherwise, long_invert does (edited for brevity) 'x = long_add(v, PyLong_FromLong(1));', and then negates x in-place. In other words, long_invert assumes long_add hasn't returned a reference to an element of small_ints. However, if all of the following conditions are true: * NSMALLNEGINTS is maximized (i.e. NSMALLNEGINTS == 2 ** PyLong_SHIFT - 1). * long_add is changed in such a way that if someone does (in Python) '-2 ** PyLong_SHIFT + 1' while NSMALLNEGINTS is maximized, long_add would return a reference to an element of small_ints. (Actually, I have recently opened an issue that proposes such a change - http://bugs.python.org/issue27145.) * long_invert is called for (-2 ** PyLong_SHIFT). Then long_invert would negate in-place an element of small_ints. In addition, because long_invert first checks whether v is a single-digit int, calling maybe_small_long before returning would save up memory only in case both of the following conditions are true: * NSMALLPOSINTS is maximized (i.e. NSMALLPOSINTS == 2 ** PyLong_SHIFT). * long_invert is called for (-2 ** PyLong_SHIFT). So the call to maybe_small_long introduces a performance penalty for every case where v is a multiple-digit int (and long_invert doesn't fail), while the only case where it actually saves up memory is the aforementioned corner case. ------------ the proposed changes ------------ Both of the proposed changes are in Objects/longobject.c in long_invert: 1. Replace the in-place negation with a call to _PyLong_Negate, which safely negates an int. 2. Remove the call to maybe_small_long. maybe_small_long was added to long_invert in revision 48567, as part of an effort to wipe out different places in the code where small_ints could be used (and saved up memory), but was not. I am not sure why maybe_small_long was also added to long_invert back then, even though it mostly undermines performance. ------------ diff ------------ The patches diff is attached. ------------ tests ------------ I built the patched CPython for x86, and played with it a little. Everything seemed to work as usual. In addition, I ran 'python_d.exe -m test -j3' (on my 64-bit Windows 10) with and without the patches, and got quite the same output. the outputs of both runs are attached. ---------- components: Interpreter Core files: proposedPatches.diff keywords: patch messages: 267244 nosy: Oren Milman priority: normal severity: normal status: open title: a potential future bug and an optimization that mostly undermines performance in long_invert type: performance Added file: http://bugs.python.org/file43186/proposedPatches.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 04:06:01 2016 From: report at bugs.python.org (Oren Milman) Date: Sat, 04 Jun 2016 08:06:01 +0000 Subject: [issue27214] a potential future bug and an optimization that mostly undermines performance in long_invert In-Reply-To: <1465027536.85.0.992865355802.issue27214@psf.upfronthosting.co.za> Message-ID: <1465027561.09.0.420749522061.issue27214@psf.upfronthosting.co.za> Changes by Oren Milman : Added file: http://bugs.python.org/file43187/CPythonTestOutput.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 04:06:27 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 04 Jun 2016 08:06:27 +0000 Subject: [issue26372] Popen.communicate not ignoring BrokenPipeError In-Reply-To: <1455672512.72.0.551664124622.issue26372@psf.upfronthosting.co.za> Message-ID: <1465027587.83.0.829677237839.issue26372@psf.upfronthosting.co.za> Martin Panter added the comment: Maybe use os.devnull instead of "/dev/null"? http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/7728/steps/test/logs/stdio ====================================================================== ERROR: test_communicate_BrokenPipeError_stdin_flush (test.test_subprocess.ProcessTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_subprocess.py", line 1267, in test_communicate_BrokenPipeError_stdin_flush open('/dev/null', 'wb') as dev_null: FileNotFoundError: [Errno 2] No such file or directory: '/dev/null' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 04:06:49 2016 From: report at bugs.python.org (Oren Milman) Date: Sat, 04 Jun 2016 08:06:49 +0000 Subject: [issue27214] a potential future bug and an optimization that mostly undermines performance in long_invert In-Reply-To: <1465027536.85.0.992865355802.issue27214@psf.upfronthosting.co.za> Message-ID: <1465027609.09.0.517297415756.issue27214@psf.upfronthosting.co.za> Changes by Oren Milman : Added file: http://bugs.python.org/file43188/patchedCPythonTestOutput.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 04:11:37 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jun 2016 08:11:37 +0000 Subject: [issue27214] a potential future bug and an optimization that mostly undermines performance in long_invert In-Reply-To: <1465027536.85.0.992865355802.issue27214@psf.upfronthosting.co.za> Message-ID: <1465027897.22.0.255895730554.issue27214@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +mark.dickinson, serhiy.storchaka stage: -> patch review versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 04:29:01 2016 From: report at bugs.python.org (STINNER Victor) Date: Sat, 04 Jun 2016 08:29:01 +0000 Subject: [issue27179] subprocess uses wrong encoding on Windows In-Reply-To: <1465005209.34.0.503048719983.issue27179@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: "To clarify - ANSI is the natural default *for programs that don't support Unicode*." Exactly. For this reason, I am stronly opposed to chnage the default encoding. I'm ok to add helper functions or new flags. It looks like it took more than five years to support well Unicode in Python 3 on UNIX, and that we now have to enhance "Unicode support" (use the right encoding, use a real Unicode API) on Windows :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 04:33:20 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 04 Jun 2016 08:33:20 +0000 Subject: [issue26915] Test identity first in membership operation of ItemsView, ValuesView and Sequence in collections.abc In-Reply-To: <1462256356.96.0.954300432794.issue26915@psf.upfronthosting.co.za> Message-ID: <1465029200.99.0.203044056545.issue26915@psf.upfronthosting.co.za> Xiang Zhang added the comment: Thanks for review Serhiy and nice thoughts. I make the class inherited directly from Sequence. So if the methods in Sequence are OK, the test class is OK. ---------- Added file: http://bugs.python.org/file43189/issue26915_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 04:42:28 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 04 Jun 2016 08:42:28 +0000 Subject: [issue26915] Test identity first in membership operation of ItemsView, ValuesView and Sequence in collections.abc In-Reply-To: <1462256356.96.0.954300432794.issue26915@psf.upfronthosting.co.za> Message-ID: <1465029748.52.0.728234006754.issue26915@psf.upfronthosting.co.za> Xiang Zhang added the comment: Oh, sorry. Make the __len__ signature wrong. Change it. ---------- Added file: http://bugs.python.org/file43190/issue26915_v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 05:16:42 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 04 Jun 2016 09:16:42 +0000 Subject: [issue26939] android: test_functools hangs on armv7 In-Reply-To: <1462289866.52.0.349587333392.issue26939@psf.upfronthosting.co.za> Message-ID: <1465031802.37.0.899343553699.issue26939@psf.upfronthosting.co.za> Changes by Xavier de Gaye : Added file: http://bugs.python.org/file43191/test_lru_cache_threaded-x86-printf.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 05:16:57 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 04 Jun 2016 09:16:57 +0000 Subject: [issue26939] android: test_functools hangs on armv7 In-Reply-To: <1462289866.52.0.349587333392.issue26939@psf.upfronthosting.co.za> Message-ID: <1465031817.0.0.947710356794.issue26939@psf.upfronthosting.co.za> Changes by Xavier de Gaye : Added file: http://bugs.python.org/file43192/test_lru_cache_threaded-armv7-printf.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 05:20:17 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 04 Jun 2016 09:20:17 +0000 Subject: [issue27215] Docstrings of Sequence and MutableSequence seems not right Message-ID: <1465032017.04.0.0861396062626.issue27215@psf.upfronthosting.co.za> New submission from Xiang Zhang: Docstrings of Sequence and MutableSequence in collections.abc says "Concrete subclasses must provide __new__ and __init__". This seems not the truth. Not providing __new__ and __init__ is also OK. ---------- messages: 267249 nosy: rhettinger, xiang.zhang priority: normal severity: normal status: open title: Docstrings of Sequence and MutableSequence seems not right _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 05:20:20 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 04 Jun 2016 09:20:20 +0000 Subject: [issue26939] android: test_functools hangs on armv7 In-Reply-To: <1462289866.52.0.349587333392.issue26939@psf.upfronthosting.co.za> Message-ID: <1465032020.9.0.16389261201.issue26939@psf.upfronthosting.co.za> Xavier de Gaye added the comment: pycond_timedwait_2.patch prints the delta time in microseconds when deadline is in the past. Running the patch with the following command: python -m test -m test_lru_cache_threaded -v test_functools gives these results: a) natively: deadline is never in the past and the test run prints only a bunch of 'Ok's. b) on the x86 emulator: Although the test does not hang when python is not patched, the output of the test run, test_lru_cache_threaded-x86-printf.txt, shows that deadline is almost always in the past. c) on the armv7 emulator: The output of the test run, test_lru_cache_threaded-armv7-printf.txt (this is a truncated version, the original file is half a Mbytes long), shows that deadline is always in the past. With the patch, the test does not hang. It is possible that this problem could be a quirk in the implementation of the qemu emulator, given the results of b), and the fact that the python test suite runs at about the same speed when run natively and on the x86 emulator. ---------- Added file: http://bugs.python.org/file43193/pycond_timedwait_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 06:11:25 2016 From: report at bugs.python.org (Alex Chan) Date: Sat, 04 Jun 2016 10:11:25 +0000 Subject: [issue27216] Fix capitalisation of "Python runtime" in os.path.islink description Message-ID: <1465035085.6.0.0369586412077.issue27216@psf.upfronthosting.co.za> New submission from Alex Chan: Since Python is a proper noun, it should be capitalised. Fix a case where the docs used lowercase "python". The phrase "by the python runtime" was added in the 2.7 docs; the 2.6 docs just say "if symbolic links are not supported". ---------- assignee: docs at python components: Documentation files: capitalisation.patch keywords: patch messages: 267251 nosy: alexwlchan, docs at python priority: normal severity: normal status: open title: Fix capitalisation of "Python runtime" in os.path.islink description type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file43194/capitalisation.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 07:24:01 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jun 2016 11:24:01 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1465039441.35.0.971403958023.issue5124@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch that makes pasting text in all Text, Entry and Spinbox widgets to delete selection. ---------- stage: test needed -> patch review Added file: http://bugs.python.org/file43195/idle_paste_replace.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 08:59:39 2016 From: report at bugs.python.org (ppperry) Date: Sat, 04 Jun 2016 12:59:39 +0000 Subject: [issue27215] Docstrings of Sequence and MutableSequence seems not right In-Reply-To: <1465032017.04.0.0861396062626.issue27215@psf.upfronthosting.co.za> Message-ID: <1465045179.31.0.885218221894.issue27215@psf.upfronthosting.co.za> Changes by ppperry : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 09:00:45 2016 From: report at bugs.python.org (ppperry) Date: Sat, 04 Jun 2016 13:00:45 +0000 Subject: [issue27215] Docstrings of Sequence and MutableSequence seems not right In-Reply-To: <1465032017.04.0.0861396062626.issue27215@psf.upfronthosting.co.za> Message-ID: <1465045245.73.0.660204191008.issue27215@psf.upfronthosting.co.za> Changes by ppperry : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 10:14:26 2016 From: report at bugs.python.org (Ram Rachum) Date: Sat, 04 Jun 2016 14:14:26 +0000 Subject: [issue27181] Add geometric mean to `statistics` module In-Reply-To: <1464901494.08.0.0111988914026.issue27181@psf.upfronthosting.co.za> Message-ID: <1465049666.41.0.680086913009.issue27181@psf.upfronthosting.co.za> Ram Rachum added the comment: And of course, if the goal of the `statistics` module is to be comprehensive, one should ask himself what should be the difference between this new module and a mature statistics module like `scipy.stats`, and whether we should try to copy the features of off `scipy.stats`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 10:24:01 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 04 Jun 2016 14:24:01 +0000 Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX) In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za> Message-ID: <1465050241.59.0.841731746859.issue26439@psf.upfronthosting.co.za> Martin Panter added the comment: Okay here are some more thoughts about your latest patch: ## Automatic RTLD_MEMBER ## I was still uneasy about the automatic setting of RTLD_MEMBER. But I looked for how others handle this, and I found Libtool?s LTDL library, and Apache Portable Runtime (APR). Both have a similar (but stricter) automatic addition based on detecting the archive(member) notation: http://git.savannah.gnu.org/cgit/libtool.git/commit/libltdl/loaders/dlopen.c?id=8fa719e https://github.com/apache/apr/commit/c27f8d2 So I guess I can accept this way, if you think it is better than my other ideas: # Always uses RTLD_MEMBER, never loads a plain file outside an archive name = "libcrypto.a(libcrypto.so.1.0.0)" # Other options, that could be returned by find_library() and would not conflict with a plain file name name = ("libcrypto.a", "libcrypto.so.1.0.0") # (archive, member) name = ("libcrypto.a(libcrypto.so.1.0.0)", RTLD_MEMBER) # (name, extra-flags) libcrypto = CDLL(name) ## find_library() modes ## In your find_library() function, you still have three parts. Can you confirm that each behaviour is intended: A) If I have a file called "crypto" in the current directory, find_library("crypto") returns "crypto". This does not seem right. On Linux, ?gcc [. . .] -lcrypto? does not look for a file exactly called ?crypto?. B) You are still stripping bits off the library name if it contains ?lib? or a dot (.), so find_library("glib-2.0") is almost equivalent to find_library("b-2"). Isn?t this a bug? C) find_library("crypto") will return "/usr/lib/crypto" if such a file exists. Just like in A), this does not seem right to me. ## Other things ## * You don?t need to prefix most names with underscores, unless they could be confused with a public API. If you follow my earlier suggestion of renaming the new file to _aixutil.py (so it is obvious it is not a public module), then you can freely write ?import re, os, sys?, etc. * No need to add the internal variable names to the function signatures. Just write find_library(name), and if you need to initialize a variable, do that in the body. * I suggest to go over all the regular expressions, and either change them to plain string searching, or make sure special characters and external variables are escaped as necessary. A comment explaining what the RE is trying to do might help too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 11:07:25 2016 From: report at bugs.python.org (Glenn Travis) Date: Sat, 04 Jun 2016 15:07:25 +0000 Subject: [issue27217] IDLE 3.5.1 not using Tk 8.6 Message-ID: <1465052845.59.0.651456701711.issue27217@psf.upfronthosting.co.za> New submission from Glenn Travis: I do not know if this is truly an issue, but it is a concern to me. I installed Tk 8.6 after reading all the Macintosh OS warnings online and in the IDLE window. However, according to the About IDLE box, IDLE is still "using" 8.5; and the warning still appears when I open IDLE. I may have missed it, but I did not see any way update IDLE or some Unix file to correct this in the online documentation. ---------- files: About IDLE.png messages: 267255 nosy: Old Sub Sailor priority: normal severity: normal status: open title: IDLE 3.5.1 not using Tk 8.6 type: resource usage Added file: http://bugs.python.org/file43196/About IDLE.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 11:22:10 2016 From: report at bugs.python.org (Emanuel Barry) Date: Sat, 04 Jun 2016 15:22:10 +0000 Subject: [issue27217] IDLE 3.5.1 not using Tk 8.6 In-Reply-To: <1465052845.59.0.651456701711.issue27217@psf.upfronthosting.co.za> Message-ID: <1465053730.76.0.902839848841.issue27217@psf.upfronthosting.co.za> Changes by Emanuel Barry : ---------- components: +IDLE, Macintosh nosy: +kbk, ned.deily, roger.serwy, ronaldoussoren, terry.reedy stage: -> test needed type: resource usage -> behavior versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 11:33:02 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 04 Jun 2016 15:33:02 +0000 Subject: [issue23401] Add pickle support of Mapping views In-Reply-To: <1423216735.87.0.773240969368.issue23401@psf.upfronthosting.co.za> Message-ID: <1465054382.89.0.0724575488276.issue23401@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Guido, is it your intention that the ABCs grow pickle support? I presume if this were implemented that it would become a requirement for all classes (and their subclasses) that purport to be mappings. I thought that you had designed to the ABCs to stay focused only on the essential characteristics of mappings. ---------- assignee: -> gvanrossum nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 11:43:46 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 04 Jun 2016 15:43:46 +0000 Subject: [issue27203] Failing doctests in Doc/faq/programming.rst In-Reply-To: <1464999592.59.0.0136488038508.issue27203@psf.upfronthosting.co.za> Message-ID: <1465055026.1.0.406128833291.issue27203@psf.upfronthosting.co.za> Changes by Jelle Zijlstra : Removed file: http://bugs.python.org/file43173/faqdoctests.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 11:44:19 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 04 Jun 2016 15:44:19 +0000 Subject: [issue27203] Failing doctests in Doc/faq/programming.rst In-Reply-To: <1464999592.59.0.0136488038508.issue27203@psf.upfronthosting.co.za> Message-ID: <1465055059.78.0.0765249948195.issue27203@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Thanks for teaching me about `make suspicious`. The attached patch fixes the issue. This doesn't fix all failures in the file but it gets us closer. ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python versions: +Python 3.6 Added file: http://bugs.python.org/file43197/doctests-faq.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 11:53:24 2016 From: report at bugs.python.org (=?utf-8?b?RMSBdmlz?=) Date: Sat, 04 Jun 2016 15:53:24 +0000 Subject: [issue27179] subprocess uses wrong encoding on Windows In-Reply-To: <1464828766.51.0.809606583575.issue27179@psf.upfronthosting.co.za> Message-ID: <1465055604.37.0.347359529451.issue27179@psf.upfronthosting.co.za> D?vis added the comment: it makes no sense to not use better encoding default in some cases like my patch does. Most programs use console's encoding not ANSI codepage and thus by limiting default only to ANSI codepage we force basically everyone to always specify encoding. This is current behavior that ANSI codepage is used and that's why this issue and also #27048. if we keep it this way then specifying encoding will be required for like 99% of cases which means it's useless default. Actually I don't even know any Windows program which does input/output (not talking about files because that's different) in ANSI codepage because it would be broken when displayed in console as that by default uses OEM codepage. Anyway my patch doesn't really change default it just uses console encoding in most cases and then fallbacks to same current default ANSI codepage. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 11:56:31 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 04 Jun 2016 15:56:31 +0000 Subject: [issue13771] HTTPSConnection __init__ super implementation causes recursion error In-Reply-To: <1326304391.56.0.972578337686.issue13771@psf.upfronthosting.co.za> Message-ID: <1465055791.14.0.225702010682.issue13771@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Could you provide a minimal code sample that demonstrates the problem? I'm having a hard time seeing why the http.client code is buggy. ---------- nosy: +Jelle Zijlstra _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 12:07:16 2016 From: report at bugs.python.org (Eryk Sun) Date: Sat, 04 Jun 2016 16:07:16 +0000 Subject: [issue27179] subprocess uses wrong encoding on Windows In-Reply-To: <1464828766.51.0.809606583575.issue27179@psf.upfronthosting.co.za> Message-ID: <1465056436.38.0.189015989468.issue27179@psf.upfronthosting.co.za> Eryk Sun added the comment: >> so ANSI is the natural default for a detached process > > To clarify - ANSI is the natural default *for programs that > don't support Unicode*. By natural, I meant in the context of using GetConsoleOutputCP(), since WideCharToMultiByte(0, ...) encodes text as ANSI. Clearly UTF-16LE is preferred for IPC on Windows. It's the native Unicode format down to the lowest levels of the kernel. But we're talking about old-school IPC using standard I/O pipelines, for which I think UTF-8 is a better fit. > Forcing the use of UTF-8 as the code page is the easiest way > for us to support it. The console's behavior for codepage 65001 is too buggy. The show stopper is that it limits input to ASCII. The console allocates a temporary buffer for the encoded text that's sized assuming 1 ANSI/OEM byte per UTF-16 code. So if you enter non-ASCII characters, WideCharToMultiByte fails in conhost.exe. But the console returns that the operation has successfully read 0 bytes. Python's REPL and input() see this as EOF. For example: import sys, ctypes, msvcrt kernel32 = ctypes.WinDLL('kernel32', use_last_error=True) conin = open(r'\\.\CONIN$', 'r+') h = msvcrt.get_osfhandle(conin.fileno()) buf = (ctypes.c_char * 15)() n = (ctypes.c_ulong * 1)() >>> sys.stdin.encoding 'cp65001' ReadFile test in Windows 10: >>> kernel32.ReadFile(h, buf, 15, n, None) Test! 1 >>> n[0], buf[:] (7, b'Test!\r\n\x00\x00\x00\x00\x00\x00\x00\x00') >>> kernel32.ReadFile(h, buf, 15, n, None) ?Prueba! 1 >>> n[0], buf[:] (0, b'Test!\r\n\x00\x00\x00\x00\x00\x00\x00\x00') The second call obviously fails, even thought it returns 1. The input contains non-ASCII "?", which in UTF-8 requires 2 bytes, b'\xc2\xa1'. This causes the failure in conhost.exe that I described above. ReadConsoleA has the same problem: >>> kernel32.ReadConsoleA(h, buf, 15, n, None) Hello World! 1 >>> n[0], buf[:] (14, b'Hello World!\r\n\x00') >>> kernel32.ReadConsoleA(h, buf, 15, n, None) ?Hola Mundo! 1 >>> n[0], buf[:] (0, b'Hello World!\r\n\x00') UTF-8 output is also buggy prior to Windows 8. The problem is that WriteFile returns the number of UTF-16 codes written instead of the number of bytes. For non-ASCII characters in the BMP, 1 UTF-16 code is 2 or 3 UTF-8 bytes. So it looks like a partial write. A buffered writer will loop multiple times to write what appears to be the remaining bytes, in a trail of junk lines in proportion to the number of non-ASCII characters written. Python could work around this by decoding the buffer to get the corresponding number of UTF-16 codes written in the console, but child processes may also be subject to this bug. The only general solution on Windows 7 is to use something like ANSICON, which uses DLL injection to hook and wrap WriteFile and WriteConsoleA. There's also a UTF-8 related bug in ulib.dll. This bug affects programs that do console codepage conversions, such as more.com. This in turn affects Python's interactive help(). I looked at this in issue 19914. The ulib bug is fixed in Windows 10. I don't know whether it's fixed in Windows 8, but it's there in Windows 7 (supported until 2020). > This would make Python's implementation much more > complicated, as well as breaking some scripts and > existing packages. Unless you're talking about major breakage, I think switching to the wide-character API is worth it, as the only viable path to supporting Unicode in the console. The implementation probably should transcode between UTF-16LE and UTF-8, so pure Python never sees UTF-16 byte strings. sys.std*.encoding would be 'utf-8'. os.read and os.write would be implemented as _Py_read and _Py_write (already exists). For console handles these could delegate to _Py_console_read and _Py_console_write, to convert between UTF-8 and UTF-16LE and call ReadConsoleW and WriteConsoleW. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 12:25:29 2016 From: report at bugs.python.org (Ned Deily) Date: Sat, 04 Jun 2016 16:25:29 +0000 Subject: [issue27217] IDLE 3.5.1 not using Tk 8.6 In-Reply-To: <1465052845.59.0.651456701711.issue27217@psf.upfronthosting.co.za> Message-ID: <1465057529.51.0.102537036984.issue27217@psf.upfronthosting.co.za> Ned Deily added the comment: Assuming you are using the Python 3.5.1 from the python.org OS X binary installer, you need to install a version of Tcl/Tk 8.5 (such as ActiveTcl 8.5.18), not 8.6, as is described here: https://www.python.org/download/mac/tcltk/. ---------- resolution: -> not a bug stage: test needed -> resolved status: open -> closed type: behavior -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 12:27:47 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 04 Jun 2016 16:27:47 +0000 Subject: [issue27218] improve tracing performance with f_trace set to Py_None Message-ID: <1465057667.55.0.463895492434.issue27218@psf.upfronthosting.co.za> New submission from Xavier de Gaye: When a trace function set by sys.settrace() returns None, tracing of the current scope should stop, but this feature is not implemented (issue 11992). Currently f_trace is never set to Py_None. Setting f_trace to Py_None in trace_trampoline() when the trace function returns Py_None provides a way to avoid the costly calls to maybe_call_line_trace() that are made for each line in this scope even though the trace function is not called. This idea was initiated in issue 20041. ---------- components: Library (Lib) messages: 267262 nosy: georg.brandl, xdegaye priority: normal severity: normal status: open title: improve tracing performance with f_trace set to Py_None type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 12:29:00 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 04 Jun 2016 16:29:00 +0000 Subject: [issue27219] turtle.fillcolor doesn't accept a tuple of floats Message-ID: <1465057740.31.0.354444599914.issue27219@psf.upfronthosting.co.za> New submission from Jelle Zijlstra: But `turtle.pencolor()` returns a tuple of floats, so calling `turtle.fillcolor(turtle.pencolor())`. This issue shows up in the doctest at library/turtle.rst line 936. I can submit a patch with tests once the tests in issue21916 are in. ---------- assignee: Jelle Zijlstra components: Library (Lib) messages: 267263 nosy: Jelle Zijlstra priority: normal severity: normal status: open title: turtle.fillcolor doesn't accept a tuple of floats versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 12:30:51 2016 From: report at bugs.python.org (Glenn Travis) Date: Sat, 04 Jun 2016 16:30:51 +0000 Subject: [issue27217] IDLE 3.5.1 not using Tk 8.6 In-Reply-To: <1465057529.51.0.102537036984.issue27217@psf.upfronthosting.co.za> Message-ID: <71FDECC0-3852-4C30-AAE5-70F28C71D67C@comcast.net> Glenn Travis added the comment: Ok, Thank you. I wonder why they have OS X version 8.6, which seems to be the default dl link page? > On Jun 4, 2016, at 11:25 AM, Ned Deily wrote: > > > Ned Deily added the comment: > > Assuming you are using the Python 3.5.1 from the python.org OS X binary installer, you need to install a version of Tcl/Tk 8.5 (such as ActiveTcl 8.5.18), not 8.6, as is described here: https://www.python.org/download/mac/tcltk/. > > ---------- > resolution: -> not a bug > stage: test needed -> resolved > status: open -> closed > type: behavior -> > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 12:32:57 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 04 Jun 2016 16:32:57 +0000 Subject: [issue20041] TypeError when f_trace is None and tracing. In-Reply-To: <1387634487.03.0.628100767515.issue20041@psf.upfronthosting.co.za> Message-ID: <1465057977.54.0.68840500745.issue20041@psf.upfronthosting.co.za> Xavier de Gaye added the comment: This patch fixes the TypeError. New issue 27218: improve tracing performance with f_trace set to Py_None. ---------- Added file: http://bugs.python.org/file43198/none_f_trace.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 12:34:53 2016 From: report at bugs.python.org (Ned Deily) Date: Sat, 04 Jun 2016 16:34:53 +0000 Subject: [issue27217] IDLE 3.5.1 not using Tk 8.6 In-Reply-To: <1465052845.59.0.651456701711.issue27217@psf.upfronthosting.co.za> Message-ID: <1465058093.6.0.985143584429.issue27217@psf.upfronthosting.co.za> Ned Deily added the comment: Well, 8.6 is the latest version of Tcl/Tk but, because Apple does not yet ship 8.6 in OS X, we have continued to use 8.5. That will change in Python 3.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 12:37:54 2016 From: report at bugs.python.org (Glenn Travis) Date: Sat, 04 Jun 2016 16:37:54 +0000 Subject: [issue27217] IDLE 3.5.1 not using Tk 8.6 In-Reply-To: <1465058093.6.0.985143584429.issue27217@psf.upfronthosting.co.za> Message-ID: <4D44D66B-C822-414F-829E-00630AB8F880@comcast.net> Glenn Travis added the comment: Thank you again, Does that mean that I will need to reinstall 8.6 when python 3.6 comes out? > On Jun 4, 2016, at 11:34 AM, Ned Deily wrote: > > > Ned Deily added the comment: > > Well, 8.6 is the latest version of Tcl/Tk but, because Apple does not yet ship 8.6 in OS X, we have continued to use 8.5. That will change in Python 3.6. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 12:41:30 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jun 2016 16:41:30 +0000 Subject: [issue27216] Fix capitalisation of "Python runtime" in os.path.islink description In-Reply-To: <1465035085.6.0.0369586412077.issue27216@psf.upfronthosting.co.za> Message-ID: <20160604164126.13690.40782.F5562B28@psf.io> Roundup Robot added the comment: New changeset 7c20ea2bdb3f by Ned Deily in branch '2.7': Issue 27216: Fix typo (noticed by Alex Chan). https://hg.python.org/cpython/rev/7c20ea2bdb3f New changeset 5160d59a8f1c by Ned Deily in branch '3.5': Issue 27216: Fix typo (noticed by Alex Chan). https://hg.python.org/cpython/rev/5160d59a8f1c New changeset 7fda2d76d947 by Ned Deily in branch 'default': Issue 27216: Fix typo (noticed by Alex Chan). https://hg.python.org/cpython/rev/7fda2d76d947 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 12:42:37 2016 From: report at bugs.python.org (Ned Deily) Date: Sat, 04 Jun 2016 16:42:37 +0000 Subject: [issue27216] Fix capitalisation of "Python runtime" in os.path.islink description In-Reply-To: <1465035085.6.0.0369586412077.issue27216@psf.upfronthosting.co.za> Message-ID: <1465058557.67.0.695459009678.issue27216@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for noticing! ---------- nosy: +ned.deily resolution: -> fixed stage: -> resolved status: open -> closed type: enhancement -> versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 12:45:38 2016 From: report at bugs.python.org (Eryk Sun) Date: Sat, 04 Jun 2016 16:45:38 +0000 Subject: [issue27179] subprocess uses wrong encoding on Windows In-Reply-To: <1464828766.51.0.809606583575.issue27179@psf.upfronthosting.co.za> Message-ID: <1465058738.86.0.0400917945965.issue27179@psf.upfronthosting.co.za> Eryk Sun added the comment: Another set of counterexamples are the utilities in the GnuWin32 collection, which use ANSI in a pipe: >>> call('chcp.com') Active code page: 437 0 >>> '?'.encode('1252') b'\xa1' >>> '\xa1'.encode('437') b'\xad' >>> os.listdir('.') ['?'] >>> check_output('ls') b'\xa1\r\n' >>> check_output('echo.exe ?') b'\xa1\r\n' Writing ANSI to a pipe or disk file is not as uncommon as you seem to think. Microsoft has never dictated a standard. It doesn't even follow a standard for this within its own command-line utilities. IMO, it makes more sense for programs to use UTF-8, or even UTF-16. Codepages are a legacy that we need to move beyond. Internally the console uses UTF-16LE. Note that patch 3 requires setting `encoding` for even python.exe as a child process, because sys.std* default to ANSI when isatty(fd) isn't true. (The CRT's isatty is true for any character-mode file, such as NUL or a console. Checking specifically for a console handle requires GetConsoleMode. To check for a pipe or disk file, call GetFileType to check for FILE_TYPE_PIPE or FILE_TYPE_DISK.) > I also checked that cmd /u flag is totally useless because it applies > only to cmd itself not to any other programs Anything else would be magic. Once a child process inherits its standard handles from cmd.exe [1], it can write whatever bytes it wants to them. In issue 27048 I proposed using the "/u" switch for shell=True only to facilitate getting results back from cmd's internal commands such as `set`. But it doesn't change anything if you're using the shell to run other programs. [1]: Unlike Python's Popen, cmd doesn't use STARTUPINFO for this. It temporarily modifies its own standard handles, which works even when it falls back on ShellExecuteEx to run files that are neither PE excecutables nor .BAT/.CMD files. > I looked if there's some function to get used encoding for > child process but there isn't, I would have expected something > like GetConsoleOutputCP(hThread). So the only way to get it, > is by calling GetConsoleOutputCP inside child process with > CreateRemoteThread and it's not really pretty and quite hacky, > but it does work, I tested. That's not the only way. You can also start a detached Python process (via pythonw.exe or DETACHED_PROCESS) to run a script that calls AttachConsole and returns the result of calling GetConsoleOutputCP: from subprocess import * DETACHED_PROCESS = 0x00000008 CREATE_NEW_CONSOLE = 0x00000010 cmd = ('python -c "import ctypes;' "kernel32 = ctypes.WinDLL('kernel32');" 'kernel32.AttachConsole(%d);' 'print(kernel32.GetConsoleOutputCP())"') call('chcp.com 1252') p = Popen('python', creationflags=CREATE_NEW_CONSOLE) cp = int(check_output(cmd % p.pid, creationflags=DETACHED_PROCESS)) >>> cp 437 > anyway even with that would need to change something about > TextIOWrapper because we're creating it before process is even > started and encoding isn't changeable later. In this case one can detach() the buffer to wrap it in a new TextIOWrapper. > > python -c "import subprocess; > print(subprocess.check_output('quser', encoding='cp775'))" > USERNAME SESSIONNAME > d?vis console > > also works correctly with any of console's encoding even if it > didn't showed correct encoding inside cmd itself. A minor point of clarification: quser.exe doesn't run "inside" cmd.exe; it runs attached to conhost.exe. The cmd shell is just the parent process. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 12:48:29 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 04 Jun 2016 16:48:29 +0000 Subject: [issue21916] Create unit tests for turtle textonly In-Reply-To: <1404479564.66.0.23163619156.issue21916@psf.upfronthosting.co.za> Message-ID: <1465058909.81.0.563801603463.issue21916@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: This patch removes the unrelated XML changes and addresses most of the code review comments. ---------- nosy: +Jelle Zijlstra Added file: http://bugs.python.org/file43199/issue21916-cr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 12:57:06 2016 From: report at bugs.python.org (Ned Deily) Date: Sat, 04 Jun 2016 16:57:06 +0000 Subject: [issue27217] IDLE 3.5.1 not using Tk 8.6 In-Reply-To: <1465052845.59.0.651456701711.issue27217@psf.upfronthosting.co.za> Message-ID: <1465059426.36.0.193096846673.issue27217@psf.upfronthosting.co.za> Ned Deily added the comment: Multiple versions of Tcl/Tk can co-exist. Installing ActiveTcl 8.5.x does not remove the 8.6.x version you installed earlier. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 12:58:23 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 04 Jun 2016 16:58:23 +0000 Subject: [issue25804] Make Profile.print_stats support sorting by mutiple values In-Reply-To: <1449303952.27.0.310214243782.issue25804@psf.upfronthosting.co.za> Message-ID: <1465059503.3.0.508723140365.issue25804@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Patch looks good to me ---------- nosy: +Jelle Zijlstra _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 13:00:41 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 04 Jun 2016 17:00:41 +0000 Subject: [issue27217] IDLE 3.5.1 not using Tk 8.6 In-Reply-To: <1465052845.59.0.651456701711.issue27217@psf.upfronthosting.co.za> Message-ID: <1465059641.44.0.891327679955.issue27217@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Glenn, in the future when you reply by email, please trim off the quoted message you are responding to, as your reply appears beneath it on the web site. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 13:03:00 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 04 Jun 2016 17:03:00 +0000 Subject: [issue27200] make doctest in CPython has failures In-Reply-To: <1464988408.0.0.840317371896.issue27200@psf.upfronthosting.co.za> Message-ID: <1465059780.43.0.862142791067.issue27200@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for all of these patches, but I'm -1 on committing them. We already have an extensive test suite and I'm pretty sure that all of these examples are already tested in Lib/test [*]. Learning reST is already hard for contributors and we shouldn't make it harder by introducing new directives like 'testsetup'. * We have also converted some doctests to proper unittests in Lib/test in the past. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 13:07:44 2016 From: report at bugs.python.org (Emanuel Barry) Date: Sat, 04 Jun 2016 17:07:44 +0000 Subject: [issue27220] Add a pure Python version of 'collections.defaultdict' Message-ID: <1465060064.38.0.412706275461.issue27220@psf.upfronthosting.co.za> New submission from Emanuel Barry: Attached patch adds a pure Python version of `collections.defaultdict`. This is yet another step in providing better support for alternate implementations, which may or may not have `_collections`. I also went ahead and fixed __all__ so that `from collections import *` doesn't fail if 'deque' isn't present (which it may not be in alternate implementations). Patch includes (small) doc and test changes. All tests pass successfully for both versions. ---------- components: Library (Lib) files: py_defaultdict_1.patch keywords: patch messages: 267276 nosy: ebarry, rhettinger priority: normal severity: normal stage: patch review status: open title: Add a pure Python version of 'collections.defaultdict' type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43200/py_defaultdict_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 13:10:07 2016 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Sat, 04 Jun 2016 17:10:07 +0000 Subject: [issue21159] configparser.InterpolationMissingOptionError is not very intuitive In-Reply-To: <1396694112.28.0.289974893208.issue21159@psf.upfronthosting.co.za> Message-ID: <1465060207.27.0.65271581931.issue21159@psf.upfronthosting.co.za> ?ukasz Langa added the comment: Closing since there's apparently nothing actionable at this point. ---------- keywords: -3.5regression resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 13:11:51 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 04 Jun 2016 17:11:51 +0000 Subject: [issue27200] make doctest in CPython has failures In-Reply-To: <1464988408.0.0.840317371896.issue27200@psf.upfronthosting.co.za> Message-ID: <1465060311.41.0.983491834537.issue27200@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: I would consider this a test of the quality of the documentation, not of the implementation. It's important that the examples in the documentation are actually correct. For example, a doctest in Doc/library/datetime.rst passes an "hours=" keyword argument to datetime.time when "hour=" is correct. It's going to be hard to find such bugs in examples without an automated check like `make doctest`. I'm open to simplifying the patches by removing testsetup blocks. For what it's worth though, the docs already contain 17 testsetup blocks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 13:16:21 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jun 2016 17:16:21 +0000 Subject: [issue23401] Add pickle support of Mapping views In-Reply-To: <1423216735.87.0.773240969368.issue23401@psf.upfronthosting.co.za> Message-ID: <1465060581.94.0.905613319141.issue23401@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The option 3 is now available with pickle protocols >= 2 (but less efficient with protocols < 4). Adding pickle support of Mapping views doesn't add a requirement for all classes that purport to be mappings. But if you implement pickle support of your mapping, its views become automatically pickleable. ---------- versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 13:19:55 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jun 2016 17:19:55 +0000 Subject: [issue27182] PEP 519 support in the stdlib In-Reply-To: <1464887789.1.0.970652730446.issue27182@psf.upfronthosting.co.za> Message-ID: <20160604171952.23439.12673.31A37216@psf.io> Roundup Robot added the comment: New changeset 00991aa5fdb5 by Ethan Furman in branch 'default': issue27182: update fsencode and fsdecode for os.path(); patch by Dusty Phillips https://hg.python.org/cpython/rev/00991aa5fdb5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 13:20:20 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jun 2016 17:20:20 +0000 Subject: [issue20041] TypeError when f_trace is None and tracing. In-Reply-To: <1387634487.03.0.628100767515.issue20041@psf.upfronthosting.co.za> Message-ID: <1465060820.42.0.890629782876.issue20041@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- assignee: -> serhiy.storchaka stage: patch review -> commit review versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 13:24:54 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 04 Jun 2016 17:24:54 +0000 Subject: [issue27182] PEP 519 support in the stdlib In-Reply-To: <1464887789.1.0.970652730446.issue27182@psf.upfronthosting.co.za> Message-ID: <1465061094.28.0.155512722649.issue27182@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: In the patch that was just committed, the path_type variables are undefined (os.py lines 892 and 908). There is also no test for these error cases?we should test the cases where the path has no __fspath__ or does not return a bytes or str. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 13:24:59 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jun 2016 17:24:59 +0000 Subject: [issue19234] socket.fileno() documentation In-Reply-To: <52597A2F.60807@python.org> Message-ID: <20160604172455.52083.9211.C2A6BEB0@psf.io> Roundup Robot added the comment: New changeset d83007ab69e2 by Kushal Das in branch '3.5': Issue #19234: Documents socket.fileno() returns -1 on failure https://hg.python.org/cpython/rev/d83007ab69e2 New changeset 3c745b656dca by Kushal Das in branch 'default': Issue #19234: Merge from 3.5 https://hg.python.org/cpython/rev/3c745b656dca ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 13:25:21 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 04 Jun 2016 17:25:21 +0000 Subject: [issue27200] make doctest in CPython has failures In-Reply-To: <1464988408.0.0.840317371896.issue27200@psf.upfronthosting.co.za> Message-ID: <1465061121.38.0.858438420717.issue27200@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, the point here is to test the docs, not the code, and is definitely worthwhile. If we can get make doctest to pass, then the docs buildbot can start running it. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 13:33:17 2016 From: report at bugs.python.org (Ethan Furman) Date: Sat, 04 Jun 2016 17:33:17 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1465061597.95.0.643531941719.issue27186@psf.upfronthosting.co.za> Ethan Furman added the comment: Dusty: The pathlib tests looks like it's only testing the PurePath implementation; while this /should/ be sufficient, please add tests for the other classes as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 13:34:04 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 04 Jun 2016 17:34:04 +0000 Subject: [issue25548] Show the address in the repr for class objects In-Reply-To: <1446576011.58.0.372024983976.issue25548@psf.upfronthosting.co.za> Message-ID: <1465061644.36.0.380294354445.issue25548@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Nofar said not to wait for her on this one. ---------- assignee: rhettinger -> kushal.das _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 13:34:11 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jun 2016 17:34:11 +0000 Subject: [issue20041] TypeError when f_trace is None and tracing. In-Reply-To: <1387634487.03.0.628100767515.issue20041@psf.upfronthosting.co.za> Message-ID: <1465061651.27.0.136098269185.issue20041@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 13:35:47 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jun 2016 17:35:47 +0000 Subject: [issue27218] improve tracing performance with f_trace set to Py_None In-Reply-To: <1465057667.55.0.463895492434.issue27218@psf.upfronthosting.co.za> Message-ID: <1465061747.92.0.62148433441.issue27218@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 13:35:52 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jun 2016 17:35:52 +0000 Subject: [issue27218] improve tracing performance with f_trace set to Py_None In-Reply-To: <1465057667.55.0.463895492434.issue27218@psf.upfronthosting.co.za> Message-ID: <1465061752.74.0.160035982169.issue27218@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 13:36:12 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 04 Jun 2016 17:36:12 +0000 Subject: [issue27182] PEP 519 support in the stdlib In-Reply-To: <1464887789.1.0.970652730446.issue27182@psf.upfronthosting.co.za> Message-ID: <1465061772.04.0.255541544832.issue27182@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Attached patch fixes the undefined variable and adds additional tests. ---------- Added file: http://bugs.python.org/file43201/issue27182-path_type.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 13:37:06 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jun 2016 17:37:06 +0000 Subject: [issue27219] turtle.fillcolor doesn't accept a tuple of floats In-Reply-To: <1465057740.31.0.354444599914.issue27219@psf.upfronthosting.co.za> Message-ID: <1465061826.58.0.2282605937.issue27219@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Create unit tests for turtle textonly type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 13:42:47 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jun 2016 17:42:47 +0000 Subject: [issue20041] TypeError when f_trace is None and tracing. In-Reply-To: <1387634487.03.0.628100767515.issue20041@psf.upfronthosting.co.za> Message-ID: <20160604174244.52083.22145.6EFDDA96@psf.io> Roundup Robot added the comment: New changeset 4d916be61d46 by Serhiy Storchaka in branch '2.7': Issue #20041: Fixed TypeError when frame.f_trace is set to None. https://hg.python.org/cpython/rev/4d916be61d46 New changeset 74ad78d2dd8d by Serhiy Storchaka in branch '3.5': Issue #20041: Fixed TypeError when frame.f_trace is set to None. https://hg.python.org/cpython/rev/74ad78d2dd8d New changeset f993dbeb2ad2 by Serhiy Storchaka in branch 'default': Issue #20041: Fixed TypeError when frame.f_trace is set to None. https://hg.python.org/cpython/rev/f993dbeb2ad2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 13:55:43 2016 From: report at bugs.python.org (Eric Fahlgren) Date: Sat, 04 Jun 2016 17:55:43 +0000 Subject: [issue27129] Wordcode, part 2 In-Reply-To: <1464268387.83.0.862540030058.issue27129@psf.upfronthosting.co.za> Message-ID: <1465062943.55.0.238801260502.issue27129@psf.upfronthosting.co.za> Changes by Eric Fahlgren : ---------- nosy: +eric.fahlgren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 14:08:42 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jun 2016 18:08:42 +0000 Subject: [issue21916] Create unit tests for turtle textonly In-Reply-To: <1404479564.66.0.23163619156.issue21916@psf.upfronthosting.co.za> Message-ID: <1465063722.91.0.601029992048.issue21916@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Added few minor comments on Rietveld. Please use more complex example for invalid config. Add valid lines before and after an invalid line. ---------- versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 14:17:16 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 04 Jun 2016 18:17:16 +0000 Subject: [issue21916] Create unit tests for turtle textonly In-Reply-To: <1404479564.66.0.23163619156.issue21916@psf.upfronthosting.co.za> Message-ID: <1465064236.53.0.751027447669.issue21916@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Thanks for your comments. Added a patch addressing your comments. ---------- Added file: http://bugs.python.org/file43202/issue21916-cr2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 14:54:35 2016 From: report at bugs.python.org (Emanuel Barry) Date: Sat, 04 Jun 2016 18:54:35 +0000 Subject: [issue26809] Add __all__ list to the string module In-Reply-To: <1461152182.96.0.373784885739.issue26809@psf.upfronthosting.co.za> Message-ID: <1465066475.18.0.792873353241.issue26809@psf.upfronthosting.co.za> Changes by Emanuel Barry : ---------- title: `string` exposes ChainMap from `collections` -> Add __all__ list to the string module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 15:05:22 2016 From: report at bugs.python.org (Susumu Koshiba) Date: Sat, 04 Jun 2016 19:05:22 +0000 Subject: [issue25738] http.server doesn't handle RESET CONTENT status correctly In-Reply-To: <1448583978.87.0.253695569638.issue25738@psf.upfronthosting.co.za> Message-ID: <1465067122.63.0.50691977131.issue25738@psf.upfronthosting.co.za> Susumu Koshiba added the comment: Thanks a lot for a quick review. I've created a new patch with below changes. 1. No content-length and the body to be sent for: a. 204(No Content) b. 205(Reset Content) c. 304(Not Modified) d. response to HEAD request method e. 1xx 2. Documentation change to remove version changed, in case we are making this patch to 2.7 and 3.5 I've added test cases for most of the scenarios mentioned above, but the behavior of 100(Continue) is left out due to the fact that sending 100(Continue) via send_error() gets tricky as it's not meant to close the connection after sending this response. I'm a bit undecided about the handling of 100(Continue) code in send_error() so I'll leave it as-is for now and possibly file a separate ticket depending on what we decide to do. Happy to patch 2.7, 3.5 as a bug fix also. ---------- Added file: http://bugs.python.org/file43203/issue25738_http_reset_content_03.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 15:05:33 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jun 2016 19:05:33 +0000 Subject: [issue26372] Popen.communicate not ignoring BrokenPipeError In-Reply-To: <1455672512.72.0.551664124622.issue26372@psf.upfronthosting.co.za> Message-ID: <20160604190530.15244.81663.399A1B56@psf.io> Roundup Robot added the comment: New changeset 3a560525ca50 by Gregory P. Smith in branch '3.5': issue26372 - use os.devnull instead of /dev/null https://hg.python.org/cpython/rev/3a560525ca50 New changeset 52e331b86f2b by Gregory P. Smith in branch 'default': issue26372 - use os.devnull instead of /dev/null https://hg.python.org/cpython/rev/52e331b86f2b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 15:06:53 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jun 2016 19:06:53 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <20160604190651.21070.48068.5557FC3D@psf.io> Roundup Robot added the comment: New changeset 780cbe18082e by Ethan Furman in branch 'default': issue27186: add C version of os.fspath(); patch by Jelle Zijlstra https://hg.python.org/cpython/rev/780cbe18082e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 15:10:17 2016 From: report at bugs.python.org (Ethan Furman) Date: Sat, 04 Jun 2016 19:10:17 +0000 Subject: [issue27182] PEP 519 support in the stdlib In-Reply-To: <1464887789.1.0.970652730446.issue27182@psf.upfronthosting.co.za> Message-ID: <1465067417.24.0.38377672445.issue27182@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- Removed message: http://bugs.python.org/msg267280 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 15:10:26 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 04 Jun 2016 19:10:26 +0000 Subject: [issue23401] Add pickle support of Mapping views In-Reply-To: <1423216735.87.0.773240969368.issue23401@psf.upfronthosting.co.za> Message-ID: <1465067426.4.0.621590801848.issue23401@psf.upfronthosting.co.za> Guido van Rossum added the comment: Raymond, what is your opinion? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 15:11:16 2016 From: report at bugs.python.org (Ethan Furman) Date: Sat, 04 Jun 2016 19:11:16 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1465067476.01.0.469981949624.issue27186@psf.upfronthosting.co.za> Ethan Furman added the comment: New changeset 00991aa5fdb5 by Ethan Furman in branch 'default': issue27182: update fsencode and fsdecode for os.path(); patch by Dusty Phillips https://hg.python.org/cpython/rev/00991aa5fdb5 (had wrong issue # in commit) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 15:13:26 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 04 Jun 2016 19:13:26 +0000 Subject: [issue23264] Add pickle support of dict views In-Reply-To: <1421568716.9.0.947546089999.issue23264@psf.upfronthosting.co.za> Message-ID: <1465067606.45.0.587422392925.issue23264@psf.upfronthosting.co.za> Guido van Rossum added the comment: Why no docs? ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 15:14:41 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 04 Jun 2016 19:14:41 +0000 Subject: [issue23401] Add pickle support of Mapping views In-Reply-To: <1423216735.87.0.773240969368.issue23401@psf.upfronthosting.co.za> Message-ID: <1465067681.8.0.072313865257.issue23401@psf.upfronthosting.co.za> Guido van Rossum added the comment: Serhiy, why would you want to separately pickle such a view? It's a trivial wrapper around a dict/mapping. What's the use case? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 15:20:49 2016 From: report at bugs.python.org (Susumu Koshiba) Date: Sat, 04 Jun 2016 19:20:49 +0000 Subject: [issue25738] http.server doesn't handle RESET CONTENT status correctly In-Reply-To: <1448583978.87.0.253695569638.issue25738@psf.upfronthosting.co.za> Message-ID: <1465068049.89.0.0670494923989.issue25738@psf.upfronthosting.co.za> Susumu Koshiba added the comment: Sorry, re-created a patch to do the right word wrapping and made my comments less verbose. ---------- Added file: http://bugs.python.org/file43204/issue25738_http_reset_content_04.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 15:23:44 2016 From: report at bugs.python.org (Ethan Furman) Date: Sat, 04 Jun 2016 19:23:44 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1465068224.7.0.924721945391.issue27186@psf.upfronthosting.co.za> Ethan Furman added the comment: Jelle: the DirEntry patch looks good so far, but it needs a test for a bytes path. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 15:29:00 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 04 Jun 2016 19:29:00 +0000 Subject: [issue21130] equivalent functools.partial instances should compare equal In-Reply-To: <1396425472.15.0.80240218298.issue21130@psf.upfronthosting.co.za> Message-ID: <1465068540.76.0.635903449551.issue21130@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: I think the patch needs more tests, including: - Comparing a partial against some other objects - Comparing two partials with a different function - Comparing two partials with different args You also need to check each call to PyObject_RichCompareBool for error (it returns -1 on error). I believe the current implementation would silently ignore the error. This behavior should also be tested. Rietveld is not picking up this diff, maybe because it is a git rather than an hg diff. Generating the diff with hg will make it easier to review. ---------- nosy: +Jelle Zijlstra _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 15:40:32 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 04 Jun 2016 19:40:32 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1465069232.93.0.147434711276.issue27186@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Thanks for reviewing. This patch adds tests with a bytes DirEntry. ---------- Added file: http://bugs.python.org/file43205/issue27186-DirEntry-fspath.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 15:42:17 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jun 2016 19:42:17 +0000 Subject: [issue26809] Add __all__ list to the string module In-Reply-To: <1461152182.96.0.373784885739.issue26809@psf.upfronthosting.co.za> Message-ID: <20160604194214.20938.63925.436B1336@psf.io> Roundup Robot added the comment: New changeset 8136f9623d7f by Zachary Ware in branch '3.5': Issue #26809: Add __all__ to string module. Patch by Emanuel Barry https://hg.python.org/cpython/rev/8136f9623d7f New changeset 21ae58b77924 by Zachary Ware in branch 'default': Closes #26809: Merge with 3.5 https://hg.python.org/cpython/rev/21ae58b77924 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 15:42:42 2016 From: report at bugs.python.org (Memeplex) Date: Sat, 04 Jun 2016 19:42:42 +0000 Subject: [issue27221] [multiprocessing] Doc is outdated regarding method picklability Message-ID: <1465069362.83.0.142351405451.issue27221@psf.upfronthosting.co.za> New submission from Memeplex: The module documentation recommends... More picklability Ensure that all arguments to Process.__init__() are picklable. This means, in particular, that bound or unbound methods cannot be used directly as the target (unless you use the fork start method) ? just define a function and use that instead. ...but methods (bound and unbound) are now pickleable (given their self.object is picklable). ---------- assignee: docs at python components: Documentation messages: 267303 nosy: docs at python, memeplex priority: normal severity: normal status: open title: [multiprocessing] Doc is outdated regarding method picklability versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 15:42:52 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 04 Jun 2016 19:42:52 +0000 Subject: [issue16851] Hint about correct ismethod and isfunction usage In-Reply-To: <1357231289.77.0.0608728593688.issue16851@psf.upfronthosting.co.za> Message-ID: <1465069372.66.0.983982755486.issue16851@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Sounds like this can be closed? ---------- nosy: +Jelle Zijlstra _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 15:47:43 2016 From: report at bugs.python.org (Zachary Ware) Date: Sat, 04 Jun 2016 19:47:43 +0000 Subject: [issue26632] @public - an __all__ decorator In-Reply-To: <1458786797.31.0.0749407715279.issue26632@psf.upfronthosting.co.za> Message-ID: <1465069663.67.0.923248771945.issue26632@psf.upfronthosting.co.za> Zachary Ware added the comment: I had seen this go by on new-bugs-announce, but hadn't formed an opinion about it. I had also noticed several issues about __all__, but hadn't realized how widespread those issues were. Now I've just been introduced to #23883 via #26809, and was sad to find this closed when I came to give my +1. So, +1 anyway. I think this would be rather worthwhile, especially in the stdlib. ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 15:50:04 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jun 2016 19:50:04 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <20160604195001.1408.74649.FB3CDC48@psf.io> Roundup Robot added the comment: New changeset e672cf63d08a by Ethan Furman in branch 'default': issue27186: add PathLike ABC https://hg.python.org/cpython/rev/e672cf63d08a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 15:53:49 2016 From: report at bugs.python.org (Emanuel Barry) Date: Sat, 04 Jun 2016 19:53:49 +0000 Subject: [issue21130] equivalent functools.partial instances should compare equal In-Reply-To: <1396425472.15.0.80240218298.issue21130@psf.upfronthosting.co.za> Message-ID: <1465070029.75.0.531010564444.issue21130@psf.upfronthosting.co.za> Emanuel Barry added the comment: Git diffs work, but this one doesn't apply cleanly. I manually fixed it and re-generated the patch. Rietveld should pick it up now. Otherwise, what Jelle said. I'm not sure if the macro has the best name though - I'd probably name it `PyPartial_CheckExact` and reserve `PyPartial_Check` to allow checking for subclasses. Not sure if we need to add both in here, but it would be weird to have only one (even if the other is unused). (Also, depending which of this one or #27137 gets committed first, the other patch will need to be updated. I'll probably do it since the other is mine.) ---------- nosy: +ebarry stage: needs patch -> patch review versions: +Python 3.6 -Python 3.5 Added file: http://bugs.python.org/file43206/partial_richcompare_1_regenerated.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 15:54:27 2016 From: report at bugs.python.org (Oren Milman) Date: Sat, 04 Jun 2016 19:54:27 +0000 Subject: [issue27222] redundant checks and a weird use of goto statements in long_rshift Message-ID: <1465070067.21.0.305651029523.issue27222@psf.upfronthosting.co.za> New submission from Oren Milman: ------------ current state ------------ 1. long_rshift first checks whether a is a negative int. If it is, it does (edited for brevity) 'z = long_invert(long_rshift(long_invert(a), b));'. Otherwise, it calculates the result of the shift and stores it in z. In this block, there is a check whether a is a negative int. The second check was always there - since revision 443, in which long_rshift was first added. However, in revision 590, the first aforementioned check (whether a is a negative int), along with a (edited for brevity) 'return long_invert(long_rshift(long_invert(a), b));' were added, but the second check whether a is a negative int wasn't removed, and remained there to this day. 2. Ultimately, long_rshift does 'return (PyObject *) maybe_small_long(z);' for both cases (whether a is a negative int or not). Calling maybe_small_long in case a is a negative int is redundant, as long_invert returns (in case it doesn't fail) by either doing 'return PyLong_FromLong(-(MEDIUM_VALUE(v)+1));' or 'return (PyObject *)maybe_small_long(x);'. In both cases, long_invert would return a reference to an element of small_ints if it should. Calls to maybe_small_long were added both to long_rshift and long_invert in revision 48567, as part of an effort to wipe out different places in the code where small_ints could be used (to save up memory), but was not. I am not sure why maybe_small_long was added to long_rshift where it would be redundant in case a is a negative int. 3. In different cases of failure, long_rshift does 'goto rshift_error;'. The destination of these goto statements is actually a return statement that would also be reached in almost any case of success (except for a certain case in which the result of the shift is obviously zero). That goto was added in revision 15725. Back then, CONVERT_BINOP was added, and calling it in long_rshift required calling Py_DECREF for a and b before returning. Later on, in revision 43313, CONVERT_BINOP was removed, along with the calls to Py_DECREF it required, but the goto was left untouched, and remained there to this day. ------------ proposed changes ------------ All of the proposed changes are in Objects/longobject.c in long_rshift: 1. Remove the check whether a is a negative int in the block that gets executed in case a is not a negative int. 2. Move the call to maybe_small_long inside the block that runs in case a is not a negative int. 3. Replace every 'goto rshift_error;' with a 'return NULL;', and remove the rshift_error label. I could have kept the goto statements, with 'return (PyObject *)z;' as their destination, but I believe it would have been less clear. Also, there are many similar places in longobject.c where 'return NULL;' is done on failure. ------------ diff ------------ The proposed patches diff file is attached. ------------ tests ------------ I built the patched CPython for x86, and played with it a little. Everything seemed to work as usual. Specifically, I did: for i in range(10000): if not all(smallInt is ((smallInt << i) >> i) for ( smallInt) in range(-5, 257)): break print(i) And indeed 9999 was printed. In addition, I ran 'python_d.exe -m test -j3' (on my 64-bit Windows 10) with and without the patches, and got quite the same output. the outputs of both runs are attached. ---------- components: Interpreter Core files: proposedPatches.diff keywords: patch messages: 267308 nosy: Oren Milman priority: normal severity: normal status: open title: redundant checks and a weird use of goto statements in long_rshift type: performance Added file: http://bugs.python.org/file43207/proposedPatches.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 15:55:00 2016 From: report at bugs.python.org (Oren Milman) Date: Sat, 04 Jun 2016 19:55:00 +0000 Subject: [issue27222] redundant checks and a weird use of goto statements in long_rshift In-Reply-To: <1465070067.21.0.305651029523.issue27222@psf.upfronthosting.co.za> Message-ID: <1465070100.1.0.159401917879.issue27222@psf.upfronthosting.co.za> Changes by Oren Milman : Added file: http://bugs.python.org/file43208/CPythonTestOutput.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 15:55:23 2016 From: report at bugs.python.org (Oren Milman) Date: Sat, 04 Jun 2016 19:55:23 +0000 Subject: [issue27222] redundant checks and a weird use of goto statements in long_rshift In-Reply-To: <1465070067.21.0.305651029523.issue27222@psf.upfronthosting.co.za> Message-ID: <1465070123.9.0.722634338639.issue27222@psf.upfronthosting.co.za> Changes by Oren Milman : Added file: http://bugs.python.org/file43209/patchedCPythonTestOutput.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 15:57:11 2016 From: report at bugs.python.org (Matthias Klose) Date: Sat, 04 Jun 2016 19:57:11 +0000 Subject: [issue25151] venv does not work with debian releases, if you want to install pip In-Reply-To: <1442498140.39.0.803363525343.issue25151@psf.upfronthosting.co.za> Message-ID: <1465070231.12.0.589920190581.issue25151@psf.upfronthosting.co.za> Matthias Klose added the comment: The current Debian packages show this error message: $ python3 -m venv /tmp/foobar The virtual environment was not created successfully because ensurepip is not available. On Debian/Ubuntu systems, you need to install the python3-venv package using the following command. apt-get install python3-venv You may need to use sudo with that command. After installing the python3-venv package, recreate your virtual environment. Failing command: ['/tmp/foobar/bin/python3', '-Im', 'ensurepip', '--upgrade', '--default-pip'] ---------- nosy: +doko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 15:57:54 2016 From: report at bugs.python.org (Matthias Klose) Date: Sat, 04 Jun 2016 19:57:54 +0000 Subject: [issue25151] venv does not work with debian releases, if you want to install pip In-Reply-To: <1442498140.39.0.803363525343.issue25151@psf.upfronthosting.co.za> Message-ID: <1465070274.18.0.941191002038.issue25151@psf.upfronthosting.co.za> Changes by Matthias Klose : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 15:58:46 2016 From: report at bugs.python.org (=?utf-8?b?RMSBdmlz?=) Date: Sat, 04 Jun 2016 19:58:46 +0000 Subject: [issue27179] subprocess uses wrong encoding on Windows In-Reply-To: <1464828766.51.0.809606583575.issue27179@psf.upfronthosting.co.za> Message-ID: <1465070326.26.0.141867820483.issue27179@psf.upfronthosting.co.za> D?vis added the comment: Of course I agree that proper solution is to use Unicode/Wide API but that's much more work to implement and I rather have now this half-fix which works for most of cases than nothing till whenever Unicode support is implemented which might be nowhere soon. > IMO, it makes more sense for programs to use UTF-8, or even UTF-16. Codepages are a legacy that we need to move beyond. Internally the console uses UTF-16LE. yes that's true, but we can't do anything about current existing programs and so if we default to UTF-8 it will be even worse than defaulting to ANSI because there aren't many programs on Windows which would use UTF-8, in fact it's quite rare because there's not even good UTF-8 support for console itself like you mentioned. Also here I'm talking only about ANSI WinAPI programs with console/pipe encoding and not internal or file encoding which here we don't really care about. > Note that patch 3 requires setting `encoding` for even python.exe as a child process, because sys.std* default to ANSI when isatty(fd) isn't true. I think Python is a bit broken here and IMO it should also use console's encoding not ANSI when outputting to console pipe and use ANSI if it really is a file. on Windows 10 with Python 3.5.1 >chcp Active code page: 775 >python -c "print('?')" ? >python -c "print('?')" | echo ECHO is on. Exception ignored in: <_io.TextIOWrapper name='' mode='w' encoding='cp1257'> OSError: [Errno 22] Invalid argument >chcp 1257 Active code page: 1257 >python -c "print('?')" | echo ECHO is on. Exception ignored in: <_io.TextIOWrapper name='' mode='w' encoding='cp1257'> OSError: [Errno 22] Invalid argument in PowerShell >[Console]::OutputEncoding.CodePage 775 >python -c "print('?')" | Out-String ? >[Console]::OutputEncoding = [System.Text.Encoding]::UTF8 >python -c "print('?')" | Out-String ? >[Console]::OutputEncoding = [System.Text.Encoding]::GetEncoding(1257) >python -c "print('?')" | Out-String ? > I proposed using the "/u" switch for shell=True only to facilitate getting results back from cmd's internal commands such as `set`. But it doesn't change anything if you're using the shell to run other programs. but you can only do that if you know that command you execute is cmd's command but if it's user passed command then there isn't really reliable way to detect if it will execute inside cmd or not, for example "cmd /u /c chcp.exe" will return result in UTF-16 because such program doesn't exist and cmd's error message will be outputted. Also if user have set.exe in %System32% then "cmd /u /c set" won't be in UTF-16 because it will execute that program. >> by calling GetConsoleOutputCP inside child process with CreateRemoteThread > That's not the only way. You can also start a detached Python process (via pythonw.exe or DETACHED_PROCESS) to run a script that calls AttachConsole and returns the result of calling GetConsoleOutputCP: while useful to know it's still messy because I think you would need to prevent your target process from exiting before you've called AttachConsole and also most likely you want to get GetConsoleOutputCP before program's exit and not at start (say with CREATE_SUSPENDED) as it might have changed it somewhere in middle of program's execution. so looks like this route isn't worth going for. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 16:16:32 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jun 2016 20:16:32 +0000 Subject: [issue24759] Idle: require tk 8.5 and ttk widgets, and drop unneeded code. In-Reply-To: <1438294715.65.0.966229055462.issue24759@psf.upfronthosting.co.za> Message-ID: <20160604201628.1343.38531.EC6C4190@psf.io> Roundup Robot added the comment: New changeset e6560f018845 by Terry Jan Reedy in branch '2.7': Issue #24759: Add 'private' notice for idlelib.idle_test. https://hg.python.org/cpython/rev/e6560f018845 New changeset d75a25b3abe1 by Terry Jan Reedy in branch '3.5': Issue #24759: Add 'private' notice for idlelib.idle_test. https://hg.python.org/cpython/rev/d75a25b3abe1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 16:29:40 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jun 2016 20:29:40 +0000 Subject: [issue21916] Create unit tests for turtle textonly In-Reply-To: <1404479564.66.0.23163619156.issue21916@psf.upfronthosting.co.za> Message-ID: <1465072180.95.0.619710175239.issue21916@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Nice. LGTM. ---------- stage: patch review -> commit review versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 16:30:27 2016 From: report at bugs.python.org (Ethan Furman) Date: Sat, 04 Jun 2016 20:30:27 +0000 Subject: [issue27182] PEP 519 support in the stdlib In-Reply-To: <1464887789.1.0.970652730446.issue27182@psf.upfronthosting.co.za> Message-ID: <20160604171952.23439.12673.31A37216@psf.io> Ethan Furman added the comment: New changeset 00991aa5fdb5 by Ethan Furman in branch 'default': issue27182: update fsencode and fsdecode for os.path(); patch by Dusty Phillips https://hg.python.org/cpython/rev/00991aa5fdb5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 16:31:04 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 04 Jun 2016 20:31:04 +0000 Subject: [issue24759] Idle: require tk 8.5 and ttk widgets, and drop unneeded code. In-Reply-To: <1438294715.65.0.966229055462.issue24759@psf.upfronthosting.co.za> Message-ID: <1465072264.28.0.936906479843.issue24759@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I believe require85-v2.diff adds everything specified in my last post. ---------- Added file: http://bugs.python.org/file43210/require85-v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 16:31:34 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jun 2016 20:31:34 +0000 Subject: [issue21916] Create unit tests for turtle textonly In-Reply-To: <1404479564.66.0.23163619156.issue21916@psf.upfronthosting.co.za> Message-ID: <20160604203131.13769.83857.B3E20DE5@psf.io> Roundup Robot added the comment: New changeset f0b94cfcea45 by Serhiy Storchaka in branch '2.7': Issue #21916: Added tests for the turtle module. https://hg.python.org/cpython/rev/f0b94cfcea45 New changeset 3b9e96440a70 by Serhiy Storchaka in branch '3.5': Issue #21916: Added tests for the turtle module. https://hg.python.org/cpython/rev/3b9e96440a70 New changeset 3d1a23984a6e by Serhiy Storchaka in branch 'default': Issue #21916: Added tests for the turtle module. https://hg.python.org/cpython/rev/3d1a23984a6e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 16:34:16 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jun 2016 20:34:16 +0000 Subject: [issue21916] Create unit tests for turtle textonly In-Reply-To: <1404479564.66.0.23163619156.issue21916@psf.upfronthosting.co.za> Message-ID: <1465072456.25.0.0466051959987.issue21916@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Jelle, do you want to add tests the constructor, repr and pickling of Vec2D? ---------- stage: commit review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 16:35:46 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jun 2016 20:35:46 +0000 Subject: [issue27222] redundant checks and a weird use of goto statements in long_rshift In-Reply-To: <1465070067.21.0.305651029523.issue27222@psf.upfronthosting.co.za> Message-ID: <1465072546.49.0.311994418118.issue27222@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +mark.dickinson, serhiy.storchaka stage: -> patch review versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 16:48:17 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jun 2016 20:48:17 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <20160604204807.1067.31062.FE2695CD@psf.io> Roundup Robot added the comment: New changeset 76b2ddaee6bd by Ethan Furman in branch 'default': issue27186: fix fsencode/fsdecode and update tests; patch by Jelle Zijlstra https://hg.python.org/cpython/rev/76b2ddaee6bd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 16:55:20 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jun 2016 20:55:20 +0000 Subject: [issue23401] Add pickle support of Mapping views In-Reply-To: <1423216735.87.0.773240969368.issue23401@psf.upfronthosting.co.za> Message-ID: <1465073720.05.0.783126658246.issue23401@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Because I can! I just want to ensure that all basic types (for which it makes sense) are correctly and portable pickleable, especially collections and related classes. Note that currently Mapping views are pickleable (as most pure Python classes), but pickle exposes implementation detail (the _mapping attribute). For example pickled keys view of Python implementation of OrderedDict is not fully compatible with C implementation. I want to provide implementation agnostic and more efficient pickling. >>> keys = collections.abc.KeysView({1: 2, 3: 4}) >>> keys.__reduce_ex__(3) (, (,), (None, {'_mapping': {1: 2, 3: 4}}), None, None) There are many ways to do this (msg235477, msg235493). I hesitate with choosing, ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 17:03:16 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 04 Jun 2016 21:03:16 +0000 Subject: [issue23401] Add pickle support of Mapping views In-Reply-To: <1465073720.05.0.783126658246.issue23401@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I think it's fine to do this for concrete classes, I just don't think it should be added to ABCs. --Guido (mobile) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 17:05:25 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jun 2016 21:05:25 +0000 Subject: [issue27129] Wordcode, part 2 In-Reply-To: <1464268387.83.0.862540030058.issue27129@psf.upfronthosting.co.za> Message-ID: <1465074325.49.0.154179655969.issue27129@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +Mark.Shannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 17:05:43 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jun 2016 21:05:43 +0000 Subject: [issue27140] Opcode for creating dict with constant keys In-Reply-To: <1464381640.82.0.0689379791356.issue27140@psf.upfronthosting.co.za> Message-ID: <1465074343.14.0.0376774694045.issue27140@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +Mark.Shannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 17:06:05 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jun 2016 21:06:05 +0000 Subject: [issue27095] Simplify MAKE_FUNCTION In-Reply-To: <1464038780.83.0.81155899453.issue27095@psf.upfronthosting.co.za> Message-ID: <1465074365.71.0.630748024892.issue27095@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +Mark.Shannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 17:06:49 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jun 2016 21:06:49 +0000 Subject: [issue27213] Rework CALL_FUNCTION* opcodes In-Reply-To: <1465026334.02.0.369802561902.issue27213@psf.upfronthosting.co.za> Message-ID: <1465074409.65.0.19128915141.issue27213@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +Demur Rumed, Mark.Shannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 17:11:37 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 04 Jun 2016 21:11:37 +0000 Subject: [issue24254] Make class definition namespace ordered by default In-Reply-To: <1432186488.39.0.20621749373.issue24254@psf.upfronthosting.co.za> Message-ID: <1465074697.61.0.782926067238.issue24254@psf.upfronthosting.co.za> Nick Coghlan added the comment: The patch looks good to me as a reference implementation, but I think it's worth writing up as a short PEP so there's a clear reference from the What's New documentation, and so developers of other implementations have a chance to review and comment on the change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 17:12:41 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jun 2016 21:12:41 +0000 Subject: [issue23264] Add pickle support of dict views In-Reply-To: <1421568716.9.0.947546089999.issue23264@psf.upfronthosting.co.za> Message-ID: <1465074761.28.0.188279705329.issue23264@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What docs are needed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 17:16:35 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jun 2016 21:16:35 +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: <1465074995.34.0.80608026442.issue17611@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 17:25:22 2016 From: report at bugs.python.org (Emanuel Barry) Date: Sat, 04 Jun 2016 21:25:22 +0000 Subject: [issue21130] equivalent functools.partial instances should compare equal In-Reply-To: <1396425472.15.0.80240218298.issue21130@psf.upfronthosting.co.za> Message-ID: <1465075522.11.0.935988131122.issue21130@psf.upfronthosting.co.za> Emanuel Barry added the comment: New patch with Jelle's suggestions. I completely removed the macros since we need to (potentially) call Python code with PyObject_IsInstance, and need to check for return code. I also reverted some of the unrelated changes. ---------- Added file: http://bugs.python.org/file43211/partial_richcompare_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 17:39:16 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jun 2016 21:39:16 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <20160604213912.13597.54914.72578EB8@psf.io> Roundup Robot added the comment: New changeset 254125a265d2 by Ethan Furman in branch 'default': issue27186: add open/io.open; patch by Jelle Zijlstra https://hg.python.org/cpython/rev/254125a265d2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 17:41:37 2016 From: report at bugs.python.org (Yusuke Tsutsumi) Date: Sat, 04 Jun 2016 21:41:37 +0000 Subject: [issue18751] A manager's server never joins its threads In-Reply-To: <1376590396.18.0.712968689777.issue18751@psf.upfronthosting.co.za> Message-ID: <1465076497.02.0.672581848603.issue18751@psf.upfronthosting.co.za> Yusuke Tsutsumi added the comment: I'm interested in taking this on. I can do the following: * keep track of the threads in a field attached to the class * handle thread synchronization and cleanup in the finally block * set a flag on the exception, which ensures the loop completes, vs immediately passing. The part I'm unclear on is a good garbage collection strategy. I'm thinking: * set some configurable period to clean up the threads (every 10s by default. Rapid enough to ensure cleanup, but not fast enough to run every time and significantly slow down responses) * at the specific threshold, run the cleanup script. * on cleanup, check every thread if it's alive. explicit del the ones that are not. If it sounds good, I can start a patch. ---------- nosy: +Yusuke Tsutsumi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 17:44:29 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jun 2016 21:44:29 +0000 Subject: [issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects. In-Reply-To: <1384516983.26.0.0584971052865.issue19611@psf.upfronthosting.co.za> Message-ID: <20160604214426.100824.6933.E4827885@psf.io> Roundup Robot added the comment: New changeset 6247dd0f230e by Nick Coghlan in branch 'default': Issue #19611: handle implicit parameters in inspect.signature https://hg.python.org/cpython/rev/6247dd0f230e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 17:45:34 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 04 Jun 2016 21:45:34 +0000 Subject: [issue23264] Add pickle support of dict views In-Reply-To: <1465074761.28.0.188279705329.issue23264@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: On general I think we should always document whether a class is picklable. And we should document how a subclass can hook into pickling. --Guido (mobile) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 17:45:58 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 04 Jun 2016 21:45:58 +0000 Subject: [issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects. In-Reply-To: <1384516983.26.0.0584971052865.issue19611@psf.upfronthosting.co.za> Message-ID: <1465076758.16.0.607181641518.issue19611@psf.upfronthosting.co.za> Nick Coghlan added the comment: Fix committed for 3.6 - this is obscure enough that I'm not going to worry about fixing it on maintenance branches. ---------- resolution: -> fixed stage: -> resolved status: open -> closed type: -> behavior versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 17:46:23 2016 From: report at bugs.python.org (Ethan Furman) Date: Sat, 04 Jun 2016 21:46:23 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1465076783.91.0.583984220967.issue27186@psf.upfronthosting.co.za> Ethan Furman added the comment: Jelle: We still need os.open if you would like to work on that. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 17:53:36 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 04 Jun 2016 21:53:36 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1465077216.54.0.14003168131.issue27186@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Sure, I'll do that too. Now that os.PathLike and PyOS_FSPath exist, it should also be possible to add support to os.path. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 18:05:07 2016 From: report at bugs.python.org (Demur Rumed) Date: Sat, 04 Jun 2016 22:05:07 +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: <1465077907.11.0.625784047169.issue17611@psf.upfronthosting.co.za> Demur Rumed added the comment: Java duplicates finally bytecode too: http://cliffhacks.blogspot.ca/2008/02/java-6-tryfinally-compilation-without.html Tho they avoid jsr instruction because it causes non trivial bytecode validation. Still, they would've had to concluded that finally blocks are often small enough to be alright to inline ---------- nosy: +Demur Rumed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 18:07:51 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 04 Jun 2016 22:07:51 +0000 Subject: [issue25732] functools.total_ordering does not correctly implement not equal behaviour In-Reply-To: <1448457169.16.0.121144285875.issue25732@psf.upfronthosting.co.za> Message-ID: <1465078071.05.0.877769857425.issue25732@psf.upfronthosting.co.za> Nick Coghlan added the comment: Sorry for the delayed review. I agree it makes sense to fix this for 2.7, and the proposed solution looks good to me. However, the latest patch looks it was only partway through editing - the additional test cases seem to be copies of the existing test cases, rather than new scenarios. ---------- assignee: ncoghlan -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 18:10:42 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 04 Jun 2016 22:10:42 +0000 Subject: [issue25194] Opt-in motivations & affiliations page for core contributors In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za> Message-ID: <1465078242.79.0.632745835076.issue25194@psf.upfronthosting.co.za> Nick Coghlan added the comment: The page is up and running, with a few folks contributing entries, so there's nothing further to be done here. ---------- status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 18:13:23 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 04 Jun 2016 22:13:23 +0000 Subject: [issue21916] Create unit tests for turtle textonly In-Reply-To: <1404479564.66.0.23163619156.issue21916@psf.upfronthosting.co.za> Message-ID: <1465078403.07.0.24952416176.issue21916@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Thanks for merging it in. I'll add the additional tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 18:27:50 2016 From: report at bugs.python.org (Ned Deily) Date: Sat, 04 Jun 2016 22:27:50 +0000 Subject: [issue18117] Missing symlink:Current after Mac OS X 3.3.2 package installation In-Reply-To: <1370161783.39.0.437072519867.issue18117@psf.upfronthosting.co.za> Message-ID: <1465079270.37.0.032822165253.issue18117@psf.upfronthosting.co.za> Ned Deily added the comment: David, I think we are not going to change the Current symlink behavior at this point so we might as well close this issue. We may decide to address the need to pick which version to link with in a different manner later. ---------- resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 18:31:28 2016 From: report at bugs.python.org (Emanuel Barry) Date: Sat, 04 Jun 2016 22:31:28 +0000 Subject: [issue27137] Python implementation of `functools.partial` is not a class In-Reply-To: <1464367158.87.0.208604382314.issue27137@psf.upfronthosting.co.za> Message-ID: <1465079488.08.0.130424196576.issue27137@psf.upfronthosting.co.za> Emanuel Barry added the comment: New patch, now almost all the tests that are used for the C version are also used for the Python version (the only exception is the one checking that trying to change/delete attributes would raise an error). Some tests needed a bit of tweaking to work with the implementation details of both versions, but now all of the tests pass (even the pickle one, which I found how to make it pass while working on #27220). ---------- Added file: http://bugs.python.org/file43212/functools_partial_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 18:31:40 2016 From: report at bugs.python.org (Ethan Furman) Date: Sat, 04 Jun 2016 22:31:40 +0000 Subject: [issue27182] PEP 519 support in the stdlib In-Reply-To: <1464887789.1.0.970652730446.issue27182@psf.upfronthosting.co.za> Message-ID: <1465079500.4.0.223491946064.issue27182@psf.upfronthosting.co.za> Ethan Furman added the comment: Currently, os.fspath will raise an exception if the thing passed in is not str/bytes/PathLike, and that error message will proclaim that str or bytes or PathLike is required; however, this is not true in cases such as Path (which doesn't allow bytes), and incomplete in cases such as os.open (which also allows ints). On the other hand, if the thing has a functional __fspath__ (meaning calling it doesn't raise an exception) then os.fspath will return whatever that method returns, which could be complete garbage. So os.fspath is being too strict, too open, and too lax all at the same time. Given Guido's reluctance to check the output of __fspath__(), plus the current difficulty of painless integration with existing functions, I think we should have os.fspath() only raise an exception if obj.__fspath__ exists and calling it raises an exception, otherwise we return the result of calling obj.__fspath__(), or obj if it doesn't have __fspath__. In case that wasn't clear, attached is a unit test that passes when the above changes are implemented. ---------- Added file: http://bugs.python.org/file43213/test_fspath.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 18:36:03 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 04 Jun 2016 22:36:03 +0000 Subject: [issue16851] Hint about correct ismethod and isfunction usage In-Reply-To: <1357231289.77.0.0608728593688.issue16851@psf.upfronthosting.co.za> Message-ID: <1465079763.91.0.513883137626.issue16851@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 18:37:55 2016 From: report at bugs.python.org (Ethan Furman) Date: Sat, 04 Jun 2016 22:37:55 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1465079875.55.0.441624495054.issue27186@psf.upfronthosting.co.za> Ethan Furman added the comment: os.path is actually two different modules: posixpath.py and ntpath.py posixpath.py is being tracked in issue26027 ntpath.py is being tracked in issue27184 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 18:44:12 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jun 2016 22:44:12 +0000 Subject: [issue26884] android: cross-compilation of extension module links to the wrong python library In-Reply-To: <1461925930.98.0.579147295527.issue26884@psf.upfronthosting.co.za> Message-ID: <20160604224409.23397.28857.AEEDD24C@psf.io> Roundup Robot added the comment: New changeset d00837de03d7 by doko in branch '3.5': - Issue #26884: Fix linking extension modules for cross builds. https://hg.python.org/cpython/rev/d00837de03d7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 18:44:37 2016 From: report at bugs.python.org (Matthias Klose) Date: Sat, 04 Jun 2016 22:44:37 +0000 Subject: [issue26884] android: cross-compilation of extension module links to the wrong python library In-Reply-To: <1461925930.98.0.579147295527.issue26884@psf.upfronthosting.co.za> Message-ID: <1465080277.14.0.620641308093.issue26884@psf.upfronthosting.co.za> Changes by Matthias Klose : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 18:46:43 2016 From: report at bugs.python.org (Yusuke Tsutsumi) Date: Sat, 04 Jun 2016 22:46:43 +0000 Subject: [issue26467] Add async magic method support to unittest.mock.Mock In-Reply-To: <1456872706.59.0.97059255221.issue26467@psf.upfronthosting.co.za> Message-ID: <1465080403.38.0.135271521452.issue26467@psf.upfronthosting.co.za> Yusuke Tsutsumi added the comment: I'm interested in taking this on. I'm considering for this approach, creating a new MagicProxy class specifically for async, and assigning __aexit__ and __aenter__ to those. The __call__ method itself has to be detected as asynchronous, and I don't believe it's possible for a __call__ to behave appropriately for both asynchronous and synchronous cases. ---------- nosy: +tsutsumi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 18:53:01 2016 From: report at bugs.python.org (Matthias Klose) Date: Sat, 04 Jun 2016 22:53:01 +0000 Subject: [issue27201] expose the ABI name as a config variable In-Reply-To: <1464993442.58.0.656419844053.issue27201@psf.upfronthosting.co.za> Message-ID: <1465080781.77.0.682973278545.issue27201@psf.upfronthosting.co.za> Matthias Klose added the comment: maybe we don't need that. you already can do: import sys '%s-%d%d%s' % (sys.implementation.name, sys.version_info[0], sys.version_info[1], sys.abiflags) 'cpython-35m' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 18:59:34 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 04 Jun 2016 22:59:34 +0000 Subject: [issue27182] PEP 519 support in the stdlib In-Reply-To: <1464887789.1.0.970652730446.issue27182@psf.upfronthosting.co.za> Message-ID: <1465081174.51.0.735839424614.issue27182@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: If we do that, then os.* functions that accept fds would also work on objects whose __fspath__ method returns an integer. I don't think that is desirable (I was just writing a test to ensure that fspath returning an integer throws an error). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 19:12:07 2016 From: report at bugs.python.org (Demur Rumed) Date: Sat, 04 Jun 2016 23:12:07 +0000 Subject: [issue27213] Rework CALL_FUNCTION* opcodes In-Reply-To: <1465026334.02.0.369802561902.issue27213@psf.upfronthosting.co.za> Message-ID: <1465081927.16.0.252243009825.issue27213@psf.upfronthosting.co.za> Demur Rumed added the comment: I'd like to take on creating a patch for this proposal once #27140 lands ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 19:13:28 2016 From: report at bugs.python.org (Matthias Klose) Date: Sat, 04 Jun 2016 23:13:28 +0000 Subject: [issue23968] rename the platform directory from plat-$(MACHDEP) to plat-$(PLATFORM_TRIPLET) In-Reply-To: <1429124647.47.0.946423694262.issue23968@psf.upfronthosting.co.za> Message-ID: <1465082008.93.0.693726910055.issue23968@psf.upfronthosting.co.za> Matthias Klose added the comment: attaching an updated patch. besides renaming of the platform directory, the following changes are made: - it makes the name of the internal _sysconfigdata module dependent on the abiflags - it moves the _sysconfigdata module into the platform directory. This address as well #22724, it should address #18083 as well, provided that some multiarch tuples for solaris are defined. - it fixes regeneration of the Python modules from C headers for cross builds. - it introduces a sys.implementation._multiarch attribute to construct the name of the platform directory without having the _sysconfigdata module available (which now is located in the platform dir) One outstanding issue probably is the generation of the platform directory in the source tree, not in the build tree (but this is existing behaviour). This should address #12619 (this patch probably needs an update), ---------- keywords: +patch Added file: http://bugs.python.org/file43214/platdir2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 19:18:05 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jun 2016 23:18:05 +0000 Subject: [issue21272] use _sysconfigdata to itinialize distutils.sysconfig In-Reply-To: <1397686328.42.0.129070062942.issue21272@psf.upfronthosting.co.za> Message-ID: <20160604231802.100911.10463.2E3DEEDD@psf.io> Roundup Robot added the comment: New changeset 3fa8aebed636 by doko in branch 'default': - Issue #21272: Use _sysconfigdata.py to initialize distutils.sysconfig. https://hg.python.org/cpython/rev/3fa8aebed636 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 19:18:23 2016 From: report at bugs.python.org (Matthias Klose) Date: Sat, 04 Jun 2016 23:18:23 +0000 Subject: [issue21272] use _sysconfigdata to itinialize distutils.sysconfig In-Reply-To: <1397686328.42.0.129070062942.issue21272@psf.upfronthosting.co.za> Message-ID: <1465082303.15.0.464258310316.issue21272@psf.upfronthosting.co.za> Changes by Matthias Klose : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 19:24:19 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jun 2016 23:24:19 +0000 Subject: [issue25548] Show the address in the repr for class objects In-Reply-To: <1446576011.58.0.372024983976.issue25548@psf.upfronthosting.co.za> Message-ID: <20160604232416.21442.92171.70601D5D@psf.io> Roundup Robot added the comment: New changeset af29d89083b3 by Kushal Das in branch 'default': Issue #25548: Showing memory address of class objects in repl https://hg.python.org/cpython/rev/af29d89083b3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 19:28:23 2016 From: report at bugs.python.org (Matthias Klose) Date: Sat, 04 Jun 2016 23:28:23 +0000 Subject: [issue27101] Compilation of python (modules) for foreign target platform problem. In-Reply-To: <1464066887.71.0.116030526807.issue27101@psf.upfronthosting.co.za> Message-ID: <1465082903.11.0.166519863048.issue27101@psf.upfronthosting.co.za> Matthias Klose added the comment: The 0002-* patches look fine, however the 0001-* patches are wrong if you are in a Multi-Arch environment, where you can find valid headers in /usr/include. From my point of view, the set of include and header directories should be directly initialized from the compiler defaults, and not hard coded. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 19:33:00 2016 From: report at bugs.python.org (Matthias Klose) Date: Sat, 04 Jun 2016 23:33:00 +0000 Subject: [issue20210] Provide configure options to enable/disable Python modules and extensions In-Reply-To: <1389307962.8.0.973949637829.issue20210@psf.upfronthosting.co.za> Message-ID: <1465083180.28.0.920982640762.issue20210@psf.upfronthosting.co.za> Matthias Klose added the comment: fyi, this came up again at the 2016 Language Summit, the request here was to provide some minimal packages which are just enough to run a cloud image (the cloud-init package requires a somehow minimal python). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 19:38:39 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jun 2016 23:38:39 +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: <20160604233836.100777.27981.AD0CDEB4@psf.io> Roundup Robot added the comment: New changeset 0a8509023c09 by doko in branch 'default': - Issue #21277: Don't try to link _ctypes with a ffi_convenience library. https://hg.python.org/cpython/rev/0a8509023c09 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 19:39:08 2016 From: report at bugs.python.org (Matthias Klose) Date: Sat, 04 Jun 2016 23:39:08 +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: <1465083548.8.0.030181351491.issue21277@psf.upfronthosting.co.za> Changes by Matthias Klose : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 19:45:41 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 04 Jun 2016 23:45:41 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1465083941.8.0.479162760777.issue27186@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: This patch adds support for fspath to a number of functions in the os module by augmenting the path_t argument converter. The tests only cover a subset of the functions that use path_t, because some (e.g., unlink) have destructive side effects. ---------- Added file: http://bugs.python.org/file43215/issue27186-os_path_t.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 19:56:22 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 04 Jun 2016 23:56:22 +0000 Subject: [issue21916] Create unit tests for turtle textonly In-Reply-To: <1404479564.66.0.23163619156.issue21916@psf.upfronthosting.co.za> Message-ID: <1465084582.5.0.531762835953.issue21916@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Patch tests constructor, repr, equality checks, and pickling on Vec2D. ---------- Added file: http://bugs.python.org/file43216/issue21916-more.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 19:59:43 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 04 Jun 2016 23:59:43 +0000 Subject: [issue22724] byte-compile fails for cross-builds In-Reply-To: <1414194759.57.0.515625475535.issue22724@psf.upfronthosting.co.za> Message-ID: <1465084783.86.0.156033062129.issue22724@psf.upfronthosting.co.za> Nick Coghlan added the comment: Issue 23968 moves _sysconfigdata.py to an arch dependendent directory ---------- dependencies: +rename the platform directory from plat-$(MACHDEP) to plat-$(PLATFORM_TRIPLET) nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 20:00:15 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 05 Jun 2016 00:00:15 +0000 Subject: [issue18083] _sysconfigdata.py is installed in an arch-independent directory In-Reply-To: <1369758893.79.0.620751759494.issue18083@psf.upfronthosting.co.za> Message-ID: <1465084815.24.0.435820933963.issue18083@psf.upfronthosting.co.za> Nick Coghlan added the comment: Issue 23968 moves _sysconfigdata.py to an arch dependent directory ---------- dependencies: +rename the platform directory from plat-$(MACHDEP) to plat-$(PLATFORM_TRIPLET) nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 20:06:33 2016 From: report at bugs.python.org (Russell Keith-Magee) Date: Sun, 05 Jun 2016 00:06:33 +0000 Subject: [issue23968] rename the platform directory from plat-$(MACHDEP) to plat-$(PLATFORM_TRIPLET) In-Reply-To: <1429124647.47.0.946423694262.issue23968@psf.upfronthosting.co.za> Message-ID: <1465085193.03.0.464335148945.issue23968@psf.upfronthosting.co.za> Changes by Russell Keith-Magee : ---------- nosy: +freakboy3742 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 20:21:52 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sun, 05 Jun 2016 00:21:52 +0000 Subject: [issue27219] turtle.fillcolor doesn't accept a tuple of floats In-Reply-To: <1465057740.31.0.354444599914.issue27219@psf.upfronthosting.co.za> Message-ID: <1465086112.26.0.657647006777.issue27219@psf.upfronthosting.co.za> Changes by Jelle Zijlstra : ---------- keywords: +patch Added file: http://bugs.python.org/file43217/issue27219.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 20:22:38 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 05 Jun 2016 00:22:38 +0000 Subject: [issue23968] rename the platform directory from plat-$(MACHDEP) to plat-$(PLATFORM_TRIPLET) In-Reply-To: <1429124647.47.0.946423694262.issue23968@psf.upfronthosting.co.za> Message-ID: <1465086158.32.0.24558101504.issue23968@psf.upfronthosting.co.za> Nick Coghlan added the comment: This may be of interest for iOS and Android cross-compilation, so I've added Xavier de Gaye to the nosy list, while Russell Keith-Magee added himself. ---------- nosy: +xdegaye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 20:25:01 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Jun 2016 00:25:01 +0000 Subject: [issue26930] Upgrade installers to OpenSSL 1.0.2h In-Reply-To: <1462285174.78.0.332365810571.issue26930@psf.upfronthosting.co.za> Message-ID: <20160605002443.1235.66093.62D25680@psf.io> Roundup Robot added the comment: New changeset d858eadf2602 by Ned Deily in branch '2.7': Issue #26930: Update OS X 32-bit-only installer builds to use OpenSSL 1.0.2h. https://hg.python.org/cpython/rev/d858eadf2602 New changeset 5462d455215a by Ned Deily in branch '3.5': Issue #26930: Update OS X 32-bit-only installer builds to use OpenSSL 1.0.2h. https://hg.python.org/cpython/rev/5462d455215a New changeset edf5ae3162ef by Ned Deily in branch 'default': Issue #26930: merge from 3.5 https://hg.python.org/cpython/rev/edf5ae3162ef ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 20:25:26 2016 From: report at bugs.python.org (Glenn Travis) Date: Sun, 05 Jun 2016 00:25:26 +0000 Subject: [issue27217] IDLE 3.5.1 not using Tk 8.6 In-Reply-To: <1465059641.44.0.891327679955.issue27217@psf.upfronthosting.co.za> Message-ID: Glenn Travis added the comment: Alas, I apologize ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 20:27:37 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 05 Jun 2016 00:27:37 +0000 Subject: [issue26930] Upgrade installers to OpenSSL 1.0.2h In-Reply-To: <1462285174.78.0.332365810571.issue26930@psf.upfronthosting.co.za> Message-ID: <1465086457.54.0.734245765864.issue26930@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- components: +Windows priority: normal -> critical stage: -> needs patch versions: +Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 20:33:36 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 05 Jun 2016 00:33:36 +0000 Subject: [issue25738] http.server doesn't handle RESET CONTENT status correctly In-Reply-To: <1448583978.87.0.253695569638.issue25738@psf.upfronthosting.co.za> Message-ID: <1465086816.64.0.558180260833.issue25738@psf.upfronthosting.co.za> Martin Panter added the comment: For a HEAD request, I think we should continue to send Content-Length (except in combination with one of the special responses). HEAD is slightly different to 304 Not Modified. With HEAD vs GET, the response code and other header values do not change, but the body is omitted. So it is plausible for a user to make the same send_error() call for both GET and HEAD. With 304 Not Modified, the response code _does_ change (304 is instead of e.g. 200), although other header values are allowed to be the same. The user would have to make a different send_error() call to trigger the different response code, and the body and length that would be generated is different. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 20:34:37 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 05 Jun 2016 00:34:37 +0000 Subject: [issue23968] rename the platform directory from plat-$(MACHDEP) to plat-$(PLATFORM_TRIPLET) In-Reply-To: <1429124647.47.0.946423694262.issue23968@psf.upfronthosting.co.za> Message-ID: <1465086877.27.0.102716577336.issue23968@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 20:46:11 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sun, 05 Jun 2016 00:46:11 +0000 Subject: [issue26336] Expose regex bytecode as attribute of compiled pattern object In-Reply-To: <1455163527.75.0.996534901196.issue26336@psf.upfronthosting.co.za> Message-ID: <1465087571.26.0.783347318319.issue26336@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: This patch exposes the bytecode as a __code__ attribute on pattern objects as a Unicode string (consistent with the internal representation as Py_UCS4 instances). ---------- keywords: +patch nosy: +Jelle Zijlstra Added file: http://bugs.python.org/file43218/issue26336.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 21:03:10 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 05 Jun 2016 01:03:10 +0000 Subject: [issue22257] PEP 432: Redesign the interpreter startup sequence In-Reply-To: <1408789351.84.0.0171822343712.issue22257@psf.upfronthosting.co.za> Message-ID: <1465088590.36.0.601182332458.issue22257@psf.upfronthosting.co.za> Nick Coghlan added the comment: Looking at the potential impact of being able to use C99 initializers for the main configuration structs, I realised those could be a *lot* easier to work with if they consisted entirely of pointers to Python objects: * NULL initialisation would correctly indicate "not set" for each value * Running Py_XDECREF on every field will correctly release memory * Boolean toggles are clearly separated from multi-value integers (PyBool vs PyLong) * No conversion is needed to provide a read-only view of the config data at the Python level This wouldn't be feasible for CoreConfig (since that is populated before Python object creation is permitted), but should work for MainInterpreterConfig and InterpreterConfig. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 21:04:16 2016 From: report at bugs.python.org (Susumu Koshiba) Date: Sun, 05 Jun 2016 01:04:16 +0000 Subject: [issue25738] http.server doesn't handle RESET CONTENT status correctly In-Reply-To: <1448583978.87.0.253695569638.issue25738@psf.upfronthosting.co.za> Message-ID: <1465088656.32.0.790765184146.issue25738@psf.upfronthosting.co.za> Susumu Koshiba added the comment: Thanks again for valuable comments. I agree that there could be a case where send_error() gets used for both HEAD and GET, in which case we could send content-length field as an optional field. However, if send_error() is not used for both HEAD and GET, then the body will likely be different and RFC specifies that we must not send content-length field with different values so I have a slight preference towards not sending it for HEAD request. If you are OK with leaving content-length out for HEAD, I'd like to proceed with creating a small patch to reflect your comments in code review and also start creating a patches for 2.7 and 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 21:08:22 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sun, 05 Jun 2016 01:08:22 +0000 Subject: [issue27200] make doctest in CPython has failures In-Reply-To: <1464988408.0.0.840317371896.issue27200@psf.upfronthosting.co.za> Message-ID: <1465088902.0.0.412548132478.issue27200@psf.upfronthosting.co.za> Changes by Jelle Zijlstra : ---------- assignee: -> Jelle Zijlstra _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 21:12:44 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sun, 05 Jun 2016 01:12:44 +0000 Subject: [issue26336] Expose regex bytecode as attribute of compiled pattern object In-Reply-To: <1455163527.75.0.996534901196.issue26336@psf.upfronthosting.co.za> Message-ID: <1465089164.3.0.235975647342.issue26336@psf.upfronthosting.co.za> Changes by Jelle Zijlstra : Added file: http://bugs.python.org/file43219/issue26336.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 21:12:59 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sun, 05 Jun 2016 01:12:59 +0000 Subject: [issue26336] Expose regex bytecode as attribute of compiled pattern object In-Reply-To: <1455163527.75.0.996534901196.issue26336@psf.upfronthosting.co.za> Message-ID: <1465089179.28.0.619932560376.issue26336@psf.upfronthosting.co.za> Changes by Jelle Zijlstra : Removed file: http://bugs.python.org/file43218/issue26336.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 21:15:43 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 05 Jun 2016 01:15:43 +0000 Subject: [issue13771] HTTPSConnection __init__ super implementation causes recursion error In-Reply-To: <1326304391.56.0.972578337686.issue13771@psf.upfronthosting.co.za> Message-ID: <1465089343.69.0.256789451034.issue13771@psf.upfronthosting.co.za> Martin Panter added the comment: My guess is Michael was doing something like >>> class Monkey(http.client.HTTPSConnection): ... pass ... >>> http.client.HTTPSConnection = Monkey >>> http.client.HTTPSConnection("bugs.python.org") Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.5/http/client.py", line 1210, in __init__ source_address) [. . .] File "/usr/lib/python3.5/http/client.py", line 1210, in __init__ source_address) File "/usr/lib/python3.5/http/client.py", line 1209, in __init__ super(HTTPSConnection, self).__init__(host, port, timeout, RecursionError: maximum recursion depth exceeded while calling a Python object Looking at , I think this problem has been overcome by also overriding __init__(). IMO Python shouldn?t go very far out of its way to support monkey patching, and in this case the workaround was disliked by Eric. Given these two facts and no apparent interest since, I think we should close this. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 21:20:33 2016 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Sun, 05 Jun 2016 01:20:33 +0000 Subject: [issue27223] _ready_ready and _write_ready should respect _conn_lost Message-ID: <1465089633.03.0.133113775178.issue27223@psf.upfronthosting.co.za> New submission from ?ukasz Langa: Currently _read_ready and _write_ready callbacks do not respect _conn_lost, which makes them vulnerable to the following race condition: - the client protocol connects to a server - the client protocol sends some data - the server sends some data back - in the mean time, something causes the connection to be lost and that information gets handled by the client protocol first - the client transport receives _read_ready but now the connection is already marked as lost and cleared on the transport This causes an ugly exception to be raised: Exception in callback _SelectorSocketTransport._read_ready() handle: Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/asyncio/selector_events.py", line 664, in _read_ready data = self._sock.recv(self.max_size) AttributeError: 'NoneType' object has no attribute 'recv' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/asyncio/events.py", line 125, in _run self._callback(*self._args) File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/asyncio/selector_events.py", line 668, in _read_ready self._fatal_error(exc, 'Fatal read error on socket transport') File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/asyncio/selector_events.py", line 587, in _fatal_error self._loop.call_exception_handler({ AttributeError: 'NoneType' object has no attribute 'call_exception_handler' This can be reproduced by running srv.py and cli.py attached here. Since this is an event loop timing issue, it might take a few tries of cli.py to the issue to surface. I get it to repro more consistently with PYTHONASYNCIODEBUG=1. In production I get this issue most often when there's a torrent of simultaneous connections being created while existing protocol connections are already being handled. To fix this, I propose to add guards for _conn_lost on both _ready_ready and _write_ready. See attached patch. This doesn't break any existing assumptions because we can't really respond to I/O events on a connection that's reset. The patch also changes 3 existing unit tests, which I believe are currently invalid. test_write_ready_exception_close simulates filling the buffer and calling _write_ready after the transport has been closed. This means _call_connection_lost has been called and now _sock is None and _loop is None. We'd have AttributeError raised (like in the traceback above) and not OSError like the test believes. That would cause the same except clause to be invoked but then (like in the traceback above) _fatal_error fails due to _loop being None. I renamed the test test_transport_close_remove_writer and removed the _write_ready assumptions in it. test_write_ready_send_closing required a change so that the buffer is non-empty BEFORE transport.close() is called. In this case close() doesn't remove the writer and schedule connection_lost. Instead, this is done by _write_ready after the write has been sent out. I also removed the following assert: `self.assertFalse(self.loop.writers)` because it's true during the entire execution of the test (in other words, checks nothing). test_write_ready_send_closing_empty_buffer checks for _call_connection_lost to be called but in fact _call_connection_lost is scheduled to be called_soon in transport.close(). I changed the test to reflect this. ---------- assignee: lukasz.langa components: asyncio messages: 267360 nosy: asvetlov, gvanrossum, haypo, lukasz.langa, yselivanov priority: normal severity: normal status: open title: _ready_ready and _write_ready should respect _conn_lost versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 21:21:31 2016 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Sun, 05 Jun 2016 01:21:31 +0000 Subject: [issue27223] _ready_ready and _write_ready should respect _conn_lost In-Reply-To: <1465089633.03.0.133113775178.issue27223@psf.upfronthosting.co.za> Message-ID: <1465089691.49.0.17738878534.issue27223@psf.upfronthosting.co.za> Changes by ?ukasz Langa : ---------- keywords: +patch Added file: http://bugs.python.org/file43220/issue27223.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 21:21:40 2016 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Sun, 05 Jun 2016 01:21:40 +0000 Subject: [issue27223] _ready_ready and _write_ready should respect _conn_lost In-Reply-To: <1465089633.03.0.133113775178.issue27223@psf.upfronthosting.co.za> Message-ID: <1465089700.08.0.669445248549.issue27223@psf.upfronthosting.co.za> Changes by ?ukasz Langa : Added file: http://bugs.python.org/file43221/cli.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 21:21:50 2016 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Sun, 05 Jun 2016 01:21:50 +0000 Subject: [issue27223] _ready_ready and _write_ready should respect _conn_lost In-Reply-To: <1465089633.03.0.133113775178.issue27223@psf.upfronthosting.co.za> Message-ID: <1465089710.82.0.746743870685.issue27223@psf.upfronthosting.co.za> Changes by ?ukasz Langa : Added file: http://bugs.python.org/file43222/srv.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 21:51:30 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 05 Jun 2016 01:51:30 +0000 Subject: [issue25738] http.server doesn't handle RESET CONTENT status correctly In-Reply-To: <1448583978.87.0.253695569638.issue25738@psf.upfronthosting.co.za> Message-ID: <1465091490.2.0.118246569871.issue25738@psf.upfronthosting.co.za> Martin Panter added the comment: I think it would be unusual to have different error handling for GET vs HEAD, given HEAD is supposed to be exactly like GET but without a body. On the other hand, see SimpleHTTPRequestHandler.send_head() for an example of calling send_error(NOT_FOUND) for both GET and HEAD. Both Content-Length and Content-Type are for the would-be error message body: HEAD /nonexistant HTTP/1.0 HTTP/1.0 404 File not found Server: SimpleHTTP/0.6 Python/3.5.1 Date: Sun, 05 Jun 2016 01:40:55 GMT Content-Type: text/html;charset=utf-8 Connection: close Content-Length: 469 Removing Content-Length (and arguably also Content-Type) for HEAD would be an unwanted change in behaviour IMO. Instead, perhaps you would prefer to document that equivalent calls to send_error() should be made for HEAD and GET responses? A separate 2.7 patch would be helpful (the filenames are different for a start, and the code is slightly different; I don?t think there is any Content-Length added). But I doubt a patch for 3.5 will be worthwhile. Instead, I will probably just apply your 3.6 patch to 3.5 and then merge forward. ---------- versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 22:22:25 2016 From: report at bugs.python.org (Susumu Koshiba) Date: Sun, 05 Jun 2016 02:22:25 +0000 Subject: [issue25738] http.server doesn't handle RESET CONTENT status correctly In-Reply-To: <1448583978.87.0.253695569638.issue25738@psf.upfronthosting.co.za> Message-ID: <1465093345.02.0.895483738188.issue25738@psf.upfronthosting.co.za> Susumu Koshiba added the comment: Thanks, makes sense to me. I've created patches for 2.7, 3.5, 3.6. 3.5's implementation looked slightly different from 3.6 so I've decided to create a separate patch, just in case. I will upload them 1 by 1 starting with 2.7. It will get a bit noisy here(sorry). ---------- Added file: http://bugs.python.org/file43223/issue25738_http_reset_content_2.7_01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 22:26:12 2016 From: report at bugs.python.org (Susumu Koshiba) Date: Sun, 05 Jun 2016 02:26:12 +0000 Subject: [issue25738] http.server doesn't handle RESET CONTENT status correctly In-Reply-To: <1448583978.87.0.253695569638.issue25738@psf.upfronthosting.co.za> Message-ID: <1465093572.78.0.92528702938.issue25738@psf.upfronthosting.co.za> Susumu Koshiba added the comment: 3.5 patch. ---------- Added file: http://bugs.python.org/file43224/issue25738_http_reset_content_3.5_01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 22:30:17 2016 From: report at bugs.python.org (Susumu Koshiba) Date: Sun, 05 Jun 2016 02:30:17 +0000 Subject: [issue25738] http.server doesn't handle RESET CONTENT status correctly In-Reply-To: <1448583978.87.0.253695569638.issue25738@psf.upfronthosting.co.za> Message-ID: <1465093817.24.0.594463806217.issue25738@psf.upfronthosting.co.za> Susumu Koshiba added the comment: 3.6 patch(..._05.patch file) ---------- Added file: http://bugs.python.org/file43225/issue25738_http_reset_content_05.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 22:32:10 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 05 Jun 2016 02:32:10 +0000 Subject: [issue13771] HTTPSConnection __init__ super implementation causes recursion error In-Reply-To: <1326304391.56.0.972578337686.issue13771@psf.upfronthosting.co.za> Message-ID: <1465093930.01.0.765968539395.issue13771@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 22:32:32 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 05 Jun 2016 02:32:32 +0000 Subject: [issue27224] IDLE: editor versus grep line number differ Message-ID: <1465093952.02.0.213444129237.issue27224@psf.upfronthosting.co.za> New submission from Terry J. Reedy: In IDLE 3.6, open idlelib.macosx (^M easiest). Open Find in Files dialog (Alt-F3), enter 'isAquaTk' (without quotes), and go. Output for me currently looks like ...\idlelib\macosx.py: 9: warnings.warn("runningAsOSXApp() is deprecated, use isAquaTk()", ...\idlelib\macosx.py: 11: return isAquaTk() ...\idlelib\macosx.py: 23: isAquaTk(), isCarbonTk(), isCocoaTk()... ...\idlelib\macosx.py: 39: def isAquaTk(): ...\idlelib\macosx.py: 226: isAquaTk(), isCarbonTk(), isCocoaTk()... ...\idlelib\macosx.py: 230: if isAquaTk(): The first 4 line numbers are correct. The last two should be 232 and 236 to match the editor. Or the editor numbers should be 226 and 230 to match grep. I have not yet tried to cound to see which is correct, or look to see if there are long or continued lines that might throw one count off. I should copy the file and delete lines between 39 and 226. ---------- messages: 267365 nosy: terry.reedy priority: normal severity: normal stage: test needed status: open title: IDLE: editor versus grep line number differ type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 22:42:24 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 05 Jun 2016 02:42:24 +0000 Subject: [issue27156] IDLE: remove unused code In-Reply-To: <1464553304.91.0.34770795987.issue27156@psf.upfronthosting.co.za> Message-ID: <1465094544.11.0.365391250254.issue27156@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Patch removed 1 & 2. 4. macosx.runningAsOSXApp and macosx.isCarbonAquaTk were deprecated in then current versions on 2014 Feb 27 by New Deily in #17654. In particular, 67a7a49e7b78 was applied to the future 3.4.1. Ned, do you have any objection to removing these now, for 3.6? I checked the usage of isXyz functions outside the definitions and deprecated functions. isAquaTk: 8, isCarbonTk: 2, isCocoaTk: 5, isXQuartz: 0. I gather from www.python.org/download/mac/tcltk/ that Carbon might still be in use on machines with early 8.5 and that XQuartz is still in use and might be needed in the future. Also, since exactly 1 of 'Aqua' and 'XQuartz' are true on current machines running 8.5+, they are currently reduncant, but this could change in the future. So I don't propose any deletion for this group. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 22:58:54 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Jun 2016 02:58:54 +0000 Subject: [issue26372] Popen.communicate not ignoring BrokenPipeError In-Reply-To: <1455672512.72.0.551664124622.issue26372@psf.upfronthosting.co.za> Message-ID: <20160605025851.13690.90076.E4AFD5B5@psf.io> Roundup Robot added the comment: New changeset e89eb7935ca9 by Gregory P. Smith in branch 'default': merge from 3.5. (moves the issue26372 tests to the proper class) https://hg.python.org/cpython/rev/e89eb7935ca9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 23:08:15 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Jun 2016 03:08:15 +0000 Subject: [issue27203] Failing doctests in Doc/faq/programming.rst In-Reply-To: <1464999592.59.0.0136488038508.issue27203@psf.upfronthosting.co.za> Message-ID: <20160605030812.1235.31567.CBB5219D@psf.io> Roundup Robot added the comment: New changeset fea14da8442d by Senthil Kumaran in branch '3.5': Issue27203 - Fix doctests Doc/faq/programming.rst. https://hg.python.org/cpython/rev/fea14da8442d New changeset 4a072fff6945 by Senthil Kumaran in branch 'default': [merge from 3.5] - Issue27203 - Fix doctests Doc/faq/programming.rst. https://hg.python.org/cpython/rev/4a072fff6945 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 23:12:22 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 05 Jun 2016 03:12:22 +0000 Subject: [issue27203] Failing doctests in Doc/faq/programming.rst In-Reply-To: <1464999592.59.0.0136488038508.issue27203@psf.upfronthosting.co.za> Message-ID: <1465096342.45.0.430104107259.issue27203@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Thanks for the patch, Jelle Zijlstra. We don't have warnings in Doc/faq/programming.rst now, and this issue was specific to fix the doctests for it. I find it complete. Closing this issue. ---------- nosy: +orsenthil resolution: -> fixed stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 23:53:43 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Jun 2016 03:53:43 +0000 Subject: [issue27202] make doctest fails on 2.7 release notes In-Reply-To: <1464998646.05.0.234628246633.issue27202@psf.upfronthosting.co.za> Message-ID: <20160605035339.21051.71837.072EA732@psf.io> Roundup Robot added the comment: New changeset 70af472451cb by Senthil Kumaran in branch '3.5': issue27202 - Exclude 2.x release notes from python3 make doctests. https://hg.python.org/cpython/rev/70af472451cb New changeset 2bb806539ca6 by Senthil Kumaran in branch 'default': [merge from 3.5] - issue27202 - Exclude 2.x release notes from python3 make doctests. https://hg.python.org/cpython/rev/2bb806539ca6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 4 23:54:15 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 05 Jun 2016 03:54:15 +0000 Subject: [issue27202] make doctest fails on 2.7 release notes In-Reply-To: <1464998646.05.0.234628246633.issue27202@psf.upfronthosting.co.za> Message-ID: <1465098855.53.0.669380838164.issue27202@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Thanks for your contribution, Jelle. ---------- nosy: +orsenthil resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 00:00:43 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 05 Jun 2016 04:00:43 +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: <1465099243.87.0.989719252049.issue17611@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 00:03:23 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 05 Jun 2016 04:03:23 +0000 Subject: [issue27202] make doctest fails on 2.7 release notes In-Reply-To: <1464998646.05.0.234628246633.issue27202@psf.upfronthosting.co.za> Message-ID: <1465099403.35.0.346067293285.issue27202@psf.upfronthosting.co.za> Berker Peksag added the comment: Perhaps it would be better to exclude all files in Doc/whatsnew. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 00:21:16 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 05 Jun 2016 04:21:16 +0000 Subject: [issue27200] make doctest in CPython has failures In-Reply-To: <1464988408.0.0.840317371896.issue27200@psf.upfronthosting.co.za> Message-ID: <1465100476.89.0.628446197968.issue27200@psf.upfronthosting.co.za> Berker Peksag added the comment: I have also found some markup errors via 'make doctest' so I agree that this can be helpful :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 00:30:52 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 05 Jun 2016 04:30:52 +0000 Subject: [issue26372] Popen.communicate not ignoring BrokenPipeError In-Reply-To: <1455672512.72.0.551664124622.issue26372@psf.upfronthosting.co.za> Message-ID: <1465101052.85.0.767178852706.issue26372@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 00:33:06 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 05 Jun 2016 04:33:06 +0000 Subject: [issue27202] make doctest fails on 2.7 release notes In-Reply-To: <1464998646.05.0.234628246633.issue27202@psf.upfronthosting.co.za> Message-ID: <1465101186.98.0.181649824424.issue27202@psf.upfronthosting.co.za> Berker Peksag added the comment: By the way, after this I'm getting the following warnings: /Users/berkerpeksag/projects/cpython/Doc/whatsnew/index.rst:11: WARNING: toctree contains reference to nonexisting document 'whatsnew/2.7' /Users/berkerpeksag/projects/cpython/Doc/whatsnew/index.rst:11: WARNING: toctree contains reference to nonexisting document 'whatsnew/2.6' /Users/berkerpeksag/projects/cpython/Doc/whatsnew/index.rst:11: WARNING: toctree contains reference to nonexisting document 'whatsnew/2.5' /Users/berkerpeksag/projects/cpython/Doc/whatsnew/index.rst:11: WARNING: toctree contains reference to nonexisting document 'whatsnew/2.4' /Users/berkerpeksag/projects/cpython/Doc/whatsnew/index.rst:11: WARNING: toctree contains reference to nonexisting document 'whatsnew/2.3' /Users/berkerpeksag/projects/cpython/Doc/whatsnew/index.rst:11: WARNING: toctree contains reference to nonexisting document 'whatsnew/2.2' /Users/berkerpeksag/projects/cpython/Doc/whatsnew/index.rst:11: WARNING: toctree contains reference to nonexisting document 'whatsnew/2.1' /Users/berkerpeksag/projects/cpython/Doc/whatsnew/index.rst:11: WARNING: toctree contains reference to nonexisting document 'whatsnew/2.0' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 00:37:49 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Jun 2016 04:37:49 +0000 Subject: [issue17888] docs: more information on documentation team In-Reply-To: <1367412914.06.0.588625037016.issue17888@psf.upfronthosting.co.za> Message-ID: <20160605043745.21538.9226.2DD05934@psf.io> Roundup Robot added the comment: New changeset 3136c67eac4d by Berker Peksag in branch '3.5': Issue #17888: Add a note about contributing to Python docs https://hg.python.org/cpython/rev/3136c67eac4d New changeset 1f8181e66b36 by Berker Peksag in branch 'default': Issue #17888: Merge from 3.5 https://hg.python.org/cpython/rev/1f8181e66b36 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 00:38:34 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sun, 05 Jun 2016 04:38:34 +0000 Subject: [issue27202] make doctest fails on 2.7 release notes In-Reply-To: <1464998646.05.0.234628246633.issue27202@psf.upfronthosting.co.za> Message-ID: <1465101514.46.0.0442068584282.issue27202@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Yes, I realized this patch is wrong: it excludes the 2.7 release notes from all make steps, not just `make doctest`. The attached patch reverts the conf.py change and instead uses directives to skip most doctests in the 2.7 release notes. The other 2.x release notes have no failing doctests. ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 00:38:49 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 05 Jun 2016 04:38:49 +0000 Subject: [issue17888] docs: more information on documentation team In-Reply-To: <1367412914.06.0.588625037016.issue17888@psf.upfronthosting.co.za> Message-ID: <1465101529.96.0.495917133898.issue17888@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patches Terry and Laura. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 00:39:34 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Jun 2016 04:39:34 +0000 Subject: [issue21916] Create unit tests for turtle textonly In-Reply-To: <1404479564.66.0.23163619156.issue21916@psf.upfronthosting.co.za> Message-ID: <1465101574.57.0.59966393216.issue21916@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Jelle. Added minor comments on Rietveld. ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 00:53:53 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sun, 05 Jun 2016 04:53:53 +0000 Subject: [issue27202] make doctest fails on 2.7 release notes In-Reply-To: <1464998646.05.0.234628246633.issue27202@psf.upfronthosting.co.za> Message-ID: <1465102433.5.0.902003547842.issue27202@psf.upfronthosting.co.za> Changes by Jelle Zijlstra : Added file: http://bugs.python.org/file43226/issue27202-revised.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 00:58:12 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Jun 2016 04:58:12 +0000 Subject: [issue23401] Add pickle support of Mapping views In-Reply-To: <1423216735.87.0.773240969368.issue23401@psf.upfronthosting.co.za> Message-ID: <1465102692.19.0.511284623339.issue23401@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In this case we need to implement pickle support separately in OrderedDict and any Mapping subclass. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 00:59:07 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 05 Jun 2016 04:59:07 +0000 Subject: [issue24459] Mention PYTHONFAULTHANDLER in the man page In-Reply-To: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za> Message-ID: <1465102747.55.0.761523252117.issue24459@psf.upfronthosting.co.za> Berker Peksag added the comment: I left some review comments on Rietveld: http://bugs.python.org/review/24459/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 01:04:12 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Jun 2016 05:04:12 +0000 Subject: [issue26336] Expose regex bytecode as attribute of compiled pattern object In-Reply-To: <1455163527.75.0.996534901196.issue26336@psf.upfronthosting.co.za> Message-ID: <1465103052.43.0.279853149354.issue26336@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: __code__ is associated with Python bytecode. Regex bytecode can't be represented as a Unicode string since it is a sequence of 32-bit integers that can be out of the ord(sys.maxunicode) limit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 01:09:44 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 05 Jun 2016 05:09:44 +0000 Subject: [issue27225] Potential refleak in type_new when setting __new__ fails Message-ID: <1465103384.56.0.665508256655.issue27225@psf.upfronthosting.co.za> New submission from Xiang Zhang: As the title, there seems to be a potential refleak in type_new when setting __new__ fails. ---------- files: refleak_in_type_new.patch keywords: patch messages: 267382 nosy: xiang.zhang priority: normal severity: normal status: open title: Potential refleak in type_new when setting __new__ fails versions: Python 3.6 Added file: http://bugs.python.org/file43227/refleak_in_type_new.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 01:12:54 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 05 Jun 2016 05:12:54 +0000 Subject: [issue23401] Add pickle support of Mapping views In-Reply-To: <1423216735.87.0.773240969368.issue23401@psf.upfronthosting.co.za> Message-ID: <1465103574.67.0.861284621615.issue23401@psf.upfronthosting.co.za> Guido van Rossum added the comment: I find it extremely suspicious that if you pickle the keys of a large object it also pickles that object. These are views, not copied data, for a reason. I also take back that this is okay for concrete dict. As for your reason (http://bugs.python.org/issue23401#msg267317), that doesn't explain the use case for pickling keys views. If you forbade pickling them would any user code break? I seriously doubt it. Who on earth would want to pickle a keys view on an OrderedDict? It doesn't contain any information other than the underlying object. These views exist as alternate APIs to dicts, not as objects by themselves. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 01:13:51 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 05 Jun 2016 05:13:51 +0000 Subject: [issue23264] Add pickle support of dict views In-Reply-To: <1421568716.9.0.947546089999.issue23264@psf.upfronthosting.co.za> Message-ID: <1465103631.41.0.70713720088.issue23264@psf.upfronthosting.co.za> Guido van Rossum added the comment: Hm, I no longer think this is a good idea. See http://bugs.python.org/issue23401#msg267383 . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 01:23:23 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Jun 2016 05:23:23 +0000 Subject: [issue27202] make doctest fails on 2.7 release notes In-Reply-To: <1464998646.05.0.234628246633.issue27202@psf.upfronthosting.co.za> Message-ID: <20160605052320.120019.351.EB79690F@psf.io> Roundup Robot added the comment: New changeset 378c1d09b256 by Senthil Kumaran in branch '3.5': issue27202 - Fix the mistake in changesets 70af472451cb (3.5) and 2bb806539ca6 (3.6) https://hg.python.org/cpython/rev/378c1d09b256 New changeset 31573473a50e by Senthil Kumaran in branch 'default': [merge from 3.5] - issue27202 - Fix the mistake in changesets 70af472451cb (3.5) and 2bb806539ca6 (3.6) https://hg.python.org/cpython/rev/31573473a50e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 01:24:06 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 05 Jun 2016 05:24:06 +0000 Subject: [issue27202] make doctest fails on 2.7 release notes In-Reply-To: <1464998646.05.0.234628246633.issue27202@psf.upfronthosting.co.za> Message-ID: <1465104246.85.0.493382789118.issue27202@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Addressed the problem with the previous commit. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 01:29:51 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sun, 05 Jun 2016 05:29:51 +0000 Subject: [issue21916] Create unit tests for turtle textonly In-Reply-To: <1404479564.66.0.23163619156.issue21916@psf.upfronthosting.co.za> Message-ID: <1465104591.52.0.338705528847.issue21916@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Thanks, this patch addresses your comments. ---------- Added file: http://bugs.python.org/file43228/issue21916-more-cr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 01:50:09 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sun, 05 Jun 2016 05:50:09 +0000 Subject: [issue26336] Expose regex bytecode as attribute of compiled pattern object In-Reply-To: <1455163527.75.0.996534901196.issue26336@psf.upfronthosting.co.za> Message-ID: <1465105809.52.0.0362798039446.issue26336@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Thanks for the feedback. This patch instead exposes the code as a tuple of integers named __pattern_code__. "Bytecode" is technically inaccurate since the code isn't limited to bytes but can contain larger integers. ---------- Added file: http://bugs.python.org/file43229/issue26336-cr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 02:03:29 2016 From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=) Date: Sun, 05 Jun 2016 06:03:29 +0000 Subject: [issue27226] distutils: unable to compile both .opt-1.pyc and .opt2.pyc simultaneously Message-ID: <1465106608.99.0.622112847685.issue27226@psf.upfronthosting.co.za> New submission from Micha? G?rny: Since 3.5, optimized Python modules for -O and -OO are installed using different names. The Python build system itself seems to been prepared for this as Python itself is built with both .opt-1.pyc and .opt-2.pyc files built. However, distutils at the moment can only install one of them. Gentoo is relying on 'setup.py install --compile -O2' doing the right thing. We can change the arguments if necessary but calling it twice would require a lot of conditional changes to how we build packages. Of course, not installing both variants is not an option since it causes Python to attempt to write them at runtime later. Could we please get some way to build both .opt-1.pyc and .opt-2.pyc in setup.py install? Either through making -O2 build also -O1 implicitly, or providing an ability to specify multiple optimization levels. Relevant Gentoo bug: https://bugs.gentoo.org/585060 ---------- components: Distutils messages: 267389 nosy: dstufft, eric.araujo, mgorny priority: normal severity: normal status: open title: distutils: unable to compile both .opt-1.pyc and .opt2.pyc simultaneously type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 02:12:12 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 05 Jun 2016 06:12:12 +0000 Subject: [issue25738] http.server doesn't handle RESET CONTENT status correctly In-Reply-To: <1448583978.87.0.253695569638.issue25738@psf.upfronthosting.co.za> Message-ID: <1465107132.57.0.292790503583.issue25738@psf.upfronthosting.co.za> Martin Panter added the comment: Sorry to be a pain, but I think the new logic for HEAD is wrong. See review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 02:21:19 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 05 Jun 2016 06:21:19 +0000 Subject: [issue27164] zlib can't decompress DEFLATE using shared dictionary In-Reply-To: <1464687663.75.0.126366287594.issue27164@psf.upfronthosting.co.za> Message-ID: <1465107679.94.0.0327521238465.issue27164@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch which I propose to use that factors out a set_inflate_zdict() function. I think this will help with maintainence, e.g. if someone changes the UINT_MAX checking, but forgets that there are two places than need changing. Let me know if that is okay with you :) ---------- components: +Extension Modules -Library (Lib) stage: patch review -> commit review versions: +Python 3.6 Added file: http://bugs.python.org/file43230/raw-zdict.v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 02:34:58 2016 From: report at bugs.python.org (SilentGhost) Date: Sun, 05 Jun 2016 06:34:58 +0000 Subject: [issue27188] sqlite3 execute* methods return value not documented In-Reply-To: <1464904414.88.0.548243958784.issue27188@psf.upfronthosting.co.za> Message-ID: <1465108498.46.0.798988647899.issue27188@psf.upfronthosting.co.za> SilentGhost added the comment: Thanks for the patch, Dave. For whatever reason it doesn't seem to apply cleanly to the current tip, would you mind preparing a new patch that does? ---------- assignee: -> docs at python components: +Documentation nosy: +SilentGhost, berker.peksag, docs at python, ghaering stage: -> patch review type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 02:49:27 2016 From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=) Date: Sun, 05 Jun 2016 06:49:27 +0000 Subject: [issue27226] distutils: unable to compile both .opt-1.pyc and .opt2.pyc simultaneously In-Reply-To: <1465106608.99.0.622112847685.issue27226@psf.upfronthosting.co.za> Message-ID: <1465109367.59.0.908037103601.issue27226@psf.upfronthosting.co.za> Changes by Micha? G?rny : ---------- keywords: +patch Added file: http://bugs.python.org/file43231/0001-distutils-make-OO-enable-both-opt-1-and-opt-2-optimi.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 02:59:12 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Jun 2016 06:59:12 +0000 Subject: [issue24291] Many servers (wsgiref, http.server, etc) can truncate large output blobs In-Reply-To: <1432671481.51.0.762064908488.issue24291@psf.upfronthosting.co.za> Message-ID: <20160605065909.15244.54762.91C3418B@psf.io> Roundup Robot added the comment: New changeset a57703119f40 by Martin Panter in branch '3.5': Issue #24291: Avoid WSGIRequestHandler doing partial writes https://hg.python.org/cpython/rev/a57703119f40 New changeset d8f021944e0b by Martin Panter in branch 'default': Issue #24291: Merge wsgi partial write fix from 3.5 https://hg.python.org/cpython/rev/d8f021944e0b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 03:08:56 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Jun 2016 07:08:56 +0000 Subject: [issue27219] turtle.fillcolor doesn't accept a tuple of floats In-Reply-To: <1465057740.31.0.354444599914.issue27219@psf.upfronthosting.co.za> Message-ID: <1465110536.8.0.104898443774.issue27219@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: _color_triple_to_hexstring() is implementation detail. It would be better to test it indirectly using public method (like fillcolor()). Added other comments on Rietveld. ---------- nosy: +serhiy.storchaka stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 03:19:02 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Jun 2016 07:19:02 +0000 Subject: [issue26336] Expose regex bytecode as attribute of compiled pattern object In-Reply-To: <1455163527.75.0.996534901196.issue26336@psf.upfronthosting.co.za> Message-ID: <1465111142.77.0.274628756554.issue26336@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Added comments on Rietveld. I still not think this is a good idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 03:35:28 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sun, 05 Jun 2016 07:35:28 +0000 Subject: [issue26336] Expose regex bytecode as attribute of compiled pattern object In-Reply-To: <1455163527.75.0.996534901196.issue26336@psf.upfronthosting.co.za> Message-ID: <1465112128.87.0.61770811511.issue26336@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Updated patch attached. I don't feel strongly about whether this should be in Python, but it seems potentially useful at least as a tool to learn more about how re is implemented. If I have time I may write a tool using __pattern_code__ and the sre_constants module to provide a disassembly for regexes. ---------- Added file: http://bugs.python.org/file43232/issue26336-cr2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 03:38:18 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Jun 2016 07:38:18 +0000 Subject: [issue21916] Create unit tests for turtle textonly In-Reply-To: <1404479564.66.0.23163619156.issue21916@psf.upfronthosting.co.za> Message-ID: <20160605073815.100840.3348.2E5D244C@psf.io> Roundup Robot added the comment: New changeset 5c1befa401ca by Serhiy Storchaka in branch '3.5': Issue #21916: Added more tests for the turtle module. https://hg.python.org/cpython/rev/5c1befa401ca New changeset 41fa38ea46ba by Serhiy Storchaka in branch '2.7': Issue #21916: Added more tests for the turtle module. https://hg.python.org/cpython/rev/41fa38ea46ba New changeset 356f411e8c5c by Serhiy Storchaka in branch 'default': Issue #21916: Added more tests for the turtle module. https://hg.python.org/cpython/rev/356f411e8c5c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 03:39:19 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Jun 2016 07:39:19 +0000 Subject: [issue21916] Create unit tests for turtle textonly In-Reply-To: <1404479564.66.0.23163619156.issue21916@psf.upfronthosting.co.za> Message-ID: <1465112359.56.0.564828292115.issue21916@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your patches Jelle. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 03:43:38 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Jun 2016 07:43:38 +0000 Subject: [issue27225] Potential refleak in type_new when setting __new__ fails In-Reply-To: <1465103384.56.0.665508256655.issue27225@psf.upfronthosting.co.za> Message-ID: <1465112618.65.0.224193300545.issue27225@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- assignee: -> serhiy.storchaka components: +Interpreter Core nosy: +serhiy.storchaka stage: -> commit review type: -> resource usage versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 03:59:01 2016 From: report at bugs.python.org (Arno-Can Uestuensoez) Date: Sun, 05 Jun 2016 07:59:01 +0000 Subject: [issue26329] os.path.normpath("//") returns // In-Reply-To: <1455116285.45.0.915370101527.issue26329@psf.upfronthosting.co.za> Message-ID: <1465113541.66.0.427830937814.issue26329@psf.upfronthosting.co.za> Arno-Can Uestuensoez added the comment: I propose to add at least a statement like e.g. "In conformance to IEEE Std 1003.1?, 2013 Edition; 4.12 Pathname Resolution". Because I had the same thought of a bug at first view, this because I did not find any hint in e.g. docs for 2.7.11. The reason to handle this thoroughly in my projects is the application of a path-matching library for generic unit tests, e.g. for bash scripts which require intensive PATH resolution. This has to be applied by the users of the library. See "https://pypi.python.org/pypi/pyfilesysobjects", and "https://pypi.python.org/pypi/epyunit" which requires intensive pattern matching of application provided pathnames, e.g. when it comes to automatic split of actual used PYTHONPATH items for a specific function/method, module, or package. E.g. the user provides an 'intentional casual' pathname for drop-in unit tests(see epyunit), "os.sep + context.sys.path[x] + os.sep + 'rel-module-path'", due to mixed relative and absolute paths resulting in leading "os.sep + os.sep". The pattern match than fails, but it is not immediately clear for which reason. ---------- nosy: +acue _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 04:07:13 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Jun 2016 08:07:13 +0000 Subject: [issue27225] Potential refleak in type_new when setting __new__ fails In-Reply-To: <1465103384.56.0.665508256655.issue27225@psf.upfronthosting.co.za> Message-ID: <20160605080709.21244.12665.2341CD8D@psf.io> Roundup Robot added the comment: New changeset 33b53734805b by Serhiy Storchaka in branch '3.5': Issue #27225: Fixed a reference leak in type_new when setting __new__ fails. https://hg.python.org/cpython/rev/33b53734805b New changeset 31ad7885e2e5 by Serhiy Storchaka in branch 'default': Issue #27225: Fixed a reference leak in type_new when setting __new__ fails. https://hg.python.org/cpython/rev/31ad7885e2e5 New changeset db24d51c69d3 by Serhiy Storchaka in branch '2.7': Issue #27225: Fixed a reference leak in type_new when setting __new__ fails. https://hg.python.org/cpython/rev/db24d51c69d3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 04:07:41 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Jun 2016 08:07:41 +0000 Subject: [issue27225] Potential refleak in type_new when setting __new__ fails In-Reply-To: <1465103384.56.0.665508256655.issue27225@psf.upfronthosting.co.za> Message-ID: <1465114061.87.0.443034547734.issue27225@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 04:17:13 2016 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 05 Jun 2016 08:17:13 +0000 Subject: [issue27226] distutils: unable to compile both .opt-1.pyc and .opt2.pyc simultaneously In-Reply-To: <1465106608.99.0.622112847685.issue27226@psf.upfronthosting.co.za> Message-ID: <1465114633.7.0.977465829138.issue27226@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: I would suggest using --optimize=1,2 / -O1,2 for this purpose. Documentation in this part of Lib/distutils/command/build_py.py and Lib/distutils/command/install_lib.py should also be updated: ('optimize=', 'O', "also compile with optimization: -O1 for \"python -O\", " "-O2 for \"python -OO\", and -O0 to disable [default: -O0]"), ---------- nosy: +Arfrever versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 04:57:57 2016 From: report at bugs.python.org (Nofar Schnider) Date: Sun, 05 Jun 2016 08:57:57 +0000 Subject: [issue25548] Show the address in the repr for class objects In-Reply-To: <1446576011.58.0.372024983976.issue25548@psf.upfronthosting.co.za> Message-ID: <1465117077.87.0.132770590687.issue25548@psf.upfronthosting.co.za> Nofar Schnider added the comment: Kushal, you've beat me to it. Great work! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 04:59:16 2016 From: report at bugs.python.org (Evan) Date: Sun, 05 Jun 2016 08:59:16 +0000 Subject: [issue27227] argparse fails to parse [] when using choices and nargs='*' Message-ID: <1465117156.8.0.428303445441.issue27227@psf.upfronthosting.co.za> New submission from Evan: When using nargs='*' with choices, it is impossible to specify 0 args: from argparse import ArgumentParser parser = ArgumentParser() parser.add_argument('foo', choices=['foo'], nargs='*') args = parser.parse_args([]) # <-- fails, error message below assert args.foo == [] # usage: args.py [-h] [{foo} [{foo} ...]] # args.py: error: argument foo: invalid choice: [] (choose from 'foo') The problem appears to be this block of code trying to validate `value` immediately after it sets it to `[]`: # when nargs='*' on a positional, if there were no command-line # args, use the default if it is anything other than None elif (not arg_strings and action.nargs == ZERO_OR_MORE and not action.option_strings): if action.default is not None: value = action.default else: value = arg_strings self._check_value(action, value) The fix seems to be as simple as moving the check under `if action.default is not None`. (NOTE: This would be also adequately solved by patches already attached to http://bugs.python.org/issue9625, however the minimal solution to this problem is simpler.) ---------- components: Library (Lib) messages: 267404 nosy: evan_ priority: normal severity: normal status: open title: argparse fails to parse [] when using choices and nargs='*' type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 05:05:31 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 05 Jun 2016 09:05:31 +0000 Subject: [issue27164] zlib can't decompress DEFLATE using shared dictionary In-Reply-To: <1464687663.75.0.126366287594.issue27164@psf.upfronthosting.co.za> Message-ID: <1465117531.18.0.00410639530033.issue27164@psf.upfronthosting.co.za> Xiang Zhang added the comment: It looks good. I don't think that is a matter since usually I will do a search before change. But of course extracting them to a subroutine helps. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 06:48:19 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 05 Jun 2016 10:48:19 +0000 Subject: [issue24291] Many servers (wsgiref, http.server, etc) can truncate large output blobs In-Reply-To: <1432671481.51.0.762064908488.issue24291@psf.upfronthosting.co.za> Message-ID: <1465123699.15.0.578580236195.issue24291@psf.upfronthosting.co.za> Martin Panter added the comment: Here is an updated patch with the remaining fixes for other servers. I considered changing the behaviour of shutil.copyfileobj() to handle partial writes better. But I decided against it, because: (a) nobody has complained yet, and (b) it could potentially break stuff, e.g. if fsrc.read() returned a strange kind of object. ---------- Added file: http://bugs.python.org/file43233/wfile-partial.v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 07:19:28 2016 From: report at bugs.python.org (Arno-Can Uestuensoez) Date: Sun, 05 Jun 2016 11:19:28 +0000 Subject: [issue27228] just for clearing: os.path.normpath("file://a") returns "file:/a" Message-ID: <1465125568.33.0.580386729971.issue27228@psf.upfronthosting.co.za> New submission from Arno-Can Uestuensoez: I am currently finishing a file system library and use 'os.path.normpath' for canonical input into match-operations. So already found Issue26329 - IEEE-1003.1-Chap 4.2 and written a comment. But I guess this issue should be handled seperately. Now have to deal by myself with the eventual prefix 'file://' for input, and guess it should be supported. I did not found a statement on this case, so issue this for clarification. The 'os.path.normpath' call simply replaces subsequent os.sep, when they are not leading as 1003.1 states. But how should the following examples be handled: file:////a => /a OR //a ??? file://///a => /a OK file:///a => /a OK ---------- assignee: docs at python components: Documentation messages: 267407 nosy: Fred Rolland, Winterflower, acue, docs at python, ebarry, lemburg, serhiy.storchaka priority: normal severity: normal status: open title: just for clearing: os.path.normpath("file://a") returns "file:/a" type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 07:47:30 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Sun, 05 Jun 2016 11:47:30 +0000 Subject: [issue27228] just for clearing: os.path.normpath("file://a") returns "file:/a" In-Reply-To: <1465125568.33.0.580386729971.issue27228@psf.upfronthosting.co.za> Message-ID: <1465127250.65.0.709098986639.issue27228@psf.upfronthosting.co.za> Steven D'Aprano added the comment: "file://a" is a valid relative file path, for a directory called "file:" and a file called "a", so normpath should return "file:/a". ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 07:50:40 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 05 Jun 2016 11:50:40 +0000 Subject: [issue26855] android: add platform.android_ver() In-Reply-To: <1461676711.89.0.563475479331.issue26855@psf.upfronthosting.co.za> Message-ID: <1465127440.29.0.377810839314.issue26855@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The ro.kernel.qemu property is set to 1 on an Android emulator and 0 otherwise. I think it should be added to the list. On some threading tests where the switch interval is set to one microsecond, it is necessary to set the switch interval to a higher value when running on the qemu emulator, see the three issues: issue #26939: android: test_functools hangs on armv7 issue #26940: android: test_importlib hangs on armv7 issue #26941: android: test_threading hangs on armv7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 07:56:32 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 05 Jun 2016 11:56:32 +0000 Subject: [issue26939] android: test_functools hangs on armv7 In-Reply-To: <1462289866.52.0.349587333392.issue26939@psf.upfronthosting.co.za> Message-ID: <1465127792.15.0.0559370695192.issue26939@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The problem can be fixed by changing the switch interval to a higher value when the test is run on an Android emulator. Issue 26855 can provide a way to know when this is the case through the value of the ro.kernel.qemu property. ---------- dependencies: +android: add platform.android_ver() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 08:09:40 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Jun 2016 12:09:40 +0000 Subject: [issue26329] os.path.normpath("//") returns // In-Reply-To: <1455116285.45.0.915370101527.issue26329@psf.upfronthosting.co.za> Message-ID: <1465128580.07.0.112016525568.issue26329@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you provide a patch Arno-Can? According to the comment in the configure script of GNU coreutils, the only POSIX platforms known for coreutils developers that have two distinct roots / and // are Cygwin, z/OS and dead Apollo DomainOS. Yet few exotic platforms are mentioned in the topic at http://comments.gmane.org/gmane.comp.standards.posix.austin.general/11947 . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 08:11:02 2016 From: report at bugs.python.org (Georg Brandl) Date: Sun, 05 Jun 2016 12:11:02 +0000 Subject: [issue27228] just for clearing: os.path.normpath("file://a") returns "file:/a" In-Reply-To: <1465125568.33.0.580386729971.issue27228@psf.upfronthosting.co.za> Message-ID: <1465128662.04.0.132225729501.issue27228@psf.upfronthosting.co.za> Georg Brandl added the comment: `os.path` does not handle URIs of any type, so this behavior is correct as Steven says. ---------- nosy: +georg.brandl resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 08:19:51 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sun, 05 Jun 2016 12:19:51 +0000 Subject: [issue26855] android: add platform.android_ver() In-Reply-To: <1461676711.89.0.563475479331.issue26855@psf.upfronthosting.co.za> Message-ID: <1465129191.77.0.543280088875.issue26855@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: I guess ro.kernel.qemu is not generic enough to be an item in android_ver(). In tests you can simply use _android_getprop() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 08:23:34 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 05 Jun 2016 12:23:34 +0000 Subject: [issue26862] android: SYS_getdents64 does not need to be defined on android API 21 In-Reply-To: <1461678588.46.0.828463582716.issue26862@psf.upfronthosting.co.za> Message-ID: <1465129414.91.0.835915520783.issue26862@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The patch is simpler since android/api-level.h is now included in pyport.h by changeset 09af54099973. ---------- Added file: http://bugs.python.org/file43234/posixmodule_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 08:30:27 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 05 Jun 2016 12:30:27 +0000 Subject: [issue26855] android: add platform.android_ver() In-Reply-To: <1461676711.89.0.563475479331.issue26855@psf.upfronthosting.co.za> Message-ID: <1465129827.83.0.761209299201.issue26855@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Agreed, and it is not part of the versioning scheme either. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 08:36:56 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Jun 2016 12:36:56 +0000 Subject: [issue27164] zlib can't decompress DEFLATE using shared dictionary In-Reply-To: <1464687663.75.0.126366287594.issue27164@psf.upfronthosting.co.za> Message-ID: <20160605123653.100427.25766.2E169DB8@psf.io> Roundup Robot added the comment: New changeset d91b951e676f by Martin Panter in branch '3.5': Issue #27164: Allow decompressing raw Deflate streams with predefined zdict https://hg.python.org/cpython/rev/d91b951e676f New changeset 470954641f3b by Martin Panter in branch 'default': Issue #27164: Merge raw Deflate zdict support from 3.5 https://hg.python.org/cpython/rev/470954641f3b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 09:05:41 2016 From: report at bugs.python.org (Alex Willmer) Date: Sun, 05 Jun 2016 13:05:41 +0000 Subject: [issue27229] In tree cross-build fails copying Include/graminit.h to itself Message-ID: <1465131940.98.0.80292566271.issue27229@psf.upfronthosting.co.za> New submission from Alex Willmer: While trying a cross compile of Python 3.6 I encountered the following alex at martha:~/src/cpython default? hg summary parent: 101753:31ad7885e2e5 Issue #27225: Fixed a reference leak in type_new when setting __new__ fails. branch: default commit: (clean) update: (current) alex at martha:~/src/cpython default? ./configure --build=x86_64-linux --host=arm-linux-gnueabihf --disable-ipv6 ac_cv_file__dev_ptc=no ac_cv_file__dev_ptmx=no checking for hg... found ... creating Makefile alex at martha:~/src/cpython default? make ... arm-linux-gnueabihf-gcc -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/bitset.o Parser/metagrammar.o Parser/firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o Python/dynamic_annotations.o Python/mysnprintf.o Python/pyctype.o Parser/tokenizer_pgen.o Parser/printgrammar.o Parser/parsetok_pgen.o Parser/pgenmain.o -lpthread -ldl -lpthread -lutil -o Parser/pgen if test "yes" != "yes"; then \ Parser/pgen ./Grammar/Grammar Include/graminit.h Python/graminit.c; \ else \ cp ./Include/graminit.h Include/graminit.h; \ fi cp: './Include/graminit.h' and 'Include/graminit.h' are the same file Makefile:806: recipe for target 'Include/graminit.h' failed make: *** [Include/graminit.h] Error 1 The attached patch allows me to get past this error. I'm unsure if it's an appropriate fix or just a workaround. ---------- components: Cross-Build files: graminit-same-file.patch keywords: patch messages: 267417 nosy: Alex.Willmer priority: normal severity: normal status: open title: In tree cross-build fails copying Include/graminit.h to itself type: compile error versions: Python 3.6 Added file: http://bugs.python.org/file43235/graminit-same-file.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 11:03:23 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Jun 2016 15:03: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: <1465139003.89.0.662883687683.issue17611@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch no longer applied cleanly. Mark, can you please update your patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 11:30:34 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Jun 2016 15:30:34 +0000 Subject: [issue26448] dis.findlabels ignores EXTENDED_ARG In-Reply-To: <1456545250.68.0.0525262950792.issue26448@psf.upfronthosting.co.za> Message-ID: <1465140634.34.0.71890428988.issue26448@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This bug was fixed in issue26881 with similar patch. Sorry, I didn't know about this issue. Your patches look good. In any case thank you for your effort. ---------- nosy: +serhiy.storchaka resolution: -> out of date stage: -> resolved status: open -> closed superseder: -> modulefinder should reuse the dis module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 11:57:42 2016 From: report at bugs.python.org (aixtools) Date: Sun, 05 Jun 2016 15:57:42 +0000 Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX) In-Reply-To: <1465050241.59.0.841731746859.issue26439@psf.upfronthosting.co.za> Message-ID: <9c39e9fc-99b8-b195-4d9b-169cfa30b4ab@gmail.com> aixtools added the comment: On 04-Jun-16 16:24, Martin Panter wrote: > Martin Panter added the comment: > > Okay here are some more thoughts about your latest patch: > > ## Automatic RTLD_MEMBER ## > > I was still uneasy about the automatic setting of RTLD_MEMBER. But I looked for how others handle this, and I found Libtool?s LTDL library, and Apache Portable Runtime (APR). Both have a similar (but stricter) automatic addition based on detecting the archive(member) notation: > > http://git.savannah.gnu.org/cgit/libtool.git/commit/libltdl/loaders/dlopen.c?id=8fa719e > https://github.com/apache/apr/commit/c27f8d2 The "stricter" from libtool is an excellent idea - I should done that as well, but I really hate string manipulation :) I hope that the intent at least more clear, and should anyone ever complain about it not opening a file named: libFoo.a(libFOO.so) as a filename - by design, not accepted as a filename. > So I guess I can accept this way, if you think it is better than my other ideas: > > # Always uses RTLD_MEMBER, never loads a plain file outside an archive > name = "libcrypto.a(libcrypto.so.1.0.0)" > > # Other options, that could be returned by find_library() and would not conflict with a plain file name > name = ("libcrypto.a", "libcrypto.so.1.0.0") # (archive, member) > name = ("libcrypto.a(libcrypto.so.1.0.0)", RTLD_MEMBER) # (name, extra-flags) > > libcrypto = CDLL(name) Isn't this more of an API change - name is no longer just a string? > > ## find_library() modes ## > > In your find_library() function, you still have three parts. Can you confirm that each behaviour is intended: I have to catch a plane - will get back on these. Short - if I have a potential bug, then needs to be improved. More later. > > A) If I have a file called "crypto" in the current directory, find_library("crypto") returns "crypto". This does not seem right. On Linux, ?gcc [. . .] -lcrypto? does not look for a file exactly called ?crypto?. > > B) You are still stripping bits off the library name if it contains ?lib? or a dot (.), so find_library("glib-2.0") is almost equivalent to find_library("b-2"). Isn?t this a bug? > > C) find_library("crypto") will return "/usr/lib/crypto" if such a file exists. Just like in A), this does not seem right to me. > > ## Other things ## > > * You don?t need to prefix most names with underscores, unless they could be confused with a public API. If you follow my earlier suggestion of renaming the new file to _aixutil.py (so it is obvious it is not a public module), then you can freely write ?import re, os, sys?, etc. > > * No need to add the internal variable names to the function signatures. Just write find_library(name), and if you need to initialize a variable, do that in the body. > > * I suggest to go over all the regular expressions, and either change them to plain string searching, or make sure special characters and external variables are escaped as necessary. A comment explaining what the RE is trying to do might help too. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 12:07:17 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Jun 2016 16:07:17 +0000 Subject: [issue21130] equivalent functools.partial instances should compare equal In-Reply-To: <1396425472.15.0.80240218298.issue21130@psf.upfronthosting.co.za> Message-ID: <1465142837.07.0.909539655814.issue21130@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I support Jelle's comments and have added other comments. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 12:10:31 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Jun 2016 16:10:31 +0000 Subject: [issue21130] equivalent functools.partial instances should compare equal In-Reply-To: <1396425472.15.0.80240218298.issue21130@psf.upfronthosting.co.za> Message-ID: <1465143031.8.0.888788315232.issue21130@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There is a question: should partial(func) be equal to func? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 12:18:41 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sun, 05 Jun 2016 16:18:41 +0000 Subject: [issue27219] turtle.fillcolor doesn't accept a tuple of floats In-Reply-To: <1465057740.31.0.354444599914.issue27219@psf.upfronthosting.co.za> Message-ID: <1465143521.1.0.74536979858.issue27219@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: New patch ---------- Added file: http://bugs.python.org/file43236/issue27219-cr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 12:22:30 2016 From: report at bugs.python.org (Eryk Sun) Date: Sun, 05 Jun 2016 16:22:30 +0000 Subject: [issue27179] subprocess uses wrong encoding on Windows In-Reply-To: <1464828766.51.0.809606583575.issue27179@psf.upfronthosting.co.za> Message-ID: <1465143750.19.0.107999988911.issue27179@psf.upfronthosting.co.za> Eryk Sun added the comment: > so if we default to UTF-8 it will be even worse than > defaulting to ANSI because there aren't many programs > on Windows which would use UTF-8 I didn't say subprocess should default to UTF-8. What I wish is for Python to default to using UTF-8 for its own pipe and disk file I/O. The old behavior could be selected by setting some hypothetical environment variable, such as PYTHONIOUSELOCALE. If subprocess defaults to the console's current codepage (when available), it would be nice to have a way to conveniently select the OEM or ANSI codepage. The codecs module could define string constants based on GetOEMCP() and GetACP(), such as codecs.CP_OEMCP (e.g. 'cp437') and codecs.CP_ACP (e.g. 'cp1252'). subprocess could import these constants on Windows. > for example "cmd /u /c chcp.exe" will return result > in UTF-16 because such program doesn't exist and cmd's > error message will be outputted. Yes, that's a problem. The cases where we want UTF-16 from the shell should be handled specially instead of enabled generally. > Also if user have set.exe in %System32% then > "cmd /u /c set" won't be in UTF-16 because it will > execute that program. This one's not actually a problem because cmd defaults to parsing `set` as its internal command. An external `set` requires quotes (e.g. `"set"` to look for set, set.com, set.exe, ...). > you want to get GetConsoleOutputCP before program's > exit and not at start (say with CREATE_SUSPENDED) > as it might have changed it somewhere in middle of > program's execution. You'd have to pass both the process ID and the thread ID to have the monitor call OpenProcess to get a waitable handle and OpenThread to call ResumeThread. It can be done, but it's not something I'd consider doing in practice. It's too fragile and not worth the trouble for something that's rarely required. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 12:27:54 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Jun 2016 16:27:54 +0000 Subject: [issue11822] Improve disassembly to show embedded code objects In-Reply-To: <1302467152.39.0.854888976189.issue11822@psf.upfronthosting.co.za> Message-ID: <1465144074.01.0.290246513051.issue11822@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I like St?phane's idea about placing the output for nested code object at the same level after the output for the main code object. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 12:32:02 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Jun 2016 16:32:02 +0000 Subject: [issue17288] cannot jump from a return after setting f_lineno In-Reply-To: <1361726813.15.0.719765769531.issue17288@psf.upfronthosting.co.za> Message-ID: <1465144322.04.0.233390491875.issue17288@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 12:32:03 2016 From: report at bugs.python.org (Andrew Lyasoff) Date: Sun, 05 Jun 2016 16:32:03 +0000 Subject: [issue27230] Calculation involving mpmath gives wrong result with Python 3.6 and correct result with 2.7 Message-ID: <1465144323.23.0.0323886668259.issue27230@psf.upfronthosting.co.za> New submission from Andrew Lyasoff: A particular numerical expression involving mpmath produces the wrong result when evaluated with Python 3.5 and produces the correct result when evaluated with Python 2.7. The expression involves the commonly used erf (error) function. ---------- components: IO files: special_f_test.ipynb messages: 267426 nosy: alyasoff priority: normal severity: normal status: open title: Calculation involving mpmath gives wrong result with Python 3.6 and correct result with 2.7 versions: Python 3.5 Added file: http://bugs.python.org/file43237/special_f_test.ipynb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 12:34:21 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sun, 05 Jun 2016 16:34:21 +0000 Subject: [issue26027] Support Path objects in the posix module In-Reply-To: <1452114329.99.0.617690911804.issue26027@psf.upfronthosting.co.za> Message-ID: <1465144461.33.0.363093881945.issue26027@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: The patch is obsolete because PEP 519 ended up going with a different approach. I submitted a new patch for the path_t converter in issue27186. That patch probably fits better here, so I'm resubmitting it. ---------- nosy: +Jelle Zijlstra Added file: http://bugs.python.org/file43238/issue27186-os_path_t.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 12:35:39 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sun, 05 Jun 2016 16:35:39 +0000 Subject: [issue27231] Support the fspath protocol in the posixpath module Message-ID: <1465144539.6.0.0510380371882.issue27231@psf.upfronthosting.co.za> New submission from Jelle Zijlstra: Various functions in posixpath.py need to accept os.PathLike objects. I will submit a patch. ---------- assignee: Jelle Zijlstra components: Library (Lib) messages: 267428 nosy: Jelle Zijlstra, ethan.furman priority: normal severity: normal status: open title: Support the fspath protocol in the posixpath module versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 12:36:55 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sun, 05 Jun 2016 16:36:55 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1465144615.06.0.605070896039.issue27186@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: I moved my patch for the path_t converter to issue26027, which already covers posixmodule.c. I'm creating issue27231 to track adding os.fspath() support to posixpath.py. With that, I think this issue is done. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 12:48:02 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 05 Jun 2016 16:48:02 +0000 Subject: [issue27230] Calculation involving mpmath gives wrong result with Python 3.6 and correct result with 2.7 In-Reply-To: <1465144323.23.0.0323886668259.issue27230@psf.upfronthosting.co.za> Message-ID: <1465145282.94.0.96068220859.issue27230@psf.upfronthosting.co.za> Ned Deily added the comment: Mpmath is a separate project, not in the Python Standard Library. I suggest you pursue the issue on its issue tracker, providing more information about exactly what results you see with what components (e.g. which OS platform and version, which versions of mpmath, etc). http://mpmath.org ---------- nosy: +ned.deily resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 12:50:51 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 05 Jun 2016 16:50:51 +0000 Subject: [issue27229] In tree cross-build fails copying Include/graminit.h to itself In-Reply-To: <1465131940.98.0.80292566271.issue27229@psf.upfronthosting.co.za> Message-ID: <1465145451.94.0.833878440295.issue27229@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +doko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 12:57:47 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 05 Jun 2016 16:57:47 +0000 Subject: [issue27229] In tree cross-build fails copying Include/graminit.h to itself In-Reply-To: <1465131940.98.0.80292566271.issue27229@psf.upfronthosting.co.za> Message-ID: <1465145867.32.0.602098221674.issue27229@psf.upfronthosting.co.za> Ned Deily added the comment: The culprit appears to be the changes introduced for Issue22359 (c36b9ef8ff39 and friends). ---------- nosy: +martin.panter, ned.deily, xdegaye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 12:58:05 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sun, 05 Jun 2016 16:58:05 +0000 Subject: [issue27232] os.fspath() should not use repr() on error Message-ID: <1465145885.45.0.563591962736.issue27232@psf.upfronthosting.co.za> New submission from Jelle Zijlstra: The current implementation of os.fspath() outputs something like this if you call os.fspath(0): expected str, bytes or os.PathLike object, not This patch changes the output to: expected str, bytes or os.PathLike object, not int ---------- components: Library (Lib) files: fspath-exception.patch keywords: patch messages: 267432 nosy: Jelle Zijlstra, ethan.furman priority: normal severity: normal status: open title: os.fspath() should not use repr() on error versions: Python 3.6 Added file: http://bugs.python.org/file43239/fspath-exception.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 13:00:30 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sun, 05 Jun 2016 17:00:30 +0000 Subject: [issue27233] Missing documentation for PyOS_FSPath Message-ID: <1465146030.9.0.386709465455.issue27233@psf.upfronthosting.co.za> New submission from Jelle Zijlstra: It should be added to the C API documentation. I plan on getting to this today. ---------- assignee: Jelle Zijlstra components: Documentation messages: 267433 nosy: Jelle Zijlstra, ethan.furman priority: normal severity: normal status: open title: Missing documentation for PyOS_FSPath versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 13:03:04 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sun, 05 Jun 2016 17:03:04 +0000 Subject: [issue27232] os.fspath() should not use repr() on error In-Reply-To: <1465145885.45.0.563591962736.issue27232@psf.upfronthosting.co.za> Message-ID: <1465146184.24.0.810921018488.issue27232@psf.upfronthosting.co.za> Changes by Jelle Zijlstra : Added file: http://bugs.python.org/file43240/fspath-exception.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 13:03:14 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sun, 05 Jun 2016 17:03:14 +0000 Subject: [issue27232] os.fspath() should not use repr() on error In-Reply-To: <1465145885.45.0.563591962736.issue27232@psf.upfronthosting.co.za> Message-ID: <1465146194.4.0.458575261654.issue27232@psf.upfronthosting.co.za> Changes by Jelle Zijlstra : Removed file: http://bugs.python.org/file43239/fspath-exception.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 13:06:46 2016 From: report at bugs.python.org (Arno-Can Uestuensoez) Date: Sun, 05 Jun 2016 17:06:46 +0000 Subject: [issue27234] tuple - single value with comma is assigned as type tuple Message-ID: <1465146406.06.0.602143214773.issue27234@psf.upfronthosting.co.za> New submission from Arno-Can Uestuensoez: A single value terminated by a comma is assigned to be a tuple, even when missing parenthesis. a=(1) => a=1 OK/defined as a=(1,) => a=(1,) OK a=1, => a=(1,) ??? Is the latter intended? ------------------ In [4]: a=1, In [5]: print a (1,) In [6]: type(a) Out[6]: tuple ------------------- ---------- components: Interpreter Core messages: 267434 nosy: acue priority: normal severity: normal status: open title: tuple - single value with comma is assigned as type tuple type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 13:08:28 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 05 Jun 2016 17:08:28 +0000 Subject: [issue27226] distutils: unable to compile both .opt-1.pyc and .opt2.pyc simultaneously In-Reply-To: <1465106608.99.0.622112847685.issue27226@psf.upfronthosting.co.za> Message-ID: <1465146508.02.0.123604736855.issue27226@psf.upfronthosting.co.za> Ned Deily added the comment: Since this is an addition to the changes made for PEP 488 (Issue23731), nosying Brett ---------- nosy: +brett.cannon, ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 13:09:08 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sun, 05 Jun 2016 17:09:08 +0000 Subject: [issue27234] tuple - single value with comma is assigned as type tuple In-Reply-To: <1465146406.06.0.602143214773.issue27234@psf.upfronthosting.co.za> Message-ID: <1465146548.82.0.828645171482.issue27234@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Yes, this is intentional. It is documented in https://docs.python.org/3/reference/expressions.html#expression-lists: "The trailing comma is required only to create a single tuple" ---------- nosy: +Jelle Zijlstra _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 13:14:13 2016 From: report at bugs.python.org (shakur shams Mullick) Date: Sun, 05 Jun 2016 17:14:13 +0000 Subject: [issue21130] equivalent functools.partial instances should compare equal In-Reply-To: <1396425472.15.0.80240218298.issue21130@psf.upfronthosting.co.za> Message-ID: <1465146853.27.0.260233517336.issue21130@psf.upfronthosting.co.za> shakur shams Mullick added the comment: Emanuel Barry if you want to take it over, I will stop and will not modify my patch further. Otherwise please let me know. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 13:14:57 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Sun, 05 Jun 2016 17:14:57 +0000 Subject: [issue27234] tuple - single value with comma is assigned as type tuple In-Reply-To: <1465146406.06.0.602143214773.issue27234@psf.upfronthosting.co.za> Message-ID: <1465146897.65.0.836720722802.issue27234@psf.upfronthosting.co.za> Steven D'Aprano added the comment: Yes, it is intended. Commas create tuples, not parentheses. (With the exception of the empty tuple.) The parens are just for grouping and precedence. `1,` is a tuple, regardless of whether you use parens around it or not. ---------- nosy: +steven.daprano resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 13:18:40 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 05 Jun 2016 17:18:40 +0000 Subject: [issue27156] IDLE: remove unused code In-Reply-To: <1464553304.91.0.34770795987.issue27156@psf.upfronthosting.co.za> Message-ID: <1465147120.87.0.588664269483.issue27156@psf.upfronthosting.co.za> Ned Deily added the comment: > Ned, do you have any objection to removing these now, for 3.6? No, go right ahead. Nobody should be using them. And I concur with keeping the others around for the time being. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 13:26:45 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 05 Jun 2016 17:26:45 +0000 Subject: [issue27188] sqlite3 execute* methods return value not documented In-Reply-To: <1464904414.88.0.548243958784.issue27188@psf.upfronthosting.co.za> Message-ID: <1465147605.14.0.234032712619.issue27188@psf.upfronthosting.co.za> Berker Peksag added the comment: Could you also change the function signatures from .. method:: execute(sql, [parameters]) to .. method:: execute(sql[, parameters]) and document that parameters should be list (or sequence or iterable -- I'm a the airport now so I can't check what is the correct term)? I'm not a native speaker but this sentence sounds a bit weird to me: This is a nonstandard shortcut that creates a cursor object by calling the cursor method, calls the cursor's :meth:`execute ` [...] Perhaps it can be changed to This is a nonstandard shortcut that creates a cursor object by calling the cursor's :meth:`execute ` method [...] Also, please change the following usages :meth:`execute ` with :meth:`~Cursor.execute` ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 13:40:46 2016 From: report at bugs.python.org (Emanuel Barry) Date: Sun, 05 Jun 2016 17:40:46 +0000 Subject: [issue21130] equivalent functools.partial instances should compare equal In-Reply-To: <1396425472.15.0.80240218298.issue21130@psf.upfronthosting.co.za> Message-ID: <1465148446.52.0.151005090526.issue21130@psf.upfronthosting.co.za> Emanuel Barry added the comment: Shakur - Feel free to take over and work on it. Serhiy - I don't think that partial(func) == func should be, in the same sense that (0, 1, 2), [0, 1, 2] and range(3) aren't equal even though they fundamentally represent the same thing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 13:41:24 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 05 Jun 2016 17:41:24 +0000 Subject: [issue27224] IDLE: editor versus grep line number differ In-Reply-To: <1465093952.02.0.213444129237.issue27224@psf.upfronthosting.co.za> Message-ID: <1465148484.86.0.621430888182.issue27224@psf.upfronthosting.co.za> Ned Deily added the comment: FWIW, using an IDLE built from the current top-of-trunk default (on OS X), the steps outlined above produce the correct result, 226 and 236, which match up with what other tools report. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 13:44:16 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Jun 2016 17:44:16 +0000 Subject: [issue27111] redundant variables in long_add and long_sub In-Reply-To: <1464122604.65.0.69831533642.issue27111@psf.upfronthosting.co.za> Message-ID: <1465148656.22.0.658259697346.issue27111@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oren, could you please sign a Contributor Licensing Agreement? http://www.python.org/psf/contrib/contrib-form/ http://www.python.org/psf/contrib/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 13:45:53 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sun, 05 Jun 2016 17:45:53 +0000 Subject: [issue27231] Support the fspath protocol in the posixpath module In-Reply-To: <1465144539.6.0.0510380371882.issue27231@psf.upfronthosting.co.za> Message-ID: <1465148753.98.0.969687612042.issue27231@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: This patch adds a number of os.fspath calls to the posixpath.py module. I didn't duplicate all tests to check PathLike objects in addition str/bytes, because that seemed excessive. Instead I tried to ensure that each function has at least one test checking that it accepts PathLike objects. ---------- keywords: +patch Added file: http://bugs.python.org/file43241/issue27231.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 13:53:08 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 05 Jun 2016 17:53:08 +0000 Subject: [issue27168] Yury isn't sure comprehensions and await interact correctly In-Reply-To: <1464718014.77.0.520069298007.issue27168@psf.upfronthosting.co.za> Message-ID: <1465149188.58.0.265905968221.issue27168@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- assignee: -> yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 13:54:07 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 05 Jun 2016 17:54:07 +0000 Subject: [issue27151] multiprocessing.Process leaves read pipes open (Process.sentinel) In-Reply-To: <1464519594.44.0.838880586419.issue27151@psf.upfronthosting.co.za> Message-ID: <1465149247.86.0.590241706816.issue27151@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 14:00:03 2016 From: report at bugs.python.org (Chris Barker) Date: Sun, 05 Jun 2016 18:00:03 +0000 Subject: [issue27198] Adding an assertClose() method to unittest.TestCase In-Reply-To: <1464979712.74.0.398203716413.issue27198@psf.upfronthosting.co.za> Message-ID: <1465149603.91.0.209515806701.issue27198@psf.upfronthosting.co.za> Chris Barker added the comment: Thanks Raymond. Damn! I wrote a nice comprehensive note, and my browser lost it somehow :-(. Here's a shorter version: "FWIW, I find assertClose easy to misinterpret. At first, it looks like an assertion that a file is closed." sure -- we can find a new name -- I only used that because it's called "isclose" in the math module -- but no one's likely to think a math module function is about files... "we don't need another way to do it" Yes, we certainly do -- it was added to the math module (even though a large fraction of use cases would be testing), and something like this is in numpy, Boost, etc, and as the long debate about the PEP indicates -- it's not obvious how to do it -- I'd argue this is more necessary in unitest than most of the other asserts.... (and, sample size 1: a relatively new user offered to proofread the patch for me, and immediately said "hey this is great -- I've been needing this!" Frankly, the objections to adding new aseert methods are really a critique of the unittest API -- it is clearly DESIGNED to have specialized asserts for many common use cases. So I think we should either: Embrace the API and add useful asserts like this one. or Make a concerted effort (Primarily through documentation) to move toward a different API (or a different way to use the current one, anyway). Robert's posts about "matches" are a good start. In the meantime, maybe the way to go with this is to add it to assertAlmostEqual -- it gives folks the functionality, makes it discoverable, and doesn't add a new name. Any objections to that before I take the time to code that up? -Chris ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 14:01:26 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sun, 05 Jun 2016 18:01:26 +0000 Subject: [issue27233] Missing documentation for PyOS_FSPath In-Reply-To: <1465146030.9.0.386709465455.issue27233@psf.upfronthosting.co.za> Message-ID: <1465149686.83.0.773230212423.issue27233@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Patch adds concise documentation ---------- keywords: +patch Added file: http://bugs.python.org/file43242/issue27233.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 14:01:37 2016 From: report at bugs.python.org (Rustemzade Mehemmed) Date: Sun, 05 Jun 2016 18:01:37 +0000 Subject: [issue27235] Heap overflow occurred due to the int overflow Message-ID: <1465149697.95.0.775433257828.issue27235@psf.upfronthosting.co.za> New submission from Rustemzade Mehemmed: I have tested this vulnerability on the Python 2.7 and it absolutely affected :). Integer overflow produce in posix_fdopen function. If an attacker sent fdopen mode value larger than max integer value (2*32) to fdopen after integer overflow occurred. int fd; char *orgmode = "r"; int bufsize = -1; FILE *fp; PyObject *f; char *mode; if (!PyArg_ParseTuple(args, "i|si", &fd, &orgmode, &bufsize)) return NULL; /* Sanitize mode. See fileobject.c */ mode = PyMem_MALLOC(strlen(orgmode)+3); ... strcpy(mode, orgmode); os.fdopen(fd[, mode[, bufsize]]) fo = os.fdopen(fd, "r"*0xffffffff) 0x5e2595 <+86>: mov edi,eax => 0x5e2598 <+89>: call 0x416e50 (gdb) print /x $eax $1 = 0xffffffff after does addition of "add" instruction therefore overflow occured and => 0x5e259d <+94>: add eax,0x3 (gdb) print /x $eax $5 = 0x2 and memory allocate after buffer copy== > 0x5e25a1 <+98>: mov edi,eax 0x5e25a4 <+101>: call 0x48f793 <_PyMem_DebugMalloc> 0x5e25cb <+140>: mov esi,edx ... 0x5e25ce <+143>: mov edi,eax 0x5e25d1 <+146>: call 0x416b80 copy buffer strcpy(mode, orgmode); <=== overflow poc: #!/usr/bin/python import os, sys fd = os.open( "foo.txt", os.O_RDWR|os.O_CREAT ) fo = os.fdopen(fd, "r"*0xffffff) print "Closed the file successfully!!" ---------- messages: 267447 nosy: madness priority: normal severity: normal status: open title: Heap overflow occurred due to the int overflow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 14:02:55 2016 From: report at bugs.python.org (Rustemzade Mehemmed) Date: Sun, 05 Jun 2016 18:02:55 +0000 Subject: [issue27235] Heap overflow occurred due to the int overflow (Python-2.7.11/Modules/posixmodule.c) In-Reply-To: <1465149697.95.0.775433257828.issue27235@psf.upfronthosting.co.za> Message-ID: <1465149775.61.0.50293166786.issue27235@psf.upfronthosting.co.za> Changes by Rustemzade Mehemmed : ---------- title: Heap overflow occurred due to the int overflow -> Heap overflow occurred due to the int overflow (Python-2.7.11/Modules/posixmodule.c) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 14:05:55 2016 From: report at bugs.python.org (Oren Milman) Date: Sun, 05 Jun 2016 18:05:55 +0000 Subject: [issue27111] redundant variables in long_add and long_sub In-Reply-To: <1464122604.65.0.69831533642.issue27111@psf.upfronthosting.co.za> Message-ID: <1465149955.59.0.466305395531.issue27111@psf.upfronthosting.co.za> Oren Milman added the comment: done. By the way, I am logging in to bugs.python.org through accounts.google.com, but I couldn't see any way to do the same in www.python.org, so I have a native account there (with the same email address). I hope that won't be an issue... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 14:09:32 2016 From: report at bugs.python.org (Rustemzade Mehemmed) Date: Sun, 05 Jun 2016 18:09:32 +0000 Subject: [issue27235] Heap overflow occurred due to the int overflow (Python-2.7.11/Modules/posixmodule.c) In-Reply-To: <1465149697.95.0.775433257828.issue27235@psf.upfronthosting.co.za> Message-ID: <1465150172.83.0.876053162544.issue27235@psf.upfronthosting.co.za> Changes by Rustemzade Mehemmed : ---------- type: -> security _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 14:24:53 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 05 Jun 2016 18:24:53 +0000 Subject: [issue17500] move PC/icons/source.xar to http://www.python.org/community/logos/ In-Reply-To: <1363820002.7.0.633809398541.issue17500@psf.upfronthosting.co.za> Message-ID: <1465151093.56.0.346565617414.issue17500@psf.upfronthosting.co.za> Ned Deily added the comment: LGTM ---------- versions: +Python 3.5, Python 3.6 -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 14:26:58 2016 From: report at bugs.python.org (Brett Cannon) Date: Sun, 05 Jun 2016 18:26:58 +0000 Subject: [issue27226] distutils: unable to compile both .opt-1.pyc and .opt2.pyc simultaneously In-Reply-To: <1465106608.99.0.622112847685.issue27226@psf.upfronthosting.co.za> Message-ID: <1465151218.03.0.0455001215301.issue27226@psf.upfronthosting.co.za> Brett Cannon added the comment: So the reason Python does the right thing at install is because compileall is used by the Makefile to do the compilation and it's run twice (it actually doesn't use distutils for this). My question is what did distutils do before PEP 488 since .pyc and .pyo files had different names before as well? Did distutils build both previously and so this is a regression? Or is this a feature request? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 14:33:05 2016 From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=) Date: Sun, 05 Jun 2016 18:33:05 +0000 Subject: [issue27226] distutils: unable to compile both .opt-1.pyc and .opt2.pyc simultaneously In-Reply-To: <1465106608.99.0.622112847685.issue27226@psf.upfronthosting.co.za> Message-ID: <1465151585.94.0.15604142493.issue27226@psf.upfronthosting.co.za> Micha? G?rny added the comment: Brett, .pyc was controlled by --compile and .pyo by --optimize (either 1 or 2). Technically only two variants could be used simultaneously, and distutils accounted for that. Now you have .pyc + .opt-1.pyc + .opt-2.pyc, so three variants instead of two. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 14:34:12 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sun, 05 Jun 2016 18:34:12 +0000 Subject: [issue27221] [multiprocessing] Doc is outdated regarding method picklability In-Reply-To: <1465069362.83.0.142351405451.issue27221@psf.upfronthosting.co.za> Message-ID: <1465151652.99.0.397655525494.issue27221@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Patch attached. I also checked that this case is tested, and it looks like the Bunch object in Lib/test/_test_multiprocessing.py uses a method as its target. ---------- keywords: +patch nosy: +Jelle Zijlstra Added file: http://bugs.python.org/file43243/issue27233.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 14:34:39 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 05 Jun 2016 18:34:39 +0000 Subject: [issue26971] python v3.5.1: sys.paths not respecting DESTDIRS and DESTSHARED In-Reply-To: <1462628482.0.0.926875224828.issue26971@psf.upfronthosting.co.za> Message-ID: <1465151679.32.0.795097929816.issue26971@psf.upfronthosting.co.za> Ned Deily added the comment: Sorry, it is no longer clear to me exactly what problem(s) and solution are being proposed here. When dealing with installation problems like this, we have to be *very* precise: here's what I started with on what platform, here are the contents of the relevant directories and/or files before I start, here are exactly the steps I took, here are the results I expected, and here are the results I observed. Using a downloaded tarball and the steps in @yaro-yaro's initial message, I see no change in /usr/lib64; note, there *may* have been Python .so files installed there by system packages but that should be irrelevant to building and installing your own Python. I also could not reproduce @jojo's recipe as best I understand it and don't see how it could produce any change in /usr/lib64. Changing the value of --libdir is a whole different matter and not relevant to the original problem. Also the title of the issue refers to DESTDIR and DESTSHARED but nowhere in the body of the issue are these variables directly referenced, so I have to assume they aren't being explicitly set. Unless someone can better demonstrate an actual problem here, I'm going to close this issue. ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 14:35:46 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sun, 05 Jun 2016 18:35:46 +0000 Subject: [issue19234] socket.fileno() documentation In-Reply-To: <52597A2F.60807@python.org> Message-ID: <1465151746.68.0.619646703157.issue19234@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: This looks fixed. ---------- nosy: +Jelle Zijlstra resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 14:38:19 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sun, 05 Jun 2016 18:38:19 +0000 Subject: [issue27221] [multiprocessing] Doc is outdated regarding method picklability In-Reply-To: <1465069362.83.0.142351405451.issue27221@psf.upfronthosting.co.za> Message-ID: <1465151899.98.0.470835633562.issue27221@psf.upfronthosting.co.za> Changes by Jelle Zijlstra : Removed file: http://bugs.python.org/file43243/issue27233.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 14:38:40 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sun, 05 Jun 2016 18:38:40 +0000 Subject: [issue27221] [multiprocessing] Doc is outdated regarding method picklability In-Reply-To: <1465069362.83.0.142351405451.issue27221@psf.upfronthosting.co.za> Message-ID: <1465151920.39.0.690008283319.issue27221@psf.upfronthosting.co.za> Changes by Jelle Zijlstra : Added file: http://bugs.python.org/file43244/issue27221.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 14:43:07 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 05 Jun 2016 18:43:07 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465152187.66.0.959151061709.issue26839@psf.upfronthosting.co.za> Ned Deily added the comment: Since 3.5.2 is almost upon us, I'm setting this to "release blocker" status so we can make a decision about whether this should be changed for 3.5.2 or not. @haypo, do you have an opinion about the patch? ---------- nosy: +ned.deily priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 14:43:43 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 05 Jun 2016 18:43:43 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465152223.76.0.637031211971.issue26839@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 14:44:14 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 05 Jun 2016 18:44:14 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465152254.34.0.816335821837.issue26839@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 14:45:09 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sun, 05 Jun 2016 18:45:09 +0000 Subject: [issue27215] Docstrings of Sequence and MutableSequence seems not right In-Reply-To: <1465032017.04.0.0861396062626.issue27215@psf.upfronthosting.co.za> Message-ID: <1465152309.73.0.0854071801086.issue27215@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: The docstrings (at least in 3.6) say subclasses must override __new__ *or* __init__. However, I think this is wrong too. The following is a correct (if not very useful) implementation of Sequence: >>> import collections.abc >>> class MySequence(collections.abc.Sequence): ... def __getitem__(self, key): ... raise IndexError(key) ... def __len__(self): ... return 0 ... Other abc docstrings also don't claim that __init__ or __new__ must be implemented. The attached patch fixes the docstrings. ---------- keywords: +patch nosy: +Jelle Zijlstra Added file: http://bugs.python.org/file43245/issue27215.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 14:45:40 2016 From: report at bugs.python.org (Brett Cannon) Date: Sun, 05 Jun 2016 18:45:40 +0000 Subject: [issue27182] PEP 519 support in the stdlib In-Reply-To: <1464887789.1.0.970652730446.issue27182@psf.upfronthosting.co.za> Message-ID: <1465152340.0.0.656435193138.issue27182@psf.upfronthosting.co.za> Brett Cannon added the comment: Functions that only accept file descriptors should not be updated to work with __fspath__() as it will never return an int/fd. As for Ethan's suggestion, are you saying you want to toss the str/bytes check from os.fspath()? If so then you will need to go to python-dev and bring that up as the PEP clearly specifies that str/bytes is checked for and specifically in the order of the Python code. The thinking behind the current design is that since __fspath__() has to be explicitly implemented that people will do so properly, versus accidentally passing in some type that isn't str/bytes like the pre-PEP 519 world (i.e. trust the __fspath__() implementors to do the right thing and only protect against someone passing in something wrong from complicated code flow). There has been discussion about using the ``path.__fspath__() if hasattr(path, '__fspath__') else path`` idiom in os.path so that the pre-existing type-checks can do their thing instead of checking twice, although that's different from how os.fspath() works (then again, since this is all new code we could argue that going our own route in os.path is acceptable in the name of performance). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 14:54:10 2016 From: report at bugs.python.org (Brett Cannon) Date: Sun, 05 Jun 2016 18:54:10 +0000 Subject: [issue27226] distutils: unable to compile both .opt-1.pyc and .opt2.pyc simultaneously In-Reply-To: <1465106608.99.0.622112847685.issue27226@psf.upfronthosting.co.za> Message-ID: <1465152850.66.0.209087286261.issue27226@psf.upfronthosting.co.za> Brett Cannon added the comment: But distutils still does the right thing with -O2 and --optimize 2, right? If that's the case then this is an enhancement request to add support to distutils to compile all bytecode levels and not a regression. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 15:00:54 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sun, 05 Jun 2016 19:00:54 +0000 Subject: [issue15243] Misleading documentation for __prepare__ In-Reply-To: <1341328118.33.0.670602196671.issue15243@psf.upfronthosting.co.za> Message-ID: <1465153254.87.0.957747195902.issue15243@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: I think the current documentation is correct and doesn't need changes. There is also already an example of a working __prepare__ method. ---------- nosy: +Jelle Zijlstra _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 15:02:43 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sun, 05 Jun 2016 19:02:43 +0000 Subject: [issue19489] move quick search box above TOC In-Reply-To: <1383546510.68.0.587653327623.issue19489@psf.upfronthosting.co.za> Message-ID: <1465153363.04.0.634013653729.issue19489@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Yes, I don't think we control this, the layout is generated by sphinx. ---------- nosy: +Jelle Zijlstra _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 15:07:59 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Jun 2016 19:07:59 +0000 Subject: [issue25941] Add 'How to Review a Patch' section to devguide In-Reply-To: <1450992057.28.0.358724589512.issue25941@psf.upfronthosting.co.za> Message-ID: <20160605190755.64315.4590.8BCE41CE@psf.io> Roundup Robot added the comment: New changeset 8b3f4473432e by Ned Deily in branch 'default': Issue #25941: Add "How To Review A Patch" section to the devguide. https://hg.python.org/devguide/rev/8b3f4473432e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 15:11:16 2016 From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=) Date: Sun, 05 Jun 2016 19:11:16 +0000 Subject: [issue27226] distutils: unable to compile both .opt-1.pyc and .opt2.pyc simultaneously In-Reply-To: <1465106608.99.0.622112847685.issue27226@psf.upfronthosting.co.za> Message-ID: <1465153876.14.0.775574314178.issue27226@psf.upfronthosting.co.za> Micha? G?rny added the comment: Yes, you could put it like this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 15:12:30 2016 From: report at bugs.python.org (Brett Cannon) Date: Sun, 05 Jun 2016 19:12:30 +0000 Subject: [issue27226] distutils: unable to compile both .opt-1.pyc and .opt2.pyc simultaneously In-Reply-To: <1465106608.99.0.622112847685.issue27226@psf.upfronthosting.co.za> Message-ID: <1465153950.26.0.165895756555.issue27226@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 15:12:36 2016 From: report at bugs.python.org (Brett Cannon) Date: Sun, 05 Jun 2016 19:12:36 +0000 Subject: [issue27226] distutils: unable to compile both .opt-1.pyc and .opt2.pyc simultaneously In-Reply-To: <1465106608.99.0.622112847685.issue27226@psf.upfronthosting.co.za> Message-ID: <1465153956.78.0.688560113853.issue27226@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 15:12:59 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 05 Jun 2016 19:12:59 +0000 Subject: [issue25941] Add 'How to Review a Patch' section to devguide In-Reply-To: <1450992057.28.0.358724589512.issue25941@psf.upfronthosting.co.za> Message-ID: <1465153979.15.0.12870780064.issue25941@psf.upfronthosting.co.za> Ned Deily added the comment: The revised patch looks good to me (other than some trailing whitespace). Camilla, thanks for your contribution. If you haven't already, please sign a contributor form to cover this and future contributions as noted elsewhere in the Developer's Guide: https://docs.python.org/devguide/coredev.html#sign-a-contributor-agreement ---------- nosy: +ned.deily resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 15:14:44 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sun, 05 Jun 2016 19:14:44 +0000 Subject: [issue26582] asyncio documentation links to wrong CancelledError In-Reply-To: <1458225953.38.0.399231880747.issue26582@psf.upfronthosting.co.za> Message-ID: <1465154084.97.0.271712572389.issue26582@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: This patch documents CancelledError in the asyncio documentation. ---------- keywords: +patch nosy: +Jelle Zijlstra Added file: http://bugs.python.org/file43246/issue26582.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 15:43:17 2016 From: report at bugs.python.org (Dusty Phillips) Date: Sun, 05 Jun 2016 19:43:17 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1465155797.4.0.953399909722.issue27186@psf.upfronthosting.co.za> Dusty Phillips added the comment: Ethan: Can you clarify what you mean by "testing the other classes"? PureWindowsPath and PurePosixPath are tested by extension of _BasePurePathTest. So I think you mean that _BasePathTest also needs testing, but I don't see anything in there that would mirror the constructor testing that is happening in PurePath. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 15:43:25 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Jun 2016 19:43:25 +0000 Subject: [issue27236] Add CHAINED_COMPARE_OP opcode Message-ID: <1465155805.46.0.0768541508675.issue27236@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: For now complex code is generated for chained comparing. $ echo "x = a < b > c < d" | ./python -m dis 1 0 LOAD_NAME 0 (a) 2 LOAD_NAME 1 (b) 4 DUP_TOP 6 ROT_THREE 8 COMPARE_OP 0 (<) 10 JUMP_IF_FALSE_OR_POP 28 12 LOAD_NAME 2 (c) 14 DUP_TOP 16 ROT_THREE 18 COMPARE_OP 4 (>) 20 JUMP_IF_FALSE_OR_POP 28 22 LOAD_NAME 3 (d) 24 COMPARE_OP 0 (<) 26 JUMP_FORWARD 4 (to 32) >> 28 ROT_TWO 30 POP_TOP >> 32 STORE_NAME 4 (x) 34 LOAD_CONST 0 (None) 36 RETURN_VALUE Proposed patch adds CHAINED_COMPARE_OP opcode that does all necessary stack manipulatios. Using it the generated code is simpler: $ echo "x = a < b > c < d" | ./python -m dis 1 0 LOAD_NAME 0 (a) 2 LOAD_NAME 1 (b) 4 CHAINED_COMPARE_OP 0 (<) 6 JUMP_IF_FALSE_OR_POP 18 8 LOAD_NAME 2 (c) 10 CHAINED_COMPARE_OP 4 (>) 12 JUMP_IF_FALSE_OR_POP 18 14 LOAD_NAME 3 (d) 16 COMPARE_OP 0 (<) >> 18 STORE_NAME 4 (x) 20 LOAD_CONST 0 (None) 22 RETURN_VALUE ---------- components: Interpreter Core files: chained_compare_op.patch keywords: patch messages: 267466 nosy: Demur Rumed, Mark.Shannon, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Add CHAINED_COMPARE_OP opcode type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43247/chained_compare_op.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 15:51:12 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 05 Jun 2016 19:51:12 +0000 Subject: [issue26336] Expose regex bytecode as attribute of compiled pattern object In-Reply-To: <1455163527.75.0.996534901196.issue26336@psf.upfronthosting.co.za> Message-ID: <1465156272.13.0.0765788946241.issue26336@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I prefer 'rexcode' for the attribute name. I share Serhiy's reservations. When people write code that depends on CPython implementation details, even though documented as such, the existence of such code becomes a drag on change, especially when details have been stable for awhile. I just saw this used as an argument against one of the proposed bytecode/wordcode changes. "It would break current 3rd party code." It also came up a few years ago with randomizing hashes (and dict iteration order). Jelle, can one access the 'rexcode' via ctypes? Is so, I think an re disassembler with docs would be a good pypi module. Maybe you could also make it work with Barnett's regex module. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 15:53:25 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Jun 2016 19:53:25 +0000 Subject: [issue27127] Never have GET_ITER not followed by FOR_ITER In-Reply-To: <1464227064.89.0.81963094053.issue27127@psf.upfronthosting.co.za> Message-ID: <1465156405.51.0.155709464457.issue27127@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It looks to me this idea is dead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 15:56:08 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 05 Jun 2016 19:56:08 +0000 Subject: [issue27052] Python2.7.11+ as in Debian testing and Ubuntu 16.04 LTS crashes with segfault In-Reply-To: <1463553501.27.0.152340887562.issue27052@psf.upfronthosting.co.za> Message-ID: <1465156568.87.0.0683720091254.issue27052@psf.upfronthosting.co.za> Ned Deily added the comment: FWIW, I am also unable to reproduce the crash on OS X with a current top-of-2.7 debug build. Since it doesn't seem to be able to be reproduced with stock Python 2.7's, perhaps it is time to close the issue here? ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 15:58:01 2016 From: report at bugs.python.org (Joshua Jay Herman) Date: Sun, 05 Jun 2016 19:58:01 +0000 Subject: [issue24459] Mention PYTHONFAULTHANDLER in the man page In-Reply-To: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za> Message-ID: <1465156681.03.0.237531719491.issue24459@psf.upfronthosting.co.za> Joshua Jay Herman added the comment: I have reviewed the comments on Rietveld and made the changes to the patch. Attached is the revised version. ---------- Added file: http://bugs.python.org/file43248/addMissingEnvironmentVariables-review-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 16:25:56 2016 From: report at bugs.python.org (Arno-Can Uestuensoez) Date: Sun, 05 Jun 2016 20:25:56 +0000 Subject: [issue26329] os.path.normpath("//") returns // In-Reply-To: <1455116285.45.0.915370101527.issue26329@psf.upfronthosting.co.za> Message-ID: <1465158356.6.0.00840876786846.issue26329@psf.upfronthosting.co.za> Arno-Can Uestuensoez added the comment: Hi Serhiy, I am currently still investigating it for my own project. https://stackoverflow.com/questions/37646103/posix-path-1003-1-examples-and-behaviour-for-foo-bar Currently I do not have the build environment, so I can provide the text, but because I am a bit under pressure with finishing a larger pack of OpenSource projects currently I cannot manage to setup the environment. So can do this eventually in 2-3Weeks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 16:31:39 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 05 Jun 2016 20:31:39 +0000 Subject: [issue26867] test_ssl test_options fails on ubuntu 16.04 In-Reply-To: <1461728238.71.0.110276038105.issue26867@psf.upfronthosting.co.za> Message-ID: <1465158699.44.0.105427975959.issue26867@psf.upfronthosting.co.za> Ned Deily added the comment: Can we close this as an Ubuntu-specific problem? ---------- nosy: +doko, ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 16:40:10 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 05 Jun 2016 20:40:10 +0000 Subject: [issue27224] IDLE: editor versus grep line number differ In-Reply-To: <1465093952.02.0.213444129237.issue27224@psf.upfronthosting.co.za> Message-ID: <1465159210.83.0.975836671534.issue27224@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Yesterday, I grepped three times and got the same wrong result each time, so I know I was not crazy. But today, starting fresh with no IDLE or TortoiseHg running, all is well. Closing as 'heisenbug' ;-). Lesson: start fresh before reporting weird behavior. (I should have known. I occasionally have to reboot windows to reset its key mappings.) Thanks, and sorry for the noise. ---------- resolution: -> not a bug stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 16:42:53 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 05 Jun 2016 20:42:53 +0000 Subject: [issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions In-Reply-To: <1280333027.17.0.112361474517.issue9400@psf.upfronthosting.co.za> Message-ID: <1465159373.36.0.566995765409.issue9400@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +davin versions: +Python 3.5, Python 3.6 -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 16:55:29 2016 From: report at bugs.python.org (Matthias Klose) Date: Sun, 05 Jun 2016 20:55:29 +0000 Subject: [issue27052] Python2.7.11+ as in Debian testing and Ubuntu 16.04 LTS crashes with segfault In-Reply-To: <1463553501.27.0.152340887562.issue27052@psf.upfronthosting.co.za> Message-ID: <1465160129.86.0.126445732164.issue27052@psf.upfronthosting.co.za> Matthias Klose added the comment: I'm unable to reproduce this with the 2.7 branch 20160603. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 16:56:18 2016 From: report at bugs.python.org (Matthias Klose) Date: Sun, 05 Jun 2016 20:56:18 +0000 Subject: [issue27052] Python2.7.11+ as in Debian testing and Ubuntu 16.04 LTS crashes with segfault In-Reply-To: <1463553501.27.0.152340887562.issue27052@psf.upfronthosting.co.za> Message-ID: <1465160178.59.0.795949066544.issue27052@psf.upfronthosting.co.za> Changes by Matthias Klose : ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 16:56:52 2016 From: report at bugs.python.org (Matthias Klose) Date: Sun, 05 Jun 2016 20:56:52 +0000 Subject: [issue27052] Python2.7.11+ as in Debian testing and Ubuntu 16.04 LTS crashes with segfault In-Reply-To: <1463553501.27.0.152340887562.issue27052@psf.upfronthosting.co.za> Message-ID: <1465160212.13.0.130865680257.issue27052@psf.upfronthosting.co.za> Matthias Klose added the comment: (checked with the recent packages in Debian unstable and Ubuntu yakkety) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 16:58:43 2016 From: report at bugs.python.org (Demur Rumed) Date: Sun, 05 Jun 2016 20:58:43 +0000 Subject: [issue27127] Never have GET_ITER not followed by FOR_ITER In-Reply-To: <1464227064.89.0.81963094053.issue27127@psf.upfronthosting.co.za> Message-ID: <1465160323.12.0.802417528846.issue27127@psf.upfronthosting.co.za> Demur Rumed added the comment: I've gotten most tests to past by having FOR_ITER be traced as if the instruction index is that of the corresponding FOR_BEGIN. test_sys_settrace still fails on test_15_loops because an empty loop body doesn't have the 'pass' line traced (ie when FOR_ITER starts the line) which I'm currently pondering ways around The first patch, which only moved GET_ITER into the closure, would still be good for list/set/dict comprehensions (to help PREDICT & JITs) If there's essentially a decision that all loops should have JUMP_ABSOLUTE to their beginning for the sake of tracing simplicity, then FOR_BEGIN/FOR_ITER are dead ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 17:15:47 2016 From: report at bugs.python.org (Eric Fahlgren) Date: Sun, 05 Jun 2016 21:15:47 +0000 Subject: [issue26448] dis.findlabels ignores EXTENDED_ARG In-Reply-To: <1465140634.34.0.71890428988.issue26448@psf.upfronthosting.co.za> Message-ID: Eric Fahlgren added the comment: Thanks, Serhiy. I sort of figured that it would get fixed with the wordcode rework, and was going to verify that it was when 3.6 settled down. On Sun, Jun 5, 2016 at 8:30 AM, Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > This bug was fixed in issue26881 with similar patch. Sorry, I didn't know > about this issue. Your patches look good. In any case thank you for your > effort. > > ---------- > nosy: +serhiy.storchaka > resolution: -> out of date > stage: -> resolved > status: open -> closed > superseder: -> modulefinder should reuse the dis module > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 17:44:23 2016 From: report at bugs.python.org (Jack McCracken) Date: Sun, 05 Jun 2016 21:44:23 +0000 Subject: [issue26329] os.path.normpath("//") returns // In-Reply-To: <1455116285.45.0.915370101527.issue26329@psf.upfronthosting.co.za> Message-ID: <1465163063.29.0.948690353215.issue26329@psf.upfronthosting.co.za> Jack McCracken added the comment: Hey all - I would love to write a patch :) Working on it! ---------- nosy: +Jack.McCracken _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 17:51:27 2016 From: report at bugs.python.org (Yusuke Tsutsumi) Date: Sun, 05 Jun 2016 21:51:27 +0000 Subject: [issue26467] Add async magic method support to unittest.mock.Mock In-Reply-To: <1456872706.59.0.97059255221.issue26467@psf.upfronthosting.co.za> Message-ID: <1465163487.53.0.546088978024.issue26467@psf.upfronthosting.co.za> Yusuke Tsutsumi added the comment: Taking a look at the code, this may require a bit more discussion. Mock's classes create copies of themselves when an attribute is accessed. As such, I can't just add __aexit__ and have it generate a different mock type entirely, unless I know exactly what an async variant of this mock is. If there was a way to specifically provide a function for asynchronous situations, like __acall__, that would make this a lot easier as well. Anyway, my proposal now is: create new classes MockAsync and MagicMockAsync, and have MockAsync and MagicMockAsync implement the __aexit__ and __aenter__ methods. How is that as an approach? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 18:05:37 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 05 Jun 2016 22:05:37 +0000 Subject: [issue27229] In tree cross-build fails copying Include/graminit.h to itself In-Reply-To: <1465131940.98.0.80292566271.issue27229@psf.upfronthosting.co.za> Message-ID: <1465164337.58.0.061434736623.issue27229@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Yes, those changes incorrectly assume that the source directory and the build directory are always different (using VPATH). Alex patch LGTM, this other patch overwrites the graminit.[ch] files, not sure if this is better. ---------- Added file: http://bugs.python.org/file43249/vpath.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 18:23:42 2016 From: report at bugs.python.org (Jack McCracken) Date: Sun, 05 Jun 2016 22:23:42 +0000 Subject: [issue26329] os.path.normpath("//") returns // In-Reply-To: <1455116285.45.0.915370101527.issue26329@psf.upfronthosting.co.za> Message-ID: <1465165422.09.0.471990600007.issue26329@psf.upfronthosting.co.za> Jack McCracken added the comment: Here's the patch I made. ---------- keywords: +patch Added file: http://bugs.python.org/file43250/add-many-slash-path-note.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 18:41:47 2016 From: report at bugs.python.org (Jack McCracken) Date: Sun, 05 Jun 2016 22:41:47 +0000 Subject: [issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more In-Reply-To: <1464270042.87.0.0233765451432.issue27130@psf.upfronthosting.co.za> Message-ID: <1465166507.05.0.349966463082.issue27130@psf.upfronthosting.co.za> Jack McCracken added the comment: Don't know how useful this will be, but here's a crash report from Mac OS X 10.11 with Klamann's example (Python 3.5). ---------- nosy: +Jack.McCracken Added file: http://bugs.python.org/file43251/coredump_macosx10.11.5.crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 19:40:48 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sun, 05 Jun 2016 23:40:48 +0000 Subject: [issue26336] Expose regex bytecode as attribute of compiled pattern object In-Reply-To: <1455163527.75.0.996534901196.issue26336@psf.upfronthosting.co.za> Message-ID: <1465170048.51.0.737223507536.issue26336@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Yes, you can get at it with ctypes. I released a small (and virtually untested) library at https://github.com/JelleZijlstra/regdis that provides dis-like capabilities. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 19:50:59 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 05 Jun 2016 23:50:59 +0000 Subject: [issue27236] Add CHAINED_COMPARE_OP opcode In-Reply-To: <1465155805.46.0.0768541508675.issue27236@psf.upfronthosting.co.za> Message-ID: <1465170659.84.0.0505661021937.issue27236@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Please stop adding new opcodes for rare use cases. That represents a sharp departure from our entire history of adding opcodes. Code like "x = a < b > c < d" almost never comes up. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 20:02:38 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 06 Jun 2016 00:02:38 +0000 Subject: [issue26867] test_ssl test_options fails on ubuntu 16.04 In-Reply-To: <1461728238.71.0.110276038105.issue26867@psf.upfronthosting.co.za> Message-ID: <1465171358.41.0.00954238033241.issue26867@psf.upfronthosting.co.za> Martin Panter added the comment: This test is already decorated with @skip_if_broken_ubuntu_ssl. I?m not sure Python should go too far out of its way to handle downstream patches, but it seems there is a precedent here. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 20:05:17 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 06 Jun 2016 00:05:17 +0000 Subject: [issue23401] Add pickle support of Mapping views In-Reply-To: <1423216735.87.0.773240969368.issue23401@psf.upfronthosting.co.za> Message-ID: <1465171517.73.0.381737941068.issue23401@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > Raymond, what is your opinion? Whether and how to pickle should be at the discretion of a concrete class rather than a requirement for being a mapping. For example, it may not make any sense for a persistent dictionary such as a FileDict or an SQLDict. Also, my mental model of a mapping view is something that is transparent, a window to the world rather than the world itself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 20:06:03 2016 From: report at bugs.python.org (Rahul) Date: Mon, 06 Jun 2016 00:06:03 +0000 Subject: [issue27237] Kafka Python Consumer Messages gets truncated Message-ID: <1465171563.42.0.101406692034.issue27237@psf.upfronthosting.co.za> New submission from Rahul: Snippet code is below: from kafka import KafkaConsumer from kafka.client import KafkaClient from kafka.consumer import SimpleConsumer consumer = KafkaConsumer('eventdetails_ingestion' , group_id='1',bootstrap_servers=?xxxx:9092', max_partition_fetch_bytes=10555555) for msg in consumer: try: jValue = json.loads(str(msg.value)) except ValueError: fileErr.write(str(msg.value)+"\n") Steps: We send/produce large sets of messages to Kafka of around 20 to 30 KB size each messages in JSON format and producing around 200 messages / sec for 1 hour duration. We have 3 Kafka Brokers running and I am trying to consume the messages from these 3 Kafka Brokers from the same topic using the above code. The problem is that sometimes some of the messages gets truncated, I am not sure why it happen ? ---------- components: Library (Lib) messages: 267487 nosy: rgowda at threatmetrix.com priority: normal severity: normal status: open title: Kafka Python Consumer Messages gets truncated type: performance versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 20:07:16 2016 From: report at bugs.python.org (Ned Deily) Date: Mon, 06 Jun 2016 00:07:16 +0000 Subject: [issue26867] test_ssl test_options fails on ubuntu 16.04 In-Reply-To: <1461728238.71.0.110276038105.issue26867@psf.upfronthosting.co.za> Message-ID: <1465171636.3.0.382341362636.issue26867@psf.upfronthosting.co.za> Ned Deily added the comment: I just spoke with @doko about this here at PyCon. I think we came to the conclusion it might be time to consider removing the old @skip_if_broken_ubuntu_ssl decorator and focus on making the tests work with the most recent releases since pretty much every distributor and current Python releases have moved to disabling the old compromised ssl/tls versions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 20:10:02 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 06 Jun 2016 00:10:02 +0000 Subject: [issue27215] Docstrings of Sequence and MutableSequence seems not right In-Reply-To: <1465032017.04.0.0861396062626.issue27215@psf.upfronthosting.co.za> Message-ID: <1465171802.71.0.105964255303.issue27215@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I think you're reading too much into the docs. Most useful classes provide a __new__ or __init__ to put data into instances. The docs are simply saying that that responsibility lies with the implementer rather than with the ABC. IMO, the docs are more useful as-is. Were we to accept the patch, it wouldn't be long before another user reported a bug saying that the implemented the other methods but the class didn't do anything useful. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 20:12:30 2016 From: report at bugs.python.org (Ned Deily) Date: Mon, 06 Jun 2016 00:12:30 +0000 Subject: [issue27237] Kafka Python Consumer Messages gets truncated In-Reply-To: <1465171563.42.0.101406692034.issue27237@psf.upfronthosting.co.za> Message-ID: <1465171950.58.0.971709481512.issue27237@psf.upfronthosting.co.za> Ned Deily added the comment: Sorry, kafka is a third-party package, not part of the Python Standard Library. Suggest you pursue this with the Kafka project: http://kafka-python.readthedocs.io/en/master/support.html ---------- nosy: +ned.deily resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 20:16:56 2016 From: report at bugs.python.org (Demur Rumed) Date: Mon, 06 Jun 2016 00:16:56 +0000 Subject: [issue27236] Add CHAINED_COMPARE_OP opcode In-Reply-To: <1465155805.46.0.0768541508675.issue27236@psf.upfronthosting.co.za> Message-ID: <1465172216.58.0.40800273804.issue27236@psf.upfronthosting.co.za> Demur Rumed added the comment: @rhettinger can you clarify your opinion in relation to #27140 with #27095 & #27213 in mind? I agree that CHAINED_COMPARE_OP is unnecessary ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 20:17:45 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 06 Jun 2016 00:17:45 +0000 Subject: [issue27072] random.getrandbits is limited to 2**31-1 bits on 64-bit Windows In-Reply-To: <1463810870.39.0.980113200971.issue27072@psf.upfronthosting.co.za> Message-ID: <1465172265.53.0.438122412332.issue27072@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Sorry Steven, I'm going to mark this as rejected on the grounds that it is likely to do more harm than good. We could in fact make the range larger but it easily creates terrible effects (encouraging bad design and creating a non-interruptable, long-running, total-memory-filling call). While we do allow ``2 ** 50 ** 50``, that call is more deliberately asking for trouble than getrandbits(2**60). If someone really needed that number of bits, it isn't hard to multiple calls to getrandbits() and combine the results, deliberately and interruptably. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 20:38:06 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Mon, 06 Jun 2016 00:38:06 +0000 Subject: [issue27238] Bare except: usages in turtle.py Message-ID: <1465173486.36.0.354067909151.issue27238@psf.upfronthosting.co.za> New submission from Jelle Zijlstra: Will add a patch ---------- assignee: Jelle Zijlstra components: Library (Lib) messages: 267493 nosy: Jelle Zijlstra, serhiy.storchaka priority: normal severity: normal status: open title: Bare except: usages in turtle.py versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 20:40:45 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Jun 2016 00:40:45 +0000 Subject: [issue26014] Guide users to the newer package install instructions In-Reply-To: <1451999065.99.0.467691766338.issue26014@psf.upfronthosting.co.za> Message-ID: <20160606004041.23482.86377.9C963D5B@psf.io> Roundup Robot added the comment: New changeset 71fc5b246f5b by Ned Deily in branch '2.7': Issue #26014: Guide 2.7 users to the new packaging documentation: https://hg.python.org/cpython/rev/71fc5b246f5b New changeset f5fd646b265b by Ned Deily in branch '3.5': Issue #26014: Update 3.x packaging documentation: https://hg.python.org/cpython/rev/f5fd646b265b New changeset 7583d65da2ad by Ned Deily in branch 'default': Issue #26014: merge from 3.5 https://hg.python.org/cpython/rev/7583d65da2ad ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 20:41:07 2016 From: report at bugs.python.org (Yoni Lavi) Date: Mon, 06 Jun 2016 00:41:07 +0000 Subject: [issue22558] Missing doc links to source code for Python-coded modules. In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za> Message-ID: <1465173667.34.0.454925411894.issue22558@psf.upfronthosting.co.za> Yoni Lavi added the comment: Thank you very much for the detailed review, Nathan. Attached is a new patch that resolves the merge issues, and some of the other issues you mentioned. Concerning the index reference in marshal.rst , ah, yes, I missed that it only related to a single paragraph. I reverted that change. Concerning versionadded in unittest.mock-examples.rst, you're right, I saw that this was already available elsewhere and removed it for consistency with other similar intro files. I'll revert if you tell me. I think I fixed all the smaller issues you mentioned, too. I wasn't sure about the fuzz; I didn't see any issue, so I assume it was automatically resolved by `hg update`. I don't have any input to give concerning the 'subjective' issues and will be happy to wait for a decision. ---------- Added file: http://bugs.python.org/file43252/mywork3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 20:46:07 2016 From: report at bugs.python.org (Ned Deily) Date: Mon, 06 Jun 2016 00:46:07 +0000 Subject: [issue26014] Guide users to the newer package install instructions In-Reply-To: <1451999065.99.0.467691766338.issue26014@psf.upfronthosting.co.za> Message-ID: <1465173967.42.0.0630825844669.issue26014@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks, Susan, for your suggested patch. I expanded on it to address all of the issues Nick brought up and then some, such as also updating to the changed setuptools doc link. Pushed for release in 2.7.12, 3.5.2, and 3.6.0. ---------- nosy: +ned.deily resolution: -> fixed stage: needs patch -> resolved status: open -> closed versions: +Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 21:20:20 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 06 Jun 2016 01:20:20 +0000 Subject: [issue27229] In tree cross-build fails copying Include/graminit.h to itself In-Reply-To: <1465131940.98.0.80292566271.issue27229@psf.upfronthosting.co.za> Message-ID: <1465176020.65.0.988578037699.issue27229@psf.upfronthosting.co.za> Martin Panter added the comment: I was a little concerned that Alex?s patch used ?test A -ef B?, which is not specified by Posix. But it is apparently widely supported (and consider we would only need it for cross compilation). Anyway, I was going to suggest test "$(srcdir)" == "." instead, but maybe Xavier?s solution is slightly better again. I say go with vpath.patch, perhaps with a brief comment explaining that the cp + mv dance avoids copying the file onto itself when doing an in-tree build. ---------- stage: -> commit review versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 21:23:52 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 06 Jun 2016 01:23:52 +0000 Subject: [issue17598] mingw: init system calls In-Reply-To: <1364759885.17.0.0266392857932.issue17598@psf.upfronthosting.co.za> Message-ID: <1465176232.41.0.491419945507.issue17598@psf.upfronthosting.co.za> Martin Panter added the comment: Part of this patch is superceded by revision c7adad17f663 (Issue 22579). Here is a patch of the remaining significant changes. But I don?t know enough about Modules/Setup.config.in and Modules/Setup.dist to give it a proper review. ---------- nosy: +martin.panter stage: -> patch review versions: +Python 3.6 -Python 3.4 Added file: http://bugs.python.org/file43253/MINGW-INITSYS.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 21:33:09 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Jun 2016 01:33:09 +0000 Subject: [issue27156] IDLE: remove unused code In-Reply-To: <1464553304.91.0.34770795987.issue27156@psf.upfronthosting.co.za> Message-ID: <20160606013305.36606.22626.0E03F823@psf.io> Roundup Robot added the comment: New changeset 166784c40be8 by Terry Jan Reedy in branch 'default': Issue #27156: Remove more unused idlelib code. https://hg.python.org/cpython/rev/166784c40be8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 21:36:49 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 06 Jun 2016 01:36:49 +0000 Subject: [issue27156] IDLE: remove unused code In-Reply-To: <1464553304.91.0.34770795987.issue27156@psf.upfronthosting.co.za> Message-ID: <1465177009.3.0.0856299089849.issue27156@psf.upfronthosting.co.za> Terry J. Reedy added the comment: 3 and 4 removed. Closing at least until I find something else that is not part of a refactoring but needs at least a question answered. ---------- components: +IDLE nosy: -python-dev resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 21:48:25 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 06 Jun 2016 01:48:25 +0000 Subject: [issue27164] zlib can't decompress DEFLATE using shared dictionary In-Reply-To: <1464687663.75.0.126366287594.issue27164@psf.upfronthosting.co.za> Message-ID: <1465177705.53.0.450791327446.issue27164@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 22:11:18 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 06 Jun 2016 02:11:18 +0000 Subject: [issue24790] Idle: improve stack viewer In-Reply-To: <1438734562.89.0.932245136919.issue24790@psf.upfronthosting.co.za> Message-ID: <1465179078.06.0.335441914762.issue24790@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Deleted .keys in 8.6. ---------- versions: -Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 22:13:14 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 06 Jun 2016 02:13:14 +0000 Subject: [issue24759] Idle: require tk 8.5 and ttk widgets, and drop unneeded code. In-Reply-To: <1438294715.65.0.966229055462.issue24759@psf.upfronthosting.co.za> Message-ID: <1465179194.13.0.102499208529.issue24759@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Fixed whitespace and added comment. ---------- Added file: http://bugs.python.org/file43254/require85-v3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 22:14:04 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 06 Jun 2016 02:14:04 +0000 Subject: [issue26867] test_ssl test_options fails on ubuntu 16.04 In-Reply-To: <1461728238.71.0.110276038105.issue26867@psf.upfronthosting.co.za> Message-ID: <1465179244.8.0.65062870215.issue26867@psf.upfronthosting.co.za> Xiang Zhang added the comment: @skip_if_broken_ubuntu_ssl doesn't work in this case. `hasattr(ssl, 'PROTOCOL_SSLv2')` returns False. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 22:29:41 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 06 Jun 2016 02:29:41 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465180181.26.0.33750642381.issue26839@psf.upfronthosting.co.za> Martin Panter added the comment: Minor thing: the patch has tabbed intentation in places rather than spaces. As I understand it, if there is no entropy initialized, this patch will fall back to reading /dev/urandom, which will return predictable data (opposite of ?random? data!). But since we take this non-strict fallback in other cases (e.g. no OS support), there is a decent argument for also taking the predictable fallback path when entropy is uninitialized. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 22:30:51 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Jun 2016 02:30:51 +0000 Subject: [issue27107] mailbox.__all__ list is incomplete In-Reply-To: <1464121814.28.0.86378219066.issue27107@psf.upfronthosting.co.za> Message-ID: <20160606023048.100455.70887.279AAE18@psf.io> Roundup Robot added the comment: New changeset 4705b7597c86 by Martin Panter in branch 'default': Issue #27107: Add exception classes to mailbox.__all__, by Jacek Ko?odziej https://hg.python.org/cpython/rev/4705b7597c86 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 22:30:51 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Jun 2016 02:30:51 +0000 Subject: [issue27110] smtpd.__all__ list is incomplete In-Reply-To: <1464122507.71.0.719319292765.issue27110@psf.upfronthosting.co.za> Message-ID: <20160606023048.100455.52400.C296A913@psf.io> Roundup Robot added the comment: New changeset bcc0c3fd4a40 by Martin Panter in branch 'default': Issue #27110: Add smtpd.SMTPChannel to __all__, by Jacek Ko?odziej https://hg.python.org/cpython/rev/bcc0c3fd4a40 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 22:30:53 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Jun 2016 02:30:53 +0000 Subject: [issue27105] cgi.__all__ is incomplete In-Reply-To: <1464121575.73.0.75569808483.issue27105@psf.upfronthosting.co.za> Message-ID: <20160606023048.100455.37320.5D62CBBC@psf.io> Roundup Robot added the comment: New changeset 74ed6f3fb8d2 by Martin Panter in branch 'default': Issue #27105: Add cgi.test() to __all__, based on Jacek Ko?odziej?s patch https://hg.python.org/cpython/rev/74ed6f3fb8d2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 22:30:53 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Jun 2016 02:30:53 +0000 Subject: [issue27109] plistlib.__all__ list is incomplete In-Reply-To: <1464121972.25.0.312623599868.issue27109@psf.upfronthosting.co.za> Message-ID: <20160606023049.100455.8055.835D6D35@psf.io> Roundup Robot added the comment: New changeset 450171f53e81 by Martin Panter in branch 'default': Issue #27109: Add InvalidFileException to __all__, by Jacek Ko?odziej https://hg.python.org/cpython/rev/450171f53e81 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 22:30:54 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Jun 2016 02:30:54 +0000 Subject: [issue27108] mimetypes.__all__ list is incomplete In-Reply-To: <1464121896.07.0.577561794509.issue27108@psf.upfronthosting.co.za> Message-ID: <20160606023049.100455.81318.9070BA07@psf.io> Roundup Robot added the comment: New changeset 2057b0af1c52 by Martin Panter in branch 'default': Issue #27108: Add missing names to mimetypes.__all__, by Jacek Ko?odziej https://hg.python.org/cpython/rev/2057b0af1c52 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 22:30:54 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Jun 2016 02:30:54 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <20160606023048.100455.50932.A27A3574@psf.io> Roundup Robot added the comment: New changeset a36c7f87eba9 by Martin Panter in branch 'default': Issue #23883: News updates for __all__ attributes https://hg.python.org/cpython/rev/a36c7f87eba9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 22:39:33 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 06 Jun 2016 02:39:33 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465180773.89.0.177111757424.issue26839@psf.upfronthosting.co.za> Martin Panter added the comment: Maybe an alternative would be to add a special PYTHONHASHSEED=best-effort (or whatever) value that says if there is no entropy available, use a predictable hash seed. That would force whoever starts the Python process to be aware of the problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 22:53:43 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Jun 2016 02:53:43 +0000 Subject: [issue27107] mailbox.__all__ list is incomplete In-Reply-To: <1464121814.28.0.86378219066.issue27107@psf.upfronthosting.co.za> Message-ID: <20160606025338.36542.32504.AE53D39F@psf.io> Roundup Robot added the comment: New changeset d62e57958e7c by Martin Panter in branch 'default': Issue #27107: mailbox.fcntl = None on Windows https://hg.python.org/cpython/rev/d62e57958e7c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 22:55:25 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 06 Jun 2016 02:55:25 +0000 Subject: [issue27108] mimetypes.__all__ list is incomplete In-Reply-To: <1464121896.07.0.577561794509.issue27108@psf.upfronthosting.co.za> Message-ID: <1465181725.07.0.634232754906.issue27108@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 22:55:36 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 06 Jun 2016 02:55:36 +0000 Subject: [issue27109] plistlib.__all__ list is incomplete In-Reply-To: <1464121972.25.0.312623599868.issue27109@psf.upfronthosting.co.za> Message-ID: <1465181736.5.0.538566688078.issue27109@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 22:55:48 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 06 Jun 2016 02:55:48 +0000 Subject: [issue27110] smtpd.__all__ list is incomplete In-Reply-To: <1464122507.71.0.719319292765.issue27110@psf.upfronthosting.co.za> Message-ID: <1465181748.68.0.91376024762.issue27110@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 22:57:34 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 06 Jun 2016 02:57:34 +0000 Subject: [issue27239] Make idlelib.macosx self-contained. Message-ID: <1465181854.1.0.00138868755932.issue27239@psf.upfronthosting.co.za> New submission from Terry J. Reedy: Lib/idlelib/macosx.py:8 initializes _tk_type to None. It next defines private function _initializeTkVariantTests, which in called in setupApp and which initializes _tk_type. Then follow 4 isXyzTk functins, which "assert _tk_type is not None". This is fine for IDLE because IDLE call setupApp on startup. This is not fine for testing. In general, tests do not and should not call setupApp. If a test happens to exercise one of the 11 (for now) isXyzTk calls occurring outside of macosx, the assert is triggered. The test writer must then discover to import and call the supposedly private _initializeTkVariantTests. I would prefer instead that maxosx be more self-contained, and initialize _tk_type as needed. _initializeTkVariantTests needs a Tk instance for this line. ws = root.tk.call('tk', 'windowingsystem') I would like to wrap that with root = tkinter.Tk() and root.destroy. If that cannot be done on import, then instead of deleting the asserts, replace them with conditional calls to the initialization function. ---------- assignee: terry.reedy messages: 267513 nosy: terry.reedy priority: normal severity: normal stage: test needed status: open title: Make idlelib.macosx self-contained. type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 22:58:59 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 06 Jun 2016 02:58:59 +0000 Subject: [issue27105] cgi.__all__ is incomplete In-Reply-To: <1464121575.73.0.75569808483.issue27105@psf.upfronthosting.co.za> Message-ID: <1465181939.62.0.166624960741.issue27105@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for the patches Jacek. This one I committed after moving the test into CgiTests. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 23:05:35 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 06 Jun 2016 03:05:35 +0000 Subject: [issue27107] mailbox.__all__ list is incomplete In-Reply-To: <1464121814.28.0.86378219066.issue27107@psf.upfronthosting.co.za> Message-ID: <1465182335.61.0.381639721661.issue27107@psf.upfronthosting.co.za> Martin Panter added the comment: FTR the closest thing I could find discussing reap_children() is Issue 16968. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 23:05:59 2016 From: report at bugs.python.org (Rustemzade Mehemmed) Date: Mon, 06 Jun 2016 03:05:59 +0000 Subject: [issue27235] Heap overflow occurred due to the int overflow (Python-2.7.11/Modules/posixmodule.c) In-Reply-To: <1465149697.95.0.775433257828.issue27235@psf.upfronthosting.co.za> Message-ID: <1465182359.31.0.337847113872.issue27235@psf.upfronthosting.co.za> Changes by Rustemzade Mehemmed : ---------- components: +Interpreter Core versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 5 23:13:30 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 06 Jun 2016 03:13:30 +0000 Subject: [issue27233] Missing documentation for PyOS_FSPath In-Reply-To: <1465146030.9.0.386709465455.issue27233@psf.upfronthosting.co.za> Message-ID: <1465182810.96.0.996200317573.issue27233@psf.upfronthosting.co.za> Martin Panter added the comment: I haven?t really been following the FS-path stuff, but I guess this also needs .. versionadded:: 3.6 ---------- nosy: +martin.panter stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 01:19:03 2016 From: report at bugs.python.org (Susumu Koshiba) Date: Mon, 06 Jun 2016 05:19:03 +0000 Subject: [issue25738] http.server doesn't handle RESET CONTENT status correctly In-Reply-To: <1448583978.87.0.253695569638.issue25738@psf.upfronthosting.co.za> Message-ID: <1465190343.38.0.888956545011.issue25738@psf.upfronthosting.co.za> Susumu Koshiba added the comment: Ah yes, you are right. I didn't think about the cases where it will send HEAD for codes like 204(No Content). I've created a patch for 3.6 to see if this looks reasonable, if review passes, I'll create patches for the rest of the releases. Thanks a lot for pointing this out. ---------- Added file: http://bugs.python.org/file43255/issue25738_http_reset_content_06.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 01:57:38 2016 From: report at bugs.python.org (SilentGhost) Date: Mon, 06 Jun 2016 05:57:38 +0000 Subject: [issue27235] Heap overflow occurred due to the int overflow (Python-2.7.11/Modules/posixmodule.c) In-Reply-To: <1465149697.95.0.775433257828.issue27235@psf.upfronthosting.co.za> Message-ID: <1465192658.68.0.191323106774.issue27235@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- components: +Extension Modules -Interpreter Core nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 01:59:11 2016 From: report at bugs.python.org (SilentGhost) Date: Mon, 06 Jun 2016 05:59:11 +0000 Subject: [issue27168] Comprehensions and await need more unittests In-Reply-To: <1464718014.77.0.520069298007.issue27168@psf.upfronthosting.co.za> Message-ID: <1465192751.62.0.693750563167.issue27168@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- components: +Tests title: Yury isn't sure comprehensions and await interact correctly -> Comprehensions and await need more unittests type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 02:30:07 2016 From: report at bugs.python.org (SilentGhost) Date: Mon, 06 Jun 2016 06:30:07 +0000 Subject: [issue27231] Support the fspath protocol in the posixpath module In-Reply-To: <1465144539.6.0.0510380371882.issue27231@psf.upfronthosting.co.za> Message-ID: <1465194607.74.0.305375333446.issue27231@psf.upfronthosting.co.za> SilentGhost added the comment: There seems to be an issue with your patch, it does apply cleanly when doing that manually, but Rietveld doesn't like it. The changes in Lib/posixpath.py and Lib/test/test_posixpath.py don't show up. ---------- nosy: +SilentGhost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 02:50:15 2016 From: report at bugs.python.org (SilentGhost) Date: Mon, 06 Jun 2016 06:50:15 +0000 Subject: [issue27232] os.fspath() should not use repr() on error In-Reply-To: <1465145885.45.0.563591962736.issue27232@psf.upfronthosting.co.za> Message-ID: <1465195815.04.0.44880562049.issue27232@psf.upfronthosting.co.za> SilentGhost added the comment: This is behaviour introduced by issue 25548, it would make sense to me to discuss this problem there if you think it's necessary. repr in error messages has been a standard approach in Python for a very long time, however. ---------- nosy: +SilentGhost resolution: -> not a bug stage: -> resolved status: open -> closed superseder: -> Show the address in the repr for class objects _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 03:32:30 2016 From: report at bugs.python.org (Petr Ovtchenkov) Date: Mon, 06 Jun 2016 07:32:30 +0000 Subject: [issue27101] Compilation of python (modules) for foreign target platform problem. In-Reply-To: <1464066887.71.0.116030526807.issue27101@psf.upfronthosting.co.za> Message-ID: <1465198350.96.0.161123483277.issue27101@psf.upfronthosting.co.za> Petr Ovtchenkov added the comment: Matthias, This question is really for you: fc1903166 (doko 2012-09-21 13:52:29 +0200 422) if multiarch_path_component != '': fc1903166 (doko 2012-09-21 13:52:29 +0200 423) add_dir_to_list(self.compiler.library_dirs, fc1903166 (doko 2012-09-21 13:52:29 +0200 424) '/usr/lib/' + multiarch_path_component) fc1903166 (doko 2012-09-21 13:52:29 +0200 425) add_dir_to_list(self.compiler.include_dirs, fc1903166 (doko 2012-09-21 13:52:29 +0200 426) '/usr/include/' + multiarch_path_component) fc1903166 (doko 2012-09-21 13:52:29 +0200 427) return ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 03:48:54 2016 From: report at bugs.python.org (SilentGhost) Date: Mon, 06 Jun 2016 07:48:54 +0000 Subject: [issue26867] test_ssl test_options fails on ubuntu 16.04 In-Reply-To: <1461728238.71.0.110276038105.issue26867@psf.upfronthosting.co.za> Message-ID: <1465199334.37.0.806679367793.issue26867@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +SilentGhost versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 04:08:04 2016 From: report at bugs.python.org (SilentGhost) Date: Mon, 06 Jun 2016 08:08:04 +0000 Subject: [issue26983] float() can return not exact float instance In-Reply-To: <1462801593.23.0.789372695786.issue26983@psf.upfronthosting.co.za> Message-ID: <1465200484.48.0.847257187015.issue26983@psf.upfronthosting.co.za> SilentGhost added the comment: test_format resulted in semi-failure due to this change. The attached patch fixes the issue. ---------- assignee: -> serhiy.storchaka nosy: +SilentGhost resolution: fixed -> stage: resolved -> commit review status: closed -> open Added file: http://bugs.python.org/file43256/issue26983.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 05:04:38 2016 From: report at bugs.python.org (Mathieu Dupuy) Date: Mon, 06 Jun 2016 09:04:38 +0000 Subject: [issue25738] http.server doesn't handle RESET CONTENT status correctly In-Reply-To: <1448583978.87.0.253695569638.issue25738@psf.upfronthosting.co.za> Message-ID: <1465203878.35.0.868618588724.issue25738@psf.upfronthosting.co.za> Changes by Mathieu Dupuy : ---------- nosy: -deronnax _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 05:32:02 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 06 Jun 2016 09:32:02 +0000 Subject: [issue27235] Heap overflow occurred due to the int overflow (Python-2.7.11/Modules/posixmodule.c) In-Reply-To: <1465149697.95.0.775433257828.issue27235@psf.upfronthosting.co.za> Message-ID: <1465205522.19.0.0204933691777.issue27235@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 05:58:08 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 06 Jun 2016 09:58:08 +0000 Subject: [issue27235] Heap overflow occurred due to the int overflow (Python-2.7.11/Modules/posixmodule.c) In-Reply-To: <1465149697.95.0.775433257828.issue27235@psf.upfronthosting.co.za> Message-ID: <1465207088.53.0.711894940591.issue27235@psf.upfronthosting.co.za> Xiang Zhang added the comment: I am confused why this could happen. On x86 platform, you can not even create a string of size 0xffffffff. On x64 platform, I don't think strlen(s) + 3 can lead to overflow where s is of size Py_ssize_t. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 06:00:28 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Jun 2016 10:00:28 +0000 Subject: [issue26983] float() can return not exact float instance In-Reply-To: <1462801593.23.0.789372695786.issue26983@psf.upfronthosting.co.za> Message-ID: <20160606100023.21221.90342.6C82FEE6@psf.io> Roundup Robot added the comment: New changeset 6216fb8afa53 by Serhiy Storchaka in branch 'default': Issue #26983: Fixed test_format failure. https://hg.python.org/cpython/rev/6216fb8afa53 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 06:01:54 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Jun 2016 10:01:54 +0000 Subject: [issue26983] float() can return not exact float instance In-Reply-To: <1462801593.23.0.789372695786.issue26983@psf.upfronthosting.co.za> Message-ID: <1465207314.57.0.791613049529.issue26983@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: My failure. Thank you for your report and patch SilentGhost. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 06:25:59 2016 From: report at bugs.python.org (Leblond Emmanuel) Date: Mon, 06 Jun 2016 10:25:59 +0000 Subject: [issue27240] 'UnstructuredTokenList' object has no attribute '_fold_as_ew' Message-ID: <1465208759.2.0.0752415166741.issue27240@psf.upfronthosting.co.za> New submission from Leblond Emmanuel: The folding code for email headers crashes whenever it hits line _header_value_parser.py:432 given it try to call method `_fold_as_ew`. ``` (venv)? vigiechiro-api git:(in2p3) ? python test_mail.py Traceback (most recent call last): File "test_mail.py", line 36, in mail.send(msg) File "/home/emmanuel/projects/vigiechiro-api/venv/lib/python3.5/site-packages/flask_mail.py", line 492, in send message.send(connection) File "/home/emmanuel/projects/vigiechiro-api/venv/lib/python3.5/site-packages/flask_mail.py", line 427, in send connection.send(self) File "/home/emmanuel/projects/vigiechiro-api/venv/lib/python3.5/site-packages/flask_mail.py", line 190, in send message.as_bytes() if PY3 else message.as_string(), File "/home/emmanuel/projects/vigiechiro-api/venv/lib/python3.5/site-packages/flask_mail.py", line 385, in as_bytes return self._message().as_bytes() File "/usr/lib/python3.5/email/message.py", line 179, in as_bytes g.flatten(self, unixfrom=unixfrom) File "/usr/lib/python3.5/email/generator.py", line 115, in flatten self._write(msg) File "/usr/lib/python3.5/email/generator.py", line 195, in _write self._write_headers(msg) File "/usr/lib/python3.5/email/generator.py", line 422, in _write_headers self._fp.write(self.policy.fold_binary(h, v)) File "/usr/lib/python3.5/email/policy.py", line 190, in fold_binary folded = self._fold(name, value, refold_binary=self.cte_type=='7bit') File "/usr/lib/python3.5/email/policy.py", line 204, in _fold return self.header_factory(name, ''.join(lines)).fold(policy=self) File "/usr/lib/python3.5/email/headerregistry.py", line 255, in fold return header.fold(policy=policy) File "/usr/lib/python3.5/email/_header_value_parser.py", line 300, in fold self._fold(folded) File "/usr/lib/python3.5/email/_header_value_parser.py", line 1228, in _fold rest._fold(folded) File "/usr/lib/python3.5/email/_header_value_parser.py", line 432, in _fold part._fold_as_ew(folded) AttributeError: 'UnstructuredTokenList' object has no attribute '_fold_as_ew' > /usr/lib/python3.5/email/_header_value_parser.py(432)_fold() -> part._fold_as_ew(folded) ``` Given folding depends a lot on the processed value, this bug only trigger in very specific encoded headers (I've try to reproduce this bug with various values but only the one which originally made me find the bug worked so far). I've isolated the bug into a simple test case (see enclosed file). It seems this part of the code has been rewritten between Python2 and 3 (the file _header_value_parser.py doesn't exists in Python2). So unsurprisingly the bug doesn't trigger in Python2. Replacing `part._fold_as_ew(folded)` by `part._fold(folded)` seems to fix the bug, but given my poor knowledge of this code, this fix probably produce unwanted behaviors. ---------- components: email files: test_mail_2.py messages: 267525 nosy: Leblond Emmanuel, barry, r.david.murray priority: normal severity: normal status: open title: 'UnstructuredTokenList' object has no attribute '_fold_as_ew' versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43257/test_mail_2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 06:41:40 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 06 Jun 2016 10:41:40 +0000 Subject: [issue25738] http.server doesn't handle RESET CONTENT status correctly In-Reply-To: <1448583978.87.0.253695569638.issue25738@psf.upfronthosting.co.za> Message-ID: <1465209700.98.0.908160418878.issue25738@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks Susumu, I think the logic is right this time. I left some new suggestions for the tests, if you want to take them on or not, that?s up to you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 07:19:26 2016 From: report at bugs.python.org (SilentGhost) Date: Mon, 06 Jun 2016 11:19:26 +0000 Subject: [issue27240] 'UnstructuredTokenList' object has no attribute '_fold_as_ew' In-Reply-To: <1465208759.2.0.0752415166741.issue27240@psf.upfronthosting.co.za> Message-ID: <1465211966.99.0.850737913989.issue27240@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- stage: -> needs patch type: -> behavior versions: -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 08:43:03 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Mon, 06 Jun 2016 12:43:03 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465216983.56.0.605501465755.issue26839@psf.upfronthosting.co.za> Changes by ???? ????????? : ---------- nosy: -mmarkk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 08:58:29 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Mon, 06 Jun 2016 12:58:29 +0000 Subject: [issue17004] Expand zipimport to include other compression methods In-Reply-To: <1358707302.86.0.811743649739.issue17004@psf.upfronthosting.co.za> Message-ID: <1465217909.66.0.307361832721.issue17004@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: +1 for that. I like XZ support so that our application size can be reduced. ---------- nosy: +Chi Hsuan Yen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 09:49:06 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Mon, 06 Jun 2016 13:49:06 +0000 Subject: [issue27238] Bare except: usages in turtle.py In-Reply-To: <1465173486.36.0.354067909151.issue27238@psf.upfronthosting.co.za> Message-ID: <1465220946.53.0.0932369141196.issue27238@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: This patch removes all usages of "except:" in turtle.py. The tests in test_turtle.py and turtle.rst still work. ---------- keywords: +patch Added file: http://bugs.python.org/file43258/issue27238.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 09:55:27 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Mon, 06 Jun 2016 13:55:27 +0000 Subject: [issue27232] os.fspath() should not use repr() on error In-Reply-To: <1465145885.45.0.563591962736.issue27232@psf.upfronthosting.co.za> Message-ID: <1465221327.53.0.603000964131.issue27232@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: No, that issue just adds the address to the repr() of types. It is not normal to use repr for type objects in error messages: >>> int(None) Traceback (most recent call last): File "", line 1, in TypeError: int() argument must be a string, a bytes-like object or a number, not 'NoneType' >>> open(None, 0) Traceback (most recent call last): File "", line 1, in TypeError: open() argument 2 must be str, not int >>> os.fspath(None) Traceback (most recent call last): File "", line 1, in TypeError: expected str, bytes or os.PathLike object, not ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 09:57:15 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Mon, 06 Jun 2016 13:57:15 +0000 Subject: [issue27232] os.fspath() should not use repr() on error In-Reply-To: <1465145885.45.0.563591962736.issue27232@psf.upfronthosting.co.za> Message-ID: <1465221435.84.0.753003233939.issue27232@psf.upfronthosting.co.za> Changes by Jelle Zijlstra : ---------- resolution: not a bug -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 10:01:30 2016 From: report at bugs.python.org (Sophie) Date: Mon, 06 Jun 2016 14:01:30 +0000 Subject: [issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program In-Reply-To: <1366373912.56.0.138468709297.issue17797@psf.upfronthosting.co.za> Message-ID: <1465221690.79.0.647977040784.issue17797@psf.upfronthosting.co.za> Sophie added the comment: In case someone else need it, here is a patch for python 3.5.0b1 ---------- nosy: +Sopouic versions: +Python 3.5 -Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file43259/python-3.5.0b1-fdvalidation.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 10:02:31 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Mon, 06 Jun 2016 14:02:31 +0000 Subject: [issue27231] Support the fspath protocol in the posixpath module In-Reply-To: <1465144539.6.0.0510380371882.issue27231@psf.upfronthosting.co.za> Message-ID: <1465221751.98.0.886300526456.issue27231@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: I wrote the patch assuming that the error messages would be changed in accordance with issue27232. Let's put this on hold until that is resolved. ---------- dependencies: +os.fspath() should not use repr() on error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 10:06:50 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Mon, 06 Jun 2016 14:06:50 +0000 Subject: [issue27233] Missing documentation for PyOS_FSPath In-Reply-To: <1465146030.9.0.386709465455.issue27233@psf.upfronthosting.co.za> Message-ID: <1465222010.47.0.763197983639.issue27233@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Thanks for the comments here and in Rietveld. This patch adds versionadded and an extra space. ---------- Added file: http://bugs.python.org/file43260/issue27233-cr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 10:22:13 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Jun 2016 14:22:13 +0000 Subject: [issue27238] Bare except: usages in turtle.py In-Reply-To: <1465173486.36.0.354067909151.issue27238@psf.upfronthosting.co.za> Message-ID: <1465222933.7.0.884448031967.issue27238@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> patch review type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 10:55:56 2016 From: report at bugs.python.org (Matthias Klose) Date: Mon, 06 Jun 2016 14:55:56 +0000 Subject: [issue27101] Compilation of python (modules) for foreign target platform problem. In-Reply-To: <1464066887.71.0.116030526807.issue27101@psf.upfronthosting.co.za> Message-ID: <1465224956.07.0.98925887804.issue27101@psf.upfronthosting.co.za> Matthias Klose added the comment: sorry, I don't understand your last comment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 11:09:50 2016 From: report at bugs.python.org (A. Skrobov) Date: Mon, 06 Jun 2016 15:09:50 +0000 Subject: [issue26415] Fragmentation of the heap memory in the Python parser In-Reply-To: <1456182380.09.0.81920177296.issue26415@psf.upfronthosting.co.za> Message-ID: <1465225790.32.0.354602042327.issue26415@psf.upfronthosting.co.za> A. Skrobov added the comment: Now that #26526 landed (thanks to everybody involved!), I'm requesting a review on an updated version of my patch, which addresses the excessive memory consumption by the parser. The description of my original patch still applies: > The attached patch for the parser reduces "Maximum resident set size (kbytes)" threefold, for the degenerate example of 'import ast; ast.parse("0,"*1000000, mode="eval")', by eliminating many CST nodes that have a single child. > > According to the comment in Parser/node.c -- "89% of PyObject_REALLOC calls in PyNode_AddChild passed 1 for the size" -- the memory saving should be generally applicable, and not limited just to this degenerate case. > I've now tried it with "perf.py -r -m", and the memory savings are as follows: > ... > on these benchmarks, the saving is not threefold, of course; but still quite substantial (up to 30%). My new patch updates Modules/parsermodule.c to accept such "compressed" nodes, so that everything still builds cleanly and passes the tests. ---------- nosy: +benjamin.peterson, berker.peksag, brett.cannon, fdrake, giampaolo.rodola Added file: http://bugs.python.org/file43261/patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 11:11:58 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Jun 2016 15:11:58 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1465225918.37.0.636202843806.issue5124@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 11:13:05 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Jun 2016 15:13:05 +0000 Subject: [issue27173] Modern Unix key bindings for IDLE In-Reply-To: <1464766185.36.0.150155479026.issue27173@psf.upfronthosting.co.za> Message-ID: <1465225985.53.0.888954388994.issue27173@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 11:52:41 2016 From: report at bugs.python.org (Antti Haapala) Date: Mon, 06 Jun 2016 15:52:41 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465228361.49.0.242290992302.issue26839@psf.upfronthosting.co.za> Antti Haapala added the comment: I don't think setting environment variables is a solution, as it is not always clear which script occurs early in the boot process, or even that which program has components written in Python. However I'd want to be notified of failure as well, perhaps a warning should be emitted. ---------- nosy: +ztane _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 12:09:37 2016 From: report at bugs.python.org (Petr Ovtchenkov) Date: Mon, 06 Jun 2016 16:09:37 +0000 Subject: [issue27101] Compilation of python (modules) for foreign target platform problem. In-Reply-To: <1464066887.71.0.116030526807.issue27101@psf.upfronthosting.co.za> Message-ID: <1465229377.37.0.396130125319.issue27101@psf.upfronthosting.co.za> Petr Ovtchenkov added the comment: This mean that code for search in /usr/include/... in multiarch environment was added by you in commit fc1903166 2012-09-21 13:52:29 +0200, so in my suggestion I just don't change behaviour of you code. As for my opinion, any additions of -I/usr/include/... are wrong: compiler either see it without such -I... or shouldn't see it at all (as for cross), or require hint from builder (something like CURSES_CFLAGS=-I/home/bluser/new_curses/include). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 12:13:23 2016 From: report at bugs.python.org (Stefan Krah) Date: Mon, 06 Jun 2016 16:13:23 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465229603.25.0.62081583502.issue26839@psf.upfronthosting.co.za> Stefan Krah added the comment: I think such warnings should be emitted at application level, similar to the case when a program refuses to run under UID 0. If admins wish, they can also integrate such checks into the system startup sequence (e.g. runlevel 3 is only reached if randomness is actually available). ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 12:27:31 2016 From: report at bugs.python.org (Nathan Harold) Date: Mon, 06 Jun 2016 16:27:31 +0000 Subject: [issue22558] Missing doc links to source code for Python-coded modules. In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za> Message-ID: <1465230451.52.0.5719099354.issue22558@psf.upfronthosting.co.za> Nathan Harold added the comment: I went over the sections I above called "Other/Smaller details" as addressed in mywork3.patch. I think they look fine. The patch applies seamlessly to both 3.5 and 3.6. For reference, since I noted them when I reviewed mywork2.patch last week, here are the packages at issue in the question about links to packages: Package docs in which the patch in this issue adds a link to __init__.py: dbm.rst, email.rst, importlib.rst, json.rst, msilib.rst, tkinter.rst, unittest.rst, xml.dom.rst, xml.sax.rst Package docs in which the patch in this issue adds a link to a directory: 2to3.rst, email.mime.rst, idle.rst, multiprocessing.rst, sqlite3.rst, urllib.rst, venv.rst, xml.rst Also, I noticed that asyncio.rst provides a precedent for linking to a source directory. So both ways have been done before. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 12:31:15 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Mon, 06 Jun 2016 16:31:15 +0000 Subject: [issue27236] Add CHAINED_COMPARE_OP opcode In-Reply-To: <1465155805.46.0.0768541508675.issue27236@psf.upfronthosting.co.za> Message-ID: <1465230675.93.0.390073370648.issue27236@psf.upfronthosting.co.za> Josh Rosenberg added the comment: It is a little funny though. I expect a more common test like: if a < b < c: pass to be unconditionally faster than the logically equivalent: if a < b and b < c: pass The only difference between the two should be that b is loaded only once, which should make the chained comparison either equivalent or faster. But thanks to the additional stack manipulations needed, in microbenchmarks, this isn't the case. I was just testing a couple simple cases in ipython (3.5, Linux, x64), and the chained comparison is actually slower when short-circuiting is involved: %%timeit -r5 a, b, c = range(3, 0, -1) if a < b < c: pass 10000000 loops, best of 5: 33.7 ns per loop %%timeit -r5 a, b, c = range(3, 0, -1) if a < b and b < c: pass 10000000 loops, best of 5: 25 ns per loop or even without short-circuiting, but with the final test failing, chained loses (by a smaller margin): %%timeit -r5 a, b, c = 0, 1, 0 if a < b < c: pass 10000000 loops, best of 5: 42.5 ns per loop %%timeit -r5 a, b, c = 0, 1, 0 if a < b and b < c: pass 10000000 loops, best of 5: 39.3 ns per loop The same pattern holds if a and c are replaced with constants, e.g. if 0 < b < 2: (so only b is loaded by name). Yes, it's a small difference; when a, b, c are initialized from range(3), so all tests succeed, chained comparisons win, 44.9 ns to 54.5 ns. But it seems kind of odd that the simplest case of a chained comparison is actually a pessimization in two of the three cases. Not saying it's worth changing (I doubt chained comparisons occur in code enough to justify the tiny savings a dedicated op code could provide), but it's not something I'd reject out of hand. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 13:46:57 2016 From: report at bugs.python.org (Joe Jevnik) Date: Mon, 06 Jun 2016 17:46:57 +0000 Subject: [issue27241] Catch exceptions raised in pstats add (repl) Message-ID: <1465235217.03.0.206339762722.issue27241@psf.upfronthosting.co.za> New submission from Joe Jevnik: I was trying to add a file and accidently mistyped the name which crashed the repl session. I think it would be nicer to report the failure but bring me back to the prompt so I can decide what I would like to do. This patch catches any IOErrors that can be raised when adding a file in the repl, reports it to the user, and then returns them to the repl. ---------- components: Demos and Tools files: catch-pstats-add.patch keywords: patch messages: 267542 nosy: llllllllll priority: normal severity: normal status: open title: Catch exceptions raised in pstats add (repl) type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43262/catch-pstats-add.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 13:49:11 2016 From: report at bugs.python.org (SilentGhost) Date: Mon, 06 Jun 2016 17:49:11 +0000 Subject: [issue27241] Catch exceptions raised in pstats add (repl) In-Reply-To: <1465235217.03.0.206339762722.issue27241@psf.upfronthosting.co.za> Message-ID: <1465235351.54.0.858901732305.issue27241@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +georg.brandl stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 14:59:27 2016 From: report at bugs.python.org (Emanuel Barry) Date: Mon, 06 Jun 2016 18:59:27 +0000 Subject: [issue27242] Clarify the use cases of NotImplemented in the docs Message-ID: <1465239567.69.0.773832868585.issue27242@psf.upfronthosting.co.za> New submission from Emanuel Barry: The NotImplemented docs aren't explicit enough when it comes to where it can/should be used. Patch attached. ---------- assignee: docs at python components: Documentation files: NotImplemented_wording_1.patch keywords: patch messages: 267543 nosy: docs at python, ebarry priority: normal severity: normal stage: patch review status: open title: Clarify the use cases of NotImplemented in the docs type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43263/NotImplemented_wording_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 15:21:36 2016 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 06 Jun 2016 19:21:36 +0000 Subject: [issue27243] __aiter__ should return async iterator instead of awaitable Message-ID: <1465240896.52.0.994549894653.issue27243@psf.upfronthosting.co.za> New submission from Yury Selivanov: There is a small flaw in PEP 492 design -- __aiter__ should not return an awaitable object that resolves to an asynchronous iterator. It should return an asynchronous iterator directly. Let me explain this by showing some examples. I've discovered this while working on a new asynchronous generators PEP. Let's pretend that we have them already: if we have a 'yield' expression in an 'async def' function, the function becomes an "asynchronous generator function": async def foo(): await bar() yield 1 await baz() yield 2 # foo -- is an `asynchronous generator function` # foo() -- is an `asynchronous generator` If we iterate through "foo()", it will await on "bar()", yield "1", await on "baz()", and yield "2": >>> async for el in foo(): ... print(el) 1 2 If we decide to have a class with an __aiter__ that is an async generator, we'd write something like this: class Foo: async def __aiter__(self): await bar() yield 1 await baz() yield 2 However, with the current PEP 492 design, the above code would be invalid! The interpreter expects __aiter__ to return a coroutine, not an async generator. I'm still working on the PEP for async generators, targeting CPython 3.6. And once it is ready, it might still be rejected or deferred. But in any case, this PEP 492 flaw has to be fixed now, in 3.5.2 (since PEP 492 is provisional). The attached patch fixes the __aiter__ in a backwards compatible way: 1. ceval/GET_AITER opcode calls the __aiter__ method. 2. If the returned object has an '__anext__' method, GET_AITER silently wraps it in an awaitable, which is equivalent to the following coroutine: async def wrapper(aiter_result): return aiter_result 3. If the returned object does not have an '__anext__' method, a DeprecationWarning is raised. ---------- assignee: yselivanov components: Interpreter Core files: fix_aiter.patch keywords: patch messages: 267544 nosy: brett.cannon, gvanrossum, haypo, lukasz.langa, ncoghlan, yselivanov priority: release blocker severity: normal status: open title: __aiter__ should return async iterator instead of awaitable versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43264/fix_aiter.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 16:10:36 2016 From: report at bugs.python.org (Thomas Petazzoni) Date: Mon, 06 Jun 2016 20:10:36 +0000 Subject: [issue20210] Provide configure options to enable/disable Python modules and extensions In-Reply-To: <1465083180.28.0.920982640762.issue20210@psf.upfronthosting.co.za> Message-ID: <20160606221023.3d4eabee@free-electrons.com> Thomas Petazzoni added the comment: Hello, On Sat, 04 Jun 2016 23:33:00 +0000, Matthias Klose wrote: > fyi, this came up again at the 2016 Language Summit, the request here > was to provide some minimal packages which are just enough to run a > cloud image (the cloud-init package requires a somehow minimal > python). Thanks for the feedback! Definitely glad to hear that some other folks are interested in reducing the footprint of the default Python installation. Since embedded people have been ignored, hopefully the cloud people will have more luck in this endeavor :) Thanks! Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 16:24:44 2016 From: report at bugs.python.org (Larry Hastings) Date: Mon, 06 Jun 2016 20:24:44 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465244684.98.0.936995726322.issue26839@psf.upfronthosting.co.za> Larry Hastings added the comment: Speaking as the 3.5 RM, I suppose I have to have an opinion. I don't think "Python now uses a better source of randomness to seed the random module at startup" is a major feature. It's a nice-to-have, not a must-have. And people who care about good randomness (e.g. people doing crypto with the random module) shouldn't be relying on the freebie initialization they get just by importing. So I think changing the default is fine, especially if the new default is "seed from the entropy pool, but if it's empty failover to the not-as-good source of random bits". If you think that's a bad move, please add your comments here--I'm willing to have my mind changed about this. I'll remind you: the schedule says I tag 3.5.2 RC 1 this coming Saturday (almost exactly six days from now). Naturally I'd prefer to make the release on time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 16:27:56 2016 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 06 Jun 2016 20:27:56 +0000 Subject: [issue27243] __aiter__ should return async iterator instead of awaitable In-Reply-To: <1465240896.52.0.994549894653.issue27243@psf.upfronthosting.co.za> Message-ID: <1465244876.49.0.54944536316.issue27243@psf.upfronthosting.co.za> Nick Coghlan added the comment: While I agree this needs to be fixed, one key piece of documentation needed will be to cover how to write an __aiter__ method that does the right thing on both 3.5.1 and 3.5.2+ (and also avoids the deprecation warning in the latter case). (I've also added Larry to the cc list as release manager) ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 16:31:34 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 06 Jun 2016 20:31:34 +0000 Subject: [issue27243] __aiter__ should return async iterator instead of awaitable In-Reply-To: <1465244876.49.0.54944536316.issue27243@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Would it be easier to handle for everyone if this did not vary between 3.5.0/1 and 3.5.2, and instead was an incompatibility in 3.6? (That would still be allowed given 492's provisional status.) ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 16:43:45 2016 From: report at bugs.python.org (Chris Withers) Date: Mon, 06 Jun 2016 20:43:45 +0000 Subject: [issue27244] print(';;') fails in pdb with SyntaxError Message-ID: <1465245825.04.0.474122067055.issue27244@psf.upfronthosting.co.za> New submission from Chris Withers: This doesn't seem right: (Pdb) ';;' *** SyntaxError: EOL while scanning string literal *** SyntaxError: EOL while scanning string literal (Pdb) p ';;' *** SyntaxError: EOL while scanning string literal *** SyntaxError: EOL while scanning string literal (Pdb) !print(';;') *** SyntaxError: EOL while scanning string literal *** SyntaxError: EOL while scanning string literal ---------- components: Library (Lib) messages: 267549 nosy: cjw296 priority: normal severity: normal status: open title: print(';;') fails in pdb with SyntaxError versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 16:45:55 2016 From: report at bugs.python.org (Colm Buckley) Date: Mon, 06 Jun 2016 20:45:55 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465245955.27.0.565265253778.issue26839@psf.upfronthosting.co.za> Colm Buckley added the comment: @larry - Thank you for joining in. I'm uploading a third version of the patch (against clean 3.5.1 source, with correct whitespace and a less confusing comment) which implements the following: * configure.ac / pyconfig.h.in : looks for linux/random.h and sets HAVE_LINUX_RANDOM_H if present. * random.c : calls getrandom() with the GRND_NONBLOCK flag; if that fails, fall back to reading /dev/urandom which will have insufficient entropy but will at least return some data. I feel that there is no consistent way to signal to higher-level applications that the random data has sub-standard entropy; but that this at least preserves the expected semantics, and doesn't block on startup in the event of an uninitialized entropy pool. ---------- Added file: http://bugs.python.org/file43265/getrandom-nonblocking-v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 16:46:04 2016 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 06 Jun 2016 20:46:04 +0000 Subject: [issue27243] __aiter__ should return async iterator instead of awaitable In-Reply-To: <1465240896.52.0.994549894653.issue27243@psf.upfronthosting.co.za> Message-ID: <1465245964.53.0.017421771135.issue27243@psf.upfronthosting.co.za> Nick Coghlan added the comment: Since the old behaviour is only deprecated with Yury's changes, rather than disallowed entirely, I think it makes sense to provide a 3.5.x version that also supports the new behaviour. In addition to my docs comment above, the other thing I noticed in reviewing the patch is that the proposed tests don't currently check that we *don't* emit a deprecation warning for the newly permitted forward compatible cases that return an asynchronous iterator (rather than an awaitable) directly from __aiter__. There are definitely some tests that exercise that path, so we could rely on the general principle of "the test suite shouldn't emit deprecation warnings", but we could also add some tests that specifically check that no warning is emitted in that case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 16:48:26 2016 From: report at bugs.python.org (wim glenn) Date: Mon, 06 Jun 2016 20:48:26 +0000 Subject: [issue27244] print(';;') fails in pdb with SyntaxError In-Reply-To: <1465245825.04.0.474122067055.issue27244@psf.upfronthosting.co.za> Message-ID: <1465246106.45.0.241772956247.issue27244@psf.upfronthosting.co.za> wim glenn added the comment: Seems to be as documented here: https://docs.python.org/2/library/pdb.html#debugger-commands "No intelligence is applied to separating the commands; the input is split at the first ;; pair, even if it is in the middle of a quoted string." ---------- nosy: +wim.glenn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 16:49:39 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Jun 2016 20:49:39 +0000 Subject: [issue27236] Add CHAINED_COMPARE_OP opcode In-Reply-To: <1465155805.46.0.0768541508675.issue27236@psf.upfronthosting.co.za> Message-ID: <1465246179.71.0.465107383218.issue27236@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your tests Josh. I have collected additional statistics. According to it CHAINED_COMPARE_OP would be used 100 times less than COMPARE_OP. This is not worth adding new opcode. ---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 16:50:09 2016 From: report at bugs.python.org (Larry Hastings) Date: Mon, 06 Jun 2016 20:50:09 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465246209.04.0.0876824381258.issue26839@psf.upfronthosting.co.za> Larry Hastings added the comment: > I'm uploading a third version of the patch (against clean 3.5.1 source Not against the 3.5 branch from hg.python.org/cpython ? If not, why not? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 16:50:52 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Jun 2016 20:50:52 +0000 Subject: [issue20210] Provide configure options to enable/disable Python modules and extensions In-Reply-To: <20160606221023.3d4eabee@free-electrons.com> Message-ID: STINNER Victor added the comment: Fedora 24 also uses a minimal "system python" to get small cloud image: https://fedoraproject.org/wiki/Changes/System_Python#Benefit_to_Fedora The base package only contains the minimum subset of the stdlib, the full stdlib comes with a second package based on the first one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 16:52:15 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Jun 2016 20:52:15 +0000 Subject: [issue27238] Bare except: usages in turtle.py In-Reply-To: <1465173486.36.0.354067909151.issue27238@psf.upfronthosting.co.za> Message-ID: <1465246335.65.0.742787398005.issue27238@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Brett, can __file__ of imported/executed module be None, bytes or absent in 3.6? Can it be non-str? ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 16:57:42 2016 From: report at bugs.python.org (Larry Hastings) Date: Mon, 06 Jun 2016 20:57:42 +0000 Subject: [issue27243] __aiter__ should return async iterator instead of awaitable In-Reply-To: <1465240896.52.0.994549894653.issue27243@psf.upfronthosting.co.za> Message-ID: <1465246662.84.0.118676516631.issue27243@psf.upfronthosting.co.za> Larry Hastings added the comment: As RM my default position is naturally "don't change behavior in point releases". I'm willing to be overruled by the BDFL, less so by anybody else. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 16:58:08 2016 From: report at bugs.python.org (William Grzybowski) Date: Mon, 06 Jun 2016 20:58:08 +0000 Subject: [issue25602] Add support for EVFILT_USER kqueue filter In-Reply-To: <1447242368.46.0.687277732517.issue25602@psf.upfronthosting.co.za> Message-ID: <1465246688.87.0.624540824047.issue25602@psf.upfronthosting.co.za> William Grzybowski added the comment: I have bumped into this issue as well. This change would be much appreciate on my end. What can we do to move the ball forward here? Thanks! ---------- nosy: +wg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 16:58:43 2016 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 06 Jun 2016 20:58:43 +0000 Subject: [issue27243] __aiter__ should return async iterator instead of awaitable In-Reply-To: <1465240896.52.0.994549894653.issue27243@psf.upfronthosting.co.za> Message-ID: <1465246723.7.0.789246568392.issue27243@psf.upfronthosting.co.za> Yury Selivanov added the comment: > While I agree this needs to be fixed, one key piece of documentation needed will be to cover how to write an __aiter__ method that does the right thing on both 3.5.1 and 3.5.2+ (and also avoids the deprecation warning in the latter case). Oh, this is tough. How about we do this: 1. In 3.5.2 we start to support new behaviour. We raise PendingDeprecationWarning. We update documentation and PEP 492. The recommended way to write 3.5 code is to keep returning awaitables from __aiter__. We can add a snippet of code for a compatibility decorator to the docs. 2. In 3.6 we start to raise DeprecationWarning. The recommended way to write code for 3.6 & 3.7 is to return async iterators from __aiter__. 3. In 3.7 we remove support of the old behaviour. It's a rather long & conservative process, but it will be ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 17:00:12 2016 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 06 Jun 2016 21:00:12 +0000 Subject: [issue27243] __aiter__ should return async iterator instead of awaitable In-Reply-To: <1465240896.52.0.994549894653.issue27243@psf.upfronthosting.co.za> Message-ID: <1465246812.26.0.406531353045.issue27243@psf.upfronthosting.co.za> Yury Selivanov added the comment: It's a rather long & conservative process, but it will be easier for people to migrate their code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 17:26:57 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 06 Jun 2016 21:26:57 +0000 Subject: [issue27243] __aiter__ should return async iterator instead of awaitable In-Reply-To: <1465246812.26.0.406531353045.issue27243@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Unless Nick disagrees (or unless we can't figure out how to implement it) I think Yury's proposal makes sense. So if Larry is asking for my fiat, this is it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 17:41:56 2016 From: report at bugs.python.org (Brett Cannon) Date: Mon, 06 Jun 2016 21:41:56 +0000 Subject: [issue27238] Bare except: usages in turtle.py In-Reply-To: <1465173486.36.0.354067909151.issue27238@psf.upfronthosting.co.za> Message-ID: <1465249316.62.0.169036753725.issue27238@psf.upfronthosting.co.za> Brett Cannon added the comment: __file__ could be None if __spec__.origin is None. The import machinery doesn't introspect on __file__ for anything, so it won't break import if __file__ has alternative values. In general, though, normal imports will set __file__ to a string. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 17:48:10 2016 From: report at bugs.python.org (Larry Hastings) Date: Mon, 06 Jun 2016 21:48:10 +0000 Subject: [issue27243] __aiter__ should return async iterator instead of awaitable In-Reply-To: <1465240896.52.0.994549894653.issue27243@psf.upfronthosting.co.za> Message-ID: <1465249690.93.0.406134011731.issue27243@psf.upfronthosting.co.za> Larry Hastings added the comment: Okay. I'm hoping to not delay 3.5.2 RC1, and the schedule calls for me to tag the release Saturday afternoon. Can you guys get this solid and checked in before then? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 18:02:59 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 06 Jun 2016 22:02:59 +0000 Subject: [issue27239] Make idlelib.macosx self-contained. In-Reply-To: <1465181854.1.0.00138868755932.issue27239@psf.upfronthosting.co.za> Message-ID: <1465250579.66.0.789651552502.issue27239@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Here is a post-import patch with tests. ---------- keywords: +patch stage: test needed -> patch review Added file: http://bugs.python.org/file43266/macosx-contained.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 18:04:23 2016 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 06 Jun 2016 22:04:23 +0000 Subject: [issue27243] __aiter__ should return async iterator instead of awaitable In-Reply-To: <1465240896.52.0.994549894653.issue27243@psf.upfronthosting.co.za> Message-ID: <1465250663.6.0.639433806364.issue27243@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Can you guys get this solid and checked in before then? Will do my best. I'll update the patch soon with some code comments and docs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 18:16:22 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 06 Jun 2016 22:16:22 +0000 Subject: [issue20210] Provide configure options to enable/disable Python modules and extensions In-Reply-To: <1389307962.8.0.973949637829.issue20210@psf.upfronthosting.co.za> Message-ID: <1465251382.66.0.6057328374.issue20210@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Just found this ticket and apparently late to the game... Some comments: It is already possible to selectively build Python C extension modules in the stdlib via editing the Modules/Setup file and this is a lot better to maintain than a long list of configure options. Martin's suggestion to add support for a *disabled* option would make this even easier. This would also complement the *static* and *shared* option we have for Modules/Setup to define modules to compile into the main executable rather than as shared module. The only bit that's missing (if really needed), is to prevent setup.py from building modules not listed in Modules/Setup as shared libs. This could be had with a single configure option, e.g. --disable-setuppy-builds. But all that said, I don't think, it's really necessary to cripple Python just to save some image space. As you can see with our eGenix PyRun runtime, it is possible to compress Python down to just a few MBs: http://www.egenix.com/products/python/PyRun/ while still having most of the stdlib readily available. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 18:22:25 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 06 Jun 2016 22:22:25 +0000 Subject: [issue27242] Clarify the use cases of NotImplemented in the docs In-Reply-To: <1465239567.69.0.773832868585.issue27242@psf.upfronthosting.co.za> Message-ID: <1465251744.99.0.834303108066.issue27242@psf.upfronthosting.co.za> Guido van Rossum added the comment: LGTM ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 18:31:53 2016 From: report at bugs.python.org (Ethan Furman) Date: Mon, 06 Jun 2016 22:31:53 +0000 Subject: [issue27242] Clarify the use cases of NotImplemented in the docs In-Reply-To: <1465239567.69.0.773832868585.issue27242@psf.upfronthosting.co.za> Message-ID: <1465252313.37.0.946534412232.issue27242@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 18:44:37 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 06 Jun 2016 22:44:37 +0000 Subject: [issue27242] Clarify the use cases of NotImplemented in the docs In-Reply-To: <1465239567.69.0.773832868585.issue27242@psf.upfronthosting.co.za> Message-ID: <1465253077.71.0.370645344613.issue27242@psf.upfronthosting.co.za> Raymond Hettinger added the comment: It would be nice to also clarify and differentiate NotImplementedError as well. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 18:57:03 2016 From: report at bugs.python.org (Brett Cannon) Date: Mon, 06 Jun 2016 22:57:03 +0000 Subject: [issue26467] Add async magic method support to unittest.mock.Mock In-Reply-To: <1456872706.59.0.97059255221.issue26467@psf.upfronthosting.co.za> Message-ID: <1465253823.66.0.505255989918.issue26467@psf.upfronthosting.co.za> Brett Cannon added the comment: There's also __aiter__, but it's semantics might be changing (issue #27243). Robert or Michael, any opinions on Yusuke's proposal? ---------- nosy: +rbcollins _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 18:58:56 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Jun 2016 22:58:56 +0000 Subject: [issue27243] __aiter__ should return async iterator instead of awaitable In-Reply-To: <1465240896.52.0.994549894653.issue27243@psf.upfronthosting.co.za> Message-ID: <1465253936.73.0.478774755821.issue27243@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: -haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 19:13:40 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 06 Jun 2016 23:13:40 +0000 Subject: [issue27238] Bare except: usages in turtle.py In-Reply-To: <1465173486.36.0.354067909151.issue27238@psf.upfronthosting.co.za> Message-ID: <1465254820.79.0.636975880792.issue27238@psf.upfronthosting.co.za> Martin Panter added the comment: The documentation says __file__ can be missing. It is missing for builtin modules (e.g. sys) and frozen modules (e.g. __hello__). ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 19:32:39 2016 From: report at bugs.python.org (Colm Buckley) Date: Mon, 06 Jun 2016 23:32:39 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465255959.87.0.179486431962.issue26839@psf.upfronthosting.co.za> Colm Buckley added the comment: @larry Short version; I'm not set up on HG and don't have enough time to get there from here. The patch I submitted applies cleanly to the HG tip as of 15 minutes ago (rev 101768) with only offset changes; the attached v4 version includes the necessary offset changes. ---------- Added file: http://bugs.python.org/file43267/getrandom_nonblocking_v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 20:25:36 2016 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 07 Jun 2016 00:25:36 +0000 Subject: [issue27243] __aiter__ should return async iterator instead of awaitable In-Reply-To: <1465240896.52.0.994549894653.issue27243@psf.upfronthosting.co.za> Message-ID: <1465259136.01.0.485706628322.issue27243@psf.upfronthosting.co.za> Yury Selivanov added the comment: Updated patch (fix_aiter2.patch) ---------- Added file: http://bugs.python.org/file43268/fix_aiter2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 20:34:47 2016 From: report at bugs.python.org (Dave Sawyer) Date: Tue, 07 Jun 2016 00:34:47 +0000 Subject: [issue27188] sqlite3 execute* methods return value not documented In-Reply-To: <1464904414.88.0.548243958784.issue27188@psf.upfronthosting.co.za> Message-ID: <1465259687.41.0.911358865173.issue27188@psf.upfronthosting.co.za> Dave Sawyer added the comment: Updated optional parameters. Fixed executescript which takes a single parameter. The English is correct - one needs to looks at the verbs to be sure they match in tense and number. Like "He OPENS the fridge, GRABS the milk, and DRINKS it." This method CREATES a cursor, CALLS the method, and RETURNS the cursor. ---------- Added file: http://bugs.python.org/file43269/issue27188_patch2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 20:39:58 2016 From: report at bugs.python.org (Dave Sawyer) Date: Tue, 07 Jun 2016 00:39:58 +0000 Subject: [issue27188] sqlite3 execute* methods return value not documented In-Reply-To: <1465108498.46.0.798988647899.issue27188@psf.upfronthosting.co.za> Message-ID: Dave Sawyer added the comment: No problem. I did a pull and reposted with additional fixes suggested by Berker and one copy/paste error I spotted. On Sat, Jun 4, 2016 at 11:34 PM, SilentGhost wrote: > > SilentGhost added the comment: > > Thanks for the patch, Dave. For whatever reason it doesn't seem to apply > cleanly to the current tip, would you mind preparing a new patch that does? > > ---------- > assignee: -> docs at python > components: +Documentation > nosy: +SilentGhost, berker.peksag, docs at python, ghaering > stage: -> patch review > type: enhancement -> behavior > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 20:44:46 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 07 Jun 2016 00:44:46 +0000 Subject: [issue27099] IDLE: turn builting extensions into regular modules In-Reply-To: <1464055360.13.0.626532918919.issue27099@psf.upfronthosting.co.za> Message-ID: <1465260286.1.0.134543660581.issue27099@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The final paragraph of my initial post should have talked about config-main and features, rather than keys. The following experiment indicates that adding new sections to config-main.def and customizations thereof to config-main.cfg should not be a problem. Add the following to config-main.cfg [NewSection] new = True Open IDLE 2.7 from console (python, with import). Open config dialog. Change item. Close with [OK] confirm that change is written and new section is left alone. Close IDLE. Repeat with 3.5. Old versions will not see new config-main.def, so that is not an issue. Conclusion: adding a new section that old versions ignore is much safer then adding a new value for a current section&item that old versions do read and act on, and which may refer to something that does not exist. (This was the problem with IDLE Dark theme and would be with Unix New keyset). The remaining issues: 4. Finding a place on the dialog itself for new customization widgets. On Font, Theme, and General tabs, there is space available either now or with some changes. The dialog can be enlarged if needed. 5. Adding the behind-the-scenes plumbing. This is mostly straightforward. 6. Doing minimal refactoring to make better testing easier. That would include being able to patch in a .idlerc directory or individual user files. The files are small and could easily fit in memory as StringIOs. I would like to be able to set user files, open config and idleConf, open config dialog, simulate user actions on the dialog, close, and check the effect on the files. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 20:45:39 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Jun 2016 00:45:39 +0000 Subject: [issue27229] In tree cross-build fails copying Include/graminit.h to itself In-Reply-To: <1465131940.98.0.80292566271.issue27229@psf.upfronthosting.co.za> Message-ID: <20160607004535.83562.65840.CFDD531E@psf.io> Roundup Robot added the comment: New changeset 619f7a2aa40a by Martin Panter in branch '3.5': Issue #27229: Fix in-tree cross-build rule, by Xavier de Gaye https://hg.python.org/cpython/rev/619f7a2aa40a New changeset 9902230b101f by Martin Panter in branch 'default': Issue #27229: Merge cross-compiling fix from 3.5 https://hg.python.org/cpython/rev/9902230b101f New changeset ffed402528c7 by Martin Panter in branch '2.7': Issue #27229: Fix in-tree cross-build rule, by Xavier de Gaye https://hg.python.org/cpython/rev/ffed402528c7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 20:50:03 2016 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 07 Jun 2016 00:50:03 +0000 Subject: [issue27243] __aiter__ should return async iterator instead of awaitable In-Reply-To: <1465240896.52.0.994549894653.issue27243@psf.upfronthosting.co.za> Message-ID: <1465260603.32.0.730535508628.issue27243@psf.upfronthosting.co.za> Nick Coghlan added the comment: Yury's proposal sounds good to me - I'll have time to do a proper review tomorrow (at a quick glance, my one suggestion is to move the if statement outside the example decorator, so the decorator is defined differently based on the Python version, rather than checking the version when called) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 20:50:08 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 07 Jun 2016 00:50:08 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1465260608.63.0.691434944538.issue5124@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I can't test but I looked at the patch. It uses the new-to-me fact that bound 'functions' can be tcl code in a string. For me, root.bind_class('Text', '<>') returns the code string '\n tk_textPaste %W\n'. Options for the patch: 0. Do nothing. 1. 3.6 as option (default TBD). 2. 3.6 as fixed change. 3. All versions as option (default TBD). 4. All versions as fixed change. I have determined that adding new sections to config-main does not affect previous releases, so 1 and 3 are possible. See the post I just made to #27099 as to what is needed for new options. For 1 and 3, there is the question of default - 'insert' versus 'replace', and for 3, whether it should be the same in all versions. I don't think 'insert' and the option should stay around forever. The question we need to think about is what would be best for beginners. The young but experienced Widows user, new to Linux, reported this to me as a bug that tripped her up a lot. Serhiy, I think that this change, at least as an option, should be in tkinter, so as to make it more 'cross-platform'. In the meantime, I will look at including this with the changes in #20799. I am thinking about posting to python-ideas for other opinions on what to do in which package. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 21:11:50 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Jun 2016 01:11:50 +0000 Subject: [issue27229] In tree cross-build fails copying Include/graminit.h to itself In-Reply-To: <1465131940.98.0.80292566271.issue27229@psf.upfronthosting.co.za> Message-ID: <20160607011146.38497.84665.1AF2BAE1@psf.io> Roundup Robot added the comment: New changeset ec214654708f by Martin Panter in branch '2.7': Issue #27229: Comment in middle of shell command fails on BSD and OS X https://hg.python.org/cpython/rev/ec214654708f New changeset de5b85f96266 by Martin Panter in branch '3.5': Issue #27229: Comment in middle of shell command fails on BSD and OS X https://hg.python.org/cpython/rev/de5b85f96266 New changeset b7a4c076ba40 by Martin Panter in branch 'default': Issue #27229: Merge makefile fix from 3.5 https://hg.python.org/cpython/rev/b7a4c076ba40 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 21:40:32 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 07 Jun 2016 01:40:32 +0000 Subject: [issue27245] IDLE: Fix deletion of custom themes and key bindings Message-ID: <1465263632.45.0.499678988052.issue27245@psf.upfronthosting.co.za> New submission from Terry J. Reedy: Open IDLE by running from console or importing idlelib.idle in interactive Python window. In the IDLE Preferences dialog, create a new custom theme or key set. [Apply] or close with [OK]. Reopen, if necessary, select the new custom set as current, select Delete, and Apply or close. IDLE will delete the set and then try to read it. A warning message will appear in the console/interpreter for each item in the set that is had to replace with the default value. IDLE should replace the deleted set with one of the builtins before reading, or even better, allow and require deletion of something that is not current. ---------- messages: 267580 nosy: terry.reedy priority: normal severity: normal stage: test needed status: open title: IDLE: Fix deletion of custom themes and key bindings type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 21:51:17 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 07 Jun 2016 01:51:17 +0000 Subject: [issue27173] Modern Unix key bindings for IDLE In-Reply-To: <1464766185.36.0.150155479026.issue27173@psf.upfronthosting.co.za> Message-ID: <1465264277.94.0.411659394078.issue27173@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I looked at _set3 and it looks plausible and possibly complete other than testing. I added something about testing customizations to #27099. This applied cleanly to 3.6. 3.6 started, dialog opened, new key set selected, dialog closed, config-main.cfg looks good. Open dialog, same as custom, close dialog, config-keys and config main changed as expected. Open 3.5, open dialog, everything looks fine. Now the problems. 1. To delete, one must select as current. After deletion, config tries to reread the keyset just deleted. This prints a warning to console for each item in the set, with message as to default used instead. The same happens with deleting custom themes. I may have noted this somewhere, but cannot find. In any case, the solution for both problems is to either allow deletion of non-selected sets, and only such, or to switch to *something* before re-reading. I open a new issue, #27245, for this. 2. More serious, the warnigs are followed by Exception in Tkinter callback Traceback (most recent call last): File "F:\Python\dev\35\lib\tkinter\__init__.py", line 1550, in __call__ return self.func(*args) File "F:\Python\dev\35\lib\idlelib\configDialog.py", line 1182, in Ok self.Apply() File "F:\Python\dev\35\lib\idlelib\configDialog.py", line 1186, in Apply self.DeactivateCurrentConfig() File "F:\Python\dev\35\lib\idlelib\configDialog.py", line 1166, in DeactivateCurrentConfig instance.RemoveKeybindings() File "F:\Python\dev\35\lib\idlelib\EditorWindow.py", line 771, in RemoveKeybindings self.text.event_delete(event, *keylist) File "F:\Python\dev\35\lib\idlelib\MultiCall.py", line 391, in event_delete self.__binders[triplet[1]].unbind(triplet, func) File "F:\Python\dev\35\lib\idlelib\MultiCall.py", line 234, in unbind doit() File "F:\Python\dev\35\lib\idlelib\MultiCall.py", line 232, in doit = lambda: self.bindedfuncs[triplet[2]][triplet[0]].remove(func) ValueError: list.remove(x): x not in list Hitting OK repeats warnings and traceback (the last line might have been a bit different the first time). Only Cancel would close. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 21:56:28 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 07 Jun 2016 01:56:28 +0000 Subject: [issue7949] IDLE: problems with dark GTK or KDE color schemes In-Reply-To: <1266372113.11.0.0197701157976.issue7949@psf.upfronthosting.co.za> Message-ID: <1465264588.85.0.922921363569.issue7949@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Use of ttk got delayed for back-compatibility issues. We should be clear to start in a week. ---------- versions: -Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 22:38:19 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 07 Jun 2016 02:38:19 +0000 Subject: [issue19234] socket.fileno() documentation In-Reply-To: <52597A2F.60807@python.org> Message-ID: <1465267099.97.0.265316617598.issue19234@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 6 23:55:39 2016 From: report at bugs.python.org (Demur Rumed) Date: Tue, 07 Jun 2016 03:55:39 +0000 Subject: [issue27127] Never have GET_ITER not followed by FOR_ITER In-Reply-To: <1464227064.89.0.81963094053.issue27127@psf.upfronthosting.co.za> Message-ID: <1465271739.5.0.938317507323.issue27127@psf.upfronthosting.co.za> Demur Rumed added the comment: Attached is a patch which fixes test_sys_settrace & test_pdb & test_trace. Still failing is test_genexps. I'm unsure the best way to fix this one: 1. Allow generator expressions to defer type errors about non iterables until the initial call to next 2. Create a TEST_ITER opcode entirely for generator expressions to eagerly throw 3. Generate instructions like FOR_BEGIN, if empty, jump over generator & put an empty generator on the stack -> CALL_FUNCTION 2, have generator produce code as LOAD_FAST 0, LOAD_FAST 1, , FOR_ITER repeat (ie translate stack of FOR_BEGIN from before call as header of generator) Empty generator can be created with 'LOAD_CONST (None,), FOR_BEGIN, POP' but it seems rather bad to have generators require 3 more opcodes around their creation than currently ---------- Added file: http://bugs.python.org/file43270/forbegin2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 00:05:30 2016 From: report at bugs.python.org (Demur Rumed) Date: Tue, 07 Jun 2016 04:05:30 +0000 Subject: [issue27127] Never have GET_ITER not followed by FOR_ITER In-Reply-To: <1464227064.89.0.81963094053.issue27127@psf.upfronthosting.co.za> Message-ID: <1465272330.74.0.991404895266.issue27127@psf.upfronthosting.co.za> Changes by Demur Rumed : Removed file: http://bugs.python.org/file43270/forbegin2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 00:05:40 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 07 Jun 2016 04:05:40 +0000 Subject: [issue27227] argparse fails to parse [] when using choices and nargs='*' In-Reply-To: <1465117156.8.0.428303445441.issue27227@psf.upfronthosting.co.za> Message-ID: <1465272340.88.0.58940744988.issue27227@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: -> needs patch versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 00:06:29 2016 From: report at bugs.python.org (Demur Rumed) Date: Tue, 07 Jun 2016 04:06:29 +0000 Subject: [issue27127] Never have GET_ITER not followed by FOR_ITER In-Reply-To: <1464227064.89.0.81963094053.issue27127@psf.upfronthosting.co.za> Message-ID: <1465272389.0.0.57653640461.issue27127@psf.upfronthosting.co.za> Changes by Demur Rumed : Added file: http://bugs.python.org/file43271/forbegin2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 00:13:06 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jun 2016 04:13:06 +0000 Subject: [issue27127] Never have GET_ITER not followed by FOR_ITER In-Reply-To: <1464227064.89.0.81963094053.issue27127@psf.upfronthosting.co.za> Message-ID: <1465272786.82.0.88844625099.issue27127@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What if generate following code? GET_ITER JUMP_FORWARD L2 L1: # ... L2: FOR_ITER L1 This saves one jump instruction per iteration. Next, we can merge GET_ITER+JUMP_FORWARD in one FOR_BEGIN instruction for regular loops. Generators will start with JUMP_FORWARD. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 00:21:00 2016 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 07 Jun 2016 04:21:00 +0000 Subject: [issue26415] Fragmentation of the heap memory in the Python parser In-Reply-To: <1456182380.09.0.81920177296.issue26415@psf.upfronthosting.co.za> Message-ID: <1465273260.49.0.676538508586.issue26415@psf.upfronthosting.co.za> Benjamin Peterson added the comment: It seems to me a simpler solution would be allocate all nodes for a parse tree in an arena. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 00:24:03 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jun 2016 04:24:03 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1465273443.23.0.796469004479.issue5124@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think it is better to fix this in all versions unconditionally. This simple workaround is good enough for IDLE, but if add it as a part of Tkinter, it should be much more complex. I prefer to provide this as a recipe at http://code.activestate.com/recipes/langs/python/ . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 00:31:35 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jun 2016 04:31:35 +0000 Subject: [issue27173] Modern Unix key bindings for IDLE In-Reply-To: <1464766185.36.0.150155479026.issue27173@psf.upfronthosting.co.za> Message-ID: <1465273895.17.0.172971317941.issue27173@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'm aware of the bug with deleting current key set. idle_modern_unix_key_set3.patch effectively fixes it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 00:35:34 2016 From: report at bugs.python.org (Emanuel Barry) Date: Tue, 07 Jun 2016 04:35:34 +0000 Subject: [issue27242] Make the docs for NotImplemented & NotImplementedError unambigous In-Reply-To: <1465239567.69.0.773832868585.issue27242@psf.upfronthosting.co.za> Message-ID: <1465274134.52.0.714413325106.issue27242@psf.upfronthosting.co.za> Emanuel Barry added the comment: Added further notes to `NotImplemented` and `NotImplementedError` to clearly state the differences between the two. I also added some more details to `TypeError` - I'm amazed at how little was described for such a common exception! Maybe I explained a bit too thoroughly in some parts, but I like to have everything unambigous and well explained. I haven't yet spent the time to learn how to build documentation (Soon?), so I'm going off the existing docs, and I try to follow the style as closely as possible. ---------- title: Clarify the use cases of NotImplemented in the docs -> Make the docs for NotImplemented & NotImplementedError unambigous Added file: http://bugs.python.org/file43272/NotImplemented_exceptions_wording_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 00:37:41 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jun 2016 04:37:41 +0000 Subject: [issue27173] Modern Unix key bindings for IDLE In-Reply-To: <1464766185.36.0.150155479026.issue27173@psf.upfronthosting.co.za> Message-ID: <1465274261.42.0.879584894952.issue27173@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: After applying this patch I'm going to redesign Highlighting and Keys tabs in the Settings dialog. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 00:39:43 2016 From: report at bugs.python.org (Harrison Chudleigh) Date: Tue, 07 Jun 2016 04:39:43 +0000 Subject: [issue27246] Keyboard Shortcuts Crash Idle Message-ID: <1465274383.08.0.0475025936215.issue27246@psf.upfronthosting.co.za> New submission from Harrison Chudleigh: When pressing Alt-E, Alt-I, Alt-N and Alt-U to create special characters in IDLE (the diacritics ?,?,?and?) the program crashed. ---------- components: IDLE messages: 267590 nosy: Harrison Chudleigh priority: normal severity: normal status: open title: Keyboard Shortcuts Crash Idle type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 00:46:02 2016 From: report at bugs.python.org (Emanuel Barry) Date: Tue, 07 Jun 2016 04:46:02 +0000 Subject: [issue27246] Keyboard Shortcuts Crash Idle In-Reply-To: <1465274383.08.0.0475025936215.issue27246@psf.upfronthosting.co.za> Message-ID: <1465274762.76.0.866116393962.issue27246@psf.upfronthosting.co.za> Emanuel Barry added the comment: Your report was already addressed in #27192, and the solution to your problem was given by Ned Deily. If you are still experiencing crashes with the official python.org version, please specify so. In the meantime, I'm closing this off as duplicate. ---------- nosy: +ebarry resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Keyboard Shortcuts Consistently Cause Crashes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 00:54:39 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jun 2016 04:54:39 +0000 Subject: [issue27238] Bare except: usages in turtle.py In-Reply-To: <1465173486.36.0.354067909151.issue27238@psf.upfronthosting.co.za> Message-ID: <1465275279.27.0.577727299593.issue27238@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Brett and Martin. Jelle, I think it would be safer to use "except Exception" here. "except (TypeError, ValueError):" is not enough. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 01:15:45 2016 From: report at bugs.python.org (Emanuel Barry) Date: Tue, 07 Jun 2016 05:15:45 +0000 Subject: [issue27242] Make the docs for NotImplemented & NotImplementedError unambigous In-Reply-To: <1465239567.69.0.773832868585.issue27242@psf.upfronthosting.co.za> Message-ID: <1465276545.65.0.995340914626.issue27242@psf.upfronthosting.co.za> Emanuel Barry added the comment: New patch with small tweaks. Thanks Jelle for the comments! ---------- Added file: http://bugs.python.org/file43273/NotImplemented_exceptions_wording_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 01:51:01 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 07 Jun 2016 05:51:01 +0000 Subject: [issue27173] Modern Unix key bindings for IDLE In-Reply-To: <1464766185.36.0.150155479026.issue27173@psf.upfronthosting.co.za> Message-ID: <1465278661.79.0.402170274963.issue27173@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I don't understand > idle_modern_unix_key_set3.patch effectively fixes [the bug]. That is the patch that generated the exception I posted. I look forward to contributions to improving the dialog. Redoing the font tab is #24776. The highlight tab is #24781. The latest mockups look like improvements to me, but we can discuss further. (#24781 also has Mark's proposed refactoring of the dialog code, but I have not reviewed in detail.) There are numerous issues connected with key definitions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 01:53:57 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 07 Jun 2016 05:53:57 +0000 Subject: [issue24810] UX mode for IDLE targeted to 'new learners' In-Reply-To: <1438874369.3.0.632862170315.issue24810@psf.upfronthosting.co.za> Message-ID: <1465278837.14.0.315390894318.issue24810@psf.upfronthosting.co.za> Terry J. Reedy added the comment: This is not going to go anywhere for the present. ---------- assignee: -> terry.reedy resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 02:16:33 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jun 2016 06:16:33 +0000 Subject: [issue27173] Modern Unix key bindings for IDLE In-Reply-To: <1464766185.36.0.150155479026.issue27173@psf.upfronthosting.co.za> Message-ID: <1465280193.01.0.209789944429.issue27173@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Interesting, I was not able to reproduce a bug if just save as custom theme and apply, but after creating and deleting the second custom theme I got a mystical behavior of IDLE -- radiobuttons are not consistent with comboboxes, OK can't be pressed, etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 02:20:14 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 07 Jun 2016 06:20:14 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1465280414.61.0.716316602038.issue5124@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I presume you mean option 4. I understand this to be what David and others expected. Ned, what do you think now? You were opposed 3 years ago, but we have a bit more evidence that the current behavior is out of whack with current Linux practice. Should I ask for for linux experiences and opinions on python-ideas? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 02:25:15 2016 From: report at bugs.python.org (spoo) Date: Tue, 07 Jun 2016 06:25:15 +0000 Subject: [issue26293] Embedded zipfile fields dependent on absolute position In-Reply-To: <1464956825.14.0.467157196361.issue26293@psf.upfronthosting.co.za> Message-ID: <62931b80-c9af-af58-ed34-08e18d3518ea@zarbosoft.com> spoo added the comment: Thank you for looking into this! I don't have my tablet to test with at the moment, but testing locally with zipinfo there used to be a warning about missing bytes and now there is none. I will test with the tablet in a week or two when I get it back. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 02:41:23 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 07 Jun 2016 06:41:23 +0000 Subject: [issue27229] In tree cross-build fails copying Include/graminit.h to itself In-Reply-To: <1465131940.98.0.80292566271.issue27229@psf.upfronthosting.co.za> Message-ID: <1465281683.79.0.68079643075.issue27229@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks Alex & Xavier. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 02:54:03 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jun 2016 06:54:03 +0000 Subject: [issue27173] Modern Unix key bindings for IDLE In-Reply-To: <1464766185.36.0.150155479026.issue27173@psf.upfronthosting.co.za> Message-ID: <1465282443.97.0.959122682125.issue27173@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There was a bug, saving custom key set didn't have any effect if previous key set was IDLE Modern Unix. ---------- Added file: http://bugs.python.org/file43274/idle_modern_unix_key_set4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 02:59:47 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jun 2016 06:59:47 +0000 Subject: [issue27245] IDLE: Fix deletion of custom themes and key bindings In-Reply-To: <1465263632.45.0.499678988052.issue27245@psf.upfronthosting.co.za> Message-ID: <1465282787.46.0.224197859066.issue27245@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Proposed patch should fix this issue. ---------- components: +IDLE keywords: +patch nosy: +serhiy.storchaka stage: test needed -> patch review versions: +Python 2.7, Python 3.5 Added file: http://bugs.python.org/file43275/idle_delete_current_theme.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 03:01:24 2016 From: report at bugs.python.org (A. Skrobov) Date: Tue, 07 Jun 2016 07:01:24 +0000 Subject: [issue26415] Fragmentation of the heap memory in the Python parser In-Reply-To: <1456182380.09.0.81920177296.issue26415@psf.upfronthosting.co.za> Message-ID: <1465282884.78.0.241834960158.issue26415@psf.upfronthosting.co.za> A. Skrobov added the comment: An arena might help reclaim the memory once the parsing is complete, but it wouldn't reduce the peak memory consumption by the parser, and so it wouldn't prevent a MemoryError when parsing a 35MB source on a PC with 2GB of RAM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 03:35:38 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 07 Jun 2016 07:35:38 +0000 Subject: [issue27221] multiprocessing documentation is outdated regarding method picklability In-Reply-To: <1465069362.83.0.142351405451.issue27221@psf.upfronthosting.co.za> Message-ID: <1465284938.58.0.157989219189.issue27221@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: -> patch review title: [multiprocessing] Doc is outdated regarding method picklability -> multiprocessing documentation is outdated regarding method picklability type: -> behavior versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 03:39:49 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 07 Jun 2016 07:39:49 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1465285189.73.0.315581577087.issue27186@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: test needed -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 04:24:36 2016 From: report at bugs.python.org (Muhammad Toufeeq Ockards) Date: Tue, 07 Jun 2016 08:24:36 +0000 Subject: [issue27247] telnetlib AttributeError: 'error' object has no attribute 'errno' (handling of select.error) Message-ID: <1465287876.51.0.228447119579.issue27247@psf.upfronthosting.co.za> New submission from Muhammad Toufeeq Ockards: I was using the telnetlib on linux in python 2.7 and ran into error that executed line 320 of https://hg.python.org/cpython/file/2.7/Lib/telnetlib.py ---------------------------------- 319: except select.error as e: 320: if e.errno == errno.EINTR: ------------------------------------ Inspecting select.error showed that it has no errno attribute. I opened up a python2.7 idle session on my computer and entered the following. --------------------------------------------------------- >>> import select >>> try: ... raise select.error ... except Exception as e: ... pass ... >>> e error() >>> dir(e) ['__class__', '__delattr__', '__dict__', '__doc__', '__format__', '__getattribute__', '__getitem__', '__getslice__', '__hash__', '__init__', '__module__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__setstate__', '__sizeof__', '__str__', '__subclasshook__', '__unicode__', '__weakref__', 'args', 'message'] >>> e.errno Traceback (most recent call last): File "", line 1, in AttributeError: 'error' object has no attribute 'errno' >>> ------------------------------------------------------------- ---------- components: Library (Lib) messages: 267603 nosy: Muhammad Toufeeq Ockards priority: normal severity: normal status: open title: telnetlib AttributeError: 'error' object has no attribute 'errno' (handling of select.error) type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 05:05:35 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 07 Jun 2016 09:05:35 +0000 Subject: [issue27247] telnetlib AttributeError: 'error' object has no attribute 'errno' (handling of select.error) In-Reply-To: <1465287876.51.0.228447119579.issue27247@psf.upfronthosting.co.za> Message-ID: <1465290335.81.0.431825145663.issue27247@psf.upfronthosting.co.za> Xiang Zhang added the comment: In py2, select.error is a stand alone exception while in py3 it's an alias of OSError. This difference seems not noticed when introduced in 872afada51b0. ---------- nosy: +gregory.p.smith, xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 05:18:15 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jun 2016 09:18:15 +0000 Subject: [issue23264] Add pickle support of dict views In-Reply-To: <1421568716.9.0.947546089999.issue23264@psf.upfronthosting.co.za> Message-ID: <1465291095.81.0.229697983037.issue23264@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your attention Guido. ---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 05:23:09 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jun 2016 09:23:09 +0000 Subject: [issue23401] Add pickle support of Mapping views In-Reply-To: <1423216735.87.0.773240969368.issue23401@psf.upfronthosting.co.za> Message-ID: <1465291389.3.0.736035584608.issue23401@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Should we forbid pickling MappingView? And what about copying and deepcopying? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 05:27:24 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 07 Jun 2016 09:27:24 +0000 Subject: [issue27248] Possible refleaks in PyType_Ready in error condition Message-ID: <1465291644.02.0.339755831898.issue27248@psf.upfronthosting.co.za> New submission from Xiang Zhang: As the title, in add_* used in PyType_Ready, the reference counts are not decreased when adding them to dict fails. ---------- files: refleak_in_pytype_ready.patch keywords: patch messages: 267607 nosy: serhiy.storchaka, xiang.zhang priority: normal severity: normal status: open title: Possible refleaks in PyType_Ready in error condition Added file: http://bugs.python.org/file43276/refleak_in_pytype_ready.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 05:27:24 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Jun 2016 09:27:24 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <20160607092719.38423.66471.78E6CB7E@psf.io> Roundup Robot added the comment: New changeset 9de508dc4837 by Victor Stinner in branch '3.5': os.urandom() doesn't block on Linux anymore https://hg.python.org/cpython/rev/9de508dc4837 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 05:39:57 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Jun 2016 09:39:57 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465292397.35.0.254476882747.issue26839@psf.upfronthosting.co.za> STINNER Victor added the comment: Sorry for the delay. getrandom_nonblocking_v4.patch LGTM, but I made a major change: if getrandom() fails with EAGAIN, it now *always* fall back on reading /dev/urandom. I also documented the change in os.urandom() documentation and in Misc/NEWS. I pushed the fix to Python 3.5 and 3.6. Python 2.7 doesn't use getrandom() and so doesn't need the fix. I now consider that the bug is fixed. If you consider that it's important enough to retry calling getrandom() each time os.urandom() is called, please open a new issue with a patch and elaborate your rationale :-) ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 05:40:22 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Jun 2016 09:40:22 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465292422.97.0.192389695564.issue26839@psf.upfronthosting.co.za> STINNER Victor added the comment: Manual check to ensure that getrandom() syscall is used on Linux: $ strace -o trace ./python -c 'import os; os.urandom(16); os.urandom(16)' && grep getrandom trace getrandom("...", 24, GRND_NONBLOCK) = 24 getrandom("...", 16, GRND_NONBLOCK) = 16 getrandom("...", 16, GRND_NONBLOCK) = 16 The first read of 24 bytes is to initialize the randomized hash function. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 05:55:53 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Jun 2016 09:55:53 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465293353.21.0.00592438437705.issue26839@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm the author of the os.urandom() change which introduced the usage of the new getrandom() syscall: see the issue #22181. My motivation was to avoid the internal file descriptor to read /dev/urandom. In some corner cases (issue #18756), creating a file descriptor fails with EMFILE. Python introduced a workaround keeping the file descriptor open (issue #18756), but this change introduced new issues (issue #21207)... When I modified os.urandom(), I was aware that getrandom() can block at startup, but I saw this feature as a good thing for Python. It doesn't seem like a good idea to generate low quality random numbers. I expected that such system *quickly* gets enough good entropy. With this issue, we now have more information: "quickly" means in fact longer than 1 minute! ("causing a 90-second boot delay", msg265477). Blocking Python startup longer than 1 minute just to get good quality random numbers doesn't seem worth it to me. It is clearly seen as a regression compared to Python 2 (which doesn't use getrandom() but reads /dev/urandom). I understand that the behaviour is also seen as a bug when compared to other programming languages or applications. For all these reasons, I pushed Colm's change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 06:01:16 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Jun 2016 10:01:16 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465293676.33.0.584066409322.issue26839@psf.upfronthosting.co.za> STINNER Victor added the comment: Colm Buckley: "I feel that there is no consistent way to signal to higher-level applications that the random data has sub-standard entropy; but that this at least preserves the expected semantics, and doesn't block on startup in the event of an uninitialized entropy pool." I chose to document the behaviour of os.urandom(). Stefan Krah (msg267539): "If admins wish, they can also integrate such checks into the system startup sequence (e.g. runlevel 3 is only reached if randomness is actually available)." Maybe need something like time.get_clock_info(), sys.float_info and sys.thread_info for os.urandom(): a string describing the implementation of os.urandom(). It would allow the developer to decide what to do when getrandom() is not used. Reminder: getrandom() feature is specific to Linux. I understand that all other operating systems don't warn if the urandom entropy pool is not initialized yet! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 06:03:34 2016 From: report at bugs.python.org (Susumu Koshiba) Date: Tue, 07 Jun 2016 10:03:34 +0000 Subject: [issue25738] http.server doesn't handle RESET CONTENT status correctly In-Reply-To: <1448583978.87.0.253695569638.issue25738@psf.upfronthosting.co.za> Message-ID: <1465293814.43.0.585041659902.issue25738@psf.upfronthosting.co.za> Susumu Koshiba added the comment: Thanks for the suggestions, I've updated the test cases and created a patch for 3.6. ---------- Added file: http://bugs.python.org/file43277/issue25738_http_reset_content_07.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 06:09:48 2016 From: report at bugs.python.org (Colm Buckley) Date: Tue, 07 Jun 2016 10:09:48 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465294188.93.0.518342330881.issue26839@psf.upfronthosting.co.za> Colm Buckley added the comment: @haypo - I concur with all of your comments. I didn't have a strong opinion on whether to modify getrandom_works; your proposal looks fine to me (and will give consistent behavior over the lifetime of the process). Thanks all for your help with this issue; much appreciated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 06:13:25 2016 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jun 2016 10:13:25 +0000 Subject: [issue27235] Heap overflow occurred due to the int overflow (Python-2.7.11/Modules/posixmodule.c) In-Reply-To: <1465149697.95.0.775433257828.issue27235@psf.upfronthosting.co.za> Message-ID: <1465294405.52.0.717820941329.issue27235@psf.upfronthosting.co.za> Larry Hastings added the comment: I agree with the previous comment author. Can you post a sample program that crashes Python? Please specify what platform you're running on. On 32-bit platforms, you'd be unable to construct even the first "r" * ((2**32)-1) string. That string would use 4GB of memory, and 32-bit platforms always reserve some virtual memory space for the OS. Even if you could construct the first one, you couldn't create the second one. mode would be NULL and the next line (which you didn't paste below) would notice the NULL and throw an exception. On 64-bit platforms, strlen() returns a 64-bit signed integer, and a string of length (2**32)-1 is no problem as long as you have enough memory. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 06:14:36 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Jun 2016 10:14:36 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465294476.28.0.138546142865.issue26839@psf.upfronthosting.co.za> STINNER Victor added the comment: Martin Panter (msg267504): "As I understand it, if there is no entropy initialized, this patch will fall back to reading /dev/urandom, which will return predictable data (opposite of ?random? data!)." No, I don't think so. Linux uses a lot of random sources, but some of them are seen as untrusted as so are added with a very low estimation of their entropy. Linux even adds some random values with a estimation of 0 bit of entropy. For example, drivers can add serial numbers as random numbers. So even if getrandom() blocks, if the urandom entropy pool is not considered as fully initialized yet, I expect that /dev/urandom still generates *random* numbers, even if these numbers are not suitable to generate cryptographic keys. Please double check, I'm not sure of what I wrote :-) See also http://www.2uo.de/myths-about-urandom/ (but this article doesn't describe how urandom is initialized). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 06:15:40 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Jun 2016 10:15:40 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465294540.67.0.112026096832.issue26839@psf.upfronthosting.co.za> STINNER Victor added the comment: Martin Panter (msg267511): "Maybe an alternative would be to add a special PYTHONHASHSEED=best-effort (or whatever) value that says if there is no entropy available, use a predictable hash seed. That would force whoever starts the Python process to be aware of the problem." In my experience, it's better if users don't touch security :-) It's better if Python simply makes the best choices regarding to security. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 06:16:51 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jun 2016 10:16:51 +0000 Subject: [issue27248] Possible refleaks in PyType_Ready in error condition In-Reply-To: <1465291644.02.0.339755831898.issue27248@psf.upfronthosting.co.za> Message-ID: <1465294611.54.0.870202521994.issue27248@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Interpreter Core stage: -> patch review type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 06:19:14 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Jun 2016 10:19:14 +0000 Subject: [issue26415] Fragmentation of the heap memory in the Python parser In-Reply-To: <1456182380.09.0.81920177296.issue26415@psf.upfronthosting.co.za> Message-ID: <1465294754.47.0.847635489272.issue26415@psf.upfronthosting.co.za> STINNER Victor added the comment: Benjamin Peterson: "It seems to me a simpler solution would be allocate all nodes for a parse tree in an arena." Exactly, that's the real fix. Just make sure that deallocating this arena does punch holes in the "heap memory". For example, on Linux, it means using mmap() rather than sbrk() to allocate memory. A. Skrobov: "An arena might help reclaim the memory once the parsing is complete, but it wouldn't reduce the peak memory consumption by the parser, and so it wouldn't prevent a MemoryError when parsing a 35MB source on a PC with 2GB of RAM." Parsing a 35 MB source doesn't seem like a good idea :-) I think that it's ok to have a memory peak, but it's not ok to not release the memory later. Do you have a solution avoid the memory peak *and* don't create memory fragmentation? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 06:26:32 2016 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jun 2016 10:26:32 +0000 Subject: [issue26556] Update expat to 2.2.1 In-Reply-To: <1457951495.3.0.910401967595.issue26556@psf.upfronthosting.co.za> Message-ID: <1465295192.3.0.0527566976439.issue26556@psf.upfronthosting.co.za> Larry Hastings added the comment: Was this critical bug fix released on May 17th as promised? I will not hold up 3.5.2 for this. 3.5.2 has waited long enough. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 06:37:35 2016 From: report at bugs.python.org (A. Skrobov) Date: Tue, 07 Jun 2016 10:37:35 +0000 Subject: [issue26415] Fragmentation of the heap memory in the Python parser In-Reply-To: <1456182380.09.0.81920177296.issue26415@psf.upfronthosting.co.za> Message-ID: <1465295855.6.0.544887076694.issue26415@psf.upfronthosting.co.za> A. Skrobov added the comment: My current patch avoids the memory peak *and* doesn't add any memory fragmentation on top of whatever is already there. In other words, it makes the parser better in this one aspect, and it doesn't make it worse in any aspect. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 06:44:50 2016 From: report at bugs.python.org (Stefan Krah) Date: Tue, 07 Jun 2016 10:44:50 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1465293676.33.0.584066409322.issue26839@psf.upfronthosting.co.za> Message-ID: <20160607104439.GA4914@bytereef.org> Stefan Krah added the comment: On Tue, Jun 07, 2016 at 10:01:16AM +0000, STINNER Victor wrote: > Maybe need something like time.get_clock_info(), sys.float_info and sys.thread_info for os.urandom(): a string describing the implementation of os.urandom(). It would allow the developer to decide what to do when getrandom() is not used. I think this is a very good idea. Just a flag for "cryptographically secure" or not. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 07:01:45 2016 From: report at bugs.python.org (A. Skrobov) Date: Tue, 07 Jun 2016 11:01:45 +0000 Subject: [issue26415] Excessive peak memory consumption by the Python parser In-Reply-To: <1456182380.09.0.81920177296.issue26415@psf.upfronthosting.co.za> Message-ID: <1465297305.64.0.944547958371.issue26415@psf.upfronthosting.co.za> A. Skrobov added the comment: (Updating the issue title, to avoid confusion between two orthogonal concerns) ---------- title: Fragmentation of the heap memory in the Python parser -> Excessive peak memory consumption by the Python parser _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 07:27:33 2016 From: report at bugs.python.org (Alex Gaynor) Date: Tue, 07 Jun 2016 11:27:33 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465298853.42.0.503828063338.issue26839@psf.upfronthosting.co.za> Alex Gaynor added the comment: This doesn't look correct to me. Despite what the Linux maintainers insist, it's a _bug_ that /dev/urandom will return immediately if the system's entropy pool has never been seeded; one of the whole points of the getrandom syscall is that it has the correct behavior (which is the same behavior as BSDs). IMO the patch landed this morning should be reverted and it should be left as is. ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 07:31:47 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 07 Jun 2016 11:31:47 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1465298853.42.0.503828063338.issue26839@psf.upfronthosting.co.za> Message-ID: <5756B09D.8020801@egenix.com> Marc-Andre Lemburg added the comment: On 07.06.2016 13:27, Alex Gaynor wrote: > > This doesn't look correct to me. Despite what the Linux maintainers insist, it's a _bug_ that /dev/urandom will return immediately if the system's entropy pool has never been seeded; one of the whole points of the getrandom syscall is that it has the correct behavior (which is the same behavior as BSDs). > > IMO the patch landed this morning should be reverted and it should be left as is. I'm with Victor and the others on this one. Practicality beats purity. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 07:32:00 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Jun 2016 11:32:00 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465299120.47.0.44577333573.issue26839@psf.upfronthosting.co.za> STINNER Victor added the comment: Alex: "IMO the patch landed this morning should be reverted and it should be left as is." Sorry, but you should elaborate a little bit more, see my rationale: https://bugs.python.org/issue26839#msg267611 There are multiple issues. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 07:34:35 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Jun 2016 11:34:35 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465299275.2.0.0393500228347.issue26839@psf.upfronthosting.co.za> STINNER Victor added the comment: Stefan Krah: "I think this is a very good idea. Just a flag for "cryptographically secure" or not." If you consider it is worth it, please open a new issue. I dislike the idea of a boolean. The quality of each system RNG has been discussed long enough to be able to say that "cryptographically secure" term depends a lot of your use case, and experts disagree between themself :-) You might even have to consider the version of the Linux kernel to decide if /dev/urandom is good enough or not for you use case. The implementation changed last years. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 07:35:49 2016 From: report at bugs.python.org (Cory Benfield) Date: Tue, 07 Jun 2016 11:35:49 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465299349.53.0.115853160881.issue26839@psf.upfronthosting.co.za> Cory Benfield added the comment: This patch explicitly violates several of the documented constraints of the Python standard library. For example, random.SystemRandom uses os.urandom to generate its random numbers. SystemRandom is then used by the secrets module to generate *its* random numbers. This means that os.urandom *is* explicitly used by the Python standard library to generate cryptographically secure random numbers. It was done so in part expressly because the call to random() could block. If Python needs a non-blocking RNG for internal purposes, that's totally fine, a new function should be written that does exactly that. But any code that is calling secrets or random.SystemRandom is expecting the documented guarantees of that module: that is, that the security profile of the random numbers generated by those objects are cryptographically secure. This patch ensures that that guarantee is *violated* on Linux systems run on cloud servers, which is more than a little alarming to me. ---------- nosy: +Lukasa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 07:36:17 2016 From: report at bugs.python.org (Donald Stufft) Date: Tue, 07 Jun 2016 11:36:17 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465299377.41.0.45258059526.issue26839@psf.upfronthosting.co.za> Donald Stufft added the comment: I agree with Alex here. The documentation of ``os.urandom`` states: Return a string of n random bytes suitable for cryptographic use. However the old behavior prior to using the ``getrandom()`` call and the behavior with this patch makes that documentation a lie. It's now a string of n random bytes that may or may not be suitable for cryptographic use, but we have no idea which one it is. No where in the documentation of ``os.urandom`` does it ever promise it will not block. In fact, on systems like FreeBSD where their /dev/urandom is better than Linuxes it always blocked on start up because that's just the way their /dev/urandom works. ---------- nosy: +dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 07:39:59 2016 From: report at bugs.python.org (Donald Stufft) Date: Tue, 07 Jun 2016 11:39:59 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465299599.06.0.643068404503.issue26839@psf.upfronthosting.co.za> Donald Stufft added the comment: I also agree with Cory :) If CPython needs a non blocking RNG for start up, then it should add a new function that does that, breaking the promise of ``os.urandom`` cryptographically suitable random is not the way to do that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 07:41:58 2016 From: report at bugs.python.org (Thomas Petazzoni) Date: Tue, 07 Jun 2016 11:41:58 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465299718.83.0.644384311139.issue26839@psf.upfronthosting.co.za> Thomas Petazzoni added the comment: The original problem is that Python wants to generate random numbers at *startup*. Are those random numbers really used for crypto-related activities? I doubt it. So isn't the proper solution to have two functions, one delivering random numbers that are usable for crypto-related activities, and which would potentially block, and a second one that delivers random numbers that are not appropriate for crypto stuff. This second function can be used at Python startup to replace what is done currently. It is most likely perfectly fine if Python blocks when explicitly asked to generate cryptographically secure random numbers. But not when simply starting the interpreter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 07:45:29 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 07 Jun 2016 11:45:29 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1465299377.41.0.45258059526.issue26839@psf.upfronthosting.co.za> Message-ID: <5756B3D3.3020609@egenix.com> Marc-Andre Lemburg added the comment: On 07.06.2016 13:36, Donald Stufft wrote: > No where in the documentation of ``os.urandom`` does it ever promise it will not block. In fact, on systems like FreeBSD where their /dev/urandom is better than Linuxes it always blocked on start up because that's just the way their /dev/urandom works. The whole purpose of urandom is to have a non-blocking source of random numbers: http://man7.org/linux/man-pages/man4/random.4.html and os.urandom() has always stated: "This function returns random bytes from an OS-specific randomness source. The returned data should be unpredictable enough for cryptographic applications, though its exact quality depends on the OS implementation." That's pretty much in line with what the implementation now does. There's no promise on the quality of the data it returns. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 07:51:54 2016 From: report at bugs.python.org (Donald Stufft) Date: Tue, 07 Jun 2016 11:51:54 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465300314.07.0.511804101933.issue26839@psf.upfronthosting.co.za> Donald Stufft added the comment: > That's pretty much in line with what the implementation now does. Literally the first line of the os.urandom documentation is "Return a string of n random bytes suitable for cryptographic use.". There is absolutely a promise that, as long as your OS isn't broken, this will provide cryptographically safe random numbers. As Cory pointed out, random.SystemRandom and the new secrets module are both relying on this promise of cryptographically safe numbers to provide their functionality, as is a number of other, external Python programs. This patch is a regression in the safety of this function, flat out, no way around it. Modern *nix's other than Linux have all already made /dev/urandom blocking on start up until it's been intialized. The only reason Linux hasn't is because Ted T'so has bad opinions, but that doesn't change the fact that people should always use urandom, and you should block until it's been initialized. I fail to understand why, if the CPython start up needs non blocking random to the point it would rather have cryptographically unsafe random than block, why a function that does that shouldn't be added instead of causing every other use of ``os.urandom`` to be potentially unsafe. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 07:53:20 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Jun 2016 11:53:20 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <5756B3D3.3020609@egenix.com> Message-ID: STINNER Victor added the comment: Cory Benfield: "For example, random.SystemRandom uses os.urandom to generate its random numbers. SystemRandom is then used by the secrets module to generate *its* random numbers. This means that os.urandom *is* explicitly used by the Python standard library to generate cryptographically secure random numbers. It was done so in part expressly because the call to random() could block." IMHO you should read http://www.2uo.de/myths-about-urandom/ which explains that the property of blocking or not blocking doesn't matter for the quality of the RNG. /dev/urandom is good enough to generate crytographic keys. Can we please stay focused on the *uninitialized entropy pool* case? Please see my message: https://bugs.python.org/issue26839#msg267612 "Reminder: getrandom() feature is specific to Linux. I understand that all other operating systems don't warn if the urandom entropy pool is not initialized yet!" IMHO you are expecting too much from os.urandom(). *If* you consider that secrets require an initialized entropy pool, IMHO you should help Stephan to implement a function to retrieve the implementation of os.urandom() and then take a decision *in the secrets module*. For example, raise an exception. It's the best way to warn users that something goes wrong. I don't think that *blocking* is a good choice. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 07:54:46 2016 From: report at bugs.python.org (Donald Stufft) Date: Tue, 07 Jun 2016 11:54:46 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465300486.01.0.146709962465.issue26839@psf.upfronthosting.co.za> Donald Stufft added the comment: > Reminder: getrandom() feature is specific to Linux. I understand that all other operating systems don't warn if the urandom entropy pool is not initialized yet! As far as I know, all other modern OSs *ALWAYS* block until their entropy pool is intialized. It's Linux that refuses to get with the program. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 08:00:01 2016 From: report at bugs.python.org (Donald Stufft) Date: Tue, 07 Jun 2016 12:00:01 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465300801.39.0.130541267135.issue26839@psf.upfronthosting.co.za> Donald Stufft added the comment: > IMHO you should read http://www.2uo.de/myths-about-urandom/ which explains that the property of blocking or not blocking doesn't matter for the quality of the RNG. /dev/urandom is good enough to generate crytographic keys. Can we please stay focused on the *uninitialized entropy pool* case? Cory wasn't speaking about (non)blocking in general, but the case where (apparently) it's desired to not block even if that means you don't get cryptographically secure random in the CPython interpreter start up. Nobody here wants ``os.urandom`` to behave like ``/dev/random`` does on Linux. We just want ``os.urandom`` to always return cryptographically safe random numbers. > IMHO you are expecting too much from os.urandom(). *If* you consider that secrets require an initialized entropy pool, IMHO you should help Stephan to implement a function to retrieve the implementation of os.urandom() and then take a decision *in the secrets module*. For example, raise an exception. It's the best way to warn users that something goes wrong. I don't think that *blocking* is a good choice. I think this is a pretty crappy way of handling it-- blocking for a short amount of time is almost always going to be the right thing for people here, particularly since it only matters right at the start of a fresh VM and no other time. I think that it's wrong to let an edge case of PYTHONHASHSEED reduce the security and the ability to reason about the return value of os.urandom for basically every other application of it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 08:02:52 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Jun 2016 12:02:52 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1465300486.01.0.146709962465.issue26839@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Donald Stufft: "As far as I know, all other modern OSs *ALWAYS* block until their entropy pool is intialized. It's Linux that refuses to get with the program." Ah? I didn't know. Anyway, it doesn't change anything to the problem. I don't think that security matters enough to block Python at startup. Python has a long history of being a thin wrapper on top of the OS. Usually, Python doesn't workaround design issues of OSes, but expose functions as they are. If you think that Linux is broken, please fix Linux, not Python. -- If security matters in your application, you should works around the Linux behaviour (bug?) in your application, but not in Python. For example, raise a fatal error with an error written in capital letters. Or block. Python *cannot* make this choice for you. It's part of Python design to not take such decision for you. Python is used in various areas, and in many areas, security don't matter at all. To me, it's just a major bug that python3 -c 'print("Hello World") blocks until Linux has enough entropy. In some embedded devices, you can wait forever, you will *never* get enough entropy to see the hello world message... -- Trying to decide if os.urandom() and /dev/urnadom are "secure" or not is a waste of time. To me it's now clear that it's impossible to decide :-) It depends on your expectation from security. Don't start to loose time on discussion this forever ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 08:04:52 2016 From: report at bugs.python.org (Cory Benfield) Date: Tue, 07 Jun 2016 12:04:52 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465301092.33.0.312580315037.issue26839@psf.upfronthosting.co.za> Cory Benfield added the comment: Victor Stinner: I found that comment to be pretty patronising, but I'm assuming that wasn't the intent. However, your characterisation of my comment was not as I intended it: when I said "because it can block", I meant because on almost every system urandom will block if there is insufficient randomness to seed the kernel CSPRNG. On FreeBSD, /dev/urandom blocks on startup until sufficiently seeded. On OS X, /dev/urandom behaves exactly the same as /dev/random (from the man page: "the two devices behave identically"), which is to say it blocks until the CSPRNG is sufficiently seeded. On Windows, CryptGenRandom (used by this code) specifies no blocking guarantees and the opinion of the wider community is that it too will block until sufficient entropy is gathered from startup. So, let me say this: if the purpose of this patch was to prevent long startup delays, *it failed*. On all the systems above os.urandom may continue to block system startup. If the purpose of this patch is to prevent the system blocking at startup then you *must not use urandom at Python interpreter startup*. This is why I object to this patch: it weakens the Linux interpreter while not fixing the actual problem. If Python does not need a CSPRNG at startup, then it should not block waiting for one *on any system*. If it does need a CSPRNG, then it should block until seeded. I don't see why some weird in-between solution is good enough here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 08:05:15 2016 From: report at bugs.python.org (Alex Gaynor) Date: Tue, 07 Jun 2016 12:05:15 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465301115.32.0.280567525443.issue26839@psf.upfronthosting.co.za> Alex Gaynor added the comment: Repeating what a few other folks have said: the of os.urandom's callers shouldn't have to pay for the hash seed implementation. If Python internally is ok with suboptimal entropy, it should use a different function. Or early-boot Python users should set PYTHONHASHSEED. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 08:05:28 2016 From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=) Date: Tue, 07 Jun 2016 12:05:28 +0000 Subject: [issue27105] cgi.__all__ is incomplete In-Reply-To: <1464121575.73.0.75569808483.issue27105@psf.upfronthosting.co.za> Message-ID: <1465301128.61.0.0213535613773.issue27105@psf.upfronthosting.co.za> Jacek Ko?odziej added the comment: Thank you, Martin. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 08:05:33 2016 From: report at bugs.python.org (Donald Stufft) Date: Tue, 07 Jun 2016 12:05:33 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465301133.12.0.23498374531.issue26839@psf.upfronthosting.co.za> Donald Stufft added the comment: > I don't think that security matters enough to block Python at startup. > Python has a long history of being a thin wrapper on top of the OS. > Usually, Python doesn't workaround design issues of OSes, but expose > functions as they are. That's fine, so make a new function that will return "maybe random data maybe not, who knows" instead of taking the function for producing cryptographically secure random data and making it less suitable for that task. This is the problem, not that Python start up is blocking, but that this patch takes that edge case, and declares that it's behavior is the correct behavior for everyone trying to get cryptographically secure random numbers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 08:06:14 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Jun 2016 12:06:14 +0000 Subject: [issue27249] Add os.urandom_info Message-ID: <1465301174.7.0.6272995241.issue27249@psf.upfronthosting.co.za> New submission from STINNER Victor: It seems like in some cases, you do need to know how os.urandom() generates random numbers. On Linux, using getrandom() to read /dev/urandom in blocking mode or reading from /dev/urandom give a different level of security if the urandom entropy pool is not feeded with enough entropy yet. See the issue #26839 for the background. ---------- messages: 267641 nosy: haypo priority: normal severity: normal status: open title: Add os.urandom_info versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 08:06:36 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Jun 2016 12:06:36 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465301196.93.0.899679414581.issue26839@psf.upfronthosting.co.za> STINNER Victor added the comment: Since many people seem to disagree, I reopen the issue, even if I still consider it as fixed ;-) I also opened the issue #27249: "Add os.urandom_info". ---------- resolution: fixed -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 08:09:01 2016 From: report at bugs.python.org (Donald Stufft) Date: Tue, 07 Jun 2016 12:09:01 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465301341.78.0.57631558945.issue26839@psf.upfronthosting.co.za> Donald Stufft added the comment: To be clear, I don't have a problem adding ``os.urandom_info`` but I don't think that it solves the problem, we shouldn't force people to introspect ``os.urandom`` to figure out if CPython decided to make it less secure on this invocation or not. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 08:18:18 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 07 Jun 2016 12:18:18 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1465300314.07.0.511804101933.issue26839@psf.upfronthosting.co.za> Message-ID: <5756BB84.6030708@egenix.com> Marc-Andre Lemburg added the comment: On 07.06.2016 13:51, Donald Stufft wrote: > > Donald Stufft added the comment: > >> That's pretty much in line with what the implementation now does. > > Literally the first line of the os.urandom documentation is "Return a string of n random bytes suitable for cryptographic use.". There is absolutely a promise that, as long as your OS isn't broken, this will provide cryptographically safe random numbers. As Cory pointed out, random.SystemRandom and the new secrets module are both relying on this promise of cryptographically safe numbers to provide their functionality, as is a number of other, external Python programs. Ah, that's what you call taking quotes out of context :-) The full documentation reads: """ Return a string of n random bytes suitable for cryptographic use. This function returns random bytes from an OS-specific randomness source. The returned data should be unpredictable enough for cryptographic applications, though its exact quality depends on the OS implementation. On Linux, getrandom() syscall is used if available and the urandom entropy pool is initialized (getrandom() does not block). On a Unix-like system this will query /dev/urandom. """ https://docs.python.org/3.5/library/os.html?highlight=urandom#os.urandom Note how the documentation emphasizes on os.urandom() not blocking. I like the idea that Victor brought to allow applications to check whether os.urandom() reverted to non-blocking /dev/urandom or not. That way applications can make the right choices, while still assuring that Python doesn't block on startup just to init hash randomization (which has it's own set of issues). BTW: /dev/urandom doesn't make many promises as to the quality of the data on Linux. For crypto applications relying on real entropy, it's better to gather data from a hardware source with known properties, e.g. http://fios.sector16.net/hardware-rng-on-raspberry-pi/, not on /dev/random or /dev/urandom: https://www.schneier.com/blog/archives/2013/10/insecurities_in.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 08:19:32 2016 From: report at bugs.python.org (Donald Stufft) Date: Tue, 07 Jun 2016 12:19:32 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465301971.99.0.147678680232.issue26839@psf.upfronthosting.co.za> Donald Stufft added the comment: > Note how the documentation emphasizes on os.urandom() not blocking. That line about not-blocking was added by the patch that Victor committed that we're objecting to. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 08:21:07 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Jun 2016 12:21:07 +0000 Subject: [issue27250] Add os.urandom_block() Message-ID: <1465302067.94.0.484576804121.issue27250@psf.upfronthosting.co.za> New submission from STINNER Victor: The change of the issue #26839 creates a long discussion around the behaviour of os.urandom() when the entropy pool is not seeded with enough entropy. On Python 2.7, os.urandom() doesn't block in this case. I expect that bytes are random, but not "random enough" to generate a cryptographic key. I propose to add a new os.urandom_block() function which is similar to os.urandom(), but with one single difference: don't fallback on reading /dev/urandom on Linux with the entropy pool is not initialized yet. In short, os.urandom() can be used for everything except generating cryptographic keys. os.urandom_block() is suitable for cryptographic keys. -- I expect that security experts would prefer the opposite: add a new os.pseudo_random() function and make os.urandom() blocking by default. Let me elaborate my rationale. Python is used in various areas. In most cases, random is not used for security purpose, but for game, simulation, numerical computation, etc. "random" term is large in Python: * random seed for the randomized hash function: Python SIPHASH requires 24 random bytes * importing the random modules immediatly instanciate a random.Random which is Mersenne Twister RNG which requires not less than 2500 random bytes These two users of random bytes blocked Python startup: see issue #26839. I consider that random is used in more cases for game, simulation, etc. than for security. That's why the secrets module was added to Python 3.6 rather than making the random module "more secure". https://lwn.net/Articles/659643/ ---------- messages: 267646 nosy: haypo priority: normal severity: normal status: open title: Add os.urandom_block() versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 08:22:07 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 07 Jun 2016 12:22:07 +0000 Subject: [issue27247] telnetlib AttributeError: 'error' object has no attribute 'errno' (handling of select.error) In-Reply-To: <1465287876.51.0.228447119579.issue27247@psf.upfronthosting.co.za> Message-ID: <1465302127.97.0.233881160717.issue27247@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report. This is a duplicate of issue 18035. ---------- nosy: +berker.peksag resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> telnetlib incorrectly assumes that select.error has an errno attribute _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 08:22:51 2016 From: report at bugs.python.org (Alex Gaynor) Date: Tue, 07 Jun 2016 12:22:51 +0000 Subject: [issue27249] Add os.urandom_info In-Reply-To: <1465301174.7.0.6272995241.issue27249@psf.upfronthosting.co.za> Message-ID: <1465302171.85.0.20480684246.issue27249@psf.upfronthosting.co.za> Changes by Alex Gaynor : ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 08:22:54 2016 From: report at bugs.python.org (Alex Gaynor) Date: Tue, 07 Jun 2016 12:22:54 +0000 Subject: [issue27250] Add os.urandom_block() In-Reply-To: <1465302067.94.0.484576804121.issue27250@psf.upfronthosting.co.za> Message-ID: <1465302174.83.0.59899198818.issue27250@psf.upfronthosting.co.za> Changes by Alex Gaynor : ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 08:24:19 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Jun 2016 12:24:19 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465302259.51.0.434234223751.issue26839@psf.upfronthosting.co.za> STINNER Victor added the comment: Thomas Petazzoni: "The original problem is that Python wants to generate random numbers at *startup*. Are those random numbers really used for crypto-related activities? I doubt it." Python randomized hash function and random.Random (Mersenne Twister, instanciated when "import random" is called) don't need high quality random. Poor entropy is enough ;-) Thomas Petazzoni: "So isn't the proper solution to have two functions, one delivering random numbers that are usable for crypto-related activities, and which would potentially block, and a second one that delivers random numbers that are not appropriate for crypto stuff. This second function can be used at Python startup to replace what is done currently." Sure, that's the obvious change: I proposed the issue #27250. I forgot about the new secrets module. I agree that *this* module must require high-quality entropy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 08:24:26 2016 From: report at bugs.python.org (Donald Stufft) Date: Tue, 07 Jun 2016 12:24:26 +0000 Subject: [issue27250] Add os.urandom_block() In-Reply-To: <1465302067.94.0.484576804121.issue27250@psf.upfronthosting.co.za> Message-ID: <1465302266.04.0.577853535397.issue27250@psf.upfronthosting.co.za> Donald Stufft added the comment: This should be add ``os.urandom_noblock`` instead. Don't make every other application change just so the Python interpreter can continue to call ``os.urandom``. ---------- nosy: +dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 08:25:12 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Jun 2016 12:25:12 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465302312.26.0.172545215259.issue26839@psf.upfronthosting.co.za> STINNER Victor added the comment: (Oh, in fact I wanted to reopen the issue, so Status must be changed, not Resolution, so the issue is visible again in the main list of issues.) ---------- resolution: -> fixed status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 08:26:18 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Jun 2016 12:26:18 +0000 Subject: [issue27250] Add os.urandom_block() In-Reply-To: <1465302067.94.0.484576804121.issue27250@psf.upfronthosting.co.za> Message-ID: <1465302378.65.0.320569524751.issue27250@psf.upfronthosting.co.za> STINNER Victor added the comment: If os.urandom_block() is added, I don't think that it's worth to add os.urandom_info as I proposed in the issue #27249. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 08:32:44 2016 From: report at bugs.python.org (Cory Benfield) Date: Tue, 07 Jun 2016 12:32:44 +0000 Subject: [issue27250] Add os.urandom_block() In-Reply-To: <1465302067.94.0.484576804121.issue27250@psf.upfronthosting.co.za> Message-ID: <1465302764.98.0.117220610893.issue27250@psf.upfronthosting.co.za> Cory Benfield added the comment: Let me make the security person argument even though you've dismissed it in your original post: Security should be on by default and opted out of, not the other way around. If the obvious choice is insecure then users who aren't careful enough won't notice, because even bad RNGs produce numbers that *look* random if not carefully evaluated. This means they won't fix it and it will stay there, broken, until they are attacked (which they may never notice). On the other hand, if the obvious choice is secure then users who aren't careful enough (that is, ones that don't care about security but do care about blocking) *will* notice, because their apps will hang on startup. They'll investigate the hang, see the docs, and fix their code. This is a *much better* failure mode. There is a reason that modern cars warn you about any upcoming problem with the car (e.g. worn brake pads, low oil etc.): users whose expectations are violated in a way they can easily detect are much more likely to act than users whose expectations are subtly violated. This is doubly true here, because the only system that is complaining about the random numbers right now is CPython, which, being the same system providing these new functions, can always ensure that it's doing the right thing. With this patch as proposed here, external library developers need to see this discussion and realise that, for Python 3.5 or lower, they want os.urandom, and for Python 3.6 and higher, they want os.urandom_block(). And, again, because os.urandom() still appears to produce high quality random numbers (and most of the time *actually does so*), I guarantee at least one application will not notice the change and will become open to attack. Those are the two arguments for making non-blocking be explicit, rather than making blocking be specific. ---------- nosy: +Lukasa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 08:35:11 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Jun 2016 12:35:11 +0000 Subject: [issue27250] Add os.urandom_block() In-Reply-To: <1465302067.94.0.484576804121.issue27250@psf.upfronthosting.co.za> Message-ID: <1465302911.34.0.927793961043.issue27250@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 08:35:57 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Jun 2016 12:35:57 +0000 Subject: [issue27250] Add os.urandom_block() In-Reply-To: <1465302067.94.0.484576804121.issue27250@psf.upfronthosting.co.za> Message-ID: <1465302957.65.0.47639109396.issue27250@psf.upfronthosting.co.za> STINNER Victor added the comment: See also issue #26970 "Replace OpenSSL's CPRNG with system entropy source". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 08:36:59 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 07 Jun 2016 12:36:59 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1465301971.99.0.147678680232.issue26839@psf.upfronthosting.co.za> Message-ID: <5756BFE3.7000404@egenix.com> Marc-Andre Lemburg added the comment: On 07.06.2016 14:19, Donald Stufft wrote: > >> Note how the documentation emphasizes on os.urandom() not blocking. > > That line about not-blocking was added by the patch that Victor committed that we're objecting to. Ah, sorry, I was looking at the online docs and the selector was set to 3.5.1, so I was under the impression of looking at the 3.5.1 docs, not a later version. In any case, the point still stands: os.urandom() has always been documented as interface to /dev/urandom on Linux, which again is defined as non-blocking interface. The change in 3.5.0 to use getrandom() broke this and Victor's patch restored the previously documented and expected behavior, so I don't see what the problem is. People looking for a blocking random number source should use /dev/random (or better: a hardware entropy device). Even with initialized entropy pool, /dev/urandom will happily return pseudo random numbers if the entropy pool lacks entropy, so you don't really win much: """ A read from the /dev/urandom device will not block waiting for more entropy. If there is not sufficient entropy, a pseudorandom number generator is used to create the requested bytes. """ http://man7.org/linux/man-pages/man4/random.4.html It's simply the wrong source to use for crypto random data, since you can never be sure that the data returned by /dev/urandom originates from true entropy or some approximation. In that light, using it to seed hash randomization is the right approach, since you don't need a crypto RNG to seed this part of the Python runtime. ---------- _______________________________________ Python tracker _______________________________________ From mal at egenix.com Tue Jun 7 08:38:34 2016 From: mal at egenix.com (M.-A. Lemburg) Date: Tue, 7 Jun 2016 14:38:34 +0200 Subject: [issue27250] Add os.urandom_block() In-Reply-To: <1465302764.98.0.117220610893.issue27250@psf.upfronthosting.co.za> References: <1465302764.98.0.117220610893.issue27250@psf.upfronthosting.co.za> Message-ID: <5756C04A.4050508@egenix.com> Should this ticket be named "Add os.random()" ? After all, blocking in case of missing entropy is what /dev/random is all about. -- Marc-Andre Lemburg eGenix.com From report at bugs.python.org Tue Jun 7 08:38:39 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 07 Jun 2016 12:38:39 +0000 Subject: [issue27250] Add os.urandom_block() In-Reply-To: <1465302764.98.0.117220610893.issue27250@psf.upfronthosting.co.za> Message-ID: <5756C04A.4050508@egenix.com> Marc-Andre Lemburg added the comment: Should this ticket be named "Add os.random()" ? After all, blocking in case of missing entropy is what /dev/random is all about. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 08:40:32 2016 From: report at bugs.python.org (Donald Stufft) Date: Tue, 07 Jun 2016 12:40:32 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465303232.29.0.991986972079.issue26839@psf.upfronthosting.co.za> Donald Stufft added the comment: (Basically) nobody should ever use /dev/random (and cryptographers agree!). The thing you want to use is /dev/urandom and the fact that /dev/urandom on Linux doesn't block before the pool is initalized has long been considered by cryptographers to be a fairly large flaw. The ``getrandom()`` calls were added explicitly to allow programs to get the correct behavior out of the system random. For more information see http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ or http://www.2uo.de/myths-about-urandom/. The /dev/urandom man page is wrong, and it's wrong for political reasons and because Ted T'so has bad opinions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 08:41:23 2016 From: report at bugs.python.org (Cory Benfield) Date: Tue, 07 Jun 2016 12:41:23 +0000 Subject: [issue27250] Add os.urandom_block() In-Reply-To: <1465302067.94.0.484576804121.issue27250@psf.upfronthosting.co.za> Message-ID: <1465303283.48.0.570222372679.issue27250@psf.upfronthosting.co.za> Cory Benfield added the comment: Marc-Andre: No. See the discussion in the related issue #27249 for more. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 08:41:51 2016 From: report at bugs.python.org (Cory Benfield) Date: Tue, 07 Jun 2016 12:41:51 +0000 Subject: [issue27250] Add os.urandom_block() In-Reply-To: <1465302067.94.0.484576804121.issue27250@psf.upfronthosting.co.za> Message-ID: <1465303311.66.0.732315383967.issue27250@psf.upfronthosting.co.za> Cory Benfield added the comment: Uh, sorry, I meant #26839. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 08:46:04 2016 From: report at bugs.python.org (Christian Heimes) Date: Tue, 07 Jun 2016 12:46:04 +0000 Subject: [issue27249] Add os.urandom_info In-Reply-To: <1465301174.7.0.6272995241.issue27249@psf.upfronthosting.co.za> Message-ID: <1465303564.36.0.644723725919.issue27249@psf.upfronthosting.co.za> Christian Heimes added the comment: +1 How are you planning to handle initialization? Run getentropy() and check if the syscall succeeds? ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 08:52:17 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Jun 2016 12:52:17 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465303937.54.0.578079735897.issue26839@psf.upfronthosting.co.za> STINNER Victor added the comment: Currently, os.urandom() doesn't block anymore which means secrets should be updated. If we revert os.urandom(), Python must be patched to use a non-blocking urandom to initialized hash secret and random.Random (when the random module is imported). In both cases, something should be changed. I suggest to move the discussion to the issue #27250 to try to identify which parts of Python requires secure RNG, which parts of Python don't require a secure RNG, and how to expose secure and not secure RNG in Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 09:01:44 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 07 Jun 2016 13:01:44 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1465303232.29.0.991986972079.issue26839@psf.upfronthosting.co.za> Message-ID: <5756C5B3.8090009@egenix.com> Marc-Andre Lemburg added the comment: On 07.06.2016 14:40, Donald Stufft wrote: > > Donald Stufft added the comment: > > (Basically) nobody should ever use /dev/random (and cryptographers agree!). The thing you want to use is /dev/urandom and the fact that /dev/urandom on Linux doesn't block before the pool is initalized has long been considered by cryptographers to be a fairly large flaw. The ``getrandom()`` calls were added explicitly to allow programs to get the correct behavior out of the system random. Sounds to me that what you really want is os.getrandom() and not a change in the implementation of os.urandom(). I think that would be a better solution overall: we get os.getrandom() with access to all options and have os.urandom be the non-blocking interface to /dev/urandom it has always been. > For more information see http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ or http://www.2uo.de/myths-about-urandom/. The /dev/urandom man page is wrong, and it's wrong for political reasons and because Ted T'so has bad opinions. I'm not sure what you are trying to tell me with those blog posts or comments. The concept of trying to measure entropy in an entropy pool is certainly something that people can have different opinions about, but it's not wrong per-se when you don't have easy access to a hardware device providing truely random data (as in the Raspi SoC). IMO, blocking is never a good strategy, since it doesn't increase security - in fact, it lowers it because it opens up a denial of service attack vector. Raising an exception is or providing other ways of letting the application decide. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 09:03:02 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 07 Jun 2016 13:03:02 +0000 Subject: [issue27250] Add os.urandom_block() In-Reply-To: <1465303311.66.0.732315383967.issue27250@psf.upfronthosting.co.za> Message-ID: <5756C601.1010900@egenix.com> Marc-Andre Lemburg added the comment: On 07.06.2016 14:41, Cory Benfield wrote: > > Uh, sorry, I meant #26839. Ok, then perhaps "Add os.getrandom()" - also see the discussion there :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 09:07:10 2016 From: report at bugs.python.org (Donald Stufft) Date: Tue, 07 Jun 2016 13:07:10 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465304830.92.0.672455167664.issue26839@psf.upfronthosting.co.za> Donald Stufft added the comment: What I'm trying to tell you is that /dev/random is a bad implementation and practically every cryptographer agrees that everyone should use /dev/urandom and they all also agree that on Linux /dev/urandom has a bad wart of giving bad randomness at the start of the system. The behavior of getrandom is a fix to that. In addition, almost nobody needs hardware RNG, /dev/urandom (minus the intialization problem on Linux) is the right answer for almost every single application (and if it's not the right answer, you're a cryptographer who knows that it's not the right answer). On most systems, /dev/random and /dev/urandom have the exact same behavior (which is the behavior of getrandom()-- blocks on intialization, otherwise doens't), it's just linux being brain dead here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 09:12:05 2016 From: report at bugs.python.org (Donald Stufft) Date: Tue, 07 Jun 2016 13:12:05 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465305125.79.0.739599111796.issue26839@psf.upfronthosting.co.za> Donald Stufft added the comment: Since there's obviously contention about what the right answer here is, I suggest we should revert the patch (since the old behavior already exists in 3.5 and is shipped to thousands of people already, and status quo wins) and then continue the discussion about what to do further beyond that. At the very least, if something isn't decided prior to Larry cutting a release, then it should be reverted then. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 09:16:35 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 07 Jun 2016 13:16:35 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1465305125.79.0.739599111796.issue26839@psf.upfronthosting.co.za> Message-ID: <5756C92C.6090402@egenix.com> Marc-Andre Lemburg added the comment: On 07.06.2016 15:12, Donald Stufft wrote: > > Since there's obviously contention about what the right answer here is, I suggest we should revert the patch (since the old behavior already exists in 3.5 and is shipped to thousands of people already, and status quo wins) and then continue the discussion about what to do further beyond that. At the very least, if something isn't decided prior to Larry cutting a release, then it should be reverted then. Wait. Under that argument, every regression we introduce would be deemed fine and not bug, because the "status quo wins". I'm sorry, but that's non sense. Python 3.5 introduced a regression w/r to the behavior of os.urandom() compared to Python 3.4 and older releases. If someone wants getrandom() behavior, we should add a new API for this and fix the regression in os.urandom(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 09:21:08 2016 From: report at bugs.python.org (Donald Stufft) Date: Tue, 07 Jun 2016 13:21:08 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465305668.29.0.091260234974.issue26839@psf.upfronthosting.co.za> Donald Stufft added the comment: The patch causes a regression because I'm relying on the 3.5 behavior of getting secure randomness from ``os.urandom`` via the ``getrandom()`` system call (behavior that was documented in the Whats New in 3.5). The 3.5 behavior also makes ``os.urandom`` behave the same on Windows, FreeBSD, OpenBSD, etc, basically every major OS except for Linux. And yes, it's not unusual for "bugs" to not be fixed if there is contention about whether or not they are bugs at all and if they should be fixed. The typical resolution path to not change anything unless there's broad agreement, if that can't happen on bugs.p.o then escalate to python-dev, and if it can't happen there then escalate to a PEP for a BDFL pronouncement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 09:33:13 2016 From: report at bugs.python.org (Colm Buckley) Date: Tue, 07 Jun 2016 13:33:13 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465306393.52.0.974106429924.issue26839@psf.upfronthosting.co.za> Colm Buckley added the comment: Here's where things stand, as I currently see it. Under certain circumstances, under Linux at least, calls to getrandom() will block. Specifically, they will block if the system's PRNG has been insufficiently initialized. Depending on the nature of the host, this block can be for a long time - delays of over 90 seconds have been observed. This does not just affect VMs; physical systems are also affected. Even if an application does not explicitly request random data, Python calls this function early in its execution to initialize the per-process hash seed (in _PyRandom_Init()). The net effect is that *all* invocations of Python will block at startup if the system RNG is blocking. The only reason this is being called out as Linux-specific is that the behavior has been noticed in Linux. I posit that it's *highly undesirable* to have Python block on the system RNG even when called in non-crypto contexts. (The specific trigger for this bug is the current behavior of Debian's 'testing' branch which calls a Python script very shortly after boot to parse crontab entries.) Regardless of what behavior is expected of module functions such as os.urandom(), a blocking RNG must not be used to initialize _Py_HashSecret, even at the expense of predictability. I agree that ultimately a variety of interfaces should be exposed, to allow developers to choose sensible compromises between performance and security. However, the current patchset makes the minimal change to system behavior while allowing a practical path forward. My personal preference would be for os.urandom(n) to favor non-blocking operation over cryptographic security, and either add os.random() or add an optional parameter to os.urandom() to make the opposite trade-off. Given the deadline requested by Larry for 3.5.2, however, can I suggest that the minimal solution is the one already proposed by myself and Victor? (Aside: "you should fix Linux" is not really within the realm of practicality.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 09:36:37 2016 From: report at bugs.python.org (Colm Buckley) Date: Tue, 07 Jun 2016 13:36:37 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465306597.25.0.0939462016855.issue26839@psf.upfronthosting.co.za> Colm Buckley added the comment: Donald: please note - the current behavior is that Python *will not start at all* if getrandom() blocks (because the hash secret initialization fails). If you are relying on the current behavior with a functioning application, then you are invoking it well after the system PRNG has been initialized, and the situation doesn't apply. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 09:37:21 2016 From: report at bugs.python.org (Christian Heimes) Date: Tue, 07 Jun 2016 13:37:21 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465306641.7.0.540197040699.issue26839@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 09:40:16 2016 From: report at bugs.python.org (Donald Stufft) Date: Tue, 07 Jun 2016 13:40:16 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465306816.36.0.672099930394.issue26839@psf.upfronthosting.co.za> Donald Stufft added the comment: > My personal preference would be for os.urandom(n) to favor non-blocking operation over cryptographic security, and either add os.random() or add an optional parameter to os.urandom() to make the opposite trade-off. Insecure by default is very rarely the right trade off. There are thousands of projects using ``os.urandom()`` already assuming it's going to give them cryptographically strong numbers. If we want a "maybe random" function or option, then it should be the new thing, not the other way around. I have no problem with SipHash using a possibly insecure random so that Python can start up quickly even in the face of an unitialized urandom on Linux. I do have a problem with infecting every single call to os.urandom with that same choice. > The current behavior is that Python *will not start at all* if getrandom() blocks (because the hash secret initialization fails). It starts jsut fine, it just can possible takes awhile. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 09:43:55 2016 From: report at bugs.python.org (Donald Stufft) Date: Tue, 07 Jun 2016 13:43:55 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465307035.46.0.920680075881.issue26839@psf.upfronthosting.co.za> Donald Stufft added the comment: > The net effect is that *all* invocations of Python will block at startup if the system RNG is blocking. The only reason this is being called out as Linux-specific is that the behavior has been noticed in Linux. The fix is Linux specific, because all other modern OSs don't allow you to read randomness from /dev/urandom until the bool is initialized. So the problem that this ticket has exists on all platforms *by design* because every modern platform but Linux has a good implementation of /dev/urandom with regards to the behavior prior to the pool being fully initialized. IOW this patch on OpenBSD (where this syscall also exists) will cause us to try getrandom(), fail because it would have to block, then open up /dev/urandom and then.. block again because OpenBSD made reasonable choices and doesn't allow people to read bad random off it's random device. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 09:49:23 2016 From: report at bugs.python.org (Colm Buckley) Date: Tue, 07 Jun 2016 13:49:23 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465307363.87.0.291053788091.issue26839@psf.upfronthosting.co.za> Colm Buckley added the comment: Donald - With the greatest respect, you're talking about introducing multi-minute delays into the startup times of hundreds of millions of systems, regardless of whether they have a proximate requirement for cryptographically-secure RNG sources. I don't think that's reasonable. My servers start up in about fifteen seconds with this patch applied, or over two minutes without. Note; it's perfectly possible for getrandom() to block *indefinitely* - in the trigger case here (systemd's crontab generator), it times out after 90 seconds rather than eventually succeeding. If (for example), a Python script is called before device initialization, it's quite possible that there will *never* be enough entropy in the system to satisfy getrandom(), resulting in a non-booting system. To reiterate; the overwhelming majority of applications (in particular, anything which is called after the entropy pool is initialized, which typically happens once networking, USB etc. are running) will use perfectly acceptable random sources. The only applications affected by this patch are those which call getrandom() very early in the boot process. I feel you're tilting at a very impractical windmill. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 09:51:40 2016 From: report at bugs.python.org (Alex Gaynor) Date: Tue, 07 Jun 2016 13:51:40 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465307500.11.0.423299375738.issue26839@psf.upfronthosting.co.za> Alex Gaynor added the comment: Colm -- how is that situation not addressed by fixing the hash seed generation specifically, rather than patching all consumers of os.urandom? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 09:51:51 2016 From: report at bugs.python.org (Donald Stufft) Date: Tue, 07 Jun 2016 13:51:51 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465307511.9.0.851038586387.issue26839@psf.upfronthosting.co.za> Donald Stufft added the comment: > With the greatest respect, you're talking about introducing multi-minute delays into the startup times of hundreds of millions of systems, regardless of whether they have a proximate requirement for cryptographically-secure RNG sources. No I'm not. I'm talking about implementing this fix so that it *only* affects the Python interpreter start up, in particular things like SipHash initialization, instead of affecting the security of every other user of os.urandom. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 09:58:38 2016 From: report at bugs.python.org (Colm Buckley) Date: Tue, 07 Jun 2016 13:58:38 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465307918.73.0.882344281902.issue26839@psf.upfronthosting.co.za> Colm Buckley added the comment: I have no objection to *deliberate* invocations of the system RNG blocking if needed. Presumably this behavior can be codified into the various APIs. My objection is *entirely* to _PyRandom_Init() calling a potentially-blocking RNG source, before script parsing even begins. This basically prohibits Python from starting on systems where the system RNG is blocking. Linux is the only affected system *now* because the systemd crontab generator is the only Python script called before the RNG has initialized. Exactly the same issue would apply to any of the BSDs or Solaris, if /dev/urandom blocks as you describe. I want to be clear - this is not a Linux-specific issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 10:06:05 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 07 Jun 2016 14:06:05 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1465305668.29.0.091260234974.issue26839@psf.upfronthosting.co.za> Message-ID: <5756D4C7.1080600@egenix.com> Marc-Andre Lemburg added the comment: On 07.06.2016 15:21, Donald Stufft wrote: > > The patch causes a regression because I'm relying on the 3.5 behavior of getting secure randomness from ``os.urandom`` via the ``getrandom()`` system call (behavior that was documented in the Whats New in 3.5). The 3.5 behavior also makes ``os.urandom`` behave the same on Windows, FreeBSD, OpenBSD, etc, basically every major OS except for Linux. The contention is not about using getrandom() to fetch data, but the newly introduced and unwanted blocking nature during system startup. This was not documented anywhere and it's a regression that causes major problems with using Python 3.5 on containers and VMs systems where startup time is of essence. You get the same blocking behavior when importing the random module (see http://bugs.python.org/issue25420), even though it's just seeding the global PRNG. All these instances assume that os.urandom() does *not* block and rightly so, since at the time they were written, os.urandom() was a direct interface to /dev/urandom, which is documented and designed to not block on Linux. > And yes, it's not unusual for "bugs" to not be fixed if there is contention about whether or not they are bugs at all and if they should be fixed. The typical resolution path to not change anything unless there's broad agreement, if that can't happen on bugs.p.o then escalate to python-dev, and if it can't happen there then escalate to a PEP for a BDFL pronouncement. Sure, we can have the discussion again on python-dev. I just don't understand why you are apparently not willing to even consider compromises. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 10:09:10 2016 From: report at bugs.python.org (Donald Stufft) Date: Tue, 07 Jun 2016 14:09:10 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465308550.21.0.164752726669.issue26839@psf.upfronthosting.co.za> Donald Stufft added the comment: > I have no objection to *deliberate* invocations of the system RNG blocking if needed. Presumably this behavior can be codified into the various APIs. > > My objection is *entirely* to _PyRandom_Init() calling a potentially-blocking RNG source, before script parsing even begins. It sounds like we might (somehwat?) be in violent agreement then. If someone calls os.urandom() (or calls something that causes it to be called, e.g. secrets.py, random.SystemRandom, etc) then they should not get randomness from an un-initialized /dev/urandom by default. I have a preference for blocking until randomness is available, but an exception would be OK too. I have no problem with the interpreter start up not blocking on entropy because no user invoked code caused that, and the security properties of SipHash that need really good random only really matter for long lived processes that processes a lot of user input-- IOW stuff that's unlikely to be started prior to the pool being initialized. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 10:09:44 2016 From: report at bugs.python.org (Christian Heimes) Date: Tue, 07 Jun 2016 14:09:44 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465308584.55.0.665850864367.issue26839@psf.upfronthosting.co.za> Christian Heimes added the comment: I'm with Donald here. Python must not reduce security just for a special case. It doesn't mean that we should not address and fix this special case -- just treat it as special. 1) For your use case, the hash randomization key for the SipHash PRN doesn't need to be 4 or 8 bytes of CPRNG. Since you are not dealing with lots of untrusted input from a malicious remote source, any unpredictable or even predictable value will do. 2) Your use case might be special enough to use a special build of Python. Too bad https://www.python.org/dev/peps/pep-0432/ is not ready yet. 3) #21470 causes 'import random' to read os.urandom(2500) in order to initialize the MT state of random.random. I really don't understand why MT needs 2500 bytes of distinct CPRNG data. The module should rather read less data and then stretch it into a larger init vector. We could use SipHash for the job. In fact why does the MT use a CPRNG at all? It's not designed as CPRNG source and could be initialized from other sources (id(self), time()...) instead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 10:14:59 2016 From: report at bugs.python.org (Colm Buckley) Date: Tue, 07 Jun 2016 14:14:59 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465308899.07.0.639441134217.issue26839@psf.upfronthosting.co.za> Colm Buckley added the comment: The attached patch (against tip) is a very quick attempt to implement the desired behavior: * add a "nonblocking" argument to py_getrandom() * dev_urandom_python() sets this to 0, to request blocking operation * dev_urandom_noraise() sets this to 1 to request non-blocking As far as I can tell, dev_urandom_noraise() is only called by _PyRandom_Init() so only the hash secret initialization will be affected. Victor; can you take a look and let me know what you think? This probably needs some comments etc. before pushing. I'm also a little unsure about the rest of the logic in dev_urandom_noraise - it should probably also be modified to not block in the event that urandom is unavailable. ---------- Added file: http://bugs.python.org/file43278/nonblocking_urandom_noraise.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 10:17:02 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Jun 2016 14:17:02 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465309022.67.0.00965794669495.issue26839@psf.upfronthosting.co.za> STINNER Victor added the comment: nonblocking_urandom_noraise.patch doesn't fix the issue #21470. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 10:18:09 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Jun 2016 14:18:09 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465309089.21.0.268153225092.issue26839@psf.upfronthosting.co.za> STINNER Victor added the comment: > nonblocking_urandom_noraise.patch doesn't fix the issue #21470. Sorry, it's the issue #25420: "import random" blocks on entropy collection on Linux with low entropy ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 10:18:35 2016 From: report at bugs.python.org (Donald Stufft) Date: Tue, 07 Jun 2016 14:18:35 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465309115.08.0.157352239694.issue26839@psf.upfronthosting.co.za> Donald Stufft added the comment: > I just don't understand why you are apparently not willing to even consider compromises. I have one thing that I hold immutable here, That os.urandom should use the best interfaces provided by the OS to ensure that it always returns cryptographically random data. I don't care if SipHash is allowed to use lesser data. I don't care if os.urandom raises an exception or if it blocks if enough entropy isn't available. I don't care if people are given an option that will let them maybe get bad data (but will only work on Linux or older *nixes). All I care about is that the default behavior of os.urandom gets data that is generated using the best practices for that system, because that's what people have been told to use for years and years. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 10:19:10 2016 From: report at bugs.python.org (Stefan Krah) Date: Tue, 07 Jun 2016 14:19:10 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465309150.11.0.851073357095.issue26839@psf.upfronthosting.co.za> Stefan Krah added the comment: man urandom: "A read from the /dev/urandom device will not block waiting for more entropy. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver. Knowledge of how to do this is not available in the current unclassified literature, but it is theoretically possible that such an attack may exist. If this is a concern in your application, use /dev/random instead." There was never any guarantee on Linux. Python is a language and not an application. Security checks should be done by applications or better during the OS startup. Any properly configured Linux server will not have a problem, but it is not up to a language implementation to check for that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 10:33:38 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 07 Jun 2016 14:33:38 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1465310018.35.0.604765909032.issue5124@psf.upfronthosting.co.za> Ned Deily added the comment: Terry, after the discussion I don't have a strong opinion one way or the other. It seems that current X11 users expect the replace behavior, so option 4 seems fine to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 10:43:43 2016 From: report at bugs.python.org (Colm Buckley) Date: Tue, 07 Jun 2016 14:43:43 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465310623.51.0.476332035518.issue26839@psf.upfronthosting.co.za> Colm Buckley added the comment: Victor - I see three options for 3.5.2: * continue with the 3.5.1 behaviour, which blocks all python invocations in low-entropy situations. I think this is highly undesireable. * apply my patches, which fixes the hash secret initialization but not 'import random'. This at least allows current Debian testing-track systems to boot properly ;) * attempt to find a solution for #25420 which also addresses this issue. The original patch we submitted fixed both, but has encountered community objections from Donald and others. The situation we're encountering is that it is *not possible* to use a sound PRNG under certain circumstances - if the system doesn't have entropy, it doesn't have entropy and there's not a lot to be done about it apart from wait. I posit that an application which uses the random module has higher expectations of unpredictability, and therefore should take userspace measures to ensure entropy availability (as you suggest in msg253163 for example). Note that the previous behavior (reading /dev/urandom) returns potentially unsafe data (as Donald and others point out). The only resolution to me seems to be modifying the behavior of the random module so that the buffer is initialized lazily (at first use, rather than at module import). This should be relatively straightforward, but I haven't had time to unpick all the logic of random.py to determine The Right Thing. Maybe Raymond can take a look at this? In summary: I propose that the fix for this issue be implemented using the patches already discussed in this thread, and the fix for #25420 be implemented by modifying random.py. Is this acceptable to everyone? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 10:47:40 2016 From: report at bugs.python.org (Christian Heimes) Date: Tue, 07 Jun 2016 14:47:40 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465310860.48.0.930633154294.issue26839@psf.upfronthosting.co.za> Christian Heimes added the comment: PSRT VETO! This ticket is turning into a bike-shedding discussion. In the light of the upcoming release 3.5.2 I'm now putting on my PSRT hat (Python Security Response Team) and proclaim a veto against any and all changes to os.urandom(). The security properties of os.urandom() must not be modified or reduced compared to 3.5.1. Please restore the behavior of os.urandom(). Reasoning: The security of our general audience is much more important than this special case. I agree that the problem of Python blocking in an early boot phase should be fixed. But under no circumstances must the fix affect security. For now please work around the issue with PYTHONHASHSEED or forwarding the host's entropy source into your virtualization environment. Any change to os.urandom(), _Py_HashSecret (I'm the author of PEP 456) and Mersenne-Twister initialization of random.random() shall go through a formal PEP process. I'm willing to participate in writing the PEP. A formal PEP also enables us to ask trained security experts for review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 10:49:28 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 07 Jun 2016 14:49:28 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1465309115.08.0.157352239694.issue26839@psf.upfronthosting.co.za> Message-ID: <5756DEF2.5040506@egenix.com> Marc-Andre Lemburg added the comment: On 07.06.2016 16:18, Donald Stufft wrote: > > Donald Stufft added the comment: > >> I just don't understand why you are apparently not willing to even consider compromises. > > I have one thing that I hold immutable here, That os.urandom should use the best interfaces provided by the OS to ensure that it always returns cryptographically random data. > > I don't care if SipHash is allowed to use lesser data. > I don't care if os.urandom raises an exception or if it blocks if enough entropy isn't available. > I don't care if people are given an option that will let them maybe get bad data (but will only work on Linux or older *nixes). > > All I care about is that the default behavior of os.urandom gets data that is generated using the best practices for that system, because that's what people have been told to use for years and years. Fine, but that's just your personal desire. It's not something that we have documented anywhere - all these years, we've told people that os.urandom() is an interface to /dev/urandom and this was now changed in an incompatible way without giving notice to anyone. Why not expose os.getrandom() and then have folks that care about having it block in the case of an uninitialized entropy buffer use that ? This gives people a clear choice and doesn't cause people to have to reconsider using the random module or wait for Python hash randomization to initialize itself when using Python during VM/container/system startup. I don't really appreciate this approach to break Python in cloud setups just because some entropy pool is not initialized, which only a tiny fraction of users care about. It doesn't make Python land a better place. This is similar to the approach that Python3 should always determine the I/O encoding from the environment, without providing sane defaults to even startup the interactive console or run a pipe. It wasn't helping with the adoption of Python. We've resolved that by making useful assumptions. We should do the same here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 10:57:51 2016 From: report at bugs.python.org (Colm Buckley) Date: Tue, 07 Jun 2016 14:57:51 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465311471.24.0.826342980813.issue26839@psf.upfronthosting.co.za> Colm Buckley added the comment: Christian - I would like to make one further comment: The only reason getrandom() was used instead of /dev/random was to avoid wasting a file descriptor. The previous behavior was in use for many years with no security issues; it was changed for FD conservation reasons, not security reasons. The change between 3.5 and 3.5.1 caused a very notable regression; the initialization of the hash secret can block indefinitely under circumstances which unfortunately are fairly common. Persisting with the 3.5.1 behavior, in my opinion, violates the principle of least surprise - Python blocks at startup waiting for random data even when none is actually required by the application. The fallback to 3.5 behavior is only invoked under the single case where the system PRNG is uninitialized. You are within your rights to request the reversion; however I want to point out again that the implications are the introduction of multi-minute delays into the startup times of hundreds of millions of systems, due to a change in *Python's* behavior. Colm ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 10:59:16 2016 From: report at bugs.python.org (Christian Heimes) Date: Tue, 07 Jun 2016 14:59:16 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <5756DEF2.5040506@egenix.com> Message-ID: <375318ea-1783-d681-1c71-cbe6430337bb@cheimes.de> Christian Heimes added the comment: On 2016-06-07 16:49, Marc-Andre Lemburg wrote: > This gives people a clear choice and doesn't cause people > to have to reconsider using the random module or wait for > Python hash randomization to initialize itself when using > Python during VM/container/system startup. > > I don't really appreciate this approach to break Python in > cloud setups just because some entropy pool is not initialized, > which only a tiny fraction of users care about. It doesn't > make Python land a better place. VM and cloud setup without a proper CPRNG source are plain broken. True fact! Secure entropy sources are a fundamental resource for all modern applications. Please start treating CPRNG like RAM, CPU or disks. You wouldn't add a workaround for broken CPU instructions to math.c or semi-functional network card to socket.c, would you? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 11:03:10 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 07 Jun 2016 15:03:10 +0000 Subject: [issue27221] multiprocessing documentation is outdated regarding method picklability In-Reply-To: <1465069362.83.0.142351405451.issue27221@psf.upfronthosting.co.za> Message-ID: <1465311790.69.0.700932435455.issue27221@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 11:10:02 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 07 Jun 2016 15:10:02 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <375318ea-1783-d681-1c71-cbe6430337bb@cheimes.de> Message-ID: <5756E3C4.2080906@egenix.com> Marc-Andre Lemburg added the comment: On 07.06.2016 16:59, Christian Heimes wrote: > > Christian Heimes added the comment: > > On 2016-06-07 16:49, Marc-Andre Lemburg wrote: >> This gives people a clear choice and doesn't cause people >> to have to reconsider using the random module or wait for >> Python hash randomization to initialize itself when using >> Python during VM/container/system startup. >> >> I don't really appreciate this approach to break Python in >> cloud setups just because some entropy pool is not initialized, >> which only a tiny fraction of users care about. It doesn't >> make Python land a better place. > > VM and cloud setup without a proper CPRNG source are plain broken. True > fact! > > Secure entropy sources are a fundamental resource for all modern > applications. Please start treating CPRNG like RAM, CPU or disks. You > wouldn't add a workaround for broken CPU instructions to math.c or > semi-functional network card to socket.c, would you? For security relevant applications, I agree and for those I question the use of os.urandom() altogether (see my other replies), but for everything else, a PRNG is just fine. I'm repeating myself, but making users believe that an entropy source is more important that preventing a denial of service just won't work out. You're position is quite similar to the one that others have taken with the I/O encoding in Python3. Their stance was "fix your system and it'll work". Well, tell that to 9-year olds who want to learn Python. Likewise, it may be easy for you to track down the reason why Python 3.5.1 isn't working in your VM or container, but not everyone knows that there's an entropy source which needs to be connected to your VM or container to make things work - and even if they do know about the problem they may not have the means to do so. It's pretty much the same situation and the reason why we have "practicality beats purity". A hanging Python process is the worst of all user experiences. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 11:10:54 2016 From: report at bugs.python.org (Colm Buckley) Date: Tue, 07 Jun 2016 15:10:54 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465312254.13.0.0484530226069.issue26839@psf.upfronthosting.co.za> Colm Buckley added the comment: Christian - Please note: this is *not* just a VM/cloud issue. This is observed on physical standalone systems. The issue (on Debian) is that the Python script xxxx is called very early in the boot process; in particular before most hardware initialization is done. As there are yet no network or USB devices configured, there is no entropy pool to speak of. We observe that getrandom() blocks apparently indefinitely under these circumstances (even though this script has no requirement for random data apart from the hash secret). My final suggestion is that we return to using a command-line flag to indicate our preferences regarding hash seed initialization; although reverse the sense compared to the -R flag in 3.2.3 (ie: default is to use strong initialization, but allow the user to over-ride just as though PYTHONHASHSEED were set in the environment.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 11:17:52 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 07 Jun 2016 15:17:52 +0000 Subject: [issue23401] Add pickle support of Mapping views In-Reply-To: <1465291389.3.0.736035584608.issue23401@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: No, it should just be up to the implementation. Though you might add a note to the docs explaining that it's probably a misguided idea. On Tue, Jun 7, 2016 at 2:23 AM, Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > Should we forbid pickling MappingView? > > And what about copying and deepcopying? > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 11:23:06 2016 From: report at bugs.python.org (paul j3) Date: Tue, 07 Jun 2016 15:23:06 +0000 Subject: [issue9253] argparse: optional subparsers In-Reply-To: <1279056589.03.0.566167994161.issue9253@psf.upfronthosting.co.za> Message-ID: <1465312986.81.0.210854528315.issue9253@psf.upfronthosting.co.za> paul j3 added the comment: My answer to http://stackoverflow.com/questions/23349349/argparse-with-required-subparser is getting a slow but steady stream of + scores; so the `required subparser` issue is still bothering people. This particular question addresses the problem that the error message has when a required subparser is missing - it can't format the error with the default dest - SUPPRESS. The may be a another bug issue that addresses that. Anyways, due to this continued attention, I'm going to raise the priority for this issue. ---------- priority: low -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 11:23:32 2016 From: report at bugs.python.org (Colm Buckley) Date: Tue, 07 Jun 2016 15:23:32 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465313012.92.0.37365662341.issue26839@psf.upfronthosting.co.za> Colm Buckley added the comment: ... the script is /lib/systemd/system-generators/systemd-crontab-generator, although that's not hugely germane to the discussion. Arranging for PYTHONHASHSEED to be set while it's called wouldn't be impossible of course, although a command-line flag would be easier and probably safer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 11:32:08 2016 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jun 2016 15:32:08 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465313528.25.0.28741946964.issue26839@psf.upfronthosting.co.za> Larry Hastings added the comment: > PSRT VETO! This is an amusing concept, but membership in the PSRT does not empower you with a "veto". On the other hand, being Release Manager does give me some say here. > You wouldn't add a workaround for broken CPU instructions to math.c or semi-functional network card to socket.c, would you? Well, yes, of course we would, if we had to. Consider the F00F bug. Happily the operating systems handled that one for us. It is unreasonable for Python startup to take 90 seconds, poorly-configured cloud virtual machine or otherwise. And there are many, many uses of the random module and hashlib that don't require CPRNG. On the other hand, people who need cryptographic-strength random bits should be able to get them. And the documentation literally does state that os.urandom() is a source of cryptographically-suitable random bytes. ISTM that the happy middle ground would be: * seed the random module with non-cryptographically-secure random bits * lazily seed hashlib Am I missing something, besides the anxiety of making this sort of change four days before I tag 3.5.2 RC2? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 11:35:49 2016 From: report at bugs.python.org (Donald Stufft) Date: Tue, 07 Jun 2016 15:35:49 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465313749.54.0.281951571849.issue26839@psf.upfronthosting.co.za> Donald Stufft added the comment: > Please note: this is *not* just a VM/cloud issue. This is observed on physical standalone systems. But it should only occur on initial boot I believe? AFAIK all of the major linux vendors have stored a seed file once the machine has been booted and the pool has been initialized to use to seed the pool on subsequent boots. I suppose it's possible that /lib/systemd/system-generators/systemd-crontab-generator is running prior to Debian reseeding the pool from that seed file, but it seems like it should be doing the reseeding as early as possible? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 11:39:12 2016 From: report at bugs.python.org (Donald Stufft) Date: Tue, 07 Jun 2016 15:39:12 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465313952.91.0.0647615308962.issue26839@psf.upfronthosting.co.za> Donald Stufft added the comment: > ISTM that the happy middle ground would be: > * seed the random module with non-cryptographically-secure random bits > * lazily seed hashlib I don't think it was actually hashlib that was causing the problem, but rather the initialization of SipHash, it just so happened that hashlib was the first import and thus was getting the blame. I could be wrong about that though. In any case, I think it's perfectly reasoanble to seed the random module with non-cryptographically-secure random bits and if applicable lazily seed hashlib. I also think it's reasonable to seed SipHash with possibly non-cryptographically-secure random bits since it's likely to only be a problem early on in the boot cycle. Another option is as Colm suggestion, allowing the inverse of the old -R flag, to turn off hash seed randomization from the CLI so that scripts that run early on in the boot process can disable hash seed randomization and not require reading from urandom (assuming of course, they don't do something that explicitly calls os.urandom). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 11:42:32 2016 From: report at bugs.python.org (Christian Heimes) Date: Tue, 07 Jun 2016 15:42:32 +0000 Subject: [issue26556] Update expat to 2.2.1 In-Reply-To: <1457951495.3.0.910401967595.issue26556@psf.upfronthosting.co.za> Message-ID: <1465314152.87.0.082384424073.issue26556@psf.upfronthosting.co.za> Christian Heimes added the comment: There is another security release for expat planned, but we can skip it for now. I'll provide a patch for Python 2 and 3 with 2.1.1 by tomorrow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 11:45:38 2016 From: report at bugs.python.org (=?utf-8?q?Th=C3=A9o_Bueno?=) Date: Tue, 07 Jun 2016 15:45:38 +0000 Subject: [issue27251] TypeError in logging.HTTPHandler.emit; possible python 2 to 3 conversion issue Message-ID: <1465314338.49.0.176049462957.issue27251@psf.upfronthosting.co.za> New submission from Th?o Bueno: When trying to log a message with a registered HTTPHandler, using http authentication (by specifying a credentials tuple when constructing an HTTPHandler): logging/handlers.py, in HTTPHandler.emit: if self.credentials: import base64 s = ('u%s:%s' % self.credentials).encode('utf-8') s = 'Basic ' + base64.b64encode(s).strip() # TypeError: Can't convert 'bytes' object to str implicitly h.putheader('Authorization', s) It sounds like a python 2 to 3 conversion issue. I also want to point out that there is no test covering http authentication in HTTPHandler. ---------- components: Library (Lib) messages: 267698 nosy: munrek priority: normal severity: normal status: open title: TypeError in logging.HTTPHandler.emit; possible python 2 to 3 conversion issue versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 12:04:21 2016 From: report at bugs.python.org (Colm Buckley) Date: Tue, 07 Jun 2016 16:04:21 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465315461.98.0.174674237919.issue26839@psf.upfronthosting.co.za> Colm Buckley added the comment: Donald - To be clear - no import of random or of hashlib is required to trigger this issue. The null script alone triggers the issue; the Python hash secret is initialized at startup regardless of script contents. Yes, there is a race condition at system boot which we can probably resolve with userspace manipulations. I still feel that having Python hang indefinitely under certain circumstances, even when the application does not require any entropy, is a violation of the principle of least surprise. At the very least, there should be a command-line flag to disable "secure" initialization of the hash secret. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 12:05:00 2016 From: report at bugs.python.org (Christian Heimes) Date: Tue, 07 Jun 2016 16:05:00 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1465315500.01.0.0061925496978.issue21470@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 12:08:41 2016 From: report at bugs.python.org (shakur shams Mullick) Date: Tue, 07 Jun 2016 16:08:41 +0000 Subject: [issue21130] equivalent functools.partial instances should compare equal In-Reply-To: <1396425472.15.0.80240218298.issue21130@psf.upfronthosting.co.za> Message-ID: <1465315721.44.0.865826983344.issue21130@psf.upfronthosting.co.za> shakur shams Mullick added the comment: Submitted a new patch addressing the review comments. ---------- Added file: http://bugs.python.org/file43279/issue_21130_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 12:24:39 2016 From: report at bugs.python.org (SilentGhost) Date: Tue, 07 Jun 2016 16:24:39 +0000 Subject: [issue27251] TypeError in logging.HTTPHandler.emit; possible python 2 to 3 conversion issue In-Reply-To: <1465314338.49.0.176049462957.issue27251@psf.upfronthosting.co.za> Message-ID: <1465316679.85.0.300515453158.issue27251@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +vinay.sajip stage: -> test needed type: -> behavior versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 12:27:29 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jun 2016 16:27:29 +0000 Subject: [issue27252] Make dict views copyable Message-ID: <1465316849.69.0.0784684578474.issue27252@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch adds support of dict views in the copy module. Since dict views are immutable, copy.copy() just returns the same object. copy.deepcopy() returns a frozenset for the dict_keys object, a tuple for the dict_values object, and a dict_items object for the dict_items object. Only needed data is copied (keys for dict_keys, values for dict_values). ---------- components: Library (Lib) files: dict_views_copy.patch keywords: patch messages: 267701 nosy: gvanrossum, rhettinger, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Make dict views copyable type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43280/dict_views_copy.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 12:31:10 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jun 2016 16:31:10 +0000 Subject: [issue23401] Add pickle support of Mapping views In-Reply-To: <1423216735.87.0.773240969368.issue23401@psf.upfronthosting.co.za> Message-ID: <1465317070.49.0.936748881498.issue23401@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: OK, then I withdraw my proposition. Thank you for your attention Raymond and Guido. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 12:39:56 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 07 Jun 2016 16:39:56 +0000 Subject: [issue27252] Make dict views copyable In-Reply-To: <1465316849.69.0.0784684578474.issue27252@psf.upfronthosting.co.za> Message-ID: <1465317596.48.0.951649678597.issue27252@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'm still not clear about the use case -- have you heard from people who had to work around the current situation? Use of the copy module is often a code smell in my experience, so I don't want to encourage it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 12:56:28 2016 From: report at bugs.python.org (Matthias Bussonnier) Date: Tue, 07 Jun 2016 16:56:28 +0000 Subject: [issue25548] Show the address in the repr for class objects In-Reply-To: <1446576011.58.0.372024983976.issue25548@psf.upfronthosting.co.za> Message-ID: <1465318588.88.0.0175881274785.issue25548@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: Hi guys, the title of the issues is "show address in the **repR**", but the NEWS file says[1] in the **repL*, which are 2 different things ! :-) And this patch change the repR so it also affect scripts and unittests. [1] since https://hg.python.org/cpython/rev/af29d89083b3 ---------- nosy: +mbussonn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 13:16:13 2016 From: report at bugs.python.org (Colm Buckley) Date: Tue, 07 Jun 2016 17:16:13 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465319773.74.0.523664387778.issue26839@psf.upfronthosting.co.za> Colm Buckley added the comment: Larry - I see at least two issues here, although they are related: * blocking initialization of the hash secret. This occurs regardless of script contents; at present Python simply can't be used at all in low-entropy situations. I feel that this issue is a release blocker. Possible resolutions: * accept possible low-entropy initialization of the hash secret; using the patches supplied here by myself and Victor. * add a command-line flag to disable "strong" initialization of the hash secret (or revive the old -R flag). * simply require user-space workarounds like setting PYTHONHASHSEED * blocking random reads during import hashlib or import random. This is more complex, as we need to take developer intentions into account. I do *not* think that these are release blockers as there are reasonably easy workarounds, however the fact remains that there has been a regression in Python's behavior on Linux. Possible resolutions: * accept Victor's existing changeset without my nonblocking_urandom_noraise patch, which makes _PyOS_URandom nonblocking in all Linux cases. * resolve as above (both Victor's and my patches), and require that applications be modified to work correctly * require modifications to hashlib.py and random.py to use nonblocking sources and/or raise exceptions accordingly. I see these largely as policy decisions rather than technical ones. The security implications of the first issue are fairly small (I would be interested in PSRT's assessment of an actual attack on a predictable hash secret); of the second issue rather larger and probably unquantifiable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 13:35:13 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jun 2016 17:35:13 +0000 Subject: [issue27253] More efficient deepcopying of Mapping Message-ID: <1465320913.02.0.739523600127.issue27253@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Mapping views supports copying and deepcopying by default (using pickle protocol). But copy.deepcopy() is not efficient for KeysView and ValuesView. It copies all keys and values, while KeysView needs copying only keys and ValuesView needs copying only values. Proposed patch implements more efficient deepcopy support for KeysView and ValuesView. ---------- components: Library (Lib) files: MappingView_deepcopy.patch keywords: patch messages: 267706 nosy: gvanrossum, rhettinger, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: More efficient deepcopying of Mapping type: resource usage versions: Python 3.6 Added file: http://bugs.python.org/file43281/MappingView_deepcopy.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 13:36:53 2016 From: report at bugs.python.org (Donald Stufft) Date: Tue, 07 Jun 2016 17:36:53 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465321013.78.0.318947100547.issue26839@psf.upfronthosting.co.za> Donald Stufft added the comment: > Possible resolutions: > * accept possible low-entropy initialization of the hash secret; using the patches supplied here by myself and Victor. > * add a command-line flag to disable "strong" initialization of the hash secret (or revive the old -R flag). > * simply require user-space workarounds like setting PYTHONHASHSEED I think either the first or second here are good solutions, the third is kind of crummy on it's own because it's not always possible to pass in an environment variable. Pairing the third with a CLI flag option might work out nice though, perhaps a -XPYTHONHASHSEED=(random/int()) or something. Then folks who are in early boot can easily just hardcode a hash seed, removing the need to hit the entropy pools while still maintaining strong random for everyone else. So I guess I would lean towards adding a CLI flag, but just allowing SipHash to fall back to possibly bad randomness for it's initialization is OK. > * accept Victor's existing changeset without my nonblocking_urandom_noraise patch, which makes _PyOS_URandom nonblocking in all Linux cases. > * resolve as above (both Victor's and my patches), and require that applications be modified to work correctly > * require modifications to hashlib.py and random.py to use nonblocking sources and/or raise exceptions accordingly. Of these, I think random.py should just not use a CSPRNG, it's not required for it so there's no reason to do it. I don't think there's actually any problem with hashlib, I don't see any use of random in it. > I would be interested in PSRT's assessment of an actual attack on a predictable hash secret For something like systemd-crontab-generator, basically nothing-- for anything short lived or which does not provide a means for arbitrary users to put data into a dictionary. IOW, it's largely persistent network services. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 13:44:17 2016 From: report at bugs.python.org (Chris Rebert) Date: Tue, 07 Jun 2016 17:44:17 +0000 Subject: [issue23670] Modifications to support iOS as a cross-compilation target In-Reply-To: <1426400747.11.0.0527548590348.issue23670@psf.upfronthosting.co.za> Message-ID: <1465321457.41.0.130715924867.issue23670@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 13:45:50 2016 From: report at bugs.python.org (Evelyn Mitchell) Date: Tue, 07 Jun 2016 17:45:50 +0000 Subject: [issue27180] Doc/pathlib: Please describe the behaviour of Path().rename() is depends on the platform (same as os.rename()) In-Reply-To: <1464866299.22.0.549959469595.issue27180@psf.upfronthosting.co.za> Message-ID: <1465321550.41.0.299019605283.issue27180@psf.upfronthosting.co.za> Evelyn Mitchell added the comment: *** cpythonmod/Doc/library/pathlib.rst 2016-06-07 11:29:07.200774979 -0600 --- cpython/Doc/library/pathlib.rst 2016-06-07 11:29:59.372777817 -0600 *************** *** 887,896 **** .. method:: Path.rename(target) ! Rename this file or directory to the given *target*. On Unix, ! if *target* exists and is a file, it will be replaced silently ! if the user has permission. *target* can be either a string or ! another path object:: >>> p = Path('foo') >>> p.open('w').write('some text') --- 887,894 ---- .. method:: Path.rename(target) ! Rename this file or directory to the given *target*. *target* can be ! either a string or another path object:: >>> p = Path('foo') >>> p.open('w').write('some text') ---------- nosy: +Evelyn Mitchell _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 13:46:03 2016 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jun 2016 17:46:03 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465321563.56.0.481398326991.issue26839@psf.upfronthosting.co.za> Larry Hastings added the comment: Thank you for summarizing the debate. It made it a lot easier to > * blocking initialization of the hash secret. This occurs regardless of script contents; at present Python simply can't be used at all in low-entropy situations. I feel that this issue is a release blocker. > > Possible resolutions: > * accept possible low-entropy initialization of the hash secret; using the patches supplied here by myself and Victor. > * add a command-line flag to disable "strong" initialization of the hash secret (or revive the old -R flag). > * simply require user-space workarounds like setting PYTHONHASHSEED The latter two approaches are unacceptable IMO. They result in a poor user experience. Python should do the "right" thing by default; the "right" thing includes not taking 90 seconds to start up. By process of elimination, this leaves only the first approach as viable. Ergo, let's do that. The hash secret is a 32-bit integer, even on 64-bit builds of Python. It is not and cannot be cryptographically secure. It's frankly ridiculous to fret about "strong" initialization of it at the cost of a 90 second startup time. (For posterity: when people mention "SipHash", they're talking about the hashing algorithm used for str/dict/etc. The seed for SipHash is the "hash secret" we're talking about here.) > * blocking random reads during import hashlib or import random. This is more complex, as we need to take developer intentions into account. I do *not* think that these are release blockers as there are reasonably easy workarounds, however the fact remains that there has been a regression in Python's behavior on Linux. > > Possible resolutions: > > * accept Victor's existing changeset without my nonblocking_urandom_noraise patch, which makes _PyOS_URandom nonblocking in all Linux cases. > * resolve as above (both Victor's and my patches), and require that applications be modified to work correctly > * require modifications to hashlib.py and random.py to use nonblocking sources and/or raise exceptions accordingly. I don't follow whose patch does what. But here's what I find acceptable, from a high level. * The semantics as presented by the documentation must be preserved. os.urandom() and other operations that declare they're safe for cryptographic use must remain safe for cryptographic use. * "import random" must not block. * "import hashlib" must not block. Is there a patch set that accomplishes that? -- If this means that random.random() may be seeded with poor-quality random bits, so be it. As I think I already stated in this thread: there are many non-cryptographic uses for random.random(). And the documentation for the random module already states that it's not suitable for cryptography. So making it block in order to procure a cryptographically-strong seed is counterproductive. Also, I think the constraint "import hashlib must not block" is a non-issue. I preserved it above just in case I missed something. But Colm was the one who suggested "import hashlib" was blocking, and he quickly said afterwards that he was mistaken. In any case a quick review of the code suggests that hashlib never uses getrandom and thus should not currently block. Unless someone says otherwise, I'll assume hashlib is fine, never blocks on import, and thus requires no modification. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 13:47:40 2016 From: report at bugs.python.org (Chris Rebert) Date: Tue, 07 Jun 2016 17:47:40 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1465321660.66.0.34166487662.issue23496@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 13:52:01 2016 From: report at bugs.python.org (Donald Stufft) Date: Tue, 07 Jun 2016 17:52:01 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465321921.55.0.629558740358.issue26839@psf.upfronthosting.co.za> Donald Stufft added the comment: > I don't follow whose patch does what. But here's what I find acceptable, from a high level. > > * The semantics as presented by the documentation must be preserved. os.urandom() and other operations that declare they're safe for cryptographic use must remain safe for cryptographic use. > * "import random" must not block. > * "import hashlib" must not block. > > Is there a patch set that accomplishes that? I *think* nonblocking_urandom_noraise.patch will solve the 90+ second start up without affecting os.urandom which should solve the first one (once the already applied patch gets reverted), but I'm afraid I don't know C well enough to meaningfully review that for accuracy. None of the current patches solve the second without invalidating the first, but it would be, I believe, an additional patch ontop of nonblocking_urandom_noraise.patch. The third is already the case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 13:53:19 2016 From: report at bugs.python.org (Christian Heimes) Date: Tue, 07 Jun 2016 17:53:19 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1465321563.56.0.481398326991.issue26839@psf.upfronthosting.co.za> Message-ID: Christian Heimes added the comment: On 2016-06-07 19:46, Larry Hastings wrote: > > Larry Hastings added the comment: > > Thank you for summarizing the debate. It made it a lot easier to > >> * blocking initialization of the hash secret. This occurs regardless of script contents; at present Python simply can't be used at all in low-entropy situations. I feel that this issue is a release blocker. >> >> Possible resolutions: >> * accept possible low-entropy initialization of the hash secret; using the patches supplied here by myself and Victor. >> * add a command-line flag to disable "strong" initialization of the hash secret (or revive the old -R flag). >> * simply require user-space workarounds like setting PYTHONHASHSEED > > The latter two approaches are unacceptable IMO. They result in a poor user experience. Python should do the "right" thing by default; the "right" thing includes not taking 90 seconds to start up. > > By process of elimination, this leaves only the first approach as viable. Ergo, let's do that. > > The hash secret is a 32-bit integer, even on 64-bit builds of Python. It is not and cannot be cryptographically secure. It's frankly ridiculous to fret about "strong" initialization of it at the cost of a 90 second startup time. > > (For posterity: when people mention "SipHash", they're talking about the hashing algorithm used for str/dict/etc. The seed for SipHash is the "hash secret" we're talking about here.) The secret for SipHash is composed of two 64bit integers. The entire _Py_HashSecret_t struct is 24 bytes. The remaining 8 bytes are used for XML hash randomization of libexpat. Only the manual seed with PYTHONHASHSEED is a 32bit integer which is stretched to 24 bytes with a LCG. Christian ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 13:59:54 2016 From: report at bugs.python.org (Christian Heimes) Date: Tue, 07 Jun 2016 17:59:54 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1465321013.78.0.318947100547.issue26839@psf.upfronthosting.co.za> Message-ID: <9c115560-4e17-7092-ef76-dceda885873b@cheimes.de> Christian Heimes added the comment: On 2016-06-07 19:36, Donald Stufft wrote: > > Donald Stufft added the comment: > >> Possible resolutions: >> * accept possible low-entropy initialization of the hash secret; using the patches supplied here by myself and Victor. >> * add a command-line flag to disable "strong" initialization of the hash secret (or revive the old -R flag). >> * simply require user-space workarounds like setting PYTHONHASHSEED > > I think either the first or second here are good solutions, the third is kind of crummy on it's own because it's not always possible to pass in an environment variable. Pairing the third with a CLI flag option might work out nice though, perhaps a -XPYTHONHASHSEED=(random/int()) or something. Then folks who are in early boot can easily just hardcode a hash seed, removing the need to hit the entropy pools while still maintaining strong random for everyone else. > > So I guess I would lean towards adding a CLI flag, but just allowing SipHash to fall back to possibly bad randomness for it's initialization is OK. I don't like the fact that applications can fall back to insecure RNG without user involvement or warning. Therefore I'm in favor of a command line argument that allows pyhash.c to fall back to a less secure RNG. System scripts must use the -I option (isolated mode without user-site dir and PY* env vars) anyway. The new option would enable less secure RNG as fallback and -I. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 14:24:14 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jun 2016 18:24:14 +0000 Subject: [issue27252] Make dict views copyable In-Reply-To: <1465316849.69.0.0784684578474.issue27252@psf.upfronthosting.co.za> Message-ID: <1465323854.49.0.271250234848.issue27252@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I didn't encounter this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 14:29:01 2016 From: report at bugs.python.org (Emin Ghuliev) Date: Tue, 07 Jun 2016 18:29:01 +0000 Subject: [issue27254] heap overflow in Tkinter module Message-ID: <1465324141.01.0.361051063774.issue27254@psf.upfronthosting.co.za> New submission from Emin Ghuliev: /* This is used to get the application class for Tk 4.1 and up */ argv0 = (char*)attemptckalloc(strlen(className) + 1); //<=== classname allocated if (!argv0) { PyErr_NoMemory(); Py_DECREF(v); return NULL; } strcpy(argv0, className); <==== //classname copy to argv0 if (Py_ISUPPER(Py_CHARMASK(argv0[0]))) argv0[0] = Py_TOLOWER(Py_CHARMASK(argv0[0])); Tcl_SetVar(v->interp, "argv0", argv0, TCL_GLOBAL_ONLY); // argv0 passed to v->interp and freed; ckfree(argv0); then v->interp passed to the Tcl_AppInit function if (Tcl_AppInit(v->interp) != TCL_OK) in Tcl_AppInit call to (and passed the v->interp) the Tcl_DStringAppend. allocates the specified byte Tcl_DStringAppend function then heap memory passed to memcpy. Realloc arguments presentation in the native tcl allocator; char * Tcl_Realloc(ptr, size) disassemble: gdb> print /x $rdi $4 = 0x7ffff03c8810 0x7ffff03c8814: 0x41414141 ....... gdb> print /x $rsi $2 = 0x3ffffe 0x00007ffff3a07dfe <+46>: call 0x7ffff3935040 after return to the caller function. Performed memory copy operation. 0x00007ffff3a07e0a <+58>: lea rdi,[rax+rdx*1] < === destination buffer $rax = 0x7fffeffc5810 - $rdx = 0x100000 $rax+$rdx = 0x7ffff00c5810 0x00007ffff3a07e0e <+62>: mov rsi,r12 < === source buffer 0x00007ffff3a07e11 <+65>: movsxd rdx,ebp <=== 0xfffff 0x00007ffff3a07e14 <+68>: call 0x7ffff39155c0 copy to $rdi bytes to $rsi buffer with 0xfffff byte; ASAN report. ================================================================= ==27988==ERROR: AddressSanitizer: heap-use-after-free on address 0x7f4e6ba64810 at pc 0x4665ea bp 0x7fff89a4ab80 sp 0x7fff89a4a340 READ of size 1048575 at 0x7f4e6ba64810 thread T0 ==27988==WARNING: Trying to symbolize code, but external symbolizer is not initialized! #0 0x4665e9 (/home/eminus/Downloads/Python-2.7.11/python+0x4665e9) #1 0x7f4e6f0a3e18 (/usr/lib/x86_64-linux-gnu/libtcl8.6.so+0x116e18) #2 0x7f4e6f38744e (/usr/lib/x86_64-linux-gnu/libtk8.6.so+0x6244e) #3 0x7f4e6f6b6e4c (/home/eminus/Downloads/Python-2.7.11/build/lib.linux-x86_64-2.7/_tkinter.so+0x19e4c) #4 0x7f4e6f6a7fc5 (/home/eminus/Downloads/Python-2.7.11/build/lib.linux-x86_64-2.7/_tkinter.so+0xafc5) #5 0x5e1813 (/home/eminus/Downloads/Python-2.7.11/python+0x5e1813) #6 0x5d319c (/home/eminus/Downloads/Python-2.7.11/python+0x5d319c) #7 0x721353 (/home/eminus/Downloads/Python-2.7.11/python+0x721353) #8 0x4acb2a (/home/eminus/Downloads/Python-2.7.11/python+0x4acb2a) #9 0x4b6c62 (/home/eminus/Downloads/Python-2.7.11/python+0x4b6c62) #10 0x4acb2a (/home/eminus/Downloads/Python-2.7.11/python+0x4acb2a) #11 0x5f0823 (/home/eminus/Downloads/Python-2.7.11/python+0x5f0823) #12 0x4b0a08 (/home/eminus/Downloads/Python-2.7.11/python+0x4b0a08) #13 0x4acb2a (/home/eminus/Downloads/Python-2.7.11/python+0x4acb2a) #14 0x5e2d19 (/home/eminus/Downloads/Python-2.7.11/python+0x5e2d19) #15 0x5d319c (/home/eminus/Downloads/Python-2.7.11/python+0x5d319c) #16 0x5d2041 (/home/eminus/Downloads/Python-2.7.11/python+0x5d2041) #17 0x660980 (/home/eminus/Downloads/Python-2.7.11/python+0x660980) #18 0x65fc8a (/home/eminus/Downloads/Python-2.7.11/python+0x65fc8a) #19 0x48e46c (/home/eminus/Downloads/Python-2.7.11/python+0x48e46c) #20 0x7f4e72389ec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4) #21 0x48c5bc (/home/eminus/Downloads/Python-2.7.11/python+0x48c5bc) 0x7f4e6ba64810 is located 16 bytes inside of 2097166-byte region [0x7f4e6ba64800,0x7f4e6bc6480e) freed by thread T0 here: #0 0x4766d3 (/home/eminus/Downloads/Python-2.7.11/python+0x4766d3) #1 0x7f4e6f09b52d (/usr/lib/x86_64-linux-gnu/libtcl8.6.so+0x10e52d) previously allocated by thread T0 here: #0 0x4764d9 (/home/eminus/Downloads/Python-2.7.11/python+0x4764d9) #1 0x7f4e6f09b0cc (/usr/lib/x86_64-linux-gnu/libtcl8.6.so+0x10e0cc) SUMMARY: AddressSanitizer: heap-use-after-free ??:0 ?? Shadow bytes around the buggy address: 0x0fea4d7448b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0fea4d7448c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0fea4d7448d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0fea4d7448e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0fea4d7448f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0fea4d744900: fd fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0fea4d744910: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0fea4d744920: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0fea4d744930: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0fea4d744940: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0fea4d744950: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 ASan internal: fe ==27988==ABORTING PoC from Tkinter import * class Application(Frame): def say_hi(self): print ("hi there, everyone!") def createWidgets(self): self.QUIT = Button(self) self.QUIT["text"] = "QUIT" self.QUIT["fg"] = "red" self.QUIT["command"] = self.quit self.QUIT.pack({"side": "left"}) self.hi_there = Button(self) self.hi_there["text"] = "Hello", self.hi_there["command"] = self.say_hi self.hi_there.pack({"side": "left"}) def __init__(self, master=None): Frame.__init__(self, master) self.pack() self.createWidgets() root = Tk(screenName=None, baseName=None, className='A'*0xfffff, useTk=1) app = Application(master=root) app.mainloop() root.destroy() ---------- components: Tkinter messages: 267714 nosy: Emin Ghuliev priority: normal severity: normal status: open title: heap overflow in Tkinter module type: security versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 14:29:04 2016 From: report at bugs.python.org (Donald Stufft) Date: Tue, 07 Jun 2016 18:29:04 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465324144.64.0.466557905701.issue26839@psf.upfronthosting.co.za> Donald Stufft added the comment: I've attached a minimal patch for making it so ``import random`` does not block, it does this by changing what the default instance of Random() is seeded with, from os.urandom() to the time based fallback it currently employs. It does not change the behavior of any documented behavior that I can see (it's documented that calling seed(None) or seed() will use urandom if available). This could be improved by mixing in id(self) and using SipHash or LCG on the value, but this represents a minimal patch that is already possible in cases where os.urandom doesn't exist. ---------- Added file: http://bugs.python.org/file43282/no-urandom-by-default.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 14:34:05 2016 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jun 2016 18:34:05 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465324445.13.0.194520860741.issue26839@psf.upfronthosting.co.za> Larry Hastings added the comment: Everybody: let's drop discussing "hashlib" unless someone says it actually is a problem. I think it was always, as we say in English, a "red herring". > The secret for SipHash is composed of two 64bit integers. The entire _Py_HashSecret_t struct is 24 bytes. The remaining 8 bytes are used for XML hash randomization of libexpat. Only the manual seed with PYTHONHASHSEED is a 32bit integer which is stretched to 24 bytes with a LCG. Okay, I have misunderstood the code. Have I misunderstood the strength of SipHash? Is it regarded as "cryptographically secure"? Predictability of the hash function on web servers was the original use case of the "hash seed"; I remember a demonstration of an attack where the attacker produced pathologically bad hash behavior on a Python-based web server with very little data. So it seems like web servers running on cloud instances is exactly the sort of use case where we'd want less-predictable hashing. -- Nevertheless, a 90 second startup time is simply unacceptable. I am officially making a pronouncement as Release Manager: Python 3.5 *must not* take 90 seconds to start up under *any* circumstances. I view this as a performance regression, and it is and will remain a release blocker for 3.5.2. Python *must not* require special command-line flags to avoid a 90 second startup time. Python *must not* require a special environment-variable to avoid a 90 second startup time. This is no longer open to debate, and I will only be overruled by Guido. -- If I understand the technical issues correctly, here's how I expect it to work. For seeding the hash randomization, and seeding the _inst in the random module, we will use getrandom() in a non-blocking way (GRND_NONBLOCK?). If it succeeds, we use those bits. If it fails because it would have blocked (EAGAIN?), we fall back to a less-random source of random bits. Under no circumstances will Python block when seeding the hash randomization function or seeding the MT for the random module. This means cloud instances may inadvertently use lower-quality hash randomization seeds. I judge this as obviously better than cloud instances taking 90 seconds to start up. Also, as Christian points out, the people running these cloud instances should be managing their entropy pools anyway. Additionally, there are many uses of cloud instances that aren't exposed to tainted data that permit these predictable-hash abuses. -- As a final note, let me steer you towards this comment in Python/random.c: /* Issue #25003: Don' use getentropy() on Solaris (available since * Solaris 11.3), it is blocking whereas os.urandom() should not block. */ Yes: we already had this discussion for Solaris, nine months ago, on issue #25003. Both Guido and Tim Peters were involved in the discussion. The decision there: use lower-quality random bits to seed the MT when importing the random module. Keeping the slowdown was so obviously wrong it wasn't even debated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 14:35:30 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 07 Jun 2016 18:35:30 +0000 Subject: [issue27252] Make dict views copyable In-Reply-To: <1465316849.69.0.0784684578474.issue27252@psf.upfronthosting.co.za> Message-ID: <1465324530.25.0.0274870758931.issue27252@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I think we should stop adding features like this without actual user requests and real use cases to show necessity and to inform the design. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 14:40:30 2016 From: report at bugs.python.org (Donald Stufft) Date: Tue, 07 Jun 2016 18:40:30 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465324830.38.0.386348299025.issue26839@psf.upfronthosting.co.za> Donald Stufft added the comment: > As a final note, let me steer you towards this comment in Python/random.c: > > /* Issue #25003: Don' use getentropy() on Solaris (available since > * Solaris 11.3), it is blocking whereas os.urandom() should not block. */ > > Yes: we already had this discussion for Solaris, nine months ago, on issue #25003. Both Guido and Tim Peters were involved in the discussion. The decision there: use lower-quality random bits to seed the MT when importing the random module. Keeping the slowdown was so obviously wrong it wasn't even debated. I will point out, that was a somewhat different situation as ``getentropy`` on Solaris is more like /dev/random in that it tries to decide how much random-ness is in the pool and will randomly block throughout the execution of the program. The ``getrandom()`` call on Linux (and Solaris) will, by default, only block on the first boot at the very beginning before the kernel has collected enough entropy. I don't think this changes anything, I just want to be clear because there are two kinds of "blocking" in this discussion, one that only occurs in very specific scenarios and one that occurs regularly in the operation of the program. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 14:41:44 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jun 2016 18:41:44 +0000 Subject: [issue27255] More opcode predictions Message-ID: <1465324904.47.0.783952984943.issue27255@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Currently the PREDICT() macros is used for predicticting following pair of opcodes in the ceval loop: LIST_APPEND JUMP_ABSOLUTE SET_ADD JUMP_ABSOLUTE MAP_ADD JUMP_ABSOLUTE COMPARE_OP POP_JUMP_IF_FALSE COMPARE_OP POP_JUMP_IF_TRUE GET_ITER FOR_ITER FOR_ITER STORE_FAST (if continue iterating) FOR_ITER UNPACK_SEQUENCE (if continue iterating) WITH_CLEANUP_START WITH_CLEANUP_FINISH WITH_CLEANUP_FINISH END_FINALLY I collected static and dynamic opcode statistics. Static statistics is a statistics about what opcodes are used in code objects after running the compileall script on the Lib directory. Dynamic statistics is is a statistics about what opcodes are executed when run all Python tests. Resulting numbers are close, but there are some reasonable differences (opcodes used in loops have larger numbers in dynamic statistics, and opcodes used for creating classes and functions have larger numbers in static statistics). In following lines the fist number is from dynamic statistics and the second number is from static statistics. LIST_APPEND, SET_ADD and MAP_ADD are always followed by JUMP_ABSOLUTE. COMPARE_OP is followed by POP_JUMP_IF_FALSE in 83% (78%) and by POP_JUMP_IF_TRUE in 13% (5%). GET_ITER is followed by FOR_ITER in 72% (80%) and CALL_FUNCTION in 28% (28%). FOR_ITER is followed by STORE_FAST in 50% (80%), UNPACK_SEQUENCE in 21% (18%) and POP_BLOCK in 20% (0%). WITH_CLEANUP_START is always followed by WITH_CLEANUP_FINISH. WITH_CLEANUP_FINISH is always followed by END_FINALLY According to this statistic existing predictions are correct. But the statistics suggests other predictions. JUMP_ABSOLUTE is followed by FOR_ITER in 77% (0%). UNPACK_SEQUENCE is followed by STORE_FAST in 97% (94%). SETUP_LOOP is followed by LOAD_FAST in 81% (52%) and LOAD_GLOBAL in 18% (31%). BUILD_SLICE is followed by BINARY_SUBSCR in 99% (87%). ROT_TWO is followed by STORE_FAST in 85% (40%). LOAD_CLOSURE is followed by BUILD_TUPLE in 94% (68%). SETUP_WITH is followed by POP_TOP in 94% (54%) and STORE_FAST in 6% (44%). GET_YIELD_FROM_ITER, GET_AITER, GET_ANEXT and GET_AWAITABLE are always followed by LOAD_CONST. DUP_TOP_TWO is always followed by BINARY_SUBSCR. BEFORE_ASYNC_WITH is always followed by GET_AWAITABLE. All INPLACE_ instructions almost always are followed by STORE_FAST. Proposed patch adds predictions of following pairs: DUP_TOP_TWO BINARY_SUBSCR INPLACE_POWER STORE_FAST INPLACE_MULTIPLY STORE_FAST INPLACE_MATRIX_MULTIPLY STORE_FAST INPLACE_TRUE_DIVIDE STORE_FAST INPLACE_FLOOR_DIVIDE STORE_FAST INPLACE_MODULO STORE_FAST INPLACE_ADD STORE_FAST INPLACE_SUBTRACT STORE_FAST INPLACE_LSHIFT STORE_FAST INPLACE_RSHIFT STORE_FAST INPLACE_AND STORE_FAST INPLACE_XOR STORE_FAST INPLACE_OR STORE_FAST GET_AITER LOAD_CONST GET_ANEXT LOAD_CONST GET_AWAITABLE LOAD_CONST UNPACK_SEQUENCE STORE_FAST LOAD_CLOSURE BUILD_TUPLE GET_ITER CALL_FUNCTION GET_YIELD_FROM_ITER LOAD_CONST FOR_ITER POP_BLOCK BEFORE_ASYNC_WITH GET_AWAITABLE SETUP_WITH POP_TOP SETUP_WITH STORE_FAST BUILD_SLICE BINARY_SUBSCR Note that the effect of this change is not very significant since the PREDICT() macros is no-op if computed GOTOs are used. ---------- components: Interpreter Core files: more_opcode_predicts.patch keywords: patch messages: 267719 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: More opcode predictions type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43283/more_opcode_predicts.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 14:41:51 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jun 2016 18:41:51 +0000 Subject: [issue27255] More opcode predictions In-Reply-To: <1465324904.47.0.783952984943.issue27255@psf.upfronthosting.co.za> Message-ID: <1465324911.91.0.559197568471.issue27255@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 14:45:11 2016 From: report at bugs.python.org (Colm Buckley) Date: Tue, 07 Jun 2016 18:45:11 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465325111.83.0.454666522884.issue26839@psf.upfronthosting.co.za> Colm Buckley added the comment: Larry - To the first point: The combination of Victor's changeset 9de508dc4837 (based on my patch) and my most recent nonblocking_urandom_noraise patch (which is on top of 9de508dc4837) will do what you suggest for the hash secret initialization - ie: it is allowed to fall back to predictable sources when there is insufficient entropy to securely seed it. I suspect that it is simply impossible to reconcile "os.urandom will never block" with "os.urandom is always cryptographically reasonable". If the system has no entropy, it has no entropy. The only escape I see is to add an exception condition, instead of the silent fallback which some platforms currently have. There is a judgement call to be made here; whether silent fallback is acceptable or not. As Donald points out, this will fail only in very unusual circumstances (specifically, early in the boot process, although not I think just on the first boot of a system; Debian at least by default does not attempt to preserve its entropy pool across a reboot.) This should not affect things like web servers etc. as they start much later in the boot process; in particular after networking has started, which I believe is the principal source of entropy for /dev/urandom. Colm ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 14:46:22 2016 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jun 2016 18:46:22 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465325182.51.0.564699591196.issue26839@psf.upfronthosting.co.za> Larry Hastings added the comment: That reminds me. I want to be clear: I think it's preferable that os.urandom() blocks when insufficient entropy is available. If Victor's patch changed that, it should be backed out. (Since non-blocking urandom is useful, perhaps in 3.6 os.urandom() should take a new "block=True" parameter. But it's too late to add it for 3.5.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 14:48:08 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 07 Jun 2016 18:48:08 +0000 Subject: [issue27127] Never have GET_ITER not followed by FOR_ITER In-Reply-To: <1464227064.89.0.81963094053.issue27127@psf.upfronthosting.co.za> Message-ID: <1465325288.05.0.278770809584.issue27127@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I don't think this should go forward. The current FOR_ITER and JUMP_ABSOLUTE combination is very efficient and shouldn't be changed lightly. It is the inside of the loop that matters -- the GET_ITER step is outside of the loop and isn't expensive. Also, I really like that GET_ITER and FOR_ITER correspond exactly to our high level understanding of how for-loops operate: for x in s: f(x) corresponds to: it = iter(s) while True: try: x = next(it) except StopIteration: break f(x) I really don't think this should be pursued further. It messes with my understanding of for-loops, it combines features that should remain decoupled, it focuses its efforts on the exterior of the loop, and it alters code that is very mature (having been examined and tweaked by hundreds of your predecessors). ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 14:51:52 2016 From: report at bugs.python.org (Matthias Klose) Date: Tue, 07 Jun 2016 18:51:52 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1465310860.48.0.930633154294.issue26839@psf.upfronthosting.co.za> Message-ID: <575717BF.4030700@debian.org> Matthias Klose added the comment: On 07.06.2016 16:47, Christian Heimes wrote: > > Christian Heimes added the comment: > > PSRT VETO! > > In the light of the upcoming release 3.5.2 I'm now putting on my PSRT hat (Python Security Response Team) and proclaim a veto against any and all changes to os.urandom(). The security properties of os.urandom() must not be modified or reduced compared to 3.5.1. Please restore the behavior of os.urandom(). So you are intentionally accepting a new vector for DoS attacks, and calling this non-reduced security? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 14:52:40 2016 From: report at bugs.python.org (Emanuel Barry) Date: Tue, 07 Jun 2016 18:52:40 +0000 Subject: [issue27242] Make the docs for NotImplemented & NotImplementedError unambigous In-Reply-To: <1465239567.69.0.773832868585.issue27242@psf.upfronthosting.co.za> Message-ID: <1465325560.74.0.592056474793.issue27242@psf.upfronthosting.co.za> Emanuel Barry added the comment: More tweaks after Ethan's comments. This is starting to get way outside of the realm of NotImplemented, but it still makes for a good reference to point confused users at. ---------- Added file: http://bugs.python.org/file43284/NotImplemented_exceptions_wording_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 14:55:37 2016 From: report at bugs.python.org (Colm Buckley) Date: Tue, 07 Jun 2016 18:55:37 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465325737.47.0.402353702819.issue26839@psf.upfronthosting.co.za> Colm Buckley added the comment: To clarify what the various patches do: 3.5.1 as released: os.urandom and hash secret initialization both attempt getrandom() in preference to reading /dev/urandom. Under certain circumstances, this will block, possibly indefinitely. Changeset 9de508dc4837: both os.urandom and hash secret initialization call getrandom() in nonblocking mode, falling back to (possibly low-entropy) /dev/urandom should getrandom() block due to lack of entropy. Changeset 9de508dc4837 + nonblocking_urandom_noraise.patch: hash secret initialization calls getrandom() in nonblocking mode (ie: will always succeed, although with a silent fallback to low-entropy data if called when the system has no entropy). os.urandom will always block until there's enough entropy. I think this final case implements what you need for the 3.5.2 RC. The issue of "import random" still needs to be resolved; maybe we should de-merge #25420 and pursue Donald's approach there. Thanks, Colm ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 15:00:53 2016 From: report at bugs.python.org (Donald Stufft) Date: Tue, 07 Jun 2016 19:00:53 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465326053.07.0.434929084712.issue26839@psf.upfronthosting.co.za> Donald Stufft added the comment: > specifically, early in the boot process, although not I think just on the first boot of a system; Debian at least by default does not attempt to preserve its entropy pool across a reboot.) Look at /etc/init.d/urandom in the initscripts package in Jessie (https://anonscm.debian.org/cgit/collab-maint/sysvinit.git/tree/debian/src/initscripts/etc/init.d/urandom). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 15:01:36 2016 From: report at bugs.python.org (Ethan Furman) Date: Tue, 07 Jun 2016 19:01:36 +0000 Subject: [issue25958] Implicit ABCs have no means of "anti-registration" In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za> Message-ID: <1465326096.96.0.745151518803.issue25958@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 15:02:10 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jun 2016 19:02:10 +0000 Subject: [issue27254] heap overflow in Tkinter module In-Reply-To: <1465324141.01.0.361051063774.issue27254@psf.upfronthosting.co.za> Message-ID: <1465326130.17.0.139809766069.issue27254@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Minimal reproducer: from tkinter import Tk Tk(className='A'*0xfffff) This looks as Tcl/Tk problem. ---------- nosy: +serhiy.storchaka type: security -> crash versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 15:03:05 2016 From: report at bugs.python.org (Colm Buckley) Date: Tue, 07 Jun 2016 19:03:05 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465326185.15.0.836610727025.issue26839@psf.upfronthosting.co.za> Colm Buckley added the comment: Donald - Oh, that's interesting; thank you. I guess that system-crontab-generator is being called before that in the boot process. The most common trigger case, I guess, will then be cloud containers and VMs which are spun up for single applications. I think Larry's comments are still very valid. Colm ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 15:03:48 2016 From: report at bugs.python.org (Cory Benfield) Date: Tue, 07 Jun 2016 19:03:48 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465326228.41.0.227190625531.issue26839@psf.upfronthosting.co.za> Cory Benfield added the comment: > So you are intentionally accepting a new vector for DoS attacks, and calling this non-reduced security? This is only a DoS vector if you can hit the server so early in the boot process that it doesn't have enough entropy. The *second* enough entropy has been gathered getrandom() will never block again. In essence, then, the situation where it becomes possible to DoS a server is entirely outside an attackers control and extremely unlikely to ever actually occur in real life: you can only DoS the server if you can demand entropy before the system has gathered enough, and if the server has managed to *boot* by then then the alternative is that it is incapable of generating secure random numbers and shouldn't be running exposed against the web anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 15:10:18 2016 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jun 2016 19:10:18 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465326618.72.0.718273103565.issue26839@psf.upfronthosting.co.za> Larry Hastings added the comment: > This is only a DoS vector if you can hit the server so early in the boot process that it doesn't have enough entropy. Python hash randomization only happens once. So it's not a matter of how early we try the attack, it's a matter of how early we seed Python hash randomization. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 15:12:00 2016 From: report at bugs.python.org (Cory Benfield) Date: Tue, 07 Jun 2016 19:12:00 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465326720.96.0.220308713091.issue26839@psf.upfronthosting.co.za> Cory Benfield added the comment: > Python hash randomization only happens once. So it's not a matter of how early we try the attack, it's a matter of how early we seed Python hash randomization. Sorry Larry, I was insufficiently clear (relying on context from earlier). I totally agree that Python startup should not block. I'm saying that having getrandom() called in "blocking mode" for os.urandom, random.SystemRandom, and secrets is not a DoS vector. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 15:14:47 2016 From: report at bugs.python.org (Hans-Peter Jansen) Date: Tue, 07 Jun 2016 19:14:47 +0000 Subject: [issue27256] header indentation destroyed Message-ID: <1465326886.85.0.738328133832.issue27256@psf.upfronthosting.co.za> New submission from Hans-Peter Jansen: In the course of replacing an old Python 2.7 email filter tool with a rewritten Python3 version, I stumbled across a ugly case, where such an header: X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTDJQUjAyTUI1MTQ7MjM6bEtRRlNaUHQvVTk5WCttdktlOUVrUGQvVFBH?= =?utf-8?B?cDFJemVUeXFzOGNzYnZOYWlwMDZpR0YzbXZyY09WaTBKM2pkeUl4S1VDMkxw?= =?utf-8?B?eVRkNWthRW9waUhJTzczTWd5WDZOQ3hMNU1haGFvQTVzVTdRZmxJUnZlblpW?= ... is regenerated as: X-Microsoft-Exchange-Diagnostics: 1;BL2PR02MB514;23:lKQFSZPt/U99X+mvKe9EkPd/TPG p1IzeTyqs8csbvNaip06iGF3mvrcOVi0J3jdyIxKUC2Lp yTd5kaEopiHIO73MgyX6NCxL5MahaoA5sU7QflIRvenZV which is plain wrong of course. I'm using email.message_from_binary_file for parsing and BytesGenerator.flatten for regeneration. Since those are LKML public mails, I'm attaching both versions. I'm using 3.4.4, but also the email module from current hg for testing. ---------- components: email files: utf8-header-failure.mail messages: 267732 nosy: barry, frispete, r.david.murray priority: normal severity: normal status: open title: header indentation destroyed versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43285/utf8-header-failure.mail _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 15:15:48 2016 From: report at bugs.python.org (Hans-Peter Jansen) Date: Tue, 07 Jun 2016 19:15:48 +0000 Subject: [issue27256] header indentation destroyed In-Reply-To: <1465326886.85.0.738328133832.issue27256@psf.upfronthosting.co.za> Message-ID: <1465326948.39.0.165480872021.issue27256@psf.upfronthosting.co.za> Changes by Hans-Peter Jansen : Added file: http://bugs.python.org/file43286/mf.9__mi0bf.out _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 15:16:29 2016 From: report at bugs.python.org (ppperry) Date: Tue, 07 Jun 2016 19:16:29 +0000 Subject: [issue27081] Cannot capture sys.stderr output from an uncaught exception in a multiprocessing Process using a multiprocessing Queue In-Reply-To: <1463864673.26.0.0758761622573.issue27081@psf.upfronthosting.co.za> Message-ID: <1465326989.78.0.9065179047.issue27081@psf.upfronthosting.co.za> Changes by ppperry : ---------- title: Multiprocessing is not robust against sys.stderr changes involving queues -> Cannot capture sys.stderr output from an uncaught exception in a multiprocessing Process using a multiprocessing Queue _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 15:24:54 2016 From: report at bugs.python.org (Hans-Peter Jansen) Date: Tue, 07 Jun 2016 19:24:54 +0000 Subject: [issue27257] get_addresses results in traceback with a valid? header Message-ID: <1465327493.81.0.354921385455.issue27257@psf.upfronthosting.co.za> New submission from Hans-Peter Jansen: In the course of replacing an old Python 2.7 email filter tool with a rewritten Python3 version, I stumbled across a ugly case, where such an header: To: unlisted-recipients: ;, ""@pop.kundenserver.de (no To-header on input) results in a Traceback (most recent call last): File "./mail_filter.py", line 606, in ret = main.run() File "./mail_filter.py", line 595, in run self.process(fp) File "./mail_filter.py", line 520, in process config.recipients = self.get_addresses('to', msg) File "./mail_filter.py", line 103, in get_addresses vals = msg.get_all(field, []) File "/usr/lib64/python3.4/email/message.py", line 511, in get_all values.append(self.policy.header_fetch_parse(k, v)) File "/usr/lib64/python3.4/email/policy.py", line 145, in header_fetch_parse return self.header_factory(name, ''.join(value.splitlines())) File "/usr/lib64/python3.4/email/headerregistry.py", line 584, in __call__ return self[name](name, value) File "/usr/lib64/python3.4/email/headerregistry.py", line 195, in __new__ cls.parse(value, kwds) File "/usr/lib64/python3.4/email/headerregistry.py", line 342, in parse for mb in addr.all_mailboxes])) File "/usr/lib64/python3.4/email/headerregistry.py", line 342, in for mb in addr.all_mailboxes])) File "/usr/lib64/python3.4/email/_header_value_parser.py", line 837, in local_part return self[0].local_part File "/usr/lib64/python3.4/email/_header_value_parser.py", line 889, in local_part return self[0].local_part File "/usr/lib64/python3.4/email/_header_value_parser.py", line 984, in local_part tok[0].token_type == 'cfws'): IndexError: list index out of range I'm not completely sure, if the Top header, as added from my email provider, is perfectly valid, but none of the other parts of my mail infrastructure neither complained, nor behave strange with such headers. This happens with 3.4.4, but also with the email module from current hg for testing. ---------- components: email files: lkml-exception.mail messages: 267733 nosy: barry, frispete, r.david.murray priority: normal severity: normal status: open title: get_addresses results in traceback with a valid? header versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43287/lkml-exception.mail _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 15:29:41 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 07 Jun 2016 19:29:41 +0000 Subject: [issue26632] @public - an __all__ decorator In-Reply-To: <1465069663.67.0.923248771945.issue26632@psf.upfronthosting.co.za> Message-ID: <20160607152930.204954ab@anarchist.wooz.org> Barry A. Warsaw added the comment: On Jun 04, 2016, at 07:47 PM, Zachary Ware wrote: >So, +1 anyway. I think this would be rather worthwhile, especially in the >stdlib. Thanks! I still like it and plan on continuing to use it in my code. I would recommend you playing with the third party module: https://pypi.python.org/pypi/atpublic and seeing how you like it. If you do like it maybe help get some momentum behind it. Then we can approach python-dev and try to get it into builtins. I'd be willing to bring it up there (it didn't get such an overwhelming reception at the Pycon 2016 language summit ;). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 15:54:29 2016 From: report at bugs.python.org (Donald Stufft) Date: Tue, 07 Jun 2016 19:54:29 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465329269.31.0.752191064324.issue26839@psf.upfronthosting.co.za> Donald Stufft added the comment: Colm, Great, then I think there's general agreement, we just need someone to review the nonblocking_urandom_noraise.patch (which my C is not strong enough to feel comfortable doing). That still leaves the `import random` issue, but I think we can reopen #25420 and figure out over there what the right answer is for that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 15:55:26 2016 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jun 2016 19:55:26 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465329326.37.0.525581961446.issue26839@psf.upfronthosting.co.za> Larry Hastings added the comment: I fear I may be changing my mind a little bit. However, I skipped breakfast--and now it's looking like a late lunch--so I simply have to step away for a while. Expect me to post in about two hours when I get some calories down and finally make up my tiny mind. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 15:55:04 2016 From: report at bugs.python.org (Mark Summerfield) Date: Tue, 07 Jun 2016 19:55:04 +0000 Subject: [issue27259] Possible missing deprecation warnings? Message-ID: <1465329304.45.0.636759597708.issue27259@psf.upfronthosting.co.za> New submission from Mark Summerfield: In the docs for the array module: https://docs.python.org/dev/library/array.html#module-array Note 1 in the table of type codes says that the 'u' type is deprecated and will go in Python 4.0. Since the array.fromunicode() and array.tounicode() methods depend on type code 'u' shouldn't they also be marked as deprecated? If people use the 'u' type code maybe it would be helpful to provide an example of how to store unicode chars in an array.array? (Presumably they'd use type code 'L' and use ord() and chr()?) ---------- assignee: docs at python components: Documentation messages: 267738 nosy: docs at python, mark priority: normal severity: normal status: open title: Possible missing deprecation warnings? type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 16:06:42 2016 From: report at bugs.python.org (Christian Heimes) Date: Tue, 07 Jun 2016 20:06:42 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465330002.31.0.64929520725.issue26839@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: -christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 16:01:29 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 07 Jun 2016 20:01:29 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1465326720.96.0.220308713091.issue26839@psf.upfronthosting.co.za> Message-ID: <57572813.4000607@egenix.com> Marc-Andre Lemburg added the comment: On 07.06.2016 21:12, Cory Benfield wrote: > >> Python hash randomization only happens once. So it's not a matter of how early we try the attack, it's a matter of how early we seed Python hash randomization. > > Sorry Larry, I was insufficiently clear (relying on context from earlier). I totally agree that Python startup should not block. I'm saying that having getrandom() called in "blocking mode" for os.urandom, random.SystemRandom, and secrets is not a DoS vector. I'm not sure I follow. A delay of 90 seconds on startup of a VM or container can easily lead the supervisor style management tool to think that something is wrong and issue a retry. Depending on the configuration it'll then try this a couple of times and give up. Overall, I have a hard time following the arguments. To be clear: getrandom() on Linux is just a wrapper with some additional control around /dev/random and /dev/urandom. http://lxr.free-electrons.com/source/drivers/char/random.c#L1601 Unlike /dev/urandom, getrandom() without flag GRND_NONBLOCK will block, but only in the case where the entropy pool has not been initialized yet. Once this has been done, it will never block again, and happily send you poor random data if the entropy pool has been completely wiped of any entropy data - without telling you. So now, you're all arguing: oh my, it's so insecure to use data from /dev/urandom when the entropy pool is not initialized. But you're not worried about os.urandom() happily sending you data which is no longer based on any external entropy half an hour later: http://lxr.free-electrons.com/source/drivers/char/random.c#L1458 This doesn't make sense. Either you're worried all the time, or you're not :-) The whole discussion is centering around whether to block on an uninitialized entropy pool or not. This can only happen during startup. By falling back to reading /dev/urandom in case of an uninitialized pool, you are reading data from a not fully initialized pool, but you still get random data. That's really all that's needed for basic operations like hash seeding or seeding the PRNG in the random module. And it's limited to Python processes which are run very early in the VM/container startup phase. Note that "uninitialized" only means that the kernel entropy pool has not yet reached an "entropy level" of 128 (whatever that means): http://lxr.free-electrons.com/source/drivers/char/random.c#L676 It does not mean that you're just reading a list of zeros. So given all this information, why is it that you get so tangled up in wanting os.urandom() to block during system startup ? Or put differently: Where is the attack vector that blocking behavior of os.urandom() would help remedy ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 15:52:43 2016 From: report at bugs.python.org (Hans-Peter Jansen) Date: Tue, 07 Jun 2016 19:52:43 +0000 Subject: [issue27258] Exception in BytesGenerator.flatten Message-ID: <1465329163.65.0.664069941673.issue27258@psf.upfronthosting.co.za> New submission from Hans-Peter Jansen: Attached mail, parsed with email.message_from_binary_file results in: Traceback (most recent call last): File "./mail_filter.py", line 616, in ret = main.run() File "./mail_filter.py", line 605, in run self.process(fp) File "./mail_filter.py", line 589, in process self.save_message(msg, self._fname + '.out') File "./mail_filter.py", line 103, in save_message ofd.write(msg.as_bytes()) File "/usr/lib64/python3.4/email/message.py", line 179, in as_bytes g.flatten(self, unixfrom=unixfrom) File "/usr/lib64/python3.4/email/generator.py", line 115, in flatten self._write(msg) File "/usr/lib64/python3.4/email/generator.py", line 195, in _write self._write_headers(msg) File "/usr/lib64/python3.4/email/generator.py", line 422, in _write_headers self._fp.write(self.policy.fold_binary(h, v)) File "/usr/lib64/python3.4/email/policy.py", line 190, in fold_binary folded = self._fold(name, value, refold_binary=self.cte_type=='7bit') File "/usr/lib64/python3.4/email/policy.py", line 204, in _fold return self.header_factory(name, ''.join(lines)).fold(policy=self) File "/usr/lib64/python3.4/email/headerregistry.py", line 255, in fold return header.fold(policy=policy) File "/usr/lib64/python3.4/email/_header_value_parser.py", line 300, in fold self._fold(folded) File "/usr/lib64/python3.4/email/_header_value_parser.py", line 1228, in _fold rest._fold(folded) File "/usr/lib64/python3.4/email/_header_value_parser.py", line 338, in _fold if folded.append_if_fits(part, tstr): File "/usr/lib64/python3.4/email/_header_value_parser.py", line 149, in append_if_fits token._fold(self) File "/usr/lib64/python3.4/email/_header_value_parser.py", line 324, in _fold for part in self.parts: File "/usr/lib64/python3.4/email/_header_value_parser.py", line 254, in parts if token.startswith_fws(): File "/usr/lib64/python3.4/email/_header_value_parser.py", line 267, in startswith_fws return self[0].startswith_fws() File "/usr/lib64/python3.4/email/_header_value_parser.py", line 267, in startswith_fws return self[0].startswith_fws() File "/usr/lib64/python3.4/email/_header_value_parser.py", line 267, in startswith_fws return self[0].startswith_fws() File "/usr/lib64/python3.4/email/_header_value_parser.py", line 267, in startswith_fws return self[0].startswith_fws() File "/usr/lib64/python3.4/email/_header_value_parser.py", line 267, in startswith_fws return self[0].startswith_fws() IndexError: list index out of range when flattened with BytesGenerator. ---------- components: email files: flatten-exception.mail messages: 267736 nosy: barry, frispete, r.david.murray priority: normal severity: normal status: open title: Exception in BytesGenerator.flatten versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43288/flatten-exception.mail _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 16:07:35 2016 From: report at bugs.python.org (Donald Stufft) Date: Tue, 07 Jun 2016 20:07:35 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465330055.56.0.28219766868.issue26839@psf.upfronthosting.co.za> Donald Stufft added the comment: > Once this has been done, it will never block again, and happily send you poor random data if the entropy pool has been completely wiped of any entropy data - without telling you. This doesn't actually happen in real life, once urandom has been initialized you will never be able to get "poor random" out of it. You will get cryptographically secure random out of it always. *ACTUAL* Cryptographers pretty much universally agree on this statement. You can even use them for cryptographic keys, no matter how long it's been since your system booted as long as the urandom pool has had a chance to initialize. > Or put differently: Where is the attack vector that blocking behavior of os.urandom() would help remedy ? Someone attempting to use cryptographic random before the urandom pool has been sufficiently initialized to provide said random. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 15:50:22 2016 From: report at bugs.python.org (Colm Buckley) Date: Tue, 07 Jun 2016 19:50:22 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465329022.85.0.910906192766.issue26839@psf.upfronthosting.co.za> Colm Buckley added the comment: I've spoken with Ted Ts'o (one advantage of working for Google) and taken a look in the Linux kernel source, and things are actually better than we'd feared. Firstly, calling getrandom() with GRND_NONBLOCK and a buffer size of less than or equal to 32 bytes will always succeed (so, for the hash seed initialization at least, the EAGAIN logic is superfluous - it's still possibly needed for the general case and other operating systems, though). Secondly, the quality of the getrandom data *before* the kernel PRNG is initialized is still pretty good - it's seeded from a combination of RDRAND, interrupt timing, several kernel parameters like uname -a, and RTC. Ted is confident that at least 24 bytes of real entropy will be present by a few seconds into boot time (due to interrupts etc), and that the predictability of the data will be very low. Finally - note that any network-facing applications are *extremely* unlikely to encounter this issue, as they will be started well after networking and other good entropy sources have started. In particular, getrandom() will no longer block once fastinit has completed (on my system, this was less than one second after kernel load). In other words, I think we are very safe to proceed with changeset 9de508dc4837 + the nonblocking_urandom_noraise.patch Note that this solves the problem for *Linux* - if other operating systems do indeed have blocking /dev/urandom reads, this still needs to be addressed. I am not aware of any reports from non-Linux systems, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 16:20:56 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Jun 2016 20:20:56 +0000 Subject: [issue27251] TypeError in logging.HTTPHandler.emit; possible python 2 to 3 conversion issue In-Reply-To: <1465314338.49.0.176049462957.issue27251@psf.upfronthosting.co.za> Message-ID: <20160607202052.3304.96133.0A890A66@psf.io> Roundup Robot added the comment: New changeset 11ebd14076b4 by Vinay Sajip in branch '3.5': Fixed #27251: corrected string/bytes handling in credentials. https://hg.python.org/cpython/rev/11ebd14076b4 New changeset 12d939477b4f by Vinay Sajip in branch 'default': Fixed #27251: merged fix from 3.5. https://hg.python.org/cpython/rev/12d939477b4f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 16:22:49 2016 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 07 Jun 2016 20:22:49 +0000 Subject: [issue27251] TypeError in logging.HTTPHandler.emit; possible python 2 to 3 conversion issue In-Reply-To: <1465314338.49.0.176049462957.issue27251@psf.upfronthosting.co.za> Message-ID: <1465330969.29.0.181465270115.issue27251@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 16:25:26 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Jun 2016 20:25:26 +0000 Subject: [issue27187] Relax __all__ location requirement in PEP 8 In-Reply-To: <1464901602.05.0.802918160149.issue27187@psf.upfronthosting.co.za> Message-ID: <20160607202522.39513.2656.F918B9D0@psf.io> Roundup Robot added the comment: New changeset cf8e888b9555 by Barry Warsaw in branch 'default': Relax __all__ location. https://hg.python.org/peps/rev/cf8e888b9555 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 16:26:13 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 07 Jun 2016 20:26:13 +0000 Subject: [issue27187] Relax __all__ location requirement in PEP 8 In-Reply-To: <1464901602.05.0.802918160149.issue27187@psf.upfronthosting.co.za> Message-ID: <1465331173.88.0.88629123354.issue27187@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Thanks for the patch! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 16:27:03 2016 From: report at bugs.python.org (Theodore Tso) Date: Tue, 07 Jun 2016 20:27:03 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465331223.64.0.269660807987.issue26839@psf.upfronthosting.co.za> Theodore Tso added the comment: Hi. Colm alerted me to this bug, so I thought I would chime in as the author of Linux's getrandom(2) function. First of all, if you are OK with reading from /dev/urandom, then you might as well use getrandom's GRND_NONBLOCK flag. They are logically equivalent. Secondly, when I decided to add this behavior to getrandom(2), it was because people were really worried that people would be using /dev/urandom for security-critical things (e.g., initializing ssh host session keys, when they'd _really_ rather not the NSA have be able to trivally pwn the server) before it had been completely initialized. (And if it is not completely initialized, it would be trivially and embarassingly easy. See https://factorable.net/weakkeys12.extended.pdf for an example of where this was rather disastrous.) Why didn't I make /dev/urandom blocking? Because a lot of people would whine and complain. But getrandom(2) was a new interface, and so this was something I could do. Now, before I decided to do this, I did do some benchmarks, and pre-systemd in practice on real hardware (e.g., x86 servers and laptops), I observed that you would actually see a message indicating that we had gathered 128 bits of entropy long before the root file system had been mounted. With systemd, I observed that udevd was trying to read from /dev/urandom when we had only gathered an estimated 7 bits of entropy --- but I devoutly hoped that udevd wasn't doing anything super security critical, and trying to get the systemd people to change what they are doing is mostly like trying to teach a pig to sing, so I let it be. However, in practice within a single digit number of seconds, the kernel printk indicating that random driver had considered itself initialized came quickly enough that I figured it would be safe to do. If people are claiming that they are seeing cases where it takes over 90 seconds for the random number generator to initialize itself, please contact me directly; I'd love to know more, because that's input I would very much like to have. However, at the end of the day, on certain hardware, if you don't have a source of initial entropy because the system doesn't have enough real hardware with real sources of entropy --- or if you don't trust your friendly cloud provider to provide you with some entropy from the hypervisor's entropy pool via virtio-random --- you can either (a) decide to pretend you are secure, when you really aren't, (b) wait, or (c) decide that you don't *really* need a secure source of randomness because you're really just initializing a hash for some associative array, and in fact srandom(time(0)) would have been fine, and you were using getrandom(2) or /dev/urandom just because you wanted to feel like one of the cool kids. That being said, I do know of one potential issue which is if you happening to be using Microsoft Azure, the way the virtualized interrupt works, we weren't actually getting any entropy, and this was something I didn't discover until someone sent me a patch. I have a patch[1] queued up in the random.git tree for the next kernel merge window to address that issue for Microsoft Azure servers. [1] http://git.kernel.org/cgit/linux/kernel/git/tytso/random.git/commit/?h=dev&id=8748971b4f5e322236154981827bf43dec4dc470 On a Google Compute Engine (GCE) system, I just did a quick test, and the "random: non-blocking pool initialized" message appears 5.64 seconds after the system is booted. The changes I have queued up in random.git should reduce that to under a second. All of this is neither here nor there, though. The big question is *what* does Python expect to do with the randomness. If you are just using it for computational simulation, you can do whatever you want. If you are using it to create long-lived secrets that are intended to be secure against the depredations of a Nation-State's intelligence service, and you are on a system which really has almost no entropy available to be collected, then falling back to reading from /dev/urandom or using GRND_NONBLOCOK is going to be the equivalent of saying La-La-La-La-La-Nobody-Knows-How-Secure-I-Am while keeping your ears plugged. (Now, if you are on an Intel system with RDRAND, and you trust Intel not to have given a back door to the NSA, you probably are safe, because we do actually mix in RDRAND. On the other hand, if you are using some crappy ARM SOC for some Internet of Things device, and are firing up Python right after the system boots for the first time, and creating long-lived RSA private keys within milliseconds after the system is first booted --- please tell me so, I can avoid your product like the Plague. :-) ---------- nosy: +Theodore Tso _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 16:34:03 2016 From: report at bugs.python.org (Donald Stufft) Date: Tue, 07 Jun 2016 20:34:03 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465331643.74.0.884162926826.issue26839@psf.upfronthosting.co.za> Donald Stufft added the comment: Thanks for weighing in Theodore, I think that matches what Colm's last suggestion was, and what I was personally OK with. To seed our SipHash function using GRND_NONBLOCK since it's likely that will be fine, and worst case we're just using it for some hash tables. Then for our os.urandom binding, we should use getrandom() without GRND_NONBLOCK since we don't know why someone is calling os.urandom, but we know in practice people are using it for cryptographic keys and the like. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 16:48:03 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Tue, 07 Jun 2016 20:48:03 +0000 Subject: [issue27260] Missing equality check for super objects Message-ID: <1465332483.31.0.223891907563.issue27260@psf.upfronthosting.co.za> New submission from Jelle Zijlstra: >>> class Foo: pass ... >>> super(Foo) == super(Foo) False Will submit a patch later ---------- assignee: Jelle Zijlstra components: Library (Lib) messages: 267747 nosy: Jelle Zijlstra priority: normal severity: normal status: open title: Missing equality check for super objects versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 16:52:57 2016 From: report at bugs.python.org (Justus Winter) Date: Tue, 07 Jun 2016 20:52:57 +0000 Subject: [issue27261] io.BytesIO.truncate does not work as advertised Message-ID: <1465332777.38.0.718878645897.issue27261@psf.upfronthosting.co.za> New submission from Justus Winter: % python3.6 -c "import io; b=io.BytesIO(); assert b.truncate(42) == 42; assert len(b.getbuffer()) == 42, 'expected length 42, got {}'.format(len(b.getbuffer()))" Traceback (most recent call last): File "", line 1, in AssertionError: expected length 42, got 0 The documentation [0] says that truncate can extend objects, and there is no indication that BytesIO does not support that. As demonstrated, truncate returns the new size, but the buffer obtained from that BytesIO is of size zero (likewise, b.getvalue() returns b''. 0: https://docs.python.org/3.6/library/io.html#io.IOBase.truncate ---------- components: IO, Library (Lib) messages: 267748 nosy: justus.winter priority: normal severity: normal status: open title: io.BytesIO.truncate does not work as advertised type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 17:19:28 2016 From: report at bugs.python.org (Colm Buckley) Date: Tue, 07 Jun 2016 21:19:28 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465334368.49.0.136832542534.issue26839@psf.upfronthosting.co.za> Colm Buckley added the comment: Ted - I'd suggest the following to test. Boot an arbitrary Linux system with init=/usr/bin/python3 (assuming filesystems mounted etc). Python 3.5.1 (on Linux) will call getrandom() in blocking mode very early in its startup; if this happens before the pool is initialized, Python will fail to start. Given that ~nothing else will be happening, I'm interested to see what happens to the entropy pool, and whether getrandom() returns. Haven't tried this myself, but it should work. Colm ---------- _______________________________________ Python tracker _______________________________________ From mal at egenix.com Tue Jun 7 17:24:42 2016 From: mal at egenix.com (M.-A. Lemburg) Date: Tue, 7 Jun 2016 23:24:42 +0200 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1465331223.64.0.269660807987.issue26839@psf.upfronthosting.co.za> References: <1465331223.64.0.269660807987.issue26839@psf.upfronthosting.co.za> Message-ID: <57573B9A.4090504@egenix.com> On 07.06.2016 22:27, Theodore Tso wrote: > > Secondly, when I decided to add this behavior to getrandom(2), it was because people were really worried that people would be using /dev/urandom for security-critical things (e.g., initializing ssh host session keys, when they'd _really_ rather not the NSA have be able to trivally pwn the server) before it had been completely initialized. (And if it is not completely initialized, it would be trivially and embarassingly easy. See https://factorable.net/weakkeys12.extended.pdf for an example of where this was rather disastrous.) Thanks, Theodore, for this paper reference. It provides convincing arguments that going back to the Python 3.4 behavior is indeed not a good idea - even though I'm still not convinced that the main use case for os.urandom() is cryptography. Most people will simply use it to seed their Mersenne Twisters, like the random module does too. Now, raising an exception instead of blocking would likely cause even more breakage, so I'm with Colm in keeping Victor's patch and applying the fix to not block in dev_urandom_noraise(). We still need to fix the random module issue, though. For 3.6, I wish we could have the getrandom() API exposed as os.getrandom(), with all options available to applications. That way, the application can decide what is best for them. -- Marc-Andre Lemburg eGenix.com From report at bugs.python.org Tue Jun 7 17:24:48 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 07 Jun 2016 21:24:48 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1465331223.64.0.269660807987.issue26839@psf.upfronthosting.co.za> Message-ID: <57573B9A.4090504@egenix.com> Marc-Andre Lemburg added the comment: On 07.06.2016 22:27, Theodore Tso wrote: > > Secondly, when I decided to add this behavior to getrandom(2), it was because people were really worried that people would be using /dev/urandom for security-critical things (e.g., initializing ssh host session keys, when they'd _really_ rather not the NSA have be able to trivally pwn the server) before it had been completely initialized. (And if it is not completely initialized, it would be trivially and embarassingly easy. See https://factorable.net/weakkeys12.extended.pdf for an example of where this was rather disastrous.) Thanks, Theodore, for this paper reference. It provides convincing arguments that going back to the Python 3.4 behavior is indeed not a good idea - even though I'm still not convinced that the main use case for os.urandom() is cryptography. Most people will simply use it to seed their Mersenne Twisters, like the random module does too. Now, raising an exception instead of blocking would likely cause even more breakage, so I'm with Colm in keeping Victor's patch and applying the fix to not block in dev_urandom_noraise(). We still need to fix the random module issue, though. For 3.6, I wish we could have the getrandom() API exposed as os.getrandom(), with all options available to applications. That way, the application can decide what is best for them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 18:45:02 2016 From: report at bugs.python.org (Theodore Tso) Date: Tue, 07 Jun 2016 22:45:02 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465339502.45.0.25455854557.issue26839@psf.upfronthosting.co.za> Theodore Tso added the comment: I ran the experiment Colm asked me to run --- and yes, if you boot a system with Python 3.5.1 with the boot options "init=/usr/bin/python3", you're going to have a bad time. The problem is that in a KVM environment where things are very quiet, especially if you are using a tickless kernel, if python calls getrandom(2), it will block since the entropy pool hasn't been initialized yet. But since we aren't doing anything, the system becomes completely quiescent and so no entropy can be collected. If systemd tries to run a python script very early in the boot process, and does this in a way where no further boot time activity takes place until the python script exits, you can indeed deadlock the system. The solution is I think what Donald suggested in msg267746, which is to use GRND_NONBLOCK for initializing the hash which gets used for the dict, or whatever it's used for. My understanding is that this is not a long-term cryptographic secret, and indeed it will be thrown away as soon as the python interpreter exits. Since this is before networking has been brought up, the denial service attack or whatever requires that you use a strong SipHash for your Python dictionaries shouldn't be a problem. (Which I gather has something to do with this? https://events.ccc.de/congress/2011/Fahrplan/attachments/2007_28C3_Effective_DoS_on_web_application_platforms.pdf) Now, I can see people being concerned that if Python *always* initializes its hash dictionaries using getrandom with GRND_NONBLOCK, it might be opening up a DOS attack. Well, in practice, once the boot sequence continues and the system is actually doing some real work, within a few seconds the random number generator will be initialized so in practice it won't be an issue once the system has booted. If you want to be really paranoid, I suppose you could give some kind of command-line flag which tells Python to use GRND_NONBLOCK for the purposes of initializing its hash table for its dictionary, and only use it in the boot path. In practice, I suspect very early in the systemd boot path, before it actually starts running the boot scripts in parallel, is the only place where you are likely going to run into this problem, so making it be a flag that only systemd scripts have to call is probably the right thing to do. But I'll let someone else have the joys of negotiating with Lennart, and I won't blame the Python devs if using GRND_NONBLOCK unconditionally is less painful than having to work with the systemd folks. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 19:15:55 2016 From: report at bugs.python.org (Christian Heimes) Date: Tue, 07 Jun 2016 23:15:55 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465341355.01.0.304056599581.issue26839@psf.upfronthosting.co.za> Christian Heimes added the comment: Thanks Theodore! Your analysis was exactly what I was aiming for when I requested a thorough security analysis in form of a PEP. The correct choice of CPRNG is important for the overall security. I'm mostly concerned with the behavior of os.urandom(), which is Python's preferred CPRNG for any critical data from session keys to key material. Several people including me have been pushing developers towards os.urandom() for many years. For that reason I put up a veto against any hasty change. Larry could my bluff. The hash randomization for hashing of strings and bytes is explained in PEP 456, https://www.python.org/dev/peps/pep-0456 . I wrote the PEP and added DJB's and JP Aumasson's SipHash24 as PRF. The 24 byte Py_HashSecret struct contains two keys for SipHash24 and another 8 byte key for randomization of expat XML library, https://hg.python.org/cpython/file/tip/Include/pyhash.h#l34 . For short-running scripts early in the boot phase, hash randomization is not required at all. It is only relevant for applications that reads untrusted data from potentially malicious peers. GET dict of HTTP requests is a famous example. Hash randomization can already be disabled or set to a fixed value by using an env var. I argued to add an option that falls back to a different CPRNG and sets other options at the same time (#16499) but Larry (release manager of 3.5) is against any option. He wants Python to always start in a timely fashion without any extra arguments. Your suggestion should fix the issue on Linux (GRND_NONBLOCK, fall back to srandom()), although I would rather use gettimeofday() with t.tv_sec + t.tv_usec. I'm still concerned how we should address the issue on BSD. As far as I am familiar with BSD, all reads from the Kernel's CPRNG are blocking until the CPRNG is seeded. I can bring up the issue with Lennart, if it is really necessary (one advantage of working for Red Hat ;) ). I'm going to ping JP Aumasson to get his feedback. ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 19:16:59 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 07 Jun 2016 23:16:59 +0000 Subject: [issue27260] Missing equality check for super objects In-Reply-To: <1465332483.31.0.223891907563.issue27260@psf.upfronthosting.co.za> Message-ID: <1465341419.95.0.620948678032.issue27260@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Why would you need this? Also, would it interfere with super's ability to use the __eq__ method for a parent class? class A: def __eq__(self, other): return True class B(A): def __eq__(self, other): return super(B, self).__eq__(other) print(B() == B()) ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 20:01:30 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 08 Jun 2016 00:01:30 +0000 Subject: [issue27255] More opcode predictions In-Reply-To: <1465324904.47.0.783952984943.issue27255@psf.upfronthosting.co.za> Message-ID: <1465344090.24.0.536219559446.issue27255@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 20:01:18 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 08 Jun 2016 00:01:18 +0000 Subject: [issue27255] More opcode predictions In-Reply-To: <1465324904.47.0.783952984943.issue27255@psf.upfronthosting.co.za> Message-ID: <1465344078.11.0.494710477921.issue27255@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Serhiy, please slow down and stop rewriting every single thing you see. Your rate of patches is prolific and hard to digest. Please give some consideration that the people who came before you (lots of them) put a lot of thought into what was done and were deliberately conservative. Dynamic statistics can vary widely depending on code being profiled (much like PGO optimizations for C compilers). For a prediction to have value, it needs to be a commonly used opcode; it must occur in a highly predictive pair with an intrinsic relationship rather than a coincidental relationship. FWIW, these tests aren't free. Global prediction tables have a limited size and are subject to aliasing. Mispredictions are expensive. Also, the ceval loop doesn't need more clutter. The new opcodes GET_YIELD_FROM_ITER, GET_AITER, GET_ANEXT, and GET_AWAITABLE haven't been considered before. The code in Python/compile.c shows that LOAD_CONST is the only possible next opcode, so these are reasonable candidates (i.e. the pair effectively acts as a single opcode). Of these, I think only GET_ANEXT and GET_AWAITABLE are likely to occur in a loop. So, these two may be worthwhile. All the rest should probably be skipped. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 20:10:06 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 08 Jun 2016 00:10:06 +0000 Subject: [issue27253] More efficient deepcopying of Mapping In-Reply-To: <1465320913.02.0.739523600127.issue27253@psf.upfronthosting.co.za> Message-ID: <1465344606.04.0.0664704573158.issue27253@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Is this ever needed? I'm not sure whether all these patches are being driven by reasonable use cases or whether it is just something that could be done. I thought the whole point of the views was to avoid copying. If so, there is a design principle that says roughly, "take things you want users to do and make them easy and fast, while leaving undesirable patterns in a less comfortable state". We don't have to break the copying and deepcopying, but we don't need to go out of our way to make them more efficient unless that is what we want users to be doing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 20:11:26 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 08 Jun 2016 00:11:26 +0000 Subject: [issue27252] Make dict views copyable In-Reply-To: <1465316849.69.0.0784684578474.issue27252@psf.upfronthosting.co.za> Message-ID: <1465344686.66.0.31128657456.issue27252@psf.upfronthosting.co.za> Raymond Hettinger added the comment: See also: http://bugs.python.org/issue27253 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 20:50:42 2016 From: report at bugs.python.org (John Mark Vandenberg) Date: Wed, 08 Jun 2016 00:50:42 +0000 Subject: [issue27187] Relax __all__ location requirement in PEP 8 In-Reply-To: <1464901602.05.0.802918160149.issue27187@psf.upfronthosting.co.za> Message-ID: <1465347042.85.0.162054842851.issue27187@psf.upfronthosting.co.za> John Mark Vandenberg added the comment: The revised text says __dunder__ should appear before any imports, however __future__ imports must appear first for obvious reasons. Does this need to be mentioned in the pep? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 21:00:12 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 08 Jun 2016 01:00:12 +0000 Subject: [issue27261] io.BytesIO.truncate does not work as advertised In-Reply-To: <1465332777.38.0.718878645897.issue27261@psf.upfronthosting.co.za> Message-ID: <1465347612.96.0.759530802685.issue27261@psf.upfronthosting.co.za> Martin Panter added the comment: BytesIO is supposed to implement IOBase. I would treat this as a bug in existing versions too. ---------- nosy: +martin.panter stage: -> needs patch versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 21:05:57 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 08 Jun 2016 01:05:57 +0000 Subject: [issue27180] Doc/pathlib: Please describe the behaviour of Path().rename() is depends on the platform (same as os.rename()) In-Reply-To: <1464866299.22.0.549959469595.issue27180@psf.upfronthosting.co.za> Message-ID: <1465347957.62.0.799453495959.issue27180@psf.upfronthosting.co.za> Berker Peksag added the comment: Could you please send your patch in unified diff format? See https://docs.python.org/devguide/patch.html for details. ---------- nosy: +berker.peksag stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 21:06:35 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 08 Jun 2016 01:06:35 +0000 Subject: [issue27251] TypeError in logging.HTTPHandler.emit; possible python 2 to 3 conversion issue In-Reply-To: <1465314338.49.0.176049462957.issue27251@psf.upfronthosting.co.za> Message-ID: <1465347995.67.0.217947842119.issue27251@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: test needed -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 21:19:30 2016 From: report at bugs.python.org (Evelyn Mitchell) Date: Wed, 08 Jun 2016 01:19:30 +0000 Subject: [issue27180] Doc/pathlib: Please describe the behaviour of Path().rename() is depends on the platform (same as os.rename()) In-Reply-To: <1464866299.22.0.549959469595.issue27180@psf.upfronthosting.co.za> Message-ID: <1465348770.28.0.601248438268.issue27180@psf.upfronthosting.co.za> Changes by Evelyn Mitchell : Added file: http://bugs.python.org/file43289/patch27180 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 22:21:23 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 08 Jun 2016 02:21:23 +0000 Subject: [issue27262] IDLE: move Aqua context menu code to maxosx Message-ID: <1465352483.17.0.330062690814.issue27262@psf.upfronthosting.co.za> New submission from Terry J. Reedy: Put the AquaTk code added to pyshell.main in #24801 where it should have gone originally. (My fault, ultimately.) See aqua_context.diff. This is a step in factoring main (currently about 170 lines) into a manageable number of function calls. I will try to add a test that 1. creates an editor window with a 'fixed' root and mocked .right_click_event method, generates a right click, and checks the mock event handler; 2. creates a context menu, etc. Serhiy, the docstring for .class_bind says "Bind to widgets with bindtag CLASSNAME". I have not and do not see 'bindtag' defined. Am I correct that it must refer to a tk widget class, rather than a python tkinter class, or subclass thereof? ---------- assignee: terry.reedy files: aqua_context.diff keywords: patch messages: 267760 nosy: serhiy.storchaka, terry.reedy priority: normal severity: normal stage: test needed status: open title: IDLE: move Aqua context menu code to maxosx type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43290/aqua_context.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 22:24:47 2016 From: report at bugs.python.org (Jarrod Petz) Date: Wed, 08 Jun 2016 02:24:47 +0000 Subject: [issue27263] IDLE sets the HOME environment variable breaking scripts Message-ID: <1465352687.77.0.957460905896.issue27263@psf.upfronthosting.co.za> New submission from Jarrod Petz: It seems IDEL is setting the environment variable 'HOME' on windows. Specifically I am on windows 8.1 This is extremly annoying and bad as according the code and doco, os.path.expanduser will preference this variable above others such as USERPROFILE. https://docs.python.org/3/library/os.path.html#os.path.expanduser This is causing scripts/libraries and in my case the AWS SDK boto3/botocore modules to break. As they are looking for config files in the users home location using os.path resolution order which should be %USERPROFILE% in my case as I don't have HOME set. But because idle is setting HOME to what looks to be my HOMEPATH and HOMEDRIVE this is making the AWS SDK unable to pickup the credential files required. path = "~/.aws/credentials" print(os.path.expanduser(path)) Should be C:\Users\myUserName/.aws/credentials But is instead H:\/.aws/credentials Please stop IDLE from setting this environment variable. Running the same scripts with python.exe or pythonw.exe works fine. ---------- components: IDLE messages: 267761 nosy: Jarrod Petz priority: normal severity: normal status: open title: IDLE sets the HOME environment variable breaking scripts type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 22:26:36 2016 From: report at bugs.python.org (Jarrod Petz) Date: Wed, 08 Jun 2016 02:26:36 +0000 Subject: [issue27263] IDLE sets the HOME environment variable breaking scripts In-Reply-To: <1465352687.77.0.957460905896.issue27263@psf.upfronthosting.co.za> Message-ID: <1465352796.29.0.571831212227.issue27263@psf.upfronthosting.co.za> Jarrod Petz added the comment: It also makes things none deterministic. As when I am off the domain or my network drive H:\ is unavailable it works and uses USERPROFILE. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 22:34:43 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 08 Jun 2016 02:34:43 +0000 Subject: [issue25738] http.server doesn't handle RESET CONTENT status correctly In-Reply-To: <1448583978.87.0.253695569638.issue25738@psf.upfronthosting.co.za> Message-ID: <1465353283.63.0.544787983939.issue25738@psf.upfronthosting.co.za> Martin Panter added the comment: Patch 07 looks fine. I presume you still want to do the porting to 3.5 and 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 22:54:10 2016 From: report at bugs.python.org (Susumu Koshiba) Date: Wed, 08 Jun 2016 02:54:10 +0000 Subject: [issue25738] http.server doesn't handle RESET CONTENT status correctly In-Reply-To: <1448583978.87.0.253695569638.issue25738@psf.upfronthosting.co.za> Message-ID: <1465354450.03.0.87835364065.issue25738@psf.upfronthosting.co.za> Susumu Koshiba added the comment: Great, thanks for checking. Attaching patch for 2.7. 3.5 will follow. ---------- Added file: http://bugs.python.org/file43291/issue25738_http_reset_content_2.7_02.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 23:01:50 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 08 Jun 2016 03:01:50 +0000 Subject: [issue27261] io.BytesIO.truncate does not work as advertised In-Reply-To: <1465332777.38.0.718878645897.issue27261@psf.upfronthosting.co.za> Message-ID: <1465354910.9.0.913031346075.issue27261@psf.upfronthosting.co.za> Xiang Zhang added the comment: Is this a bug or a documentation matter? Inspecting BytesIO.truncate's code, it does resizing similar to list, this seems to be a designed feature, which conflicts with the documented behaviour. ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 23:02:25 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 08 Jun 2016 03:02:25 +0000 Subject: [issue27261] io.BytesIO.truncate does not work as advertised In-Reply-To: <1465332777.38.0.718878645897.issue27261@psf.upfronthosting.co.za> Message-ID: <1465354945.71.0.101581415091.issue27261@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- nosy: +alexandre.vassalotti, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 23:05:23 2016 From: report at bugs.python.org (Susumu Koshiba) Date: Wed, 08 Jun 2016 03:05:23 +0000 Subject: [issue25738] http.server doesn't handle RESET CONTENT status correctly In-Reply-To: <1448583978.87.0.253695569638.issue25738@psf.upfronthosting.co.za> Message-ID: <1465355123.04.0.981822577176.issue25738@psf.upfronthosting.co.za> Susumu Koshiba added the comment: A patch for 3.5 attached. ---------- Added file: http://bugs.python.org/file43292/issue25738_http_reset_content_3.5_02.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 23:08:35 2016 From: report at bugs.python.org (Evelyn Mitchell) Date: Wed, 08 Jun 2016 03:08:35 +0000 Subject: [issue8491] Need readline command and keybinding information In-Reply-To: <1271879913.89.0.268262009322.issue8491@psf.upfronthosting.co.za> Message-ID: <1465355315.06.0.757283239527.issue8491@psf.upfronthosting.co.za> Changes by Evelyn Mitchell : Added file: http://bugs.python.org/file43293/patch8491 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 23:23:48 2016 From: report at bugs.python.org (Evelyn Mitchell) Date: Wed, 08 Jun 2016 03:23:48 +0000 Subject: [issue26446] Mention in the devguide that core dev stuff falls under the PSF CoC In-Reply-To: <1456514667.83.0.674412678031.issue26446@psf.upfronthosting.co.za> Message-ID: <1465356228.37.0.224633021232.issue26446@psf.upfronthosting.co.za> Changes by Evelyn Mitchell : Added file: http://bugs.python.org/file43294/patchCoreCoC _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 23:35:41 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 08 Jun 2016 03:35:41 +0000 Subject: [issue26446] Mention in the devguide that core dev stuff falls under the PSF CoC In-Reply-To: <1456514667.83.0.674412678031.issue26446@psf.upfronthosting.co.za> Message-ID: <1465356941.33.0.0785577500433.issue26446@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch Evelyn. The patch looks good to me. I have a couple of suggestions: 1. It seems like https://docs.python.org/devguide/coredev.html#responsibilities is a better place to put this 2. Core committers -> Core developers 3. PSF CoC -> PSF Code of Conduct 4. Could you also link "PSF Code of Conduct" to https://www.python.org/psf/codeofconduct/ ? I always need to look at the Sphinx docs but we need to make it look like `Spam eggs `_ ---------- nosy: +berker.peksag stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 23:38:18 2016 From: report at bugs.python.org (Demur Rumed) Date: Wed, 08 Jun 2016 03:38:18 +0000 Subject: [issue27127] Never have GET_ITER not followed by FOR_ITER In-Reply-To: <1464227064.89.0.81963094053.issue27127@psf.upfronthosting.co.za> Message-ID: <1465357098.22.0.988148815374.issue27127@psf.upfronthosting.co.za> Demur Rumed added the comment: Attaching forbegin3.patch. It reintroduces GET_ITER for the sole purpose of eagerly throwing. I decided to reuse GET_ITER over something like TEST_ITER as this way we can have GET_ITER flow into FOR_BEGIN & rely on the fast path of iter(iter(x)) GET_ITER/JUMP_FORWARD idea doesn't work because FOR_ITER is carefully setup currently to trace as existing on 2 separate lines. If we JUMP_FORWARD into FOR_ITER then that tracing triggers & our trace will say we executed the last line of the loop immediately before executing the iteration logic ---------- Added file: http://bugs.python.org/file43295/forbegin3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 23:42:18 2016 From: report at bugs.python.org (Demur Rumed) Date: Wed, 08 Jun 2016 03:42:18 +0000 Subject: [issue27127] Never have GET_ITER not followed by FOR_ITER In-Reply-To: <1464227064.89.0.81963094053.issue27127@psf.upfronthosting.co.za> Message-ID: <1465357338.7.0.44950566432.issue27127@psf.upfronthosting.co.za> Demur Rumed added the comment: Didn't see Raymond's response before posting, forbegin3 at least exists as a completion of the experiment to a passes-tests state. The tracing hacks to support an instruction corresponding to two separate lines support rejecting this idea ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 23:43:12 2016 From: report at bugs.python.org (Jarrod Petz) Date: Wed, 08 Jun 2016 03:43:12 +0000 Subject: [issue27263] IDLE sets the HOME environment variable breaking scripts In-Reply-To: <1465352687.77.0.957460905896.issue27263@psf.upfronthosting.co.za> Message-ID: <1465357392.88.0.161721530138.issue27263@psf.upfronthosting.co.za> Jarrod Petz added the comment: Worked around this by setting HOME to be USERPROFILE before IDLE starts Rather then change the system/user environment permanently. I edited the Idle script which the windows shortcut seems to run below. C:\Python35\Lib\idlelib\idle.pyw At the top of the script I added ------------------------------------ import os os.environ['HOME'] = os.environ['USERPROFILE'] ------------------------------------ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 23:44:08 2016 From: report at bugs.python.org (Ian Lee) Date: Wed, 08 Jun 2016 03:44:08 +0000 Subject: [issue27187] Relax __all__ location requirement in PEP 8 In-Reply-To: <1464901602.05.0.802918160149.issue27187@psf.upfronthosting.co.za> Message-ID: <1465357448.47.0.880553033371.issue27187@psf.upfronthosting.co.za> Ian Lee added the comment: Good catch. I'm uploading a new patch that addresses ``from __future__`` imports issue explicitly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 23:44:54 2016 From: report at bugs.python.org (Ian Lee) Date: Wed, 08 Jun 2016 03:44:54 +0000 Subject: [issue27187] Relax __all__ location requirement in PEP 8 In-Reply-To: <1464901602.05.0.802918160149.issue27187@psf.upfronthosting.co.za> Message-ID: <1465357494.8.0.114497294472.issue27187@psf.upfronthosting.co.za> Changes by Ian Lee : Added file: http://bugs.python.org/file43296/issue-27187-patch3.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 23:46:28 2016 From: report at bugs.python.org (Evelyn Mitchell) Date: Wed, 08 Jun 2016 03:46:28 +0000 Subject: [issue26446] Mention in the devguide that core dev stuff falls under the PSF CoC In-Reply-To: <1456514667.83.0.674412678031.issue26446@psf.upfronthosting.co.za> Message-ID: <1465357588.15.0.53949597372.issue26446@psf.upfronthosting.co.za> Evelyn Mitchell added the comment: Thank you for your help Berker. ---------- nosy: +Evelyn Mitchell Added file: http://bugs.python.org/file43297/patchCoreDevCoC _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 7 23:51:34 2016 From: report at bugs.python.org (Tommy Beadle) Date: Wed, 08 Jun 2016 03:51:34 +0000 Subject: [issue15476] Index "code object" and link to code object definition In-Reply-To: <1343459471.56.0.370073010984.issue15476@psf.upfronthosting.co.za> Message-ID: <1465357894.76.0.554115605195.issue15476@psf.upfronthosting.co.za> Tommy Beadle added the comment: Martin, thanks for the suggestion that worked. I believe this patch should have all of the issues addressed. ---------- Added file: http://bugs.python.org/file43298/0001-Issue-15476-Make-code-object-its-own-entry-in-the-do.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 00:27:32 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 08 Jun 2016 04:27:32 +0000 Subject: [issue8491] Need readline command and keybinding information In-Reply-To: <1271879913.89.0.268262009322.issue8491@psf.upfronthosting.co.za> Message-ID: <1465360052.41.0.793960147782.issue8491@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for the patch. I left a couple review comments. Also, this new paragraph should be outside the ?Note? box, which is specifically about libedit aka Editline, not Gnu Readline. ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 00:28:05 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jun 2016 04:28:05 +0000 Subject: [issue27262] IDLE: move Aqua context menu code to maxosx In-Reply-To: <1465352483.17.0.330062690814.issue27262@psf.upfronthosting.co.za> Message-ID: <1465360085.89.0.264085238629.issue27262@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: "bindtag" is an arbitrary string. Usually this is a name of Tk widget class of or "all". bindtags() allows to retrieve or set a list of bindtags associated with a widget. By default they are: full path of a widget, name of Tk class of widgets, full path of a toplevel window, "all". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 00:38:01 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 08 Jun 2016 04:38:01 +0000 Subject: [issue27242] Make the docs for NotImplemented & NotImplementedError unambigous In-Reply-To: <1465239567.69.0.773832868585.issue27242@psf.upfronthosting.co.za> Message-ID: <1465360681.74.0.347864254199.issue27242@psf.upfronthosting.co.za> Martin Panter added the comment: Emanuel, have you seen ? From my experience, install Sphinx, and then ?make -C Doc/ html?. About the patch, I think the ?.. note? boxes should be intended under the NotImplementedError heading. The current box looks wrong sandwiched between NotImplemnted and Ellipsis. (Personally I think ?Note? boxes are an annoying distraction anyway, and should normally be written into the surrounding text. In this case ?Note that? inside a ?Note? box seems doubly redundant. But other people seem to like them, so I try to resist complaining :) ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 00:44:48 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jun 2016 04:44:48 +0000 Subject: [issue17394] Add slicing support to collections.deque In-Reply-To: <1362972021.66.0.443403979058.issue17394@psf.upfronthosting.co.za> Message-ID: <1465361088.16.0.135338683125.issue17394@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Raymond, do you have a time to make a review? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 00:57:02 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jun 2016 04:57:02 +0000 Subject: [issue17900] Recursive OrderedDict pickling In-Reply-To: <1367610016.74.0.566900545996.issue17900@psf.upfronthosting.co.za> Message-ID: <1465361822.17.0.484522505687.issue17900@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think it is too late to revert this change. Is it worth to add a workaround for PyYAML if it still hasn't fixed serialization of OrderedDicts? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 01:01:33 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Wed, 08 Jun 2016 05:01:33 +0000 Subject: [issue27238] Bare except: usages in turtle.py In-Reply-To: <1465173486.36.0.354067909151.issue27238@psf.upfronthosting.co.za> Message-ID: <1465362093.38.0.341087952348.issue27238@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Thanks for the review and comments. This patch addresses your comments and changes the __file__-related one to catch Exception. ---------- Added file: http://bugs.python.org/file43299/issue27238-cr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 01:08:52 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jun 2016 05:08:52 +0000 Subject: [issue13451] sched.py: speedup cancel() method In-Reply-To: <1321923822.73.0.49972384361.issue13451@psf.upfronthosting.co.za> Message-ID: <1465362532.42.0.329455549594.issue13451@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 01:10:28 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Wed, 08 Jun 2016 05:10:28 +0000 Subject: [issue27260] Missing equality check for super objects In-Reply-To: <1465332483.31.0.223891907563.issue27260@psf.upfronthosting.co.za> Message-ID: <1465362628.23.0.836752821799.issue27260@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: This came up as part of a static analysis script that compares sets of method calls, including calls to methods on super(). The check was giving incorrect results because identical super() objects were comparing as different. super() is documented (https://docs.python.org/3/library/functions.html#super) as only delegating lookups for explicit attribute lookups, not for implicit lookups like that done by the == operator, so I think it would be safe to override tp_richcompare in C on super objects. In writing my patch, I'll be sure to test that the code you gave still works correctly though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 01:10:31 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jun 2016 05:10:31 +0000 Subject: [issue18844] allow weights in random.choice In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za> Message-ID: <1465362630.98.0.416115333933.issue18844@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Raymond, do you have a time for this issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 01:12:45 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jun 2016 05:12:45 +0000 Subject: [issue25628] Make namedtuple "verbose" and "rename" parameters into keyword only arguments In-Reply-To: <1447615273.45.0.0364929463097.issue25628@psf.upfronthosting.co.za> Message-ID: <1465362765.64.0.370711910763.issue25628@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 01:12:47 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Wed, 08 Jun 2016 05:12:47 +0000 Subject: [issue27260] Missing equality check for super objects In-Reply-To: <1465332483.31.0.223891907563.issue27260@psf.upfronthosting.co.za> Message-ID: <1465362767.36.0.185158403113.issue27260@psf.upfronthosting.co.za> Changes by Jelle Zijlstra : ---------- priority: normal -> low type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 01:13:47 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jun 2016 05:13:47 +0000 Subject: [issue25455] Some repr implementations don't check for self-referential structures In-Reply-To: <1445455038.6.0.824380060049.issue25455@psf.upfronthosting.co.za> Message-ID: <1465362827.62.0.562387451389.issue25455@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 01:16:23 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jun 2016 05:16:23 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1465362983.77.0.809936944598.issue24567@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 01:23:31 2016 From: report at bugs.python.org (Mark Lawrence) Date: Wed, 08 Jun 2016 05:23:31 +0000 Subject: [issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program In-Reply-To: <1366373912.56.0.138468709297.issue17797@psf.upfronthosting.co.za> Message-ID: <1465363411.35.0.4455890235.issue17797@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 01:25:57 2016 From: report at bugs.python.org (David Perra) Date: Wed, 08 Jun 2016 05:25:57 +0000 Subject: [issue27264] python 3.4 vs. 3.5 strftime same locale different output on Windows Message-ID: <1465363557.77.0.0608625622508.issue27264@psf.upfronthosting.co.za> New submission from David Perra: The execution of these commands in python 3.4.x (Windows 10 Home) import locale from datetime import datetime locale.setlocale(locale.LC_ALL, 'Spanish') datetime.strftime(datetime.now(), '%a %d %b %Y') renders the output 'Spanish_Spain.1252' 'mar 07 jun 2016' but with Python 3.5.x the output is 'Spanish_Spain.1252' 'ma. 07 jun. 2016' ---------- components: Library (Lib), Windows messages: 267786 nosy: David Perra, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: python 3.4 vs. 3.5 strftime same locale different output on Windows type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 01:26:14 2016 From: report at bugs.python.org (Demur Rumed) Date: Wed, 08 Jun 2016 05:26:14 +0000 Subject: [issue27127] Never have GET_ITER not followed by FOR_ITER In-Reply-To: <1464227064.89.0.81963094053.issue27127@psf.upfronthosting.co.za> Message-ID: <1465363574.7.0.965155461361.issue27127@psf.upfronthosting.co.za> Demur Rumed added the comment: I should've kept gitfit & forbegin more separated as issues. Attached is gitfit2, which only folds the GET_ITER into the comprehension if it isn't a generator so to pass test_genexps ---------- Added file: http://bugs.python.org/file43300/gitfit2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 01:30:13 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 08 Jun 2016 05:30:13 +0000 Subject: [issue15476] Index "code object" and link to code object definition In-Reply-To: <1343459471.56.0.370073010984.issue15476@psf.upfronthosting.co.za> Message-ID: <1465363813.26.0.434894265524.issue15476@psf.upfronthosting.co.za> Martin Panter added the comment: Yes it seems you even fixed the problem with the definition list, which I thought was not fixable :) ---------- stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 01:36:06 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jun 2016 05:36:06 +0000 Subject: [issue27127] Never have GET_ITER not followed by FOR_ITER In-Reply-To: <1464227064.89.0.81963094053.issue27127@psf.upfronthosting.co.za> Message-ID: <1465364166.73.0.32961056152.issue27127@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: As Dino noted in msg266453, this leaves the iterable on the stack while the loop is running. I think opcode reworking shouldn't change behavior. You should call GET_ITER or FOR_BEGIN before calling generator code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 01:37:18 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Wed, 08 Jun 2016 05:37:18 +0000 Subject: [issue24136] document PEP 448: unpacking generalization In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za> Message-ID: <1465364238.47.0.408293165973.issue24136@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Here's what I found reviewing what needs to be done here: - Neil's What's New patch apparently made it into the 3.5 release notes. - moigagoo's two patches haven't been committed. The text of both looks ok to me, but the patches don't apply cleanly. Other areas that still need updates: - https://docs.python.org/3/reference/expressions.html#list-displays and the sections for set, dict, and tuple displays need to mention PEP 448-style syntax. ---------- nosy: +Jelle Zijlstra _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 01:41:27 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 08 Jun 2016 05:41:27 +0000 Subject: [issue20699] Document that binary IO classes work with bytes-likes objects In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za> Message-ID: <1465364487.89.0.682178448265.issue20699@psf.upfronthosting.co.za> Martin Panter added the comment: New patch that I plan to commit: * Use bytes instead of str * bytes, bytearray or memoryview for readinto() methods * bytes or memoryview for write() methods * Added single ?Changed in version 2.7? notice under the IOBase class (rather than every version of readinto and write) * Since we only require 1-D byte array memoryviews, I resurrected the len(b) text * Removed outdated XXX comment about supporting buffer API, since bytearray and memoryview of bytes is now all that is required ---------- stage: patch review -> commit review Added file: http://bugs.python.org/file43301/bytes-like-param.py2.v9.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 01:51:14 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Wed, 08 Jun 2016 05:51:14 +0000 Subject: [issue24136] document PEP 448: unpacking generalization In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za> Message-ID: <1465365074.4.0.430718149426.issue24136@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: This updates reference_calls_syntax_update.diff. The previous patch's grammard had a mistake; it was missing commas between arguments. I believe all other patches in this diff are now obsolete. ---------- Added file: http://bugs.python.org/file43302/issue24136-expressions.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 01:53:26 2016 From: report at bugs.python.org (Eryk Sun) Date: Wed, 08 Jun 2016 05:53:26 +0000 Subject: [issue27263] IDLE sets the HOME environment variable breaking scripts In-Reply-To: <1465352687.77.0.957460905896.issue27263@psf.upfronthosting.co.za> Message-ID: <1465365206.92.0.511503830706.issue27263@psf.upfronthosting.co.za> Eryk Sun added the comment: This affects all Tkinter applications on Windows. For example, in Python 2.7: import Tkinter import ctypes libc = ctypes.CDLL('msvcr90') libc.getenv.restype = ctypes.c_char_p >>> libc.getenv(b"HOME") >>> root = Tkinter.Tk() >>> libc.getenv(b"HOME") 'C:\\Users\\me' TCL sets this environment variable in TclpSetVariables [1] and has since 1995 [2]. I don't think IDLE or any other Tkinter application should necessarily favor %USERPROFILE% over %HOMEDRIVE%%HOMEPATH%, and the default shouldn't be changed at this point. Probably the behavior should be documented for Tkinter and IDLE. [1]: https://github.com/tcltk/tcl/blob/core_8_6_4/win/tclWinInit.c#L502 [2]: https://github.com/tcltk/tcl/blob/core_8_6_4/changes#L1378 ---------- components: +Tkinter, Windows nosy: +eryksun, paul.moore, steve.dower, tim.golden, zach.ware versions: +Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 02:19:08 2016 From: report at bugs.python.org (Emin Ghuliev) Date: Wed, 08 Jun 2016 06:19:08 +0000 Subject: [issue27254] heap overflow in Tkinter module In-Reply-To: <1465324141.01.0.361051063774.issue27254@psf.upfronthosting.co.za> Message-ID: <1465366748.29.0.60697711942.issue27254@psf.upfronthosting.co.za> Emin Ghuliev added the comment: Yeah you're right but Python doesn't check the classname length. Therefore then heap overflow occurred in the Tcl. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 02:36:39 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 08 Jun 2016 06:36:39 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1465367799.85.0.121558653361.issue5124@psf.upfronthosting.co.za> Terry J. Reedy added the comment: To avoid bloating pyshell.main further, and to facilitate testing, I put the new code in a separate function called from main and a test. The test should PASS as is and FAIL on X11 with the call to fix_x11_paste commented out. If it does not, it is not a test and should be modified. When we have a real test, I will apply. x11-paste.diff is against 3.6. I already have 2.7 and 3.5 versions. ---------- assignee: -> terry.reedy Added file: http://bugs.python.org/file43303/x11-paste.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 02:50:52 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jun 2016 06:50:52 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1465368652.54.0.590873315508.issue5124@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Tested. LGTM. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 02:52:03 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jun 2016 06:52:03 +0000 Subject: [issue27254] heap overflow in Tkinter module In-Reply-To: <1465324141.01.0.361051063774.issue27254@psf.upfronthosting.co.za> Message-ID: <1465368723.84.0.240149083709.issue27254@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What size is safe for className? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 02:53:27 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 08 Jun 2016 06:53:27 +0000 Subject: [issue27262] IDLE: move Aqua context menu code to maxosx In-Reply-To: <1465352483.17.0.330062690814.issue27262@psf.upfronthosting.co.za> Message-ID: <1465368807.18.0.406654501981.issue27262@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I am asking because I noticed that every editor windows gets the same set of bindings set and destroyed, (as in the other part of the #24801 patch). Since events have a widget attribute, using bound methods with a self parameter is not necessary, so all the duplication seems redundant. But class_binding to Text is too broad. It there any way to register 'subclasses', similar to the way one can register style options as applying to a subset of, for instance, all Buttons? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 03:02:41 2016 From: report at bugs.python.org (Emin Ghuliev) Date: Wed, 08 Jun 2016 07:02:41 +0000 Subject: [issue27254] heap overflow in Tkinter module In-Reply-To: <1465324141.01.0.361051063774.issue27254@psf.upfronthosting.co.za> Message-ID: <1465369361.61.0.0559170807371.issue27254@psf.upfronthosting.co.za> Emin Ghuliev added the comment: the appropriate size should be chosen I) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 03:12:56 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jun 2016 07:12:56 +0000 Subject: [issue27262] IDLE: move Aqua context menu code to maxosx In-Reply-To: <1465352483.17.0.330062690814.issue27262@psf.upfronthosting.co.za> Message-ID: <1465369976.55.0.910742911022.issue27262@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think you can just use bindtags(). button = Button(...) bindtags = button.bindtags() button.bindtags(bindtags[:1] + ['MyButton'] + bindtags[1:]) root.bind_class('MyButton', ...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 04:04:21 2016 From: report at bugs.python.org (=?utf-8?q?Rados=C5=82aw_Szalski?=) Date: Wed, 08 Jun 2016 08:04:21 +0000 Subject: [issue27265] Hash of different, specific Decimals created from str is the same Message-ID: <1465373061.21.0.960848543198.issue27265@psf.upfronthosting.co.za> New submission from Rados?aw Szalski: Python 2.7.11 (default, May 9 2016, 19:53:39) [GCC 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.31)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from decimal import Decimal >>> hash(Decimal('0.05')) == hash(Decimal('0.005')) True >>> hash(Decimal(0.05)) == hash(Decimal(0.005)) False Interactive example: https://repl.it/CZUJ/6 Those values are numerically different and IMO should not have equal hashes. I am aware of the quirk with hash(-1) == hash(-2) which is at play here. This only applies to Decimals created from strings as they are hashed differently than float-based ones. What happens? The following equation is True: >>> hash(Decimal('0.005')) == hash(Decimal('0.05')) What I expected to happen? The following equation to be False: >>> hash(Decimal('0.005')) == hash(Decimal('0.05')) Platform: MacBook Pro Retina, 13", early 2015, OSX 10.11.5 Tested on Python Versions: 2.7.3, 2.7.10, 2.7.11 (installed via pyenv), all exhibit the same behavior Relevant (not duplicate) issues I've found: http://bugs.python.org/issue10356 - decimal.py: hash of -1 http://bugs.python.org/issue8188 - Unified hash for numeric types. --- Transcript of the interactive example: https://repl.it/CZUJ/6: from decimal import Decimal # These two different decimals have equal hashes print(hash(Decimal('0.005')) == hash(Decimal('0.05'))) # Internally, Decimal's hash is computed like this (sign, exp + len(int), int) print(hash((0, -2+len('5'), '5')) == hash((0, -3+len('5'), '5'))) # Removing constants, this becomes print(hash(-2+len('5')) == hash(-3+len('5'))) # Which can be further simplified to: print(hash(-1) == hash(-2)) # They both return -2, because at the CPython level, -1 is reserved for errors # Whereas: print(hash(Decimal(0.005)) == hash(Decimal(0.05))) # And this is because Decimals created from floats are hashed as floats ---------- components: Library (Lib) messages: 267802 nosy: Rados?aw Szalski, mark.dickinson priority: normal severity: normal status: open title: Hash of different, specific Decimals created from str is the same type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 04:04:33 2016 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jun 2016 08:04:33 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465373073.53.0.0797074593352.issue26839@psf.upfronthosting.co.za> Larry Hastings added the comment: I've revised my thinking on the subject. First, my previous statements stand: Python startup must not block. "import random" must not block. Now I'm thinking that "os.urandom()" must not block, too. Here's my reasoning. -- If you read #25003, it's clear that /dev/urandom is a well-known UNIX facility with well-known, predictable behavior. One behavior that I'll draw particular attention to now: it will never block. If the system is low on entropy, /dev/urandom will produce lower-quality random bits. Again I repeat myself: this is the *expected* behavior. It is so completely the expected behavior, that today's special celebrity guest on the issue, Mr. Theodore Ts'o himself, added /dev/random specifically so it would be permitted to block when the system was low on entropy. He *did not change* the behavior of /dev/urandom. He added a *new device*. A well-informed engineer would see "os.urandom()" and predict (correctly) that Python has provided a thin layer over /dev/urandom. Thus os.urandom() should provide the same well-known, predictable behavior as /dev/urandom. It's fine to enhance os.urandom(). For example, it's fine to provide higher-quality bits where available. It's fine to provide the function on Windows which doesn't have a /dev/urandom object. What is *not* fine is to degrade its behavior. /dev/urandom is known to never, ever block. This is a *feature*. os.urandom(), therefore, must also never, ever block. Yes, this means that on these cloud instances with no entropy (yet), os.urandom() may return these low-quality random bits. Just like /dev/urandom does. If I understand the APIs correctly, I'm fine with os.urandom() calling getrandom(,,GRND_RANDOM|GRND_NONBLOCK). If that fails with EAGAIN it should fall back to reading from /dev/urandom, or getrandom(,,GRND_NONBLOCK) if that makes sense. (IDK if that's Linux-specific; if it is I suppose /dev/urandom is the more cross-platform way to go.) -- If this is seen as the end of the world by the crypto guys in the thread, let me say that I'm willing to consider adding a new function in 3.5.2. I would propose it be spelled "os.getrandom(n, block=True)". Crypto code could use this function if available, and fall back to os.urandom() where it was not. This means you're covered: in 3.5.0 and 3.5.1 you use os.urandom(), and in 3.5.2+ you use os.getrandom(), and in both circumstances you'll block if there's insufficient entropy. -- p.s. Colm Buckley: you notice how dstufft's patch got a "review" link, and none of the patches you posted got one? That's because his is based on the current 3.5 repo and yours aren't. This "review" link is very useful in reading your patches. Please in the future try to base your patches against 3.5 trunk. It's easy: % hg clone https://hg.python.org/cpython/ % cd cpython % hg up -r 3.5 (do your work here) % hg diff > patchfile (upload patchfile) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 04:16:34 2016 From: report at bugs.python.org (Cory Benfield) Date: Wed, 08 Jun 2016 08:16:34 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465373794.05.0.31528321225.issue26839@psf.upfronthosting.co.za> Cory Benfield added the comment: > If you read #25003, it's clear that /dev/urandom is a well-known UNIX facility with well-known, predictable behavior. One behavior that I'll draw particular attention to now: it will never block. If the system is low on entropy, /dev/urandom will produce lower-quality random bits. That's not accurate. /dev/urandom is a well-known UNIX facility, yes, but it does not have consistent behaviour across Unices. The behaviour you've described here Larry is a well-known *Linux* behaviour. However, on other Unices the behaviour is different. Here, for example, is the relevant man page from Mac OS X ("man 4 random"): /dev/urandom is a compatibility nod to Linux. On Linux, /dev/urandom will produce lower quality output if the entropy pool drains, while /dev/random will prefer to block and wait for additional entropy to be collected. With Yarrow, this choice and distinction is not necessary, and the two devices behave identically. You may use either. Note the specific wording here: "the two devices behave identically". That is to say, on OS X both /dev/random and /dev/urandom are identical devices, and that includes the fact that both will in principle block if used without sufficient entropy. OS X's implementation is a direct descendent of FreeBSD's, so the same caveats apply there, and in fact all the BSDs have this exact same behaviour. So, again, I repeat my objection from above: if the concern is that starting Python must never block, then Python must *never* read from /dev/urandom on startup. Otherwise, Python *can* block on BSDs (OS X included in principle, though in practice I doubt Apple will use Python that early in boot). At this point I literally no longer care whether os.urandom() is just a wrapper around /dev/urandom: we can look back on this in 10 years and see how we feel about the choices made by core dev at that time. But if we're arguing that this issue is about "Python must never block at startup", then we really have to acknowledge that /dev/urandom *can block* on some Unices, and so is entirely unacceptable for reading at startup. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 04:19:30 2016 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jun 2016 08:19:30 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465373970.95.0.389606436959.issue26839@psf.upfronthosting.co.za> Larry Hastings added the comment: Are you certain that /dev/urandom will block on Mac OS X if sufficient entropy is not available? The dismissive tone ("this choice and distinction is not necessary") suggests that *their* implementation is superior, and it could hardly be seen as superior if sometimes it blocks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 04:29:17 2016 From: report at bugs.python.org (Cory Benfield) Date: Wed, 08 Jun 2016 08:29:17 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465374557.82.0.736067829815.issue26839@psf.upfronthosting.co.za> Cory Benfield added the comment: I have never seen it block in person, but I also wouldn't expect to. OS X's blocking guarantees are the same as FreeBSD's: that is, both /dev/random and /dev/urandom block until sufficient entropy has been gathered at startup and then never block again. This means that, on OS X, in practice, /dev/urandom does never block, because you basically can't run user code early enough to encounter this problem. FreeBSD again has the exact same behaviour: /dev/urandom is a symlink to /dev/random, and both will block at startup until sufficient entropy is gathered and never again. This is the bigger risk for Python, because if Linux people want to use Python in their init system it's not unreasonable for FreeBSD folks to want to do it too. This is why I'm concerned about this "solution": while there's no question that adding getrandom() made the situation worse on Linux, it has drawn our attention to the fact that Python is relying on Linux-only semantics of /dev/urandom on all Unices. That's probably not a good plan. (The above is all facts. Everything in these parentheticals is opinion. Please disregard as appropriate. I agree with the OS X devs in that I believe their implementation *is* better than Linux's: sorry Ted! There is no reason to be concerned about using a good kernel CSPRNG once sufficient entropy has been gathered *once*. The CSPRNG essentially "stretches" the entropy out into a long sequence of numbers, much like a cipher like AES "stretches" the entropy in the key across the entire cipherstream. Talking about "running out" of entropy in one of these devices is weird to me: as a blog post linked earlier mentions, it's like talking about "running out of key" in an encryption algorithm. It seems to me, then, that Linux's /dev/random is wrong in most situations (because it sometimes blocks), and /dev/urandom is wrong in some situations (because it'll run before it has enough entropy to properly seed the CSPRNG and it won't tell you that that is what has happened). On OS X, the best of both worlds occurs: you get no random numbers until sufficient entropy has been gathered to seed the CSPRNG, and then you get good random numbers from that point on. Please note: I am not a trained cryptographer. However, trained cryptographers have agreed with this set of sentiments, so I think I'm on pretty good ground here.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 04:38:47 2016 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jun 2016 08:38:47 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465375127.41.0.962205627216.issue26839@psf.upfronthosting.co.za> Larry Hastings added the comment: So, in short, you don't know. #25003 is about Solaris, and the reporter clearly had the expectation that /dev/urandom would never block. The documentation on Linux is clear: /dev/urandom will never block. That's two. This "StackExchange" discussion: http://security.stackexchange.com/questions/42952/how-can-i-measure-and-increase-entropy-on-mac-os-x suggests that the Yarrow-based /dev/random and /dev/urandom on OS X will *both* degrade to PRNG if insufficient entropy is present. Thus they are are *both* like /dev/urandom, and *neither* will ever block. The salient quote is this, from the random(4) manpage on OS X: "If the SecurityServer system daemon fails for any reason, output quality will suffer over time without any explicit indication from the random device itself." That sure sounds like bad quality PRNG random bits to me. So that's three. Again: ISTM that the universal expectation is that /dev/urandom will never block. Therefore os.urandom() should also never block. That it blocks in 3.5.0 and 3.5.1 is a performance regression and should be fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 04:43:00 2016 From: report at bugs.python.org (Christian Heimes) Date: Wed, 08 Jun 2016 08:43:00 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465375380.54.0.788536452448.issue26839@psf.upfronthosting.co.za> Christian Heimes added the comment: Cory, thanks for summing it up for us. I totally agree with you. In my opinion it is troublesome to have different behavior on platforms. We can implement a workaround for Linux, but not for BSD. Or would O_NONBLOCK cause read() to fail with EWOULDBLOCK on /dev/urandom device? It might be secure enough to use srandom() / random() instead of /dev/urandom in some platforms. It still won't do any good on platforms like Raspberry Pie since the SoC has no RTC. Without a RTC the clock is not set yet. It happens much later in the boot phase when network is available. I don't see a cross-platform solution that is able to handle this super-special case without opening a potential security issue for the majority of users. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 04:44:56 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jun 2016 08:44:56 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465375496.27.0.637592042142.issue26839@psf.upfronthosting.co.za> STINNER Victor added the comment: To see how long it takes to initialize urandom pool, you can grep your kernel logs. On my physical PC with real hardware, interruptions etc. it's quite fast: 5 seconds. -- Logs begin at mar. 2016-01-26 07:54:37 CET, ... ... juin 06 18:34:47 smithers kernel: random: systemd urandom read with 2 bits of entropy available ... juin 06 18:34:52 smithers kernel: random: nonblocking pool is initialized I get that the "kernel: random: systemd urandom read with 2 bits of entropy available" message comes from the kernel when systemd reads from /dev/urandom whereas the pool is not initialized yet. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 04:48:10 2016 From: report at bugs.python.org (Christian Heimes) Date: Wed, 08 Jun 2016 08:48:10 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465375690.8.0.936588256285.issue26839@psf.upfronthosting.co.za> Christian Heimes added the comment: Larry, /dev/urandom blocks on BSD when it hasn't been seeded yet. But it looks like we can use sysctl to fetch the seed state from kern.random.sys.seeded. https://www.freebsd.org/cgi/man.cgi?query=random&sektion=4 The software generator will start in an unseeded state, and will block reads until it is (re)seeded. This may cause trouble at system boot when keys and the like are generated from /dev/random so steps should be taken to ensure a reseed as soon as possible. The sysctl(8) controlling the seeded status (see below) may be used if security is not an issue or for convenience during setup or development. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 04:59:52 2016 From: report at bugs.python.org (Colm Buckley) Date: Wed, 08 Jun 2016 08:59:52 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465376392.16.0.0290553721644.issue26839@psf.upfronthosting.co.za> Colm Buckley added the comment: [[ Larry - thanks for the Mercurial pointers. I was starting from the Debian sources because I initially assumed this was a Debian problem. Will switch to hg in future. ]] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 05:01:24 2016 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jun 2016 09:01:24 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465376484.23.0.344793502846.issue26839@psf.upfronthosting.co.za> Larry Hastings added the comment: I don't know if anyone literally still uses BSD. But on FreeBSD, /dev/urandom can block. So let me revise my statement slightly. Developers on platform X know how *their* /dev/urandom behaves. They should rightly expect that os.urandom() is a thin wrapper around their local /dev/urandom. If their /dev/urandom doesn't block, then os.urandom() shouldn't block. If their /dev/urandom blocks, then it's acceptable that their os.urandom() would block. What I'm trying to avoid here is the surprising situation where someone is using Python on a system where /dev/urandom will never block, and os.urandom() blocks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 05:12:34 2016 From: report at bugs.python.org (Cory Benfield) Date: Wed, 08 Jun 2016 09:12:34 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465377153.99.0.246702145747.issue26839@psf.upfronthosting.co.za> Cory Benfield added the comment: > What I'm trying to avoid here is the surprising situation where someone is using Python on a system where /dev/urandom will never block, and os.urandom() blocks. At this point I literally do not understand what issue we're trying to solve then. If the problem is that os.urandom() must behave exactly like /dev/urandom, then sure, that got regressed. However, I've been talking based on your two previous pronouncements: > First, my previous statements stand: Python startup must not block. "import random" must not block. and > I am officially making a pronouncement as Release Manager: Python 3.5 *must > not* take 90 seconds to start up under *any* circumstances. I view this as > a performance regression, and it is and will remain a release blocker for > 3.5.2. > > Python *must not* require special command-line flags to avoid a 90 second > startup time. Python *must not* require a special environment-variable to > avoid a 90 second startup time. This is no longer open to debate, and I > will only be overruled by Guido. Now, if that's the case, then this patch does not fix that problem. It fixes that problem *on Linux*, but not on BSDs. Perhaps you meant to say that those pronouncements only apply to Linux. That's fine, it's your prerogative. But as written, they don't: they're unconditional. And if they are unconditional, then again I feel like we have to say that /dev/urandom should get *out* of the call path on interpreter startup, because it absolutely can block. And based on Colm's original problem around gathering entropy, which is almost certainly not a Linux-specific concern, I see no reason to believe that this is a hypothetical concern on the BSDs. So, let me ask a very direct question: does the position about 90s startup apply only to Linux? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 05:19:03 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jun 2016 09:19:03 +0000 Subject: [issue27266] Add block keyword-only optional parameter to os.urandom() Message-ID: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> New submission from STINNER Victor: Follow-up of the issue #26839: I propose to add a "block" keyword-only optional parameter to os.urandom(). I chose to make the parameter a keyword-only to avoid suprises and backward incompatible change and because I want to make this change in Python 3.5.2. The attached patch: * add block parameter to os.urandom() * modify random.Random constructor to call os.urandom() with block=False * modify _PyOS_URandom() to add a block parameter * modify dev_urandom_noraise() to not block The block parameter currently only changes the behaviour on Linux when the getrandom() syscall is used and the urandom entropy pool is not initialized. With the change, os.urandom() blocks by default, but Python startup and "import random" doesn't block even if the urandom entropy pool is not initialized yet. ---------- files: urandom_block.patch keywords: patch messages: 267814 nosy: haypo priority: normal severity: normal status: open title: Add block keyword-only optional parameter to os.urandom() versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43304/urandom_block.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 05:21:05 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jun 2016 09:21:05 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465377665.06.0.153420436849.issue26839@psf.upfronthosting.co.za> STINNER Victor added the comment: Hi. I created the issue #27266 "Add block keyword-only optional parameter to os.urandom()" which is compromise between all proposed solutions and should fix *all* urandom issues ;-) * os.urandom() remains secure by default, as asked by our security experts * Python startup (hash secret) and "import random" don't block anymore Happy? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 05:25:08 2016 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jun 2016 09:25:08 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465377908.74.0.990700108818.issue26839@psf.upfronthosting.co.za> Larry Hastings added the comment: You're right, it's remotely possible that on platforms where /dev/urandom could block, Python startup could therefore also block. And I'm not proposing we fix that, as so far nobody has reported it as a problem. This suggests to me that yes I'm talking specifically about the regression on Linux in the 3.5 series. But honestly it's too late for me to say for sure one way or another. I need to go to bed. p.s if we have to slip RC1 by a day or two in order to get this settled, that's okay, but hopefully I can keep final on schedule. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 05:30:10 2016 From: report at bugs.python.org (Cory Benfield) Date: Wed, 08 Jun 2016 09:30:10 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465378210.76.0.166782523032.issue26839@psf.upfronthosting.co.za> Cory Benfield added the comment: > You're right, it's remotely possible that on platforms where /dev/urandom > could block, Python startup could therefore also block. And I'm not > proposing we fix that, as so far nobody has reported it as a problem. > > This suggests to me that yes I'm talking specifically about the regression > on Linux in the 3.5 series. Ok, so with that clarification I personally would prefer Victor's patch from #27266, but can also understand wanting to leave the codebase as-is. Either way would be consistent with your goals, Larry. Victor's patch is more secure, but does cause os.urandom to diverge from the semantics of /dev/urandom in extreme conditions (specifically, early boot) on Linux. That's your tradeoff to make, Larry. =) I think both sides have been well-argued here. Thanks for clarifying. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 05:31:10 2016 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jun 2016 09:31:10 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465378270.78.0.786052578654.issue26839@psf.upfronthosting.co.za> Larry Hastings added the comment: > Hi. I created the issue #27266 "Add block keyword-only optional parameter > to os.urandom()" which is compromise between all proposed solutions and > should fix *all* urandom issues ;-) > > * os.urandom() remains secure by default, as asked by our security experts > * Python startup (hash secret) and "import random" don't block anymore > > Happy? Probably not. What is the default value of the "block" parameter? If called with block=False on FreeBSD, where /dev/urandom may block sometimes, what does the function do? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 05:39:04 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jun 2016 09:39:04 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465378744.6.0.846317155805.issue26839@psf.upfronthosting.co.za> STINNER Victor added the comment: no-urandom-by-default.diff uses a very weak source of entropy for random.Random :-( I'm fighting against weak sources of entropy since many years... This change introduces the bug similar to OpenSSL RAND_bytes() bug (two processes with the same pid can produce the same random sequence): two Python processes started "at the same time" (with a resolution of 1/256 sec ~= 3.9 ms) produces the same random sequence. With my script: --- import subprocess, sys args = [sys.executable, '-S', '-c', 'import random; print([random.randint(0, 999) for _ in range(4)])'] numbers = set() procs = [subprocess.Popen(args, stdout=subprocess.PIPE) for _ in range(10)] for proc in procs: stdout = proc.communicate()[0] numbers.add(stdout.rstrip()) for line in numbers: print(line.decode()) print("duplicates", len(procs) - len(numbers)) --- Output: --- [68, 812, 821, 421] [732, 506, 562, 439] [70, 711, 476, 230] [411, 474, 729, 837] [530, 161, 699, 521] [818, 897, 582, 38] [42, 132, 359, 275] [630, 863, 370, 288] [497, 716, 61, 93] duplicates 1 --- ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 05:40:22 2016 From: report at bugs.python.org (Ralph Haist) Date: Wed, 08 Jun 2016 09:40:22 +0000 Subject: [issue27267] memory leak in _ssl.c, function load_cert_chain Message-ID: <1465378822.97.0.0135826659877.issue27267@psf.upfronthosting.co.za> New submission from Ralph Haist: Test program: $ cat sslTest.py import ssl ctx = ssl.SSLContext(ssl.PROTOCOL_SSLv23) ctx.load_cert_chain("mycert.pem") $ valgrind reports a memory leak if this test program is executed by python2.7 as follows: ==7266== 24 bytes in 1 blocks are definitely lost in loss record 564 of 2,578 ==7266== at 0x4C2815D: malloc (vg_replace_malloc.c:299) ==7266== by 0x4BCDAA: convertsimple (getargs.c:1160) ==7266== by 0x4BCDAA: convertitem (getargs.c:514) ==7266== by 0x4BD841: vgetargskeywords (getargs.c:1618) ==7266== by 0x4BE47B: _PyArg_ParseTupleAndKeywords_SizeT (getargs.c:1464) ==7266== by 0x6DCFADC: load_cert_chain (_ssl.c:2536) ==7266== by 0x4AA75D: call_function (ceval.c:4350) ==7266== by 0x4AA75D: PyEval_EvalFrameEx (ceval.c:2987) ==7266== by 0x4AE209: PyEval_EvalCodeEx (ceval.c:3582) ==7266== by 0x4AE641: PyEval_EvalCode (ceval.c:669) ==7266== by 0x4CC9AD: run_mod (pythonrun.c:1370) ==7266== by 0x4CDAC1: PyRun_FileExFlags (pythonrun.c:1356) ==7266== by 0x4CE4C9: PyRun_SimpleFileExFlags (pythonrun.c:948) ==7266== by 0x4155FF: Py_Main (main.c:654) After applying this patch to _ssl.c, the memory leak disappears: $ diff -rc _ssl.c.org _ssl.c *** _ssl.c.org 2016-05-18 14:18:39.093418625 +0200 --- _ssl.c 2016-05-18 14:41:50.215460826 +0200 *************** *** 2611,2616 **** --- 2611,2617 ---- SSL_CTX_set_default_passwd_cb(self->ctx, orig_passwd_cb); SSL_CTX_set_default_passwd_cb_userdata(self->ctx, orig_passwd_userdata); PyMem_Free(pw_info.password); + PyMem_Free(certfile_bytes); Py_RETURN_NONE; error: ---------- components: Extension Modules messages: 267820 nosy: rhaist priority: normal severity: normal status: open title: memory leak in _ssl.c, function load_cert_chain type: resource usage versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 05:43:02 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jun 2016 09:43:02 +0000 Subject: [issue27266] Add block keyword-only optional parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465378982.59.0.637663701118.issue27266@psf.upfronthosting.co.za> STINNER Victor added the comment: Larry Hastings (msg267818, on the issue #26839): > What is the default value of the "block" parameter? False > If called with block=False on FreeBSD, where /dev/urandom may block sometimes, what does the function do? The function blocks. In which case FreeBSD urandom can block? Is there a way to read from /dev/urandom without blocking? If not, _PyOS_URandom() may use arc4random() on FreeBSD if block is false. I suggest to enhance _PyOS_URandom() after the Python 3.5.2 release. My patch is a quick fix for Python 3.5.2, it can be enhanced later. I chose to only modify the behaviour on Linux since issues #26839 and #25420 were only reported on Linux. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 05:43:07 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jun 2016 09:43:07 +0000 Subject: [issue27266] Add block keyword-only optional parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465378987.4.0.609456756781.issue27266@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 05:43:13 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 08 Jun 2016 09:43:13 +0000 Subject: [issue24136] document PEP 448: unpacking generalization In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za> Message-ID: <1465378993.72.0.113329045794.issue24136@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for helping with this Jelle. The documentation of unpacking sequences vs iterables was adjusted in 3.6 as part of Issue 23275. I guess part of revision 8a0754fed986 should be extracted to 3.5 as well. Looking at the function call syntax, positional and starred should be optional. I don?t think your syntax would allow print(file=stderr). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 05:44:12 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jun 2016 09:44:12 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465379052.63.0.685303865179.issue26839@psf.upfronthosting.co.za> STINNER Victor added the comment: Larry Hastings: > > Hi. I created the issue #27266 "Add block keyword-only optional parameter to os.urandom()" (...) > > Happy? > Probably not. (...) I replied on the issue #27266. Sorry I'm unable to follow this issue, there are too many messages now :-( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 05:45:16 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jun 2016 09:45:16 +0000 Subject: [issue27266] Add block keyword-only optional parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465379116.49.0.0961809307082.issue27266@psf.upfronthosting.co.za> STINNER Victor added the comment: This issue is the opposite of the issue #27250 "Add os.urandom_block()". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 05:46:41 2016 From: report at bugs.python.org (Christian Heimes) Date: Wed, 08 Jun 2016 09:46:41 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1465378744.6.0.846317155805.issue26839@psf.upfronthosting.co.za> Message-ID: <50319774-9208-25bf-6400-8787147039a9@cheimes.de> Christian Heimes added the comment: On 2016-06-08 11:39, STINNER Victor wrote: > > STINNER Victor added the comment: > > no-urandom-by-default.diff uses a very weak source of entropy for random.Random :-( I'm fighting against weak sources of entropy since many years... It is totally fine to init the MT of random.random() from a weak entropy source. Just keep in mind that a Mersenne Twister is not a CPRNG. There is simply no reason why you want to init a MT from a CPRNG. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 05:50:28 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 08 Jun 2016 09:50:28 +0000 Subject: [issue24136] document PEP 448: unpacking generalization In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za> Message-ID: <1465379428.35.0.527583979043.issue24136@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: -pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 05:50:50 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 Jun 2016 09:50:50 +0000 Subject: [issue25738] http.server doesn't handle RESET CONTENT status correctly In-Reply-To: <1448583978.87.0.253695569638.issue25738@psf.upfronthosting.co.za> Message-ID: <20160608095045.38517.62557.85470C7D@psf.io> Roundup Robot added the comment: New changeset 1dc495007b8f by Martin Panter in branch '3.5': Issue #25738: Don?t send message body for 205 Reset Content https://hg.python.org/cpython/rev/1dc495007b8f New changeset b1041ddb1391 by Martin Panter in branch '2.7': Issue #25738: Don?t send message body for 205 Reset Content https://hg.python.org/cpython/rev/b1041ddb1391 New changeset de5e1eb4a88d by Martin Panter in branch 'default': Issue #25738: Merge HTTP server from 3.5 https://hg.python.org/cpython/rev/de5e1eb4a88d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 05:50:50 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 Jun 2016 09:50:50 +0000 Subject: [issue21313] Py_GetVersion() is broken when using mqueue and a long patch name In-Reply-To: <1397945838.86.0.227153547567.issue21313@psf.upfronthosting.co.za> Message-ID: <20160608095045.38517.16981.FBEAF5FE@psf.io> Roundup Robot added the comment: New changeset b86e259271b3 by Martin Panter in branch '2.7': Issue #21313: Tolerate truncated buildinfo in sys.version https://hg.python.org/cpython/rev/b86e259271b3 New changeset 4deec876db0d by Martin Panter in branch '3.5': Issue #21313: Tolerate truncated buildinfo in sys.version https://hg.python.org/cpython/rev/4deec876db0d New changeset aec5a3fc4890 by Martin Panter in branch 'default': Issue #21313: Merge version parsing from 3.5 https://hg.python.org/cpython/rev/aec5a3fc4890 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 05:58:43 2016 From: report at bugs.python.org (SilentGhost) Date: Wed, 08 Jun 2016 09:58:43 +0000 Subject: [issue27267] memory leak in _ssl.c, function load_cert_chain In-Reply-To: <1465378822.97.0.0135826659877.issue27267@psf.upfronthosting.co.za> Message-ID: <1465379923.86.0.422101284928.issue27267@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 06:03:36 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jun 2016 10:03:36 +0000 Subject: [issue27266] Add block keyword-only optional parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465380216.1.0.333037865675.issue27266@psf.upfronthosting.co.za> STINNER Victor added the comment: > Is there a way to read from /dev/urandom without blocking? If not, _PyOS_URandom() may use arc4random() on FreeBSD if block is false. I suggest to enhance _PyOS_URandom() after the Python 3.5.2 release. See the issue #22542 "Use arc4random under OpenBSD for os.urandom() if /dev/urandom is not present". It looks like arc4random() is now initialized with getentropy(KEYSZ+IVSZ) (32+8 = 40 bytes) on OpenBSD: http://bxr.su/OpenBSD/lib/libc/crypt/arc4random.c getentropy() is non-blocking. By the way, os.urandom() is now implemented with getentropy() on OpenBSD. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 06:06:01 2016 From: report at bugs.python.org (Donald Stufft) Date: Wed, 08 Jun 2016 10:06:01 +0000 Subject: [issue27266] Add block keyword-only optional parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465380361.84.0.996656818192.issue27266@psf.upfronthosting.co.za> Donald Stufft added the comment: I'm pretty sure that getentropy on OpenBSD will block until the pool is initialized. ---------- nosy: +dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 06:17:14 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 08 Jun 2016 10:17:14 +0000 Subject: [issue22942] Language Reference - optional comma In-Reply-To: <1416945158.04.0.329806790258.issue22942@psf.upfronthosting.co.za> Message-ID: <1465381034.74.0.707272247727.issue22942@psf.upfronthosting.co.za> Martin Panter added the comment: Bug 1 is still present in 3.5. In 3.6 it is no longer relevant because the documentation was changed for Issue 9232 (allowing trailing commas in function definitions). Bug 2 is present in 2.7, but is not relevant to 3.5+. Trailing commas are now allowed in function calls, probably thanks to PEP 448, unpacking generalizations. Bug 3 has been fixed in Issue 27042. ---------- stage: -> needs patch versions: +Python 2.7, Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 06:23:58 2016 From: report at bugs.python.org (Donald Stufft) Date: Wed, 08 Jun 2016 10:23:58 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465381438.51.0.0280297469091.issue26839@psf.upfronthosting.co.za> Donald Stufft added the comment: Larry, I would greatly prefer it if we would allow os.urandom to block on Linux, at least by default. This will make os.urandom behavior similarly on most modern platforms. The cases where this is going to matter are extreme edge cases, for most users they'll just silently be a bit more secure-- important for a number of use cases of Python (think for instance, if someone has a SSH server written in Twisted that generates it's own host keys, a perfectly reasonable use of os.urandom). We've been telling people that os.urandom is the right source for generating randomness for cryptographic use for ages, and I think it is important to use the tools provided to us by the platform to best satisfy that use case by default-- in this case, getrandom() in blocking mode is the best tool provided by the Linux platform. People writing Python code cannot expect that os.urandom will not block, because on most platforms it *will* block on intialization. However, the cases where it will block are a fairly small window, so by allowing it to block we're giving a better guarantee for very little downside-- essentially that something early on in the boot process shouldn't call os.urandom(), which is the right behavior on Linux (and any other OS) anyways. The problem is that the Python interpreter itself (essentially) calls os.urandom() as part of it's start up sequence which makes it unsuitable for use in very early stage boot programs. In the abstract, it's not possible to fix this on every single platform without removing all use of os.urandom from Python start up (which I think would be a bad idea). I think Colm's nonblocking_urandom_noraise.patch is a reasonable trade off (perhaps not the one I would personally make, but I think it's reasonable). If we wish to ensure that Python interpreter start up never blocks on Linux without needing to supply any command line flags or environment variables, then I would strongly urge us to adopt his patch, but allow os.urandom to still block. In other words, please let's not let systemd's design weaken the security guarantees of os.urandom (generate cryptographically secure random bytes using the best tools provided by the platform). Let's make a targeted fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 06:36:51 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 08 Jun 2016 10:36:51 +0000 Subject: [issue20842] pkgutil docs should reference glossary terms not PEP 302 In-Reply-To: <1393846400.67.0.723549613222.issue20842@psf.upfronthosting.co.za> Message-ID: <1465382211.37.0.121424673574.issue20842@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- keywords: +easy versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 06:44:11 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 08 Jun 2016 10:44:11 +0000 Subject: [issue12962] TitledHelpFormatter and IndentedHelpFormatter are not documented In-Reply-To: <1315812430.81.0.82881222836.issue12962@psf.upfronthosting.co.za> Message-ID: <1465382651.59.0.828726033713.issue12962@psf.upfronthosting.co.za> Berker Peksag added the comment: optparse has been deprecated for years and I don't see any reason to document them now. Closing as rejected. ---------- assignee: -> docs at python components: +Documentation -Library (Lib) nosy: +berker.peksag, docs at python resolution: -> rejected stage: -> resolved status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 07:01:06 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 08 Jun 2016 11:01:06 +0000 Subject: [issue26437] asyncio create_server() not always accepts the 'port' parameter as str In-Reply-To: <1456408319.2.0.804697554696.issue26437@psf.upfronthosting.co.za> Message-ID: <1465383666.7.0.470378890066.issue26437@psf.upfronthosting.co.za> Berker Peksag added the comment: After changeset 3ec208c01418 this is no longer an issue: >>> from asyncio import * >>> loop = get_event_loop() >>> coro = loop.create_server(Protocol(), '', '12345') >>> loop.run_until_complete(coro) >> coro = loop.create_server(Protocol(), '127.0.0.1', '12345') >>> loop.run_until_complete(coro) Traceback (most recent call last): File "/home/berker/projects/cpython/default/Lib/asyncio/base_events.py", line 981, in create_server sock.bind(sa) OSError: [Errno 98] Address already in use During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 1, in File "/home/berker/projects/cpython/default/Lib/asyncio/base_events.py", line 404, in run_until_complete return future.result() File "/home/berker/projects/cpython/default/Lib/asyncio/futures.py", line 274, in result raise self._exception File "/home/berker/projects/cpython/default/Lib/asyncio/tasks.py", line 240, in _step result = coro.send(None) File "/home/berker/projects/cpython/default/Lib/asyncio/base_events.py", line 985, in create_server % (sa, err.strerror.lower())) OSError: [Errno 98] error while attempting to bind on address ('127.0.0.1', 12345): address already in use The traceback looks a bit noisy though. Perhaps it needs ``... from None`` or something like that. ---------- nosy: +berker.peksag resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 07:29:10 2016 From: report at bugs.python.org (Eryk Sun) Date: Wed, 08 Jun 2016 11:29:10 +0000 Subject: [issue27264] python 3.4 vs. 3.5 strftime same locale different output on Windows In-Reply-To: <1465363557.77.0.0608625622508.issue27264@psf.upfronthosting.co.za> Message-ID: <1465385350.13.0.0742701326824.issue27264@psf.upfronthosting.co.za> Eryk Sun added the comment: The universal CRT that's used by 3.5+ implements locales using Windows locale names [1], which were introduced in Vista. Examples for Spanish include 'es', 'es-ES', and 'es-ES_tradnl' . The latter is the traditional sort for Spain, which has the 3-letter abbreviations for the days of the week. The default for Spain is the modern sort, which uses 2-letter abbreviations. The old LCID system [2] defaults to the traditional sort (0x40A), to which the old CRT maps unqualified "spanish". The modern sort (0xC0A) is available as "spanish-modern" [3]. The universal CRT still honors "spanish-modern" [4], but just "spanish" by itself is mapped instead to neutral "es", which uses the modern sort. If you need to use the traditional form in both versions, then in 3.4 it's just "spanish", but 3.5+ requires a locale name with the sort suffix. I actually couldn't find a table on MSDN that listed the "tradnl" sort name to append to "es-ES", so I wrote a quick script to find it, assuming at least "tra" would be in the name: import re import ctypes kernel32 = ctypes.WinDLL('kernel32') LOCALE_ENUMPROCEX = ctypes.WINFUNCTYPE( ctypes.c_int, ctypes.c_wchar_p, ctypes.c_uint, ctypes.c_void_p) def find_locale(pattern): result = [] @LOCALE_ENUMPROCEX def cb(locale, flags, param): if re.match(pattern, locale, re.I): result.append(locale) return True kernel32.EnumSystemLocalesEx(cb, 0, None, None) result.sort() return result >>> find_locale('es-.*TRA.*') ['es-ES_tradnl'] >>> import locale, time >>> locale.setlocale(locale.LC_TIME, 'es-ES_tradnl') 'es-ES_tradnl' >>> time.strftime('%a') 'mi?' Note that abbreviations in Spanish generally end with a period. It's present for every country except Spain, such as Mexico: >>> locale.setlocale(locale.LC_TIME, 'spanish_mexico') 'Spanish_Mexico.1252' >>> time.strftime('%a') 'mi?.' or using the locale name (3.5+): >>> locale.setlocale(locale.LC_TIME, 'es-MX') 'es-MX' >>> time.strftime('%a') 'mi?.' Note that Python still doesn't support parsing locale names: >>> locale.getlocale(locale.LC_TIME) Traceback (most recent call last): File "", line 1, in File "C:\Program Files\Python35\lib\locale.py", line 578, in getlocale return _parse_localename(localename) File "C:\Program Files\Python35\lib\locale.py", line 487, in _parse_localename raise ValueError('unknown locale: %s' % localename) ValueError: unknown locale: es-MX Since locale names don't include the encoding, parsing them for getlocale() will require an additional call to get the locale's ANSI codepage, in case anyone wants to update the locale module to support this: >>> LOCALE_IDEFAULTANSICODEPAGE = 0x1004 >>> buf = (ctypes.c_wchar * 10)() >>> kernel32.GetLocaleInfoEx('es-MX', LOCALE_IDEFAULTANSICODEPAGE, buf, 10) 5 >>> buf.value '1252' If no one has additional concerns here, I'll close this issue as 3rd party in a day or so. Inconsistencies in the locale that "spanish" maps to in different versions of the CRT are completely Microsoft's problem. [1]: https://msdn.microsoft.com/en-us/library/dd373814 [2]: https://msdn.microsoft.com/en-us/library/dd318693 [3]: https://msdn.microsoft.com/en-us/library/39cwe7zf%28v=vs.100%29.aspx [4]: https://msdn.microsoft.com/en-us/library/39cwe7zf.aspx ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 07:34:42 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 08 Jun 2016 11:34:42 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1465381438.51.0.0280297469091.issue26839@psf.upfronthosting.co.za> Message-ID: <575802CA.7030207@egenix.com> Marc-Andre Lemburg added the comment: Even though it may sound like a minor problem that os.urandom() blocks on startup, I think the problem is getting more and more something to consider given how systems are used nowadays. Today, we no longer have the case where you keep a system up and running for multiple years as we had in the past. VM, containers and other virtualizations are spun up and down at a high rate, so the boot cycle becomes more and more important. FreeBSD, for example, is also concerned about the blocking issue they have in their implementation: https://wiki.freebsd.org/201308DevSummit/Security/DevRandom and they are trying to resolve this by making sure to add as much entropy they can find very early on in the process. Now, most applications you run early on in the boot process are not going to be applications that need crypto random numbers and this is where I think the problem originates. We've been telling everybody to use os.urandom() for seeding, and so everyone uses it, including many many applications that don't even require crypto random seeding. The random module is the perfect example. Essentially, we'd need to educate people that there's a difference in requesting crypto random data and pseudo random data. While we can fix the the cases in the stdlib and the interpreter that don't need crypto random data to use other means of seeding (e.g. reading straight from /dev/urandom on Linux or gathering other data to mix into a seed), existing applications out there will continue to use os.urandom() for things that don't need crypto random numbers - after all, we told them to use it. Some of these will eventually be hit by the blocking problem, even for applications such as Monte Carlo simulations that don't need crypto random and should thus not have to wait for some entropy pool to get initialized. Now, applications that do need crypto random data should be able to request this from Python via the stdlib and os.urandom() may sound like a good basis, but since this is designed as interface to /dev/urandom, it doesn't block on Linux, so not such a good choice. Using /dev/random probably doesn't work either, because this can block unexpected even after initialization. IMO, the best way forward and to educate application writers about the problems is to introduce a two new APIs in 3.6: os.cyptorandom() for getting OS crypto random data os.pseudorandom() for getting OS pseudo random data Crypto applications will then clearly know that os.cryptorandom() is the right choice for them and everyone else can use os.pseudorandom(). The APIs would on Linux and other platforms then use getrandom() with appropriate default settings, i.e. blocking or raising for os.cryptorandom() and non-blocking, non-raising for os.pseudorandom(). As for the solving the current issue, we will have to give people some way to get at non-blocking pseudo random data, if they need it early in the boot process. With the proposed change, this is still possible via reading /dev/urandom directly on Linux, so not everything is lost. BTW: Wikipedia has a good overview of how the different implementations of /dev/random work across platforms: https://en.wikipedia.org/wiki//dev/random ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 07:49:55 2016 From: report at bugs.python.org (Christian Heimes) Date: Wed, 08 Jun 2016 11:49:55 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465386595.91.0.653449445507.issue26839@psf.upfronthosting.co.za> Christian Heimes added the comment: I'm unsubscribing from this ticket for the second time. This form of discussion is becoming toxic for me because I strongly beliefe that it is not the correct way to handle a security-related problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 07:50:08 2016 From: report at bugs.python.org (Christian Heimes) Date: Wed, 08 Jun 2016 11:50:08 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465386608.28.0.832013197323.issue26839@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: -christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 07:57:40 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 Jun 2016 11:57:40 +0000 Subject: [issue21593] Clarify re.search documentation first match In-Reply-To: <1401287966.38.0.860641123785.issue21593@psf.upfronthosting.co.za> Message-ID: <20160608115731.19119.71437.7F4D61CB@psf.io> Roundup Robot added the comment: New changeset 48bb48e7499d by Berker Peksag in branch '3.5': Issue #21593: Clarify that re.search() returns the first match https://hg.python.org/cpython/rev/48bb48e7499d New changeset 243b95782059 by Berker Peksag in branch 'default': Issue #21593: Merge from 3.5 https://hg.python.org/cpython/rev/243b95782059 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 07:58:29 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 08 Jun 2016 11:58:29 +0000 Subject: [issue21593] Clarify re.search documentation first match In-Reply-To: <1401287966.38.0.860641123785.issue21593@psf.upfronthosting.co.za> Message-ID: <1465387109.55.0.0682936361936.issue21593@psf.upfronthosting.co.za> Berker Peksag added the comment: > This should also be applied to regex.search's docstring. Done. ---------- nosy: +berker.peksag resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 08:00:01 2016 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 08 Jun 2016 12:00:01 +0000 Subject: [issue27265] Hash of different, specific Decimals created from str is the same In-Reply-To: <1465373061.21.0.960848543198.issue27265@psf.upfronthosting.co.za> Message-ID: <1465387201.19.0.421153776662.issue27265@psf.upfronthosting.co.za> Mark Dickinson added the comment: There's nothing wrong with two different Decimal objects having the same hash (indeed, it's inevitable, given that there are fewer than 2**64 hash values available, and many more possible Decimal objects). It only becomes a problem if you have a largish naturally-occurring dataset whose values all end up falling into the same hash bucket, resulting in linear-time dict operations instead of constant time. I don't think that's the case here: each example of this form only has two different values with the same hash. @Rados?aw Szalski: is this causing problems in a real application? If not, I think it should be closed as "won't fix". Note that Python 3 is not subject to this issue: it uses a different hashing technique (as described in the issue 8188 that you already linked to). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 08:06:39 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 08 Jun 2016 12:06:39 +0000 Subject: [issue26985] Information about CodeType in inspect documentation is outdated In-Reply-To: <1462803102.24.0.542356144335.issue26985@psf.upfronthosting.co.za> Message-ID: <1465387599.33.0.983872292755.issue26985@psf.upfronthosting.co.za> Berker Peksag added the comment: I prefer to not duplicate the list in Lib/inspect.py. We did similar docstring cleanups in several modules (venv for example) recently. ---------- nosy: +berker.peksag stage: -> patch review type: -> behavior versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 08:16:20 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 08 Jun 2016 12:16:20 +0000 Subject: [issue21313] Py_GetVersion() is broken when using mqueue and a long patch name In-Reply-To: <1397945838.86.0.227153547567.issue21313@psf.upfronthosting.co.za> Message-ID: <1465388180.57.0.333727610496.issue21313@psf.upfronthosting.co.za> Martin Panter added the comment: Closing now that platform._sys_version() can tolerate the truncated version info. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 08:16:58 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 08 Jun 2016 12:16:58 +0000 Subject: [issue25738] http.server doesn't handle RESET CONTENT status correctly In-Reply-To: <1448583978.87.0.253695569638.issue25738@psf.upfronthosting.co.za> Message-ID: <1465388218.85.0.830277654305.issue25738@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 08:56:12 2016 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 08 Jun 2016 12:56:12 +0000 Subject: [issue27265] Hash of different, specific Decimals created from str is the same In-Reply-To: <1465373061.21.0.960848543198.issue27265@psf.upfronthosting.co.za> Message-ID: <1465390572.05.0.390222585993.issue27265@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- resolution: -> wont fix status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 08:59:56 2016 From: report at bugs.python.org (Emanuel Barry) Date: Wed, 08 Jun 2016 12:59:56 +0000 Subject: [issue27242] Make the docs for NotImplemented & NotImplementedError unambigous In-Reply-To: <1465239567.69.0.773832868585.issue27242@psf.upfronthosting.co.za> Message-ID: <1465390796.76.0.181667824027.issue27242@psf.upfronthosting.co.za> Emanuel Barry added the comment: Martin: yes, I plan to install Sphinx soon enough, so that I can build the docs. As for the notes part, I indented it exactly like it was indented for other existing notes boxes in the same file. I'll change that if needed though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 09:01:43 2016 From: report at bugs.python.org (Tommy Beadle) Date: Wed, 08 Jun 2016 13:01:43 +0000 Subject: [issue24617] os.makedirs()'s [mode] not correct In-Reply-To: <1436721223.66.0.229120395272.issue24617@psf.upfronthosting.co.za> Message-ID: <1465390903.64.0.668921924026.issue24617@psf.upfronthosting.co.za> Changes by Tommy Beadle : Added file: http://bugs.python.org/file43305/0001-Issue-24617-Add-comment-for-os.makedirs-about-certai.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 09:13:46 2016 From: report at bugs.python.org (Stephen J. Turnbull) Date: Wed, 08 Jun 2016 13:13:46 +0000 Subject: [issue27257] get_addresses results in traceback with a valid? header In-Reply-To: <1465327493.81.0.354921385455.issue27257@psf.upfronthosting.co.za> Message-ID: <1465391626.12.0.88339611564.issue27257@psf.upfronthosting.co.za> Stephen J. Turnbull added the comment: In Python 3.5, both entering the problematic header by hand with a trivial body and using email.message_from_string to parse it, and calling email.message_from_file on lkml-exception.mail, produce an email.message.Message with no defects and no traceback. Without access to mail_filter.py, it's not clear what the defect might be. ---------- nosy: +sjt stage: -> test needed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 09:24:05 2016 From: report at bugs.python.org (Evelyn Mitchell) Date: Wed, 08 Jun 2016 13:24:05 +0000 Subject: [issue8491] Need readline command and keybinding information In-Reply-To: <1271879913.89.0.268262009322.issue8491@psf.upfronthosting.co.za> Message-ID: <1465392245.18.0.295894786084.issue8491@psf.upfronthosting.co.za> Evelyn Mitchell added the comment: Revised patch following Martin Panter's review comments. ---------- nosy: +Evelyn Mitchell Added file: http://bugs.python.org/file43306/patch8491a _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 09:35:53 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jun 2016 13:35:53 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465392953.54.0.834649551229.issue26839@psf.upfronthosting.co.za> STINNER Victor added the comment: Donald: "Cory wasn't speaking about (non)blocking in general, but the case where (apparently) it's desired to not block even if that means you don't get cryptographically secure random in the CPython interpreter start up. (...)" Oh sorry, I misunderstood his message. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 09:36:22 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 Jun 2016 13:36:22 +0000 Subject: [issue23275] Can assign [] = (), but not () = [] In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za> Message-ID: <20160608133613.38459.3921.1D6282D3@psf.io> Roundup Robot added the comment: New changeset 39a72018dd76 by Martin Panter in branch '3.5': Issue #23275: Backport target list assignment documentation fixes https://hg.python.org/cpython/rev/39a72018dd76 New changeset 8700f4d09b28 by Martin Panter in branch '2.7': Issue #23275: Backport empty square bracket assignment documentation fix https://hg.python.org/cpython/rev/8700f4d09b28 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 09:41:11 2016 From: report at bugs.python.org (Justus Winter) Date: Wed, 08 Jun 2016 13:41:11 +0000 Subject: [issue27261] io.BytesIO.truncate does not work as advertised In-Reply-To: <1465332777.38.0.718878645897.issue27261@psf.upfronthosting.co.za> Message-ID: <1465393271.75.0.35446884041.issue27261@psf.upfronthosting.co.za> Justus Winter added the comment: FWIW, I consider the documented behavior a feature. My use case is to allocate a BytesIO object with a given size, obtain a view to its buffer, and write to it from a c library. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 09:41:52 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jun 2016 13:41:52 +0000 Subject: [issue24617] os.makedirs()'s [mode] not correct In-Reply-To: <1436721223.66.0.229120395272.issue24617@psf.upfronthosting.co.za> Message-ID: <1465393312.34.0.134127642637.issue24617@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issue19930. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 09:44:38 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jun 2016 13:44:38 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465393478.41.0.0594332305478.issue26839@psf.upfronthosting.co.za> STINNER Victor added the comment: Cory Benfield (msg267637): "if the purpose of this patch was to prevent long startup delays, *it failed*. On all the systems above os.urandom may continue to block system startup." I don't pretend fixing the issue on all operating systems. As stated in the issue title, this issue is specific to Linux. I understand that the bug still exists on other platforms and is likely to require a specific fix for each platform. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 09:44:51 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 08 Jun 2016 13:44:51 +0000 Subject: [issue27242] Make the docs for NotImplemented & NotImplementedError unambigous In-Reply-To: <1465239567.69.0.773832868585.issue27242@psf.upfronthosting.co.za> Message-ID: <1465393491.79.0.643318798285.issue27242@psf.upfronthosting.co.za> Martin Panter added the comment: I think the box about NotImplementedError needs indenting too. See the box for for a better example. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 09:49:55 2016 From: report at bugs.python.org (Tommy Beadle) Date: Wed, 08 Jun 2016 13:49:55 +0000 Subject: [issue24617] os.makedirs()'s [mode] not correct In-Reply-To: <1436721223.66.0.229120395272.issue24617@psf.upfronthosting.co.za> Message-ID: <1465393795.66.0.309506684015.issue24617@psf.upfronthosting.co.za> Tommy Beadle added the comment: I think that the documentation should be updated to reflect issue19930's change when that is actually committed, not as a part of this change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 09:58:17 2016 From: report at bugs.python.org (Theodore Tso) Date: Wed, 08 Jun 2016 13:58:17 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465394297.42.0.0160786399233.issue26839@psf.upfronthosting.co.za> Theodore Tso added the comment: One of the reasons why trying to deal with randomness is hard is because a lot of it is about trust. Did Intel backdoor RDRAND to help out the NSA? You might have one answer if you work for the NSA, and perhaps if you are willing to assume the worst about the NSA balancing its equities between its signals intelligence mission and providing a secure infrastructure for its customers and keeping the US computing industry strong. Etc., etc. It is true that OS developers are trying to make their random number generators be initialized more quickly at boot time. Part of this is because of the dynamic which we can all see at work on the discussion of this bug. Some people care about very much about not blocking; some people want Python to be useful during the boot sequences; some people care very much about security above all else; some people don't trust application programmers. (And if you fit in that camp; congratulations, now you know how I often feel when I worry about user space programmers doing potentially crazy things and I have no way of even knowing about them until the security researchers publish a web site such as http://www.factorable.net) >From the OS's perspective, one of the problems is that it's very hard to know when you have actually achieved a securely initialized random number generator. Sure, we can say we've done this once we have accumulated at least 128 bits of entropy, but that begs the question of when you've collected a bit of entropy. There's no way to know for sure. On current systems, we assume that each interrupt gathers 1/64th of a bit of entropy on average. This is an incredibly conservative number, and on real hardware, assuming the normal bootup activity, we achieve that within about 5 seconds (plus/minus 2 seconds) after boot. On Intel, on real hardware, I'm comfortable cutting this to 1 bit of entropy per interrupt, which will speed up things considerably. In an ARM SOC, or if you are on a VM and you don't trust the hypervisor so you don't use virtio-rng, is one bit of entropy per interrupt going to be good enough? It's hard to say. On the other hand, if we use too conservative a number, there is a risk that userspace programmers (such as some have advocated on the discussionon this bug) to simply always use GRND_NONBLOCK, or fall back to /dev/urandom, and then if there's a security exposure, they'll cast the blame on the OS developers. The reality is that we really need to work together, because the real problem are the clueless people writing python scripts at boot time to create long-term RSA private keys for IOT devices[1]. :-) So when people assert that developers at FreeBSD are at work trying to speedup /dev/random initialization, folks need to understand that there's no magic here. What's really happening is that we're all trying to figure out which defaults work the best. In some ways the FreeBSD folks have it easier, because they support a much fewer range of platforms. It's a lot easier to get things right on x86, where we have instructions like RDTSC and RDRAND to help us out. It's a lot harder to be sure you have things right for ARM SOC's. There are other techniques such as trying to carry entropy over from previous boot sessions, but (a) this requires support from the boot loaders, and on an OS with a large number of architectures, that means adding support to a large number of different ways of booting the kernel --- and it doesn't solve the "consumer device generating keys after a cold start when the device is freshly removed from the packaging". As far as adding knobs, such as "blocking vs non-blocking", etc., keep in mind that as you add knobs, you increase the knowledge of the system that you force onto the next layer of the stack. So this goes to the question of whether you trust application programmers will be able to get things right. So Ted, why does Linux expose /dev/random vs /dev/urandom? Historical reasons; some people don't believe that relying on cryptogaphic random number generators is sufficient, they *want* to use entropy which has minimal reliance on the belief that NSA ***probably*** didn't leave a back door into SHA-1, for example. It is for that reason that /dev/random exists. These days, the number of people who believe that to be true are very small, but I didn't want to make changes in existing interfaces. For similar reasons I didn't want to suddenly make /dev/urandom block. The fact that getrandom(2) blocks only until the cryptographic RNG has been initialized, and that it depends on a cryptogaphic RNG, is the consensus that *most* people have come to, and it reflects my recommendations that unless you ***really*** know what you are doing, the right thing to do is to call getrandom(2) with the flags field set to zero, and to be happy. Of course, many people are sure they know what they need to do than there are people who really *do* know what they are doing, which is why in BSD, they simply don't give people a choice with their getentropy(2) system call. If you assume that application/user-space programmers should never be trusted, and API's should come with a strong point of view, that's a reasonable design choice. At some level this is the same choice which is before the Python developer community. I'm not going to presume to tell you what the right thing to do is here, because it's filled with engineering and design tradeoffs. Hopefully this additional perspective is useful, though. [1] This is a joke, folks. We need to all work together, even the application programmers. Some may say that means we're doomed from a security perspective, but security really has to be a collective responsibility if we don't want our "home of the future" to be completely pwned by the bad guys..... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 10:04:56 2016 From: report at bugs.python.org (Stephen J. Turnbull) Date: Wed, 08 Jun 2016 14:04:56 +0000 Subject: [issue27257] get_addresses results in traceback with a valid? header In-Reply-To: <1465327493.81.0.354921385455.issue27257@psf.upfronthosting.co.za> Message-ID: <1465394696.97.0.221090460463.issue27257@psf.upfronthosting.co.za> Stephen J. Turnbull added the comment: OK, I can reproduce now. $ python3.5 Python 3.5.0 (v3.5.0:374f501f4567, Sep 17 2015, 17:04:56) [GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import email >>> with open(b'lkml-exception.mail', mode = 'r') as f: ... msg = email.message_from_file(f, policy=email.policy.SMTP) ... >>> msg.get_all('to') Traceback (most recent call last): and (except for a slight skew in line-numbering) the rest is the same as the tail of the OP. The crucial part is the policy=email.policy.SMTP argument, and evidently what's happening is that the parser assumes that the local-part of the addr-spec is non-empty. RFC5322 does permit a quoted-string to be empty, so this is a bug in the email module's parser. (I don't have a patch,sorry.) Aside: although strictly speaking it's hold-your-nose-and-avert-your-eyes legal according to RFC 5322, RFC 5321 (SMTP) does say: While the above definition for Local-part is relatively permissive, for maximum interoperability, a host that expects to receive mail SHOULD avoid defining mailboxes where the Local-part requires (or uses) the Quoted-string form[...]. I don't see a good reason for the usage in the test case, so I'd call this nonconformant to RFC 5321. I think the right way to handle it is to register a defect but let the parse succeed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 10:21:34 2016 From: report at bugs.python.org (Theodore Tso) Date: Wed, 08 Jun 2016 14:21:34 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465395694.08.0.896463616519.issue26839@psf.upfronthosting.co.za> Theodore Tso added the comment: Oh --- and about people wondering whether os.random is being used for cryptographic purposes or not "most of the time" or not --- again, welcome to my world. I get complaints all the time from people who try to do "dd if=/dev/urandom of=/dev/hdX bs=4k" and then complain this is too slow. Creating an os.cryptorandom and os.pseudorandom might be a useful way to go here. I've often considered whether I should create a /dev/frandom for the crazies who want to use dd as a way to wipe a disk, but to date I've haven't thought it was worth the effort, and I didn't want to encourage them. Besides, isn't obviously the right answer is to create a quickie python script? :-) Splitting os.random does beg the question of what os.random should do, however. If you go down that path, I'd suggest defaulting to the secure-but-slow choice. I'd also suggest assuming it's OK to put the onus on the people who are trying to run python scripts during early boot to have to either add some command flags to the python interpreter, or to otherwise make adjustments, as being completely fair. But again, that's my bias, and if people don't want to deal with trying to ask the systemd folks to make a change in their code, I'd _completely_ understand. My design preference is that outside of boot scripts, having os.random block in the same of security is completely fair, since in that case you won't deadlock the system. People of good will may disagree, of course, and I'm not on the Python development team, so take that with whatever grain of salt you wish. At the end of the day, this is all about tradeoffs, and you know your customer/developer base better than I do.\ Cheers! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 10:27:06 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jun 2016 14:27:06 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465396026.32.0.699273643931.issue26839@psf.upfronthosting.co.za> STINNER Victor added the comment: >> The current behavior is that Python *will not start at all* if getrandom() blocks (because the hash secret initialization fails). > It starts jsut fine, it just can possible takes awhile. In my experience, connecting to a VM using SSH with low entropy can take longer than 1 minute. As an user, I considered that the host was down. Longer than 1 minute is simply too long. It's unclear to me if getrandom() can succeed (return random bytes) on embedded devices without hardware RNG. Can it take longer than 1 minute? Is it possible that getrandom() simply blocks forever? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 10:30:46 2016 From: report at bugs.python.org (Colm Buckley) Date: Wed, 08 Jun 2016 14:30:46 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465396246.23.0.934800432988.issue26839@psf.upfronthosting.co.za> Colm Buckley added the comment: Victor - Yes, it is possible for it to block forever - see the test I proposed for Ted upthread. The triggering case (systemd-crontab-generator) delays for 90 seconds, but is *killed* by systemd after that time; it doesn't itself time out. Colm ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 10:34:24 2016 From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=) Date: Wed, 08 Jun 2016 14:34:24 +0000 Subject: [issue27268] Incorrect error message on float('') Message-ID: <1465396464.66.0.148764915141.issue27268@psf.upfronthosting.co.za> New submission from Adam Barto?: >>> float('foo') ValueError: could not convert string to float: 'foo' >>> float('') ValueError: could not convert string to float: should be ValueError: could not convert string to float: '' The message comes from Objects/floatobject.c:183 but I don't understand how the empty string gets discarded. ---------- components: Interpreter Core messages: 267858 nosy: Drekin priority: normal severity: normal status: open title: Incorrect error message on float('') type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 10:34:38 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 08 Jun 2016 14:34:38 +0000 Subject: [issue27187] Relax __all__ location requirement in PEP 8 In-Reply-To: <1464901602.05.0.802918160149.issue27187@psf.upfronthosting.co.za> Message-ID: <1465396478.67.0.627347107686.issue27187@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Thanks Ian. I'm going to apply that, but rephrase it a bit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 10:45:49 2016 From: report at bugs.python.org (Emin Ghuliev) Date: Wed, 08 Jun 2016 14:45:49 +0000 Subject: [issue27254] heap overflow in Tkinter module In-Reply-To: <1465324141.01.0.361051063774.issue27254@psf.upfronthosting.co.za> Message-ID: <1465397149.88.0.0621141910287.issue27254@psf.upfronthosting.co.za> Emin Ghuliev added the comment: psuedocode <+16>: movsxd rdx,DWORD PTR [rbx+0x8] <+20>: lea eax,[rdx+rbp*1] newSize = length ($rdx) + dsPtr->length ($rbp) gdb > print /x $rbp $5 = 0xfffff gdb > print /x $rdx $6 = 0x100000 newsize = 0xfffff+0x100000 = 0x1fffff cmp eax,DWORD PTR [rbx+0xc] ? $pc jl 0x7ffff6194e38 newSize ($eax) >= dsPtr->spaceAvl gdb > print /x $eax $7 = 0x1fffff gdb > x/x $rbx+0xc 0x7fffffffd0cc: 0x001ffffe condition: 0x1fffff >= 0x001ffffe = True if (newSize >= dsPtr->spaceAvl) { lea esi,[rax+rax*1] ; magic compiler optimization :) (newSize(0x1fffff)*2) /* */ dsPtr->spaceAvl = newSize * 2; gdb > print /x $rax $4 = 0x1fffff $esi = 0x1fffff+0x1fffff (newSize(0x1fffff)*2) = 0x3ffffe /* */ => <+34>: lea rax,[rbx+0x10] <+38>: mov DWORD PTR [rbx+0xc],esi <+41>: cmp rdi,rax ; $rax = dsPtr->staticSpace and $rdi = dsPtr->string <+44>: je 0x7ffff6194e50 condition : dsPtr->string == dsPtr->staticSpace = False then jump to ' call 0x7ffff60c2040 ' if (dsPtr->string == dsPtr->staticSpace) { char *newString = ckalloc(dsPtr->spaceAvl); memcpy(newString, dsPtr->string, (size_t) dsPtr->length); dsPtr->string = newString; } else { call 0x7ffff60c2040 $rsi = 0x3ffffe $rdi = 0x7ffff333e020 dsPtr->string = ckrealloc(dsPtr->string = 0x7ffff333e020, dsPtr->spaceAvl = 0x3ffffe); } } disassemble: lea rdi,[rax+rdx*1] ; dsPtr->string + dsPtr->length mov rsi,r12 ; bytes movsxd rdx,ebp ; length call 0x7ffff60a25c0 memcpy(dsPtr->string + dsPtr->length, bytes, length); ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 10:55:23 2016 From: report at bugs.python.org (ThiefMaster) Date: Wed, 08 Jun 2016 14:55:23 +0000 Subject: [issue27269] ipaddress: Wrong behavior with ::ffff:1.2.3.4 style IPs Message-ID: <1465397723.89.0.175384049159.issue27269@psf.upfronthosting.co.za> New submission from ThiefMaster: I'd expect the IPv4 address to be considered part of that network (or actually parsed as an IPv4Address and not IPv6Address) even if it's written in IPv6 notation. It's an IPv4 after all. Python 3.5.1 (default, Jun 7 2016, 09:20:44) [GCC 4.9.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import ipaddress >>> ipaddress.ip_address('::ffff:127.0.0.1') IPv6Address('::ffff:7f00:1') >>> ipaddress.ip_address('::ffff:127.0.0.1') in ipaddress.ip_network('127.0.0.0/8') False >>> ipaddress.ip_address('127.0.0.1') in ipaddress.ip_network('127.0.0.0/8') True ---------- components: Library (Lib) messages: 267861 nosy: ThiefMaster priority: normal severity: normal status: open title: ipaddress: Wrong behavior with ::ffff:1.2.3.4 style IPs type: behavior versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 11:04:31 2016 From: report at bugs.python.org (SilentGhost) Date: Wed, 08 Jun 2016 15:04:31 +0000 Subject: [issue27269] ipaddress: Wrong behavior with ::ffff:1.2.3.4 style IPs In-Reply-To: <1465397723.89.0.175384049159.issue27269@psf.upfronthosting.co.za> Message-ID: <1465398271.51.0.733474511324.issue27269@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +pmoody versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 11:12:20 2016 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 08 Jun 2016 15:12:20 +0000 Subject: [issue27265] Hash of different, specific Decimals created from str is the same In-Reply-To: <1465373061.21.0.960848543198.issue27265@psf.upfronthosting.co.za> Message-ID: <1465398740.57.0.45434441867.issue27265@psf.upfronthosting.co.za> Mark Dickinson added the comment: For what it's worth, here are timings on my machine showing the overhead of the extra equality check when a hash collision occurs. Python 2.7.11 (default, Mar 1 2016, 18:08:21) Type "copyright", "credits" or "license" for more information. IPython 4.2.0 -- An enhanced Interactive Python. ? -> Introduction and overview of IPython's features. %quickref -> Quick reference. help -> Python's own help system. object? -> Details about 'object', use 'object??' for extra details. In [1]: from decimal import Decimal In [2]: set1 = set([Decimal(str(n/1000.0)) for n in range(1, 10)] + [Decimal(str(n/100.0)) for n in range(1, 10)]) In [3]: set2 = set([Decimal(str(n/1000.0)) for n in range(2, 20)]) In [4]: print len(set1), len(set2) # Both sets have the same length 18 18 In [5]: print len(set(map(hash, set1))), len(set(map(hash, set2))) # But set1 has hash collisions 9 18 In [6]: %timeit Decimal('0.005') in set1 # checking elt in the set, first match is the right one The slowest run took 5.98 times longer than the fastest. This could mean that an intermediate result is being cached. 100000 loops, best of 3: 17.4 ?s per loop In [7]: %timeit Decimal('0.05') in set1 # checking elt in the set, collision resolution needed The slowest run took 5.72 times longer than the fastest. This could mean that an intermediate result is being cached. 100000 loops, best of 3: 19.6 ?s per loop In [8]: %timeit Decimal('0.005') in set2 # should be similar to the first set1 result The slowest run took 5.99 times longer than the fastest. This could mean that an intermediate result is being cached. 100000 loops, best of 3: 17.3 ?s per loop ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 11:12:31 2016 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 08 Jun 2016 15:12:31 +0000 Subject: [issue27265] Hash of different, specific Decimals created from str is the same In-Reply-To: <1465373061.21.0.960848543198.issue27265@psf.upfronthosting.co.za> Message-ID: <1465398751.29.0.0743991097597.issue27265@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 11:22:20 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 08 Jun 2016 15:22:20 +0000 Subject: [issue7063] Memory errors in array.array In-Reply-To: <1254730349.27.0.71088310024.issue7063@psf.upfronthosting.co.za> Message-ID: <1465399340.72.0.397589074883.issue7063@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: needs patch -> patch review versions: +Python 3.6 -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 11:23:32 2016 From: report at bugs.python.org (Colm Buckley) Date: Wed, 08 Jun 2016 15:23:32 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465399412.1.0.75584083191.issue26839@psf.upfronthosting.co.za> Colm Buckley added the comment: Just to re-state; I think we have three problems: 1) _Py_HashSecret initialization blocking. Affects all Python invocations; already a substantial issue on Debian testing track (90s startup delay). * there seems to be general agreement that this does not need a 'strong' secret in a script called at/near startup. * On Linux, getrandom(GRND_NONBLOCK) *or* /dev/urandom are sufficient for this initialization. * On other OS, we don't have a non-blocking kernel PRNG; this is probably not an issue for Solaris or OS X, and only a possible issue for OpenBSD. * Is it acceptable to fall back to an in-process seed generation for the cases where initialization via /dev/urandom fails (NB : there have been no reports of this type of failure in the wild). * existing tip with or without nonblocking_urandom_noraise.patch addresses this for Linux. Solution for other OS remains to be written. * Possibly can be considered non-blocking for other OS, as there has been no recent regression in behavior. 2) Blocking on 'import random' and/or os.urandom. I don't see a clear consensus on the Right Thing for this case. Existing tip (without nonblocking_urandom_noraise.patch) addresses it for Linux, but solution is not universally accepted. Unclear whether this is a 3.5.2 blocker. 3) Design of future APIs for >= 3.6. The most frequent suggestion is something like os.pseudorandom() (guaranteed nonblocking) and os.cryptorandom() (guaranteed entropy); I guess this needs to go to the dev list for full discussion - is it safely out of scope for this bug? My suggestion (for what it's worth): accept Victor's changeset plus nonblocking_urandom_noraise for 3.5.2 (I'll submit a proper patch shortly), recommend userspace workarounds for the blocking urandom issue, propose new APIs for 3.6 on the dev list. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 11:26:24 2016 From: report at bugs.python.org (Eryk Sun) Date: Wed, 08 Jun 2016 15:26:24 +0000 Subject: [issue27268] Incorrect error message on float('') In-Reply-To: <1465396464.66.0.148764915141.issue27268@psf.upfronthosting.co.za> Message-ID: <1465399584.91.0.908124373813.issue27268@psf.upfronthosting.co.za> Eryk Sun added the comment: > The message comes from Objects/floatobject.c:183 No, in this case the error is set in PyOS_string_to_double in Python/pystrtod.c, because `fail_pos == s`, and it doesn't get replaced in PyFloat_FromString because `end == last`. The format string in PyOS_string_to_double should probably be "'%.200s'". ---------- nosy: +eryksun versions: +Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 11:35:50 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 08 Jun 2016 15:35:50 +0000 Subject: [issue27243] __aiter__ should return async iterator instead of awaitable In-Reply-To: <1465240896.52.0.994549894653.issue27243@psf.upfronthosting.co.za> Message-ID: <1465400150.58.0.802649387173.issue27243@psf.upfronthosting.co.za> Yury Selivanov added the comment: Nick, Please see the updated patch. Do you think it's ready to be merged? I want buildbots to have some time with it before RC. ---------- Added file: http://bugs.python.org/file43307/fix_aiter3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 11:57:08 2016 From: report at bugs.python.org (Akira Li) Date: Wed, 08 Jun 2016 15:57:08 +0000 Subject: [issue27050] Demote run() below the high level APIs in subprocess docs In-Reply-To: <1463548305.72.0.232219818049.issue27050@psf.upfronthosting.co.za> Message-ID: <1465401428.22.0.471604217529.issue27050@psf.upfronthosting.co.za> Akira Li added the comment: > setting "universal_newlines=True" switches to UTF-8 encoded text pipes It uses locale.getpreferredencoding(False) encoding -- something like cp1252,cp1251,etc on Windows, and UTF-8 on *nix with proper locale settings. It is ASCII (C/POSIX locale default) if the locale is not set in cron, ssh, init.d scripts, etc. If you need a different character encoding, you could use (instead of universal_newlines=True): pipe = io.TextIOWrapper(process.stdout, encoding=character_encoding) A better spelling for universal_newlines=True would be text_mode=True. A summary table (like in itertools' module) would be nice. check_output() name is unfortunate but it does the right thing and it is not hard to use for a beginner -- once somebody discovers it e.g., via "Running shell command from Python and capturing the output" Stack Overflow question http://stackoverflow.com/questions/4760215/running-shell-command-from-python-and-capturing-the-output Compare: output = check_output([sys.executable, '-c', 'print("abc")']) and output = run([sys.executable, '-c', 'print("abc)'], stdout=PIPE).stdout The latter command doesn't raise exception if the child process fails. A beginner has to know about check=True to do the right thing: output = run([sys.executable, '-c', 'print("abc")'], stdout=PIPE, check=True).stdout It is easier to refer to check_output() if someone asks "How do I get command's output in Python?" I wish call() did what check_call() does and the current call() behavior would be achieved by the opposite parameter e.g. no_raise_on_status=False being the default: rc = call(command, no_raise_on_status=True) If we can't change the interface then check_call() is the answer to "Calling an external command in Python" question http://stackoverflow.com/questions/89228/calling-an-external-command-in-python - check_call(command) -- run command, raise if it fails - output = check_output(command) -- get command's output, raise if it fails. To pass *data* to the command via its standard input, pass input=data. To get/pass text (Unicode) instead of bytes, pass universal_newlines=True - check_call("a -- *.jpg | b 2>&1 >output | c", shell=True) -- run a shell command as is It is a pity that a list argument such as ["ls", "-l"] is allowed with shell=True These cover the most common operations with a subprocess. Henceforth, run() is more convenient if we don't need to interact with the child process while it is running. For example, if we introduce the word PIPE (a magic object in the kernel that connects processes) then to capture both standard and error streams of the command: cp = run(command, stdout=PIPE, stderr=PIPE) output, errors = cp.stdout, cp.stderr run() allows to get the output and to get the exit status easily: cp.returncode. Explicit cp.stdout_text, cp.stdout_bytes regardless the text mode would be nice. To interact with a child process while it is running, Popen() have to be used directly. There could be buffering and other issues (tty vs. pipe), see "Q: Why not just use a pipe (popen())?" http://pexpect.readthedocs.io/en/latest/FAQ.html#whynotpipe Working with both stdout/stderr or a non-blocking read require threads or asyncio, fcntl, etc. A couple of words should be said about killing a command started with shell=True. (to kill a process tree: set start_new_session=True parameter and call os.killpg()). timeout option doesn't work in this case (it uses Popen.kill()). check_output() unlike check_call() may wait for grandchildren if they inherit the pipe. Mention Job object on Windows e.g., http://stackoverflow.com/questions/23434842/python-how-to-kill-child-processes-when-parent-dies ---------- nosy: +akira _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 11:59:56 2016 From: report at bugs.python.org (Demur Rumed) Date: Wed, 08 Jun 2016 15:59:56 +0000 Subject: [issue27127] Never have GET_ITER not followed by FOR_ITER In-Reply-To: <1464227064.89.0.81963094053.issue27127@psf.upfronthosting.co.za> Message-ID: <1465401596.42.0.106048812062.issue27127@psf.upfronthosting.co.za> Changes by Demur Rumed : ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 12:18:34 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jun 2016 16:18:34 +0000 Subject: [issue27266] Add block keyword-only optional parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465402714.84.0.415130887.issue27266@psf.upfronthosting.co.za> STINNER Victor added the comment: Ah, there is maybe a solution for BSD? msg267810: "it looks like we can use sysctl to fetch the seed state from kern.random.sys.seeded" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 12:23:19 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jun 2016 16:23:19 +0000 Subject: [issue27266] Always use getrandom() in os.random() and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465402999.65.0.588981190433.issue27266@psf.upfronthosting.co.za> STINNER Victor added the comment: I changed the title to make my intent more explicit: the goal is to make os.urandom() more secure on Linux by always using getrandom(). But always using getrandom() in os.urandom() requires a non-blocking os.urandom() to start Python: see #25420 (import random) and #26839 (hash secret) for practical issues. I removed Python 3.5 from versions since Larry explicitly asked to not add a new parameter to os.urandom() in Python 3.5: msg267721. ---------- title: Add block keyword-only optional parameter to os.urandom() -> Always use getrandom() in os.random() and add block=False parameter to os.urandom() type: -> enhancement versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 12:24:19 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jun 2016 16:24:19 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465403059.13.0.859904572046.issue27266@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: Always use getrandom() in os.random() and add block=False parameter to os.urandom() -> Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 12:35:03 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 Jun 2016 16:35:03 +0000 Subject: [issue27136] sock_connect fails for bluetooth (and probably others) In-Reply-To: <1464346938.98.0.196127839357.issue27136@psf.upfronthosting.co.za> Message-ID: <20160608163403.19170.39642.0C3D2D6C@psf.io> Roundup Robot added the comment: New changeset 3f49e89be8a9 by Yury Selivanov in branch '3.5': Issue #27136: Fix DNS static resolution; don't use it in getaddrinfo https://hg.python.org/cpython/rev/3f49e89be8a9 New changeset e46b23b6a068 by Yury Selivanov in branch 'default': Merge 3.5 (issue #27136, asyncio) https://hg.python.org/cpython/rev/e46b23b6a068 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 12:35:43 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 08 Jun 2016 16:35:43 +0000 Subject: [issue27136] sock_connect fails for bluetooth (and probably others) In-Reply-To: <1464346938.98.0.196127839357.issue27136@psf.upfronthosting.co.za> Message-ID: <1465403743.98.0.44279866223.issue27136@psf.upfronthosting.co.za> Yury Selivanov added the comment: Will be fixed in CPython 3.5.2. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 12:48:50 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 Jun 2016 16:48:50 +0000 Subject: [issue27136] sock_connect fails for bluetooth (and probably others) In-Reply-To: <1464346938.98.0.196127839357.issue27136@psf.upfronthosting.co.za> Message-ID: <20160608164839.33062.76253.4B1954CC@psf.io> Roundup Robot added the comment: New changeset 149fbdbe4729 by Yury Selivanov in branch '3.5': Issue #27136: Update asyncio docs https://hg.python.org/cpython/rev/149fbdbe4729 New changeset 44767f603535 by Yury Selivanov in branch 'default': Merge 3.5 (asyncio, issue #27136) https://hg.python.org/cpython/rev/44767f603535 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 12:49:13 2016 From: report at bugs.python.org (Brett Cannon) Date: Wed, 08 Jun 2016 16:49:13 +0000 Subject: [issue26446] Mention in the devguide that core dev stuff falls under the PSF CoC In-Reply-To: <1456514667.83.0.674412678031.issue26446@psf.upfronthosting.co.za> Message-ID: <1465404553.73.0.2901894403.issue26446@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks for the patch, Evelyn! The latest one LGTM and I will commit it when I have time. I do still plan to add a subsection at the bottom of the index page mentioning the CoC so it's in a very visible location. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 12:52:10 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jun 2016 16:52:10 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465404730.9.0.678436569516.issue26839@psf.upfronthosting.co.za> STINNER Victor added the comment: I spent almost my whole day to read this issue, some related issues, and some more related links. WOW! Amazing discussing. Sorry that Christian decided to quit the discussion (twice) :-( Here is my summary: http://haypo-notes.readthedocs.io/pep_random.html tl; dr "The issue is to find a solution to not block Python startup on such case, and keep getrandom() enhancement for os.urandom()." -- Status of Python 3.5.2: http://haypo-notes.readthedocs.io/pep_random.html#status-of-python-3-5-2 My summary: "With the changeset 9de508dc4837: Python doesn?t block at startup anymore (issues #25420 and #26839 are fixed) and os.urandom() is as secure as Python 2.7, Python 3.4 and any application reading /dev/urandom." => STOP! don't touch anything, it's now fine ;-) (but maybe follow my link for more information) -- To *enhance* os.urandom(), always use getrandom() syscall on Linux, I opened the issue #27266. I changed the title to "Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()" to make my intent more explicit. As some of you have already noticed, it's not easy to implement this issue! There are technical issues to implement os.urandom(block=False). In fact, this issue tries to fix two different but close issues: (a) Always use getrandom() for os.urandom() on Linux (b) Implement os.urandom(block=False) on *all* platforms The requirement for (a) is to not reopen the bug #25420 (block on "import random"). dstufft proposed no-urandom-by-default.diff (attached to this issue), but IMHO it makes the random module worse than before. I proposed (b) as the correct fix. It's a work-in-progress, please come on the issue #27266 to help me! -- Please contact me if we want to fix/enhance my doc http://haypo-notes.readthedocs.io/pep_random.html Right now, I'm not interested to convert this summary to a real PEP. It looks like you agree on solutions. We should now invest our time on solutions rather than listing again all issues ;-) I know that it's really hard, but I suggest to abandon this issue (since, again, it's closed!), and focus on more specific issues and work on fixing issues. No? What do you think? -- IMHO The problem in this discussion is that it started with a very well defined issue (Python blocks at startup on Debian Testing in a script started by systemd when running in a VM) to a wide discussion about all RNG, all kinds of issues related to RNG and a little bit to security in general. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 13:37:29 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 08 Jun 2016 17:37:29 +0000 Subject: [issue27242] Make the docs for NotImplemented & NotImplementedError unambiguous In-Reply-To: <1465239567.69.0.773832868585.issue27242@psf.upfronthosting.co.za> Message-ID: <1465407449.34.0.559679487278.issue27242@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- title: Make the docs for NotImplemented & NotImplementedError unambigous -> Make the docs for NotImplemented & NotImplementedError unambiguous _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 13:38:03 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 08 Jun 2016 17:38:03 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1465407483.79.0.778391486515.issue24567@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Will get to it shortly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 13:40:30 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 08 Jun 2016 17:40:30 +0000 Subject: [issue27260] Missing equality check for super objects In-Reply-To: <1465332483.31.0.223891907563.issue27260@psf.upfronthosting.co.za> Message-ID: <1465407630.01.0.448008833788.issue27260@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I don't think this should be done. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 13:41:45 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jun 2016 17:41:45 +0000 Subject: [issue27268] Incorrect error message on float('') In-Reply-To: <1465396464.66.0.148764915141.issue27268@psf.upfronthosting.co.za> Message-ID: <1465407705.02.0.026053012826.issue27268@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +mark.dickinson, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 14:22:52 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 08 Jun 2016 18:22:52 +0000 Subject: [issue27262] IDLE: move Aqua context menu code to maxosx In-Reply-To: <1465352483.17.0.330062690814.issue27262@psf.upfronthosting.co.za> Message-ID: <1465410172.92.0.0977486275836.issue27262@psf.upfronthosting.co.za> Terry J. Reedy added the comment: [The light dawns, as the pieces connect together] The pseudoclass 'MyButton' would then consist of all widgets with 'MyButton' inserted into its bindtags list. Similarly for 'Editor'. I presume that a) tk has the equivalent of a master bind dict mapping bindtags to dicts mapping event sequences strings to event handlers, and b) .bind_class(cname, evseq, func) does the equivalent of "tagdict.get(cname, {})[evseq] = func". I also notice that the introspective versions of .bind... call will let us discover the pre-defined bindings on difference systems and check our alterations. Anyway, thanks. I will experiment when ready to refactor bindings. In the meanwhile, I will apply the patch and close this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 14:37:36 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 Jun 2016 18:37:36 +0000 Subject: [issue27262] IDLE: move Aqua context menu code to maxosx In-Reply-To: <1465352483.17.0.330062690814.issue27262@psf.upfronthosting.co.za> Message-ID: <20160608183724.19529.40702.A12B7730@psf.io> Roundup Robot added the comment: New changeset 09ec7f7322b5 by Terry Jan Reedy in branch 'default': Issue #27262: move Aqua unbinding code, which enable context menus, to maxosx. https://hg.python.org/cpython/rev/09ec7f7322b5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 14:40:30 2016 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jun 2016 18:40:30 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465411230.53.0.542339616876.issue27266@psf.upfronthosting.co.za> Larry Hastings added the comment: First, DO NOT merge this change into 3.5.2 without my explicit permission. Second, unless you can guarantee you support blocking / non-blocking behavior on all platforms, this is a bad move. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 15:02:15 2016 From: report at bugs.python.org (Theodore Tso) Date: Wed, 08 Jun 2016 19:02:15 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465412535.75.0.197015945266.issue27266@psf.upfronthosting.co.za> Theodore Tso added the comment: Larry, at least on FreeBSD, it sounds like the implementation could just the kern.random.sys.seeded sysctl, and return . (Note: what is the proposed behaviour if the PRNG is not seeded? Return Null?) As far as OpenBSD is concerned, it's true that it's getentropy(2) never blocks. But that's because OpenBSD assumes that the bootloader can read a seeded entropy file from the previous boot session, and that the CD-ROM installer will be able to gather enough entropy to save a entropy file from the beginning of the installation. So if you don't have worry about booting your OS on an ARC Internet of Things device, you can afford to make certain simplifying assumptions. Could Linux on x86 do something similar (read the entropy file in the bootloader)? Sure, the design isn't difficult. If someone can fund the headcount to do the work, I'd be happy to help supervise the GSOC intern or work with some engineer at some other company who is interested in getting a change like this upstream. But there will still be cases where getrandom(2) could block, simply because I can't control all of the hardware platforms where Linux might be ported to. The real problem is that since on real hardware platforms it's only a problem in very early boot, it's hard to make a business case to invest in solving this problem. ---------- nosy: +Theodore Tso _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 15:42:24 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jun 2016 19:42:24 +0000 Subject: [issue27129] Wordcode, part 2 In-Reply-To: <1464268387.83.0.862540030058.issue27129@psf.upfronthosting.co.za> Message-ID: <1465414944.72.0.948467305726.issue27129@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch that just refactors the code. It renames OPCODE and OPCODE to _Py_OPCODE and _Py_OPCODE and moves them to code.h for reusing in other files. Introduces _Py_CODEUNIT as an alias to unsigned short (if it is 16-bit, otherwise a compile error is raised). Makes compiler and peepholer to operate with _Py_CODEUNIT units instead of bytes. Replaces or scale magic numbers with sizeof(_Py_CODEUNIT). Adds fill_nops() for filling specified region with NOPs. Decreases memory consumption for peepholer (doesn't allocate memory for unused odd addresses). ---------- Added file: http://bugs.python.org/file43308/wordcode-refactor.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 15:47:43 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 08 Jun 2016 19:47:43 +0000 Subject: [issue27270] 'parentheses-equality' warnings when building with clang and ccache Message-ID: <1465415263.12.0.159795814979.issue27270@psf.upfronthosting.co.za> New submission from Xavier de Gaye: Building Python with clang and ccache produces about 200 'parentheses-equality' warnings with the message: warning: equality comparison with extraneous parentheses [-Wparentheses-equality] It seems that clang does not recognize that these extraneous parentheses are valid [1] after a macro expansion because the preprocessing is done as a separate stage by ccache. [1] For example: With the macros: #define Py_TYPE(ob) (((PyObject*)(ob))->ob_type) #define PyLong_CheckExact(op) (Py_TYPE(op) == &PyLong_Type) The statement: if (PyLong_CheckExact(v)) is expanded to: if (((((PyObject*)(v))->ob_type) == &PyLong_Type)) and produces the warning with ccache. ---------- components: Devguide files: clang_ccache.patch keywords: patch messages: 267881 nosy: eric.araujo, ezio.melotti, ncoghlan, willingc, xdegaye priority: normal severity: normal stage: patch review status: open title: 'parentheses-equality' warnings when building with clang and ccache type: enhancement Added file: http://bugs.python.org/file43309/clang_ccache.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 15:54:46 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jun 2016 19:54:46 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465411230.53.0.542339616876.issue27266@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Larry Hastings added the comment: > > First, DO NOT merge this change into 3.5.2 without my explicit permission. > I explicitly removed Python 3.5 from this issue to follow your request. See my previous comment :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 16:00:44 2016 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jun 2016 20:00:44 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465416044.34.0.878611690096.issue27266@psf.upfronthosting.co.za> Larry Hastings added the comment: > getentropy() is non-blocking. By the way, os.urandom() is now implemented with getentropy() on OpenBSD. I quote issue #25003: > You can not substitute getentropy() for getrandom(), if you need randomness then entropy does not suffice. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 16:09:57 2016 From: report at bugs.python.org (Mark Lawrence) Date: Wed, 08 Jun 2016 20:09:57 +0000 Subject: [issue7063] Memory errors in array.array In-Reply-To: <1254730349.27.0.71088310024.issue7063@psf.upfronthosting.co.za> Message-ID: <1465416597.88.0.443797006448.issue7063@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 16:17:39 2016 From: report at bugs.python.org (valdemar pavesi) Date: Wed, 08 Jun 2016 20:17:39 +0000 Subject: [issue27271] asyncio lost udp packets Message-ID: <1465417059.51.0.620953300582.issue27271@psf.upfronthosting.co.za> New submission from valdemar pavesi: hello, I am using asyncio to handle 165 udp-packet per second everything received by (datagram_received) will be put into a queue. +++ 124605 UDP packets send from client. and received by server network: dumpcap ( filter "port 59999 and len > 100" ) Packets: 124605 correct number send and received. 124605 ++++++ received by application: def datagram_received(self, data, addr): [2016-06-08 14:59:49] total udp = 124255,queue size =0 [2016-06-08 14:59:49] Got 124255 json report from server. only 124255 received by application. 124605 - 124255 = 350 udp , received by network card , but application never got it. +++ code: ######################################### class UDPProtocolServerTraffica: def __init__(self): self.transport = None # heart beat timer self.HEARTBEAT_TIMEOUT = 10.0 self.REPORTSHOWTOTAL_TIMEOUT=60.0 self.MSG_UDP_HEARTBEAT = b'\x01\x00\x00\x00\x11\x00\x00\x00\x01\x00\x00\x00\x00\x05\x00\x00\x00' self.UDPCount = 0 def connection_made(self, transport): self.transport = transport # traffica startup message self.transport.sendto(self.MSG_UDP_HEARTBEAT, (fns_remote_host, fns_remote_port)) # start 10 seconds timeout timer self.h_timeout = asyncio.get_event_loop().call_later(self.HEARTBEAT_TIMEOUT, self.timeout_heartbeat) # show total report self.h_timeout = asyncio.get_event_loop().call_later(self.REPORTSHOWTOTAL_TIMEOUT, self.timeout_report_showtotal) def datagram_received(self, data, addr): #fns_mmdu_ipaddr = addr [0] #fns_mmdu_port = addr [1] Report_Id = (int.from_bytes(data[0:2], byteorder='big')) if Report_Id != 327: self.UDPCount += 1 # send message to queue asyncio_queue.put_nowait(data) def pause_reading(self): print('pause_reading') def resume_reading(self): print('resume_reading') def error_received(self, exc): print('Error received:', exc) def connection_lost(self, exc): print('stop', exc) def timeout_heartbeat(self): self.transport.sendto(self.MSG_UDP_HEARTBEAT, (fns_remote_host, fns_remote_port)) self.h_timeout = asyncio.get_event_loop().call_later(self.HEARTBEAT_TIMEOUT, self.timeout_heartbeat) #print('queue size ',asyncio_queue.qsize()) def timeout_report_showtotal(self): self.h_timeout = asyncio.get_event_loop().call_later(self.REPORTSHOWTOTAL_TIMEOUT, self.timeout_report_showtotal) self.displayReportTotalCount() elasticsearch_get_all_reports() def displayReportTotalCount(self): logging.info('Total udp from fns: ' + str(self.UDPCount) + ' , queue size: ' + str(asyncio_queue.qsize()) ) regards! Valdemar ---------- components: asyncio messages: 267884 nosy: gvanrossum, haypo, valdemar.pavesi, yselivanov priority: normal severity: normal status: open title: asyncio lost udp packets versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 16:21:28 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 08 Jun 2016 20:21:28 +0000 Subject: [issue27271] asyncio lost udp packets In-Reply-To: <1465417059.51.0.620953300582.issue27271@psf.upfronthosting.co.za> Message-ID: <1465417288.6.0.299922700952.issue27271@psf.upfronthosting.co.za> Yury Selivanov added the comment: Isn't it normal for UDP to lose some packets? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 16:26:49 2016 From: report at bugs.python.org (Hans-Peter Jansen) Date: Wed, 08 Jun 2016 20:26:49 +0000 Subject: [issue27257] get_addresses results in traceback with a valid? header In-Reply-To: <1465327493.81.0.354921385455.issue27257@psf.upfronthosting.co.za> Message-ID: <1465417609.7.0.145600244432.issue27257@psf.upfronthosting.co.za> Hans-Peter Jansen added the comment: Dear Stephen, thanks for your care. I'm glad, that you're able to reproduce it. This header is added from the email provider (the biggest here in Germany), so yes, it deserves an entry in the defects list, but must not traceback, of course. It is not expected to provide a sensible way of interoperability otherwise. The unlisted-recipients part is a bit more useful in this respect. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 16:35:23 2016 From: report at bugs.python.org (Martin Pitt) Date: Wed, 08 Jun 2016 20:35:23 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing /arguinthe random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465418123.89.0.156256770979.issue26839@psf.upfronthosting.co.za> Martin Pitt added the comment: > you could give some kind of command-line flag That already exists -- set PYTHONHASHSEED=0. > But I'll let someone else have the joys of negotiating with Lennart, and I won't blame the Python devs if using GRND_NONBLOCK unconditionally is less painful than having to work with the systemd folks. In case it's of any relief: This has nothing to do with having to change anything in systemd itself -- none of the services that systemd ships use Python. The practical case where this bug appeared was cloud-init (which is written in Python), and that wants to run early in the boot sequence even before the network is up (so that tools like "pollinate" which gather entropy from the cloud host don't kick in yet). So if there's any change needed at all, it would be in cloud-init and similar services which run Python during early boot. ---------- nosy: +pitti title: Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() -> Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing /arguinthe random module on getrandom() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 16:41:13 2016 From: report at bugs.python.org (Tim Smith) Date: Wed, 08 Jun 2016 20:41:13 +0000 Subject: [issue26955] Implement equivalent to `pip.locations.distutils_scheme` in distutils In-Reply-To: <1462378664.68.0.201238634465.issue26955@psf.upfronthosting.co.za> Message-ID: <1465418473.05.0.890909712252.issue26955@psf.upfronthosting.co.za> Tim Smith added the comment: As a Homebrew maintainer I'm happy to consider improving Homebrew's configuration if someone can point me to an extant package that uses this mechanism. ---------- nosy: +tdsmith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 16:41:25 2016 From: report at bugs.python.org (valdemar pavesi) Date: Wed, 08 Jun 2016 20:41:25 +0000 Subject: [issue27271] asyncio lost udp packets In-Reply-To: <1465417059.51.0.620953300582.issue27271@psf.upfronthosting.co.za> Message-ID: <1465418485.91.0.0446084116751.issue27271@psf.upfronthosting.co.za> valdemar pavesi added the comment: thanks Yury, I think we could lose inside the network, but we cannot lose inside of our application. regards! Valdemar ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 16:41:46 2016 From: report at bugs.python.org (Colm Buckley) Date: Wed, 08 Jun 2016 20:41:46 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing /arguinthe random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465418506.24.0.409081713338.issue26839@psf.upfronthosting.co.za> Colm Buckley added the comment: @pitti - We already discussed this; there are cases where it's not practical to set an environment variable. The discussion eventually converged on "it is not desirable that Python should block on startup, regardless of system RNG status". Re: the triggering bug; it was actually /lib/systemd/system-generators/systemd-crontab-generator (in systemd-cron) which caused the behavior to be noticed in Debian. It wasn't a change in systemd behavior, per se (that has been a Python script for some time), it was the fact that it was being called before the system PRNG had been initialized. With the change from /dev/urandom to getrandom() in 3.5.1, this caused a deadlock at boot. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 16:44:38 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 08 Jun 2016 20:44:38 +0000 Subject: [issue27271] asyncio lost udp packets In-Reply-To: <1465417059.51.0.620953300582.issue27271@psf.upfronthosting.co.za> Message-ID: <1465418678.26.0.77407391522.issue27271@psf.upfronthosting.co.za> Yury Selivanov added the comment: > I think we could lose inside the network, but we cannot lose inside of our application. UDP is fundamentally unreliable. It *will* lose data even over UNIX sockets. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 16:45:08 2016 From: report at bugs.python.org (valdemar pavesi) Date: Wed, 08 Jun 2016 20:45:08 +0000 Subject: [issue27271] asyncio lost udp packets In-Reply-To: <1465417059.51.0.620953300582.issue27271@psf.upfronthosting.co.za> Message-ID: <1465418708.2.0.874550360222.issue27271@psf.upfronthosting.co.za> valdemar pavesi added the comment: I am not getting any pause, or any message about buffer full. def pause_reading(self): print('pause_reading') def resume_reading(self): print('resume_reading') and I cannot find a way to increase the receive buffer by asyncio. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 16:49:31 2016 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jun 2016 20:49:31 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing /arguinthe random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465418971.68.0.478744503659.issue26839@psf.upfronthosting.co.za> Larry Hastings added the comment: I am increasingly convinced that I'm right. -- First, consider that the functions in the os module, as a rule, are a thin shell over the equivalent function provided by the operating system. If Python exposes a function called os.XYZ(), and it calls the OS, then with few exceptions it does so by calling a function called XYZ().** This has several ramifications, and these are effectively guarantees for the Python programmer: * You can read your local man pages (or equivalent) to see how the function behaves oh your system. Python occasionally improves on the functionality provided; os.utime() provides a lot more functionality than POSIX utime. But it never *degrades* the functionality provided. * It's implied, and strongly preferred, that the function is atomic: it will make exactly one system call. I once proposed simulating behavior for an os module function using a series of system calls, and this approach was rejected because it wasn't atomic. So if you see a function os.XYZ(), you may predict that Python will call XYZ() exactly once, and with only a few exceptions you'll be right. Now read this snippet of the documentation for os.urandom(): "The returned data should be unpredictable enough for cryptographic applications, though its exact quality depends on the OS implementation. On a Unix-like system this will query /dev/urandom, and on Windows it will use CryptGenRandom()." That text has been in the documentation for os.urandom() since at least Python 2.6. (That's as old as we have on the web site; I didn't go hunting for older documentation.) Thus the documentation for os.urandom(): * explicitly says it uses /dev/urandom, and * explicitly *does not* guarantee cryptographic strength random numbers on all platforms at all times. Thus, while it's laudable to try and give the user higher-quality random bits when they call os.urandom(), you cannot degrade the behavior of the system's /dev/urandom when doing so. On Linux /dev/urandom is *guaranteed* to never block. This guarantee is so strong, Mr. Ts'o had to add a separate facility to Linux (/dev/random) to permit blocking. os.urandom() *must* replicate this behavior. What I'm proposing is that os.urandom() may use getrandom(RND_NOBLOCK) to attempt to get higher-quality random bits, but it *must not block*. If it fails, it will use /dev/urandom, *exactly as it is documented to do*. (Naturally this flunks the "atomic operation" test. But in the case of procuring random bits, the atomicity of its operation is obviously irrelevant.) ** The exception to this, naturally, is Windows. Internally the os module is called "posixmodule"--and this is no coincidence. AFAIK every platform supported by CPython is POSIX-based except Windows. The choice was made long ago to simulate POSIX behavior on Windows so as to present a consistent API to the programmer. If you're curious about this, and have the time, read the implementation of os.stat for Windows. What a rush! -- Second, I invoke the "consenting adults" rule. Python provides well-documented behavior for os.urandom(). You cannot make assumptions about the use case of the caller and decide for them that they would prefer the function block in an unbounded fashion rather than provide low-quality random bits. And yes, unbounded. As covered earlier in the thread, it only blocked for 90 seconds before systemd killed it. We don't know how long it would actually have blocked. This is completely unacceptable--for startup, for "import random", and for "os.urandom()" on Linux. -- Third, because the os module is in general a thin wrapper over what the OS provides, I disapprove of "cryptorandom()" and "pseudorandom()" going into the os module. There are no functions with these names on any OS of which I'm aware. This is why I proposed "os.getrandom(n, block=True)". From its signature, the function it calls on your OS will be obvious, and its semantics on your OS will be documented by your OS. Thus I am completely unwilling to add os.cryptorandom() and os.pseudorandom() in 3.5.2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 16:52:16 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 08 Jun 2016 20:52:16 +0000 Subject: [issue27271] asyncio lost udp packets In-Reply-To: <1465417059.51.0.620953300582.issue27271@psf.upfronthosting.co.za> Message-ID: <1465419136.25.0.0344302664592.issue27271@psf.upfronthosting.co.za> Yury Selivanov added the comment: Even if you increase buffers you will lose data over UDP. The reason can be the network, or the kernel may simply skip sending the data. To work with buffer sizes use transport.set_write_buffer_limits ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 16:52:25 2016 From: report at bugs.python.org (valdemar pavesi) Date: Wed, 08 Jun 2016 20:52:25 +0000 Subject: [issue27271] asyncio lost udp packets In-Reply-To: <1465417059.51.0.620953300582.issue27271@psf.upfronthosting.co.za> Message-ID: <1465419145.57.0.66533128174.issue27271@psf.upfronthosting.co.za> valdemar pavesi added the comment: I do understand the possibility to lose on udp. and I am monitoring all machines involved. I am not losing on network, I am losing between our network-card-dumpcap and read udp from socket. is it possible that read will be blocked and not able to read ? during read and write to queue? I do have udp packets that will come in same microsecond. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 16:56:26 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 08 Jun 2016 20:56:26 +0000 Subject: [issue27271] asyncio lost udp packets In-Reply-To: <1465419145.57.0.66533128174.issue27271@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: How do you know the OS kernel isn't dropping them? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 17:04:48 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 08 Jun 2016 21:04:48 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing /arguinthe random module on getrandom() In-Reply-To: <1465418971.68.0.478744503659.issue26839@psf.upfronthosting.co.za> Message-ID: <57588868.3030307@egenix.com> Marc-Andre Lemburg added the comment: On 08.06.2016 22:49, Larry Hastings wrote: > > Third, because the os module is in general a thin wrapper over what the OS provides, I disapprove of "cryptorandom()" and "pseudorandom()" going into the os module. There are no functions with these names on any OS of which I'm aware. This is why I proposed "os.getrandom(n, block=True)". From its signature, the function it calls on your OS will be obvious, and its semantics on your OS will be documented by your OS. > > Thus I am completely unwilling to add os.cryptorandom() and os.pseudorandom() in 3.5.2. That was a sketch for 3.6 to resolve the ambiguity between the different use cases. You're right, it's better to move such things to the random module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 17:25:20 2016 From: report at bugs.python.org (ppperry) Date: Wed, 08 Jun 2016 21:25:20 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465421120.1.0.999265717895.issue26839@psf.upfronthosting.co.za> Changes by ppperry : ---------- title: Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing /arguinthe random module on getrandom() -> Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 17:26:27 2016 From: report at bugs.python.org (Colm Buckley) Date: Wed, 08 Jun 2016 21:26:27 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465421187.42.0.365921171164.issue26839@psf.upfronthosting.co.za> Colm Buckley added the comment: Larry - Regardless of the behavior of os.urandom (and 'import random'), is it agreed that the current state of _PyRandom_Init is acceptable for 3.5.2? The current behavior (as of 9de508dc4837) is that it will never block on Linux, but could still block on other OS if called before /dev/urandom is initialized. We have not determined a satisfactory solution for other operating systems. Note that no other OS have reported a problem 'in the wild', probably because of their extreme rarity in VM/container environments and the lack of Python in their early init sequence. Colm ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 17:30:43 2016 From: report at bugs.python.org (Marcos Dione) Date: Wed, 08 Jun 2016 21:30:43 +0000 Subject: [issue26826] Expose new copy_file_range() syscall in os module. In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za> Message-ID: <1465421442.96.0.308159643787.issue26826@psf.upfronthosting.co.za> Marcos Dione added the comment: I added a couple of unit tests, which lead me to fix a couple of bugs (yay!). I discarded the idea of removing any reference to flags. ---------- Added file: http://bugs.python.org/file43310/copy_file_range.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 17:39:17 2016 From: report at bugs.python.org (aixtools) Date: Wed, 08 Jun 2016 21:39:17 +0000 Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX) In-Reply-To: <1465050241.59.0.841731746859.issue26439@psf.upfronthosting.co.za> Message-ID: aixtools added the comment: Answering this again - now that the new patch is ready. On 04-Jun-16 16:24, Martin Panter wrote: > Martin Panter added the comment: > > Okay here are some more thoughts about your latest patch: > > ## Automatic RTLD_MEMBER ## > > I was still uneasy about the automatic setting of RTLD_MEMBER. But I looked for how others handle this, and I found Libtool?s LTDL library, and Apache Portable Runtime (APR). Both have a similar (but stricter) automatic addition based on detecting the archive(member) notation: > > http://git.savannah.gnu.org/cgit/libtool.git/commit/libltdl/loaders/dlopen.c?id=8fa719e > https://github.com/apache/apr/commit/c27f8d2 > > So I guess I can accept this way, if you think it is better than my other ideas: a) I think it is more in line with what I perceive as normal practice libFOO = CDLL(find_library("FOO")) As CDLL() has always had a 'simple' string as input and not a "tuple". I have also added some lines to test/test_loading.py to test direct calling of CDLL() with fixed strings and a test of os.maxsize and in util.py - but using e.g., CDLL(find_library("c") as behavior is dependent on 32 or 64-bit mode depending on mode - different output: note: find_library("libssl64") is expected to return None - as it would be "abnormal" to have an archive libssl64.a or a file libssl64.so cd Lib/ctypes ../../python util.py # 32-bit mode: None libc.a(shr.o) libbz2.a(libbz2.so) find_library("c") returns: libc.a(shr.o) find_library("libc") returns: libc.a(shr.o) find_library("libssl") returns: libssl.a(libssl.so) find_library("libssl64") returns: None find_library("ssl") returns: libssl.a(libssl.so) find_library("libiconv") returns: libiconv.a(libiconv.so.2) find_library("intl") returns: libintl.a(libintl.so.8) libcrypt.a(shr.o) # 64-bit mode: None libc.a(shr_64.o) libbz2.a(libbz2.so.1) find_library("c") returns: libc.a(shr_64.o) find_library("libc") returns: libc.a(shr_64.o) find_library("libssl") returns: libssl.a(libssl64.so.1.0.0) find_library("libssl64") returns: None find_library("ssl") returns: libssl.a(libssl64.so.1.0.0) find_library("libiconv") returns: libiconv.a(shr4_64.o) find_library("intl") returns: libintl.a(libintl.so.1) libcrypt.a(shr_64.o) > > # Always uses RTLD_MEMBER, never loads a plain file outside an archive > name = "libcrypto.a(libcrypto.so.1.0.0)" > > # Other options, that could be returned by find_library() and would not conflict with a plain file name > name = ("libcrypto.a", "libcrypto.so.1.0.0") # (archive, member) > name = ("libcrypto.a(libcrypto.so.1.0.0)", RTLD_MEMBER) # (name, extra-flags) > > libcrypto = CDLL(name) > > ## find_library() modes ## > > In your find_library() function, you still have three parts. Can you confirm that each behaviour is intended: I was being "Q&D" here, not changing the aixutils.py (now _aixutils.py). My intent is to be comparable with other "posix" behaviors. So, if you believe I am still not compatible with their behavior, forgive me - but also shoot me! > > A) If I have a file called "crypto" in the current directory, find_library("crypto") returns "crypto". This does not seem right. On Linux, ?gcc [. . .] -lcrypto? does not look for a file exactly called ?crypto?. > > B) You are still stripping bits off the library name if it contains ?lib? or a dot (.), so find_library("glib-2.0") is almost equivalent to find_library("b-2"). Isn?t this a bug? > > C) find_library("crypto") will return "/usr/lib/crypto" if such a file exists. Just like in A), this does not seem right to me. All should be seen as bugs, and I hope I coded it correctly to not do this anymore. > ## Other things ## > > * You don?t need to prefix most names with underscores, unless they could be confused with a public API. If you follow my earlier suggestion of renaming the new file to _aixutil.py (so it is obvious it is not a public module), then you can freely write ?import re, os, sys?, etc. I had missed, certainly not understood the context, before. aixutil.py is now _aixutil.py. Originally I had done this to make the diff in util.py much simplier, but also because I incorrectly thought CDLL() was frequently called with "foo" or "libfoo". In short, trying to prevent a non-existent problem. __init__.py delta is also much much simpler to grasp. > * No need to add the internal variable names to the function signatures. Just write find_library(name), and if you need to initialize a variable, do that in the body. Oops - not removed those yet. That was done to be sure there was no global scope interference. If you feel it is vital they be removed - will be done. > > * I suggest to go over all the regular expressions, and either change them to plain string searching, or make sure special characters and external variables are escaped as necessary. A comment explaining what the RE is trying to do might help too. Ugh. I actually hate string stuff. I will need to spend more time on that. FYI - after a lot of testing with various expr strings I found not using the 'raw' format worked better (read: I was probably making beginner errors, and made fewer when using "normal" back-slash escapes. However, I shall add comments in the next pass (which I now conclude is unavoidable) However #2 - I hope we are really really close to an acceptable patch. Michael > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 17:41:50 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 08 Jun 2016 21:41:50 +0000 Subject: [issue27270] 'parentheses-equality' warnings when building with clang and ccache In-Reply-To: <1465415263.12.0.159795814979.issue27270@psf.upfronthosting.co.za> Message-ID: <1465422110.24.0.532510707068.issue27270@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I like this suggestion. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 17:43:32 2016 From: report at bugs.python.org (Michael Felt) Date: Wed, 08 Jun 2016 21:43:32 +0000 Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX) In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za> Message-ID: <1465422212.78.0.584616279183.issue26439@psf.upfronthosting.co.za> Michael Felt added the comment: aixutil.py renamed as _aixutil.py and other changes in response to Martin's comments of 4 June ---------- Added file: http://bugs.python.org/file43311/_aixutil.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 17:45:29 2016 From: report at bugs.python.org (Michael Felt) Date: Wed, 08 Jun 2016 21:45:29 +0000 Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX) In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za> Message-ID: <1465422329.58.0.507851404437.issue26439@psf.upfronthosting.co.za> Michael Felt added the comment: aixutil.py renamed as _aixutil.py and other changes in response to Martin's comments of 4 June delta of changes to __init__.py, util.py, and test/test_loading.py ---------- Added file: http://bugs.python.org/file43312/python.Lib.ctypes.160608.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 17:57:39 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 Jun 2016 21:57:39 +0000 Subject: [issue27066] SystemError if custom opener returns -1 In-Reply-To: <1463701849.23.0.646090431797.issue27066@psf.upfronthosting.co.za> Message-ID: <20160608215733.18306.97604.2236B211@psf.io> Roundup Robot added the comment: New changeset 4af64ab34eef by Barry Warsaw in branch '3.5': Issue #27066: Fixed SystemError if a custom opener (for open()) returns https://hg.python.org/cpython/rev/4af64ab34eef New changeset 84c91d7d4667 by Barry Warsaw in branch 'default': Issue #27066: Fixed SystemError if a custom opener (for open()) returns a https://hg.python.org/cpython/rev/84c91d7d4667 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 17:58:16 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jun 2016 21:58:16 +0000 Subject: [issue27272] random.Random should not read 2500 bytes from urandom Message-ID: <1465423096.81.0.204885224668.issue27272@psf.upfronthosting.co.za> New submission from STINNER Victor: Reading more than 256 bytes from os.urandom() is different than reading 256 bytes or less. For example, see getrandom() and getentropy() manual pages for more details. random.Random doesn't need a very high quality entropy. The glib library only reads 128 bits from /dev/urandom to initialize the Mersenne Twister RNG for example. ---------- messages: 267905 nosy: christian.heimes, haypo priority: normal severity: normal status: open title: random.Random should not read 2500 bytes from urandom versions: Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 17:58:54 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 08 Jun 2016 21:58:54 +0000 Subject: [issue27066] SystemError if custom opener returns -1 In-Reply-To: <1463701849.23.0.646090431797.issue27066@psf.upfronthosting.co.za> Message-ID: <1465423134.36.0.580488203387.issue27066@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 17:58:59 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jun 2016 21:58:59 +0000 Subject: [issue27272] random.Random should not read 2500 bytes from urandom In-Reply-To: <1465423096.81.0.204885224668.issue27272@psf.upfronthosting.co.za> Message-ID: <1465423139.92.0.832277942189.issue27272@psf.upfronthosting.co.za> STINNER Victor added the comment: Related issue #26839. Don't read this very long issue! You can read my summary :-D https://haypo-notes.readthedocs.io/pep_random.html#bug-reports ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 18:01:49 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 08 Jun 2016 22:01:49 +0000 Subject: [issue27257] get_addresses results in traceback with an addrspec with an empty local part. In-Reply-To: <1465327493.81.0.354921385455.issue27257@psf.upfronthosting.co.za> Message-ID: <1465423309.32.0.846474652766.issue27257@psf.upfronthosting.co.za> R. David Murray added the comment: Yeah, it never occurred to me that the local part could be empty, so I never made a test case for that. The correct behavior should indeed to be to register a defect and set the local part to blank. I will not be surprised if there are other bits of the code (on the output side) that expect local part to be non-blank, so there may be some additional test cases and fixes needed. ---------- title: get_addresses results in traceback with a valid? header -> get_addresses results in traceback with an addrspec with an empty local part. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 18:09:44 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 Jun 2016 22:09:44 +0000 Subject: [issue27239] Make idlelib.macosx self-contained. In-Reply-To: <1465181854.1.0.00138868755932.issue27239@psf.upfronthosting.co.za> Message-ID: <20160608220940.5871.74725.DC1BB2E5@psf.io> Roundup Robot added the comment: New changeset cc7f63b6847e by Terry Jan Reedy in branch 'default': Issue #27239: idlelib.macosx.isXyzTk functions initialize as needed. https://hg.python.org/cpython/rev/cc7f63b6847e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 18:13:09 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jun 2016 22:13:09 +0000 Subject: [issue27272] random.Random should not read 2500 bytes from urandom In-Reply-To: <1465423096.81.0.204885224668.issue27272@psf.upfronthosting.co.za> Message-ID: <1465423989.69.0.136358630043.issue27272@psf.upfronthosting.co.za> STINNER Victor added the comment: PHP uses GENERATE_SEED() to initialize mt_rand(): https://github.com/php/php-src/blob/1c295d4a9ac78fcc2f77d6695987598bb7abcb83/ext/standard/php_rand.h#L50 This macro uses: time() (resolution of 1 second), process identifier, php_combined_lcg() php_combined_lcg() is seeded using: gettimeofday(), and getpid() or thread id in ZTS mode, gettimeofday() (called again after getpid()): https://github.com/php/php-src/blob/1c295d4a9ac78fcc2f77d6695987598bb7abcb83/ext/standard/lcg.c#L55 mt_rand(): https://github.com/php/php-src/blob/1c295d4a9ac78fcc2f77d6695987598bb7abcb83/ext/standard/rand.c#L308 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 18:16:57 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jun 2016 22:16:57 +0000 Subject: [issue27272] random.Random should not read 2500 bytes from urandom In-Reply-To: <1465423096.81.0.204885224668.issue27272@psf.upfronthosting.co.za> Message-ID: <1465424217.02.0.808932777634.issue27272@psf.upfronthosting.co.za> STINNER Victor added the comment: Donald Stufft proposed the patch no-urandom-by-default.diff in the issue #26839 which replaces os.urandom() with int(time.time()*256) in random.Random constructor. I dislike this change because it becomes more likely that two Python processes produce the same random number sequence: https://bugs.python.org/issue26839#msg267819 ---------- nosy: +dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 18:17:33 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 08 Jun 2016 22:17:33 +0000 Subject: [issue27239] Make idlelib.macosx self-contained. In-Reply-To: <1465181854.1.0.00138868755932.issue27239@psf.upfronthosting.co.za> Message-ID: <1465424253.34.0.563146135474.issue27239@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I ran into this issue again with the test I am writing for another issue, so I pushed it as is, after testing. Ned, neither of the working OSX buildbots run gui tests. I am presuming that you run the test suite occasionally and will notice if test_idle fails. Serhiy, almost ditto, except for Zach Ware's Gentoo bot. What do you think of initializing, using a temporary Tk(), during import? Or best to leave as is? ---------- resolution: -> fixed stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 18:18:12 2016 From: report at bugs.python.org (Donald Stufft) Date: Wed, 08 Jun 2016 22:18:12 +0000 Subject: [issue27272] random.Random should not read 2500 bytes from urandom In-Reply-To: <1465423096.81.0.204885224668.issue27272@psf.upfronthosting.co.za> Message-ID: <1465424292.78.0.442249603078.issue27272@psf.upfronthosting.co.za> Donald Stufft added the comment: To be clear, that was a minimal patch using a method that already existing. It could be made a lot better by mixing in other sources of entropy like PID#, id(self), etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 18:19:25 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jun 2016 22:19:25 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465424365.73.0.912732615632.issue26839@psf.upfronthosting.co.za> STINNER Victor added the comment: I opened the issue #27272: "random.Random should not read 2500 bytes from urandom". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 18:22:03 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jun 2016 22:22:03 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465424523.33.0.756292014599.issue26839@psf.upfronthosting.co.za> STINNER Victor added the comment: > The current behavior (as of 9de508dc4837) is that it will never block on Linux, but could still block on other OS if called before /dev/urandom is initialized. In practice, only Linux is impacted. See the rationale: https://haypo-notes.readthedocs.io/pep_random.html#scope-of-the-python-blocks-at-startup-issue > We have not determined a satisfactory solution for other operating systems. Stoooop. This issue is specific to Linux. If you want to fix the issue on other operating systems, please open a new issue. Oh, you know what? I already opened such issue :-) The issue #27266 wants to fix the issue on all platforms, not only Linux. Open a second issue if you prefer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 18:23:44 2016 From: report at bugs.python.org (Donald Stufft) Date: Wed, 08 Jun 2016 22:23:44 +0000 Subject: [issue27272] random.Random should not read 2500 bytes from urandom In-Reply-To: <1465423096.81.0.204885224668.issue27272@psf.upfronthosting.co.za> Message-ID: <1465424624.53.0.783764556338.issue27272@psf.upfronthosting.co.za> Donald Stufft added the comment: One of the key take aways though is that MT doesn't really *need* to be initialized with a CSPRNG, all it needs it some moderately random data. So we can eliminate the case all together by just not using it. Though a sticking point is that it's documented to seed itself from os.urandom if seed(None) is called. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 18:24:26 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 08 Jun 2016 22:24:26 +0000 Subject: [issue27256] header indentation destroyed In-Reply-To: <1465326886.85.0.738328133832.issue27256@psf.upfronthosting.co.za> Message-ID: <1465424666.87.0.499979754772.issue27256@psf.upfronthosting.co.za> R. David Murray added the comment: Hmm. There appear to be at least two bugs here, using the SMTP policy. I thought I had test cases like this, but clearly I don't :( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 18:29:41 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jun 2016 22:29:41 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465424981.05.0.542613649065.issue27266@psf.upfronthosting.co.za> STINNER Victor added the comment: > Second, unless you can guarantee you support blocking / non-blocking behavior on all platforms, this is a bad move. Well, there are two options: * Detect when os.urandom() is going to block, and falls back to weaker entropy (Linux: /dev/urandom in non-blocking mode, others: getpid+time?). * Never use os.urandom() to seed random.Random when the randim module is imported: I suggest to discuss this option in the issue #27272 I would prefer to collect enough technical information before taking a decision (ensure that it's not possible to get a portable function to check if /dev/urandom is going to block.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 18:33:02 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jun 2016 22:33:02 +0000 Subject: [issue27249] Add os.urandom_info In-Reply-To: <1465301174.7.0.6272995241.issue27249@psf.upfronthosting.co.za> Message-ID: <1465425182.43.0.327610558208.issue27249@psf.upfronthosting.co.za> STINNER Victor added the comment: The current trend in the random discussion (see https://haypo-notes.readthedocs.io/pep_random.html and the issue #26839) is more to use weak entropy to start Python (hash seed and random constructor) and os.urandom() blocks until the kernel collected enough entropy. In this case, such information is no more needed. So I close this issue, superseded by the issue #27266. ---------- resolution: -> postponed status: open -> closed superseder: -> Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 18:34:33 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jun 2016 22:34:33 +0000 Subject: [issue27250] Add os.urandom_block() In-Reply-To: <1465302067.94.0.484576804121.issue27250@psf.upfronthosting.co.za> Message-ID: <1465425273.41.0.252223079491.issue27250@psf.upfronthosting.co.za> STINNER Victor added the comment: > Should this ticket be named "Add os.random()" ? After all, blocking in case of missing entropy is what /dev/random is all about. In short, /dev/random must not be used :-) See: https://haypo-notes.readthedocs.io/pep_random.html#rng-denial-of-service ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 18:42:03 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jun 2016 22:42:03 +0000 Subject: [issue27250] Add os.urandom_block() In-Reply-To: <1465302067.94.0.484576804121.issue27250@psf.upfronthosting.co.za> Message-ID: <1465425723.27.0.0161891620932.issue27250@psf.upfronthosting.co.za> STINNER Victor added the comment: IMHO "Should os.urandom() block before the kernel collected enough entropy?" is the last major question in the large discussion around random: https://haypo-notes.readthedocs.io/pep_random.html#os-urandom It became clear that Python at startup should use a weak entropy if high-quality entropy is not available (read would block): https://haypo-notes.readthedocs.io/pep_random.html#python-startup So Python startup should no more be impacted if os.urandom() blocks or not. In this case, I'm in favor of making os.urandom() the most secure as possible: block until the kernel collected enough entropy. I'm in favor in the issue #27266 instead of this one. If it is not possible to agree on a solution, I fear that a PEP will be required. I hope that once people understood that the Python startup issue is (no more) unrelated to the behaviour of os.urandom() (block or not), most people will be in favor of making os.urandom() as secure as possible. See also https://haypo-notes.readthedocs.io/pep_random.html : my summary of the issue #26839. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 18:51:04 2016 From: report at bugs.python.org (A. Jesse Jiryu Davis) Date: Wed, 08 Jun 2016 22:51:04 +0000 Subject: [issue27136] sock_connect fails for bluetooth (and probably others) In-Reply-To: <1464346938.98.0.196127839357.issue27136@psf.upfronthosting.co.za> Message-ID: <1465426264.31.0.804277548515.issue27136@psf.upfronthosting.co.za> A. Jesse Jiryu Davis added the comment: The asyncio fix was proposed and reviewed here: https://github.com/python/asyncio/pull/357 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 18:54:20 2016 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jun 2016 22:54:20 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465426460.54.0.442124647155.issue27266@psf.upfronthosting.co.za> Larry Hastings added the comment: This is why I'm unwilling to accept this change in 3.5.2. This sort of "we think it's right" behavior is only appropriate in a point release like 3.6. I think odds are better than even that I'm going to get an os.getrandom(n, block=True) call in 3.5.2. It solves problems, and its behavior is predictable on a platform-by-platform basis. It also won't change the behavior of any reasonable existing code. (Yes, someone could say "if hasattr(os, 'getrandom'): detonate_the_device()" but that's unreasonable.) If os.getrandom(n, block=True) goes in 3.5 and 3.6, this makes adding a block parameter to os.urandom() less interesting. Also I disagree with adding the block parameter to os.urandom() in the first place. os.urandom() should behave like the /dev/urandom device on the local OS. Whether or not /dev/urandom blocks is system-dependent behavior. On Linux, it's guaranteed to never block; on FreeBSD it is permitted to block under certain conditions. At the point that you say "but on Linux we're implementing os.urandom() using the getrandom() system call, which has the ability to block if you want", you are straying quite far from the behavior of os.urandom(). Functions in the os module are intended to provide a thin shell around the equivalent local OS function, and should behave predictably like that local function. os.stat() should behave like the local stat(); os.utime() should behave like the local utime(); and os.urandom() should behave like the local /dev/urandom. It's okay to add functionality for free, but it's not okay to degrade behavior (like "it might block forever"). Since the behavior of /dev/urandom already varies so widely between different platforms, I think it adds unhelpful complexity and confusion to add the block= parameter. I think we're much better off with a new function providing the local system call: os.getrandom(), if available, and perhaps os.getentropy(), if available. Then we preserve the "behaves predictably like the local system call" approach of the os module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 18:56:24 2016 From: report at bugs.python.org (Donald Stufft) Date: Wed, 08 Jun 2016 22:56:24 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465426584.03.0.347115217613.issue27266@psf.upfronthosting.co.za> Donald Stufft added the comment: It would still be a thin shell around what the OS provides, it'd just be a thin wrapper around getrandom() instead of around /dev/urandom specifically-- but accessing the same content. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 18:58:18 2016 From: report at bugs.python.org (Donald Stufft) Date: Wed, 08 Jun 2016 22:58:18 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465426698.15.0.0251470979719.issue27266@psf.upfronthosting.co.za> Donald Stufft added the comment: I think a new function is a bad idea TBH, os.urandom provides 99% of the right interface on Linux, and 100% of the right interface on other OSes and there is a lot of code out there using os.urandom for it's security properties, and a lot of people educating users to use os.urandom for security sensitive tasks. All of a sudden going, "wait! You actually want Y" is not going to make anything more clear, especially since the difference in behavior only matters in an edge case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 19:14:17 2016 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jun 2016 23:14:17 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465427657.17.0.884332514849.issue27266@psf.upfronthosting.co.za> Larry Hastings added the comment: os.getrandom() would be a thin shell around what the local OS provides, and has the advantage of behaving in a predictable manner. If you provide block=, its implementation and semantics will vary wildly between platforms. * On Linux, block=False should be the default. block=True means it will use getrandom(), and block=False means it will use /dev/urandom except possibly getrandom(). * On FreeBSD, block=True will be the default, and block=False will either be ignored, or return an empty string (or throw an exception, depending on what would be a better error-handling mechanism, IDK). * On OS X, block=False would be the default, and block=True would be ignored, because the interface doesn't permit blocking to wait for additional entropy and generating higher-quality random bits. So, yes, the os module should *expose* the behavior of the underlying OS, rather than trying to paper over it. > there is a lot of code out there using os.urandom for it's security properties This is exactly why we should not change the behavior of os.urandom(). os.urandom() must not block on Linux. So defaulting to block=True on Linux is a non-starter. The argument "if we add a block parameter, then users can use it and benefit", is equivalent to saying "if we add a new function os.getrandom(), then users can use it and benefit". The user needs to be educated, and we can do that with either approach. However, if users want to write backwards-compatible code, it's a lot easier to detect the presence or lack of a new function (hasattr(os, "getrandom")) than to detect the presence or lack of a new parameter to an existing function (which, if we're lucky, we could do with inspect.signature, and if we're unlucky involves a try/except block). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 19:14:41 2016 From: report at bugs.python.org (Donald Stufft) Date: Wed, 08 Jun 2016 23:14:41 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465427681.06.0.132286521284.issue27266@psf.upfronthosting.co.za> Donald Stufft added the comment: I also contest the idea that os functions must only be thin shells around system provided calls (even though I don't think that using getrandom instead of reading from /dev/urandom violates that assertion). There are a number of functions in os.py that add additional logic ontop of the system calls, like: * os.makedirs * os.removedirs * os.renames * os.walk * os.popen (which actually imports and uses the entire subprocess module) * os.scandir That's just from a quick scan of the pure Python os.py file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 19:16:00 2016 From: report at bugs.python.org (Donald Stufft) Date: Wed, 08 Jun 2016 23:16:00 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465427760.76.0.264990741943.issue27266@psf.upfronthosting.co.za> Donald Stufft added the comment: > > there is a lot of code out there using os.urandom for it's security properties > > This is exactly why we should not change the behavior of os.urandom(). os.urandom() must not block on Linux. So defaulting to block=True on Linux is a non-starter. This statement doesn't make any sense to me... you're asserting that because a lot of people are using os.urandom assuming it's going to give them cryptographically secure random numbers... we shouldn't change the implementation of this function to assure that they are going to get cryptographically secure random numbers? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 19:23:13 2016 From: report at bugs.python.org (valdemar pavesi) Date: Wed, 08 Jun 2016 23:23:13 +0000 Subject: [issue27271] asyncio lost udp packets In-Reply-To: <1465417059.51.0.620953300582.issue27271@psf.upfronthosting.co.za> Message-ID: <1465428193.7.0.137357893464.issue27271@psf.upfronthosting.co.za> valdemar pavesi added the comment: hi, I did made a change, removing the queue and calling corotine. and now lost udp is bigger. def datagram_received(self, data, addr): asyncio.ensure_future(process_report(data)) @asyncio.coroutine def process_report(data): tcmpdump got 38122 and asyncio got just 20711 2016-06-08 18:19:23,209 [INFO] 546 Total udp from fns: 20711 , queue size: 0 2016-06-08 18:19:23,209 [INFO] 417 Got 20711 json report from traffica server all udp received will be send by tcp to another server. (Got 20711 json report ) ---------- Added file: http://bugs.python.org/file43313/calling_corotine_wihout_queue_lost_bigger.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 19:26:53 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 08 Jun 2016 23:26:53 +0000 Subject: [issue27271] asyncio lost udp packets In-Reply-To: <1465417059.51.0.620953300582.issue27271@psf.upfronthosting.co.za> Message-ID: <1465428413.5.0.910272981093.issue27271@psf.upfronthosting.co.za> Guido van Rossum added the comment: You have not convinced anyone that this is asyncio's fault. I'm closing the issue. If you need help debugging this please use the python-tulip Google Group; if in the end it is found to be an asyncio issue we'll help you file a useful bug report on the asyncio GitHub project. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 19:31:38 2016 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 08 Jun 2016 23:31:38 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465428698.36.0.947838773463.issue27266@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 19:31:43 2016 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 08 Jun 2016 23:31:43 +0000 Subject: [issue27250] Add os.urandom_block() In-Reply-To: <1465302067.94.0.484576804121.issue27250@psf.upfronthosting.co.za> Message-ID: <1465428703.86.0.385087740788.issue27250@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 19:32:05 2016 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 08 Jun 2016 23:32:05 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465428725.76.0.0890355495836.issue26839@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 19:32:33 2016 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jun 2016 23:32:33 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465428753.16.0.31330113672.issue27266@psf.upfronthosting.co.za> Larry Hastings added the comment: > There are a number of functions in os.py that add additional logic ontop of the system calls, like: All the functions you name don't have POSIX equivalents, except popen and scandir. popen provides a lot of functionality around popen (which internally does fork()/exec()). But fundamentally it behaves like popen, and its behavior is predictable across platforms. scandir() says right in the documentation: it's implemented using opendir() and readdir(). This makes the behavior predictable across platforms. You might have also cited os.utime(), which hides byzantine complexity internally and may be implemented with one of about a half-dozen local calls. But is behavior is predictable across platforms. /dev/urandom behaves very differently on different platforms, to an extent that CPython can't reasonably be expected to hide the cross-platform behavior and behave in an outwardly predictable manner. On Linux, by default it should never block, and we could theoretically provide additional functionality to let it block and guarantee high-quality random bits. On OS X, we don't have any option: it will never block, and it will never provide high-quality random bits. On FreeBSD, we don't have any option: it could locally block, and if the user would prefer to not block and get lower-quality random numbers as a result, sorry they're out of luck. It's not reasonable for os.urandom() to hide this complexity. It is better that os.urandom() is a thin layer around /dev/urandom, and behaves predictably like /dev/urandom on the local computer. The block= parameter confuses the matter greatly, which is why I oppose it. > This statement doesn't make any sense to me... you're asserting that because a lot of people are using os.urandom assuming it's going to give them cryptographically secure random numbers... we shouldn't change the implementation of this function to assure that they are going to get cryptographically secure random numbers? You misunderstand me. I assert that people are calling os.urandom() because they expect it to behave like /dev/urandom on their machine. I make no assertion what they expect to happen as a result. What is returned by os.urandom() is platform-dependent. If you read the documentation for os.urandom(), it specifically does *not* guarantee the result is suitable for cryptography. The one-line summary seems to suggest that it does, but then in the very next paragraph it clarifies the situation: "This function returns random bytes from an OS-specific randomness source. The returned data should be unpredictable enough for cryptographic applications, though its exact quality depends on the OS implementation." I *am* asserting that /dev/urandom is guaranteed to not block on Linux, therefore os.urandom() should never block on Linux. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 19:43:53 2016 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jun 2016 23:43:53 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465429433.18.0.561045548119.issue27266@psf.upfronthosting.co.za> Larry Hastings added the comment: Let me make one more thing clear. I'm willing for os.urandom() to try to use getrandom(GRND_NOBLOCK) (or whatever the flag is called). This will not block unless the entropy pool is low--which almost never happens. So 99.9999% of the time, os.urandom() should return lovely high-quality, cryptographically-safe random numbers. Really this entire debacle is an argument about this funny edge cases, like "you create a new VM and run python3 as PID 0 and your bad sysadmins don't manage the entropy pool and the entropy pool never fills". What should the code do in that situation? Is it acceptable to use low-quality bits from /dev/urandom? Or do they need cryptographically-strong random numbers? I quote the Zen: "In the face of ambiguity, refuse the temptation to guess." Thus, we shouldn't block on Linux, and we should behave predictably like /dev/urandom does on the local machine. This leads me to one reason why I oppose block=. It's hiding the complexity of the local system with even more complexity, and makes it hard to reason about what the code is doing. The os module should behave in a predictable manner, as if it was a thin shell around the local system call. Given that it's impossible to block on Linux and get higher-quality random bits, and it's impossible to *not* block on FreeBSD and get lower-quality random bits, adding block= to os.urandom() means its behavior becomes inobvious and hard to predict. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 19:46:49 2016 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 08 Jun 2016 23:46:49 +0000 Subject: [issue27250] Add os.urandom_block() In-Reply-To: <1465302067.94.0.484576804121.issue27250@psf.upfronthosting.co.za> Message-ID: <1465429609.74.0.0532338312882.issue27250@psf.upfronthosting.co.za> Nick Coghlan added the comment: One request I'd make in these discussions is that we avoid using the term "block" - it makes people think of the /dev/random behaviour (i.e. blocking intermittently and unhelpfully), rather than the usually-desired "wait for sufficient entropy on system startup" behaviour. I'd also request that we keep in mind that any Linux user always remains free to write the 3-line utility function: def read_urandom(num_bytes): with open('/dev/urandom', 'rb') as urandom: return urandom.read(num_bytes) If they want to get precisely the Linux /dev/urandom semantics, and not a Python level abstraction that provides the same kinds of assurances offered by other *nix platforms. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 19:49:39 2016 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 08 Jun 2016 23:49:39 +0000 Subject: [issue27250] Add os.urandom_block() In-Reply-To: <1465302067.94.0.484576804121.issue27250@psf.upfronthosting.co.za> Message-ID: <1465429779.74.0.361097099351.issue27250@psf.upfronthosting.co.za> Nick Coghlan added the comment: Victor, given the assumption that internal hashing and the random module will change to no longer depend on os.urandom, are you happy to close this one in favour of #27250? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 19:51:58 2016 From: report at bugs.python.org (Donald Stufft) Date: Wed, 08 Jun 2016 23:51:58 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465429918.22.0.944966856768.issue27266@psf.upfronthosting.co.za> Donald Stufft added the comment: > The block= parameter confuses the matter greatly, which is why I oppose it. I don't like the block= parameter. > I assert that people are calling os.urandom() because they expect it to behave like /dev/urandom on their machine. I don't think most people calling os.urandom have any idea how /dev/urandom behaves on their machine nor do I think most people have any idea how /dev/urandom behaves on other people's machines. In fact, in the original thread there were long time developers stating factually wrong information about the properties of os.urandom. That's not a mark against them, the behavior of random is an esoteric and nuanced thing and there is a lot of misinformation out there about the properties and behavior of it on various systems. > If you read the documentation for os.urandom(), it specifically does *not* guarantee the result is suitable for cryptography. Sure, but the cases where os.urandom doesn't provide results suitable for cryptography are: * Systems where you have a random number generator that is completely broken, in which case there's basically no help for you and you're screwed 10 times over before you even execute Python. * Linux, in the window prior to the pool being initialized. That statement is an obvious hedge against the first case, not an allowance for the second case in situations where we don't have to continue to use a worse interface for the same underlying functionality. If chdir on Linux would, in 0.01% of cases, cause a segfault, but 99.9% of cases work as you'd expect and a new, chdir2 function was added that still changed the directory, but did so in 100% of cases, would you be opposed to changing os.chdir to use chdir2, even though it's no longer a thin wrapper around chdir or would you demand that all developers switch to os.chdir2? Especially if this behavior only really occurred on Linux. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 19:59:22 2016 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jun 2016 23:59:22 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465430362.75.0.993530083711.issue27266@psf.upfronthosting.co.za> Larry Hastings added the comment: Wait a minute. If I read the code correctly, currently os.urandom() is implemented strictly using getrandom() *on all platforms*. And if block=false, it... returns an empty buffer? Am I reading that right? And what does it do on platforms that don't have a getrandom() call? Does os.urandom() literally always raise an exception on OS X or FreeBSD? This is so crazy. Surely I'm misunderstanding the code. What am I missing? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 19:59:24 2016 From: report at bugs.python.org (Akira Li) Date: Wed, 08 Jun 2016 23:59:24 +0000 Subject: [issue27273] subprocess.run(cmd, input='text') should pass universal_newlines=True to Popen Message-ID: <1465430363.96.0.915441067061.issue27273@psf.upfronthosting.co.za> New submission from Akira Li: At the moment, subprocess.run(cmd, input='text') raises TypeError. It would be nice if universal_newlines=isinstance(input, str) if *input* is set. I've attached a corresponding patch with the necessary changes to the docs, tests and the subprocess.run() code. ---------- components: Library (Lib) files: text_input.diff keywords: patch messages: 267936 nosy: akira priority: normal severity: normal status: open title: subprocess.run(cmd, input='text') should pass universal_newlines=True to Popen type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43314/text_input.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 20:03:11 2016 From: report at bugs.python.org (Larry Hastings) Date: Thu, 09 Jun 2016 00:03:11 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465430591.52.0.836434419564.issue27266@psf.upfronthosting.co.za> Larry Hastings added the comment: > I don't think most people calling os.urandom have any idea how /dev/urandom behaves on their machine nor do I think most people have any idea how /dev/urandom behaves on other people's machines. Here I invoke the "consenting adults" rule. In Python development, we never say "The user doesn't know what they're doing here, so we need to do the right thing for them." You must treat Python programmers as adults and assume they know what they're doing. If the user is calling os.urandom(), which is documented as behaving like /dev/urandom, then it must behave like /dev/urandom. We can optionally make it behave better than /dev/urandom, but not at the cost of unpredictable complexity, and not at the cost of degraded performance (unbounded blocking). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 20:04:55 2016 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 09 Jun 2016 00:04:55 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465430695.0.0.555300487063.issue27266@psf.upfronthosting.co.za> Nick Coghlan added the comment: Transferring a comment I previously made on #27250: One request I'd make in these discussions is that we avoid using the term "block" - it makes people think of the /dev/random behaviour (i.e. blocking intermittently and unhelpfully), rather than the usually-desired "wait for sufficient entropy on system startup" behaviour. (The only documented case where that behaviour clearly *isn't* desired is for people writing startup scripts on Linux that may run before the system entropy pool is initialised, since doing that has been shown to deadlock the system until the systemd script watchdog times out) I'd also request that we keep in mind that any Linux user always remains free to write the 3-line utility function: def read_urandom(num_bytes): with open('/dev/urandom', 'rb') as urandom: return urandom.read(num_bytes) If they want to get precisely the Linux /dev/urandom semantics, and not a Python level abstraction that provides the same kinds of assurances offered by other *nix platforms and by the Windows crypto APIs. While "os" originated as a relatively thin wrapper around POSIX APIs, that's far from universally true these days, especially given the introduction of things like implicit Unicode handling, implicit EINTR handling, os.scandir, dir_fd handling, and more. I'd also *STRONGLY* request that we avoid adding any new APIs in relation to this that mean "Use os.urandom" is no longer the preferred option to obtain cryptographically strong random numbers in Python. Any such APIs can't be used in single source Python 2/3 code, they invalidate existing third party documentation like https://cryptography.io/en/latest/random-numbers/ and they invalidate answers on Q&A sites like http://stackoverflow.com/questions/20936993/how-can-i-create-a-random-number-that-is-cryptographically-secure-in-python ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 20:07:00 2016 From: report at bugs.python.org (Larry Hastings) Date: Thu, 09 Jun 2016 00:07:00 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465430820.9.0.725286875966.issue26839@psf.upfronthosting.co.za> Larry Hastings added the comment: > Regardless of the behavior of os.urandom (and 'import random'), is it agreed that the current state of _PyRandom_Init is acceptable for 3.5.2? I'll get back to you with a specific yes or no. What I want is that it the behavior removed where "import random" can block unboundedly on Linux because it's waiting for the entropy pool to fill. If the code behaves like that, then yes, but I'm not giving it my official blessing until I read it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 20:14:27 2016 From: report at bugs.python.org (Donald Stufft) Date: Thu, 09 Jun 2016 00:14:27 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465431267.53.0.00472501418062.issue27266@psf.upfronthosting.co.za> Donald Stufft added the comment: Python should strive do the right thing, and the right thing for something as security sensitive as accessing a CSPRNG is to use the interface that most strongly promises to in fact, give cryptographically secure random numbers. Obsessing over the purity of matching /dev/urandom because the function happens to be called os.urandom is only making Python more dangerous to use. This is exactly the kind of change like making urllib validate HTTPS by default, it doesn't matter what you document something as behaving, what matters is how people use it and what the expectations are of the average user. The nice thing about this change, is the downside is massively smaller than that urllib change, because it's basically not going to negatively affect the vast vast bulk of people. I think this is doubly so since to get the behavior you desire on Linux is trivial to do regardless of what os.urandom does, which is using the code snippet that Nick pasted. Larry, I'm sorry but I think you're just flat wrong here and I don't know what else to say about it. Since you're the RM for 3.5 and you've made it clear you're against the behavior I'm advocating for, I'm going to respect your decision on that and I'm not going to pursue getting it into 3.5, however I am going to pursue getting it into 3.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 20:15:05 2016 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 09 Jun 2016 00:15:05 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465431305.85.0.227831582856.issue27266@psf.upfronthosting.co.za> Nick Coghlan added the comment: As a process comment: I agree with what Victor wrote in http://haypo-notes.readthedocs.io/pep_random.html#status-of-python-3-5-2, when he suggests that we leave 3.5.2 as is for now (i.e. reverted to be consistent with 2.7 and 3.4, which favours a risk of subtle security failures in some situations over a certainty of Python failing to start in those same situations), and only reconsider what to do for 3.5.x and 2.7.x after we have agreed on an acceptable solution for 3.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 20:24:47 2016 From: report at bugs.python.org (Larry Hastings) Date: Thu, 09 Jun 2016 00:24:47 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465431887.06.0.440250605274.issue27266@psf.upfronthosting.co.za> Larry Hastings added the comment: > I'd also *STRONGLY* request that we avoid adding any new APIs in relation to this that mean "Use os.urandom" is no longer the preferred option to obtain cryptographically strong random numbers in Python. According to the documentation, os.urandom() does not actually *guarantee* cryptographically strong random numbers in Python. Indeed, it has never guaranteed this; you can check the 2.6 documentation, it says the same thing. There are debates among cryptographers about how strong the numbers are. The paper cited by Mr. Ts'o shows that the numbers can be pretty awful under Linux when the entropy pool is empty. The only way of fixing this this is by using a different API, which can block in an unbounded fashion. It's simply unreasonable to change to this API by default, because on Linux /dev/urandom is guaranteed to never block. I don't see it as an improvement to add a block= parameter to os.urandom(); the parameter behaves differently on different platforms (currently ignored on most platforms) and if implemented would make the underlying implementation and behavior far more difficult to predict and reason about. Mr. Ts'o had exactly the same problem on Linux. /dev/urandom was the preferred way of obtaining cryptographically strong random numbers. But it didn't produce them in all cases, and in order to produce them he really had to block. Instead of changing /dev/urandom so it would sometimes block, he added a new kernel API (getrandom()) which is permitted to block, and he basically left /dev/urandom alone. I see Python as facing the same problem, and I think it should solve the problem in the same way: leave os.urandom() alone and add a new function getrandom() where possible. I would support a new function in 3.6, something like random.get_cprng_bytes(n) (probably a bad name), which always returns cryptographically strong PRNG bits and is permitted to block in an unbounded fashion. The complication here is I'm not sure we can provide it on every platform; the quality of bits available from /dev/random on OS X is apparently highly debatable. (OTOH, what aspect of cryptography is not highly, endlessly, debatable? *sigh*) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 20:29:34 2016 From: report at bugs.python.org (Larry Hastings) Date: Thu, 09 Jun 2016 00:29:34 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465432174.34.0.107435972898.issue27266@psf.upfronthosting.co.za> Larry Hastings added the comment: > As a process comment: I agree with what Victor wrote in http://haypo-notes.readthedocs.io/pep_random.html#status-of-python-3-5-2, when he suggests that we leave 3.5.2 as is for now [...] I agree in principle. Certainly we all agree it'd be inappropriate to add the block parameter to 3.5.2. I only allowed the possibility of adding os.getrandom() in 3.5.2 to try and placate the authors of cryptography libraries. They could use os.getrandom() if it was available, and fall back to os.urandom() if not. Since they want the blocking behavior, that means they'd block in 3.5.2+ (they'd call getrandom), and they'd also block in 3.5.[0-1] (they'd call os.urandom() which blocks on Linux in those versions). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 20:34:01 2016 From: report at bugs.python.org (Larry Hastings) Date: Thu, 09 Jun 2016 00:34:01 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465432441.58.0.667718405182.issue27266@psf.upfronthosting.co.za> Larry Hastings added the comment: > Larry, I'm sorry but I think you're just flat wrong here and I don't know what else to say about it. Yeah, I think maybe asking Guido to make a ruling would be the right thing here. Again, I cite #25003: he implicitly ruled there that it's not permissible for os.urandom() to block on Solaris, so I think he agrees with me. But if he made a ruling naturally I'd acquiesce to it regardless of what he decided. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 20:35:18 2016 From: report at bugs.python.org (Donald Stufft) Date: Thu, 09 Jun 2016 00:35:18 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465432518.46.0.681476316715.issue27266@psf.upfronthosting.co.za> Donald Stufft added the comment: > Again, I cite #25003: he implicitly ruled there that it's not permissible for os.urandom() to block on Solaris, so I think he agrees with me. To be clear, that's an entirely different kind of blocking. That made os.urandom on Solaris behave similarly to /dev/random, where it would randomly block for all users of that API regularly. I would have made the same ruling, this blocking is not that blocking. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 21:07:04 2016 From: report at bugs.python.org (=?utf-8?b?RMSBdmlz?=) Date: Thu, 09 Jun 2016 01:07:04 +0000 Subject: [issue27179] subprocess uses wrong encoding on Windows In-Reply-To: <1464828766.51.0.809606583575.issue27179@psf.upfronthosting.co.za> Message-ID: <1465434424.79.0.411072479352.issue27179@psf.upfronthosting.co.za> D?vis added the comment: > Note that patch 3 requires setting `encoding` for even python.exe as a child process, because sys.std* default to ANSI when isatty(fd) isn't true. I've updated my patch so that Python outputs in consoles encoding for pipes too. So now in PowerShell >[Console]::OutputEncoding = [System.Text.Encoding]::UTF8 >python -c "print('?')" | Out-String ? > python -c "import subprocess; print(subprocess.getoutput('python -c ""print(\'?\')""'))" ? >[Console]::OutputEncoding = [System.Text.Encoding]::GetEncoding(775) >python -c "print('?')" | Out-String ? > python -c "import subprocess; print(subprocess.getoutput('python -c ""print(\'?\')""'))" ? > What I wish is for Python to default to using UTF-8 for its own pipe and disk file I/O. The old behavior could be selected by setting some hypothetical environment variable, such as PYTHONIOUSELOCALE. I actually don't really see need for this, specifying PYTHONIOENCODING="UTF-8" it will be used for pipes. > If subprocess defaults to the console's current codepage (when available), it would be nice to have a way to conveniently select the OEM or ANSI codepage. The codecs module could define string constants based on GetOEMCP() and GetACP(), such as codecs.CP_OEMCP (e.g. 'cp437') and codecs.CP_ACP (e.g. 'cp1252'). subprocess could import these constants on Windows. also updated in my patch and implemented something like this but IMO easier, basically "ansi" and "oem" is a valid encoding on Windows and can be used anywhere where encoding can be specified as a parameter. Look at patch to see how it's implemented. Ok, so now does my patch look acceptable? What would be issues with it? IMO it greatly improves current situation (fixes #27048 and solves #6135) and I don't see any issues with it. Things that are changed: * "ansi" and "oem" are valid encodings on Windows * console's code page is used for console and pipe (if there's no console then ANSI is used like now) * subprocess uses "ansi" for DETACHED_PROCESS and "oem" for CREATE_NEW_CONSOLE, CREATE_NO_WINDOW * encoding and errors parameters can be specified for Popen * custom parameters (including encoding and errors) can be specified for subprocess.getstatusoutput and getoutput Also if it's needed I see how easily can add support for separate encodings and errors for stdin/out/err for example with if (type(encoding) is str): encoding_stdin = encoding_stdout = encoding_stderr = encoding elif (type(encoding) is tuple): encoding_stdin, encoding_stdout, encoding_stderr = encoding else: encoding_stdin = encoding_stdout = encoding_stderr = None then could use subprocess.check_output('', encoding='oem') and subprocess.check_output('', encoding=('oem', 'ansi', 'ansi')) Known issues (present in both cases with and without my patch): * when using cmd.exe and python is outputting to pipe then for some unknown reason error happens with cmd.exe > python -c "print('\n')" | echo ECHO is on. Exception ignored in: <_io.TextIOWrapper name='' mode='w' encoding='cp775'> OSError: [Errno 22] Invalid argument It doesn't matter which code page for console is set and what is being outputted. It happens for both released 3.5.1 and repo default branch but it doesn't happen when PowerShell is used. I looked into it but didn't found why it happens, only that n = write(fd, buf, (int)count); in _Py_write_impl (fileutils.c) returns -1 and errno is EINVAL I verified that all parameters are correct fd, buf (it isn't NULL) and count (parameters are same as when running without pipe) so I've no idea what causes it. * Python corrupts characters when reading from stdin with PowerShell > Out-String -InputObject "?" | python -c "import sys; print(sys.stdin.encoding,sys.stdin.read())" cp1257 ? It happens for both released 3.5.1 and repo default branch. With my patch used encoding will be based on console's code page, but it doesn't matter because seems it gets corrupted even before it gets used. I tested it when using console encodings: oem, ansi and utf-8 and also these same with PYTHONIOENCODING too and in all cases it was corrupted, replaced with "?". I didn't looked further into this. ---------- Added file: http://bugs.python.org/file43315/subprocess_fix_encoding_v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 21:08:21 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Jun 2016 01:08:21 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465434501.2.0.686722152433.issue27266@psf.upfronthosting.co.za> STINNER Victor added the comment: About the "add block=False parameter to os.urandom()" part of the issue title: I don't really care of the exact API. It can be a new function. The parameter can be named differently. The idea is to give access to users to Linux non-blocking /dev/urandom, and do something helpful for users on platforms without non-blocing urandom. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 21:36:37 2016 From: report at bugs.python.org (=?utf-8?b?RMSBdmlz?=) Date: Thu, 09 Jun 2016 01:36:37 +0000 Subject: [issue27179] subprocess uses wrong encoding on Windows In-Reply-To: <1464828766.51.0.809606583575.issue27179@psf.upfronthosting.co.za> Message-ID: <1465436197.56.0.107181216335.issue27179@psf.upfronthosting.co.za> Changes by D?vis : Removed file: http://bugs.python.org/file43315/subprocess_fix_encoding_v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 21:36:56 2016 From: report at bugs.python.org (=?utf-8?b?RMSBdmlz?=) Date: Thu, 09 Jun 2016 01:36:56 +0000 Subject: [issue27179] subprocess uses wrong encoding on Windows In-Reply-To: <1464828766.51.0.809606583575.issue27179@psf.upfronthosting.co.za> Message-ID: <1465436216.11.0.558265285828.issue27179@psf.upfronthosting.co.za> Changes by D?vis : Added file: http://bugs.python.org/file43316/subprocess_fix_encoding_v4fixed.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 21:42:01 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 09 Jun 2016 01:42:01 +0000 Subject: [issue27066] SystemError if custom opener returns -1 In-Reply-To: <1463701849.23.0.646090431797.issue27066@psf.upfronthosting.co.za> Message-ID: <1465436521.25.0.950860926648.issue27066@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 21:50:16 2016 From: report at bugs.python.org (Larry Hastings) Date: Thu, 09 Jun 2016 01:50:16 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465437016.02.0.615317821805.issue27266@psf.upfronthosting.co.za> Larry Hastings added the comment: Victor: just to confirm, would "os.getrandom(n, block=True)" be okay with you? Do you strongly prefer adding the "block" parameter to os.urandom(), or do you not care much? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 22:01:47 2016 From: report at bugs.python.org (valdemar pavesi) Date: Thu, 09 Jun 2016 02:01:47 +0000 Subject: [issue27271] asyncio lost udp packets In-Reply-To: <1465417059.51.0.620953300582.issue27271@psf.upfronthosting.co.za> Message-ID: <1465437707.53.0.400962530299.issue27271@psf.upfronthosting.co.za> valdemar pavesi added the comment: thanks Guido I will keep working with it. I am not able to debug between socket and asyncio-read-udp. There is no bottleneck on cpu/memory or network card. I cannot write debug with this heavy udp load. if I decrease the UDP per second then this problem go away. I know when it will start dropping and i never got any drop inside the network. ( tcpdump to validate it ). I will send it to python-tulip regards! Valdemar ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 22:49:03 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 09 Jun 2016 02:49:03 +0000 Subject: [issue27272] random.Random should not read 2500 bytes from urandom In-Reply-To: <1465423096.81.0.204885224668.issue27272@psf.upfronthosting.co.za> Message-ID: <1465440543.29.0.581467319212.issue27272@psf.upfronthosting.co.za> Martin Panter added the comment: If the seed is to be based on time.time(), why not use something based on hash(time.time()) to avoid the 1/256 s resolution? If there is a practical way to get pseudo-random data from the platform, it would be better to use that, rather than cooking up our own entropy from time.time(), PID, etc. But I guess that depends on the future of os.urandom() and friends. In the meantime, limiting to os.urandom(256) seems reasonable, though I?m not a random number or cryptography expert. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 23:17:38 2016 From: report at bugs.python.org (Memeplex) Date: Thu, 09 Jun 2016 03:17:38 +0000 Subject: [issue27274] [ctypes] Allow from_pointer creation Message-ID: <1465442258.95.0.0850234987407.issue27274@psf.upfronthosting.co.za> New submission from Memeplex: This real life example is pretty terrible: (ct.c_float * self._nfeats).from_address( ct.addressof(self._vals.contents)) The alternative of casting the pointer to pointer-to-array, then pick ptr.contents is not really better. What about a from_pointer(ptr) method? Or overloading from_address to take a pointer? Or a simple shortcut to get the address pointed to by a pointer (related: https://bugs.python.org/issue26565). I think this part of ctypes api needs to get more concise and pythonic. ---------- components: ctypes messages: 267951 nosy: memeplex priority: normal severity: normal status: open title: [ctypes] Allow from_pointer creation type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 23:20:49 2016 From: report at bugs.python.org (Tim Peters) Date: Thu, 09 Jun 2016 03:20:49 +0000 Subject: [issue27272] random.Random should not read 2500 bytes from urandom In-Reply-To: <1465423096.81.0.204885224668.issue27272@psf.upfronthosting.co.za> Message-ID: <1465442449.0.0.161949003819.issue27272@psf.upfronthosting.co.za> Tim Peters added the comment: Didn't anyone here follow the discussion about the `secrets` module? PHP was crucified by security wonks for its horridly naive ways of initializing its PRNGs: https://media.blackhat.com/bh-us-12/Briefings/Argyros/BH_US_12_Argyros_PRNG_WP.pdf Please don't even think about making Python a target of similar ridicule ;-) The only sane approach is to use an _excellent_ source of randomness for initialization, and `urandom()` is the only obvious such source. While the more the merrier, I agree 2500 utterly unpredictable bytes isn't necessary. If this has to change, use the most possible without creating other problems on a major platform, but certainly no less than 128 crypto-strength bytes. -1 on any poke-and-hope gibberish trying to brew our own out of time.time(), PID, id(), etc. That stuff is easy for a malicious program to attack. That's why Python switched to using `urandom()` to begin with, before security wonks noticed how poorly most libraries handle this. It's not about supplying "enough randomness" for applications, it's about making it computationally intractable for well-funded expert attackers to out-guess. That's why urandom() is used. ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 23:23:50 2016 From: report at bugs.python.org (Memeplex) Date: Thu, 09 Jun 2016 03:23:50 +0000 Subject: [issue26565] [ctypes] Add value attribute to non basic pointers. In-Reply-To: <1458007329.36.0.71536825947.issue26565@psf.upfronthosting.co.za> Message-ID: <1465442630.92.0.978921200364.issue26565@psf.upfronthosting.co.za> Memeplex added the comment: Related: http://bugs.python.org/issue27274. Maybe ptr.toaddress? As opposed to addressof(ptr). I think ptr.address might be confusing as it's intutive meaning is closer to addressof(ptr). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 8 23:39:11 2016 From: report at bugs.python.org (Memeplex) Date: Thu, 09 Jun 2016 03:39:11 +0000 Subject: [issue27274] [ctypes] Allow from_pointer creation In-Reply-To: <1465442258.95.0.0850234987407.issue27274@psf.upfronthosting.co.za> Message-ID: <1465443551.4.0.389500188877.issue27274@psf.upfronthosting.co.za> Memeplex added the comment: I would like to add some information about my use case. Many c structs have pointers to arrays of data plus some field indicating the length of those arrays. Sometimes I need to pickle that kind of structs and a bytes object has to somehow be created from each pointer, given the length (the alternative ptr[:len] is too expensive for large arrays). So I need to cast the pointer to a ctypes array first and then convert the array to bytes (sadly, there is no way to pickle a memoryview, so a copy is unavoidable). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 00:05:03 2016 From: report at bugs.python.org (Donald Stufft) Date: Thu, 09 Jun 2016 04:05:03 +0000 Subject: [issue27272] random.Random should not read 2500 bytes from urandom In-Reply-To: <1465423096.81.0.204885224668.issue27272@psf.upfronthosting.co.za> Message-ID: <1465445103.87.0.603992360423.issue27272@psf.upfronthosting.co.za> Donald Stufft added the comment: Tim, If MT is used in any of the security sensitive contexts that paper mentions, then it doesn't matter if you seed it with a static zero or a billion bytes read from the purest of purestrain randomness, your application is broken. In other words, it doesn't matter what we seed it with, random.py (outside of SystemRandom) is vulnerable to everything said in that paper. It took me 5 minutes of googling to find https://github.com/fx5/not_random, which took 22 minutes on my iMac to generate my own copy of it's `magic_data` file, and then 15 seconds to clone the state of the MT using nothing but the output of it. This was on CPython 2.7.11 where MT is seeded with 2500 bytes off urandom. Surely we're not making engineering trade offs based off whether or not someone who doesn't understand the difference between a CSPRNG and a PRNG would make fun of us for not using a CSPRNG where it's not needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 00:17:51 2016 From: report at bugs.python.org (Sylvain Corlay) Date: Thu, 09 Jun 2016 04:17:51 +0000 Subject: [issue26955] Implement equivalent to `pip.locations.distutils_scheme` in distutils In-Reply-To: <1462378664.68.0.201238634465.issue26955@psf.upfronthosting.co.za> Message-ID: <1465445871.35.0.653214303675.issue26955@psf.upfronthosting.co.za> Sylvain Corlay added the comment: We use it in the pybind11 project. I am not sure that homebrew does anything wrong. It is just that it is the only case I am aware of where the `install_headers` command does not install headers in a subdirectory of `sysconfig.get_path('include')`. On the other hand, pip.locations.distutil_scheme provides the location used by install_headers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 00:33:55 2016 From: report at bugs.python.org (William Pitcock) Date: Thu, 09 Jun 2016 04:33:55 +0000 Subject: [issue27275] KeyError thrown by optimised collections.OrderedDict.popitem() Message-ID: <1465446835.8.0.930561202137.issue27275@psf.upfronthosting.co.za> New submission from William Pitcock: The C-based optimised version of collections.OrderedDict occasionally throws KeyErrors when deleting items. See https://github.com/mailgun/expiringdict/issues/16 for an example of this regression. Backporting 3.6's patches to 3.5.1 does not resolve the issue. :( ---------- components: Library (Lib) messages: 267957 nosy: kaniini priority: normal severity: normal status: open title: KeyError thrown by optimised collections.OrderedDict.popitem() type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 00:47:32 2016 From: report at bugs.python.org (Tim Peters) Date: Thu, 09 Jun 2016 04:47:32 +0000 Subject: [issue27272] random.Random should not read 2500 bytes from urandom In-Reply-To: <1465423096.81.0.204885224668.issue27272@psf.upfronthosting.co.za> Message-ID: <1465447652.36.0.906595574872.issue27272@psf.upfronthosting.co.za> Tim Peters added the comment: Donald, it does matter. The code you found must be using some older version of Python, because the Python 3 version of randint() uses _randbelow(), which is an accept/reject method that consumes an _unpredictable_ number of 32-bit Twister outputs. That utterly destroys the theoretical framework the code you found relies on. I know all about this, because I did extensive research during the `secrets` module discussion - Python 3 isn't systematically vulnerable to any of the attacks in the paper. Deduction of the Twister's internal state is blocked in "almost all" cases because of the accept/reject logic in _randbelow() (BTW, .choice() is of far more practical concern here than .randint(), but in Python 3 they both build on _randbelow()). Code attempting to deduce the state can't know how many Twister outputs were consumed, so can't know which bit variables in its equations are involved. It can make a relatively high-probability _guess_, but that's not good enough either: it has to get many consecutive high-probability guesses right to deduce all the bits of the Twister's very large state. The usual outcome: at least one (usually more than one) guess is wrong, and if the equation solver is careful it notices that its equations have become mutually inconsistent. Dead end. More rarely, the equations remain consistent, but the "deduced" state is pure fantasy due to a wrong guess along the way. There's nothing about this that's a mystery to me. I wrote my own solver more capable than the one you found: it can deduce full MT states quickly from partial outputs of any kind whatsoever (e.g., it only sees the bits of the form 2**i for prime i in every 7th Twister output). However, it too needs to know exactly _which_ MT partial outputs it's seeing. If it believes it's seeing every 7th, but actually sees the 8th in one case, all bets are off: the equations may become inconsistent, or they remain consistent but deliver a nonsense state. So I remain strongly -1 on any attempt to make Python's seeding stupid again. Stupid seeding makes Python vulnerable to attacks by script kiddies; no relatively sophisticated equation solvers are needed if the seeding is lame. Yes, the Twister remains unsuitable for crypto purposes. That's why the `secrets` module is being introduced. But that's no excuse for deliberately making existing naive code laughably easy to attack. And, also yes, we have made some decisions based on worst-case scenarios about naivety. That's why random switched to using urandom() to begin with. Get over it ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 00:56:11 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 09 Jun 2016 04:56:11 +0000 Subject: [issue16132] ctypes incorrectly encodes .format attribute of memory views In-Reply-To: <1349364906.03.0.586114989306.issue16132@psf.upfronthosting.co.za> Message-ID: <1465448171.55.0.48965975468.issue16132@psf.upfronthosting.co.za> Martin Panter added the comment: In Python 3.5 (since Issue 15944), you can now cast normal C-contiguous memoryviews (including ones from ctypes) to bytes: >>> a = (ctypes.c_double * 3)(1,2,3) >>> m = memoryview(a) >>> m.format '>> byteview = m.cast("B") >>> byteview.format 'B' >>> byteview[0] 0 Also, the format has changed at some point. See ' _______________________________________ From report at bugs.python.org Thu Jun 9 00:57:45 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jun 2016 04:57:45 +0000 Subject: [issue27275] KeyError thrown by optimised collections.OrderedDict.popitem() In-Reply-To: <1465446835.8.0.930561202137.issue27275@psf.upfronthosting.co.za> Message-ID: <1465448265.04.0.240923759555.issue27275@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please provide short example? ---------- nosy: +serhiy.storchaka stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 00:58:21 2016 From: report at bugs.python.org (Paul Marinescu) Date: Thu, 09 Jun 2016 04:58:21 +0000 Subject: [issue27276] FileFinder.find_spec() incompatible with finder specification Message-ID: <1465448301.41.0.520975382253.issue27276@psf.upfronthosting.co.za> New submission from Paul Marinescu: importlib.machinery.FileFinder.find_spec is incompatible with importlib.abc.MetaPathFinder.find_spec (different number of arguments). The following leads to a runtime error: loader = (importlib.machinery.SourceFileLoader, importlib.machinery.SOURCE_SUFFIXES) sys.meta_path.append(importlib.machinery.FileFinder('/', loader)) ---------- messages: 267961 nosy: paulmar priority: normal severity: normal status: open title: FileFinder.find_spec() incompatible with finder specification versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 01:00:24 2016 From: report at bugs.python.org (Paul Marinescu) Date: Thu, 09 Jun 2016 05:00:24 +0000 Subject: [issue27276] FileFinder.find_spec() incompatible with finder specification In-Reply-To: <1465448301.41.0.520975382253.issue27276@psf.upfronthosting.co.za> Message-ID: <1465448424.97.0.148455297046.issue27276@psf.upfronthosting.co.za> Changes by Paul Marinescu : ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 01:48:09 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Jun 2016 05:48:09 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465437016.02.0.615317821805.issue27266@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: IHMO we only need two functions. os.urandom() is now documented as the reference for security. So we need a new function. I proposed a new urandom() parameter, but a new function without parameter would also be ok. If os.getrandom() is directly a binding of Linux/Solaris getrandom(), I will not use it since it would not be portable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 01:51:03 2016 From: report at bugs.python.org (Larry Hastings) Date: Thu, 09 Jun 2016 05:51:03 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465451463.7.0.8290257626.issue27266@psf.upfronthosting.co.za> Larry Hastings added the comment: AFAICT, the history is, Linux added /dev/urandom, then all the other UNIXes followed suit. I've read a lot of man pages for /dev/urandom (or equivalent) on a lot of different platforms and most of them say "this was added to Linux, so we added our own version". /dev/random and getrandom() seem to be playing out the same way. Linux added getrandom() first, then Solaris added it. My bet is most of the other UNIXes will add it over the next couple years. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 02:19:08 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Jun 2016 06:19:08 +0000 Subject: [issue27267] memory leak in _ssl.c, function load_cert_chain In-Reply-To: <1465378822.97.0.0135826659877.issue27267@psf.upfronthosting.co.za> Message-ID: <20160609061905.114454.18768.4FF7F04E@psf.io> Roundup Robot added the comment: New changeset 66cd109f3f21 by Benjamin Peterson in branch '2.7': stop leaking certfile_bytes (closes #27267) https://hg.python.org/cpython/rev/66cd109f3f21 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 03:28:55 2016 From: report at bugs.python.org (Rohit Mediratta) Date: Thu, 09 Jun 2016 07:28:55 +0000 Subject: [issue27277] Fatal Python error: Segmentation fault in test_exceptions Message-ID: <1465457335.09.0.330685258307.issue27277@psf.upfronthosting.co.za> New submission from Rohit Mediratta: Fresh clone and running test_exceptions testcase caught a Seg fault. This was being run on a Centos VM. [/loc/rom/pyd/cpython] $ ./python Python 3.6.0a1+ (default:12d939477b4f, Jun 7 2016, 17:32:31) [GCC 4.4.6 20120305 (Red Hat 4.4.6-4)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> [/loc/rom/pyd/cpython] $ ./python ../coveragepy/ run --pylib Lib/test/regrtest.py test_exceptions Run tests sequentially 0:00:00 [1/1] test_exceptions Fatal Python error: Segmentation fault Current thread 0x00007fc7324d1700 (most recent call first): File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f ... Segmentation fault ---------- components: Interpreter Core messages: 267965 nosy: Rohit Mediratta priority: normal severity: normal status: open title: Fatal Python error: Segmentation fault in test_exceptions type: crash versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 03:31:26 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 09 Jun 2016 07:31:26 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465457486.59.0.377843930058.issue27266@psf.upfronthosting.co.za> Martin Panter added the comment: I dislike the ?block? term for a different reason: it suggests raising EAGAIN (= BlockingIOError). But the proposal here is actually to generate data with low entropy. In the long term, it sounds like two separate functions is the way to go. I would prefer os.urandom() to retain its 3.5.1 behaviour introduced by Issue 22181: wait for sufficient entropy. This would be consistent with other platforms. It can continue to be used by SystemRandom, secrets, etc. The documentation should be clarified to say that os.urandom() either returns data that is supposed to be ?unpredictable enough for cryptographic applications?, blocks waiting for entropy, or raises an NotImplementedError if an OS API (e.g. /dev/urandom) is missing. The other function, say os.urandom_even_with_low_entropy(), would work like the old os.urandom() on Linux. On platforms like Free BSD, I guess it could fall back to the os.urandom() that waits for entropy. ?Import random? would be changed to try this function. I wonder what we should do on Linux if /dev/urandom is unavailable and getrandom() would block. Probably raise NotImplementedError without waiting for entropy. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 03:32:45 2016 From: report at bugs.python.org (Christian Heimes) Date: Thu, 09 Jun 2016 07:32:45 +0000 Subject: [issue27272] random.Random should not read 2500 bytes from urandom In-Reply-To: <1465423096.81.0.204885224668.issue27272@psf.upfronthosting.co.za> Message-ID: <1465457565.12.0.263454374804.issue27272@psf.upfronthosting.co.za> Christian Heimes added the comment: Tim, you are saying that some methods (e.g. randint) of the MT don't fail security properties as bad as other. I'm sorry, that argument is not good enough for me. The seed() method of the MT is causing real-world problems, e.g. #25420 where 'import random' in a VM blocks forever because the Kernel's RNG state hasn't been seeded yet. I'm in favor of changing the default seed for the default random instance. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 03:41:22 2016 From: report at bugs.python.org (Christian Heimes) Date: Thu, 09 Jun 2016 07:41:22 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465458082.03.0.124652747325.issue27266@psf.upfronthosting.co.za> Christian Heimes added the comment: Can we please stop using the term "low entropy" here. It is wrong and makes my head hurt. "Running out of entropy" is an urban myth. It's about the initialization state of Kernel's internal RNG. The Kernel blocks the syscall as long as it is not confident enough about its RNG. It wants to collect a decent amount of events from different sources until it considers its RNG properly seeded. Once the RNG is seeded, you can pull as many data from the RNG as you like. It's really block_on_boot_until_kernel_rng_has_been_seeded. ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 03:42:45 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Jun 2016 07:42:45 +0000 Subject: [issue27278] py_getrandom() uses an int for syscall() result Message-ID: <1465458165.91.0.316132030988.issue27278@psf.upfronthosting.co.za> New submission from STINNER Victor: syscall() result type is long. Moreover, long type might can smaller than the size type, so we may need to add: n = Py_MIN(size, LONG_MAX); ---------- messages: 267969 nosy: haypo priority: normal severity: normal status: open title: py_getrandom() uses an int for syscall() result versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 03:54:25 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 09 Jun 2016 07:54:25 +0000 Subject: [issue27279] Add random.cryptorandom() and random.pseudorandom, deprecate os.urandom() Message-ID: <1465458864.98.0.412270875525.issue27279@psf.upfronthosting.co.za> New submission from Marc-Andre Lemburg: I propose to deprecate os.urandom() altogether due to all the issues we've discussed on all those recent tickets, see e.g. #26839, #27250, #25420. Unlike what we've told people for many years, it's clear that in the age of VMs/containers getting booted/started every few seconds, it's not longer the generic correct answer to people asking for random data, since it doesn't make a difference between crypto random and pseudo random data. By far most use cases only need pseudo random data and only very few applications require crypto random data. Instead, let's define something everybody can start to use correctly and get sane behavior on most if not all platforms. As Larry suggested in #27266, getrandom() is a good starting point for this, since it's adoption is spreading fast and it provides the necessary features we need for the two new APIs. I propose these new APIs: * random.cryptorandom() for getting OS crypto random data * random.pseudorandom() for getting OS pseudo random data Crypto applications will then clearly know that random.cryptorandom() is the right choice for them and everyone else can use random.pseudorandom(). random.cryptorandom() will guarantee that the returned data is safe for crypto applications on all platforms, blocking or raising an exception if necessary to make sure only safe data is returned. The API should get a parameter to determine whether to raise or block. random.pseudorandom() will guarantee to not block and always return random data that can be used as seeds for simulations, games, tests, monte carlo, etc. The APIs should use the getrandom() C API, where available, with appropriate default settings, i.e. blocking or raising for random.cryptorandom() and non-blocking, non-raising for random.pseudorandom(). The existing os.urandom() would then be deprecated to guide new developments to the these new APIs, getting rid of the ambiguities and problems this interface has on several platforms (see all the other tickets and https://en.wikipedia.org/wiki//dev/random for details). ---------- components: Library (Lib) messages: 267970 nosy: lemburg priority: normal severity: normal status: open title: Add random.cryptorandom() and random.pseudorandom, deprecate os.urandom() versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From mal at egenix.com Thu Jun 9 03:55:53 2016 From: mal at egenix.com (M.-A. Lemburg) Date: Thu, 9 Jun 2016 09:55:53 +0200 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465430695.0.0.555300487063.issue27266@psf.upfronthosting.co.za> References: <1465430695.0.0.555300487063.issue27266@psf.upfronthosting.co.za> Message-ID: <57592109.5060805@egenix.com> I propose to deprecate os.urandom() altogether due to all the issues we've discussed on all those recent tickets. See #27279 for details. On 09.06.2016 02:04, Nick Coghlan wrote: > I'd also *STRONGLY* request that we avoid adding any new APIs in relation to this that mean "Use os.urandom" is no longer the preferred option to obtain cryptographically strong random numbers in Python. Any such APIs can't be used in single source Python 2/3 code, they invalidate existing third party documentation like https://cryptography.io/en/latest/random-numbers/ and they invalidate answers on Q&A sites like http://stackoverflow.com/questions/20936993/how-can-i-create-a-random-number-that-is-cryptographically-secure-in-python It's easy enough to write Python2/3 code to use the new APIs for Python3, so I don't really buy that argument. As for answers on SO: it's not a definite source for anything anyway and life moves on, so eventually people will up the new changes and update older answers to the new ones. The deprecation notice will get people aware of the change. -- Marc-Andre Lemburg eGenix.com From report at bugs.python.org Thu Jun 9 03:56:01 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 09 Jun 2016 07:56:01 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465430695.0.0.555300487063.issue27266@psf.upfronthosting.co.za> Message-ID: <57592109.5060805@egenix.com> Marc-Andre Lemburg added the comment: I propose to deprecate os.urandom() altogether due to all the issues we've discussed on all those recent tickets. See #27279 for details. On 09.06.2016 02:04, Nick Coghlan wrote: > I'd also *STRONGLY* request that we avoid adding any new APIs in relation to this that mean "Use os.urandom" is no longer the preferred option to obtain cryptographically strong random numbers in Python. Any such APIs can't be used in single source Python 2/3 code, they invalidate existing third party documentation like https://cryptography.io/en/latest/random-numbers/ and they invalidate answers on Q&A sites like http://stackoverflow.com/questions/20936993/how-can-i-create-a-random-number-that-is-cryptographically-secure-in-python It's easy enough to write Python2/3 code to use the new APIs for Python3, so I don't really buy that argument. As for answers on SO: it's not a definite source for anything anyway and life moves on, so eventually people will up the new changes and update older answers to the new ones. The deprecation notice will get people aware of the change. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 03:57:30 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 09 Jun 2016 07:57:30 +0000 Subject: [issue27279] Add random.cryptorandom() and random.pseudorandom, deprecate os.urandom() In-Reply-To: <1465458864.98.0.412270875525.issue27279@psf.upfronthosting.co.za> Message-ID: <1465459050.44.0.0639330800969.issue27279@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Fleshing out the API signatures and implementation details will have to be done in a PEP. The topic is (as all the related ticket show) too complex for discussions on a bug tracker. I just opened this ticket for reference to the idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 03:57:49 2016 From: report at bugs.python.org (Larry Hastings) Date: Thu, 09 Jun 2016 07:57:49 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465459069.55.0.0220537557014.issue27266@psf.upfronthosting.co.za> Larry Hastings added the comment: > I wonder what we should do on Linux if /dev/urandom is unavailable and getrandom() would block. I don't think that happens. getrandom() actually supports two flags. The flag GRND_RANDOM tells it "behave like /dev/random". If you don't pass in GRND_RANDOM, it behaves like "/dev/urandom". So it's hard to imagine that you could have getrandom() and not have /dev/urandom. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 03:57:55 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Jun 2016 07:57:55 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465459075.04.0.420296303967.issue27266@psf.upfronthosting.co.za> STINNER Victor added the comment: I played with select() on Linux on a VM: * /dev/random: it works as expected * /dev/urandom: the device is already seen as readable even before the urandom entropy pool is initialized. It is not really surprising since, yes, read() does not block in practice To test Python before urandom is initialized, I used the init=/path/to/python trick in the boot loader. By the way, I confirm that getrandom(GRND_NONBLOCK) fails with EAGAIN before urandom is initialized. -- I'm now trying to get a non initialized /dev/urandom in a FreeBSD VM, but it seems harder... Even if single user mode, select() on /dev/urandom says that the device is ready and yes, it works to read a few bytes. Moreover, "sysctl kern.random.sys.seeded" returns 1, which confirms that urandom is already initialized. If even in single mode urandom is already is initialized in a VM, I'm not sure that FreeBSD is really impacted by the issue #26839. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 03:58:58 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 09 Jun 2016 07:58:58 +0000 Subject: [issue27250] Add os.urandom_block() In-Reply-To: <1465425723.27.0.0161891620932.issue27250@psf.upfronthosting.co.za> Message-ID: <575921BA.9050509@egenix.com> Marc-Andre Lemburg added the comment: Please also see #27279 for an alternative plan. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 04:02:15 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Jun 2016 08:02:15 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465459335.61.0.252054849071.issue27266@psf.upfronthosting.co.za> STINNER Victor added the comment: > I dislike the ?block? term for a different reason: it suggests raising EAGAIN (= BlockingIOError). But the proposal here is actually to generate data with low entropy. Since os.urandom() is part of the os module, yes, I'm suggesting to raise BlockingIOError. The caller would be responsible to handle this error and make a choice. For example, random.py can reuse its fallback on time.time(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 04:02:56 2016 From: report at bugs.python.org (Christian Heimes) Date: Thu, 09 Jun 2016 08:02:56 +0000 Subject: [issue27279] Add random.cryptorandom() and random.pseudorandom, deprecate os.urandom() In-Reply-To: <1465458864.98.0.412270875525.issue27279@psf.upfronthosting.co.za> Message-ID: <1465459376.63.0.982741089058.issue27279@psf.upfronthosting.co.za> Christian Heimes added the comment: -1 os.urandom() is just fine. Let's not confuse users and make it even harder to write secure software. ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 04:04:16 2016 From: report at bugs.python.org (Cory Benfield) Date: Thu, 09 Jun 2016 08:04:16 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465459456.84.0.760827052846.issue27266@psf.upfronthosting.co.za> Changes by Cory Benfield : ---------- nosy: +Lukasa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 04:07:01 2016 From: report at bugs.python.org (Larry Hastings) Date: Thu, 09 Jun 2016 08:07:01 +0000 Subject: [issue27279] Add random.cryptorandom() and random.pseudorandom, deprecate os.urandom() In-Reply-To: <1465458864.98.0.412270875525.issue27279@psf.upfronthosting.co.za> Message-ID: <1465459621.0.0.949649488814.issue27279@psf.upfronthosting.co.za> Larry Hastings added the comment: I +1 on new functions that are designated the best-practice places to get your pseudo-random numbers. (IDK if the best place for both is in random; maybe the crypto one should be in secrets?) To be precise: on most OSes what you're calling "crypto random data" is actually "crypto-quality pseudo-random data". Very few platforms provide genuine random data--rather, they seed a CPRNG and give you data from that. (And then the cryptographers have endless arguments about whether the CPRNG is really crypto-safe.) I'm -1 on actually deprecating os.urandom(). It should be left alone, as a thin wrapper around /dev/urandom. I imagine your cryptorandom() and pseudorandom() functions would usually be written in Python and just import and use the appropriate function on a platform-by-platform basis. ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 04:07:36 2016 From: report at bugs.python.org (SilentGhost) Date: Thu, 09 Jun 2016 08:07:36 +0000 Subject: [issue27274] [ctypes] Allow from_pointer creation In-Reply-To: <1465442258.95.0.0850234987407.issue27274@psf.upfronthosting.co.za> Message-ID: <1465459656.43.0.464074185891.issue27274@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +amaury.forgeotdarc, belopolsky, meador.inge versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 04:08:52 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Jun 2016 08:08:52 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465459732.15.0.379597736152.issue27266@psf.upfronthosting.co.za> STINNER Victor added the comment: Martin: > I wonder what we should do on Linux if /dev/urandom is unavailable and getrandom() would block. os.urandom(block=False) should raise BlockingIOError if getrandom(GRND_NONBLOCK) fails with EAGAIN and /dev/urandom is not available. Larry: > I don't think that happens. getrandom() actually supports two flags. The flag GRND_RANDOM tells it "behave like /dev/random". If you don't pass in GRND_RANDOM, it behaves like "/dev/urandom". So it's hard to imagine that you could have getrandom() and not have /dev/urandom. You can imagine a "badly configured" container or chroot where /dev or only /dev/urandom doesn't exist. When I played with chroot, it was easy to forget /dev/urandom. Since Python uses getrandom() on Linux since Python 3.5, you can imagine that a Python 3.5 user may not notice the lack of /dev/urandom in the common case (urandom initialized), but start to get errors when the container runs before urandom is initialized. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 04:10:27 2016 From: report at bugs.python.org (Larry Hastings) Date: Thu, 09 Jun 2016 08:10:27 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465459827.07.0.430053290229.issue27266@psf.upfronthosting.co.za> Larry Hastings added the comment: Fair enough. But Theodore Ts'o said on the tracker: if you call getrandom() and don't pass in GRND_RANDOM, it's equivalent to /dev/urandom. So, if getrandom is available, getrandom(flags=0) will always work and never block. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 04:11:14 2016 From: report at bugs.python.org (Christian Heimes) Date: Thu, 09 Jun 2016 08:11:14 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465459874.76.0.988827305934.issue27266@psf.upfronthosting.co.za> Christian Heimes added the comment: I'm -1 on a block=True/False parameter. It makes the API more awkward and will make people move away from os.urandom() to a self-made RNG because they perceive os.urandom() as potential blocking. Victor, you can use sysctl on all BSD and Linux to check if the RNG has been seeded. On Linux it is kernel.random.entropy_avail >= kernel.random.read_wakeup_threshold. On BSD it is kern.random.sys.seeded == 1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 04:11:37 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 09 Jun 2016 08:11:37 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465459075.04.0.420296303967.issue27266@psf.upfronthosting.co.za> Message-ID: <575924B1.1030602@egenix.com> Marc-Andre Lemburg added the comment: On 09.06.2016 09:57, STINNER Victor wrote: > > STINNER Victor added the comment: > > I played with select() on Linux on a VM: > > * /dev/random: it works as expected > * /dev/urandom: the device is already seen as readable even before the urandom entropy pool is initialized. It is not really surprising since, yes, read() does not block in practice > > To test Python before urandom is initialized, I used the init=/path/to/python trick in the boot loader. It's best to look at the code for this in Linux: http://lxr.free-electrons.com/source/drivers/char/random.c getrandom() is implemented directly on top of the two devices: http://lxr.free-electrons.com/source/drivers/char/random.c#L1601 > By the way, I confirm that getrandom(GRND_NONBLOCK) fails with EAGAIN before urandom is initialized. Right, and that's good, since it's better to let the application control what to do than to simply block. Here's a good reading on getrandom(): https://lwn.net/Articles/606141/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 04:12:03 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 09 Jun 2016 08:12:03 +0000 Subject: [issue27279] Add random.cryptorandom() and random.pseudorandom, deprecate os.urandom() In-Reply-To: <1465458864.98.0.412270875525.issue27279@psf.upfronthosting.co.za> Message-ID: <1465459923.75.0.96895385505.issue27279@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Some resources: * getrandom() man page: http://man7.org/linux/man-pages/man2/getrandom.2.html * nice readup on how getrandom() was introduced: https://lwn.net/Articles/606141/ * random devices implementation on Linux: http://lxr.free-electrons.com/source/drivers/char/random.c * getrandom() implementation on Linux: http://lxr.free-electrons.com/source/drivers/char/random.c#L1601 (built straight on opt of the device APIs) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 04:13:13 2016 From: report at bugs.python.org (William Pitcock) Date: Thu, 09 Jun 2016 08:13:13 +0000 Subject: [issue27275] KeyError thrown by optimised collections.OrderedDict.popitem() In-Reply-To: <1465446835.8.0.930561202137.issue27275@psf.upfronthosting.co.za> Message-ID: <1465459993.88.0.68836542548.issue27275@psf.upfronthosting.co.za> William Pitcock added the comment: A frequent reproducer is to run the expiringdict tests on Python 3.5.1, unfortunately I cannot come up with a testcase. Replacing use of popitem() with "del self[next(OrderedDict.__iter__(self))]" removes the KeyErrors and the structure otherwise works fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 04:14:40 2016 From: report at bugs.python.org (Cory Benfield) Date: Thu, 09 Jun 2016 08:14:40 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465460080.21.0.718158224678.issue27266@psf.upfronthosting.co.za> Cory Benfield added the comment: > But Theodore Ts'o said on the tracker: if you call getrandom() and don't pass in GRND_RANDOM, it's equivalent to /dev/urandom. So, if getrandom is available, getrandom(flags=0) will always work and never block. Can we please try to be clear about what kind of blocking we mean? getrandom(flags=0) absolutely *can* block: that's what the original issue was all about. To ensure it *never* blocks you need to call getrandom(GRND_NONBLOCK): that's why the flag exists. Put another way: - getrandom(flags=GRND_RANDOM) == /dev/random - getrandom(flags=GRND_NONBLOCK) == /dev/urandom on Linux - getrandom(flags=0) == /dev/urandom everywhere but Linux ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 04:16:25 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 09 Jun 2016 08:16:25 +0000 Subject: [issue27278] py_getrandom() uses an int for syscall() result In-Reply-To: <1465458165.91.0.316132030988.issue27278@psf.upfronthosting.co.za> Message-ID: <1465460185.11.0.490434290928.issue27278@psf.upfronthosting.co.za> Martin Panter added the comment: According to , getrandom() returns no more than 32 MiB as an int on Linux. Doesn?t that mean you can rely on syscall()?s long return value fitting in an int? Maybe just cast n = (int)sycall(...) to be explicit. But it does make sense to cap n to LONG_MAX just in case there is some strange platform where it matters :) ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 04:16:42 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Jun 2016 08:16:42 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465460202.92.0.113847940675.issue27266@psf.upfronthosting.co.za> STINNER Victor added the comment: Marc-Andre Lemburg: > I propose to deprecate os.urandom() altogether due to all the issues we've discussed on all those recent tickets. I'm sorry, but I don't understand the purpose of this change. Usually, when we deprecate something, it is in favor of a new better function. What do you propose? I read that you proposed to expose getrandom() as os.getrandom(). It would be painful to write portable code if each OS provides its own RNG function. Python has the habit of helping users by providing portables functions. Recent example: time.monotonic (PEP 418). Somehow related: non inheritable file descriptors by default (PEP 446) and retry system calls failing with EINTR (PEP 475). These changes aim to simplify the life of Python developers to reduce the subtle differences between each operating system. To me, os.urandom() is well defined. The corner case of not initialized urandom is really a corner case which only occurs in "catastrophic" cases like ("badly configured") VM or embedded devices without hardware RNG (nor RTC). When it's hard to write a reliable behaviour on all platforms, the simple solution was always to document the subtle differences between each platforms. I started to do with documenting getrandom() and the fallback on /dev/urandom for Linux: https://docs.python.org/dev/library/os.html#os.urandom -- If we cannot agree on a technical solution, a PEP is required. But please give me some time to investigate the different technical solutions before trying to take a decision. Right now, I'm investigating the options to keep the Python startup "secure" in the "urandom not initialized" case and keep os.urandom() "blocking". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 04:19:06 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Jun 2016 08:19:06 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465460346.33.0.961256978091.issue27266@psf.upfronthosting.co.za> STINNER Victor added the comment: If you didn't read it yet, I suggest you to read my summary of the issue #26839 which contains a lot of information on RNG in the case of Python: http://haypo-notes.readthedocs.io/pep_random.html It can be used to write a real PEP. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 04:19:54 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 09 Jun 2016 08:19:54 +0000 Subject: [issue27278] py_getrandom() uses an int for syscall() result In-Reply-To: <1465458165.91.0.316132030988.issue27278@psf.upfronthosting.co.za> Message-ID: <1465460394.15.0.749805521746.issue27278@psf.upfronthosting.co.za> Martin Panter added the comment: Make that INT_MAX. Or change n from an int to a Py_ssize_t. Both Linux and Solaris versions or getrandom() are documented as accepting size_t buflen. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 04:23:34 2016 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 09 Jun 2016 08:23:34 +0000 Subject: [issue27181] Add geometric mean to `statistics` module In-Reply-To: <1464901494.08.0.0111988914026.issue27181@psf.upfronthosting.co.za> Message-ID: <1465460614.79.0.993129893767.issue27181@psf.upfronthosting.co.za> Mark Dickinson added the comment: Choice of algorithm is a bit tricky here. There are a couple of obvious algorithms that work mathematically but result in significant accuracy loss in an IEEE 754 floating-point implementation: one is `exp(mean(map(log, my_numbers)))`, where the log calls can introduce significant loss of information, and the other is `prod(x**(1./len(my_numbers)) for x in my_numbers)`, where the `**(1./n)` operation similarly discards information. A better algorithm numerically is `prod(my_numbers)**(1./len(my_numbers))`, but that's likely to overflow quickly for large datasets (and/or datasets containing large values). I'd suggest something along the lines of `prod(my_numbers)**(1./len(my_numbers))`, but keeping track of the exponent of the product separately and renormalizing where necessary to avoid overflow. There are also algorithms for improved accuracy in a product, along the same lines as the algorithm used in fsum. See e.g., the paper "Accurate Floating-Point Product and Exponentiation" by Stef Graillat. [1] (I didn't know about this paper: I just saw a reference to it in a StackOverflow comment [2], which reminded me of this issue.) [1] http://www-pequan.lip6.fr/~graillat/papers/IEEE-TC-prod.pdf [2] http://stackoverflow.com/questions/37715250/safe-computation-of-geometric-mean ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 04:30:30 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 09 Jun 2016 08:30:30 +0000 Subject: [issue27279] Add random.cryptorandom() and random.pseudorandom, deprecate os.urandom() In-Reply-To: <1465459621.0.0.949649488814.issue27279@psf.upfronthosting.co.za> Message-ID: <5759291B.1000705@egenix.com> Marc-Andre Lemburg added the comment: On 09.06.2016 10:07, Larry Hastings wrote: > > I +1 on new functions that are designated the best-practice places to get your pseudo-random numbers. > > (IDK if the best place for both is in random; maybe the crypto one should be in secrets?) All up for discussion. As long as we get the separation clear, I'm fine with any location in the stdlib. > To be precise: on most OSes what you're calling "crypto random data" is actually "crypto-quality pseudo-random data". Very few platforms provide genuine random data--rather, they seed a CPRNG and give you data from that. (And then the cryptographers have endless arguments about whether the CPRNG is really crypto-safe.) Yes, I know, this should be documented in the docs for random.cryptorandom(). We might even make the available entropy available as additional API, on platforms where this is possible, or even add APIs to access the entropy daemon where available: http://egd.sourceforge.net/ (the necessary API is available via OpenSSL: http://linux.die.net/man/3/rand_egd) Some crypto applications do need to know a bit more about where the random data is coming from, e.g. for generation of root certificates and secure one time pads. > I'm -1 on actually deprecating os.urandom(). It should be left alone, as a thin wrapper around /dev/urandom. I imagine your cryptorandom() and pseudorandom() functions would usually be written in Python and just import and use the appropriate function on a platform-by-platform basis. Fair enough. I don't feel strong about this part. The main idea here was to move people away from thinking that we can fix a broken system, which is not under our control (because it's a shim on an OS device). How we implement the functions is up to debate as well. I could imaging that we expose the getrandom() function as e.g. random._getrandom() and then use this from Python where available, with fallbacks to other solutions where necessary. This would also make it possible to have similar functionality on non-CPython platforms and opens up the door for future changes without breaking applications again. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 04:32:49 2016 From: report at bugs.python.org (Eryk Sun) Date: Thu, 09 Jun 2016 08:32:49 +0000 Subject: [issue27274] [ctypes] Allow from_pointer creation In-Reply-To: <1465442258.95.0.0850234987407.issue27274@psf.upfronthosting.co.za> Message-ID: <1465461169.56.0.491626679894.issue27274@psf.upfronthosting.co.za> Eryk Sun added the comment: Probably adding from_pointer is a good idea. That said, there's a simpler way to go about getting a bytes copy for a pointer. Say that you have a pointer p for the following array: >>> a = (c_float * 3)(1, 2, 3) >>> bytes(a) b'\x00\x00\x80?\x00\x00\x00@\x00\x00@@' >>> p = POINTER(c_float)(a) IMO, the most straight-forward way to get a bytes copy is to call string_at: >>> string_at(p, sizeof(p.contents) * 3) b'\x00\x00\x80?\x00\x00\x00@\x00\x00@@ In 3.x string_at uses the FFI machinery to call the following function: static PyObject * string_at(const char *ptr, int size) { if (size == -1) return PyBytes_FromStringAndSize(ptr, strlen(ptr)); return PyBytes_FromStringAndSize(ptr, size); } The first argument can be any type accepted by c_void_p.from_param, such as a ctypes pointer/array, str, bytes, or an integer address. Alternatively, note that pointer instantiation is the same as setting the `contents` value, which accepts any ctypes data object. Here's the C code that implements this assignment: dst = (CDataObject *)value; *(void **)self->b_ptr = dst->b_ptr; The b_ptr field points at the buffer of the ctypes data object. Thus you can cast p to a char pointer without even calling the cast() function, which avoids an FFI call: >>> bp = POINTER(c_char)(p.contents) Slicing c_char and c_wchar pointers is special cased to return bytes and str, respectively. So you can slice bp to get bytes: >>> bp[:sizeof(p.contents) * 3] b'\x00\x00\x80?\x00\x00\x00@\x00\x00@@' ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 04:38:35 2016 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 09 Jun 2016 08:38:35 +0000 Subject: [issue16132] ctypes incorrectly encodes .format attribute of memory views In-Reply-To: <1349364906.03.0.586114989306.issue16132@psf.upfronthosting.co.za> Message-ID: <1465461515.94.0.0384270233743.issue16132@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 04:41:11 2016 From: report at bugs.python.org (Larry Hastings) Date: Thu, 09 Jun 2016 08:41:11 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465461671.51.0.120526515259.issue27266@psf.upfronthosting.co.za> Larry Hastings added the comment: > Can we please try to be clear about what kind of blocking we mean? getrandom(flags=0) absolutely *can* block: that's what the original issue was all about. To ensure it *never* blocks you need to call getrandom(GRND_NONBLOCK): that's why the flag exists. Thanks, I was actually confused on this issue. I thought CPython was using getrandom(GRND_RANDOM) and that's why it was blocking. But to be clear, you're right: 3.5.1 is calling getrandom(0) in all circumstances. It never passes in GRND_RANDOM and it never passes in GRND_NOBLOCK. And according to the manpage for getrandom(), getrandom(0) "blocks if the entropy pool has not yet been initialized". What I don't understand is this, from the manpage for urandom: > A read from the /dev/urandom device will not block waiting for more entropy. If there is not sufficient entropy, a pseudorandom number generator is used to create the requested bytes. If both sources are right, then /dev/urandom behaves quite differently from getrandom(0). Imagine how confused I was when Theodore Ts'o said: > First of all, if you are OK with reading from /dev/urandom, then you might as well use getrandom's GRND_NONBLOCK flag. They are logically equivalent. He wrote it. But what he said there doesn't jibe with what the manpages say. Those say that if you call getrandom(GRND_NONBLOCK) before the entropy pool has been initialized, it will return EAGAIN, but any time you read from /dev/urandom you will always get random data. ... the more I learn about this, the less I think I understand it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 04:41:16 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Jun 2016 08:41:16 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465461676.92.0.750145774103.issue27266@psf.upfronthosting.co.za> STINNER Victor added the comment: I also tested to call os.urandom() "early" in the Windows boot process in a Windows VM. Using a startup entry in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run registry key, os.urandom() works immediatly (it is able to produce 16 bytes of entropy), whereas I didn't touch the mouse, keyboard, or anything. The VM is running with qemu without RNG device (I got one, I removed it). "early" is not correct: it's late in fact, only when the desktop is opened. I should use GPEDIT.MSC to start a task before the desktop, but this command doesn't seem to be available on my Windows 8? http://stackoverflow.com/questions/614766/run-a-script-on-windows-startup-without-a-user-logged-on ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 04:42:18 2016 From: report at bugs.python.org (Christian Heimes) Date: Thu, 09 Jun 2016 08:42:18 +0000 Subject: [issue27279] Add random.cryptorandom() and random.pseudorandom, deprecate os.urandom() In-Reply-To: <5759291B.1000705@egenix.com> Message-ID: <22a76977-9745-80cb-e72b-ce325ca4bd73@cheimes.de> Christian Heimes added the comment: On 2016-06-09 10:30, Marc-Andre Lemburg wrote: > > Marc-Andre Lemburg added the comment: > > On 09.06.2016 10:07, Larry Hastings wrote: >> >> I +1 on new functions that are designated the best-practice places to get your pseudo-random numbers. >> >> (IDK if the best place for both is in random; maybe the crypto one should be in secrets?) > > All up for discussion. As long as we get the separation clear, > I'm fine with any location in the stdlib. > >> To be precise: on most OSes what you're calling "crypto random data" is actually "crypto-quality pseudo-random data". Very few platforms provide genuine random data--rather, they seed a CPRNG and give you data from that. (And then the cryptographers have endless arguments about whether the CPRNG is really crypto-safe.) > > Yes, I know, this should be documented in the docs for > random.cryptorandom(). > > We might even make the available entropy available as > additional API, on platforms where this is possible, > or even add APIs to access the entropy daemon where available: EDG has died about 15 years ago. Please don't reanimate it. > Some crypto applications do need to know a bit more about where > the random data is coming from, e.g. for generation of root > certificates and secure one time pads. No, that is not how applications deal with certificates or OTPs. When an application is really, REALLY concerned with RNG source on that level, it will never ever use Python or even a Kernel CSPRNG to generate private keys. Instead it will use a certified, industrial grade HSM (hardware security model) to offload all cryptographic operations on a secure device. ---------- _______________________________________ Python tracker _______________________________________ From mal at egenix.com Thu Jun 9 04:49:05 2016 From: mal at egenix.com (M.-A. Lemburg) Date: Thu, 9 Jun 2016 10:49:05 +0200 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465460202.92.0.113847940675.issue27266@psf.upfronthosting.co.za> References: <1465460202.92.0.113847940675.issue27266@psf.upfronthosting.co.za> Message-ID: <57592D81.9090308@egenix.com> On 09.06.2016 10:16, STINNER Victor wrote: > > STINNER Victor added the comment: > > Marc-Andre Lemburg: >> I propose to deprecate os.urandom() altogether due to all the issues we've discussed on all those recent tickets. > > I'm sorry, but I don't understand the purpose of this change. Usually, when we deprecate something, it is in favor of a new better function. What do you propose? It's mainly to get people stop thinking that we can fix os.urandom() in a way so that it works the same across platforms and to draw some attention to the main proposal in #27279 :-) I don't feel strong about the deprecation. > I read that you proposed to expose getrandom() as os.getrandom(). It would be painful to write portable code if each OS provides its own RNG function. This would be done in the two new functions, in Python and based on whatever is available on the platform. See #27279. Application writers should not have to worry about the different mechanisms used on the different platforms. > Python has the habit of helping users by providing portables functions. Recent example: time.monotonic (PEP 418). Somehow related: non inheritable file descriptors by default (PEP 446) and retry system calls failing with EINTR (PEP 475). These changes aim to simplify the life of Python developers to reduce the subtle differences between each operating system. Exactly. > To me, os.urandom() is well defined. The corner case of not initialized urandom is really a corner case which only occurs in "catastrophic" cases like ("badly configured") VM or embedded devices without hardware RNG (nor RTC). It is a corner case, but one we'll see hit us more often going forward, since booting up VMs/containers no longer is a rather rare incident. It's being used as part of the architecture of system nowadays. > When it's hard to write a reliable behaviour on all platforms, the simple solution was always to document the subtle differences between each platforms. I started to do with documenting getrandom() and the fallback on /dev/urandom for Linux: > https://docs.python.org/dev/library/os.html#os.urandom > > -- > > If we cannot agree on a technical solution, a PEP is required. Right. The topic has too many aspects to really address in a bug tracker ticket. It's better to start writing these things down in a PEP. I'm using #27279 as scratch pad for this. > But please give me some time to investigate the different technical solutions before trying to take a decision. Sure, Python 3.6 is still in the making... > Right now, I'm investigating the options to keep the Python startup "secure" in the "urandom not initialized" case and keep os.urandom() "blocking". The Python startup definitely has to be fixed, regardless of what we do with os.urandom(). This means: getting hash randomization and the random module initialized without blocking even when the entropy pool is not yet initialized. I guess the easiest way to solve this for the random module is by making the initialization lazy (as was proposed on the resp. ticket). -- Marc-Andre Lemburg eGenix.com From report at bugs.python.org Thu Jun 9 04:49:15 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 09 Jun 2016 08:49:15 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465460202.92.0.113847940675.issue27266@psf.upfronthosting.co.za> Message-ID: <57592D81.9090308@egenix.com> Marc-Andre Lemburg added the comment: On 09.06.2016 10:16, STINNER Victor wrote: > > STINNER Victor added the comment: > > Marc-Andre Lemburg: >> I propose to deprecate os.urandom() altogether due to all the issues we've discussed on all those recent tickets. > > I'm sorry, but I don't understand the purpose of this change. Usually, when we deprecate something, it is in favor of a new better function. What do you propose? It's mainly to get people stop thinking that we can fix os.urandom() in a way so that it works the same across platforms and to draw some attention to the main proposal in #27279 :-) I don't feel strong about the deprecation. > I read that you proposed to expose getrandom() as os.getrandom(). It would be painful to write portable code if each OS provides its own RNG function. This would be done in the two new functions, in Python and based on whatever is available on the platform. See #27279. Application writers should not have to worry about the different mechanisms used on the different platforms. > Python has the habit of helping users by providing portables functions. Recent example: time.monotonic (PEP 418). Somehow related: non inheritable file descriptors by default (PEP 446) and retry system calls failing with EINTR (PEP 475). These changes aim to simplify the life of Python developers to reduce the subtle differences between each operating system. Exactly. > To me, os.urandom() is well defined. The corner case of not initialized urandom is really a corner case which only occurs in "catastrophic" cases like ("badly configured") VM or embedded devices without hardware RNG (nor RTC). It is a corner case, but one we'll see hit us more often going forward, since booting up VMs/containers no longer is a rather rare incident. It's being used as part of the architecture of system nowadays. > When it's hard to write a reliable behaviour on all platforms, the simple solution was always to document the subtle differences between each platforms. I started to do with documenting getrandom() and the fallback on /dev/urandom for Linux: > https://docs.python.org/dev/library/os.html#os.urandom > > -- > > If we cannot agree on a technical solution, a PEP is required. Right. The topic has too many aspects to really address in a bug tracker ticket. It's better to start writing these things down in a PEP. I'm using #27279 as scratch pad for this. > But please give me some time to investigate the different technical solutions before trying to take a decision. Sure, Python 3.6 is still in the making... > Right now, I'm investigating the options to keep the Python startup "secure" in the "urandom not initialized" case and keep os.urandom() "blocking". The Python startup definitely has to be fixed, regardless of what we do with os.urandom(). This means: getting hash randomization and the random module initialized without blocking even when the entropy pool is not yet initialized. I guess the easiest way to solve this for the random module is by making the initialization lazy (as was proposed on the resp. ticket). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 05:06:51 2016 From: report at bugs.python.org (Christian Heimes) Date: Thu, 09 Jun 2016 09:06:51 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <57592D81.9090308@egenix.com> Message-ID: <2816eb03-1d4e-4546-10a2-cf2e6581bb5f@cheimes.de> Christian Heimes added the comment: On 2016-06-09 10:49, Marc-Andre Lemburg wrote: > It is a corner case, but one we'll see hit us more often going > forward, since booting up VMs/containers no longer is a rather > rare incident. It's being used as part of the architecture of > system nowadays. Containers are not a problem. By definition they share the Kernel with the host and therefore use the CPRNG of the host. For early boot and VM Python needs to address the problem. Neither Py_HashSecret nor the init vector of random's MT need strong cryptographic keys. Python can ask the kernel if it has initialized its RNG and then fall back to a different RNG source (e.g. srandom(3) / random(3)). For os.urandom() let's define it as non-blocking and raise an exception when it would blocks. We can safely assume that the Kernel will never block reads from its entropy source once the entropy source has been initialized. Like Py_HashSecret we can ask the Kernel for its state (on Linux: use non-blocking getrandom()). The design is simple, secure and well specified. Python's startup works under all circumstancesm os.urandom() either succeeds or fails properly and 'import random' never blocks. Christian ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 05:10:19 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Jun 2016 09:10:19 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465463419.63.0.984863724733.issue27266@psf.upfronthosting.co.za> STINNER Victor added the comment: > "early" is not correct: it's late in fact, only when the desktop is opened. I should use GPEDIT.MSC to start a task before the desktop, but this command doesn't seem to be available on my Windows 8? Oh, I found how to start a task before the user login, and os.urandom() still works: it produces 16 bytes immediatly (in 0.0 second). As FreeBSD, I'm not sure that Windows is really impacted by the issue #26839. Latest article about Windows RNG: http://eprint.iacr.org/2007/419 "Cryptanalysis of the Random Number Generator of the Windows Operating System" (2007) by Leo Dorrendorf and Zvi Gutterman and Benny Pinkas See also "Where does a Hyper-V guest get its entropy when generating a certificate authority key pair?": http://security.stackexchange.com/questions/51538/where-does-a-hyper-v-guest-get-its-entropy-when-generating-a-certificate-authori ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 05:14:21 2016 From: report at bugs.python.org (Arthur Carcano) Date: Thu, 09 Jun 2016 09:14:21 +0000 Subject: [issue27280] Paste fail in ipaddress documentation Message-ID: <1465463661.18.0.737340731231.issue27280@psf.upfronthosting.co.za> New submission from Arthur Carcano: There is a type in the `IPv6Network' constructor doc, fixed in attached patch. ---------- assignee: docs at python components: Documentation files: patch_doc_ipaddress.patch keywords: patch messages: 267999 nosy: NougatRillettes, docs at python priority: normal severity: normal status: open title: Paste fail in ipaddress documentation type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file43317/patch_doc_ipaddress.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 05:15:08 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Jun 2016 09:15:08 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465459874.76.0.988827305934.issue27266@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Christian Heimes added the comment: > I'm -1 on a block=True/False parameter. It makes the API more awkward and will make people move away from os.urandom() to a self-made RNG because they perceive os.urandom() as potential blocking. Are you against the feature of the API (function name/parameter name)? If it's just the API, could you please propose something better? > Victor, you can use sysctl on all BSD and Linux to check if the RNG has been seeded. On Linux it is kernel.random.entropy_avail >= kernel.random.read_wakeup_threshold. On BSD it is kern.random.sys.seeded == 1. I know for BSD, but I failed to find a way to get access to a FreeBSD where kern.random.sys.seeded is still zero. For Linux, is kernel.random.entropy_avail related to /dev/random? In my tests, reading from /dev/urandom never blocks even before urandom is initialized. => see msg267974 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 05:15:40 2016 From: report at bugs.python.org (Larry Hastings) Date: Thu, 09 Jun 2016 09:15:40 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465463740.69.0.0215957972177.issue27266@psf.upfronthosting.co.za> Larry Hastings added the comment: > Oh, I found how to start a task before the user login, and os.urandom() still works: it produces 16 bytes immediatly (in 0.0 second). Just to confirm: that's a fresh Windows VM, never been booted before ever? If it had ever been booted before, it might be saving its entropy pools to the hard disk at shutdown. If you do the experiment a second time with another copy of the same fresh VM, does it generate the same 16 bytes? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 05:17:28 2016 From: report at bugs.python.org (Larry Hastings) Date: Thu, 09 Jun 2016 09:17:28 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465463848.68.0.686846841423.issue27266@psf.upfronthosting.co.za> Larry Hastings added the comment: > In my tests, reading from /dev/urandom never blocks even before urandom is initialized. That's correct, and is the big difference between getrandom(0) and reading from /dev/urandom. If "the entropy pool has not been initialized" (terminology from the man pages), getrandom(0) will block, but read(/dev/urandom) will return bytes from the urandom CPRNG before it's been initialized. Which means they are some seriously low-quality not-very-random numbers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 05:18:08 2016 From: report at bugs.python.org (Cory Benfield) Date: Thu, 09 Jun 2016 09:18:08 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465463888.35.0.765145197955.issue27266@psf.upfronthosting.co.za> Cory Benfield added the comment: > Those say that if you call getrandom(GRND_NONBLOCK) before the entropy > pool has been initialized, it will return EAGAIN, but any time you read > from /dev/urandom you will always get random data. Yeah, so this is why the crypto folks were all up in arms about falling back to the /dev/urandom behaviour on Linux: Linux's /dev/urandom behaviour is really pretty dangerous. In essence, on Linux, /dev/urandom will *always* return you some bytes, and their actual quality is entirely uncertain. This means that fundamentally without interrogating the kernel state before you read, you can't really be sure that /dev/urandom is safe for what you want it to be safe for. But /dev/random isn't a suitable replacement in most cases, because /dev/random goes too far the other way: it has this hyper-paranoid notion about "entropy" that isn't really well-founded, and so sometimes it'll go on strike for a while. This is why we've been pushing to keep hold of the os.urandom() implementation that CPython 3.5 now has: it irons out one of the most annoying warts in Linux RNGs. As Ted Tso has said elsewhere in this thread, /dev/urandom only exhibits its current behaviour for backward compatibility reasons: getrandom(flags=0) is really the ideal behaviour for almost any case *except* what Python is doing at startup. Not that it needs saying again, but I'm still in favour of doing something like what Christian is suggesting, or like I suggested earlier (have os.urandom remain good, have Python internally fall back to weaker seeds for random and SipHash if it's run so early that the system hasn't started up fully yet). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 05:20:57 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Jun 2016 09:20:57 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465463888.35.0.765145197955.issue27266@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > Not that it needs saying again, but I'm still in favour of doing something like what Christian is suggesting, or like I suggested earlier (have os.urandom remain good, have Python internally fall back to weaker seeds for random and SipHash if it's run so early that the system hasn't started up fully yet). It looks like people don't read what I'm writing :-( You are just repeating the title of this issue :-) (So yes, I agree with you, since I'm proposing the same thing.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 05:21:23 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 09 Jun 2016 09:21:23 +0000 Subject: [issue27279] Add random.cryptorandom() and random.pseudorandom, deprecate os.urandom() In-Reply-To: <1465458864.98.0.412270875525.issue27279@psf.upfronthosting.co.za> Message-ID: <1465464083.4.0.24255912655.issue27279@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Some more resources for FreeBSD: * /dev/random and /dev/urandom (symlink to /dev/random) ma page: https://www.freebsd.org/cgi/man.cgi?query=random&sektion=4 * Developer discussion about /dev/random and its future from 2013: https://wiki.freebsd.org/201308DevSummit/Security/DevRandom * FreeBSD uses the Yarrow CPRNG for /dev/random: https://www.usenix.org/legacy/events/bsdcon02/full_papers/murray/murray_html/ https://www.schneier.com/academic/archives/2000/01/yarrow-160.html * FreeBSD will likely switch to the new Fortuna successor of Yarrow in an upcoming release: https://www.schneier.com/academic/fortuna/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 05:21:46 2016 From: report at bugs.python.org (Cory Benfield) Date: Thu, 09 Jun 2016 09:21:46 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465464106.88.0.531911323699.issue27266@psf.upfronthosting.co.za> Cory Benfield added the comment: > It looks like people don't read what I'm writing :-( I'm reading you, Victor, but you and I aren't disagreeing, so I'm not trying to convince you. =) I'm trying to convince Larry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 05:23:54 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Jun 2016 09:23:54 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <2816eb03-1d4e-4546-10a2-cf2e6581bb5f@cheimes.de> Message-ID: STINNER Victor added the comment: Christian Heimes: > For os.urandom() let's define it as non-blocking and raise an exception > when it would blocks. There is a lot of discussion around random in the bug tracker, it's really hard to follow :-( Please use specific issues for each idea. Making os.urandom() non-blocking and always raise an exception is not the goal of this issue. This idea explicitly makes os.urandom() blocking on Linux. I suggest you to open a new issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 05:24:04 2016 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 09 Jun 2016 09:24:04 +0000 Subject: [issue27181] Add geometric mean to `statistics` module In-Reply-To: <1464901494.08.0.0111988914026.issue27181@psf.upfronthosting.co.za> Message-ID: <1465464244.51.0.950912500459.issue27181@psf.upfronthosting.co.za> Mark Dickinson added the comment: On the other hand, apparently `exp(mean(log(...)))` is good enough for SciPy: its current implementation looks like this: def gmean(a, axis=0): a, axis = _chk_asarray(a, axis) log_a = ma.log(a) return ma.exp(log_a.mean(axis=axis)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 05:31:07 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Jun 2016 09:31:07 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465464667.03.0.253388866823.issue27266@psf.upfronthosting.co.za> STINNER Victor added the comment: Larry Hastings: > Just to confirm: that's a fresh Windows VM, never been booted before ever? If it had ever been booted before, it might be saving its entropy pools to the hard disk at shutdown. The VM was booted before. I don't see how I could schedule a task at boot, and then reboot... the new boot will obviously not be a "fresh VM". Maybe it's possible to skip entropy written on disk on FreeBSD or Windows? If not, it confirms that the issue doesn't really affect FreeBSD and Windows in practice. I read that OpenBSD is able to pass the entropy file through the boot loader. It is done before the kernel is loaded, so it doesn't matter when Python 3.5 is started, urandom will always be initialized after the first boot on OpenBSD, no? (If the first boot was able to produce enough entropy.) Maybe it's the same thing for FreeBSD. Linux has a different design, loading the entropy file from the disk comes "later" in the init process, after the kernel booted. It's not done (currently) by the boot loader. It was discussed at: http://bugs.python.org/issue26839#msg267853 > If you do the experiment a second time with another copy of the same fresh VM, does it generate the same 16 bytes? >From what I read, Windows is vulnerable the "reset" attack on the RNG when using a VM. So you can expect the same random numbers with your scenario. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 05:32:17 2016 From: report at bugs.python.org (Larry Hastings) Date: Thu, 09 Jun 2016 09:32:17 +0000 Subject: [issue27279] Add random.cryptorandom() and random.pseudorandom, deprecate os.urandom() In-Reply-To: <1465458864.98.0.412270875525.issue27279@psf.upfronthosting.co.za> Message-ID: <1465464737.54.0.240356433497.issue27279@psf.upfronthosting.co.za> Larry Hastings added the comment: > * FreeBSD will likely switch to the new Fortuna successor of Yarrow in an upcoming release: A little more information about that. FreeBSD did a major refactoring of their /dev/urandom (etc) support, which landed in October 2014: https://svnweb.freebsd.org/base?view=revision&revision=273872 This kept Yarrow but also added Fortuna. You can switch between them with a kernel option. FreeBSD 10 shipped in January 2014, so clearly this rework didn't make it in. I see several references to "let's make Fortuna the default in FreeBSD 11". FreeBSD 11 hasn't shipped yet. However, the "what's new in FreeBSD 11" wiki page doesn't mention changing this default. So I don't know whether or not it's happening for 11. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 05:46:17 2016 From: report at bugs.python.org (Marcos Dione) Date: Thu, 09 Jun 2016 09:46:17 +0000 Subject: [issue26826] Expose new copy_file_range() syscall in os module. In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za> Message-ID: <1465465577.98.0.751398431234.issue26826@psf.upfronthosting.co.za> Marcos Dione added the comment: Fixed the last comments, including comparing what was written to the original data, but only to the length of what was actually written. I'm just not sure if the way to handle the syscall not existing is ok. ---------- Added file: http://bugs.python.org/file43318/copy_file_range.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 05:53:27 2016 From: report at bugs.python.org (Christian Heimes) Date: Thu, 09 Jun 2016 09:53:27 +0000 Subject: [issue27272] random.Random should not read 2500 bytes from urandom In-Reply-To: <1465423096.81.0.204885224668.issue27272@psf.upfronthosting.co.za> Message-ID: <1465466007.33.0.309018608433.issue27272@psf.upfronthosting.co.za> Christian Heimes added the comment: New plan: * Add a new uint64 _Py_HashSecret.random_seed * On 'import random' seed random.Random() from _Py_HashSecret.random_seed + gettimeofday().tv_sec + gettimeofday().tv_usec + id(self). That way subinterpreters get a different init state. On systems with a good entropy source, _Py_HashSecret will be filled with cryptographically strong material. On early boot / VM scenarios the situation is a bit degraded but still properly good enough. It's better than to seed from a bad RNG or just from time.time(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 06:00:48 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jun 2016 10:00:48 +0000 Subject: [issue27280] Paste fail in ipaddress documentation In-Reply-To: <1465463661.18.0.737340731231.issue27280@psf.upfronthosting.co.za> Message-ID: <1465466448.42.0.972945373195.issue27280@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +pmoody _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 06:03:39 2016 From: report at bugs.python.org (SilentGhost) Date: Thu, 09 Jun 2016 10:03:39 +0000 Subject: [issue27277] Fatal Python error: Segmentation fault in test_exceptions In-Reply-To: <1465457335.09.0.330685258307.issue27277@psf.upfronthosting.co.za> Message-ID: <1465466619.5.0.160212559007.issue27277@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- components: +Tests _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 06:06:38 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Jun 2016 10:06:38 +0000 Subject: [issue27272] random.Random should not read 2500 bytes from urandom In-Reply-To: <1465466007.33.0.309018608433.issue27272@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > On 'import random' seed random.Random() from _Py_HashSecret.random_seed + gettimeofday().tv_sec + gettimeofday().tv_usec + id(self). That way subinterpreters get a different init state. Can we use os.urandom() was random.Random is instanciated manually, but use the "secret random seed" when the random module is imported? You can easily restrict the feature to workaround blocking "import random" on VM: consume the secret in the C code, and ensure that it's only used once. For example, reimplement random.Random.seed() in C (remove the Python implementation) and use the secret in C, but only the first user of seed(None) will get it. WDYT? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 06:38:26 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 09 Jun 2016 10:38:26 +0000 Subject: [issue27279] Add random.cryptorandom() and random.pseudorandom, deprecate os.urandom() In-Reply-To: <1465458864.98.0.412270875525.issue27279@psf.upfronthosting.co.za> Message-ID: <1465468706.47.0.530925084329.issue27279@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Resources for entropy gathering sources: * Kernel based devices such as /dev/random: https://en.wikipedia.org/wiki//dev/random * EGD - old entropy gathering daemon; blocks when out of entropy http://egd.sourceforge.net/ (not maintained anymore) Important here is not the original implementation, but the Unix domain socket interface, which many applications support. * PRNG - provides the EGD interface, but feeds entropy into the OpenSSL pool; essentially a CPRNG with EGD interface. http://prngd.sourceforge.net/ * Virtio RNG - paravirtualized device for passing host RNG to guest VMs (running under KVM) https://fedoraproject.org/wiki/Features/Virtio_RNG * haveged - entropy daemon which feeds entropy into the Linux /dev/random pool http://www.issihosts.com/haveged/ https://wiki.archlinux.org/index.php/Haveged Whether this is useful on VMs, is contested, due to the way haveged works (reliance on rdtsc instructions which don't work well in VMs) http://security.stackexchange.com/questions/34523/is-it-appropriate-to-use-haveged-as-a-source-of-entropy-on-virtual-machines * Hardware RNG in Raspberry Pi: https://sites.google.com/site/astudyofentropy/project-definition/raspberry-pi-internal-hardware-random-number-generator * rng-tools - provides the rngd daemon to feed entropy from hardware RNGs into the Linux /dev/random pool https://wiki.archlinux.org/index.php/Rng-tools http://linux.die.net/man/8/rngd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 06:55:45 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 09 Jun 2016 10:55:45 +0000 Subject: [issue26826] Expose new copy_file_range() syscall in os module. In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za> Message-ID: <1465469745.13.0.887165776008.issue26826@psf.upfronthosting.co.za> Martin Panter added the comment: It?s a bit ugly, but I would write the test so that it is recorded as skipped: try: os.copy_file_range(...) except OSError as err: if err.errno != ENOSYS: raise # We get to see the full exception details self.skipTest(err) # Test is recorded as skipped, not passed ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 07:01:48 2016 From: report at bugs.python.org (Donald Stufft) Date: Thu, 09 Jun 2016 11:01:48 +0000 Subject: [issue27272] random.Random should not read 2500 bytes from urandom In-Reply-To: <1465423096.81.0.204885224668.issue27272@psf.upfronthosting.co.za> Message-ID: <1465470108.72.0.261199345697.issue27272@psf.upfronthosting.co.za> Donald Stufft added the comment: If seeding from urandom was causing no problems, then I would not care if random.Random() wanted to seed from urandom, even though it doesn't need to. However it is causing problems, and thus it shouldn't. Here's another script, this one runs on Python 3.5.1 that can clone MT using nothing but it's output: https://gist.github.com/dstufft/394ea7dd8f64159df10e25a75865c03c. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 07:18:48 2016 From: report at bugs.python.org (Donald Stufft) Date: Thu, 09 Jun 2016 11:18:48 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465471128.84.0.405231087298.issue27266@psf.upfronthosting.co.za> Donald Stufft added the comment: Having os.urandom raise an error instead of blocking is OK with me. It turns an implicit error into an explicit one. However, I prefer to have it block until it has initialized it's entropy pool because that makes Linux behave similarly to all of the other major, modern OSs instead of making Linux continue to be a weird edge case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 07:26:39 2016 From: report at bugs.python.org (Larry Hastings) Date: Thu, 09 Jun 2016 11:26:39 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465471599.39.0.173884838636.issue26839@psf.upfronthosting.co.za> Larry Hastings added the comment: I just posted to python-dev and asked Guido to make a BDFL ruling. I only represented my side, both because I worried I'd do a bad job of representing *cough* literally everybody else *cough*, and because it already took me so long to write the email. All of you who disagree with me, I'd appreciate it if you'd reply to my python-dev posting and state your point of view. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 07:55:25 2016 From: report at bugs.python.org (Marcos Dione) Date: Thu, 09 Jun 2016 11:55:25 +0000 Subject: [issue26826] Expose new copy_file_range() syscall in os module. In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za> Message-ID: <1465473325.94.0.211018651519.issue26826@psf.upfronthosting.co.za> Marcos Dione added the comment: ENOSYS catching fixed. ---------- Added file: http://bugs.python.org/file43319/copy_file_range.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 07:59:05 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Thu, 09 Jun 2016 11:59:05 +0000 Subject: [issue27181] Add geometric mean to `statistics` module In-Reply-To: <1465464244.51.0.950912500459.issue27181@psf.upfronthosting.co.za> Message-ID: <20160609115850.GA27919@ando.pearwood.info> Steven D'Aprano added the comment: On Thu, Jun 09, 2016 at 09:24:04AM +0000, Mark Dickinson wrote: > On the other hand, apparently `exp(mean(log(...)))` is good enough for SciPy: Hmm, well, I don't have SciPy installed, but I've found that despite their (well-deserved) reputation, numpy (and presumably scipy) often have rather naive algorithms that can lose accuracy rather spectacularly. py> statistics.mean([1e50, 2e-50, -1e50, 2e-50]) 1e-50 py> np.mean(np.array([1e50, 2e-50, -1e50, 2e-50])) 5e-51 py> statistics.mean([1e50, 2e-50, -1e50, 2e-50]*1000) 1e-50 py> np.mean(np.array([1e50, 2e-50, -1e50, 2e-50]*1000)) 5.0000000000000002e-54 On the other hand, np is probably a hundred times (or more) faster, so I suppose accuracy/speed makes a good trade off. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 08:16:12 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jun 2016 12:16:12 +0000 Subject: [issue27140] Opcode for creating dict with constant keys In-Reply-To: <1464381640.82.0.0689379791356.issue27140@psf.upfronthosting.co.za> Message-ID: <1465474572.26.0.577221893444.issue27140@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could anyone please make a review? ---------- keywords: +needs review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 08:16:36 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jun 2016 12:16:36 +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: <1465474596.38.0.235704776296.issue17611@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 08:23:06 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jun 2016 12:23:06 +0000 Subject: [issue23867] Argument Clinic: inline parsing code for 1-argument functions In-Reply-To: <1428157476.28.0.0922120616231.issue23867@psf.upfronthosting.co.za> Message-ID: <1465474986.13.0.711711550758.issue23867@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 08:28:50 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jun 2016 12:28:50 +0000 Subject: [issue26305] Make Argument Clinic to generate PEP 7 conforming code In-Reply-To: <1454929711.55.0.893733572519.issue26305@psf.upfronthosting.co.za> Message-ID: <1465475330.97.0.5974932431.issue26305@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 08:55:29 2016 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 09 Jun 2016 12:55:29 +0000 Subject: [issue27181] Add geometric mean to `statistics` module In-Reply-To: <1464901494.08.0.0111988914026.issue27181@psf.upfronthosting.co.za> Message-ID: <1465476929.98.0.30108888839.issue27181@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Hmm, well, I don't have SciPy installed, but I've found that despite > their (well-deserved) reputation, numpy (and presumably scipy) often > have rather naive algorithms that can lose accuracy rather > spectacularly. Agreed. And as Ram Rachum hinted, there seems little point aiming to duplicate things that already exist in the de facto standard scientific libraries. So I think there's a place for a non-naive carefully computed geometric mean in the std. lib. statistics module, but I wouldn't see the point of simply adding an exp-mean-log implementation (not that anyone is advocating that). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 09:17:24 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Jun 2016 13:17:24 +0000 Subject: [issue23026] Winreg module doesn't support REG_QWORD, small DWORD doc update In-Reply-To: <1418242433.97.0.849861872047.issue23026@psf.upfronthosting.co.za> Message-ID: <20160609131649.87602.12162.538BB6C1@psf.io> Roundup Robot added the comment: New changeset 5306f27c53aa by Serhiy Storchaka in branch 'default': Regenerate Argument Clinic code for issue #23026. https://hg.python.org/cpython/rev/5306f27c53aa ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 09:17:24 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Jun 2016 13:17:24 +0000 Subject: [issue26305] Make Argument Clinic to generate PEP 7 conforming code In-Reply-To: <1454929711.55.0.893733572519.issue26305@psf.upfronthosting.co.za> Message-ID: <20160609131649.87602.51823.6C1D3C72@psf.io> Roundup Robot added the comment: New changeset eeb742d8bf9c by Serhiy Storchaka in branch '3.5': Issue #26305: Argument Clinic now escapes braces. No need to double them. https://hg.python.org/cpython/rev/eeb742d8bf9c New changeset d983c313b8f1 by Serhiy Storchaka in branch 'default': Issue #26305: Argument Clinic now escapes braces. No need to double them. https://hg.python.org/cpython/rev/d983c313b8f1 New changeset 2d7dcd8cf928 by Serhiy Storchaka in branch 'default': Issue #26305: Argument Clinic now uses braces in C code as required by PEP 7. https://hg.python.org/cpython/rev/2d7dcd8cf928 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 09:18:07 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jun 2016 13:18:07 +0000 Subject: [issue26305] Make Argument Clinic to generate PEP 7 conforming code In-Reply-To: <1454929711.55.0.893733572519.issue26305@psf.upfronthosting.co.za> Message-ID: <1465478287.04.0.0443719878346.issue26305@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 09:42:32 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jun 2016 13:42:32 +0000 Subject: [issue26243] zlib.compress level as keyword argument In-Reply-To: <1454179267.96.0.292283649228.issue26243@psf.upfronthosting.co.za> Message-ID: <1465479752.58.0.191995596395.issue26243@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The original request was for supporting level as keyword argument. Making the first argument a keyword argument was unintentional side effect (due a to the limitation of argument parsing functions). Now it is possible to support positional-only and keyword arguments in one function (see issue26282). Proposed patch makes the first argument positional-only again. ---------- nosy: +serhiy.storchaka resolution: fixed -> stage: resolved -> patch review status: closed -> open Added file: http://bugs.python.org/file43320/zlib_compress_positional_only_data.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 10:02:32 2016 From: report at bugs.python.org (Eryk Sun) Date: Thu, 09 Jun 2016 14:02:32 +0000 Subject: [issue27264] python 3.4 vs. 3.5 strftime same locale different output on Windows In-Reply-To: <1465363557.77.0.0608625622508.issue27264@psf.upfronthosting.co.za> Message-ID: <1465480952.25.0.93977612041.issue27264@psf.upfronthosting.co.za> Changes by Eryk Sun : ---------- resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 10:09:06 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 09 Jun 2016 14:09:06 +0000 Subject: [issue18027] distutils should access stat_result timestamps via .st_*time attributes In-Reply-To: <1369085242.54.0.746637584547.issue18027@psf.upfronthosting.co.za> Message-ID: <1465481346.4.0.790980316966.issue18027@psf.upfronthosting.co.za> Berker Peksag added the comment: This is a duplicate of issue 13420. ---------- nosy: +berker.peksag resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> newer() function in dep_util.py discard changes in the same second _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 10:33:33 2016 From: report at bugs.python.org (Jakub Wilk) Date: Thu, 09 Jun 2016 14:33:33 +0000 Subject: [issue13420] newer() function in dep_util.py discard changes in the same second In-Reply-To: <1321529038.98.0.0841934486822.issue13420@psf.upfronthosting.co.za> Message-ID: <1465482813.89.0.0236559624517.issue13420@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 10:52:27 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Jun 2016 14:52:27 +0000 Subject: [issue27270] 'parentheses-equality' warnings when building with clang and ccache In-Reply-To: <1465415263.12.0.159795814979.issue27270@psf.upfronthosting.co.za> Message-ID: <1465483947.81.0.904960079349.issue27270@psf.upfronthosting.co.za> STINNER Victor added the comment: clang_ccache.patch LGTM. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 11:09:16 2016 From: report at bugs.python.org (Uri Okrent) Date: Thu, 09 Jun 2016 15:09:16 +0000 Subject: [issue27281] unpickling an xmlrpc.client.Fault raises TypeError Message-ID: <1465484956.65.0.651270200726.issue27281@psf.upfronthosting.co.za> New submission from Uri Okrent: Attempting to unpickle an xmlrpc.client.Fault will raise a TypeError: >>> import xmlrpc.client as xmlrpclib >>> f = xmlrpclib.Fault(42, 'Test Fault') >>> import pickle >>> s = pickle.dumps(f) >>> pickle.loads(s) Traceback (most recent call last): File "", line 1, in TypeError: __init__() missing 2 required positional arguments: 'faultCode' and 'faultString' Apparently unpickle relies on BaseException's args attribute when reconstructing an Exception class that inherits from BaseException (Fault inherits from Exception). Unfortunately, Fault implements __init__() and does call the base class constructor, but does not pass its arguments, so Fault.args is always an empty tuple. Simply passing Fault's arguments to the base class constructor allows it to be unpickled. I've included a patch for 3.x but the issue is present in 2.x as well (the code and fix are exactly the same except in xmlrpclib.py). ---------- components: Library (Lib) files: 0001-xmlrpc.client-make-Fault-pickleable.patch keywords: patch messages: 268028 nosy: Uri Okrent priority: normal severity: normal status: open title: unpickling an xmlrpc.client.Fault raises TypeError type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43321/0001-xmlrpc.client-make-Fault-pickleable.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 11:12:48 2016 From: report at bugs.python.org (=?utf-8?q?Rados=C5=82aw_Szalski?=) Date: Thu, 09 Jun 2016 15:12:48 +0000 Subject: [issue27265] Hash of different, specific Decimals created from str is the same In-Reply-To: <1465373061.21.0.960848543198.issue27265@psf.upfronthosting.co.za> Message-ID: <1465485168.68.0.029750699569.issue27265@psf.upfronthosting.co.za> Rados?aw Szalski added the comment: Thanks for the reply and analysis, Mark. My motivation was that as a "clueless user", I shouldn't worry about how Decimals are created. Given two equal numbers, I would expect their behavior (e.g., result of a hash) to be the same as well. In this example, the behavior differs simply based on whether the Decimal was created from a string vs a float. However, since there are bound to be collisions, and the performance overhead is negligible (in case of a collision), and Python 3 solves this problem I agree this can be closed as "won't-fix". ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 11:19:27 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 09 Jun 2016 15:19:27 +0000 Subject: [issue26985] Information about CodeType in inspect documentation is outdated In-Reply-To: <1462803102.24.0.542356144335.issue26985@psf.upfronthosting.co.za> Message-ID: <1465485567.37.0.597527872935.issue26985@psf.upfronthosting.co.za> Xiang Zhang added the comment: So maybe remove the docstring entirely? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 11:33:26 2016 From: report at bugs.python.org (valdemar pavesi) Date: Thu, 09 Jun 2016 15:33:26 +0000 Subject: [issue27271] asyncio lost udp packets In-Reply-To: <1465417059.51.0.620953300582.issue27271@psf.upfronthosting.co.za> Message-ID: <1465486406.56.0.347099713691.issue27271@psf.upfronthosting.co.za> valdemar pavesi added the comment: thanks Guido and Yury I am new on python world. I was working with automation tests, sw implemented in Delphi in 199x. this year I got a python certification from University Texas Arlington University by EDX. and I already wrote 4 projects in python3 ,handling heavy traffic , one related to voice over lte simulation. thanks for all your contribution to the world without asking nothing back. regards! valdemar ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 11:36:57 2016 From: report at bugs.python.org (Memeplex) Date: Thu, 09 Jun 2016 15:36:57 +0000 Subject: [issue27274] [ctypes] Allow from_pointer creation In-Reply-To: <1465442258.95.0.0850234987407.issue27274@psf.upfronthosting.co.za> Message-ID: <1465486617.33.0.469321123048.issue27274@psf.upfronthosting.co.za> Memeplex added the comment: Thank you for the great tips, Eryk, somehow I overlooked string_at while reading the docs. Now, given that the address parameter of string_at is pretty overloaded, wouldn't it be reasonable to overload from_address the same instead of introducing from_pointer? That is, everywhere an address is expected, an address-like ctypes object would be ok. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 11:41:05 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 09 Jun 2016 15:41:05 +0000 Subject: [issue26985] Information about CodeType in inspect documentation is outdated In-Reply-To: <1462803102.24.0.542356144335.issue26985@psf.upfronthosting.co.za> Message-ID: <1465486865.26.0.822840030251.issue26985@psf.upfronthosting.co.za> Berker Peksag added the comment: "Return true if the object is a code object." should stay. We can add a short sentence to refer people to the inspect documentation for the list of co_* attributes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 11:47:55 2016 From: report at bugs.python.org (Memeplex) Date: Thu, 09 Jun 2016 15:47:55 +0000 Subject: [issue27274] [ctypes] Allow from_pointer creation In-Reply-To: <1465442258.95.0.0850234987407.issue27274@psf.upfronthosting.co.za> Message-ID: <1465487275.01.0.436194355819.issue27274@psf.upfronthosting.co.za> Memeplex added the comment: > The first argument can be any type accepted by c_void_p.from_param, such as a ctypes pointer/array, str, bytes, or an integer address. Now I see why you suggested ptr.as_void in 26565. Both issues are very related. Some functions are overloaded in the sense they automatically call c_void_p.from_param on their arguments; other functions aren't. Uniformity would dictate to treat all functions expecting an address the same way. Anyway this would not cover all use cases for ptr.toaddress or ptr.as_void or whatever it gets called. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 12:39:24 2016 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 09 Jun 2016 16:39:24 +0000 Subject: [issue27243] __aiter__ should return async iterator instead of awaitable In-Reply-To: <1465240896.52.0.994549894653.issue27243@psf.upfronthosting.co.za> Message-ID: <1465490364.16.0.0684406470632.issue27243@psf.upfronthosting.co.za> Nick Coghlan added the comment: +1 from me - my only comments were on the docs updates and one of the explanatory comments in the code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 12:42:34 2016 From: report at bugs.python.org (SilentGhost) Date: Thu, 09 Jun 2016 16:42:34 +0000 Subject: [issue27281] unpickling an xmlrpc.client.Fault raises TypeError In-Reply-To: <1465484956.65.0.651270200726.issue27281@psf.upfronthosting.co.za> Message-ID: <1465490554.3.0.961264174182.issue27281@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +loewis stage: -> patch review versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 12:44:47 2016 From: report at bugs.python.org (Tim Peters) Date: Thu, 09 Jun 2016 16:44:47 +0000 Subject: [issue27272] random.Random should not read 2500 bytes from urandom In-Reply-To: <1465423096.81.0.204885224668.issue27272@psf.upfronthosting.co.za> Message-ID: <1465490687.22.0.177423471665.issue27272@psf.upfronthosting.co.za> Tim Peters added the comment: Donald, your script appears to recreate the state from some hundreds of consecutive outputs of getrandbits(64). Well, sure - but what of it? That just requires inverting the MT's tempering permutation. You may as well note that the state can be recreated from the output of random.getstate() - in which case, your script could be a lot shorter too ;-) But that's not what real-life programs expose. All the flaws in the PHP paper related to deducing PRNG state were found in real-life code using idiomatic PHP ways of spelling choice() or randrange(), with relatively few possible outputs. Produce a program that can deduce the state, in Python 3, from - say - a million consecutive outputs of randrange(256), and _that_ would be interesting, because that would be relevant. It's easy in Python 2. But in Python 3, you can't tell from the outputs how many times MT was invoked under the covers (but, of course, you can from your contrived getrandbits(64) outputs - the C-level MT is called exactly twice for each of those outputs). In any case, the vast bulk of the PHP flaws were found by out-brute-forcing dumb PRNG initialization, which requires nothing in the way of reproducing state via reverse-engineering outputs (see Figure 13). Noting that idiomatic use of Python 3's choice() (etc) is resistant to the paper's equation-solving state-deducing approach is really just a footnote - the _point_ is that lame seeding is, all by itself, a Bad Idea. That alone was enough to crack most of the PHP programs the paper covered. As to the rest, there are already too many massive bug reports arguing about urandom()-in-general. The title of _this_ bug report suggested it may be good enough to reduce the _number_ of urandom() bytes MT initialization uses. But, so far, Victor & I appear to be the only ones who made an on-topic comment about that ;-) What do you believe? For example, do you believe it would remain a disaster if MT initialization wanted only 1 byte from urandom()? Or is 0 the only value you can live with? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 12:45:03 2016 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 09 Jun 2016 16:45:03 +0000 Subject: [issue27271] asyncio lost udp packets In-Reply-To: <1465486406.56.0.347099713691.issue27271@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: You're welcome Valdemar. It's a wonderful world, there's so much to learn! Sounds like you're on the right path. Good luck! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 12:52:13 2016 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 09 Jun 2016 16:52:13 +0000 Subject: [issue27279] Add random.cryptorandom() and random.pseudorandom, deprecate os.urandom() In-Reply-To: <1465458864.98.0.412270875525.issue27279@psf.upfronthosting.co.za> Message-ID: <1465491133.31.0.481170050469.issue27279@psf.upfronthosting.co.za> Nick Coghlan added the comment: As with other proposals to add new APIs, I think this is an overreaction to a Linux specific problem. Linux system boot could deadlock with 3.5.0 and 3.5.1 due to: - CPython startup using os.urandom() when it wasn't necessary - systemd invoking a Python script before the OS entropy pool had been initialised (which then deadlocked until the Python invocation timed out) As long as we switch the internal hash algorithm to seeding from a non-blocking random source, and also ensure that importing the random module doesn't implicitly call os.urandom, then any other software that only needs pseudorandom data can just use the random module APIs. ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 13:08:44 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 09 Jun 2016 17:08:44 +0000 Subject: [issue27281] unpickling an xmlrpc.client.Fault raises TypeError In-Reply-To: <1465484956.65.0.651270200726.issue27281@psf.upfronthosting.co.za> Message-ID: <1465492124.58.0.250183288047.issue27281@psf.upfronthosting.co.za> Berker Peksag added the comment: Looks good to me, thanks. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 13:08:56 2016 From: report at bugs.python.org (Donald Stufft) Date: Thu, 09 Jun 2016 17:08:56 +0000 Subject: [issue27272] random.Random should not read 2500 bytes from urandom In-Reply-To: <1465423096.81.0.204885224668.issue27272@psf.upfronthosting.co.za> Message-ID: <1465492136.33.0.242278897439.issue27272@psf.upfronthosting.co.za> Donald Stufft added the comment: > But that's not what real-life programs expose. Are you sure? Searching github pulls up a number of results of people calling it, but I haven't looked through them to see how/why they're calling it. > What do you believe? For example, do you believe it would remain a disaster if MT initialization wanted only 1 byte from urandom()? Or is 0 the only value you can live with? I don't really care that much what random.Random initialized with except as it related to what os.urandom does by default. Here's a copy/paste from my email to python-dev about it: * Use getrandom(GRND_NONBLOCK) for random.Random since it doesn't matter if we get cryptographically secure random numbers or not. * Switch it to use something other than a CSPRNG by default since it doesn't need that. * Instead of seeding itself from os.urandom on import, have it lazily do that the first time one of the random.rand* functions are called. * Do nothing, and say that ``import random`` relies on having the kernel's urandom pool initialized. Between these options, I have a slight preference for switching it to use a non CSPRNG, but I really don't care that much which of these options we pick. Using random.Random is not secure and none of the above options meaningfully change the security posture of something that accidently uses it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 13:14:31 2016 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 09 Jun 2016 17:14:31 +0000 Subject: [issue27282] Raise BlockingIOError in os.urandom if kernel is not ready Message-ID: <1465492471.33.0.216651020658.issue27282@psf.upfronthosting.co.za> New submission from Nick Coghlan: This proposal competes directly with #27250, #27266, and #27279 as possible long term solutions to the Linux/systemd os.urandom deadlock bug described in #26839 Rather than adding new APIs, or making os.urandom potentially blocking on Linux (as it was in 3.5.0 and 3.5.1), it instead proposes that os.urandom immediately raise BlockingIOError if the kernel entropy pool has not yet been initialised. This behaviour will mean that users attempting to gather strong entropy too early in the Linux boot process will fail rather than block, so affected scripts and programs can readily fall back to reading from /dev/urandom or using the random module APIs if they don't need cryptographically strong random data. Scripts that do need cryptographically strong random data can either poll os.urandom until it succeeds, or else fail explicitly and let their caller resolve the problem. ---------- messages: 268041 nosy: ncoghlan priority: normal severity: normal stage: needs patch status: open title: Raise BlockingIOError in os.urandom if kernel is not ready type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 13:16:33 2016 From: report at bugs.python.org (Donald Stufft) Date: Thu, 09 Jun 2016 17:16:33 +0000 Subject: [issue27282] Raise BlockingIOError in os.urandom if kernel is not ready In-Reply-To: <1465492471.33.0.216651020658.issue27282@psf.upfronthosting.co.za> Message-ID: <1465492593.38.0.691174896723.issue27282@psf.upfronthosting.co.za> Donald Stufft added the comment: This proposal is reasonable to me and solves any problems I have with the default behavior of os.urandom. ---------- nosy: +dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 13:21:54 2016 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 09 Jun 2016 17:21:54 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465492914.17.0.641667388555.issue27266@psf.upfronthosting.co.za> Nick Coghlan added the comment: Since Victor requested it, I filed #27282 to track the "raise BlockingIOError if the kernel would block" design option. The key advantage that particular model offers is that it's trivial to build a blocking version as a busy loop around the non-blocking version: def urandom_wait_for_entropy(num_bytes): while True: try: return os.urandom(num_bytes) except BlockingIOError: pass And if you ignore the problem and just call os.urandom(), you'll almost certainly be fine unless you're working with Linux boot scripts or embedded ARM devices (in which case, this point will be minor compared to the other arcana you're dealing with). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 13:24:13 2016 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 09 Jun 2016 17:24:13 +0000 Subject: [issue27282] Raise BlockingIOError in os.urandom if kernel is not ready In-Reply-To: <1465492471.33.0.216651020658.issue27282@psf.upfronthosting.co.za> Message-ID: <1465493053.79.0.828569017068.issue27282@psf.upfronthosting.co.za> Nick Coghlan added the comment: Quoting http://bugs.python.org/issue27266#msg268043: The key advantage the BlockingIOError model offers is that it's trivial to build a blocking version as a busy loop around the non-blocking version: def urandom_wait_for_entropy(num_bytes): while True: try: return os.urandom(num_bytes) except BlockingIOError: pass And if you ignore the problem and just call os.urandom(), you'll almost certainly be fine unless you're working with Linux boot scripts or embedded ARM devices (in which case, this point will be minor compared to the other arcana you're dealing with). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 13:54:33 2016 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 09 Jun 2016 17:54:33 +0000 Subject: [issue27265] Hash of different, specific Decimals created from str is the same In-Reply-To: <1465373061.21.0.960848543198.issue27265@psf.upfronthosting.co.za> Message-ID: <1465494873.23.0.58399102275.issue27265@psf.upfronthosting.co.za> Mark Dickinson added the comment: > the behavior differs simply based on whether the Decimal was created from a string vs a float That's not quite right: a Decimal object keeps no knowledge of how it was created. The behaviour differs depending on whether the value of the Decimal happens to be exactly representable as a Python float or not. That's necessary to ensure the invariant `x == y` implies `hash(x) == hash(y)` continues to hold across types (though Python 3 has a better way of doing this). So for example `Decimal('0.375')` was created from a string, but will hash equal to the exactly equal float `0.375`: noether:float-proofs mdickinson$ python2 Python 2.7.11 (default, May 1 2016, 08:20:00) [GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from decimal import Decimal >>> hash(Decimal('0.375')), hash(Decimal(0.375)) (1610579968, 1610579968) >>> hash(0.375) 1610579968 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 13:55:52 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jun 2016 17:55:52 +0000 Subject: [issue27281] unpickling an xmlrpc.client.Fault raises TypeError In-Reply-To: <1465484956.65.0.651270200726.issue27281@psf.upfronthosting.co.za> Message-ID: <1465494952.76.0.473137858564.issue27281@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 14:04:12 2016 From: report at bugs.python.org (Tim Peters) Date: Thu, 09 Jun 2016 18:04:12 +0000 Subject: [issue27272] random.Random should not read 2500 bytes from urandom In-Reply-To: <1465423096.81.0.204885224668.issue27272@psf.upfronthosting.co.za> Message-ID: <1465495452.15.0.0331170274273.issue27272@psf.upfronthosting.co.za> Tim Peters added the comment: > Searching github pulls up a number of results of people > calling it, but I haven't looked through them to see > how/why they're calling it. Sorry, I don't know what "it" refers to. Surely not to a program exposing the output of .getstate()?! Regardless, there was a long discussion about the `secrets` module at the time, and nobody found any real code vulnerable to the approaches in the PHP paper under Python 3 (contrived code, certainly - that's easy). Again, exploiting lame seeding alone sufficed to crack most of their examples, and Python's use of urandom() for seeding eliminated that approach (in Python 2 too). Examples potentially vulnerable to state equation-solving were "just like" what the PHP coders rolled by hand: uses of things like .choice() and .randrange() to build "random" strings (passwords, session tokens, ...), from relatively small alphabets. The smaller the alphabet, the more resistant Python 3 is to this approach, because the more likely ._randbelow() will invisibly skip over MT outputs. For a while an incorrect claim was mistakenly accepted: that when len(alphabet) was a power of 2, choice(alphabet) made an always-known number of MT calls. If that were true, the equation solver could deduce the state quickly in such cases, which are relatively common. But it's false - ._randbelow() is actually _most_ likely to skip over MT outputs when it's making a choice from a power-of-2 number of possibilities. That's not obvious from a glance at the code. I remain -1 on making seeding "dumb" again. But I don't care whether urandom() returns low-quality bytes in the boot-time edge cases people are upset about. They're still likely to be "better" than anything spun out of stuff like time.time(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 14:05:09 2016 From: report at bugs.python.org (Donald Stufft) Date: Thu, 09 Jun 2016 18:05:09 +0000 Subject: [issue27272] random.Random should not read 2500 bytes from urandom In-Reply-To: <1465423096.81.0.204885224668.issue27272@psf.upfronthosting.co.za> Message-ID: <1465495509.53.0.798065010295.issue27272@psf.upfronthosting.co.za> Donald Stufft added the comment: > Sorry, I don't know what "it" refers to. Surely not to a program exposing the output of .getstate()?! random.getrandbits() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 14:13:44 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jun 2016 18:13:44 +0000 Subject: [issue27281] unpickling an xmlrpc.client.Fault raises TypeError In-Reply-To: <1465484956.65.0.651270200726.issue27281@psf.upfronthosting.co.za> Message-ID: <1465496024.88.0.895146797416.issue27281@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Why you need to pickle Fault? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 14:39:11 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jun 2016 18:39:11 +0000 Subject: [issue27265] Hash of different, specific Decimals created from str is the same In-Reply-To: <1465373061.21.0.960848543198.issue27265@psf.upfronthosting.co.za> Message-ID: <1465497551.96.0.538070116851.issue27265@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Note that Decimal(0.05) != Decimal('0.05'). >>> Decimal(0.05) Decimal('0.05000000000000000277555756156289135105907917022705078125') >>> hash(Decimal(0.05)) 966367654 >>> hash(Decimal('0.05000000000000000277555756156289135105907917022705078125')) 966367654 >>> hash(0.05) 966367654 ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 14:40:11 2016 From: report at bugs.python.org (Uri Okrent) Date: Thu, 09 Jun 2016 18:40:11 +0000 Subject: [issue27281] unpickling an xmlrpc.client.Fault raises TypeError In-Reply-To: <1465484956.65.0.651270200726.issue27281@psf.upfronthosting.co.za> Message-ID: <1465497611.71.0.738148076685.issue27281@psf.upfronthosting.co.za> Uri Okrent added the comment: I'm not pickling/unpickling it directly, I'm using multiprocessing to handle queries to my server in worker processes which is using pickle to propagate exceptions raised in the worker to the parent. I could instead raise a different exception and wrap it in a Fault later (which is what I ended up doing to avoid the issue), but it seems like a case of "to-may-to" vs. "to-mah-to". Either way an Exception should be able to be propagated up to the parent in multiprocessing, whether it's my own or Fault. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 14:43:47 2016 From: report at bugs.python.org (Tim Peters) Date: Thu, 09 Jun 2016 18:43:47 +0000 Subject: [issue27272] random.Random should not read 2500 bytes from urandom In-Reply-To: <1465423096.81.0.204885224668.issue27272@psf.upfronthosting.co.za> Message-ID: <1465497827.75.0.98604769367.issue27272@psf.upfronthosting.co.za> Tim Peters added the comment: Ah! Yes, .getrandbits(N) outputs remain vulnerable to equation-solving in Python 3, for any value of N. I haven't seen any code where that matters (may be "a security hole"), but would bet some _could_ be found. There's no claim of absolute security here. To the contrary. What I'm opposed to is making _all_ naive code vulnerable to easy script-kiddie brute force attacks against lame seeding. The kinds of things people _were_ jumping up & down about were the many instances of stuff like this on the web: https://stackoverflow.com/questions/3854692/generate-password-in-python Again, I'd be impressed if you could write code under Python 3 to deduce the MT state from any number of outputs from his naive approach in reasonable time. Of course he should be using urandom() instead (as an unaccepted answer urges) - but much code plain doesn't, and in Python 3 it's resistant to any attack the PHP paper exposed. Make seeding lame again, and the easiest attacks can succeed again (the equation-solving stuff remains a footnote to me). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 15:08:42 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jun 2016 19:08:42 +0000 Subject: [issue27281] unpickling an xmlrpc.client.Fault raises TypeError In-Reply-To: <1465484956.65.0.651270200726.issue27281@psf.upfronthosting.co.za> Message-ID: <1465499322.57.0.545652256062.issue27281@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This looks reasonable. But since Fault never was unpickleable, this issue is in gray zone between bug fixing and adding new feature. The latter can be done only in new Python version. I hesitate with classification of this issue. There are a lot of other exceptions that can't be unpickled (including xmlrpc.client.ProtocolError). This may be a part of larger issue. As for the patch itself, it solves the issue. But faultCode and faultString are saved twice (this is not a large problem for multiprocessing). Test should test pickling with all possible protocols (see how other pickle tests are written). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 15:09:39 2016 From: report at bugs.python.org (=?utf-8?q?Rados=C5=82aw_Szalski?=) Date: Thu, 09 Jun 2016 19:09:39 +0000 Subject: [issue27265] Hash of different, specific Decimals created from str is the same In-Reply-To: <1465373061.21.0.960848543198.issue27265@psf.upfronthosting.co.za> Message-ID: <1465499379.58.0.851981214879.issue27265@psf.upfronthosting.co.za> Rados?aw Szalski added the comment: Thanks for the comments, you are both correct. I think that the issue is resolved now, so I'm closing this a won't fix. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 15:10:42 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jun 2016 19:10:42 +0000 Subject: [issue27265] Hash of different, specific Decimals created from str is the same In-Reply-To: <1465373061.21.0.960848543198.issue27265@psf.upfronthosting.co.za> Message-ID: <1465499442.27.0.740061806988.issue27265@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 15:13:30 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Jun 2016 19:13:30 +0000 Subject: [issue27243] __aiter__ should return async iterator instead of awaitable In-Reply-To: <1465240896.52.0.994549894653.issue27243@psf.upfronthosting.co.za> Message-ID: <20160609191321.10071.37789.10C279B7@psf.io> Roundup Robot added the comment: New changeset 93ad47d63b87 by Yury Selivanov in branch '3.5': Issue #27243: Fix __aiter__ protocol https://hg.python.org/cpython/rev/93ad47d63b87 New changeset 9ff95c30a38e by Yury Selivanov in branch 'default': Merge 3.5 (issue #27243) https://hg.python.org/cpython/rev/9ff95c30a38e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 15:14:45 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 09 Jun 2016 19:14:45 +0000 Subject: [issue27243] __aiter__ should return async iterator instead of awaitable In-Reply-To: <1465240896.52.0.994549894653.issue27243@psf.upfronthosting.co.za> Message-ID: <1465499685.17.0.224233666963.issue27243@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thanks a lot, Nick! I've merged the patch. ---------- resolution: -> fixed stage: -> resolved status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 16:01:05 2016 From: report at bugs.python.org (Uri Okrent) Date: Thu, 09 Jun 2016 20:01:05 +0000 Subject: [issue27281] unpickling an xmlrpc.client.Fault raises TypeError In-Reply-To: <1465484956.65.0.651270200726.issue27281@psf.upfronthosting.co.za> Message-ID: <1465502465.13.0.610816735591.issue27281@psf.upfronthosting.co.za> Uri Okrent added the comment: My reading of the docs leads me to lean towards bug since this seems to break the contract of BaseException API in a standard lib module: https://docs.python.org/3/library/exceptions.html#BaseException says BaseExceptions have args and with_traceback so those probably should be preserved in all standard lib inheritors. This excerpt from the tutorial also seems to imply the same: https://docs.python.org/3/tutorial/errors.html#user-defined-exceptions "In this example, the default __init__() of Exception has been overridden. The new behavior simply creates the value attribute. This replaces the default behavior of creating the args attribute." The tutorial goes out of its way to note that the default behavior of creating args has been replaced in this simple example -- i.e., one would expect args to be present. As for your other comments, should I make a similar change to other inheritors of xmlrpc.client that inherit from xmlrpc.client.Error? Should I instead completely remove Fault's constructor and just make faultCode and faultString properties so the attributes aren't duplicated (that seems like it may be dangerous)? I will update the test for pickling with the other protocols. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 16:23:35 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jun 2016 20:23:35 +0000 Subject: [issue27128] Add _PyObject_FastCall() In-Reply-To: <1464257756.81.0.101125062969.issue27128@psf.upfronthosting.co.za> Message-ID: <1465503815.33.0.681720563364.issue27128@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See issue27213. Maybe fast call with keyword arguments would avoid the creation of a dict. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 16:25:06 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 09 Jun 2016 20:25:06 +0000 Subject: [issue15657] Error in Python 3 docs for PyMethodDef In-Reply-To: <1344970966.7.0.115664419243.issue15657@psf.upfronthosting.co.za> Message-ID: <1465503906.49.0.813122239806.issue15657@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 16:30:57 2016 From: report at bugs.python.org (Uri Okrent) Date: Thu, 09 Jun 2016 20:30:57 +0000 Subject: [issue27281] unpickling an xmlrpc.client.Fault raises TypeError In-Reply-To: <1465484956.65.0.651270200726.issue27281@psf.upfronthosting.co.za> Message-ID: <1465504257.59.0.455799485046.issue27281@psf.upfronthosting.co.za> Uri Okrent added the comment: I updated the patch to improve the tests and made the same change to xmlrpc.client.ProtocolError (which was the only other place in xmlrpc.client). I'll let you decide if this patch is better despite the fact that it suffers from the same data duplication as Fault. If not, we can go back to just fixing Fault, or come up with a fancier solution entirely that doesn't duplicate data. Though, I hesitate to start getting too fancy for two reasons: 1) this module is old and stable, and 2) these are exception objects, so while the data duplication is ugly, the instances themselves should be short-lived. ---------- Added file: http://bugs.python.org/file43322/0001-xmlrpc.client-make-Errors-pickleable.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 17:26:47 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Jun 2016 21:26:47 +0000 Subject: [issue27128] Add _PyObject_FastCall() In-Reply-To: <1465503815.33.0.681720563364.issue27128@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Serhiy Storchaka added the comment: > See issue27213. Maybe fast call with keyword arguments would avoid the creation of a dict. In a first verison of my implementation, I used dictionary items stored a a list of (key, value) tuples in the same PyObject* C array than positional parameters. But in practice, it's very rare in the C code base to have to call a function with keyword parameters, but most functions expect keyword parameters as a dict. They are implemented with PyArg_ParseTupleAndKeywords() which expects a dict. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 17:37:57 2016 From: report at bugs.python.org (Brett Cannon) Date: Thu, 09 Jun 2016 21:37:57 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1465508277.23.0.838776679195.issue27186@psf.upfronthosting.co.za> Brett Cannon added the comment: Re-opening as there are several patches that got put in here that have not been applied (e.g. glossary entry, os.DirEntry, etc.). ---------- assignee: -> brett.cannon status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 17:55:25 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 09 Jun 2016 21:55:25 +0000 Subject: [issue27262] IDLE: move Aqua context menu code to maxosx In-Reply-To: <1465352483.17.0.330062690814.issue27262@psf.upfronthosting.co.za> Message-ID: <1465509325.87.0.776329863929.issue27262@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I am leaving this open to look into later adding an automated test for this to the new test_editmenu file that will be added for #5124. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 18:01:18 2016 From: report at bugs.python.org (Brett Cannon) Date: Thu, 09 Jun 2016 22:01:18 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1465509678.47.0.880386779371.issue27186@psf.upfronthosting.co.za> Brett Cannon added the comment: I'm starting to catch up on everything you all did for PEP 519 and I wanted to say thanks! It looks like everything that needs to be done has been committed, has a patch, or just needs docs. The only thing I needed to do post-commit is tweak the docstrings to be PEP 8 compatible and reword some documention and docstrings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 18:20:23 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 09 Jun 2016 22:20:23 +0000 Subject: [issue27243] __aiter__ should return async iterator instead of awaitable In-Reply-To: <1465240896.52.0.994549894653.issue27243@psf.upfronthosting.co.za> Message-ID: <1465510823.49.0.70774210867.issue27243@psf.upfronthosting.co.za> Yury Selivanov added the comment: I've also updated PEP 492: https://hg.python.org/peps/rev/fef4b9969b9d Please feel free to post to this issue if you think that I should have covered it differently or in more detail. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 18:46:01 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 09 Jun 2016 22:46:01 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1465512361.18.0.719245931934.issue5124@psf.upfronthosting.co.za> Terry J. Reedy added the comment: For 3.6, I added ttk.Entry to x11 fixer. I expanded tests to Entry and Spinboxes. I noted in a comment that tk.Entry/Spinbox, but not ttk.Entry, would not paste with generated <> event without a 0-length selection. This might be a glitch in tk, but pasting with line Entry worked fine. Will attach 3.5 and 2.7 patches as well. The 2.7 test results in ThemeChanged warnings when run as part of test_idle, but not when run alone. I am ignoring this. I will apply when tests run on x11. ---------- Added file: http://bugs.python.org/file43323/x11-paste-36.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 18:46:14 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 09 Jun 2016 22:46:14 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1465512374.45.0.500021855572.issue5124@psf.upfronthosting.co.za> Changes by Terry J. Reedy : Added file: http://bugs.python.org/file43324/x11-paste-35.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 18:46:28 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 09 Jun 2016 22:46:28 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1465512388.73.0.0903942346045.issue5124@psf.upfronthosting.co.za> Changes by Terry J. Reedy : Added file: http://bugs.python.org/file43325/x11-paste-27.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 18:58:15 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Jun 2016 22:58:15 +0000 Subject: [issue27182] PEP 519 support in the stdlib In-Reply-To: <1464887789.1.0.970652730446.issue27182@psf.upfronthosting.co.za> Message-ID: <20160609225811.101958.72032.8D5F236D@psf.io> Roundup Robot added the comment: New changeset 6239673d5e1d by Brett Cannon in branch 'default': Issue #27182: Document os.PathLike. https://hg.python.org/cpython/rev/6239673d5e1d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 19:01:59 2016 From: report at bugs.python.org (Brett Cannon) Date: Thu, 09 Jun 2016 23:01:59 +0000 Subject: [issue27283] Add a "What's New" entry for PEP 519 Message-ID: <1465513319.76.0.455637860602.issue27283@psf.upfronthosting.co.za> New submission from Brett Cannon: Issue to track the fact that I need to write the "What's New" entry once all other PEP 519-related work is finished. ---------- assignee: brett.cannon components: Documentation messages: 268066 nosy: brett.cannon priority: deferred blocker severity: normal stage: needs patch status: open title: Add a "What's New" entry for PEP 519 versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 19:02:31 2016 From: report at bugs.python.org (Brett Cannon) Date: Thu, 09 Jun 2016 23:02:31 +0000 Subject: [issue27182] PEP 519 support in the stdlib In-Reply-To: <1464887789.1.0.970652730446.issue27182@psf.upfronthosting.co.za> Message-ID: <1465513351.13.0.918161944408.issue27182@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon dependencies: +Add a "What's New" entry for PEP 519 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 19:07:33 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Jun 2016 23:07:33 +0000 Subject: [issue23693] timeit accuracy could be better In-Reply-To: <1426631677.96.0.782828300886.issue23693@psf.upfronthosting.co.za> Message-ID: <1465513653.26.0.603214409924.issue23693@psf.upfronthosting.co.za> STINNER Victor added the comment: Hi, I develop a new implementation of timeit which should be more reliable: http://perf.readthedocs.io/en/latest/ * Run 25 processes instead of just 1 * Compute average and standard deviation rather than the minimum * Don't disable the garbage collector * Skip the first timing to "warmup" the benchmark Using the minimum and disable the garbage collector is a bad practice, it is not reliable: * multiple processes are need to test different random hash functions, since Python hash function is now randomized by default in Python 3 * Linux also randomizes the address space by default (ASLR) and so the exact timing of memory accesses is different in each process My following blog post "My journey to stable benchmark, part 3 (average)" explains in depth the multiple issues of using the minimum: https://haypo.github.io/journey-to-stable-benchmark-average.html My perf module is very yound, it's still a work-in-progress. It should be better than timeit right now. It works on Python 2.7 and 3 (I tested 3.4). We may pick the best ideas into the timeit module. See also my article explaining how to tune Linux to reduce the "noise" of the operating system on microbenchmarks: https://haypo.github.io/journey-to-stable-benchmark-system.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 19:53:52 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Jun 2016 23:53:52 +0000 Subject: [issue15476] Index "code object" and link to code object definition In-Reply-To: <1343459471.56.0.370073010984.issue15476@psf.upfronthosting.co.za> Message-ID: <20160609235347.81005.417.5784C676@psf.io> Roundup Robot added the comment: New changeset 2e9aace7e10a by Tommy Beadle in branch '3.5': [Issue 15476] Make "code object" its own entry in the index https://hg.python.org/cpython/rev/2e9aace7e10a New changeset 8455bbc6b4f2 by Martin Panter in branch 'default': Issue #15476: Merge index entries from 3.5 https://hg.python.org/cpython/rev/8455bbc6b4f2 New changeset f89e96235a42 by Tommy Beadle in branch '2.7': [Issue 15476] Make "code object" its own entry in the index https://hg.python.org/cpython/rev/f89e96235a42 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 19:55:40 2016 From: report at bugs.python.org (Brian Martin) Date: Thu, 09 Jun 2016 23:55:40 +0000 Subject: [issue26556] Update expat to 2.2.1 In-Reply-To: <1457951495.3.0.910401967595.issue26556@psf.upfronthosting.co.za> Message-ID: <1465516540.66.0.62120508755.issue26556@psf.upfronthosting.co.za> Brian Martin added the comment: Per http://expat.sourceforge.net/, version 2.1.1 fixes CVE-2015-1283, not 2.2.1 as mentioned in a comment. ---------- nosy: +Brian Martin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 19:59:26 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Jun 2016 23:59:26 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <20160609235918.114609.46819.B2DEA54D@psf.io> Roundup Robot added the comment: New changeset cec1f00c538d by Brett Cannon in branch 'default': Issue #27186: Document PyOS_FSPath(). https://hg.python.org/cpython/rev/cec1f00c538d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 20:45:07 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 10 Jun 2016 00:45:07 +0000 Subject: [issue15476] Index "code object" and link to code object definition In-Reply-To: <1343459471.56.0.370073010984.issue15476@psf.upfronthosting.co.za> Message-ID: <1465519507.4.0.268400750234.issue15476@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for the patch Tommy. I think we can close this now. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 20:46:32 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Jun 2016 00:46:32 +0000 Subject: [issue8491] Need readline command and keybinding information In-Reply-To: <1271879913.89.0.268262009322.issue8491@psf.upfronthosting.co.za> Message-ID: <20160610004620.87602.33425.780D5E11@psf.io> Roundup Robot added the comment: New changeset e981a4273cf6 by Martin Panter in branch '2.7': Issue #8491: Add link to Gnu Readline configuration documentation https://hg.python.org/cpython/rev/e981a4273cf6 New changeset 5bbb021450d7 by Martin Panter in branch '3.5': Issue #8491: Add link to Gnu Readline configuration documentation https://hg.python.org/cpython/rev/5bbb021450d7 New changeset 5b904920c2d1 by Martin Panter in branch 'default': Issue #8491: Merge readline doc from 3.5 https://hg.python.org/cpython/rev/5b904920c2d1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 21:04:26 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Jun 2016 01:04:26 +0000 Subject: [issue24759] Idle: require tk 8.5 and ttk widgets, and drop unneeded code. In-Reply-To: <1438294715.65.0.966229055462.issue24759@psf.upfronthosting.co.za> Message-ID: <20160610010421.99059.41391.B4E97F2B@psf.io> Roundup Robot added the comment: New changeset 81927f86fa3a by Terry Jan Reedy in branch 'default': Issue #24759: Add test for IDLE syntax colorizoer. https://hg.python.org/cpython/rev/81927f86fa3a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 21:09:33 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Jun 2016 01:09:33 +0000 Subject: [issue24759] Idle: require tk 8.5 and ttk widgets, and drop unneeded code. In-Reply-To: <1438294715.65.0.966229055462.issue24759@psf.upfronthosting.co.za> Message-ID: <20160610010926.26088.49635.ACD17D44@psf.io> Roundup Robot added the comment: New changeset 76f831e4b806 by Terry Jan Reedy in branch 'default': Issue #24759: IDLE requires tk 8.5 and availability ttk widgets. https://hg.python.org/cpython/rev/76f831e4b806 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 21:32:44 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 Jun 2016 01:32:44 +0000 Subject: [issue24750] IDLE: Cosmetic improvements for main window In-Reply-To: <1438203302.32.0.836313086846.issue24750@psf.upfronthosting.co.za> Message-ID: <1465522364.88.0.0253651021156.issue24750@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Revised plan: use ttk in 3.6 and only 3.6. I will revise scroll patch for new file names, retest, and apply if good. ---------- assignee: -> terry.reedy stage: needs patch -> commit review versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 21:36:49 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 10 Jun 2016 01:36:49 +0000 Subject: [issue8491] Need readline command and keybinding information In-Reply-To: <1271879913.89.0.268262009322.issue8491@psf.upfronthosting.co.za> Message-ID: <1465522609.83.0.123064745829.issue8491@psf.upfronthosting.co.za> Martin Panter added the comment: For the record, I removed some trailing spaces and reworded the link in the comitted version. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 23:02:19 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 10 Jun 2016 03:02:19 +0000 Subject: [issue7356] parsing of ldconfig output in ctypes/utils.py depends on the locale In-Reply-To: <1258641188.9.0.430542588966.issue7356@psf.upfronthosting.co.za> Message-ID: <1465527739.89.0.20433399652.issue7356@psf.upfronthosting.co.za> Martin Panter added the comment: This was supposed to be fixed in 2.7 by r78979 and beb9d176503e. But those changes were made to the dead _findLib_ldconfig() function (later deleted as part of Issue 13979). I will port the changes to the live _findSoname_ldconfig() function. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 23:52:25 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Jun 2016 03:52:25 +0000 Subject: [issue7356] parsing of ldconfig output in ctypes/utils.py depends on the locale In-Reply-To: <1258641188.9.0.430542588966.issue7356@psf.upfronthosting.co.za> Message-ID: <20160610035214.120773.71573.17BD8D89@psf.io> Roundup Robot added the comment: New changeset b4839797f482 by Matthias Klose in branch '2.7': Issue #7356: ctypes.util: Make parsing of ldconfig output locale independent. https://hg.python.org/cpython/rev/b4839797f482 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 9 23:56:35 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 10 Jun 2016 03:56:35 +0000 Subject: [issue26565] [ctypes] Add value attribute to non basic pointers. In-Reply-To: <1458007329.36.0.71536825947.issue26565@psf.upfronthosting.co.za> Message-ID: <1465530995.33.0.883674987307.issue26565@psf.upfronthosting.co.za> Martin Panter added the comment: Eryk Sun?s as_void suggestion sounds similar to doing: ctypes.cast(any_pointer, ctypes.c_void_p) Why do you want the address? Perhaps it is good enough to get it from a void pointer: ctypes.cast(any_pointer, ctypes.c_void_p).value Maybe ?pointer_value? would be less confusing than ?toaddress?. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 00:15:47 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 10 Jun 2016 04:15:47 +0000 Subject: [issue20508] IndexError from ipaddress._BaseNetwork.__getitem__ has no message In-Reply-To: <1391519371.56.0.280883005316.issue20508@psf.upfronthosting.co.za> Message-ID: <1465532147.71.0.657141463839.issue20508@psf.upfronthosting.co.za> Berker Peksag added the comment: +1 for "address index out of range". The current test only covers the first IndexError. We also need to add another one for the else branch. ---------- nosy: +berker.peksag versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 00:16:38 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 10 Jun 2016 04:16:38 +0000 Subject: [issue22636] avoid using a shell in ctypes.util: replace os.popen with subprocess In-Reply-To: <1413325975.89.0.175884398711.issue22636@psf.upfronthosting.co.za> Message-ID: <1465532198.74.0.491000353669.issue22636@psf.upfronthosting.co.za> Martin Panter added the comment: Updated Python 2 patch merged with recent changes. I will commit at least the Python 3 version soon, because the existing code sets a bad example for potential additions (Issue 26439). ---------- Added file: http://bugs.python.org/file43326/ctypes_util_popen-4.py2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 00:18:16 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 Jun 2016 04:18:16 +0000 Subject: [issue27239] Make idlelib.macosx self-contained. In-Reply-To: <1465181854.1.0.00138868755932.issue27239@psf.upfronthosting.co.za> Message-ID: <1465532296.42.0.316786237521.issue27239@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 00:21:11 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 Jun 2016 04:21:11 +0000 Subject: [issue24750] IDLE: Cosmetic improvements for main window In-Reply-To: <1438203302.32.0.836313086846.issue24750@psf.upfronthosting.co.za> Message-ID: <1465532471.49.0.518864602.issue24750@psf.upfronthosting.co.za> Changes by Terry J. Reedy : Added file: http://bugs.python.org/file43327/ttk-scrollbar.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 00:26:46 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jun 2016 04:26:46 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1465532806.63.0.543349485201.issue5124@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I deliberately omitted ttk.Entry, because it doesn't have special behavior on X11. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 00:33:52 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 10 Jun 2016 04:33:52 +0000 Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX) In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za> Message-ID: <1465533232.8.0.72096957327.issue26439@psf.upfronthosting.co.za> Martin Panter added the comment: Will try to change the existing code from os.popen to subprocess (Issue 26439) to set a better example for new code like this ---------- dependencies: +avoid using a shell in ctypes.util: replace os.popen with subprocess _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 00:36:01 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 10 Jun 2016 04:36:01 +0000 Subject: [issue24617] os.makedirs()'s [mode] not correct In-Reply-To: <1436721223.66.0.229120395272.issue24617@psf.upfronthosting.co.za> Message-ID: <1465533361.46.0.927080800099.issue24617@psf.upfronthosting.co.za> Martin Panter added the comment: This version of the patch looks good to me ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 00:56:15 2016 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 10 Jun 2016 04:56:15 +0000 Subject: [issue20508] IndexError from ipaddress._BaseNetwork.__getitem__ has no message In-Reply-To: <1391519371.56.0.280883005316.issue20508@psf.upfronthosting.co.za> Message-ID: <1465534575.32.0.230373639526.issue20508@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 01:02:26 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jun 2016 05:02:26 +0000 Subject: [issue22636] avoid using a shell in ctypes.util: replace os.popen with subprocess In-Reply-To: <1413325975.89.0.175884398711.issue22636@psf.upfronthosting.co.za> Message-ID: <1465534946.9.0.445339520195.issue22636@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It looks to me that the command used in _findLib_gcc always fails. $ LANG=C LC_ALL=C gcc -Wl,-t -o ttt -lc /usr/bin/ld: mode elf_i386 /usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/crt1.o /usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/crti.o /usr/lib/gcc/i686-linux-gnu/5/crtbegin.o /lib/i386-linux-gnu/libc.so.6 (/usr/lib/i386-linux-gnu/libc_nonshared.a)elf-init.oS /lib/i386-linux-gnu/ld-linux.so.2 /lib/i386-linux-gnu/ld-linux.so.2 -lgcc_s (/usr/lib/gcc/i686-linux-gnu/5/libgcc_s.so) /lib/i386-linux-gnu/libc.so.6 /lib/i386-linux-gnu/ld-linux.so.2 -lgcc_s (/usr/lib/gcc/i686-linux-gnu/5/libgcc_s.so) /usr/lib/gcc/i686-linux-gnu/5/crtend.o /usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/crtn.o /usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/crt1.o: In function `_start': (.text+0x18): undefined reference to `main' /usr/bin/ld: link errors found, deleting executable `ttt' collect2: error: ld returned 1 exit status Is it OK? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 01:22:07 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 Jun 2016 05:22:07 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1465536127.78.0.719796395268.issue5124@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I presume then that the tests pass on Linux with TEntry removed. I take this as repudiation of the 'X11' behavior by the tk maintainers, and as support for changing the old widgets. Having different paste behavior in text and entry widgets, or even different entry widgets (in the same release of IDLE, when some but not all 'Entry's have been converted) would be pretty bad. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 01:22:39 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 10 Jun 2016 05:22:39 +0000 Subject: [issue22636] avoid using a shell in ctypes.util: replace os.popen with subprocess In-Reply-To: <1413325975.89.0.175884398711.issue22636@psf.upfronthosting.co.za> Message-ID: <1465536159.53.0.618101969165.issue22636@psf.upfronthosting.co.za> Martin Panter added the comment: Yes it is okay. The code is compiling a dummy file without main(), just to see what libraries GCC tries to link with it. It is only interested in extracting the line matching *libc.so.*, which in your case should be /lib/i386-linux-gnu/libc.so.6 So you should find that ctypes.util._findLib_gcc("c") still returns this path, even though the compile command technically fails. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 01:37:40 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 10 Jun 2016 05:37:40 +0000 Subject: [issue26868] Document PyModule_AddObject's behavior on error In-Reply-To: <1461735404.8.0.653639688918.issue26868@psf.upfronthosting.co.za> Message-ID: <1465537060.96.0.368636153489.issue26868@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the review Serhiy. Here is an updated patch. ---------- Added file: http://bugs.python.org/file43328/issue26868_v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 01:42:25 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 10 Jun 2016 05:42:25 +0000 Subject: [issue27243] __aiter__ should return async iterator instead of awaitable In-Reply-To: <1465240896.52.0.994549894653.issue27243@psf.upfronthosting.co.za> Message-ID: <1465537345.2.0.589998615794.issue27243@psf.upfronthosting.co.za> Martin Panter added the comment: Test suite emits a new warning, and fails under python -Werror: ====================================================================== ERROR: test_readline (test.test_asyncio.test_pep492.StreamReaderTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/media/disk/home/proj/python/cpython/Lib/test/test_asyncio/test_pep492.py", line 89, in test_readline data = self.loop.run_until_complete(reader()) File "/media/disk/home/proj/python/cpython/Lib/asyncio/base_events.py", line 387, in run_until_complete return future.result() File "/media/disk/home/proj/python/cpython/Lib/asyncio/futures.py", line 274, in result raise self._exception File "/media/disk/home/proj/python/cpython/Lib/asyncio/tasks.py", line 239, in _step result = coro.send(None) File "/media/disk/home/proj/python/cpython/Lib/test/test_asyncio/test_pep492.py", line 85, in reader async for line in stream: PendingDeprecationWarning: 'StreamReader' implements legacy __aiter__ protocol; __aiter__ should return an asynchronous iterator, not awaitable ---------- nosy: +martin.panter status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 01:44:44 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 10 Jun 2016 05:44:44 +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: <1465537484.41.0.319354327806.issue16484@psf.upfronthosting.co.za> Martin Panter added the comment: Kaushik or David (or anyone else), does you have an idea of how to fix the Windows tests? It would be good to make the buildbots healthy again, then it is easier to see new failures in Windows. ---------- priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 01:56:23 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 10 Jun 2016 05:56:23 +0000 Subject: [issue15657] Error in Python 3 docs for PyMethodDef In-Reply-To: <1344970966.7.0.115664419243.issue15657@psf.upfronthosting.co.za> Message-ID: <1465538183.65.0.456560062535.issue15657@psf.upfronthosting.co.za> Berker Peksag added the comment: I'm going to delete (but note that :const:`METH_KEYWORDS` alone is equivalent to ``METH_VARARGS | METH_KEYWORDS``) from Doc/c-api/structures.rst in 3.5. Then change the value of METH_KEYWORDS from 0x0002 to 0x0003 in 3.6. Thanks for the review Serhiy. ---------- versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 01:58:23 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Jun 2016 05:58:23 +0000 Subject: [issue22636] avoid using a shell in ctypes.util: replace os.popen with subprocess In-Reply-To: <1465536159.53.0.618101969165.issue22636@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Maybe the failure should be explained in a comment? (Sorry I din't read the patch.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 02:07:57 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 10 Jun 2016 06:07:57 +0000 Subject: [issue19930] os.makedirs('dir1/dir2', 0) always fails In-Reply-To: <1386500945.84.0.693179822476.issue19930@psf.upfronthosting.co.za> Message-ID: <1465538877.21.0.751909606218.issue19930@psf.upfronthosting.co.za> Martin Panter added the comment: I?ve never considered this sort of scenario properly, so I don?t know if leaving the default mode for the parent directories is the best way or not. The obvious but more complicated alternative would be to call chmod() on all the new directories in a second step. Anyway, if we are going to make any change, it should be documented. And I would say the current patch changes behaviour, so is probably not applicable as a bug fix. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 02:20:24 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 10 Jun 2016 06:20:24 +0000 Subject: [issue22636] avoid using a shell in ctypes.util: replace os.popen with subprocess In-Reply-To: <1413325975.89.0.175884398711.issue22636@psf.upfronthosting.co.za> Message-ID: <1465539624.58.0.809233454989.issue22636@psf.upfronthosting.co.za> Martin Panter added the comment: Yes a comment sounds like a good idea. Here is a new Py 3 patch. ---------- Added file: http://bugs.python.org/file43329/ctypes_util_popen-5.py3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 02:29:44 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 10 Jun 2016 06:29:44 +0000 Subject: [issue18802] ipaddress documentation errors In-Reply-To: <1377118857.87.0.169407991036.issue18802@psf.upfronthosting.co.za> Message-ID: <1465540184.73.0.149933096777.issue18802@psf.upfronthosting.co.za> Berker Peksag added the comment: > * The IPv[46]Network.hostmask property is wrongly called "host mask" > (with a space!) in the docs This one has already been fixed in 4f8ad9a4193f. ---------- nosy: +berker.peksag versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 02:46:34 2016 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 10 Jun 2016 06:46:34 +0000 Subject: [issue27140] Opcode for creating dict with constant keys In-Reply-To: <1464381640.82.0.0689379791356.issue27140@psf.upfronthosting.co.za> Message-ID: <1465541194.35.0.788211545776.issue27140@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Does this change break this function? def subtle(): one = {-0. : 'a', -1: 'b'} two = {0. : 'a', -1: 'b'} assert all(math.copysign(1, x) < 0 for x in one) assert any(math.copysign(1, x) > 0 for x in two) Perhaps you should restrict yourself to strings... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 02:54:16 2016 From: report at bugs.python.org (Rohit Mediratta) Date: Fri, 10 Jun 2016 06:54:16 +0000 Subject: [issue27277] Fatal Python error: Segmentation fault in test_exceptions In-Reply-To: <1465457335.09.0.330685258307.issue27277@psf.upfronthosting.co.za> Message-ID: <1465541656.94.0.635235282099.issue27277@psf.upfronthosting.co.za> Rohit Mediratta added the comment: Debugged with gdb and found the following (gdb) run ../coveragepy/ run --pylib Lib/test/regrtest.py test_exceptions Starting program: /local/romedira/pydev/cpython/python ../coveragepy/ run --pylib Lib/test/regrtest.py test_exceptions [Thread debugging using libthread_db enabled] Run tests sequentially 0:00:00 [1/1] test_exceptions Program received signal SIGSEGV, Segmentation fault. 0x00000000005bf1e8 in PyEval_EvalFrameEx (f=Cannot access memory at address 0x7fffff7fd438 ) at Python/ceval.c:798 798 { Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.80.el6_3.6.x86_64 keyutils-libs-1.4-4.el6.x86_64 krb5-libs-1.9-33.el6_3.3.x86_64 libcom_err-1.41.12-12.el6.x86_64 libselinux-2.0.94-5.3.el6.x86_64 openssl-1.0.1e-16.el6_5.1.x86_64 zlib-1.2.3-29.el6.x86_64 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 02:58:16 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jun 2016 06:58:16 +0000 Subject: [issue22636] avoid using a shell in ctypes.util: replace os.popen with subprocess In-Reply-To: <1413325975.89.0.175884398711.issue22636@psf.upfronthosting.co.za> Message-ID: <1465541896.48.0.058079225781.issue22636@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: ctypes_util_popen-5.py3.patch LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 03:16:58 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jun 2016 07:16:58 +0000 Subject: [issue27140] Opcode for creating dict with constant keys In-Reply-To: <1464381640.82.0.0689379791356.issue27140@psf.upfronthosting.co.za> Message-ID: <1465543018.46.0.561122238553.issue27140@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I didn't test, but I'm sure this change doesn't break this function. Otherwise functions containing (0.0, 1) and (-0.0, -1) would be broken. Actually they were broken until recently Victor fixed this bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 03:20:35 2016 From: report at bugs.python.org (David Kirkby) Date: Fri, 10 Jun 2016 07:20:35 +0000 Subject: [issue27284] some new stuff Message-ID: <0000e385b480$ca82ba3a$884d3fbd$@onetel.net> New submission from David Kirkby: Hey, Don't miss up this new stuff, you're going to be delighted, read more here david.kirkby at onetel.net ---------- messages: 268100 nosy: drkirkby priority: normal severity: normal status: open title: some new stuff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 03:22:56 2016 From: report at bugs.python.org (Eryk Sun) Date: Fri, 10 Jun 2016 07:22:56 +0000 Subject: [issue27284] some new stuff Message-ID: <1465543376.31.0.0630206370224.issue27284@psf.upfronthosting.co.za> Changes by Eryk Sun : ---------- Removed message: http://bugs.python.org/msg268100 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 03:28:31 2016 From: report at bugs.python.org (Eryk Sun) Date: Fri, 10 Jun 2016 07:28:31 +0000 Subject: [issue27284] some new stuff Message-ID: <1465543711.47.0.188534594418.issue27284@psf.upfronthosting.co.za> Changes by Eryk Sun : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 03:29:59 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jun 2016 07:29:59 +0000 Subject: [issue19930] os.makedirs('dir1/dir2', 0) always fails In-Reply-To: <1386500945.84.0.693179822476.issue19930@psf.upfronthosting.co.za> Message-ID: <1465543799.92.0.810905832726.issue19930@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > The obvious but more complicated alternative would be to call chmod() on all the new directories in a second step. This is dangerous, because if you create read-only or unlistable directory, you couldn't remove it without changing the permission of parent directory. shutil.rmtree() would fail. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 03:33:07 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Fri, 10 Jun 2016 07:33:07 +0000 Subject: [issue27277] Fatal Python error: Segmentation fault in test_exceptions In-Reply-To: <1465457335.09.0.330685258307.issue27277@psf.upfronthosting.co.za> Message-ID: <1465543987.23.0.815145401775.issue27277@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: This test asserts that indefinite recursion causes a RecursionError, but such recursion can instead segfault if the amount of stack space available is less than Python's recursion limit (sys.getrecursionlimit()). Are you using any unusual settings for the recursion limit? Perhaps the solution here is to have CPython use a lower default recursion limit on your platform. ---------- nosy: +Jelle Zijlstra _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 03:39:32 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 10 Jun 2016 07:39:32 +0000 Subject: [issue27284] Spam Message-ID: <1465544372.69.0.461612830839.issue27284@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- title: some new stuff -> Spam _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 03:40:28 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 10 Jun 2016 07:40:28 +0000 Subject: [issue27284] Spam Message-ID: <1465544428.71.0.991350127029.issue27284@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: -drkirkby _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 03:48:39 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jun 2016 07:48:39 +0000 Subject: [issue27140] Opcode for creating dict with constant keys In-Reply-To: <1464381640.82.0.0689379791356.issue27140@psf.upfronthosting.co.za> Message-ID: <1465544919.12.0.930460396524.issue27140@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I have just tested. BUILD_CONST_KEY_MAP doesn't used in it, because at this time -0. still is not a constant, but an expression (negation of 0.). With -0 it doesn't work too. $ ./python -m dis {0: 1, 2: 3} 1 0 LOAD_CONST 0 (1) 2 LOAD_CONST 1 (3) 4 LOAD_CONST 2 ((0, 2)) 6 BUILD_CONST_KEY_MAP 2 8 POP_TOP 10 LOAD_CONST 3 (None) 12 RETURN_VALUE $ ./python -m dis {-0: 1, 2: 3} 1 0 LOAD_CONST 5 (0) 2 LOAD_CONST 1 (1) 4 LOAD_CONST 2 (2) 6 LOAD_CONST 3 (3) 8 BUILD_MAP 2 10 POP_TOP 12 LOAD_CONST 4 (None) 14 RETURN_VALUE ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 03:49:04 2016 From: report at bugs.python.org (Steve Piercy) Date: Fri, 10 Jun 2016 07:49:04 +0000 Subject: [issue27285] Deprecate pyvenv in favor of python3 -m venv Message-ID: <1465544944.16.0.549761687921.issue27285@psf.upfronthosting.co.za> New submission from Steve Piercy: Per https://bugs.python.org/issue25154 `pyvenv` is deprecated in favor of `python3 -m venv`. The docs for Python 3.5+ need to be updated accordingly. ---------- assignee: docs at python components: Documentation messages: 268104 nosy: docs at python, stevepiercy priority: normal severity: normal status: open title: Deprecate pyvenv in favor of python3 -m venv type: enhancement versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 03:52:46 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 10 Jun 2016 07:52:46 +0000 Subject: [issue27285] Deprecate pyvenv in favor of python3 -m venv In-Reply-To: <1465544944.16.0.549761687921.issue27285@psf.upfronthosting.co.za> Message-ID: <1465545166.67.0.155602900136.issue27285@psf.upfronthosting.co.za> Berker Peksag added the comment: It's actually deprecated in Python 3.6: https://docs.python.org/dev/whatsnew/3.6.html#deprecated-features ---------- keywords: +easy nosy: +berker.peksag stage: -> needs patch versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 04:12:51 2016 From: report at bugs.python.org (Steve Piercy) Date: Fri, 10 Jun 2016 08:12:51 +0000 Subject: [issue27285] Deprecate pyvenv in favor of python3 -m venv In-Reply-To: <1465544944.16.0.549761687921.issue27285@psf.upfronthosting.co.za> Message-ID: <1465546371.8.0.0424193532584.issue27285@psf.upfronthosting.co.za> Steve Piercy added the comment: I saw the patch in 3.6, yet the discussion in issue #25154 called for deprecation in 3.5.1. Was deprecation of `pyvenv` supposed to be implemented in 3.5.1? I couldn't find any other relevant discussion, so apologies for jumping in uninformed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 04:32:35 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 10 Jun 2016 08:32:35 +0000 Subject: [issue27285] Deprecate pyvenv in favor of python3 -m venv In-Reply-To: <1465544944.16.0.549761687921.issue27285@psf.upfronthosting.co.za> Message-ID: <1465547555.98.0.222734831876.issue27285@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 04:49:42 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Jun 2016 08:49:42 +0000 Subject: [issue20699] Document that binary IO classes work with bytes-likes objects In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za> Message-ID: <20160610084918.27788.67103.9035AC7A@psf.io> Roundup Robot added the comment: New changeset ec69518aeebc by Martin Panter in branch '2.7': Issue #20699: Document that ?io? methods should accept memoryview https://hg.python.org/cpython/rev/ec69518aeebc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 04:49:42 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Jun 2016 08:49:42 +0000 Subject: [issue24617] os.makedirs()'s [mode] not correct In-Reply-To: <1436721223.66.0.229120395272.issue24617@psf.upfronthosting.co.za> Message-ID: <20160610084918.27788.30022.411779D7@psf.io> Roundup Robot added the comment: New changeset 4fc7753efc89 by Tommy Beadle in branch '2.7': Issue #24617: Add comment for os.mkdir about mode quirks https://hg.python.org/cpython/rev/4fc7753efc89 New changeset e6093676e93b by Tommy Beadle in branch '3.5': Issue #24617: Add comment for os.mkdir about mode quirks https://hg.python.org/cpython/rev/e6093676e93b New changeset bfd77c6fc04f by Martin Panter in branch 'default': Issue #24617: Merge os.mkdir() doc from 3.5 https://hg.python.org/cpython/rev/bfd77c6fc04f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 05:14:21 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 10 Jun 2016 09:14:21 +0000 Subject: [issue24617] os.makedirs()'s [mode] not correct In-Reply-To: <1436721223.66.0.229120395272.issue24617@psf.upfronthosting.co.za> Message-ID: <1465550061.17.0.399018630672.issue24617@psf.upfronthosting.co.za> Berker Peksag added the comment: Please use "hg import --no-commit" in the future. Since Mercurial doesn't keep committer's information it's hard to see who actually committed the patch in case of a problem. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 05:37:11 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 10 Jun 2016 09:37:11 +0000 Subject: [issue27286] str object got multiple values for keyword argument Message-ID: <1465551431.42.0.267871198404.issue27286@psf.upfronthosting.co.za> New submission from Martin Panter: Playing with the generalized unpacking (PEP 448), I found a funny error message, when duplicate dictionary unpackings are included and also duplicate a literal keyword argument: >>> print(end=".\n", **dict(end="dupe")) # No problem TypeError: print() got multiple values for keyword argument 'end' >>> print(**dict(end=".\n"), **dict(end="dupe")) # No problem TypeError: print() got multiple values for keyword argument 'end' >>> print(end=".\n", **dict(end="dupe"), **dict(end="dupe 2")) # str object?! TypeError: str object got multiple values for keyword argument 'end' ---------- components: Interpreter Core messages: 268110 nosy: martin.panter priority: normal severity: normal status: open title: str object got multiple values for keyword argument type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 05:47:11 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 10 Jun 2016 09:47:11 +0000 Subject: [issue24617] os.makedirs()'s [mode] not correct In-Reply-To: <1436721223.66.0.229120395272.issue24617@psf.upfronthosting.co.za> Message-ID: <1465552031.26.0.197104903362.issue24617@psf.upfronthosting.co.za> Martin Panter added the comment: Okay I will avoid this problem in the future. I often use the mq extension, but I can reset the user and date with that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 05:47:33 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 10 Jun 2016 09:47:33 +0000 Subject: [issue24617] os.makedirs()'s [mode] not correct In-Reply-To: <1436721223.66.0.229120395272.issue24617@psf.upfronthosting.co.za> Message-ID: <1465552053.57.0.0695443543523.issue24617@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 06:29:10 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 10 Jun 2016 10:29:10 +0000 Subject: [issue18802] ipaddress documentation errors In-Reply-To: <1377118857.87.0.169407991036.issue18802@psf.upfronthosting.co.za> Message-ID: <1465554550.7.0.986739505193.issue18802@psf.upfronthosting.co.za> Berker Peksag added the comment: Thank you for the great patch Jon! :) I rebased Jon's patch to current default with additional changes like fixing typos and markup tweaks. I also removed the following item since it doesn't seem to be crucial: * It's probably a good idea to document that you can't always pass a IPv4Interface object to a function that expects a IPv4Address. ---------- Added file: http://bugs.python.org/file43330/issue18802_v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 07:26:33 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Jun 2016 11:26:33 +0000 Subject: [issue27280] Paste fail in ipaddress documentation In-Reply-To: <1465463661.18.0.737340731231.issue27280@psf.upfronthosting.co.za> Message-ID: <20160610112629.114316.12078.BBB8C438@psf.io> Roundup Robot added the comment: New changeset fcd9f6ffbeaf by Berker Peksag in branch '3.5': Issue #27280: Fix typo in IPv6Network documentation https://hg.python.org/cpython/rev/fcd9f6ffbeaf New changeset 18f1012e0c56 by Berker Peksag in branch 'default': Issue #27280: Merge from 3.5 https://hg.python.org/cpython/rev/18f1012e0c56 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 07:27:01 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 10 Jun 2016 11:27:01 +0000 Subject: [issue27280] Paste fail in ipaddress documentation In-Reply-To: <1465463661.18.0.737340731231.issue27280@psf.upfronthosting.co.za> Message-ID: <1465558021.34.0.113016761428.issue27280@psf.upfronthosting.co.za> Berker Peksag added the comment: Good catch, thanks Arthur! ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed type: enhancement -> behavior versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 07:33:48 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 10 Jun 2016 11:33:48 +0000 Subject: [issue22822] IPv6Network constructor docs incorrect about valid input In-Reply-To: <1415468629.6.0.255055357939.issue22822@psf.upfronthosting.co.za> Message-ID: <1465558428.76.0.392954593668.issue22822@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report Chris. The patch in issue 18802 should solve this. It would be great if you'd have time to take a look at it (should we add a note that says we only support CIDR for IPv6?) ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 07:56:12 2016 From: report at bugs.python.org (Sergey Chvalyuk) Date: Fri, 10 Jun 2016 11:56:12 +0000 Subject: [issue26545] os.walk is limited by python's recursion limit In-Reply-To: <1457744340.04.0.931517157669.issue26545@psf.upfronthosting.co.za> Message-ID: <1465559772.94.0.46339066849.issue26545@psf.upfronthosting.co.za> Sergey Chvalyuk added the comment: There is another limitation with os.walk it also cannot go very deep inside tree because of scandir can throw OSError(36, 'File name too long') I have wrote tests for both cases: https://gist.github.com/grubberr/3367f1d605e292103b576a17a46ef3c3 tested on linux only on MacOS it throw 'File name too long' for 1-st test too set sys.settrecursionlimit to lower values ---------- nosy: +Sergey Chvalyuk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 08:05:53 2016 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 10 Jun 2016 12:05:53 +0000 Subject: [issue27243] __aiter__ should return async iterator instead of awaitable In-Reply-To: <1465240896.52.0.994549894653.issue27243@psf.upfronthosting.co.za> Message-ID: <1465560353.11.0.758046257086.issue27243@psf.upfronthosting.co.za> Yury Selivanov added the comment: This is because sys.version_info is 3.5.1 (not 3.5.2 yet) in the "3.5" branch. Once 3.5.2 RC is tagged the warning will disappear. https://github.com/python/cpython/blob/master/Lib/asyncio/streams.py#L693 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 08:27:10 2016 From: report at bugs.python.org (Alexander Haensch) Date: Fri, 10 Jun 2016 12:27:10 +0000 Subject: [issue27287] SIGSEGV when calling os.forkpty() Message-ID: <1465561630.72.0.359750002725.issue27287@psf.upfronthosting.co.za> New submission from Alexander Haensch: I recieve a segmentation fault if i call os.forkpty(). It does not happen with os.openpty(). Moreover os.fork() works fine. The basesystem is gentoo-hardened. It does only happens if threading is enabled, which is the standard. Tested python versions: 2.7.10, 3.4.3 Some backtraces and py-bt are found here: https://bugs.gentoo.org/show_bug.cgi?id=584916 Is this a known issue? At the moment i am thinking that gcc is "optimizing" something here. ---------- messages: 268118 nosy: Alexander Haensch priority: normal severity: normal status: open title: SIGSEGV when calling os.forkpty() type: crash versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 08:37:35 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 10 Jun 2016 12:37:35 +0000 Subject: [issue20825] containment test for "ip_network in ip_network" In-Reply-To: <1393766299.38.0.300697561376.issue20825@psf.upfronthosting.co.za> Message-ID: <1465562255.01.0.775078329515.issue20825@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: -> patch review type: -> enhancement versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 08:51:39 2016 From: report at bugs.python.org (Tomas Gavenciak) Date: Fri, 10 Jun 2016 12:51:39 +0000 Subject: [issue3119] pickle.py is limited by python's call stack In-Reply-To: <1213589185.62.0.660916672679.issue3119@psf.upfronthosting.co.za> Message-ID: <1465563099.98.0.595674307935.issue3119@psf.upfronthosting.co.za> Tomas Gavenciak added the comment: Hey all, I would like to patch the C _pickle module to be non-recursive and help this patch go through. I have an idea on how to do that with a very small amount of changes below and I would like to get feedback and improvements before implementing it in a particular way or getting into details (basically to check if that is acceptable and whether I missed something major). Also, what is missing in the Python patch to get it merged? == Nonrecursive _pickle: First, observe that all the save_* recursive calls do not rely on the return value of save_* except for error checking (which is propagated as -1 to the top). Also, almost all work in save_* is done before calling save() recursively (most of the work after calling save()s is decref or other minor cleanup). I would propose a linked list of structures acting as a stack of objects and byte-sequences to be written (for the marks and opcodes). Imagine something like the following (a rough sketch, I need to check all the required info properly later): struct _PickleStack {_PickleStack* next; PyObject *obj; char write_opcode; /* ... objects to decref / cleanup after the write */ /* possibly pers_save flags */ }; The pickle stack would be a part of Pickler and save() would push a value onto that stack instead of recursion. (The order of save() and calls within save_*() needs to be reversed, though.) Most objects would push a fixed number of objects to the pickle stack, for lists and dicts I would make pickle stack entries for all the items at once (e.g. as in batch_list()). An alternative would be to store the last item and the open iterator, but that seems wasteful. This should not slow things down significantly (if at all), as the only overhead is having own stack of small structures (likely less than stackframe size of save_*). If frequent de/allocation will be a problem, I would modify the allocation strategy later (to blocks or such). Are there any issues with changing the working of save() internally? The functionality of reduce, custom Picklers, persistent ids and dispatch tables should stay the same. The unpickling is not recursive and needs no changes (and has its own custom stack impl). Looking forward to your comments. ---------- nosy: +gavento, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 09:04:44 2016 From: report at bugs.python.org (Julio C Cardoza) Date: Fri, 10 Jun 2016 13:04:44 +0000 Subject: [issue27139] Increased test coverage for statistics.median_grouped In-Reply-To: <1464446645.63.0.403096467331.issue27139@psf.upfronthosting.co.za> Message-ID: Julio C Cardoza added the comment: Hi... Just want to find out if you have the chance to check my code. Thanks! On Sat, May 28, 2016 at 10:44 AM, Julio C Cardoza wrote: > > New submission from Julio C Cardoza: > > I had signed the contributor agreement.! > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 09:08:59 2016 From: report at bugs.python.org (SilentGhost) Date: Fri, 10 Jun 2016 13:08:59 +0000 Subject: [issue20825] containment test for "ip_network in ip_network" In-Reply-To: <1393766299.38.0.300697561376.issue20825@psf.upfronthosting.co.za> Message-ID: <1465564139.56.0.674802943291.issue20825@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +SilentGhost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 09:15:43 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jun 2016 13:15:43 +0000 Subject: [issue27286] str object got multiple values for keyword argument In-Reply-To: <1465551431.42.0.267871198404.issue27286@psf.upfronthosting.co.za> Message-ID: <1465564543.98.0.188859327582.issue27286@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a fix. ---------- keywords: +patch nosy: +serhiy.storchaka stage: -> patch review Added file: http://bugs.python.org/file43331/BUILD_MAP_UNPACK_WITH_CALL-function_pos.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 10:05:11 2016 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 10 Jun 2016 14:05:11 +0000 Subject: [issue27275] KeyError thrown by optimised collections.OrderedDict.popitem() In-Reply-To: <1465446835.8.0.930561202137.issue27275@psf.upfronthosting.co.za> Message-ID: <1465567511.47.0.925590158024.issue27275@psf.upfronthosting.co.za> Xiang Zhang added the comment: I think your expiringdict seems not work with the C version OrderedDict, you may need to change your implementation or clarify that :(. The C version's OrderedDict.popitem may call your __getitem__ which then does deletion and emit KeyError when expires. I think the new OrderedDict may call your __getitem__ even in iteration which leads to the 'RuntimeError: OrderedDict mutated during iteration'. I haven't checked that. So a simple working example in Py3.4: d = ExpiringDict(max_len=3, max_age_seconds=0.01) d['a'] = 'z' sleep(1) d.popitem() will fail in Py3.5+. ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 11:46:17 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 10 Jun 2016 15:46:17 +0000 Subject: [issue27286] str object got multiple values for keyword argument In-Reply-To: <1465551431.42.0.267871198404.issue27286@psf.upfronthosting.co.za> Message-ID: <1465573577.2.0.965129698294.issue27286@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This patch looks correct. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 12:21:21 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 10 Jun 2016 16:21:21 +0000 Subject: [issue27285] Document the deprecation of pyvenv in favor of `python3 -m venv` In-Reply-To: <1465544944.16.0.549761687921.issue27285@psf.upfronthosting.co.za> Message-ID: <1465575681.42.0.761286682653.issue27285@psf.upfronthosting.co.za> Brett Cannon added the comment: Basically I changed my mind about adding the code deprecation in 3.5.1 since it wasn't fair to people to run into that in a bugfix release. Documenting the deprecation, though, can happen in Python 3.5.1 as well as updating the documentation of the venv module to only use `python3 -m venv` which I missed the first time through. ---------- assignee: docs at python -> brett.cannon title: Deprecate pyvenv in favor of python3 -m venv -> Document the deprecation of pyvenv in favor of `python3 -m venv` _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 12:25:55 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Jun 2016 16:25:55 +0000 Subject: [issue17500] move PC/icons/source.xar to http://www.python.org/community/logos/ In-Reply-To: <1363820002.7.0.633809398541.issue17500@psf.upfronthosting.co.za> Message-ID: <20160610162551.11688.91059.DF4833A9@psf.io> Roundup Robot added the comment: New changeset c6c55d1eadc4 by doko in branch '2.7': - Issue #17500, and https://github.com/python/pythondotorg/issues/945: Remove https://hg.python.org/cpython/rev/c6c55d1eadc4 New changeset 0c4d525a2f10 by doko in branch '3.5': - Issue #17500, and https://github.com/python/pythondotorg/issues/945: Remove https://hg.python.org/cpython/rev/0c4d525a2f10 New changeset a3060775b8ad by doko in branch 'default': - Issue #17500, and https://github.com/python/pythondotorg/issues/945: Remove https://hg.python.org/cpython/rev/a3060775b8ad ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 12:26:47 2016 From: report at bugs.python.org (Matthias Klose) Date: Fri, 10 Jun 2016 16:26:47 +0000 Subject: [issue17500] move PC/icons/source.xar to http://www.python.org/community/logos/ In-Reply-To: <1363820002.7.0.633809398541.issue17500@psf.upfronthosting.co.za> Message-ID: <1465576007.41.0.452674008384.issue17500@psf.upfronthosting.co.za> Matthias Klose added the comment: removed the PC/icons directory. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 12:50:04 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jun 2016 16:50:04 +0000 Subject: [issue26213] Document BUILD_*_UNPACK opcodes In-Reply-To: <1453851645.07.0.698993321818.issue26213@psf.upfronthosting.co.za> Message-ID: <1465577404.18.0.532184024137.issue26213@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And BUILD_MAP_UNPACK_WITH_CALL. All these opcodes were added in issue2292 for implementing PEP 448, but are not documented even in the PEP. ---------- nosy: +Joshua.Landau, neil.g, serhiy.storchaka, twouters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 12:59:49 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jun 2016 16:59:49 +0000 Subject: [issue27286] str object got multiple values for keyword argument In-Reply-To: <1465551431.42.0.267871198404.issue27286@psf.upfronthosting.co.za> Message-ID: <1465577989.95.0.94303213698.issue27286@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Since currently generated bytecode is not correct, I think we should update the magic number for forcing the regenerating pyc-files. ---------- Added file: http://bugs.python.org/file43332/BUILD_MAP_UNPACK_WITH_CALL-function_pos2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 13:02:00 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 10 Jun 2016 17:02:00 +0000 Subject: [issue27272] random.Random should not read 2500 bytes from urandom In-Reply-To: <1465423096.81.0.204885224668.issue27272@psf.upfronthosting.co.za> Message-ID: <1465578120.96.0.483387893793.issue27272@psf.upfronthosting.co.za> Raymond Hettinger added the comment: With anything less than than full seeding of the 19937-bit state space, we lose all the guarantees (proved properties) documented at http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/ARTICLES/mt.pdf . It is very nice to be able to rely on those properties and I don't think we should abandon them because glibc currently has lower standards (the trend is towards making seeding stronger rather than weaker). "Good enough" for random number generators is in the eye of the beholder. If your agenda is to reduce the number of bytes extracted from urandom(), it is easy to not care how well the MT is seeded, but there are people who do care (or should care). Note that sampling and shuffling both eat entropy like crazy. Currently, we have enough to shuffle 2000 elements. With 128 bits, we run out at 34 elements, not even enough to shuffle a deck of cards and have each permutation as a possible outcome. Over time, the random module has evolved away from "good enough" and traded-away speed in return for equi-distribution (i.e. we use _randbelow to get a balanced choice over ranges that aren't an exact power-of-two). We should not allow a regression in quality. In particular, I object to the cavalier assertion, "random.Random doesn't need a very high quality entropy." If you're running multiple simulations, this is something you should care about. And to defend against criticism of random samples, it is nice to be able to say you were properly seeded (see RFC 1750) and that you have some basis for believing that every outcome was equally likely. ---------- assignee: -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 13:06:43 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 10 Jun 2016 17:06:43 +0000 Subject: [issue23693] timeit accuracy could be better In-Reply-To: <1426631677.96.0.782828300886.issue23693@psf.upfronthosting.co.za> Message-ID: <1465578403.97.0.883295656234.issue23693@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +gvanrossum, tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 13:31:59 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 10 Jun 2016 17:31:59 +0000 Subject: [issue27275] KeyError thrown by optimised collections.OrderedDict.popitem() In-Reply-To: <1465446835.8.0.930561202137.issue27275@psf.upfronthosting.co.za> Message-ID: <1465579919.74.0.716884348595.issue27275@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I'm wondering if the expiringdict(1) needs to have locked wrappers for the inherited methods: def __delitem__(self, key): with self.lock: OrderedDict.__delitem__(self, key) Otherwise, there is a risk that one thread is deleting a key with no lock held, while another thread is running expiringdict.popitem() which holds a lock while calling both __getitem__ and del. If the first thread runs between the two steps in the second, the race condition would cause a KeyError. This might explain why you've observed, '''Replacing use of popitem() with "del self[next(OrderedDict.__iter__(self))]" removes the KeyErrors and the structure otherwise works fine.''' (1) https://github.com/mailgun/expiringdict/blob/master/expiringdict/__init__.py ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 13:42:43 2016 From: report at bugs.python.org (Matthias Klose) Date: Fri, 10 Jun 2016 17:42:43 +0000 Subject: [issue25413] ctypes (libffi) fails to compile on Solaris X86 In-Reply-To: <1444919626.01.0.242398686702.issue25413@psf.upfronthosting.co.za> Message-ID: <1465580563.26.0.585899938829.issue25413@psf.upfronthosting.co.za> Matthias Klose added the comment: CristiFati, please could you check if the libffi patch is still needed with the current upstream libffi? See https://github.com/libffi/libffi ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 13:43:39 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 10 Jun 2016 17:43:39 +0000 Subject: [issue27129] Wordcode, part 2 In-Reply-To: <1464268387.83.0.862540030058.issue27129@psf.upfronthosting.co.za> Message-ID: <1465580619.57.0.260820279868.issue27129@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I really don't think any of this should be done at all. The current code is clean and fast (and to my eyes at least is very readable). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 13:57:57 2016 From: report at bugs.python.org (Steve Piercy) Date: Fri, 10 Jun 2016 17:57:57 +0000 Subject: [issue27285] Document the deprecation of pyvenv in favor of `python3 -m venv` In-Reply-To: <1465544944.16.0.549761687921.issue27285@psf.upfronthosting.co.za> Message-ID: <1465581477.02.0.594427561153.issue27285@psf.upfronthosting.co.za> Steve Piercy added the comment: I forgot to include the specific URL to update: https://docs.python.org/3/installing/ There may be other places. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 14:02:48 2016 From: report at bugs.python.org (Steve Piercy) Date: Fri, 10 Jun 2016 18:02:48 +0000 Subject: [issue27285] Document the deprecation of pyvenv in favor of `python3 -m venv` In-Reply-To: <1465544944.16.0.549761687921.issue27285@psf.upfronthosting.co.za> Message-ID: <1465581768.5.0.276324700329.issue27285@psf.upfronthosting.co.za> Steve Piercy added the comment: One more. https://docs.python.org/3/library/venv.html Should that be updated for 3.5.1 as well as 3.6? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 14:05:11 2016 From: report at bugs.python.org (Steve Piercy) Date: Fri, 10 Jun 2016 18:05:11 +0000 Subject: [issue27285] Document the deprecation of pyvenv in favor of `python3 -m venv` In-Reply-To: <1465544944.16.0.549761687921.issue27285@psf.upfronthosting.co.za> Message-ID: <1465581911.12.0.389563928221.issue27285@psf.upfronthosting.co.za> Steve Piercy added the comment: See also: https://github.com/pypa/python-packaging-user-guide/issues/242 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 14:14:02 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 10 Jun 2016 18:14:02 +0000 Subject: [issue27285] Document the deprecation of pyvenv in favor of `python3 -m venv` In-Reply-To: <1465544944.16.0.549761687921.issue27285@psf.upfronthosting.co.za> Message-ID: <1465582442.21.0.761830905873.issue27285@psf.upfronthosting.co.za> Brett Cannon added the comment: Documenting the deprecation in 3.5 is fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 14:15:45 2016 From: report at bugs.python.org (Tim Peters) Date: Fri, 10 Jun 2016 18:15:45 +0000 Subject: [issue27272] random.Random should not read 2500 bytes from urandom In-Reply-To: <1465423096.81.0.204885224668.issue27272@psf.upfronthosting.co.za> Message-ID: <1465582545.97.0.559618631992.issue27272@psf.upfronthosting.co.za> Tim Peters added the comment: Raymond, while I'm in general agreement with you, note that urandom() doesn't deliver "random" bytes to begin with. A CSPRNG is still a PRNG. For example, if the underlying urandom() generator is ChaCha20, _it_ has "only" 512 bits of state. Seeding the Twister with 2500 bytes from urandom() far exceeds the maximum possible entropy that ChaCha20's comparatively tiny 64 bytes of state can deliver (but, yes, I'm ignoring the possibility that a good urandom() implementation may fold in fresh entropy during the time MT sucks out those 2500 bytes - nevertheless, MT's state is far larger). That's why I said earlier I could live with seeding from 128 bytes - twice the size of a currently trendy urandom() implementation's state. But I'll be happiest if nothing changes here (given that Guido ruled yesterday that Python's current urandom() implementation has to be reverted to once again match Linux's non-blocking urandom() behavior). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 14:24:22 2016 From: report at bugs.python.org (William Pitcock) Date: Fri, 10 Jun 2016 18:24:22 +0000 Subject: [issue27275] KeyError thrown by optimised collections.OrderedDict.popitem() In-Reply-To: <1465446835.8.0.930561202137.issue27275@psf.upfronthosting.co.za> Message-ID: <1465583062.36.0.622584988155.issue27275@psf.upfronthosting.co.za> William Pitcock added the comment: At least in my case, the application is single-threaded. I don't think this is a locking-related issue as the expiringdict test case itself fails which is also single-threaded. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 14:28:12 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jun 2016 18:28:12 +0000 Subject: [issue27275] KeyError thrown by optimised collections.OrderedDict.popitem() In-Reply-To: <1465446835.8.0.930561202137.issue27275@psf.upfronthosting.co.za> Message-ID: <1465583292.65.0.961377681428.issue27275@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 14:31:55 2016 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 10 Jun 2016 18:31:55 +0000 Subject: [issue27275] KeyError thrown by optimised collections.OrderedDict.popitem() In-Reply-To: <1465446835.8.0.930561202137.issue27275@psf.upfronthosting.co.za> Message-ID: <1465583515.49.0.5115414131.issue27275@psf.upfronthosting.co.za> Xiang Zhang added the comment: Raymond, In single threaded case popitem may still fail. I want to correct my last message that popitem does not fail in this case because it calls __getitem__ but instead it calls __contains__[1]. In __contains__ it deletes the item since it expires, and finally emit a KeyError[2]. Even if it passes __contains__, it will call __getitem__[3]. [1] https://hg.python.org/cpython/file/tip/Objects/odictobject.c#l1115 [2] https://hg.python.org/cpython/file/tip/Objects/odictobject.c#l1135 [3] https://hg.python.org/cpython/file/tip/Objects/odictobject.c#l1119 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 14:35:59 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 10 Jun 2016 18:35:59 +0000 Subject: [issue20900] distutils register command should print text, not bytes repr In-Reply-To: <1394657963.26.0.506041572829.issue20900@psf.upfronthosting.co.za> Message-ID: <1465583759.08.0.0967794509039.issue20900@psf.upfronthosting.co.za> Berker Peksag added the comment: issue20900.patch looks good to me. We are already testing output of "python -setup.py upload --show-response" in Lib/distutils/tests/test_upload.py so I removed test_show_reponse and tweaked test_upload to test the whole line: - self.assertIn('xyzzy\n', results[-1]) + self.assertEqual(results[-1], 75 * '-' + '\nxyzzy\n' + 75 * '-') ---------- nosy: +berker.peksag versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 14:47:43 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Jun 2016 18:47:43 +0000 Subject: [issue26282] Add support for partial keyword arguments in extension functions In-Reply-To: <1454535856.96.0.444049158428.issue26282@psf.upfronthosting.co.za> Message-ID: <20160610180951.114484.20394.0BD1ABB7@psf.io> Roundup Robot added the comment: New changeset 69c0aa8a8185 by Serhiy Storchaka in branch 'default': Issue #26282: PyArg_ParseTupleAndKeywords() and Argument Clinic now support https://hg.python.org/cpython/rev/69c0aa8a8185 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 14:49:32 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jun 2016 18:49:32 +0000 Subject: [issue27129] Wordcode, part 2 In-Reply-To: <1464268387.83.0.862540030058.issue27129@psf.upfronthosting.co.za> Message-ID: <1465584572.13.0.708302511973.issue27129@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is not just about cleaning (to my eyes current code is not very readable, and I read it many times, perhaps more times than any other core developer in last months). There are other benefits. Changing jump offsets allows to get rid of EXTENDED_ARGs for the part of jump opcodes. Changing lnotab makes it more compact and allows the peepholer to optimize the code that it rejects now. Refactoring includes the change that decreases memory consumption of the peepholer (from 4 bytes per bytecode byte to 2 bytes per bytecode byte). Changing jump offsets together with changing f_lasti removes redundant multiplications and divisions by 2. Separate changes can complicate some parts of code, but next changes removes this complication. Only all changes together achieve maximal cleanness. I think that converting to wordcode is not complete without these changes. I approved the wordcode patch only having in mind following changes. It is more painless to make all changes in one Python release than break compatibility during few releases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 14:54:37 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jun 2016 18:54:37 +0000 Subject: [issue27129] Wordcode, part 2 In-Reply-To: <1464268387.83.0.862540030058.issue27129@psf.upfronthosting.co.za> Message-ID: <1465584877.78.0.655573120503.issue27129@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: update patch replaces yet few magic constants. ---------- Added file: http://bugs.python.org/file43333/wordcode-refactor2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 14:55:30 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jun 2016 18:55:30 +0000 Subject: [issue26282] Add support for partial keyword arguments in extension functions In-Reply-To: <1454535856.96.0.444049158428.issue26282@psf.upfronthosting.co.za> Message-ID: <1465584930.87.0.0557702048378.issue26282@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 14:57:15 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jun 2016 18:57:15 +0000 Subject: [issue26243] zlib.compress level as keyword argument In-Reply-To: <1454179267.96.0.292283649228.issue26243@psf.upfronthosting.co.za> Message-ID: <1465585035.75.0.545333931214.issue26243@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Regenerated for review. ---------- Added file: http://bugs.python.org/file43334/zlib_compress_positional_only_data.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 15:06:44 2016 From: report at bugs.python.org (Demur Rumed) Date: Fri, 10 Jun 2016 19:06:44 +0000 Subject: [issue27129] Wordcode, part 2 In-Reply-To: <1464268387.83.0.862540030058.issue27129@psf.upfronthosting.co.za> Message-ID: <1465585604.93.0.134383348648.issue27129@psf.upfronthosting.co.za> Demur Rumed added the comment: The patches LGTM & seem to be implementation of follow up ideas outlined in the first portion. It'd be good to verify that benchmarks are relatively unaffected ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 15:34:05 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Jun 2016 19:34:05 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <20160610193402.9990.33259.4BBF2FB8@psf.io> Roundup Robot added the comment: New changeset a5a013ca5687 by Brett Cannon in branch 'default': Issue #27186: Add os.PathLike support to pathlib. https://hg.python.org/cpython/rev/a5a013ca5687 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 15:56:39 2016 From: report at bugs.python.org (Donald Stufft) Date: Fri, 10 Jun 2016 19:56:39 +0000 Subject: [issue27288] secrets should use getrandom() on Linux Message-ID: <1465588599.3.0.867244099768.issue27288@psf.upfronthosting.co.za> New submission from Donald Stufft: In 3.5.0 and 3.5.1 os.urandom will, where available, use the getrandom() to block rather than get insecure random from the urandom pool on Linux. In 3.5.2 this change is reverted so that os.urandom will return possibly predictable random numbers instead of blocking waiting for /dev/urandom to be intialized. However, secrets.py is a module which is explicitly for getting cryptographically safe data for, and reverting that change means that the functions in this module are no longer cryptographically safe on Linux if they are called early enough in the boot process. Thus, secrets.py should be modified so that it no longer uses os.urandom on systems where there is a better source of randomness available-- namely getrandom() set to block on Linux. ---------- messages: 268147 nosy: brett.cannon, dstufft, ned.deily priority: release blocker severity: normal status: open title: secrets should use getrandom() on Linux type: security versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 15:58:07 2016 From: report at bugs.python.org (William Pitcock) Date: Fri, 10 Jun 2016 19:58:07 +0000 Subject: [issue27275] KeyError thrown by optimised collections.OrderedDict.popitem() In-Reply-To: <1465446835.8.0.930561202137.issue27275@psf.upfronthosting.co.za> Message-ID: <1465588687.36.0.847425938606.issue27275@psf.upfronthosting.co.za> William Pitcock added the comment: It seems to me that calling __contains__() (PySequence_Contains()) isn't necessary, as the first and last elements of the list are already known, and therefore known to be in the list. Revising the behaviour of popitem() to avoid calling _odict_popkey_hash() seems like it may provide a marginal performance benefit as well as fix the problem. Calling PyObject_DelItem() directly on the node should work fine I believe. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 15:58:59 2016 From: report at bugs.python.org (Donald Stufft) Date: Fri, 10 Jun 2016 19:58:59 +0000 Subject: [issue27288] secrets should use getrandom() on Linux In-Reply-To: <1465588599.3.0.867244099768.issue27288@psf.upfronthosting.co.za> Message-ID: <1465588739.12.0.376098974455.issue27288@psf.upfronthosting.co.za> Donald Stufft added the comment: As an additional aside, the documentation of secrets references the documentation of random.py for it's secrets.SystemRandom class, however random.py docouments random.SystemRandom as using os.urandom. So the documentation for secrets.SystemRandom should be disentangled from the documentation of random.SystemRandom so that it can choose to use the stronger randomness function (or random.SystemRandom should be adapted to use the stronger randomness function, or both things). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 16:02:06 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Jun 2016 20:02:06 +0000 Subject: [issue20900] distutils register command should print text, not bytes repr In-Reply-To: <1394657963.26.0.506041572829.issue20900@psf.upfronthosting.co.za> Message-ID: <20160610200159.81388.42213.9424614A@psf.io> Roundup Robot added the comment: New changeset 02824cee7624 by Berker Peksag in branch '3.5': Issue #20900: distutils register command now decodes HTTP responses correctly https://hg.python.org/cpython/rev/02824cee7624 New changeset b0be24a2f16c by Berker Peksag in branch 'default': Issue #20900: Merge from 3.5 https://hg.python.org/cpython/rev/b0be24a2f16c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 16:04:09 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 10 Jun 2016 20:04:09 +0000 Subject: [issue20900] distutils register command should print text, not bytes repr In-Reply-To: <1394657963.26.0.506041572829.issue20900@psf.upfronthosting.co.za> Message-ID: <1465589049.49.0.263152662822.issue20900@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch ingrid! ---------- assignee: eric.araujo -> resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 16:15:49 2016 From: report at bugs.python.org (Tim Peters) Date: Fri, 10 Jun 2016 20:15:49 +0000 Subject: [issue27288] secrets should use getrandom() on Linux In-Reply-To: <1465588599.3.0.867244099768.issue27288@psf.upfronthosting.co.za> Message-ID: <1465589749.97.0.565468550496.issue27288@psf.upfronthosting.co.za> Tim Peters added the comment: It was a primary purpose of `secrets` to be a place where security best practices could be implemented, and changed over time, with no concern about backward compatibility for people who don't use it. So if `secrets` needs to supply a class with all the methods of random.Random, it should derive its own subclass (or derive from random.SystemRandom, and override the only two methods that explicitly invoke _urandom() - everything else ends up using .random() or .getrandbits()). ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 16:20:55 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 10 Jun 2016 20:20:55 +0000 Subject: [issue27288] secrets should use getrandom() on Linux In-Reply-To: <1465588599.3.0.867244099768.issue27288@psf.upfronthosting.co.za> Message-ID: <1465590055.95.0.206787118862.issue27288@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 16:21:53 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 10 Jun 2016 20:21:53 +0000 Subject: [issue15468] Edit docs to hide hashlib.md5() In-Reply-To: <1343404007.83.0.817302008925.issue15468@psf.upfronthosting.co.za> Message-ID: <1465590113.46.0.996475550871.issue15468@psf.upfronthosting.co.za> Berker Peksag added the comment: The looks good to me in general, but I'd suggest to refer to the new algorithms_guaranteed and algorithms_available attributes in the following paragraph: +:func:`sha512`. The :func:`md5` is typically available, but will be missing if +Python has been compiled in FIPS-compliant mode. If hashlib was compiled with +OpenSSL support then additional algorithms may also be available depending +upon the OpenSSL library that Python uses on your platform. OpenSSL +implementations of the builtin algorithms are used if available. ---------- assignee: -> docs at python components: +Documentation nosy: +berker.peksag, docs at python stage: -> patch review type: -> enhancement versions: +Python 3.5, Python 3.6 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 16:34:05 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 10 Jun 2016 20:34:05 +0000 Subject: [issue27289] test_ftp_timeout fails with EOFError Message-ID: <1465590845.17.0.18803116863.issue27289@psf.upfronthosting.co.za> New submission from Berker Peksag: >From http://buildbot.python.org/all/builders/x86-64%20Ubuntu%2015.10%20Skylake%20CPU%203.5/builds/533/steps/test/logs/stdio ====================================================================== ERROR: test_ftp_timeout (test.test_urllib2net.TimeoutTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/urllib/request.py", line 1471, in ftp_open fw = self.connect_ftp(user, passwd, host, port, dirs, req.timeout) File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/urllib/request.py", line 1493, in connect_ftp persistent=False) File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/urllib/request.py", line 2318, in __init__ self.init() File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/urllib/request.py", line 2327, in init self.ftp.connect(self.host, self.port, self.timeout) File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/ftplib.py", line 156, in connect self.welcome = self.getresp() File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/ftplib.py", line 235, in getresp resp = self.getmultiline() File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/ftplib.py", line 221, in getmultiline line = self.getline() File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/ftplib.py", line 209, in getline raise EOFError EOFError During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/test/test_urllib2net.py", line 323, in test_ftp_timeout u = _urlopen_with_retry(self.FTP_HOST, timeout=60) File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/test/test_urllib2net.py", line 27, in wrapped return _retry_thrice(func, exc, *args, **kwargs) File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/test/test_urllib2net.py", line 23, in _retry_thrice raise last_exc File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/test/test_urllib2net.py", line 19, in _retry_thrice return func(*args, **kwargs) File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/urllib/request.py", line 163, in urlopen return opener.open(url, data, timeout) File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/urllib/request.py", line 466, in open response = self._open(req, data) File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/urllib/request.py", line 484, in _open '_open', req) File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/urllib/request.py", line 444, in _call_chain result = func(*args) File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/urllib/request.py", line 1489, in ftp_open raise exc.with_traceback(sys.exc_info()[2]) File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/urllib/request.py", line 1471, in ftp_open fw = self.connect_ftp(user, passwd, host, port, dirs, req.timeout) File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/urllib/request.py", line 1493, in connect_ftp persistent=False) File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/urllib/request.py", line 2318, in __init__ self.init() File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/urllib/request.py", line 2327, in init self.ftp.connect(self.host, self.port, self.timeout) File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/ftplib.py", line 156, in connect self.welcome = self.getresp() File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/ftplib.py", line 235, in getresp resp = self.getmultiline() File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/ftplib.py", line 221, in getmultiline line = self.getline() File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/ftplib.py", line 209, in getline raise EOFError urllib.error.URLError: ---------- components: Tests messages: 268154 nosy: berker.peksag priority: normal severity: normal stage: needs patch status: open title: test_ftp_timeout fails with EOFError type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 16:38:57 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 10 Jun 2016 20:38:57 +0000 Subject: [issue27289] test_ftp_timeout fails with EOFError In-Reply-To: <1465590845.17.0.18803116863.issue27289@psf.upfronthosting.co.za> Message-ID: <1465591137.22.0.838462528763.issue27289@psf.upfronthosting.co.za> Berker Peksag added the comment: Here is a patch to skip the test. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file43335/issue27289.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 17:00:28 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jun 2016 21:00:28 +0000 Subject: [issue26800] Don't accept bytearray as filenames part 2 In-Reply-To: <1461015295.39.0.246147143774.issue26800@psf.upfronthosting.co.za> Message-ID: <1465592428.32.0.209174749431.issue26800@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch that deprecates support of general bytes-like objects in os functions. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file43336/path_converter-deprecate-buffer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 17:02:58 2016 From: report at bugs.python.org (Derek Wilson) Date: Fri, 10 Jun 2016 21:02:58 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za> Message-ID: <1465592578.63.0.934679629747.issue3982@psf.upfronthosting.co.za> Derek Wilson added the comment: Gregory - I'm glad that you're willing to consider this again. It still is a constant issue for me, and .format with variable width fields in binary protocols is so the right tool for the job. If there is anything I can do to help get this added to 3.6 let me know. The forward/backward compatibility issue is secondary to me to the flexibility gained from having .format available for bytes. Also padding with null bytes that don't get converted would be awesome. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 17:37:29 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Jun 2016 21:37:29 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <20160610213726.11607.33523.DC137EDD@psf.io> Roundup Robot added the comment: New changeset 5a62d682636e by Brett Cannon in branch 'default': Issue #27186: Add os.PathLike support to DirEntry https://hg.python.org/cpython/rev/5a62d682636e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 17:38:59 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 10 Jun 2016 21:38:59 +0000 Subject: [issue27038] Make os.DirEntry exist In-Reply-To: <1463413415.02.0.145090656269.issue27038@psf.upfronthosting.co.za> Message-ID: <1465594739.3.0.729583001215.issue27038@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 17:40:43 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 10 Jun 2016 21:40:43 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1465594843.27.0.242220798488.issue27186@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: fixed -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 17:40:49 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 10 Jun 2016 21:40:49 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1465594849.78.0.979121561317.issue27186@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- stage: resolved -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 17:48:11 2016 From: report at bugs.python.org (James Lu) Date: Fri, 10 Jun 2016 21:48:11 +0000 Subject: [issue27290] Turn heaps library into a more OOP data structure? Message-ID: <1465595291.89.0.406235678654.issue27290@psf.upfronthosting.co.za> New submission from James Lu: The heapq library uses a list or other mutable sequence time to represent a heap. Since Python is a highly OOP language, why not make heaps their own data type? ---------- components: Library (Lib) messages: 268159 nosy: James.Lu priority: normal severity: normal status: open title: Turn heaps library into a more OOP data structure? versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 18:00:08 2016 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 10 Jun 2016 22:00:08 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za> Message-ID: <1465596008.97.0.0436121115477.issue3982@psf.upfronthosting.co.za> Nick Coghlan added the comment: The core problem with the idea of adding bytes.format to Python 3 is that the real power of str.format actually lies in the extensible __format__ protocol and the associated format() builtin, as those rely heavily on text-specific assumptions. I interpreted Amber's comments at the language summit as referring more to our changing tune regarding mod formatting from: - mod formatting is deprecated, use brace formatting instead; to - they're both fully supported, neither is deprecated; to - use brace formatting for text data, mod formatting for binary data Folks that followed our original "stop using mod formatting" guidance thus needed to change course when it became our recommended technique for formatting binary data. Since we now know format() and __format__ aren't suitable for binary data (PEP 361 originally included it, and it got dropped as we kept finding awkward corner cases), that means any new binary formatting proposal needs to explain: - how it compares to existing serialisation techniques (mod-formatting, the struct module, text-formatting+encoding, etc) - why it needs to be a builtin method or function rather than a new serialisation module ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 18:02:49 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 10 Jun 2016 22:02:49 +0000 Subject: [issue27290] Turn heaps library into a more OOP data structure? In-Reply-To: <1465595291.89.0.406235678654.issue27290@psf.upfronthosting.co.za> Message-ID: <1465596169.73.0.194447145456.issue27290@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The main reason is that there would be very little benefit. Lists are a very efficient data structure and the heap manipulations are also very cheap. ---------- assignee: -> rhettinger nosy: +rhettinger resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 18:07:32 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 10 Jun 2016 22:07:32 +0000 Subject: [issue21386] ipaddress.IPv4Address.is_global not implemented In-Reply-To: <1398771335.62.0.997727403803.issue21386@psf.upfronthosting.co.za> Message-ID: <1465596452.76.0.36108627708.issue21386@psf.upfronthosting.co.za> Berker Peksag added the comment: Here is an updated patch that uses my proposal in msg219017. Since this is already documented at https://docs.python.org/3.5/library/ipaddress.html#ipaddress.IPv4Address.is_global I think it should also go into 3.5. ---------- versions: +Python 3.6 Added file: http://bugs.python.org/file43337/issue21386_v3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 18:07:40 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 10 Jun 2016 22:07:40 +0000 Subject: [issue27272] random.Random should not read 2500 bytes from urandom In-Reply-To: <1465423096.81.0.204885224668.issue27272@psf.upfronthosting.co.za> Message-ID: <1465596460.62.0.631064042432.issue27272@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > But I'll be happiest if nothing changes here (given that Guido ruled > yesterday that Python's current urandom() implementation has to be > reverted to once again match Linux's non-blocking urandom() behavior). With urandom() behavior restored, can we close this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 18:41:41 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 Jun 2016 22:41:41 +0000 Subject: [issue24759] Idle: require tk 8.5 and ttk widgets, and drop unneeded code. In-Reply-To: <1438294715.65.0.966229055462.issue24759@psf.upfronthosting.co.za> Message-ID: <1465598501.19.0.272853878893.issue24759@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 Fri Jun 10 18:42:34 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 Jun 2016 22:42:34 +0000 Subject: [issue24750] IDLE: Cosmetic improvements for main window In-Reply-To: <1438203302.32.0.836313086846.issue24750@psf.upfronthosting.co.za> Message-ID: <1465598554.1.0.75762751339.issue24750@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Applied as 288e97680d84 (with # -> * typo): first ttk widgets. Issue *24750: Switch all scrollbars in IDLE to ttk versions. Where needed, add minimal tests to cover changes. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 19:10:03 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 Jun 2016 23:10: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: <1465600203.36.0.137163451136.issue16484@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Those are the only failures on 2 of the 4 buildbots running gui tests. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 19:30:28 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 Jun 2016 23:30:28 +0000 Subject: [issue27238] Bare except: usages in turtle.py In-Reply-To: <1465173486.36.0.354067909151.issue27238@psf.upfronthosting.co.za> Message-ID: <1465601428.44.0.985173027964.issue27238@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Add a comment to indicate that bare exception is intentional and briefly why. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 19:33:35 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Fri, 10 Jun 2016 23:33:35 +0000 Subject: [issue27233] Missing documentation for PyOS_FSPath In-Reply-To: <1465146030.9.0.386709465455.issue27233@psf.upfronthosting.co.za> Message-ID: <1465601615.6.0.676226594006.issue27233@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Brett Cannon added documentation for this function in another issue. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 19:34:11 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 Jun 2016 23:34:11 +0000 Subject: [issue27256] email header indentation destroyed In-Reply-To: <1465326886.85.0.738328133832.issue27256@psf.upfronthosting.co.za> Message-ID: <1465601651.73.0.138559804633.issue27256@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- stage: -> test needed title: header indentation destroyed -> email header indentation destroyed type: -> behavior versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 19:54:52 2016 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 10 Jun 2016 23:54:52 +0000 Subject: [issue23693] timeit accuracy could be better In-Reply-To: <1426631677.96.0.782828300886.issue23693@psf.upfronthosting.co.za> Message-ID: <1465602892.89.0.805088445085.issue23693@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- nosy: -gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 19:56:22 2016 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Fri, 10 Jun 2016 23:56:22 +0000 Subject: [issue27223] _read_ready and _write_ready should respect _conn_lost In-Reply-To: <1465089633.03.0.133113775178.issue27223@psf.upfronthosting.co.za> Message-ID: <1465602982.45.0.170732582644.issue27223@psf.upfronthosting.co.za> Changes by ?ukasz Langa : ---------- stage: -> patch review title: _ready_ready and _write_ready should respect _conn_lost -> _read_ready and _write_ready should respect _conn_lost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 20:12:28 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jun 2016 00:12:28 +0000 Subject: [issue27263] Tkinter sets the HOME environment variable, breaking scripts In-Reply-To: <1465352687.77.0.957460905896.issue27263@psf.upfronthosting.co.za> Message-ID: <1465603948.52.0.856359768795.issue27263@psf.upfronthosting.co.za> Terry J. Reedy added the comment: As IDLE maintainer, this annoys me also. IDLE and in particular test_idle necessarily change the environment by calling tkinter.Tk(). When run under test.regrtest, test_idle gets slapped with a warning, and in 3.6, gets labelled a failure, even when it passes. This issue cuts the other way too. IDLE works for months and then stops working. User posts "IDLE stopped working' on Stackoverflow. In at least some cases, user installed a program that installed ab incompatible tcl/tk and set TCL_LIBRARY (which Python does not). tk and tkinter get trapped by what for us is a bad setting. Serhiy, could the _tkinter startup code recover from this and revert to using the one we installed? Should I open a separate issue? ---------- components: -IDLE nosy: +serhiy.storchaka, terry.reedy title: IDLE sets the HOME environment variable breaking scripts -> Tkinter sets the HOME environment variable, breaking scripts _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 20:12:44 2016 From: report at bugs.python.org (James Lu) Date: Sat, 11 Jun 2016 00:12:44 +0000 Subject: [issue27290] Turn heaps library into a more OOP data structure? In-Reply-To: <1465596169.73.0.194447145456.issue27290@psf.upfronthosting.co.za> Message-ID: James Lu added the comment: Even a wrapper class would be helpful, it's simply more pythonic. On Fri, Jun 10, 2016 at 6:02 PM, Raymond Hettinger wrote: > > Raymond Hettinger added the comment: > > The main reason is that there would be very little benefit. Lists are a > very efficient data structure and the heap manipulations are also very > cheap. > > ---------- > assignee: -> rhettinger > nosy: +rhettinger > resolution: -> rejected > status: open -> closed > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 21:53:07 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jun 2016 01:53:07 +0000 Subject: [issue25733] Code and IDLE should catch all compile errors. In-Reply-To: <1448461598.38.0.392041411432.issue25733@psf.upfronthosting.co.za> Message-ID: <1465609987.29.0.359531484462.issue25733@psf.upfronthosting.co.za> Terry J. Reedy added the comment: How to cause SyntaxError -- obvious NameError -- ?, already caught in code module OverflowError-- ?, already caught in code module SystemError - 22 nested for loops ('deeply nested blocks') TypeError -- chr(0), 2.7 ValueError -- chr(0), 3.x; bytes(0), 2.7 ---------- components: +Library (Lib) -Interpreter Core title: Idle does not handle non-standard compile errors -> Code and IDLE should catch all compile errors. versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 21:56:17 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jun 2016 01:56:17 +0000 Subject: [issue27263] Tkinter sets the HOME environment variable, breaking scripts In-Reply-To: <1465352687.77.0.957460905896.issue27263@psf.upfronthosting.co.za> Message-ID: <1465610177.01.0.408568591128.issue27263@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 21:58:45 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jun 2016 01:58:45 +0000 Subject: [issue27173] Modern Unix key bindings for IDLE In-Reply-To: <1464766185.36.0.150155479026.issue27173@psf.upfronthosting.co.za> Message-ID: <1465610325.34.0.570852309958.issue27173@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- assignee: -> terry.reedy nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 23:18:01 2016 From: report at bugs.python.org (Upendra Kumar) Date: Sat, 11 Jun 2016 03:18:01 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1465615081.0.0.12544407211.issue27051@psf.upfronthosting.co.za> Upendra Kumar added the comment: I am unable to print anything using winreg module. Does it require administrative privileges? I am using this code sample : import os import errno import winreg proc_arch = os.environ['PROCESSOR_ARCHITECTURE'].lower() try: proc_arch64 = os.environ['PROCESSOR_ARCHITEW6432'].lower() except KeyError: proc_arch64 = None pass if proc_arch == 'x86' and not proc_arch64: arch_keys = {0} elif proc_arch == 'x86' or proc_arch == 'amd64': arch_keys = {winreg.KEY_WOW64_32KEY, winreg.KEY_WOW64_64KEY} else: raise Exception("Unhandled arch {}".format(proc_arch)) for arch_key in arch_keys: key = winreg.OpenKey(winreg.HKEY_LOCAL_MACHINE, r"SOFTWARE\Python", 0, winreg.KEY_READ | arch_key) for i in range(0, winreg.QueryInfoKey(key)[0]): skey_name = winreg.EnumKey(key, i) skey = winreg.OpenKey(key, skey_name) try: print(winreg.QueryValueEx(skey, 'DisplayName')[0]) except OSError as e: if e.errno == errno.ENOENT: pass finally: skey.Close() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 23:40:06 2016 From: report at bugs.python.org (Park Alex) Date: Sat, 11 Jun 2016 03:40:06 +0000 Subject: [issue27291] two heap corruption issue Message-ID: <1465616405.38.0.731036800645.issue27291@psf.upfronthosting.co.za> New submission from Park Alex: Hello, I would like to report two heap corruption issue. Test environment: python ersion: python 2.7.11+ hg id: d858eadf2602 (2.7) compile: clang with ASAN OS: ubuntu x86_64 One is heap-buffer-overflow, the other is heap-user-after-free. All of samples are attached in this bug report. Thanks, -- Alex In detail, 1) heap-buffer-overflow bug could be triggerd at cpython/Python/ceval.c:1229 ASAN report is following: ================================================================= ==26786==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7ffff7ec56e8 at pc 0x5ec87f bp 0x7fffffffd2d0 sp 0x7fffffffd2c8 READ of size 8 at 0x7ffff7ec56e8 thread T0 #0 0x5ec87e in PyEval_EvalFrameEx /project/cpython/Python/ceval.c:1229 #1 0x5d3c6c in PyEval_EvalCodeEx /project/cpython/Python/ceval.c:3582 #2 0x5d2b11 in PyEval_EvalCode /project/cpython/Python/ceval.c:669 #3 0x6612d9 in run_pyc_file /project/cpython/Python/pythonrun.c:1406 #4 0x6612d9 in PyRun_SimpleFileExFlags /project/cpython/Python/pythonrun.c:946 #5 0x48e3dc in Py_Main /project/cpython/Modules/main.c:640 #6 0x7ffff6ce282f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #7 0x48c518 in _start (/project/cpython/python.asan+0x48c518) 0x7ffff7ec56e8 is located 280 bytes to the left of 196608-byte region [0x7ffff7ec5800,0x7ffff7ef5800) allocated by thread T0 here: #0 0x476429 in __interceptor_malloc /project/clang-3.4/llvm-3.4/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:74 #1 0x50e969 in dictresize /project/cpython/Objects/dictobject.c:643 #2 0x537844 in PyString_InternInPlace /project/cpython/Objects/stringobject.c:4757 SUMMARY: AddressSanitizer: heap-buffer-overflow /project/cpython/Python/ceval.c:1229 PyEval_EvalFrameEx Shadow bytes around the buggy address: 0x10007efd0a80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x10007efd0a90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x10007efd0aa0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x10007efd0ab0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x10007efd0ac0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x10007efd0ad0: fa fa fa fa fa fa fa fa fa fa fa fa fa[fa]fa fa 0x10007efd0ae0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x10007efd0af0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x10007efd0b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10007efd0b10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10007efd0b20: 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 right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 ASan internal: fe ==26786==ABORTING 2) heap-user-after-free bug could be triggerd at cpython/Objects/dictobject.c:732 ASAN report is following: ================================================================= ==26918==ERROR: AddressSanitizer: heap-use-after-free on address 0x60f00000ef98 at pc 0x50f5ac bp 0x7fffffffa1d0 sp 0x7fffffffa1c8 READ of size 8 at 0x60f00000ef98 thread T0 #0 0x50f5ab in PyDict_GetItem /project/cpython/Objects/dictobject.c:732 #1 0x537792 in PyString_InternInPlace /project/cpython/Objects/stringobject.c:4750 #2 0x64fad5 in r_object /project/cpython/Python/marshal.c:822 #3 0x650d00 in r_object /project/cpython/Python/marshal.c:1037 #4 0x64edf6 in r_object /project/cpython/Python/marshal.c:886 #5 0x650c1b in r_object /project/cpython/Python/marshal.c:1019 #6 0x64e1b1 in PyMarshal_ReadObjectFromString /project/cpython/Python/marshal.c:1183 #7 0x64e1b1 in PyMarshal_ReadLastObjectFromFile /project/cpython/Python/marshal.c:1144 #8 0x6429c1 in read_compiled_module /project/cpython/Python/import.c:823 #9 0x6429c1 in load_source_module /project/cpython/Python/import.c:1094 #10 0x644cda in import_submodule /project/cpython/Python/import.c:2722 #11 0x643e81 in load_next /project/cpython/Python/import.c:2537 #12 0x63e061 in import_module_level /project/cpython/Python/import.c:2254 #13 0x63e061 in PyImport_ImportModuleLevel /project/cpython/Python/import.c:2310 #14 0x5c4e1a in builtin___import__ /project/cpython/Python/bltinmodule.c:49 #15 0x5e2535 in do_call /project/cpython/Python/ceval.c:4564 #16 0x5e2535 in call_function /project/cpython/Python/ceval.c:4372 #17 0x5e2535 in PyEval_EvalFrameEx /project/cpython/Python/ceval.c:2987 #18 0x5d3c6c in PyEval_EvalCodeEx /project/cpython/Python/ceval.c:3582 #19 0x7237f3 in function_call /project/cpython/Objects/funcobject.c:523 #20 0x4aca9a in PyObject_Call /project/cpython/Objects/abstract.c:2546 #21 0x5f1313 in PyEval_CallObjectWithKeywords /project/cpython/Python/ceval.c:4219 #22 0x62118c in _PyCodec_Lookup /project/cpython/Python/codecs.c:147 #23 0x6227d5 in _PyCodec_LookupTextEncoding /project/cpython/Python/codecs.c:459 #24 0x622b6a in codec_getitem_checked /project/cpython/Python/codecs.c:511 #25 0x622b6a in _PyCodec_TextEncoder /project/cpython/Python/codecs.c:523 #26 0x622b6a in _PyCodec_EncodeText /project/cpython/Python/codecs.c:537 #27 0x54dbc8 in PyString_AsEncodedObject /project/cpython/Objects/stringobject.c:532 #28 0x54dbc8 in string_encode /project/cpython/Objects/stringobject.c:3016 #29 0x5e232f in call_function /project/cpython/Python/ceval.c:4350 #30 0x5e232f in PyEval_EvalFrameEx /project/cpython/Python/ceval.c:2987 #31 0x5d3c6c in PyEval_EvalCodeEx /project/cpython/Python/ceval.c:3582 #32 0x5f2c7d in fast_function /project/cpython/Python/ceval.c:4445 #33 0x5dd2ba in call_function /project/cpython/Python/ceval.c:4370 #34 0x5dd2ba in PyEval_EvalFrameEx /project/cpython/Python/ceval.c:2987 #35 0x5d3c6c in PyEval_EvalCodeEx /project/cpython/Python/ceval.c:3582 #36 0x5d2b11 in PyEval_EvalCode /project/cpython/Python/ceval.c:669 #37 0x6612d9 in run_pyc_file /project/cpython/Python/pythonrun.c:1406 #38 0x6612d9 in PyRun_SimpleFileExFlags /project/cpython/Python/pythonrun.c:946 #39 0x48e3dc in Py_Main /project/cpython/Modules/main.c:640 #40 0x7ffff6ce282f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #41 0x48c518 in _start (/project/cpython/python.asan+0x48c518) 0x60f00000ef98 is located 72 bytes inside of 168-byte region [0x60f00000ef50,0x60f00000eff8) freed by thread T0 here: #0 0x4762a9 in free /project/clang-3.4/llvm-3.4/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64 #1 0x64fad5 in r_object /project/cpython/Python/marshal.c:822 #2 0x64edf6 in r_object /project/cpython/Python/marshal.c:886 #3 0x650c7a in r_object /project/cpython/Python/marshal.c:1022 #4 0x64edf6 in r_object /project/cpython/Python/marshal.c:886 #5 0x650c1b in r_object /project/cpython/Python/marshal.c:1019 #6 0x64e1b1 in PyMarshal_ReadObjectFromString /project/cpython/Python/marshal.c:1183 #7 0x64e1b1 in PyMarshal_ReadLastObjectFromFile /project/cpython/Python/marshal.c:1144 #8 0x6429c1 in read_compiled_module /project/cpython/Python/import.c:823 #9 0x6429c1 in load_source_module /project/cpython/Python/import.c:1094 #10 0x644cda in import_submodule /project/cpython/Python/import.c:2722 #11 0x643e81 in load_next /project/cpython/Python/import.c:2537 previously allocated by thread T0 here: #0 0x476429 in __interceptor_malloc /project/clang-3.4/llvm-3.4/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:74 #1 0x65de92 in new_threadstate /project/cpython/Python/pystate.c:159 SUMMARY: AddressSanitizer: heap-use-after-free /project/cpython/Objects/dictobject.c:732 PyDict_GetItem Shadow bytes around the buggy address: 0x0c1e7fff9da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c1e7fff9db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c1e7fff9dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c1e7fff9dd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c1e7fff9de0: fa fa fa fa fa fa fa fa fa fa fd fd fd fd fd fd =>0x0c1e7fff9df0: fd fd fd[fd]fd fd fd fd fd fd fd fd fd fd fd fa 0x0c1e7fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c1e7fff9e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c1e7fff9e20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c1e7fff9e30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c1e7fff9e40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 ASan internal: fe ==26918==ABORTING QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB QUFBQUFBQUFBQUFBQUE= ---------- components: Interpreter Core files: poc.zip messages: 268173 nosy: Park Alex, python-dev priority: normal severity: normal status: open title: two heap corruption issue type: security versions: Python 2.7 Added file: http://bugs.python.org/file43338/poc.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 10 23:50:37 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jun 2016 03:50:37 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1465617037.17.0.770273161005.issue27051@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I don't know what you mean by 'print with winreg'. I presume you need admin privilege to alter the registry. But why are you involved with it? I just want you to use the pip interface, and let pip worry about such low level stuff. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 00:00:53 2016 From: report at bugs.python.org (Upendra Kumar) Date: Sat, 11 Jun 2016 04:00:53 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1465617653.45.0.174268785023.issue27051@psf.upfronthosting.co.za> Upendra Kumar added the comment: I, actually want to make a 'configuration object' before running the 'pip' GUI. Therefore one of the parameters of the configuration object will be to detect the path to installed 'python.exe' in Windows. In order to get executable paths I need to read the Windows registry keys. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 00:29:41 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jun 2016 04:29:41 +0000 Subject: [issue27263] Tkinter sets the HOME environment variable, breaking scripts In-Reply-To: <1465352687.77.0.957460905896.issue27263@psf.upfronthosting.co.za> Message-ID: <1465619381.65.0.510024976515.issue27263@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What is the problem? That user sets incorrect TCL_LIBRARY? I don't know how _tkinter can distinguish correct TCL_LIBRARY from the incorrect one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 00:38:12 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jun 2016 04:38:12 +0000 Subject: [issue25733] Code and IDLE should catch all compile errors. In-Reply-To: <1448461598.38.0.392041411432.issue25733@psf.upfronthosting.co.za> Message-ID: <1465619892.3.0.621358639625.issue25733@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: SystemError is serious bug. Please open separate issue for this. > Why does compile not support null bytes in the first place? Due to implementation detail of CPython tokenizer. I uses NUL-terminated C strings. Yet one possible exception: MemoryError. I agree that the long tuple should be replaced by Exception. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 00:40:05 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jun 2016 04:40:05 +0000 Subject: [issue27173] Modern Unix key bindings for IDLE In-Reply-To: <1464766185.36.0.150155479026.issue27173@psf.upfronthosting.co.za> Message-ID: <1465620005.35.0.501297092721.issue27173@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +IDLE: Fix deletion of custom themes and key bindings _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 00:43:08 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jun 2016 04:43:08 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1465620188.08.0.778748885228.issue27051@psf.upfronthosting.co.za> Terry J. Reedy added the comment: sys.executable has the path to the current executable. But you don't even need that. When you import pip, it gets that itself to find site-packages. You are making this way too complicated and are trying to do what pip can do. I don't see that we need to know the system. Pip does that. You don't need to know all installed pythons, certainly not to begin. The first thing is to install to the current version. Expand on that later. Don't worry about virtual environments. Beginners don't know what they are, and this is aimed at beginners. 3.6.0a2 will be tagged on Sunday, and I can look at this more after that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 00:52:08 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jun 2016 04:52:08 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1465620728.03.0.858539248133.issue5124@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It would be better to exclude TEntry from the list. This is a hack, and as every hack it can be not fully compatible with future Tk versions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 00:56:48 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jun 2016 04:56:48 +0000 Subject: [issue27263] Tkinter sets the HOME environment variable, breaking scripts In-Reply-To: <1465352687.77.0.957460905896.issue27263@psf.upfronthosting.co.za> Message-ID: <1465621008.17.0.266906161179.issue27263@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Python does not set TCL_LIBRARY. _tkinter finds tcl/tk installed with Python at its known location for the platform. tkinter and IDLE work fine for months. Then user installs another program. That other software (not user, and unbeknownst to the user) sets TCL_LIBRARY to something that _tkinter cannot use. I am guessing that _tkinter, seeing TCL_LIBRARY, tries to use alternate install, cannot, and gives up, instead of falling back to the python-tcl it was using for months. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 01:02:53 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jun 2016 05:02:53 +0000 Subject: [issue27263] Tkinter sets the HOME environment variable, breaking scripts In-Reply-To: <1465352687.77.0.957460905896.issue27263@psf.upfronthosting.co.za> Message-ID: <1465621373.52.0.515854566541.issue27263@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is Windows specific issue, I can't help with this, sorry. Zach should be more experienced in this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 01:23:34 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jun 2016 05:23:34 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1465622614.12.0.34143889274.issue5124@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I had some trouble committing and pushing these patches. After deleting TEntry and committed the 2.7 and 3.5 patches and tried to do the usual 3.5 to default forward merge in TortoiseHG. I got % hg merge --tool :merge --verbose 101861 resolving manifests abort: case-folding collision between Lib/idlelib/pyshell.py and Lib/idlelib/PyShell.py [command returned code 255 Fri Jun 10 22:33:09 2016] This seems to be a known problem. After some effort to resolve the situation, I gave up and used my replaced my repository with a copy of my backup copy, to undo the things I had tried. Since the renames on 5/22, I have done other merges without problem, but I rechecked and none involved a file where case was the only difference. I will try again by temporarily renaming pyshell back to PyShell first. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 01:25:17 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 11 Jun 2016 05:25:17 +0000 Subject: [issue24136] document PEP 448: unpacking generalization In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za> Message-ID: <1465622717.19.0.77941477666.issue24136@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a new patch that also updates the documentation for list etc displays as well as function calls. Let me know what you think. The 3.5 What?s New notes were written separately; Neil?s patch was never applied. But I have rescued his update for functools.partial() in my new patch. While experimenting with the current behaviour, I found some surprising inconsistencies. The following syntaxes are allowed: >>> x, *y >>> a = x, *y >>> f"{x, *y}" # New in 3.6 >>> async def f(): await x, *y But the following all produce ?SyntaxError: invalid syntax?: >>> a += x, *y >>> eval("x, *y") >>> def f(): return x, *y >>> def f(): yield x, *y >>> for i in x, *y: ... Also, the expressions allowed for unpacking in general are more limited than in function calls: >>> f(x, *y == z) # Allowed >>> (x, *y == z) SyntaxError: invalid syntax ---------- Added file: http://bugs.python.org/file43339/unpacking-doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 01:26:38 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 11 Jun 2016 05:26:38 +0000 Subject: [issue27243] __aiter__ should return async iterator instead of awaitable In-Reply-To: <1465240896.52.0.994549894653.issue27243@psf.upfronthosting.co.za> Message-ID: <1465622798.96.0.433853096396.issue27243@psf.upfronthosting.co.za> Martin Panter added the comment: I didn?t realize, sorry for the noise ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 01:28:44 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 11 Jun 2016 05:28:44 +0000 Subject: [issue20699] Document that binary IO classes work with bytes-likes objects In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za> Message-ID: <1465622924.97.0.355148435402.issue20699@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for you help figuring this out Serhiy, especially for the Python 2 case. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 01:30:55 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 11 Jun 2016 05:30:55 +0000 Subject: [issue27233] Missing documentation for PyOS_FSPath In-Reply-To: <1465146030.9.0.386709465455.issue27233@psf.upfronthosting.co.za> Message-ID: <1465623055.82.0.14903669532.issue27233@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 01:53:04 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jun 2016 05:53:04 +0000 Subject: [issue27115] IDLE/tkinter: in simpledialog, != [OK] click In-Reply-To: <1464132389.32.0.350798699754.issue27115@psf.upfronthosting.co.za> Message-ID: <1465624384.1.0.872216551854.issue27115@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is not Tkinter issue, but IDLE issue. Other similar cases: Open search dialog and find something. The status bar is not updated. It is updated only if you close the search dialog. Select a text and delete it by a mouse. The status bar is not updated. Choice the Edit|Redo action by a mouse. The status bar is not updated. ---------- components: -Tkinter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 01:58:43 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jun 2016 05:58:43 +0000 Subject: [issue20699] Document that binary IO classes work with bytes-likes objects In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za> Message-ID: <1465624723.17.0.130572396384.issue20699@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, I forgot to say my LGTM on your last patch. It LGTM. But I'm feeling the documentation epic about bytes-like objects is far from the end. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 02:03:21 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 11 Jun 2016 06:03: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: <1465625001.29.0.619262207219.issue16484@psf.upfronthosting.co.za> Martin Panter added the comment: My guess is the file.startswith(basedir) in the getdocloc() method is getting tricked by non-canonical paths (e.g. lowercase vs uppercase C: drive?). Would it help to use something like os.path.normcase(), or maybe os.path.commonpath(), pathlib.PurePath.parts or PurePath.relative_to()? file = inspect.getabsfile(object) ... basedir = os.path.normcase(basedir) if (... (file.startswith(basedir) and ... Also, in the new get_pydoc_link() function, is that os.path.join() call meant to be there? basedir = os.path.join(dirname(dirname(__file__))) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 02:07:01 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 Jun 2016 06:07:01 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <20160611060658.11495.93425.5F777457@psf.io> Roundup Robot added the comment: New changeset 99760b6a181e by Terry Jan Reedy in branch 'default': Issue #5124: Temporary pyshell rename to avoid case-folding collision in merge. https://hg.python.org/cpython/rev/99760b6a181e New changeset 6c469b50e198 by Terry Jan Reedy in branch '2.7': Issue #5124: Paste with selection should always replace. https://hg.python.org/cpython/rev/6c469b50e198 New changeset f8b40e0d5913 by Terry Jan Reedy in branch '3.5': Issue #5124: Paste with selection should always replace. https://hg.python.org/cpython/rev/f8b40e0d5913 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 02:10:18 2016 From: report at bugs.python.org (Zachary Ware) Date: Sat, 11 Jun 2016 06:10:18 +0000 Subject: [issue27263] Tkinter sets the HOME environment variable, breaking scripts In-Reply-To: <1465352687.77.0.957460905896.issue27263@psf.upfronthosting.co.za> Message-ID: <1465625418.79.0.0536038337423.issue27263@psf.upfronthosting.co.za> Zachary Ware added the comment: For the original issue, I agree with Eryk that about the best we can do is to document that Tcl sets HOME as "%HOMEDRIVE%%HOMEPATH%" or "c:\" if both of those are not set. I wonder about removing (or de-preferring) HOME in os.path.expanduser, but that would be a significantly backward incompatible change. Since HOME is not set by default on Windows, setting it is the easiest way to manipulate os.path.expanduser, and changing it is going to break things. The TCL_LIBRARY issue is completely separate. I rewrote the logic that used to be in tkinter._fix for 3.5, it's now a part of _tkinter initialization and TCL_LIBRARY is no longer set (permanently) by tkinter (TK_LIBRARY is not set or inspected at all anymore, except by Tk itself). I did this in an effort to avoid the environment warnings in the tkinter/IDLE tests, but apparently missed the HOME issue at that point. Anyhow, we could theoretically unset TCL_LIBRARY (and TK_LIBRARY) in that initialization code, possibly conditional on whether TCL_VERSION can be found in the content of TCL_LIBRARY (the assumption being that a library for the same major version of Tcl ought to work anyway). However, without that conditional, that would be another big backward compatibility issue; setting {TCL,TK}_LIBRARY is a legitimate way to point tkinter towards a non-standard Tcl/Tk library location (e.g. in an embedding situation). With conditional clearing of {TCL,TK}_LIBRARY, we're still at the mercy of a just plain bad setting that just happens to contain the magic string that makes it look acceptable. I'm -1 on making such a change anyway. We've avoided permanently setting TCL_LIBRARY for many many years, other applications can figure out how to avoid it as well. We can't try to clean up messes made by other badly behaved programs, that way lies madness. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 02:11:21 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 Jun 2016 06:11:21 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <20160611061118.114300.85633.623EEE09@psf.io> Roundup Robot added the comment: New changeset 095e79636663 by Terry Jan Reedy in branch 'default': Issue #5124: rename PyShell back to pyshell and patch test for 3.6 https://hg.python.org/cpython/rev/095e79636663 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 02:12:11 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jun 2016 06:12:11 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1465625531.37.0.12924996753.issue5124@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 02:25:01 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 11 Jun 2016 06:25:01 +0000 Subject: [issue27272] random.Random should not read 2500 bytes from urandom In-Reply-To: <1465423096.81.0.204885224668.issue27272@psf.upfronthosting.co.za> Message-ID: <1465626301.45.0.965471169964.issue27272@psf.upfronthosting.co.za> Martin Panter added the comment: Victor originally opened this mentioning a 256-byte limit. I guess that comes from Open BSD?s getentropy() function: . Solaris?s getrandom() function has a similar limit, but of 1024 bytes. But Python already works around these limits by doing multiple calls. So if it really is valid to get 2500 bytes with as much entropy as possible, maybe there is no problem and we leave things as they are. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 02:26:14 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jun 2016 06:26:14 +0000 Subject: [issue27115] IDLE/tkinter: in simpledialog, != [OK] click In-Reply-To: <1464132389.32.0.350798699754.issue27115@psf.upfronthosting.co.za> Message-ID: <1465626374.55.0.696626267374.issue27115@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Okay, will take a look at the status bar code and update mechanism. ---------- assignee: -> terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 02:58:26 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 Jun 2016 06:58:26 +0000 Subject: [issue27262] IDLE: move Aqua context menu code to maxosx In-Reply-To: <1465352483.17.0.330062690814.issue27262@psf.upfronthosting.co.za> Message-ID: <20160611065823.11495.28318.C3C3356B@psf.io> Roundup Robot added the comment: New changeset 374dd14cf0e5 by Ned Deily in branch 'default': Issue #27262: fix missing parameter typo https://hg.python.org/cpython/rev/374dd14cf0e5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 03:33:22 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jun 2016 07:33:22 +0000 Subject: [issue27263] Tkinter sets the HOME environment variable, breaking scripts In-Reply-To: <1465352687.77.0.957460905896.issue27263@psf.upfronthosting.co.za> Message-ID: <1465630402.78.0.944130097631.issue27263@psf.upfronthosting.co.za> Terry J. Reedy added the comment: #14576 is more or less about making better use of USERPROFILE when the value returned by expanduser to config.IdleConf.GetUserCfgDir fails. Now that I know that tcl always sets HOME (or pieces that are joined back together to make HOME), so that expanduser never fails (?), this might make some sense - but only if they are not the same. Zach, I was thinking that _tkinter read TCL_LIBRARY to start tcl, but your answer suggests that it is instead read by tcl. The problem with bad TCL_LIBRARY is that if IDLE is started normally, there is no error message. Even if the user tries starting in the console, the message is almost useless. I "set TCL_LIBRARY=NONE" and got ... File "C:\Programs\Python35\lib\tkinter\__init__.py", line 1867, in __init__ self.tk = _tkinter.create(screenName, baseName, className, interactive, wantobjects, useTk, sync, use) _tkinter.TclError: Can't find a usable init.tcl in the following directories: NONE C:/Programs/Python35/lib/tcl8.6 C:/Programs/lib/tcl8.6 C:/lib/tcl8.6 C:/Programs/library C:/library C:/tcl8.6.4/library C:/tcl8.6.4/library Everything after NONE is nonsensical. The IDLE doc needs a new sections "If IDLE does not start:. Now I could write a troubleshooting note explaining for this note to ignore everything after the first item, and that the first item is an unusable setting of TCL_LIBRARY set by something or someone other than Python/Tkinter/IDLE. I tried the same experiment with TK_LIBRARY and could see no effect. ---------- assignee: -> docs at python components: +Documentation, IDLE nosy: +docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 03:56:05 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Sat, 11 Jun 2016 07:56:05 +0000 Subject: [issue27288] secrets should use getrandom() on Linux In-Reply-To: <1465588599.3.0.867244099768.issue27288@psf.upfronthosting.co.za> Message-ID: <1465631765.71.0.384024260297.issue27288@psf.upfronthosting.co.za> Steven D'Aprano added the comment: I don't want to start another huge thread on python-dev unless really necessary. What should happen to random.SystemRandom? (1) nothing, it stays as it is, and if ``secrets`` needs better, it can subclass it; (2) it changes to use ``os.getrandom``, and then ``secrets`` can continue to expose ``SystemRandom``. If it comes to a vote, I'm +1 on option 2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 03:59:05 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jun 2016 07:59:05 +0000 Subject: [issue27115] IDLE/tkinter: in simpledialog, != [OK] click In-Reply-To: <1464132389.32.0.350798699754.issue27115@psf.upfronthosting.co.za> Message-ID: <1465631945.93.0.0647779756682.issue27115@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If you close the Goto dialog by pressing , the KeyRelease event is sent to the editor window. This triggers the <> event. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 04:03:15 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jun 2016 08:03:15 +0000 Subject: [issue27262] IDLE: move Aqua context menu code to maxosx In-Reply-To: <1465352483.17.0.330062690814.issue27262@psf.upfronthosting.co.za> Message-ID: <1465632195.72.0.499454302752.issue27262@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I will add a test that calls setupApp, which would have failed with an error. I will also remove the call to _init_tk_type in setupApp, and let it be called when needed by the first isMacTk function called. Test code can partly simulate being on a particular type of Mac by setting _tk_type. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 04:05:23 2016 From: report at bugs.python.org (Christian Heimes) Date: Sat, 11 Jun 2016 08:05:23 +0000 Subject: [issue27272] random.Random should not read 2500 bytes from urandom In-Reply-To: <1465596460.62.0.631064042432.issue27272@psf.upfronthosting.co.za> Message-ID: Christian Heimes added the comment: On 2016-06-11 00:07, Raymond Hettinger wrote: > > Raymond Hettinger added the comment: > >> But I'll be happiest if nothing changes here (given that Guido ruled >> yesterday that Python's current urandom() implementation has to be >> reverted to once again match Linux's non-blocking urandom() behavior). > > With urandom() behavior restored, can we close this? No, the import of random is still broken on all BSD platforms during early boot. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 04:32:51 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 Jun 2016 08:32:51 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <20160611083247.101686.26899.2D2EA2B6@psf.io> Roundup Robot added the comment: New changeset 3017e41b0c99 by Terry Jan Reedy in branch '2.7': Issue #5124: NEWS entries. https://hg.python.org/cpython/rev/3017e41b0c99 New changeset 62b949a179cb by Terry Jan Reedy in branch '3.5': Issue #5124: NEWS entries. https://hg.python.org/cpython/rev/62b949a179cb New changeset 2fc15579606b by Terry Jan Reedy in branch 'default': Merge Issue #5124: NEWS entries. https://hg.python.org/cpython/rev/2fc15579606b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 04:46:07 2016 From: report at bugs.python.org (Larry Hastings) Date: Sat, 11 Jun 2016 08:46:07 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465634767.34.0.491436089345.issue26839@psf.upfronthosting.co.za> Larry Hastings added the comment: Colm Buckley: I've read the code, *and* stepped through it, and AFAICT it is no longer even possible for Python on Linux to call getrandom() in a blocking way. Thanks for doing this! I'm marking the issue as closed. ---------- stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 04:52:02 2016 From: report at bugs.python.org (Larry Hastings) Date: Sat, 11 Jun 2016 08:52:02 +0000 Subject: [issue26556] Update expat to 2.2.1 In-Reply-To: <1457951495.3.0.910401967595.issue26556@psf.upfronthosting.co.za> Message-ID: <1465635122.86.0.728746544455.issue26556@psf.upfronthosting.co.za> Larry Hastings added the comment: Christian: I don't see any checkins on this issue, and I tag 3.4.4 rc1 and 3.5.2 rc1 in about twelve hours. As I mentioned to you in person at the PyCon 2016 sprints, I'm not holding up either of these releases for the expat update. If this is still open when it's time for me to tag those releases, I'll flip this to "deferred blocker". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 04:55:50 2016 From: report at bugs.python.org (Michael Felt) Date: Sat, 11 Jun 2016 08:55:50 +0000 Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX) In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za> Message-ID: <1465635350.39.0.603098068831.issue26439@psf.upfronthosting.co.za> Michael Felt added the comment: * You may also just modify my "attempt" in _aixutil.py I recall you said something about the p.wait() being a potential to hang, but I also want to be sure the subprocess has exited properly - as it is not something to be running in parallel - and be sure that the "lines" I return are complete. And, I see I have more underscores to remove :) * I shall work on the comments you requested asap. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 05:23:24 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jun 2016 09:23:24 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1465637004.04.0.679150371797.issue5124@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: entry=entry in test is not needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 06:07:54 2016 From: report at bugs.python.org (Christian Heimes) Date: Sat, 11 Jun 2016 10:07:54 +0000 Subject: [issue27292] Warn users that os.urandom() can return insecure values Message-ID: <1465639674.0.0.865291084778.issue27292@psf.upfronthosting.co.za> New submission from Christian Heimes: In #26839 os.urandom() was made non-blocking and non-exception-raising on Linux. As a result os.urandom() is no longer a CSPRNG under some conditions as it can and will return predictable random values without any sort of warning or error flag. These conditions are (including but not limited to): * early boot state * virtualization without host-passthrough, e.g. virtio-rng * embedded devices without hardware RNG or RTC, e.g. raspberry pi Please ensure that the documentation properly warns users about these edge cases. We might also want to add that os.urandom() can block on other platforms, e.g. FreeBSD and OpenBSD. ---------- components: Library (Lib) keywords: 3.5regression messages: 268205 nosy: christian.heimes, dstufft, haypo, larry, ned.deily priority: release blocker severity: normal stage: needs patch status: open title: Warn users that os.urandom() can return insecure values type: security versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 06:30:58 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Sat, 11 Jun 2016 10:30:58 +0000 Subject: [issue27293] Summarize issues related to urandom, getrandom etc in secrets documentation Message-ID: <1465641058.72.0.740134205443.issue27293@psf.upfronthosting.co.za> New submission from Steven D'Aprano: Write some documentation for the ``secrets`` module summarizing the issues relating to /dev/[u]random, getrandom, etc. There's a lot of confusion about these issues, and the web contains a lot of misinformation, so being able to point to the secrets docs for a summary will be useful for further discussions, and to help programmers pick the right solution. I know the Python docs cannot be the definitive source of information about OS features, but they can provide enough of a summary to allow users to make informed decisions. ---------- assignee: steven.daprano components: Documentation messages: 268206 nosy: christian.heimes, dstufft, haypo, larry, ned.deily, steven.daprano priority: normal severity: normal stage: needs patch status: open title: Summarize issues related to urandom, getrandom etc in secrets documentation versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 06:33:29 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Sat, 11 Jun 2016 10:33:29 +0000 Subject: [issue27292] Warn users that os.urandom() can return insecure values In-Reply-To: <1465639674.0.0.865291084778.issue27292@psf.upfronthosting.co.za> Message-ID: <1465641209.54.0.661588151972.issue27292@psf.upfronthosting.co.za> Steven D'Aprano added the comment: Relevant: issue #27293 (I've taken the liberty of subscribing those on this issues nosy list to the new issue, I hope that's okay) ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 06:45:33 2016 From: report at bugs.python.org (Christian Heimes) Date: Sat, 11 Jun 2016 10:45:33 +0000 Subject: [issue27293] Summarize issues related to urandom, getrandom etc in secrets documentation In-Reply-To: <1465641058.72.0.740134205443.issue27293@psf.upfronthosting.co.za> Message-ID: <1465641933.28.0.0797017278442.issue27293@psf.upfronthosting.co.za> Christian Heimes added the comment: Thx Steven. tl;dr The OS' / Kernel's CSPRNG is safe-to-use as long as one uses the correct API: getrandom(flags=0) on Linux, getentropy() on BSD, CryptGenRandom() on Windows. Myths about Linux's urandom: http://www.2uo.de/myths-about-urandom/ Example why user-space CSPRNG are bad: https://gist.github.com/tiran/a9ba8c51cc7d1b75d3bc1d3f24411b4c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 08:35:57 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jun 2016 12:35:57 +0000 Subject: [issue27294] Better repr for Tkinter event objects Message-ID: <1465648557.25.0.737232700025.issue27294@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch adds better repr for tkinter.Event objects. Currently default repr shows only class name (always the same) and object address (not interesting, since event objects are short-living). The patch makes repr showing most event attributes in human-readable form. For testing run following script. Press any keys (with modifiers), move and click mouse, select text, move and resize the window, switch to other windows. import tkinter t = tkinter.Text() t.pack() t.bind("<>", print) t.bind("<>", print) for k in tkinter.EventType: try: t.event_add("<>", '<%s>' % k) except tkinter.TclError: pass tkinter.mainloop() ---------- components: Tkinter messages: 268209 nosy: serhiy.storchaka, terry.reedy priority: normal severity: normal stage: patch review status: open title: Better repr for Tkinter event objects type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 08:48:49 2016 From: report at bugs.python.org (Cory Benfield) Date: Sat, 11 Jun 2016 12:48:49 +0000 Subject: [issue27292] Warn users that os.urandom() can return insecure values In-Reply-To: <1465639674.0.0.865291084778.issue27292@psf.upfronthosting.co.za> Message-ID: <1465649329.76.0.224427026392.issue27292@psf.upfronthosting.co.za> Changes by Cory Benfield : ---------- nosy: +Lukasa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 09:29:11 2016 From: report at bugs.python.org (rugk) Date: Sat, 11 Jun 2016 13:29:11 +0000 Subject: [issue24107] Add support for retrieving the certificate chain In-Reply-To: <1430502325.36.0.624144757291.issue24107@psf.upfronthosting.co.za> Message-ID: <1465651751.41.0.999456570094.issue24107@psf.upfronthosting.co.za> Changes by rugk <2051080c at opayq.com>: ---------- nosy: +rugk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 09:29:40 2016 From: report at bugs.python.org (rugk) Date: Sat, 11 Jun 2016 13:29:40 +0000 Subject: [issue24107] Add support for retrieving the certificate chain In-Reply-To: <1430502325.36.0.624144757291.issue24107@psf.upfronthosting.co.za> Message-ID: <1465651780.76.0.240512001229.issue24107@psf.upfronthosting.co.za> rugk added the comment: Is this issue the same as https://bugs.python.org/issue25529? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 09:31:46 2016 From: report at bugs.python.org (Cory Benfield) Date: Sat, 11 Jun 2016 13:31:46 +0000 Subject: [issue27288] secrets should use getrandom() on Linux In-Reply-To: <1465588599.3.0.867244099768.issue27288@psf.upfronthosting.co.za> Message-ID: <1465651906.99.0.136587554025.issue27288@psf.upfronthosting.co.za> Changes by Cory Benfield : ---------- nosy: +Lukasa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 09:49:52 2016 From: report at bugs.python.org (James Lu) Date: Sat, 11 Jun 2016 13:49:52 +0000 Subject: [issue27295] heaps library does not have support for max heap Message-ID: <1465652992.55.0.603716004725.issue27295@psf.upfronthosting.co.za> New submission from James Lu: Both max heaps and min heaps have uses in algorithms. Some algorithms require both. Why doesn't the heapq library support max heaps (not including the private _heapify_max() method)? ---------- components: Library (Lib) messages: 268211 nosy: James.Lu priority: normal severity: normal status: open title: heaps library does not have support for max heap _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 09:51:35 2016 From: report at bugs.python.org (SilentGhost) Date: Sat, 11 Jun 2016 13:51:35 +0000 Subject: [issue27295] heaps library does not have support for max heap In-Reply-To: <1465652992.55.0.603716004725.issue27295@psf.upfronthosting.co.za> Message-ID: <1465653095.63.0.49060926589.issue27295@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +rhettinger, stutzbach type: -> enhancement versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 10:04:01 2016 From: report at bugs.python.org (rugk) Date: Sat, 11 Jun 2016 14:04:01 +0000 Subject: [issue27296] Urllib/Urlopen IncompleteRead with HTTP header with new line characters Message-ID: <1465653841.12.0.169767702558.issue27296@psf.upfronthosting.co.za> New submission from rugk: Test file: https://gist.github.com/rugk/3ea35d04d66c2295e02d0b6cb6d822a2 Python version: 2.7.5+ Issue description: When Urllib gets a HTTP header with line breaks/new line characters it shows the following error: ``` Traceback (most recent call last): File "./downloadtest.py", line 17, in respdata = resp.read() File "/usr/lib/python2.7/socket.py", line 351, in read data = self._sock.recv(rbufsize) File "/usr/lib/python2.7/httplib.py", line 543, in read return self._read_chunked(amt) File "/usr/lib/python2.7/httplib.py", line 597, in _read_chunked raise IncompleteRead(''.join(value)) httplib.IncompleteRead: IncompleteRead(0 bytes read) ``` Compare the results with curl... # Broken version ## curl ``` $curl -i https://rugk.dedyn.io/pythontest/bug HTTP/1.1 200 OK Server: nginx Date: Sat, 11 Jun 2016 13:34:36 GMT Content-Type: text/plain Transfer-Encoding: chunked Connection: keep-alive Strict-Transport-Security: max-age=15768000; includeSubDomains; preload Public-Key-Pins: pin-sha256="306cc4Cc2py0x48ZiX2G5vt5OxF9afmouqccrFqb8Jc="; pin-sha256="dWkVtg0EuckExnceVFvu3tuEApEygbxr2FPTlpHAUrQ="; pin-sha256="DjjVxb2/6kxfX8qyP2TE/j8B0tOB60MhTTvJdNsFPaU="; max-age=5184000; includeSubDomains; report-uri="https://rugkdyndns.report-uri.io/r/default/hpkp/enforce" Bug: ``` ## python ``` $ ./downloadtest.py https://rugk.dedyn.io/pythontest/bug Accessing https://rugk.dedyn.io/pythontest/bug... Traceback (most recent call last): File "./downloadtest.py", line 17, in respdata = resp.read() File "/usr/lib/python2.7/socket.py", line 351, in read data = self._sock.recv(rbufsize) File "/usr/lib/python2.7/httplib.py", line 543, in read return self._read_chunked(amt) File "/usr/lib/python2.7/httplib.py", line 597, in _read_chunked raise IncompleteRead(''.join(value)) httplib.IncompleteRead: IncompleteRead(0 bytes read) ``` # working version ## curl ``` $ curl -i https://rugk.dedyn.io/pythontest/works HTTP/1.1 200 OK Server: nginx Date: Sat, 11 Jun 2016 13:46:09 GMT Content-Type: text/plain Transfer-Encoding: chunked Connection: keep-alive Strict-Transport-Security: max-age=15768000; includeSubDomains; preload Public-Key-Pins: pin-sha256="306cc4Cc2py0x48ZiX2G5vt5OxF9afmouqccrFqb8Jc="; pin-sha256="dWkVtg0EuckExnceVFvu3tuEApEygbxr2FPTlpHAUrQ="; pin-sha256="DjjVxb2/6kxfX8qyP2TE/j8B0tOB60MhTTvJdNsFPaU="; max-age=5184000; includeSubDomains; report-uri="https://rugkdyndns.report-uri.io/r/default/hpkp/enforce" Bug: ``` ## python ``` $ ./downloadtest.py https://rugk.dedyn.io/pythontest/works Accessing https://rugk.dedyn.io/pythontest/works... RAW: Bug: Decoded: Bug: ``` You can also test it with HTTP URLs and get the same result. In usual browsers every request works... I cannot guarantee that the test server will stay available... ---------- components: Library (Lib) messages: 268212 nosy: rugk priority: normal severity: normal status: open title: Urllib/Urlopen IncompleteRead with HTTP header with new line characters type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 10:22:09 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 11 Jun 2016 14:22:09 +0000 Subject: [issue25529] Provide access to the validated certificate chain in ssl module In-Reply-To: <1446403180.28.0.269111083171.issue25529@psf.upfronthosting.co.za> Message-ID: <1465654929.9.0.414309890153.issue25529@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Add support for retrieving the certificate chain _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 10:38:32 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jun 2016 14:38:32 +0000 Subject: [issue26754] PyUnicode_FSDecoder() accepts arbitrary iterable In-Reply-To: <1460621170.51.0.766625206789.issue26754@psf.upfronthosting.co.za> Message-ID: <1465655912.12.0.991931317589.issue26754@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Proposed patch makes PyUnicode_FSDecoder() rejecting arbitrary iterables. ---------- assignee: -> serhiy.storchaka keywords: +patch stage: -> patch review versions: +Python 3.5 Added file: http://bugs.python.org/file43340/PyUnicode_FSDecoder-no-list.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 10:52:47 2016 From: report at bugs.python.org (aixtools) Date: Sat, 11 Jun 2016 14:52:47 +0000 Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX) In-Reply-To: <1465533232.8.0.72096957327.issue26439@psf.upfronthosting.co.za> Message-ID: <02765f29-5488-436b-4dc8-041cffe32ca9@gmail.com> aixtools added the comment: On 6/10/2016 6:33 AM, Martin Panter wrote: > Martin Panter added the comment: > > Will try to change the existing code from os.popen to subprocess (Issue 26439) to set a better example for new code like this > > ---------- > dependencies: +avoid using a shell in ctypes.util: replace os.popen with subprocess > > _______________________________________ > Python tracker > > _______________________________________ I have added comments to _aixutil.py - but while doing so I came up with some thoughts re "special cases", where a) the member is not in a archive (i.e., looking for a file) b) the filename does not begin with "lib" c) CDLL.LoadLibrary(name) succeeds So, given that /usr/lib is default search path, and file FOO.so exists as /usr/lib/FOO.so - should find_library(name) return name, or None. d) name = ../some/where/Foo.so; CDLL.LoadLibrary("../some/where/Foo.so") works - should find_library(name) return name e) assume find_library("../some/where/Foo") returns ../some/where/libFoo.so, or None - again, given that ../some/where/libFoo.a does not exist ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 11:04:09 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 11 Jun 2016 15:04:09 +0000 Subject: [issue27296] Urllib/Urlopen IncompleteRead with HTTP header with new line characters In-Reply-To: <1465653841.12.0.169767702558.issue27296@psf.upfronthosting.co.za> Message-ID: <1465657449.69.0.17285343693.issue27296@psf.upfronthosting.co.za> Martin Panter added the comment: HTTP header fields are not supposed to have line breaks unless followed by a space or tab. So the server is actually providing a faulty response. However Python could do better at handling this case. There is already a bug open for this: Issue 24363. For the record, the full server response I get is: 'HTTP/1.1 200 OK\r\n' 'Server: nginx\r\n' 'Date: Sat, 11 Jun 2016 14:47:19 GMT\r\n' 'Content-Type: text/plain\r\n' 'Transfer-Encoding: chunked\r\n' 'Connection: close\r\n' 'Vary: Accept-Encoding\r\n' 'Strict-Transport-Security: max-age=15768000; includeSubDomains; preload\r\n' 'Public-Key-Pins: \n' 'pin-sha256="306cc4Cc2py0x48ZiX2G5vt5OxF9afmouqccrFqb8Jc=";\n' 'pin-sha256="dWkVtg0EuckExnceVFvu3tuEApEygbxr2FPTlpHAUrQ=";\n' 'pin-sha256="DjjVxb2/6kxfX8qyP2TE/j8B0tOB60MhTTvJdNsFPaU=";\n' 'max-age=5184000; includeSubDomains;\n' 'report-uri="https://rugkdyndns.report-uri.io/r/default/hpkp/enforce"\r\n' '\r\n' '28\r\n' 'Bug: https://bugs.python.org/issue27296\n' '\r\n' '0\r\n' '\r\n' ---------- nosy: +martin.panter resolution: -> duplicate status: open -> closed superseder: -> httplib fails to handle semivalid HTTP headers _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 11:08:06 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 11 Jun 2016 15:08:06 +0000 Subject: [issue24363] httplib fails to handle semivalid HTTP headers In-Reply-To: <1433257563.79.0.772954216205.issue24363@psf.upfronthosting.co.za> Message-ID: <1465657686.35.0.554517043111.issue24363@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 11:17:40 2016 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 11 Jun 2016 15:17:40 +0000 Subject: [issue27243] __aiter__ should return async iterator instead of awaitable In-Reply-To: <1465240896.52.0.994549894653.issue27243@psf.upfronthosting.co.za> Message-ID: <1465658260.21.0.377466017953.issue27243@psf.upfronthosting.co.za> Yury Selivanov added the comment: > I didn?t realize, sorry for the noise Actually thanks for reporting this, Martin. I didn't realize that sys.version_info was 3.5.1 in 3.5 branch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 11:21:00 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 Jun 2016 15:21:00 +0000 Subject: [issue27223] _read_ready and _write_ready should respect _conn_lost In-Reply-To: <1465089633.03.0.133113775178.issue27223@psf.upfronthosting.co.za> Message-ID: <20160611152056.87576.53695.9D096318@psf.io> Roundup Robot added the comment: New changeset 9512cfd53903 by Yury Selivanov in branch '3.5': Issue #27223: aio: Fix _read_ready and _write_ready to respect _conn_lost. https://hg.python.org/cpython/rev/9512cfd53903 New changeset d56b3e5ebfe2 by Yury Selivanov in branch 'default': Merge 3.5 (issue #27223) https://hg.python.org/cpython/rev/d56b3e5ebfe2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 11:22:11 2016 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 11 Jun 2016 15:22:11 +0000 Subject: [issue27223] _read_ready and _write_ready should respect _conn_lost In-Reply-To: <1465089633.03.0.133113775178.issue27223@psf.upfronthosting.co.za> Message-ID: <1465658531.96.0.319994654091.issue27223@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thanks, ?ukasz! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 11:43:02 2016 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 11 Jun 2016 15:43:02 +0000 Subject: [issue27223] _read_ready and _write_ready should respect _conn_lost In-Reply-To: <1465089633.03.0.133113775178.issue27223@psf.upfronthosting.co.za> Message-ID: <1465659782.77.0.601741504014.issue27223@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 11:59:47 2016 From: report at bugs.python.org (Gareth Rees) Date: Sat, 11 Jun 2016 15:59:47 +0000 Subject: [issue20508] IndexError from ipaddress._BaseNetwork.__getitem__ has no message In-Reply-To: <1391519371.56.0.280883005316.issue20508@psf.upfronthosting.co.za> Message-ID: <1465660787.78.0.411457862845.issue20508@psf.upfronthosting.co.za> Gareth Rees added the comment: I've attached a revised patch that addresses Berker Peksag's concerns: 1. The message associated with the IndexError is now "address out of range" with no information about which address failed or why. 2. There's a new test case for an IndexError from an IPv6 address lookup. ---------- Added file: http://bugs.python.org/file43341/ipaddress.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 12:01:32 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 Jun 2016 16:01:32 +0000 Subject: [issue22970] asyncio: Cancelling wait() after notification leaves Condition in an inconsistent state In-Reply-To: <1417404582.01.0.276361050449.issue22970@psf.upfronthosting.co.za> Message-ID: <20160611160126.11470.46101.6DFE46F2@psf.io> Roundup Robot added the comment: New changeset 0bda9bc443ce by Yury Selivanov in branch '3.5': Issue #22970: asyncio: Fix inconsistency cancelling Condition.wait. https://hg.python.org/cpython/rev/0bda9bc443ce New changeset 00a9de0f3fdc by Yury Selivanov in branch 'default': Merge 3.5 (issue #22970) https://hg.python.org/cpython/rev/00a9de0f3fdc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 12:05:13 2016 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 11 Jun 2016 16:05:13 +0000 Subject: [issue22970] asyncio: Cancelling wait() after notification leaves Condition in an inconsistent state In-Reply-To: <1417404582.01.0.276361050449.issue22970@psf.upfronthosting.co.za> Message-ID: <1465661113.61.0.34607688851.issue22970@psf.upfronthosting.co.za> Yury Selivanov added the comment: I'm merging David's patch. I concur with David that the only viable way to fix this is to loop through the CancelledError until the lock is acquired (and Condition is in a right state). Thanks, David. It should make it to 3.5.2 now. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 12:15:31 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 Jun 2016 16:15:31 +0000 Subject: [issue27030] Remove deprecated re features In-Reply-To: <1463337497.02.0.81864271809.issue27030@psf.upfronthosting.co.za> Message-ID: <20160611161526.99278.56965.C4FA8C88@psf.io> Roundup Robot added the comment: New changeset 09d1af3fe332 by Serhiy Storchaka in branch 'default': Issue #27030: Unknown escapes consisting of ``'\'`` and ASCII letter in https://hg.python.org/cpython/rev/09d1af3fe332 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 12:16:31 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jun 2016 16:16:31 +0000 Subject: [issue27030] Remove deprecated re features In-Reply-To: <1463337497.02.0.81864271809.issue27030@psf.upfronthosting.co.za> Message-ID: <1465661791.95.0.12273322586.issue27030@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Jim for the review. ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 12:17:52 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jun 2016 16:17:52 +0000 Subject: [issue27029] Remove support of deprecated mode 'U' in zipfile In-Reply-To: <1463336602.94.0.363644818568.issue27029@psf.upfronthosting.co.za> Message-ID: <1465661872.12.0.967040478806.issue27029@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 12:24:49 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 Jun 2016 16:24:49 +0000 Subject: [issue27030] Remove deprecated re features In-Reply-To: <1463337497.02.0.81864271809.issue27030@psf.upfronthosting.co.za> Message-ID: <20160611162445.87501.1644.777EAA23@psf.io> Roundup Robot added the comment: New changeset 8ed3880e94e5 by Serhiy Storchaka in branch 'default': Issue #27030: The re.LOCALE flag now can be used only with bytes patterns. https://hg.python.org/cpython/rev/8ed3880e94e5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 12:26:16 2016 From: report at bugs.python.org (Gareth Rees) Date: Sat, 11 Jun 2016 16:26:16 +0000 Subject: [issue14376] sys.exit documents argument as "integer" but actually requires "subtype of int" In-Reply-To: <1332288480.19.0.200013792885.issue14376@psf.upfronthosting.co.za> Message-ID: <1465662376.05.0.434883588075.issue14376@psf.upfronthosting.co.za> Gareth Rees added the comment: Let's not allow the perfect to be the enemy of the good here. The issue I reported is a very specific one: in Python 2.7, if you pass a long to sys.exit, then the value of the long is not used as the exit code. This is bad because functions like os.spawnv that return exit codes (that you might reasonably want to pass on to sys.exit) can return them as long. My patch only proposes to address this one issue. In order to keep the impact as small as possible, I do not propose to make any other changes, or address any other problems. But in the comments here people have brought up THREE other issues: 1. Alexander Belopolsky expresses the concern that "(int)PyLong_AsLong(value) can silently convert non-zero error code to zero." This is not a problem introduced by my patch -- the current code is: exitcode = (int)PyInt_AsLong(value) which has exactly the same problem (because PyIntObject stores its value as a long). So this concern (even if valid) is not a reason to reject my patch. 2. Ethan Furman wrote: "we need to protect against overflow from to " But again, this is not a problem introduced by my patch. The current code says: exitcode = (int)PyInt_AsLong(value); and my patch does not change this line. The possibility of this overflow is not a reason to reject my patch. 3. Alexander says, "Passing anything other than one of the os.EX_* constants to sys.exit() is a bad idea" First, this is not a problem introduced by my patch. The existing code in Python 2.7 allows you to specify other exit codes. So this problem (if it is a problem) is not a reason to reject my patch. Second, this claim is surely not right -- when a subprocess fails it often makes sense to pass on the exit code of the subprocess, whatever that is. This is exactly the use case that I mentioned in my original report (that is, passing on the exit code from os.spawnv to sys.exit). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 12:30:16 2016 From: report at bugs.python.org (Tim Peters) Date: Sat, 11 Jun 2016 16:30:16 +0000 Subject: [issue27272] random.Random should not read 2500 bytes from urandom In-Reply-To: <1465423096.81.0.204885224668.issue27272@psf.upfronthosting.co.za> Message-ID: <1465662616.96.0.30963052286.issue27272@psf.upfronthosting.co.za> Tim Peters added the comment: Christian, you should really be the first to vote to close this. The title of this bug report is about whether it would be good to reduce the _number_ of bytes Random initialization consumes from os.urandom(), not whether to stop using os.urandom() entirely. But if I grasp your position, anyone who thinks Random initialization should continue using os.urandom() at all is, ipso facto, so insufferably ignorant they shouldn't even be allowed to express an opinion ;-) So, to me, your position on _this_ bug report is clear: no, merely reducing the number of os.urandom() bytes consumed is of no value whatsoever, so this report should be rejected. If you want random initialization to stop using os.urandom() entirely, that argument belongs in one of the other bug reports - trying to hijack this _different_ report just adds to the noise. I haven't seen an actual reason advanced to believe that reducing the number of bytes would help anything either, so I'd also like to see this closed. Note that, today, Guido suggested that Python's os.urandom() should grow a flag to specify the desired behavior (block; raise an exception; just keep going and maybe get lower-quality bytes). In that case, the default random initialization would surely pass the "just keep going" flag. In which case, I've still seen no reason to expect that reducing the number of bytes requested would help anything. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 12:33:14 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 Jun 2016 16:33:14 +0000 Subject: [issue27029] Remove support of deprecated mode 'U' in zipfile In-Reply-To: <1463336602.94.0.363644818568.issue27029@psf.upfronthosting.co.za> Message-ID: <20160611163310.27977.82415.8EC7B418@psf.io> Roundup Robot added the comment: New changeset bf8773b054cb by Serhiy Storchaka in branch 'default': Issue #27029: Removed deprecated support of universal newlines mode from ZipFile.open(). https://hg.python.org/cpython/rev/bf8773b054cb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 12:34:40 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jun 2016 16:34:40 +0000 Subject: [issue27294] Better repr for Tkinter event objects In-Reply-To: <1465648557.25.0.737232700025.issue27294@psf.upfronthosting.co.za> Message-ID: <1465662880.67.0.219337729907.issue27294@psf.upfronthosting.co.za> Terry J. Reedy added the comment: +1! This would be helpful for exploration and quite possibly for tests. Earlier this year, I bound to a custom function(event) printing event.x, event.y so I could discover how the line thickness of Canvas rectangles was distributed inside and outside the nominal dimensions. (Using a magnifier to click on exact pixels, I discovered the rule.) Being able to bind to print instead have been nice. There is no patch uploaded. In the absence of seeing what you did... Event.type should be decoded. The hex address should be replaced by at least the widget class, if not its path name (which would make readable names imperative!) The Event representation should be customized to the event type. For me, there is no tkinter.EventType. The <> binding worked to prove the idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 12:37:20 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jun 2016 16:37:20 +0000 Subject: [issue27029] Remove support of deprecated mode 'U' in zipfile In-Reply-To: <1463336602.94.0.363644818568.issue27029@psf.upfronthosting.co.za> Message-ID: <1465663040.5.0.687601750018.issue27029@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your review Jim. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 12:40:54 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jun 2016 16:40:54 +0000 Subject: [issue16182] readline: Wrong tab completion scope indices in Unicode terminals In-Reply-To: <1349813384.06.0.615857426211.issue16182@psf.upfronthosting.co.za> Message-ID: <1465663254.1.0.928188619449.issue16182@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Martin? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 12:46:18 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jun 2016 16:46:18 +0000 Subject: [issue22558] Missing doc links to source code for Python-coded modules. In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za> Message-ID: <1465663578.87.0.490374947064.issue22558@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- assignee: docs at python -> terry.reedy stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 12:50:41 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jun 2016 16:50:41 +0000 Subject: [issue27294] Better repr for Tkinter event objects In-Reply-To: <1465648557.25.0.737232700025.issue27294@psf.upfronthosting.co.za> Message-ID: <1465663841.95.0.97182213129.issue27294@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oops! Sorry, here is a patch. Event.type is decoded. The address of the Event object is omitted as don't having much sense (this is short-living object). The name of widget is omitted since it is too long and usually know (in any case you can easy print both widget and event). Only non-default set attributes are output (thus the output depends on the type of the event). ---------- keywords: +patch Added file: http://bugs.python.org/file43342/tkinter_event_repr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 13:01:01 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jun 2016 17:01:01 +0000 Subject: [issue27294] Better repr for Tkinter event objects In-Reply-To: <1465648557.25.0.737232700025.issue27294@psf.upfronthosting.co.za> Message-ID: <1465664461.25.0.282617372282.issue27294@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file43342/tkinter_event_repr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 13:02:33 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jun 2016 17:02:33 +0000 Subject: [issue27294] Better repr for Tkinter event objects In-Reply-To: <1465648557.25.0.737232700025.issue27294@psf.upfronthosting.co.za> Message-ID: <1465664553.85.0.86294904579.issue27294@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Sorry yet once. Uploaded patch contained experimental implementation. Here is cleaned patch. ---------- Added file: http://bugs.python.org/file43343/tkinter_event_repr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 13:05:53 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 11 Jun 2016 17:05:53 +0000 Subject: [issue20508] IndexError from ipaddress._BaseNetwork.__getitem__ has no message In-Reply-To: <1391519371.56.0.280883005316.issue20508@psf.upfronthosting.co.za> Message-ID: <1465664753.66.0.716939617482.issue20508@psf.upfronthosting.co.za> Berker Peksag added the comment: Thank you Gareth. I will commit ipaddress.patch this weekend. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 13:27:35 2016 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Sat, 11 Jun 2016 17:27:35 +0000 Subject: [issue27199] TarFile expose copyfileobj bufsize to improve throughput In-Reply-To: <1464980137.78.0.803567676795.issue27199@psf.upfronthosting.co.za> Message-ID: <1465666055.09.0.589934723701.issue27199@psf.upfronthosting.co.za> ?ukasz Langa added the comment: New feature -> 3.6. ---------- assignee: -> lukasz.langa stage: -> patch review versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 13:28:55 2016 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Sat, 11 Jun 2016 17:28:55 +0000 Subject: [issue27194] Tarfile superfluous truncate calls slows extraction. In-Reply-To: <1464929793.77.0.639155899875.issue27194@psf.upfronthosting.co.za> Message-ID: <1465666135.79.0.651436943146.issue27194@psf.upfronthosting.co.za> Changes by ?ukasz Langa : ---------- assignee: -> lukasz.langa stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 13:33:47 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jun 2016 17:33:47 +0000 Subject: [issue27294] Better repr for Tkinter event objects In-Reply-To: <1465648557.25.0.737232700025.issue27294@psf.upfronthosting.co.za> Message-ID: <1465666427.22.0.712607372879.issue27294@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Is this something that you might push before a2 tomorrow? (If I review now?) Or still in development? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 13:48:10 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jun 2016 17:48:10 +0000 Subject: [issue27294] Better repr for Tkinter event objects In-Reply-To: <1465648557.25.0.737232700025.issue27294@psf.upfronthosting.co.za> Message-ID: <1465667290.88.0.885303382885.issue27294@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If you have no something to add, I'll push the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 13:55:03 2016 From: report at bugs.python.org (rugk) Date: Sat, 11 Jun 2016 17:55:03 +0000 Subject: [issue27296] Urllib/Urlopen IncompleteRead with HTTP header with new line characters In-Reply-To: <1465653841.12.0.169767702558.issue27296@psf.upfronthosting.co.za> Message-ID: <1465667703.28.0.0333600487983.issue27296@psf.upfronthosting.co.za> rugk added the comment: Yeah, it might not be the standard or best practise to send such headers, but at least all mayor browsers and curl do not complain about this. Mayor browsers even threat this HPKP header as it is supposed. But instead of showing complex error messages Python could just ignore the malformed header... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 14:07:17 2016 From: report at bugs.python.org (Larry Hastings) Date: Sat, 11 Jun 2016 18:07:17 +0000 Subject: [issue27292] Warn users that os.urandom() can return insecure values In-Reply-To: <1465639674.0.0.865291084778.issue27292@psf.upfronthosting.co.za> Message-ID: <1465668437.91.0.0696837239674.issue27292@psf.upfronthosting.co.za> Larry Hastings added the comment: I don't think this is necessary, as the documentation for os.urandom() is already pretty good. Here's the relevant bit: This function returns random bytes from an OS-specific randomness source. The returned data should be unpredictable enough for cryptographic applications, though its exact quality depends on the OS implementation. On a Unix-like system this will query /dev/urandom, and on Windows it will use CryptGenRandom(). ISTM that the Python documentation doesn't generally indulge in warning users about specific shortcomings of particular platforms; if it did it would be littered with such warnings. Personally I'd approve of making the existing statements a little more forceful, like pulling it out into a red "warning" box and making it explicit that os.urandom() isn't any more sophisticated than the platform-specific technologies it uses. But that's as far as I'd go. I wouldn't add all the specifics you suggest. Technically I think this actually is my call, as I'm the "platform expert" for the posix module: https://docs.python.org/devguide/experts.html But really I think it's the call of the "Documentation Expert" for the relevant releases. This is a stylistic concern--should the Python docs delve into these sorts of details?--and that's really the domain of the DE. Georg Brandl is the DE for all currently-supported versions of Python. (Well, 2.7 has no official DE, but I think Georg is de facto DE for that release too.) I've nosied him here; hopefully he can tell us the standard Python doc aesthetic when it comes to these sorts of concerns. By the way, the Raspberry PI does have hardware RNG: http://scruss.com/blog/2013/06/07/well-that-was-unexpected-the-raspberry-pis-hardware-random-number-generator/ It required loading an extra driver, at least as of 2014. I concede I don't know what current crypto best-practices are on the PI. That's one good reason why I think the Python documentation doesn't indulge in these laundry lists of platform failings--such information has a tendency to become out-of-date without anyone noticing. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 14:11:41 2016 From: report at bugs.python.org (Larry Hastings) Date: Sat, 11 Jun 2016 18:11:41 +0000 Subject: [issue27292] Warn users that os.urandom() can return insecure values In-Reply-To: <1465639674.0.0.865291084778.issue27292@psf.upfronthosting.co.za> Message-ID: <1465668701.8.0.477516310166.issue27292@psf.upfronthosting.co.za> Larry Hastings added the comment: Oh, and, for 3.6 I would definitely support adding a mention of "Instead of using this function directly, we recommend you use the token_bytes() function in the secrets module", blah blah best practices etc. That goes for os.getrandom() too, if we add it to 3.6 (which I rather suspect we will). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 14:18:02 2016 From: report at bugs.python.org (Larry Hastings) Date: Sat, 11 Jun 2016 18:18:02 +0000 Subject: [issue27293] Summarize issues related to urandom, getrandom etc in secrets documentation In-Reply-To: <1465641058.72.0.740134205443.issue27293@psf.upfronthosting.co.za> Message-ID: <1465669082.16.0.784175948764.issue27293@psf.upfronthosting.co.za> Larry Hastings added the comment: As with #27292, I'm going to nosy Georg Brandl about this so he can guide us in how to approach it. My hunch is, it'd be best if we avoided specifics, and talked instead in generalities. Perhaps all that's really necessary is to consistently assure the user that the secrets module represents best practices in Python, now and in the future. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 14:19:02 2016 From: report at bugs.python.org (Larry Hastings) Date: Sat, 11 Jun 2016 18:19:02 +0000 Subject: [issue27293] Summarize issues related to urandom, getrandom etc in secrets documentation In-Reply-To: <1465641058.72.0.740134205443.issue27293@psf.upfronthosting.co.za> Message-ID: <1465669142.44.0.251577682961.issue27293@psf.upfronthosting.co.za> Larry Hastings added the comment: Oops, sorry, forgot to actually nosy Georg. D'oh! ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 14:34:28 2016 From: report at bugs.python.org (Donald Stufft) Date: Sat, 11 Jun 2016 18:34:28 +0000 Subject: [issue27292] Warn users that os.urandom() can return insecure values In-Reply-To: <1465639674.0.0.865291084778.issue27292@psf.upfronthosting.co.za> Message-ID: <1465670068.25.0.635221007068.issue27292@psf.upfronthosting.co.za> Donald Stufft added the comment: I agree that we should add a warning to these, it's easy to see how someone might read the summary of the function "Return a string of n random bytes suitable for cryptographic use." and skip over the nuance in the rest of the body of the function. Adding a red box to ensure that they know that on popular platforms os.urandom is not going to always return bytes that are suitable for cryptographic use is pretty important in my opinion. The current wording makes it sound like it's something you only need to worry about on "weird" platforms, not on one of the (if not the) most popular platforms for running Python on. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 14:34:35 2016 From: report at bugs.python.org (Larry Hastings) Date: Sat, 11 Jun 2016 18:34:35 +0000 Subject: [issue27297] Add support for /dev/random to "secrets" Message-ID: <1465670075.28.0.237473871841.issue27297@psf.upfronthosting.co.za> New submission from Larry Hastings: Linux contains two separate sources for random numbers: /dev/urandom and /dev/random. On a reasonably-current Linux box, the urandom(4) man page states: As a general rule, /dev/urandom should be used for everything except long-lived GPG/SSL/SSH keys. This seems to suggest that, in the eyes of its implementors, /dev/random returns ever-so-slightly superior random numbers, and that in certain limited circumstances you should prefer those. AFAICT the secrets module doesn't make use of the /dev/random device on Linux. Should it? (Or, in the likely case that we make the getrandom() function directly callable, should it call getrandom(GRND_RANDOM)?) p.s. FWIW, Linux's /dev/urandom isn't considered a true CPRNG in all circles. This paper declines to call it simply either a CPRNG or a PRNG, instead christening it with the unfamiliar term "PRNG with entropy inputs". https://eprint.iacr.org/2012/251.pdf p.p.s. I went ahead and nosied the "cryptography" "interest category" from the nosy list. Neat! ---------- assignee: steven.daprano components: Library (Lib) messages: 268243 nosy: christian.heimes, dstufft, gregory.p.smith, larry, steven.daprano priority: low severity: normal stage: test needed status: open title: Add support for /dev/random to "secrets" type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 14:36:48 2016 From: report at bugs.python.org (Larry Hastings) Date: Sat, 11 Jun 2016 18:36:48 +0000 Subject: [issue27292] Warn users that os.urandom() can return insecure values In-Reply-To: <1465639674.0.0.865291084778.issue27292@psf.upfronthosting.co.za> Message-ID: <1465670208.74.0.277048552529.issue27292@psf.upfronthosting.co.za> Larry Hastings added the comment: I would suggest weakening the one-line summary. Currently the first line reads: Return a string of n random bytes suitable for cryptographic use. I'd support adding some "weasel words" to this, e.g.: Return a string of n random bytes that should be suitable for cryptographic use. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 14:42:30 2016 From: report at bugs.python.org (Donald Stufft) Date: Sat, 11 Jun 2016 18:42:30 +0000 Subject: [issue27297] Add support for /dev/random to "secrets" In-Reply-To: <1465670075.28.0.237473871841.issue27297@psf.upfronthosting.co.za> Message-ID: <1465670550.26.0.0452273944331.issue27297@psf.upfronthosting.co.za> Donald Stufft added the comment: No we should not use /dev/random (or GRND_RANDOM(. It's numbers are not "more random" than /dev/urandom outside of the narrow window of prior to /dev/urandom being fully seeded. In fact, on Linux both /dev/urandom and /dev/random use the exact same CSPRNG the only difference is that /dev/random does some snake oil to try and guess "how much random" is left (which experts widely agree is a load of manure) and will block randomly (pun intended) throughout the running of the system whenever it's snakeoil decides that it's "random is running low". I know what the manpage says, it's basically an urban myth, unchanged largely because of political pressure ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 14:43:10 2016 From: report at bugs.python.org (Donald Stufft) Date: Sat, 11 Jun 2016 18:43:10 +0000 Subject: [issue27297] Add support for /dev/random to "secrets" In-Reply-To: <1465670075.28.0.237473871841.issue27297@psf.upfronthosting.co.za> Message-ID: <1465670590.34.0.717226594389.issue27297@psf.upfronthosting.co.za> Donald Stufft added the comment: For more information, read http://www.2uo.de/myths-about-urandom/ . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 14:54:27 2016 From: report at bugs.python.org (Brett Cannon) Date: Sat, 11 Jun 2016 18:54:27 +0000 Subject: [issue27288] secrets should use getrandom() on Linux In-Reply-To: <1465588599.3.0.867244099768.issue27288@psf.upfronthosting.co.za> Message-ID: <1465671267.97.0.571242087069.issue27288@psf.upfronthosting.co.za> Brett Cannon added the comment: Based on the documentation of random.SysRandom I think it comes down to #1. Perhaps the secrets documentation simply shouldn't mention the random module beyond how it's different? Then any use of the random module by the secrets module is an implementation detail that people can never rely on because we never said anything in the docs about it and clearly say "we do whatever is necessary to get you the most random bytes possible, backwards-compat be damned in how we pull it off". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 15:00:03 2016 From: report at bugs.python.org (Larry Hastings) Date: Sat, 11 Jun 2016 19:00:03 +0000 Subject: [issue27297] Add support for /dev/random to "secrets" In-Reply-To: <1465670075.28.0.237473871841.issue27297@psf.upfronthosting.co.za> Message-ID: <1465671603.42.0.320727034968.issue27297@psf.upfronthosting.co.za> Larry Hastings added the comment: So, you assert getrandom(0) and getrandom(GRND_RANDOM) return random bits of identically high quality? I'm curious about this political pressure you cite. It seems bizarre to me that the Linux developers would bow to such a thing, given how they behave on... well, every other topic. Can you point me towards resources about this political squabble? p.s. Yes, I've re-read the "myths about urandom" page many times this week. But there are enough experts on both sides of the topic that I don't know what to believe anymore. Certainly I'm happy to leave it to you guys. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 15:02:28 2016 From: report at bugs.python.org (Donald Stufft) Date: Sat, 11 Jun 2016 19:02:28 +0000 Subject: [issue27297] Add support for /dev/random to "secrets" In-Reply-To: <1465670075.28.0.237473871841.issue27297@psf.upfronthosting.co.za> Message-ID: <1465671748.74.0.956889350065.issue27297@psf.upfronthosting.co.za> Donald Stufft added the comment: > So, you assert getrandom(0) and getrandom(GRND_RANDOM) return random bits of identically high quality? Yes, except the latter will randomly block. > I'm curious about this political pressure you cite. Think about the last 4 days, now imagine that's happening on LKML where instead of having GvR disagree with you, you get told your parents should have aborted you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 15:06:32 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 Jun 2016 19:06:32 +0000 Subject: [issue22558] Missing doc links to source code for Python-coded modules. In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za> Message-ID: <20160611190628.9860.32142.CCD55CAD@psf.io> Roundup Robot added the comment: New changeset 222c1d461aa8 by Terry Jan Reedy in branch '3.5': Issue #22558: Add remaining doc links to source code for Python-coded modules. https://hg.python.org/cpython/rev/222c1d461aa8 New changeset 2a01d7a488e9 by Terry Jan Reedy in branch 'default': Merge Issue #22558. https://hg.python.org/cpython/rev/2a01d7a488e9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 15:08:37 2016 From: report at bugs.python.org (Donald Stufft) Date: Sat, 11 Jun 2016 19:08:37 +0000 Subject: [issue27297] Add support for /dev/random to "secrets" In-Reply-To: <1465670075.28.0.237473871841.issue27297@psf.upfronthosting.co.za> Message-ID: <1465672117.94.0.315163675164.issue27297@psf.upfronthosting.co.za> Donald Stufft added the comment: I will add, /dev/random is not going to *hurt* when generating long lived cryptographic keys (e.g. like your SSH keys) because that's something you're generally going to do once every couple of years and if it takes a few seconds longer because of snake oil then who cares. It's not going matter once /dev/urandom is initialized (of course, it does matter if /dev/urandom hasn't been initialized yet). So it does guard against early on in the boot process in a way that /dev/urandom doesn't (but then, so does getrandom(0)). It's obviously not acceptable for your webserver to randomly block for seconds at a time trying to generate signing keys for cookies just because of snakeoil though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 15:12:31 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 Jun 2016 19:12:31 +0000 Subject: [issue21386] ipaddress.IPv4Address.is_global not implemented In-Reply-To: <1398771335.62.0.997727403803.issue21386@psf.upfronthosting.co.za> Message-ID: <20160611191228.11544.27429.D98AD393@psf.io> Roundup Robot added the comment: New changeset d65191861599 by Berker Peksag in branch '3.5': Issue #21386: Implement missing IPv4Address.is_global property https://hg.python.org/cpython/rev/d65191861599 New changeset 1519ca772e54 by Berker Peksag in branch 'default': Issue #21386: Merge from 3.5 https://hg.python.org/cpython/rev/1519ca772e54 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 15:13:06 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 11 Jun 2016 19:13:06 +0000 Subject: [issue21386] ipaddress.IPv4Address.is_global not implemented In-Reply-To: <1398771335.62.0.997727403803.issue21386@psf.upfronthosting.co.za> Message-ID: <1465672386.51.0.0484048750823.issue21386@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks Roger! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 15:25:03 2016 From: report at bugs.python.org (Larry Hastings) Date: Sat, 11 Jun 2016 19:25:03 +0000 Subject: [issue27297] Add support for /dev/random to "secrets" In-Reply-To: <1465670075.28.0.237473871841.issue27297@psf.upfronthosting.co.za> Message-ID: <1465673103.76.0.606097375834.issue27297@psf.upfronthosting.co.za> Larry Hastings added the comment: I understand. It's just that the manpage for urandom (and in fact the comments in the source code for /dev/random and /dev/urandom) both recommend using /dev/random for these long-lived cryptographic keys. Under normal circumstances I'd simply assume that was correct and I'd follow their advice. But you're claiming that there are extenuating political circumstances surrounding these statements and they should be ignored. I trust your judgement and I'd be happy to see the secrets module do as you suggest. But you must admit, this is a surprising state of affairs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 15:27:31 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jun 2016 19:27:31 +0000 Subject: [issue22558] Missing doc links to source code for Python-coded modules. In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za> Message-ID: <1465673251.93.0.816376495144.issue22558@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I committed the excellent patch. It should appear in the upcoming 3.5 and 3.6 releases, and within a day online. Thanks to both package author and also to reviewers. I would like to see more patches like this. I reverted the deletion of version added in mock examples. It is a separate page, so the reminder is not inappropriate. Minor nit: Yoni, you 'forgot' to run "python tools/scripts/patchcheck.py" on a patched repository. Not too surprisingly, the editing left trailing whitespace that needed to be removed. See the devguide for more. A possible follow-on. Some of the packages that document contained modules do so on the main page rather than in separate pages. If the source link is to the package __init__, rather than to the package directory, then it would be appropriate to add links to the module sections. The particular example I am thinking of is importlib, where we linked to .__init__. There may be another. Multiprocessing is not, because we linked to the directory. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 15:29:57 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 Jun 2016 19:29:57 +0000 Subject: [issue20508] IndexError from ipaddress._BaseNetwork.__getitem__ has no message In-Reply-To: <1391519371.56.0.280883005316.issue20508@psf.upfronthosting.co.za> Message-ID: <20160611192955.11434.95682.D00CFA71@psf.io> Roundup Robot added the comment: New changeset bc758c62bc4f by Berker Peksag in branch 'default': Issue #20508: Improve exception message of IPv{4,6}Network.__getitem__ https://hg.python.org/cpython/rev/bc758c62bc4f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 15:30:19 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 11 Jun 2016 19:30:19 +0000 Subject: [issue20508] IndexError from ipaddress._BaseNetwork.__getitem__ has no message In-Reply-To: <1391519371.56.0.280883005316.issue20508@psf.upfronthosting.co.za> Message-ID: <1465673419.16.0.381907070692.issue20508@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 15:30:50 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jun 2016 19:30:50 +0000 Subject: [issue27025] More human readable generated widget names In-Reply-To: <1463299445.94.0.887025569149.issue27025@psf.upfronthosting.co.za> Message-ID: <1465673450.22.0.135331626103.issue27025@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Patch updated. 1. The prefix "0" is used for generated names. This keeps the old rule (generated names start from a digit and are not valid Python identifier) and looks less striking than "_". 2. Lowercased Python class name is used as a base name for generated name. 3. Numbering is separate for every type and every parent widget. 4. Numerical suffix is not used for the first (often the single) child of every type. ---------- Added file: http://bugs.python.org/file43344/tkinter_names2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 15:31:41 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jun 2016 19:31:41 +0000 Subject: [issue27294] Better repr for Tkinter event objects In-Reply-To: <1465648557.25.0.737232700025.issue27294@psf.upfronthosting.co.za> Message-ID: <1465673501.84.0.479192838049.issue27294@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Testing now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 15:33:12 2016 From: report at bugs.python.org (Donald Stufft) Date: Sat, 11 Jun 2016 19:33:12 +0000 Subject: [issue27297] Add support for /dev/random to "secrets" In-Reply-To: <1465670075.28.0.237473871841.issue27297@psf.upfronthosting.co.za> Message-ID: <1465673592.09.0.2922237722.issue27297@psf.upfronthosting.co.za> Donald Stufft added the comment: > It's just that the manpage for urandom (and in fact the comments in the source code for /dev/random and /dev/urandom) both recommend using /dev/random for these long-lived cryptographic keys. It's a hedge because of the bad behavior of /dev/urandom on early boot in a situation where it's highly unlikely that the randomly blocking behavior of /dev/random is going to matter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 15:42:52 2016 From: report at bugs.python.org (Ned Deily) Date: Sat, 11 Jun 2016 19:42:52 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1465674172.53.0.311513434262.issue5124@psf.upfronthosting.co.za> Ned Deily added the comment: Terry, the 2.7 version of the test changes is causing buildbot and test_idle failures when the "gui" condition is not met. See, for example, http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%202.7/builds/1400. ---------- stage: resolved -> needs patch status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 15:58:16 2016 From: report at bugs.python.org (Gareth Rees) Date: Sat, 11 Jun 2016 19:58:16 +0000 Subject: [issue20508] IndexError from ipaddress._BaseNetwork.__getitem__ has no message In-Reply-To: <1391519371.56.0.280883005316.issue20508@psf.upfronthosting.co.za> Message-ID: <1465675096.13.0.0970301098157.issue20508@psf.upfronthosting.co.za> Gareth Rees added the comment: Thank you for applying this patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 16:10:02 2016 From: report at bugs.python.org (Memeplex) Date: Sat, 11 Jun 2016 20:10:02 +0000 Subject: [issue26565] [ctypes] Add value attribute to non basic pointers. In-Reply-To: <1458007329.36.0.71536825947.issue26565@psf.upfronthosting.co.za> Message-ID: <1465675802.57.0.361309375005.issue26565@psf.upfronthosting.co.za> Memeplex added the comment: Martin, there were two reasons: 1. Conciseness: addressof(p.contents) vs. p.value. 2. Uniformity: I expect the value of a pointer to be the address it points to. Then Eryk pointed out that p.value has already another meaning for simple pointer types, so (2) can't be fully achieved and for (1) it will be necessary to pick another attribute name. But we could still get something shorter and uniform inside the subset of pointer types. p.as_void makes me expect a c_void_p instance. In that case the address will be p.as_void.value (or p.as_void().value?), which is a bit indirect. I think p.toaddress conveys the exact meaning[1] and consistently follows the naming style of addressof, besides being slightly shorter. [1] Well, toaddress might mean "get the pointed-to address" or "convert from pointer to address", but in any case the meaning is right. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 16:15:36 2016 From: report at bugs.python.org (Rohit Mediratta) Date: Sat, 11 Jun 2016 20:15:36 +0000 Subject: [issue27277] Fatal Python error: Segmentation fault in test_exceptions In-Reply-To: <1465457335.09.0.330685258307.issue27277@psf.upfronthosting.co.za> Message-ID: <1465676136.83.0.319539055543.issue27277@psf.upfronthosting.co.za> Rohit Mediratta added the comment: It's set to 1000, I didnt change during install, so it's likely set to the default value. >>> import sys >>> sys.getrecursionlimit() 1000 I also have a lot of memory free (87G) to run scripts (should be able to handle without running into issues) [/loc/rom/pyd/cpython] $ free -m total used free shared buffers cached Mem: 96870 9849 87021 0 716 7512 -/+ buffers/cache: 1620 95250 Swap: 0 0 0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 16:16:48 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jun 2016 20:16:48 +0000 Subject: [issue27294] Better repr for Tkinter event objects In-Reply-To: <1465648557.25.0.737232700025.issue27294@psf.upfronthosting.co.za> Message-ID: <1465676208.39.0.0541536421726.issue27294@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Summary: Though I would like to see some refinements, this looks really useful as is and I would like it applied soon even if refinements have to wait for a second patch. Moving the window did not generate a printed event. I like the compact way of handling customization. Two more possible exclusions: 1. The key state seems like it should only be interesting for key events. 2. The 4 mouse positions are pretty noisy and seem not relevant to key events, and to many other non-mouse events. I wish "VirtualEvent event"s had the triggering sequence available, but you cannot change that. . ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 16:26:32 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 Jun 2016 20:26:32 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <20160611202629.11607.5190.39B3FA48@psf.io> Roundup Robot added the comment: New changeset 274308a3b8b6 by Terry Jan Reedy in branch '2.7': Issue #5124: For 2.7, move requires('gui') from module level to setUpClass. https://hg.python.org/cpython/rev/274308a3b8b6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 16:30:07 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jun 2016 20:30:07 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1465677007.61.0.406446069936.issue5124@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Oh right, requires('gui') does not work at module level in 2.7. This should fix. Will try to check next round of bot builds. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 16:32:51 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jun 2016 20:32:51 +0000 Subject: [issue27294] Better repr for Tkinter event objects In-Reply-To: <1465648557.25.0.737232700025.issue27294@psf.upfronthosting.co.za> Message-ID: <1465677171.13.0.77680570144.issue27294@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The key state can be interesting for mouse events too. Ctrl-Click, Shift-Move. Maybe it is worth to omit the output of state=0. Agreed, the 4 mouse positions are pretty noisy. Maybe omit root_x and root_y? But mouse position can be relevant for such key events as pressing Ctrl. For example if the mouse pointer points on module name in import statement, pressing Ctrl can convert the name into a hyperling to a file of the module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 16:35:41 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 Jun 2016 20:35:41 +0000 Subject: [issue26556] Update expat to 2.2.1 In-Reply-To: <1457951495.3.0.910401967595.issue26556@psf.upfronthosting.co.za> Message-ID: <20160611203528.81041.74365.E31E0E7C@psf.io> Roundup Robot added the comment: New changeset d8a0a016d8d4 by Benjamin Peterson in branch '2.7': upgrade expt to 2.1.1 (closes #26556) https://hg.python.org/cpython/rev/d8a0a016d8d4 New changeset bb3ce78572f5 by Benjamin Peterson in branch '3.4': upgrade expt to 2.1.1 (closes #26556) https://hg.python.org/cpython/rev/bb3ce78572f5 New changeset f3c36afdedae by Benjamin Peterson in branch '3.5': merge 3.4 (#26556) https://hg.python.org/cpython/rev/f3c36afdedae New changeset 77353f0106cc by Benjamin Peterson in branch 'default': merge 3.5 (#26556) https://hg.python.org/cpython/rev/77353f0106cc ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 16:39:10 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 11 Jun 2016 20:39:10 +0000 Subject: [issue27295] heaps library does not have support for max heap In-Reply-To: <1465652992.55.0.603716004725.issue27295@psf.upfronthosting.co.za> Message-ID: <1465677550.59.0.123275665466.issue27295@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Sorry James, we don't grow the APIs without sufficient demonstrated need; otherwise, we end-up with API sprawl. People with actual use cases haven't requested behavior (and the occasional one-off gets by negating the numeric argument). That is why the maxheap functions were intentionally made private. FWIW, this module is very old and the core functions have long proven themselves sufficient to meet their use cases (like being used in an event loop to efficiently select the next scheduled event). ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 16:41:53 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 11 Jun 2016 20:41:53 +0000 Subject: [issue27291] two heap corruption issue In-Reply-To: <1465616405.38.0.731036800645.issue27291@psf.upfronthosting.co.za> Message-ID: <1465677713.72.0.856707121949.issue27291@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +haypo, rhettinger, serhiy.storchaka, stutzbach _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 16:45:49 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jun 2016 20:45:49 +0000 Subject: [issue27291] two heap corruption issue In-Reply-To: <1465616405.38.0.731036800645.issue27291@psf.upfronthosting.co.za> Message-ID: <1465677949.0.0.726340541176.issue27291@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: poc.zip contains only precompiled files. Could you please provide source files? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 16:59:23 2016 From: report at bugs.python.org (Pedro Lacerda) Date: Sat, 11 Jun 2016 20:59:23 +0000 Subject: [issue22253] ConfigParser does not handle files without sections In-Reply-To: <1408731768.17.0.221948826268.issue22253@psf.upfronthosting.co.za> Message-ID: <1465678763.16.0.865587688604.issue22253@psf.upfronthosting.co.za> Pedro Lacerda added the comment: I also never found a mixture of sectionless options followed by sectioned options. So an unnamed section that is also the DEFAULTSECTION will probably work. In this patch when `default_section=None` is passed to `RawConfigParser` it will parse top level options into the default section and skip writing its title. As drawback, default options is not showed in `options()` or `has_section()` reducing it usefulness. It works with `items()` and `keys()` however. > Using DEFAULTSECT for this purpose is equally wrong since it would > silently inject default values to every section I disagree with that because I really *never* found in wild a file where it will happen. > All in all, it comes down to the question whether the programmer > expects section-less configuration. If not, the '' section will not be > helpful anyway. If yes, then it's desirable to be able to specify a > section name for global options at *read time*. Pass a name at read time will improve the API as `sections()` and `has_section()` will work as usual and not like a DEFAULTSECTION. Please look my patch and tell if it's acceptable, if you prefer that a section name must be given at read and write time we can manage it. It's my first post in this tracker and I'm very glad that I got it working even if not merged! ---------- keywords: +patch nosy: +Pedro Lacerda versions: -Python 3.5 Added file: http://bugs.python.org/file43345/nosection.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 17:00:51 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jun 2016 21:00:51 +0000 Subject: [issue27294] Better repr for Tkinter event objects In-Reply-To: <1465648557.25.0.737232700025.issue27294@psf.upfronthosting.co.za> Message-ID: <1465678851.58.0.220415371234.issue27294@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Right. This is why I suggested leaving anything we are not sure of to a later patch, after gaining more experience (and thought). However, 'state' behaved strangely in my experiments. In a sequence of about 900 events, it started as 8 (Left Alt according to Shipman, but I never touched the key) and changed to 0 here back to 8 here and briefly back to 0 here ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 17:09:30 2016 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 11 Jun 2016 21:09:30 +0000 Subject: [issue27140] Opcode for creating dict with constant keys In-Reply-To: <1464381640.82.0.0689379791356.issue27140@psf.upfronthosting.co.za> Message-ID: <1465679370.34.0.947709237136.issue27140@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Okay, I think it's fine then. However, you have a for loop in compiler_subkwargs which only executes once. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 17:20:13 2016 From: report at bugs.python.org (Oren Milman) Date: Sat, 11 Jun 2016 21:20:13 +0000 Subject: [issue27298] redundant iteration over digits in _PyLong_AsUnsignedLongMask Message-ID: <1465680013.34.0.390511904077.issue27298@psf.upfronthosting.co.za> New submission from Oren Milman: ------------ current state ------------ 1. In Objects/longobject.c in _PyLong_AsUnsignedLongMask, in case v is a multiple-digit int, _PyLong_AsUnsignedLongMask iterates over all of its digits (going from the most to the least significant digit) and does (for each digit) 'x = (x << PyLong_SHIFT) | v->ob_digit[i];'. However, iterating over digits other than the 'ceil(sizeof(x) * 8.0 / PyLong_SHIFT)' least significant digits is redundant, because their bits would be shifted out of x anyway. With regard to relevant changes made in the past, the iteration over all of the digits of a multiple-digit v remained quite the same since _PyLong_AsUnsignedLongMask was added, in revision 28652. 2. In Modules/_testcapimodule.c, the function comment of test_k_code, and an error string inside that function, contain mistakes. With regard to relevant changes made in the past, these mistakes were there since test_k_code was added, in revision 28652. ------------ proposed changes ------------ 1. In _PyLong_AsUnsignedLongMask, in case v is a multiple-digit int, iterate only over the 'Py_MIN(i, sizeof(x) * 8 / PyLong_SHIFT + 1)' least significant digits. Obviously, 'sizeof(x) * 8 / PyLong_SHIFT + 1' might be off by one in case CPython is compiled with a PyLong_SHIFT other than 15 or 30. I suspect it's an overkill, but I added an assert, just in case. 2. Fix the function comment of test_k_code, and an error string inside that function. ------------ alternative changes ------------ 1. I have also considered iterating only over the 'Py_MIN(i, (Py_ssize_t)ceil(sizeof(x) * 8.0 / PyLong_SHIFT))' least significant digits. Even though this number of digits is guaranteed to be accurate, it cannot be calculated at compile time, so it would probably cause the optimization to overall introduce a performance penalty. ------------ diff ------------ The proposed patches diff file is attached. ------------ tests ------------ I built the patched CPython for x86, and played with it a little. Everything seemed to work as usual. In addition, I ran 'python_d.exe -m test -j3' (on my 64-bit Windows 10) with and without the patches, and got quite the same output. The outputs of both runs are attached. ---------- components: Interpreter Core files: proposedPatches.diff keywords: patch messages: 268274 nosy: Oren Milman priority: normal severity: normal status: open title: redundant iteration over digits in _PyLong_AsUnsignedLongMask type: performance Added file: http://bugs.python.org/file43346/proposedPatches.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 17:20:33 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 Jun 2016 21:20:33 +0000 Subject: [issue27294] Better repr for Tkinter event objects In-Reply-To: <1465648557.25.0.737232700025.issue27294@psf.upfronthosting.co.za> Message-ID: <20160611212030.26129.16042.CB5A40DE@psf.io> Roundup Robot added the comment: New changeset 61a92a102b2d by Serhiy Storchaka in branch 'default': Issue #27294: Improved repr for Tkinter event objects. https://hg.python.org/cpython/rev/61a92a102b2d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 17:20:55 2016 From: report at bugs.python.org (Oren Milman) Date: Sat, 11 Jun 2016 21:20:55 +0000 Subject: [issue27298] redundant iteration over digits in _PyLong_AsUnsignedLongMask In-Reply-To: <1465680013.34.0.390511904077.issue27298@psf.upfronthosting.co.za> Message-ID: <1465680055.48.0.259798328388.issue27298@psf.upfronthosting.co.za> Changes by Oren Milman : Added file: http://bugs.python.org/file43347/patchedCPythonTestOutput.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 17:21:11 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jun 2016 21:21:11 +0000 Subject: [issue27298] redundant iteration over digits in _PyLong_AsUnsignedLongMask In-Reply-To: <1465680013.34.0.390511904077.issue27298@psf.upfronthosting.co.za> Message-ID: <1465680071.78.0.51254885113.issue27298@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +mark.dickinson, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 17:21:28 2016 From: report at bugs.python.org (Park Alex) Date: Sat, 11 Jun 2016 21:21:28 +0000 Subject: [issue27291] two heap corruption issue In-Reply-To: <1465616405.38.0.731036800645.issue27291@psf.upfronthosting.co.za> Message-ID: <1465680088.34.0.879232743929.issue27291@psf.upfronthosting.co.za> Park Alex added the comment: all of .pyc files had been altered by fuzzer. original py code is following: $ cat helloworld.py def hello(s=0x4142434445464748): print s if type(s) == str: print s.encode('hex') print repr(s) else: s = str(s) print len(s) << 8, len(s) ^ 8, len(s) | 8, len(s) & 8, len(s) == 8, len(s) <= 8, len(s) >= 8 x = __import__("sys") # for k, v in x.__dict__.items(): # if hasattr(v, '__subclasses__') == True: # cmd = "Subclasses:", (v.__class__.__base__.__subclasses__()[11].__init__.__str__()) return 0x5152535455565758 == max(s, abs(len(s)) % 0x1234) H = 'A'*128 hello(H.encode('base64')) hello() plus, python compiled with ASAN generated .pyc code. After that, fuzzer found a few crashes. Here are some diff information between original pyc and fuzzed pyc. file: poc_heap-buffer-overflow.pyc cmp -bl helloworld.pyc poc_heap-buffer-overflow.pyc | gawk '{printf "%08X %02X %02X\n", $1, strtonum(0$2), strtonum(0$4)}' 00000010 00 03 00000012 03 00 00000026 01 00 00000027 00 F7 0000006A 06 EE 0000006B 00 FF 0000006C 00 FF 0000006D 00 FF 00000129 01 FE 0000012A 00 FF 0000012B 64 00 0000012C 04 00 000001F0 6C DB 000001FD 6C 49 file: poc_heap-use-after-free.pyc cmp -bl helloworld.pyc poc_heap-use-after-free.pyc | gawk '{printf "%08X %02X %02X\n", $1, strtonum(0$2), strtonum(0$4)}' 0000006A 06 D0 0000006B 00 FF 0000006C 00 FF 0000006D 00 FF 00000129 01 EB 0000012A 00 FF 0000012B 64 00 0000012C 04 00 000001F0 6C DB 000001FD 6C 49 0000026F 6C 7D Thanks, -- Alex ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 17:21:49 2016 From: report at bugs.python.org (Oren Milman) Date: Sat, 11 Jun 2016 21:21:49 +0000 Subject: [issue27298] redundant iteration over digits in _PyLong_AsUnsignedLongMask In-Reply-To: <1465680013.34.0.390511904077.issue27298@psf.upfronthosting.co.za> Message-ID: <1465680109.24.0.916510203708.issue27298@psf.upfronthosting.co.za> Changes by Oren Milman : Added file: http://bugs.python.org/file43348/CPythonTestOutput.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 17:24:01 2016 From: report at bugs.python.org (Tim Peters) Date: Sat, 11 Jun 2016 21:24:01 +0000 Subject: [issue27288] secrets should use getrandom() on Linux In-Reply-To: <1465588599.3.0.867244099768.issue27288@psf.upfronthosting.co.za> Message-ID: <1465680241.23.0.225859009345.issue27288@psf.upfronthosting.co.za> Tim Peters added the comment: I think it's clear Guido would say "#1". The thrust of all his comments to date is that it was a mistake to change the semantics of os.urandom() on Linux (and one other platform? don't really care), and that in 3.6+ only `secrets` should _try_ to supply possibly-blocking behavior on Linux. Indeed, even in 3.6+ he doesn't want to expose the new-ish getrandom() directly. Today he said: """ So what should the secrets module use? Let's make that part an extension module. """ So he feels strongly enough about this as to recommend a teensy private C extension module for secrets.py alone to get at the platform getrandom() (if any - of course it needs to fall back to os.urandom() on other platforms). """ The main thing that I want to avoid is that people start cargo-culting whatever the secrets module uses rather than just using the secrets module. Having it redundantly available as os.getrandom() is just begging for people to show off how much they know about writing secure code. """ Whenever he starts taking that tone, his mind is made up for good ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 17:24:35 2016 From: report at bugs.python.org (Brett Cannon) Date: Sat, 11 Jun 2016 21:24:35 +0000 Subject: [issue27288] secrets should use getrandom() on Linux In-Reply-To: <1465588599.3.0.867244099768.issue27288@psf.upfronthosting.co.za> Message-ID: <1465680275.5.0.429957306052.issue27288@psf.upfronthosting.co.za> Brett Cannon added the comment: It should be mentioned that Guido really doesn't like the idea of os.getrandom() as it exposes stuff where we would rather simply tell people to use the secrets module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 17:25:46 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 11 Jun 2016 21:25:46 +0000 Subject: [issue10839] email module should not allow some header field repetitions In-Reply-To: <1294263603.86.0.308955870327.issue10839@psf.upfronthosting.co.za> Message-ID: <1465680346.49.0.97445305032.issue10839@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I think we should consider this as an API design bug and backport the fix. This seems to be the exact cause of this week's email address leak at LetsEncrypt: * https://community.letsencrypt.org/t/email-address-disclosures-preliminary-report-june-11-2016/16867 * https://news.ycombinator.com/item?id=11881704 * https://twitter.com/TvdW/status/741482093054550016 ---------- nosy: +rhettinger priority: normal -> high status: closed -> open versions: +Python 2.7 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 17:31:38 2016 From: report at bugs.python.org (STINNER Victor) Date: Sat, 11 Jun 2016 21:31:38 +0000 Subject: [issue27291] two heap corruption issue In-Reply-To: <1465680088.34.0.879232743929.issue27291@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Hi, corrupted .pyc files are known to be abel to crash Python. What is the point of your bug report? If you are able to execute untrusted .pyc, you can already execute arbitrary code, no? IMHO we should document the limitation of the security of CPython. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 17:38:50 2016 From: report at bugs.python.org (ppperry) Date: Sat, 11 Jun 2016 21:38:50 +0000 Subject: [issue27291] two heap corruption issues when running modified pyc code. In-Reply-To: <1465616405.38.0.731036800645.issue27291@psf.upfronthosting.co.za> Message-ID: <1465681130.88.0.373847703513.issue27291@psf.upfronthosting.co.za> Changes by ppperry : ---------- title: two heap corruption issue -> two heap corruption issues when running modified pyc code. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 17:40:36 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 Jun 2016 21:40:36 +0000 Subject: [issue27140] Opcode for creating dict with constant keys In-Reply-To: <1464381640.82.0.0689379791356.issue27140@psf.upfronthosting.co.za> Message-ID: <20160611214033.11470.84571.CB7E851C@psf.io> Roundup Robot added the comment: New changeset 27b0dbaf0ea8 by Serhiy Storchaka in branch 'default': Issue #27140: Added BUILD_CONST_KEY_MAP opcode. https://hg.python.org/cpython/rev/27b0dbaf0ea8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 17:43:52 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jun 2016 21:43:52 +0000 Subject: [issue27140] Opcode for creating dict with constant keys In-Reply-To: <1464381640.82.0.0689379791356.issue27140@psf.upfronthosting.co.za> Message-ID: <1465681432.16.0.775578943881.issue27140@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, I left it for symmetry and for easier modifying if we will add more restrictions on using BUILD_CONST_KEY_MAP. Thank you for your reviews Demur and Benjamin. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 17:46:34 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jun 2016 21:46:34 +0000 Subject: [issue27095] Simplify MAKE_FUNCTION In-Reply-To: <1464038780.83.0.81155899453.issue27095@psf.upfronthosting.co.za> Message-ID: <1465681594.88.0.779986667343.issue27095@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Now with adding BUILD_CONST_KEY_MAP I think MAKE_FUNCTION can be more compact. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 17:48:51 2016 From: report at bugs.python.org (Park Alex) Date: Sat, 11 Jun 2016 21:48:51 +0000 Subject: [issue27291] two heap corruption issues when running modified pyc code. In-Reply-To: <1465616405.38.0.731036800645.issue27291@psf.upfronthosting.co.za> Message-ID: <1465681731.74.0.477920041878.issue27291@psf.upfronthosting.co.za> Park Alex added the comment: I totally agreed with your opinion. So I hesitated before reporting the issue (I thought) It's kinda, we have different point of view. As far as I can tell, python could be corrupted with .pyc like heap-use-after-free, buffer overrun and so on. Again, I agreed with your comment below: "If you are able to execute untrusted .pyc, you can already execute arbitrary code, no?" If don't want to bother you guys, I respect python-dev as always. Thanks, -- Alex ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 17:51:32 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jun 2016 21:51:32 +0000 Subject: [issue27213] Rework CALL_FUNCTION* opcodes In-Reply-To: <1465026334.02.0.369802561902.issue27213@psf.upfronthosting.co.za> Message-ID: <1465681892.8.0.0704654808275.issue27213@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I was going to write a patch myself, but since I'm sure in your skills, I yield it to you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 17:52:29 2016 From: report at bugs.python.org (Park Alex) Date: Sat, 11 Jun 2016 21:52:29 +0000 Subject: [issue27291] two heap corruption issues when running modified pyc code. In-Reply-To: <1465616405.38.0.731036800645.issue27291@psf.upfronthosting.co.za> Message-ID: <1465681949.1.0.912486231504.issue27291@psf.upfronthosting.co.za> Park Alex added the comment: oops, I cannot modify reply even I wrote it, want to fix tiny typo. I don't want to bother you guys, I respect python-dev as always. Thanks, -- Alex ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 17:58:40 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 11 Jun 2016 21:58:40 +0000 Subject: [issue27288] secrets should use getrandom() on Linux In-Reply-To: <1465588599.3.0.867244099768.issue27288@psf.upfronthosting.co.za> Message-ID: <1465682320.94.0.717457726155.issue27288@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: I'm interested in implementing this for 3.6, but I'm not sure exactly what the changes are that were decided upon. Is the following accurate? 1. Nothing changes in os (all the necessary changes were made in 3.5.2 already). 2. On Linux 3.17+ only, we add a new extension module called _secrets that provides a wrapper around the getrandom() system call and nothing else. I'll have to figure out whether to make the extension module just not exist all on non-Linux OSs (are there any existing extension modules that only exist on one OS?), or whether to make it empty on non-Linux. _secrets.getrandom() will look like def getrandom(buflen: int, flags: int) -> bytes. 3. We change secrets.SystemRandom so that on Linux 3.17+ only, it subclasses random.SystemRandom to use _secrets.getrandom() instead of os.urandom(). We will not pass in any flags to getrandom() (so we read from /dev/urandom and block until there is sufficient entropy). To make the subclassing easier, we may want to change random.SystemRandom to have a private method for calling os.urandom. (Currently, both of its methods call os.urandom directly.) 4. Similarly, we change secrets.token_bytes to use _secrets.getrandom(). Other functions in secrets.py won't need to change since they use secrets.SystemRandom or secrets.token_bytes. 5. _secrets and _secrets.getrandom will remain private and undocumented. ---------- nosy: +Jelle Zijlstra _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 18:26:09 2016 From: report at bugs.python.org (ppperry) Date: Sat, 11 Jun 2016 22:26:09 +0000 Subject: [issue27263] Tkinter sets the HOME environment variable, breaking scripts In-Reply-To: <1465352687.77.0.957460905896.issue27263@psf.upfronthosting.co.za> Message-ID: <1465683969.49.0.865860504291.issue27263@psf.upfronthosting.co.za> Changes by ppperry : ---------- components: -IDLE _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 18:29:13 2016 From: report at bugs.python.org (ppperry) Date: Sat, 11 Jun 2016 22:29:13 +0000 Subject: [issue25733] Code and IDLE should catch all compile errors. In-Reply-To: <1448461598.38.0.392041411432.issue25733@psf.upfronthosting.co.za> Message-ID: <1465684153.85.0.602181557999.issue25733@psf.upfronthosting.co.za> ppperry added the comment: OverflowError is raised when one attempts to compile a string of 2**31 or more characters. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 18:39:03 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jun 2016 22:39:03 +0000 Subject: [issue27025] More human readable generated widget names In-Reply-To: <1463299445.94.0.887025569149.issue27025@psf.upfronthosting.co.za> Message-ID: <1465684743.09.0.39972795615.issue27025@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I agree with back-compatibility, suppression of '1' suffix, and numbering, which makes suppressed '1' common. I prefer '1' rather that '0' prefix. Visually, '1' leaves more space between digit and word. Semantically, each component represents 1 of something. 0 this, 0 that, 0 etcetera, is a bad semantic clash. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 18:40:33 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 11 Jun 2016 22:40:33 +0000 Subject: [issue24136] document PEP 448: unpacking generalization In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za> Message-ID: <1465684833.77.0.319160137175.issue24136@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Thanks for writing a better patch. The patch looks good to me and it builds correctly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 18:53:51 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jun 2016 22:53:51 +0000 Subject: [issue27294] Better repr for Tkinter event objects In-Reply-To: <1465648557.25.0.737232700025.issue27294@psf.upfronthosting.co.za> Message-ID: <1465685631.43.0.710369229559.issue27294@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Next patch decodes the state attribute. Modifier names can be platform depended, please test on Windows. What modifiers correspond Shift, Ctrl, Alt, Win, CapsLock, etc? ---------- Added file: http://bugs.python.org/file43349/tkinter_event_repr_key_state.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 18:54:50 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jun 2016 22:54:50 +0000 Subject: [issue27263] Tkinter sets the HOME environment variable, breaking scripts In-Reply-To: <1465352687.77.0.957460905896.issue27263@psf.upfronthosting.co.za> Message-ID: <1465685690.42.0.0767071838201.issue27263@psf.upfronthosting.co.za> Terry J. Reedy added the comment: ppperry, when I changed this to a doc issue, I added IDLE back as a component because, as I said in my last message, I want to include the facts revealed here in the IDLE doc. ---------- nosy: +ppperry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 18:55:39 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jun 2016 22:55:39 +0000 Subject: [issue27025] More human readable generated widget names In-Reply-To: <1463299445.94.0.887025569149.issue27025@psf.upfronthosting.co.za> Message-ID: <1465685739.12.0.694554310588.issue27025@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: "1" looks too similar to "l". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 19:02:35 2016 From: report at bugs.python.org (ppperry) Date: Sat, 11 Jun 2016 23:02:35 +0000 Subject: [issue27263] Tkinter sets the HOME environment variable, breaking scripts In-Reply-To: <1465352687.77.0.957460905896.issue27263@psf.upfronthosting.co.za> Message-ID: <1465686155.9.0.99230869706.issue27263@psf.upfronthosting.co.za> Changes by ppperry : ---------- nosy: -ppperry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 19:03:06 2016 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 11 Jun 2016 23:03:06 +0000 Subject: [issue27221] multiprocessing documentation is outdated regarding method picklability In-Reply-To: <1465069362.83.0.142351405451.issue27221@psf.upfronthosting.co.za> Message-ID: <1465686186.84.0.623658354189.issue27221@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Thanks for the Rietveld comments. I have attached a new patch. ---------- Added file: http://bugs.python.org/file43350/issue27221-cr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 19:39:06 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jun 2016 23:39:06 +0000 Subject: [issue25733] Code and IDLE should catch all compile errors. In-Reply-To: <1448461598.38.0.392041411432.issue25733@psf.upfronthosting.co.za> Message-ID: <1465688346.3.0.400499740698.issue25733@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Code patch, still needs tests. ppperry, thanks. I may create a temporary big file when large memory tests are allowed. ---------- keywords: +patch stage: needs patch -> test needed Added file: http://bugs.python.org/file43351/catch_all_syntax_errors.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 19:42:59 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jun 2016 23:42:59 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1465688579.55.0.87165825562.issue5124@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The two stable buildbots that failed on test_idle before do not now: AMD64 SnowLeapard 1403, AMD64 Win 7 2258. ---------- stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 19:59:33 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 Jun 2016 23:59:33 +0000 Subject: [issue27194] Tarfile superfluous truncate calls slows extraction. In-Reply-To: <1464929793.77.0.639155899875.issue27194@psf.upfronthosting.co.za> Message-ID: <20160611235928.99256.79180.F338F913@psf.io> Roundup Robot added the comment: New changeset b63474aa8a5f by ?ukasz Langa in branch '3.5': Issue #27194: superfluous truncate calls in tarfile.py slow down extraction https://hg.python.org/cpython/rev/b63474aa8a5f New changeset a4f918de25e5 by ?ukasz Langa in branch 'default': Merge 3.5, issue #27194 https://hg.python.org/cpython/rev/a4f918de25e5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 20:02:19 2016 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Sun, 12 Jun 2016 00:02:19 +0000 Subject: [issue27194] Tarfile superfluous truncate calls slows extraction. In-Reply-To: <1464929793.77.0.639155899875.issue27194@psf.upfronthosting.co.za> Message-ID: <1465689739.93.0.745933155122.issue27194@psf.upfronthosting.co.za> ?ukasz Langa added the comment: Thanks for the patch, Jason. This is now merged and will be available in 3.5.2 and 3.6. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 20:12:22 2016 From: report at bugs.python.org (Yoni Lavi) Date: Sun, 12 Jun 2016 00:12:22 +0000 Subject: [issue22558] Missing doc links to source code for Python-coded modules. In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za> Message-ID: <1465690342.5.0.369037688864.issue22558@psf.upfronthosting.co.za> Yoni Lavi added the comment: Thank you Terry, Nathan and David for your work on this. Sorry about the whitespace issue, I indeed forgot to run patchcheck when I prepared the 3rd patch. Tery, would you like me to prepare a patch for the follow-on you suggested? If so, given that this one is now marked as fixed, we should open a new bug, right? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 20:18:04 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 12 Jun 2016 00:18:04 +0000 Subject: [issue27294] Better repr for Tkinter event objects In-Reply-To: <1465648557.25.0.737232700025.issue27294@psf.upfronthosting.co.za> Message-ID: <1465690684.58.0.393200100253.issue27294@psf.upfronthosting.co.za> Terry J. Reedy added the comment: If you want more, say so, and I will do them after resting. ---------- Added file: http://bugs.python.org/file43352/tk-win-key-events.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 20:23:49 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 12 Jun 2016 00:23:49 +0000 Subject: [issue22558] Missing doc links to source code for Python-coded modules. In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za> Message-ID: <1465691029.19.0.136588874865.issue22558@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Yes, new issue, make me nosy, assign to me if allowed, upload patch. Start with "This is a follow to #22558." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 20:43:14 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 12 Jun 2016 00:43:14 +0000 Subject: [issue27291] two heap corruption issues when running modified pyc code. In-Reply-To: <1465616405.38.0.731036800645.issue27291@psf.upfronthosting.co.za> Message-ID: <1465692194.43.0.985950957933.issue27291@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Executing code in any form from untrusted sources can do arbitrary things. If someone can corrupt .pyc data before python executes it, they are just as likely to be able to corrupt other things leading to more direct exploits not even requiring the CPython interpreter. ---------- nosy: +gregory.p.smith resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 20:47:45 2016 From: report at bugs.python.org (Demur Rumed) Date: Sun, 12 Jun 2016 00:47:45 +0000 Subject: [issue27095] Simplify MAKE_FUNCTION In-Reply-To: <1464038780.83.0.81155899453.issue27095@psf.upfronthosting.co.za> Message-ID: <1465692465.54.0.460241051636.issue27095@psf.upfronthosting.co.za> Demur Rumed added the comment: mkfu4 implements #27140. It doesn't special case 1-tuples into `BUILD_MAP 1` It may be easier to have `BUILD_CONST_KEY_MAP 1` peepholed if it's really preferable to strength reduce I'm also noticing that it could've been suggested to go to the extreme with BUILD_CONST_KEY_MAP where instead of relying on peepholer to constant fold tuple, we implement constant folding const keys entirely there. Just a random thought, not a suggestion or anything else ---------- Added file: http://bugs.python.org/file43353/mkfu4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 20:56:56 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Jun 2016 00:56:56 +0000 Subject: [issue15468] Edit docs to hide hashlib.md5() In-Reply-To: <1343404007.83.0.817302008925.issue15468@psf.upfronthosting.co.za> Message-ID: <20160612005649.114300.99574.093AB243@psf.io> Roundup Robot added the comment: New changeset 13ea0a1d7dde by Gregory P. Smith in branch 'default': issue15468 - use sha256 instead of md5 or sha1 in the examples. https://hg.python.org/cpython/rev/13ea0a1d7dde ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 21:02:23 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Jun 2016 01:02:23 +0000 Subject: [issue15468] Edit docs to hide hashlib.md5() In-Reply-To: <1343404007.83.0.817302008925.issue15468@psf.upfronthosting.co.za> Message-ID: <20160612010218.101877.21718.D0F7B22C@psf.io> Roundup Robot added the comment: New changeset 1cfd627bee05 by Gregory P. Smith in branch 'default': Clarify that md5 is in the algorithms_guaranteed list despite what https://hg.python.org/cpython/rev/1cfd627bee05 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 21:03:13 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 12 Jun 2016 01:03:13 +0000 Subject: [issue15468] Edit docs to hide hashlib.md5() In-Reply-To: <1343404007.83.0.817302008925.issue15468@psf.upfronthosting.co.za> Message-ID: <1465693393.87.0.29278803465.issue15468@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 21:07:40 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Jun 2016 01:07:40 +0000 Subject: [issue14209] pkgutil.iter_zipimport_modules ignores the prefix parameter for packages In-Reply-To: <1331046144.89.0.833633660995.issue14209@psf.upfronthosting.co.za> Message-ID: <20160612010737.20084.41086.E05E0D19@psf.io> Roundup Robot added the comment: New changeset 9649acf7d472 by ?ukasz Langa in branch '3.5': Issue #14209: pkgutil.iter_zipimport_modules ignores the prefix for packages https://hg.python.org/cpython/rev/9649acf7d472 New changeset 389b7456a053 by ?ukasz Langa in branch 'default': Merge 3.5, issue #14209 https://hg.python.org/cpython/rev/389b7456a053 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 21:09:36 2016 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Sun, 12 Jun 2016 01:09:36 +0000 Subject: [issue14209] pkgutil.iter_zipimport_modules ignores the prefix parameter for packages In-Reply-To: <1331046144.89.0.833633660995.issue14209@psf.upfronthosting.co.za> Message-ID: <1465693776.69.0.561069212216.issue14209@psf.upfronthosting.co.za> ?ukasz Langa added the comment: Done. Fix is going to be present for 3.5.2 and 3.6. Thank you, James. ---------- resolution: -> fixed status: open -> closed versions: +Python 3.5, Python 3.6 -Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 21:12:50 2016 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Sun, 12 Jun 2016 01:12:50 +0000 Subject: [issue24086] Configparser interpolation is unexpected In-Reply-To: <1430421130.2.0.837084015548.issue24086@psf.upfronthosting.co.za> Message-ID: <1465693970.86.0.0458837335508.issue24086@psf.upfronthosting.co.za> ?ukasz Langa added the comment: This is solved upstream in setuptools by disabling configparser interpolation. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 21:16:59 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 12 Jun 2016 01:16:59 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <1465694219.79.0.211166010184.issue25782@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Patch review: I see two competing solutions with differing behaviors. Yury's raises a RuntimeError in the loop situation. Serhiy's simply reorders the exception context to put the referred to one at the front of the chain in the event of a loop. The 3.5 Release manager or someone familiar with the contextlib ExitStack code where this is triggered should make the decision as to the best way to fix this. (I came to this bug via the ExitStack + subprocess issue27122 which merely has a suggested workaround patch as a band aid that might help until this is fixed) ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 21:17:15 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 12 Jun 2016 01:17:15 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <1465694235.56.0.137341001099.issue25782@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- stage: commit review -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 21:17:53 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 12 Jun 2016 01:17:53 +0000 Subject: [issue27122] Hang with contextlib.ExitStack and subprocess.Popen (regression) In-Reply-To: <1464176880.25.0.308106356091.issue27122@psf.upfronthosting.co.za> Message-ID: <1465694273.04.0.145510127171.issue27122@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- dependencies: +CPython hangs on error __context__ set to the error itself _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 21:23:42 2016 From: report at bugs.python.org (Larry Hastings) Date: Sun, 12 Jun 2016 01:23:42 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <1465694622.54.0.019744642218.issue25782@psf.upfronthosting.co.za> Larry Hastings added the comment: I'm not the right person to decide this. As RM, all I can do is decide whether or not to hold up a release based on the bug. The answer: no. Since this isn't fixed yet in the 3.5 branch, 3.5.2 will go out without it being fixed. Sorry folks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 22:03:05 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 12 Jun 2016 02:03:05 +0000 Subject: [issue27122] Hang with contextlib.ExitStack and subprocess.Popen (regression) In-Reply-To: <1464176880.25.0.308106356091.issue27122@psf.upfronthosting.co.za> Message-ID: <1465696985.75.0.4018424765.issue27122@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Proposed fix based on STINNER and Nick's earlier comments and the simple reproducer turned into a test. Nick - your most recent comment makes me wonder if this shouldn't be doing more. this does make both hang_bug*.py examples do something reasonable. I'm at a loss for what Misc/NEWS entry to write for this one as I don't know how to accurately describe the scope of the problem. I'd also like to avoid conflating issue25782's problem with this one (that causes the hang, but once that is fixed isn't there still a problem here to be fixed)? ---------- keywords: +patch Added file: http://bugs.python.org/file43354/issue27122-gps01.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 22:03:39 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 12 Jun 2016 02:03:39 +0000 Subject: [issue27122] Hang with contextlib.ExitStack and subprocess.Popen (regression) In-Reply-To: <1464176880.25.0.308106356091.issue27122@psf.upfronthosting.co.za> Message-ID: <1465697019.9.0.562449927516.issue27122@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- assignee: gregory.p.smith -> ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 22:06:37 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Jun 2016 02:06:37 +0000 Subject: [issue24136] document PEP 448: unpacking generalization In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za> Message-ID: <20160612020634.9983.59650.1F9E56B8@psf.io> Roundup Robot added the comment: New changeset a7e04b4e51b2 by Martin Panter in branch '3.5': Issue #24136: Document generalized unpacking, PEP 448 https://hg.python.org/cpython/rev/a7e04b4e51b2 New changeset 4cf3389cd8e6 by Martin Panter in branch 'default': Issue #24136: Merge unpacking doc from 3.5 https://hg.python.org/cpython/rev/4cf3389cd8e6 New changeset 2c10f0e92256 by Martin Panter in branch 'default': Issue #24136: Adjust f-strings doc for interable unpacking https://hg.python.org/cpython/rev/2c10f0e92256 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 22:14:02 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 12 Jun 2016 02:14:02 +0000 Subject: [issue27136] sock_connect fails for bluetooth (and probably others) In-Reply-To: <1464346938.98.0.196127839357.issue27136@psf.upfronthosting.co.za> Message-ID: <1465697642.15.0.0210379291513.issue27136@psf.upfronthosting.co.za> Martin Panter added the comment: Revision 3f49e89be8a9 seems to be the cause of an x86 Tiger buildbot failure: http://buildbot.python.org/all/builders/x86%20Tiger%203.x/builds/10924/steps/test/logs/stdio ====================================================================== FAIL: test_create_connection_no_inet_pton (test.test_asyncio.test_base_events.BaseEventLoopWithSelectorTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/mock.py", line 1180, in patched return func(*args, **keywargs) File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_base_events.py", line 1210, in test_create_connection_no_inet_pton self._test_create_connection_ip_addr(m_socket, False) File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_base_events.py", line 1195, in _test_create_connection_ip_addr self.assertRegex(host, r'::(0\.)*2') AssertionError: Regex didn't match: '::(0\\.)*2' not found in '0.0.0.2' ---------- nosy: +martin.panter status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 22:36:29 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 12 Jun 2016 02:36:29 +0000 Subject: [issue17900] Recursive OrderedDict pickling In-Reply-To: <1367610016.74.0.566900545996.issue17900@psf.upfronthosting.co.za> Message-ID: <1465698989.24.0.104273518445.issue17900@psf.upfronthosting.co.za> Raymond Hettinger added the comment: At this point, we can drop it. PyYAML will just have to deal with it. ---------- assignee: rhettinger -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 22:58:01 2016 From: report at bugs.python.org (Kaushik Nadikuditi) Date: Sun, 12 Jun 2016 02:58:01 +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: <1465700281.09.0.816474738836.issue16484@psf.upfronthosting.co.za> Kaushik Nadikuditi added the comment: - fixed broken test - test_mixed_case_module_names_are_lower_cased - tested on Windows, Mac, Ubuntu - thank you Martin Panter for suggestions. ---------- components: +Tests -Documentation type: -> compile error Added file: http://bugs.python.org/file43355/issue16484_test_python3.6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 11 22:58:53 2016 From: report at bugs.python.org (Larry Hastings) Date: Sun, 12 Jun 2016 02:58:53 +0000 Subject: [issue27292] Warn users that os.urandom() can return insecure values In-Reply-To: <1465639674.0.0.865291084778.issue27292@psf.upfronthosting.co.za> Message-ID: <1465700333.61.0.127406993755.issue27292@psf.upfronthosting.co.za> Larry Hastings added the comment: This is not a release blocker. ---------- priority: release blocker -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 00:10:49 2016 From: report at bugs.python.org (gr zhang) Date: Sun, 12 Jun 2016 04:10:49 +0000 Subject: [issue27299] urllib does not splitport while putrequest realhost to HTTP headers Message-ID: <1465704649.89.0.0364976733052.issue27299@psf.upfronthosting.co.za> New submission from gr zhang: h.putheader('Host', "www.github.com:443") # this will make errcode 405, if urllib lib splitport first, and this will set Host ---> www.github.com and get 200 code. h.endheaders(None) errcode, errmsg, headers = h.getreply() print errcode ---------- components: Library (Lib) files: urllib_part.py messages: 268317 nosy: gr zhang priority: normal severity: normal status: open title: urllib does not splitport while putrequest realhost to HTTP headers type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file43356/urllib_part.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 00:27:37 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 12 Jun 2016 04:27:37 +0000 Subject: [issue27299] urllib does not splitport while putrequest realhost to HTTP headers In-Reply-To: <1465704649.89.0.0364976733052.issue27299@psf.upfronthosting.co.za> Message-ID: <1465705657.16.0.200073238512.issue27299@psf.upfronthosting.co.za> Xiang Zhang added the comment: The standard[1] says the Host header is OK to include port. Why not use 'https://www.github.com'? [1] https://tools.ietf.org/html/rfc7230#section-5.4 ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 00:28:04 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 12 Jun 2016 04:28:04 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1465705684.3.0.971329712643.issue5124@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Serhiy: entry=entry as much as any name=expression pair to print the value of variable entry on test failure, either "entry=)" or "entry=)", as in ====================================================================== FAIL: test_paste_entry (__main__.PasteTest) (ans='two', end='end', entry=) Test pasting into an entry with and without a selection. ---------------------------------------------------------------------- Traceback (most recent call last): File "F:\Python\dev\36\lib\idlelib\idle_test\test_editmenu.py", line 53, in test_paste_entry self.assertTrue(False) AssertionError: False is not true ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 00:37:15 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Jun 2016 04:37:15 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1465706235.92.0.582626838529.issue5124@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ah, I looked on 3.5 change and missed that in 3.6 you test both tkinter.Entry and ttk.Entry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 00:38:21 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Jun 2016 04:38: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: <20160612043818.28424.92421.EC23B7D0@psf.io> Roundup Robot added the comment: New changeset d84268ed62ac by Martin Panter in branch '3.5': Issue #16484: Fix pydoc link and test on Windows, by Kaushik Nadikuditi https://hg.python.org/cpython/rev/d84268ed62ac New changeset 84d1e5a4b1c5 by Martin Panter in branch 'default': Issue #16484: Merge pydoc Windows fixes from 3.5 https://hg.python.org/cpython/rev/84d1e5a4b1c5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 00:41:02 2016 From: report at bugs.python.org (Larry Hastings) Date: Sun, 12 Jun 2016 04:41:02 +0000 Subject: [issue26867] test_ssl test_options fails on ubuntu 16.04 In-Reply-To: <1461728238.71.0.110276038105.issue26867@psf.upfronthosting.co.za> Message-ID: <1465706462.83.0.930563302856.issue26867@psf.upfronthosting.co.za> Larry Hastings added the comment: I got this when testing 3.5.2rc1 on my Ubuntu 16.04 machine. CAs Xiang Zhang showed, this is Ubuntu doing something crazy. I ignored the failure and shipped 3.5.2rc1, however I would be interested in suppressing the test for 3.5.2 final. That way it has a chance of passing the whole test suite on user's Linux machines...! ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 00:49:23 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Jun 2016 04:49: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: <20160612044918.114484.13313.AC5A2C26@psf.io> Roundup Robot added the comment: New changeset c60d2e4f4f96 by Martin Panter in branch '2.7': Issue #16484: PYTHONDOCS still uses ?http:? in Python 2 https://hg.python.org/cpython/rev/c60d2e4f4f96 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 00:56:34 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Jun 2016 04:56:34 +0000 Subject: [issue27095] Simplify MAKE_FUNCTION In-Reply-To: <1464038780.83.0.81155899453.issue27095@psf.upfronthosting.co.za> Message-ID: <1465707394.33.0.501013368329.issue27095@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Added more comments on Rietveld. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 00:59:10 2016 From: report at bugs.python.org (Matthias Klose) Date: Sun, 12 Jun 2016 04:59:10 +0000 Subject: [issue26867] test_ssl test_options fails on ubuntu 16.04 In-Reply-To: <1461728238.71.0.110276038105.issue26867@psf.upfronthosting.co.za> Message-ID: <1465707550.63.0.424961812017.issue26867@psf.upfronthosting.co.za> Matthias Klose added the comment: ubuntu doesn't do anything crazy, but just disables oldish, deprecated und probably now unsecure ssl protocols. This is done by other vendors as well. From my point of of view this skip_if_ubuntu stuff should be replaced by proper feature tests. I'll see if I can come up with another work around. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 01:07:58 2016 From: report at bugs.python.org (gr zhang) Date: Sun, 12 Jun 2016 05:07:58 +0000 Subject: [issue27299] urllib does not splitport while putrequest realhost to HTTP headers In-Reply-To: <1465704649.89.0.0364976733052.issue27299@psf.upfronthosting.co.za> Message-ID: <1465708078.42.0.639773946313.issue27299@psf.upfronthosting.co.za> gr zhang added the comment: Yes, I mean when set h.putheader('Host', "www.github.com:443") and the status code from httplib will be 405 while when set h.putheader('Host', "www.github.com") the code will be 200, this is confused to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 01:11:04 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 12 Jun 2016 05:11:04 +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: <1465708264.84.0.0590568621108.issue16484@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- type: compile error -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 01:30:28 2016 From: report at bugs.python.org (Larry Hastings) Date: Sun, 12 Jun 2016 05:30:28 +0000 Subject: [issue26867] test_ssl test_options fails on ubuntu 16.04 In-Reply-To: <1461728238.71.0.110276038105.issue26867@psf.upfronthosting.co.za> Message-ID: <1465709428.86.0.0148984913386.issue26867@psf.upfronthosting.co.za> Larry Hastings added the comment: This still affects 3.4 and 3.5. It'd be lovely if it could be fixed in all the still-alive versions. (Yes, this is technically a "bug fix", but I'd still like it fixed in 3.4.) ---------- versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 01:33:06 2016 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 12 Jun 2016 05:33:06 +0000 Subject: [issue25455] Some repr implementations don't check for self-referential structures In-Reply-To: <1445455038.6.0.824380060049.issue25455@psf.upfronthosting.co.za> Message-ID: <1465709586.53.0.507363057644.issue25455@psf.upfronthosting.co.za> Stefan Behnel added the comment: Etree patch looks straight forward to me, feel free to apply it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 01:49:45 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 12 Jun 2016 05:49:45 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1465710585.38.0.171687193654.issue27186@psf.upfronthosting.co.za> Martin Panter added the comment: Test_fspath_protocol_bytes() (added in revision 5a62d682636e) fails on Windows: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/7777/steps/test/logs/stdio ====================================================================== ERROR: test_fspath_protocol_bytes (test.test_os.TestScandir) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_os.py", line 2958, in test_fspath_protocol_bytes bytes_entry = self.create_file_entry(name=bytes_filename) File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_os.py", line 2932, in create_file_entry return self.get_entry(os.path.basename(filename)) File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_os.py", line 2923, in get_entry entries = list(os.scandir(path)) TypeError: os.scandir() doesn't support bytes path on Windows, use Unicode instead ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 01:59:10 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 12 Jun 2016 05:59:10 +0000 Subject: [issue27277] Fatal Python error: Segmentation fault in test_exceptions In-Reply-To: <1465457335.09.0.330685258307.issue27277@psf.upfronthosting.co.za> Message-ID: <1465711150.82.0.244477231547.issue27277@psf.upfronthosting.co.za> Berker Peksag added the comment: Can you please try without coveragepy? ./python -m test test_exceptions ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 02:00:43 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 12 Jun 2016 06:00:43 +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: <1465711243.12.0.0297833113821.issue16484@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks Kaushik. I also changed the https:// detection to also detect http://, to maintain backwards compatibility. I am porting these changes to 2.7. ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 02:26:22 2016 From: report at bugs.python.org (Rohit Mediratta) Date: Sun, 12 Jun 2016 06:26:22 +0000 Subject: [issue27277] Fatal Python error: Segmentation fault in test_exceptions In-Reply-To: <1465457335.09.0.330685258307.issue27277@psf.upfronthosting.co.za> Message-ID: <1465712782.72.0.184290271074.issue27277@psf.upfronthosting.co.za> Rohit Mediratta added the comment: Leads to the same Segfault [/loc/rom/pyd/cpython] $ ./python -m test test_exceptions Run tests sequentially 0:00:00 [1/1] test_exceptions Fatal Python error: Segmentation fault Current thread 0x00007fb466572700 (most recent call first): File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f File "/local/romedira/pydev/cpython/Lib/test/test_exceptions.py", line 490 in f ... Segmentation fault (core dumped) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 02:28:46 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Jun 2016 06:28:46 +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: <20160612062842.120707.31173.F9D0A1B8@psf.io> Roundup Robot added the comment: New changeset ede10138327e by Martin Panter in branch '2.7': #16484: Change PYTHONDOCS to "https:", and fix links to use lowercase https://hg.python.org/cpython/rev/ede10138327e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 02:28:46 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Jun 2016 06:28:46 +0000 Subject: [issue27030] Remove deprecated re features In-Reply-To: <1463337497.02.0.81864271809.issue27030@psf.upfronthosting.co.za> Message-ID: <20160612062842.120707.85426.BB726975@psf.io> Roundup Robot added the comment: New changeset a2482e805dff by Martin Panter in branch '3.5': Fix buggy RE ?\parrot_example.py?, uncovered by Issue #27030 https://hg.python.org/cpython/rev/a2482e805dff New changeset be193f8dbe4c by Martin Panter in branch 'default': Issue #27030: Merge RE fix from 3.5 https://hg.python.org/cpython/rev/be193f8dbe4c New changeset c5411cfa0bd3 by Martin Panter in branch '2.7': Fix buggy RE ?\parrot_example.py?, uncovered by Issue #27030 https://hg.python.org/cpython/rev/c5411cfa0bd3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 02:49:49 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Jun 2016 06:49:49 +0000 Subject: [issue25455] Some repr implementations don't check for self-referential structures In-Reply-To: <1445455038.6.0.824380060049.issue25455@psf.upfronthosting.co.za> Message-ID: <20160612064946.114506.60808.CE61A282@psf.io> Roundup Robot added the comment: New changeset e44bd1259bda by Serhiy Storchaka in branch '3.5': Issue #25455: Fixed a crash in repr of ElementTree.Element with recursive tag. https://hg.python.org/cpython/rev/e44bd1259bda New changeset e3671a684ea0 by Serhiy Storchaka in branch 'default': Issue #25455: Fixed a crash in repr of ElementTree.Element with recursive tag. https://hg.python.org/cpython/rev/e3671a684ea0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 02:49:49 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Jun 2016 06:49:49 +0000 Subject: [issue27286] str object got multiple values for keyword argument In-Reply-To: <1465551431.42.0.267871198404.issue27286@psf.upfronthosting.co.za> Message-ID: <20160612064945.114506.66444.77CFD521@psf.io> Roundup Robot added the comment: New changeset 34d24c51eab6 by Serhiy Storchaka in branch '3.5': Issue #27286: Fixed compiling BUILD_MAP_UNPACK_WITH_CALL opcode. Calling https://hg.python.org/cpython/rev/34d24c51eab6 New changeset 194549801bd5 by Serhiy Storchaka in branch 'default': Issue #27286: Fixed compiling BUILD_MAP_UNPACK_WITH_CALL opcode. Calling https://hg.python.org/cpython/rev/194549801bd5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 03:17:55 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 12 Jun 2016 07:17:55 +0000 Subject: [issue24136] document PEP 448: unpacking generalization In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za> Message-ID: <1465715875.85.0.060803962787.issue24136@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for the review. I committed my patch in the hope that it makes it into 3.5.2, but if people want to suggest further improvements etc that is okay. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 03:22:45 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 12 Jun 2016 07:22:45 +0000 Subject: [issue10839] email module should not allow some header field repetitions In-Reply-To: <1294263603.86.0.308955870327.issue10839@psf.upfronthosting.co.za> Message-ID: <1465716165.85.0.175942517345.issue10839@psf.upfronthosting.co.za> Berker Peksag added the comment: The API in Python 3 is very different and I'm not sure we can backport the expected behavior without breaking other people's code (unless we treat this as a security issue). Here is a naive backport for 2.7. Known test failures: test_get_all, test_get_decoded_uu_payload, test_multipart_no_boundary ---------- nosy: +berker.peksag Added file: http://bugs.python.org/file43357/issue10839_27.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 03:35:03 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 12 Jun 2016 07:35:03 +0000 Subject: [issue15649] subprocess.Popen.communicate: accept str for input parameter if universal_newlines is False In-Reply-To: <1344959221.38.0.0409924242397.issue15649@psf.upfronthosting.co.za> Message-ID: <1465716903.18.0.972752850081.issue15649@psf.upfronthosting.co.za> Martin Panter added the comment: See also Issue 27273, proposing to use text string input as an indicator to turn on universal_newlines=True in the higher-level functions. I?m not excited by either proposal, but I find the other one a bit more palatable. IMO allowing text string input to communicate(), but returning byte string outputs would be a bad idea. It would have been better to call the universal_newlines=... flag ?text_mode?. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 03:41:31 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Jun 2016 07:41:31 +0000 Subject: [issue27286] str object got multiple values for keyword argument In-Reply-To: <1465551431.42.0.267871198404.issue27286@psf.upfronthosting.co.za> Message-ID: <1465717291.79.0.249250710245.issue27286@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 03:53:57 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 12 Jun 2016 07:53:57 +0000 Subject: [issue25455] Some repr implementations don't check for self-referential structures In-Reply-To: <1445455038.6.0.824380060049.issue25455@psf.upfronthosting.co.za> Message-ID: <1465718037.08.0.552616509601.issue25455@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: rhettinger -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 03:54:21 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 12 Jun 2016 07:54:21 +0000 Subject: [issue12623] "universal newlines" subprocess support broken with select- and poll-based communicate() In-Reply-To: <1311451893.22.0.0169745025507.issue12623@psf.upfronthosting.co.za> Message-ID: <1465718061.25.0.222451323867.issue12623@psf.upfronthosting.co.za> Martin Panter added the comment: . Summary: There was originally a bug, but it has been fixed. At best, we leave this open to work on including Andrew?s patch. Andrew?s patch adds a modified copy of test_universal_newlines_communicate_stdin(). But it does not look correct, and would fail on Windows. It needs to avoid decoding newlines in the child, like in revision 150fa296f5b9. IMO the existing test_universal_newlines_communicate_stdin() test should also be adjusted to verify that os.linesep was sent to the child process. Also, I don?t understand the SETBINARY business. Aren?t stdin etc set to binary mode by default in Python 3? Yes, it would be required for Python 2 compatibility, but if this patch is only for Python 3, why do we need it? Anyway, Antoine opened this bug specifically about the ?select- and poll-based? implementation (now based on the new selectors module). That implementation is only used with multiple pipes. So I don?t see how the patch is relevant to the original issue (although it may be worthwhile updating and adding anyway). Regarding Antoine?s original report, we now do encode text strings to bytes. This was fixed as a side effect of revision c4a0fa6e687c in 3.3 (added timeout=... parameter), and directly in 3.2 by Issue 16903. As for newline translation, I?m not sure if that is really relevant. The selectors implementation is only used if sys.platform != "win32", while os.linesep translation only needs to happen when 'posix' not in sys.builtin_module_names. I suspect in all cases where the selectors implementation is used, and os.linesep is "\n", so it is not actually a bug. ---------- components: +Tests nosy: +martin.panter priority: critical -> normal resolution: -> out of date stage: needs patch -> patch review superseder: -> subprocess.Popen.communicate with universal_newlines=True doesn't accept strings on 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 04:00:55 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 12 Jun 2016 08:00:55 +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: <1465718455.68.0.946216311016.issue16484@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 04:27:22 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Jun 2016 08:27:22 +0000 Subject: [issue17900] Recursive OrderedDict pickling In-Reply-To: <1367610016.74.0.566900545996.issue17900@psf.upfronthosting.co.za> Message-ID: <1465720042.51.0.975523537882.issue17900@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Reported PyYAML issue: https://bitbucket.org/xi/pyyaml/issues/61/ordereddict-doesnt-round-trip. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 04:46:58 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Jun 2016 08:46:58 +0000 Subject: [issue25455] Some repr implementations don't check for self-referential structures In-Reply-To: <1445455038.6.0.824380060049.issue25455@psf.upfronthosting.co.za> Message-ID: <1465721218.24.0.777355815315.issue25455@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 04:49:05 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 12 Jun 2016 08:49:05 +0000 Subject: [issue27221] multiprocessing documentation is outdated regarding method picklability In-Reply-To: <1465069362.83.0.142351405451.issue27221@psf.upfronthosting.co.za> Message-ID: <1465721345.8.0.697007623545.issue27221@psf.upfronthosting.co.za> Berker Peksag added the comment: Actually, we can remove the versionchanged directive. The attached script works fine with the spawn start method in Python 3.4. I will commit the following version: Ensure that all arguments to :meth:`Process.__init__` are picklable. Also, if you subclass :class:`~multiprocessing.Process` then make sure that instances will be picklable when the :meth:`Process.start ` method is called. ---------- Added file: http://bugs.python.org/file43358/mm.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 04:57:41 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Jun 2016 08:57:41 +0000 Subject: [issue25455] Some repr implementations don't check for self-referential structures In-Reply-To: <1445455038.6.0.824380060049.issue25455@psf.upfronthosting.co.za> Message-ID: <20160612085738.11470.49788.7DD03986@psf.io> Roundup Robot added the comment: New changeset c071da010053 by Serhiy Storchaka in branch '2.7': Issue #25455: Fixed a crash in repr of cElementTree.Element with recursive tag. https://hg.python.org/cpython/rev/c071da010053 New changeset 17e78918f608 by Serhiy Storchaka in branch '3.5': Issue #25455: Fixed a crash in repr of recursive functools.partial objects. https://hg.python.org/cpython/rev/17e78918f608 New changeset 86959c696ab7 by Serhiy Storchaka in branch 'default': Issue #25455: Fixed a crash in repr of recursive functools.partial objects. https://hg.python.org/cpython/rev/86959c696ab7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 05:19:30 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Jun 2016 09:19:30 +0000 Subject: [issue27221] multiprocessing documentation is outdated regarding method picklability In-Reply-To: <1465069362.83.0.142351405451.issue27221@psf.upfronthosting.co.za> Message-ID: <20160612091926.81413.84994.3B0EC977@psf.io> Roundup Robot added the comment: New changeset 97254031f0b7 by Berker Peksag in branch '3.5': Issue #27221: Delete an outdated paragraph about pickle support of Process https://hg.python.org/cpython/rev/97254031f0b7 New changeset 5b9d8b5b1139 by Berker Peksag in branch 'default': Issue #27221: Merge from 3.5 https://hg.python.org/cpython/rev/5b9d8b5b1139 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 05:20:13 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 12 Jun 2016 09:20:13 +0000 Subject: [issue27221] multiprocessing documentation is outdated regarding method picklability In-Reply-To: <1465069362.83.0.142351405451.issue27221@psf.upfronthosting.co.za> Message-ID: <1465723213.95.0.233384373321.issue27221@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 05:41:46 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 12 Jun 2016 09:41:46 +0000 Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX) In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za> Message-ID: <1465724506.69.0.0996802529673.issue26439@psf.upfronthosting.co.za> Martin Panter added the comment: . Michael, how are you supposed to apply your latest patch? I have Gnu Patch 2.7.5, but even in the best case it doesn?t find the files to patch: $ patch -p1 -n < python.Lib.ctypes.160608.patch can't find file to patch at input line 2 The text leading up to this was: -------------------------- |diff -r Python-2.7.11/Lib/ctypes/__init__.py python-2.7.11.5/Lib/ctypes/__init__.py -------------------------- Perhaps can you make a ?unified? diff (-u option) like you did in your previous patches? Whatever you did with Python3.issue26439.160511.patch seemed to work best. Also, since your patches add new functionality (the automatic archive member detection), they will have to be for Python 3, not 2. === Tuple vs "archive(member)" string being an API change: > name = "libcrypto.a(libcrypto.so.1.0.0)" > name = ("libcrypto.a", "libcrypto.so.1.0.0") > name = ("libcrypto.a(libcrypto.so.1.0.0)", RTLD_MEMBER) IMO all three options are API changes. Even though the first one is still a string, we are changing the meaning of the string. It no longer always means a plain file or library name, and you lose the ability to indicate a plain library file when the special format is used (even though that ability is unlikely to be used much). === Yes, please remove the internal variables from the signatures. Local variables always override the global scope anyway, so it makes no difference. And if you use the wrong kind of object (mutable object) as a default value in the signature, it can actually lead to subtle bugs. I am happy to try modifying your code (once we get the patch format etc figured out). That is probably the quickest way to fix up some of the problems that are obvious to me, e.g. variables in signatures, subprocess driving, etc. === With my understanding, find_library("FOO") should not recognize /usr/lib/FOO.so, it should only look for /usr/lib/libFOO.so, etc. So it should return None. Does linking with -lFOO recognize /usr/lib/FOO.so for you? Similarly, find_library("../some/where/Foo.so") shouldn?t work. You wouldn?t pass that with -l to the linker, I don?t think. ---------- versions: +Python 3.6 -Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 05:51:54 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 12 Jun 2016 09:51:54 +0000 Subject: [issue15243] Misleading documentation for __prepare__ In-Reply-To: <1341328118.33.0.670602196671.issue15243@psf.upfronthosting.co.za> Message-ID: <1465725114.83.0.0178399080532.issue15243@psf.upfronthosting.co.za> Berker Peksag added the comment: The documentation should mention that the __prepare__ method must be implemented as a classmethod (see msg164697 for the reference.) The example at https://docs.python.org/dev/reference/datamodel.html#metaclass-example needs to be linked from the "Preparing the class namespace" section. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 05:56:36 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Sun, 12 Jun 2016 09:56:36 +0000 Subject: [issue27300] tempfile.TemporaryFile(): missing errors=... argument Message-ID: <1465725395.98.0.993372982316.issue27300@psf.upfronthosting.co.za> Changes by ???? ????????? : ---------- components: IO, Library (Lib) nosy: mmarkk priority: normal severity: normal status: open title: tempfile.TemporaryFile(): missing errors=... argument type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 06:07:09 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 12 Jun 2016 10:07:09 +0000 Subject: [issue27299] urllib does not splitport while putrequest realhost to HTTP headers In-Reply-To: <1465704649.89.0.0364976733052.issue27299@psf.upfronthosting.co.za> Message-ID: <1465726029.0.0.197068250087.issue27299@psf.upfronthosting.co.za> Xiang Zhang added the comment: It's server side behaviour. Asking here may not get results. I think it's normal for the server to return error if it thinks the header is invalid. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 06:25:49 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 12 Jun 2016 10:25:49 +0000 Subject: [issue6057] sqlite3 error classes should be documented In-Reply-To: <1242673346.43.0.948670169284.issue6057@psf.upfronthosting.co.za> Message-ID: <1465727149.61.0.86016236982.issue6057@psf.upfronthosting.co.za> Berker Peksag added the comment: Here is a list of exceptions that need to be documented: IntegrityError, Warning, Error, ProgrammingError and DatabaseError. ---------- nosy: +berker.peksag priority: low -> normal type: behavior -> enhancement versions: +Python 3.5, Python 3.6 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 06:42:03 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Jun 2016 10:42:03 +0000 Subject: [issue27188] sqlite3 execute* methods return value not documented In-Reply-To: <1464904414.88.0.548243958784.issue27188@psf.upfronthosting.co.za> Message-ID: <20160612104200.26564.59873.49B7152C@psf.io> Roundup Robot added the comment: New changeset a825aee0721f by Berker Peksag in branch '3.5': Issue #27188: Fix various sqlite3 documentation errors https://hg.python.org/cpython/rev/a825aee0721f New changeset 187b2bc0fe26 by Berker Peksag in branch 'default': Issue #27188: Merge from 3.5 https://hg.python.org/cpython/rev/187b2bc0fe26 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 06:44:25 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 12 Jun 2016 10:44:25 +0000 Subject: [issue27188] sqlite3 execute* methods return value not documented In-Reply-To: <1464904414.88.0.548243958784.issue27188@psf.upfronthosting.co.za> Message-ID: <1465728265.66.0.912833137394.issue27188@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch Dave. I found a couple of more issues while reviewing the patch and fixed them. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 06:57:35 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 12 Jun 2016 10:57:35 +0000 Subject: [issue16182] readline: Wrong tab completion scope indices in Unicode terminals In-Reply-To: <1349813384.06.0.615857426211.issue16182@psf.upfronthosting.co.za> Message-ID: <1465729055.83.0.961715182935.issue16182@psf.upfronthosting.co.za> Martin Panter added the comment: I updated the patch to fix the error handling and memory leak. it also now skips the test in case the locale cannot encode the test data. ---------- Added file: http://bugs.python.org/file43359/readline_locale.v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:10:16 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Jun 2016 11:10:16 +0000 Subject: [issue27190] Check sqlite3_version before allowing check_same_thread = False In-Reply-To: <1464915219.9.0.729350732197.issue27190@psf.upfronthosting.co.za> Message-ID: <20160612111013.81022.64036.C6325BC1@psf.io> Roundup Robot added the comment: New changeset 12bf71b9f1cd by Berker Peksag in branch '3.5': Issue #27190: Raise NotSupportedError if sqlite3 is older than 3.3.1 https://hg.python.org/cpython/rev/12bf71b9f1cd New changeset 4502cff170c2 by Berker Peksag in branch 'default': Issue #27190: Merge from 3.5 https://hg.python.org/cpython/rev/4502cff170c2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:11:03 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 12 Jun 2016 11:11:03 +0000 Subject: [issue27190] Check sqlite3_version before allowing check_same_thread = False In-Reply-To: <1464915219.9.0.729350732197.issue27190@psf.upfronthosting.co.za> Message-ID: <1465729863.61.0.126890789534.issue27190@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:21:08 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 12 Jun 2016 11:21:08 +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: <1465730468.95.0.855080668353.issue21250@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch Alex. Some quick review comments: * We need to skip SqliteOnConflictTests if the installed sqlite3 doesn't support the feature * There is no need to duplicate https://www.sqlite.org/lang_conflict.html in every test. You can add it to SqliteOnConflictTests docstring. * Instead of ``try: except sqlite.IntegrityError: `` we can make sure that sqlite.IntegrityError is raised by using assertRaises (like you did in CheckOnConflictFail.) * The following pattern can be replaced with a list comprehension: + returned_rows = [] + for row in self.cu: + returned_rows.append(row) ---------- nosy: +berker.peksag stage: needs patch -> patch review versions: +Python 3.6 -Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:21:18 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:21:18 +0000 Subject: [issue16113] Add SHA-3 and SHAKE (Keccak) support In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za> Message-ID: <1465730478.25.0.951119033646.issue16113@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: christian.heimes -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:21:26 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:21:26 +0000 Subject: [issue26798] add BLAKE2 to hashlib In-Reply-To: <1461004812.44.0.872226457841.issue26798@psf.upfronthosting.co.za> Message-ID: <1465730486.08.0.555894923964.issue26798@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: christian.heimes -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:21:31 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:21:31 +0000 Subject: [issue16353] add function to os module for getting path to default shell In-Reply-To: <1351473560.4.0.147895276383.issue16353@psf.upfronthosting.co.za> Message-ID: <1465730491.92.0.453090991326.issue16353@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: christian.heimes -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:22:07 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:22:07 +0000 Subject: [issue26907] Add missing getsockopt constants In-Reply-To: <1462199363.91.0.625327027717.issue26907@psf.upfronthosting.co.za> Message-ID: <1465730527.29.0.357660137122.issue26907@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: christian.heimes -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:22:13 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:22:13 +0000 Subject: [issue26836] Add memfd_create to os module In-Reply-To: <1461506163.13.0.0180353008827.issue26836@psf.upfronthosting.co.za> Message-ID: <1465730533.5.0.960172117331.issue26836@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: christian.heimes -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:22:18 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:22:18 +0000 Subject: [issue26835] Add file-sealing ops to fcntl In-Reply-To: <1461505999.3.0.387096384665.issue26835@psf.upfronthosting.co.za> Message-ID: <1465730538.93.0.869890583817.issue26835@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: christian.heimes -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:22:24 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:22:24 +0000 Subject: [issue26470] Make OpenSSL module compatible with OpenSSL 1.1.0 In-Reply-To: <1456920893.87.0.933592382559.issue26470@psf.upfronthosting.co.za> Message-ID: <1465730544.58.0.839407229118.issue26470@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: christian.heimes -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:22:32 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:22:32 +0000 Subject: [issue4821] Patches for thread-support in built-in SHA modules In-Reply-To: <1231002504.32.0.171592356443.issue4821@psf.upfronthosting.co.za> Message-ID: <1465730552.07.0.663255900574.issue4821@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: christian.heimes -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:22:46 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:22:46 +0000 Subject: [issue18293] ssl.wrap_socket (cert_reqs=...), getpeercert, and unvalidated certificates In-Reply-To: <1372100693.76.0.99629035685.issue18293@psf.upfronthosting.co.za> Message-ID: <1465730566.64.0.512476154943.issue18293@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: christian.heimes -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:22:52 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:22:52 +0000 Subject: [issue26471] load_verify_locations(cadata) should load AUX ASN.1 to supported trusted certs In-Reply-To: <1456921480.82.0.773236455463.issue26471@psf.upfronthosting.co.za> Message-ID: <1465730572.11.0.690522187601.issue26471@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: christian.heimes -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:22:59 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:22:59 +0000 Subject: [issue26122] Isolated mode doesn't ignore PYTHONHASHSEED In-Reply-To: <1452862094.75.0.964095204421.issue26122@psf.upfronthosting.co.za> Message-ID: <1465730579.29.0.84429231391.issue26122@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: christian.heimes -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:23:08 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:23:08 +0000 Subject: [issue16487] Allow ssl certificates to be specified from memory rather than files. In-Reply-To: <1353078615.85.0.973290481578.issue16487@psf.upfronthosting.co.za> Message-ID: <1465730588.69.0.451861569222.issue16487@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: christian.heimes -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:23:15 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:23:15 +0000 Subject: [issue18233] SSLSocket.getpeercertchain() In-Reply-To: <1371415195.44.0.636993698614.issue18233@psf.upfronthosting.co.za> Message-ID: <1465730595.72.0.82998896313.issue18233@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: christian.heimes -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:23:21 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:23:21 +0000 Subject: [issue18369] X509 cert class for ssl module In-Reply-To: <1373055037.38.0.259814019718.issue18369@psf.upfronthosting.co.za> Message-ID: <1465730601.58.0.310616025094.issue18369@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: christian.heimes -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:23:27 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:23:27 +0000 Subject: [issue20916] ssl.enum_certificates() will not return all certificates trusted by Windows In-Reply-To: <1394740101.16.0.76901026465.issue20916@psf.upfronthosting.co.za> Message-ID: <1465730607.01.0.152232943423.issue20916@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: christian.heimes -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:23:48 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:23:48 +0000 Subject: [issue16234] Implement correct block_size and tests for HMAC-SHA3 In-Reply-To: <1350245755.11.0.901944251293.issue16234@psf.upfronthosting.co.za> Message-ID: <1465730628.3.0.297308573271.issue16234@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:24:01 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:24:01 +0000 Subject: [issue19328] Improve PBKDF2 documentation In-Reply-To: <1382355496.68.0.742475173572.issue19328@psf.upfronthosting.co.za> Message-ID: <1465730641.77.0.502349762983.issue19328@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:24:50 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:24:50 +0000 Subject: [issue20674] Update comments in dictobject.c In-Reply-To: <1392744795.57.0.649500024154.issue20674@psf.upfronthosting.co.za> Message-ID: <1465730690.39.0.364375505266.issue20674@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: christian.heimes -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:25:02 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:25:02 +0000 Subject: [issue16632] Enable DEP and ASLR In-Reply-To: <1354875781.46.0.686705865065.issue16632@psf.upfronthosting.co.za> Message-ID: <1465730702.01.0.788123787385.issue16632@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: christian.heimes -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:25:12 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:25:12 +0000 Subject: [issue15464] ssl: add set_msg_callback function In-Reply-To: <1343352856.85.0.212414509347.issue15464@psf.upfronthosting.co.za> Message-ID: <1465730712.82.0.322230307721.issue15464@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: christian.heimes -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:25:19 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:25:19 +0000 Subject: [issue18550] internal_setblocking() doesn't check return value of fcntl() In-Reply-To: <1374694779.19.0.0902694218162.issue18550@psf.upfronthosting.co.za> Message-ID: <1465730719.57.0.672149041381.issue18550@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: christian.heimes -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:25:27 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:25:27 +0000 Subject: [issue17405] Add _Py_memset_s() to securely clear memory In-Reply-To: <1363107252.29.0.782882608.issue17405@psf.upfronthosting.co.za> Message-ID: <1465730727.5.0.0678733689088.issue17405@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: christian.heimes -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:25:33 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:25:33 +0000 Subject: [issue18546] ssl.get_server_certificate like addition for cert chain In-Reply-To: <1374677834.03.0.406670886322.issue18546@psf.upfronthosting.co.za> Message-ID: <1465730733.86.0.504486717145.issue18546@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: christian.heimes -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:25:40 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:25:40 +0000 Subject: [issue17318] xml.sax and xml.dom fetch DTDs by default In-Reply-To: <1362012637.97.0.538376803739.issue17318@psf.upfronthosting.co.za> Message-ID: <1465730740.78.0.0589911151118.issue17318@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: christian.heimes -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:33:28 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:33:28 +0000 Subject: [issue26867] test_ssl test_options fails on ubuntu 16.04 In-Reply-To: <1461728238.71.0.110276038105.issue26867@psf.upfronthosting.co.za> Message-ID: <1465731208.71.0.724282780565.issue26867@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: -christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:33:38 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:33:38 +0000 Subject: [issue27292] Warn users that os.urandom() can return insecure values In-Reply-To: <1465639674.0.0.865291084778.issue27292@psf.upfronthosting.co.za> Message-ID: <1465731218.58.0.402976321535.issue27292@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: -christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:34:06 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:34:06 +0000 Subject: [issue27293] Summarize issues related to urandom, getrandom etc in secrets documentation In-Reply-To: <1465641058.72.0.740134205443.issue27293@psf.upfronthosting.co.za> Message-ID: <1465731246.91.0.183527622809.issue27293@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: -christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:34:13 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:34:13 +0000 Subject: [issue27272] random.Random should not read 2500 bytes from urandom In-Reply-To: <1465423096.81.0.204885224668.issue27272@psf.upfronthosting.co.za> Message-ID: <1465731253.71.0.0600536678196.issue27272@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: -christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:34:28 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:34:28 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1465731268.95.0.492541074835.issue27266@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: -christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:34:38 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:34:38 +0000 Subject: [issue27279] Add random.cryptorandom() and random.pseudorandom, deprecate os.urandom() In-Reply-To: <1465458864.98.0.412270875525.issue27279@psf.upfronthosting.co.za> Message-ID: <1465731278.37.0.290128246449.issue27279@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: -christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:34:45 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:34:45 +0000 Subject: [issue26826] Expose new copy_file_range() syscall in os module. In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za> Message-ID: <1465731285.86.0.0550228170522.issue26826@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: -christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:34:53 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:34:53 +0000 Subject: [issue27250] Add os.urandom_block() In-Reply-To: <1465302067.94.0.484576804121.issue27250@psf.upfronthosting.co.za> Message-ID: <1465731293.95.0.797200570535.issue27250@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: -christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:35:34 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 11:35:34 +0000 Subject: [issue27297] Add support for /dev/random to "secrets" In-Reply-To: <1465670075.28.0.237473871841.issue27297@psf.upfronthosting.co.za> Message-ID: <1465731334.1.0.928428956335.issue27297@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: -christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:40:02 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 12 Jun 2016 11:40:02 +0000 Subject: [issue25455] Some repr implementations don't check for self-referential structures In-Reply-To: <1445455038.6.0.824380060049.issue25455@psf.upfronthosting.co.za> Message-ID: <1465731602.46.0.02179390899.issue25455@psf.upfronthosting.co.za> Berker Peksag added the comment: I'm not sure if 17e78918f608 is relevant but test_gc is failing on several buildbots: * http://buildbot.python.org/all/builders/PPC64%20Fedora%203.5/builds/716 http://buildbot.python.org/all/builders/PPC64%20Fedora%203.5/builds/716/steps/test/logs/stdio * http://buildbot.python.org/all/builders/s390x%20RHEL%203.5/builds/775 http://buildbot.python.org/all/builders/s390x%20RHEL%203.5/builds/775/steps/test/logs/stdio ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 07:42:07 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 12 Jun 2016 11:42:07 +0000 Subject: [issue27289] test_ftp_timeout fails with EOFError In-Reply-To: <1465590845.17.0.18803116863.issue27289@psf.upfronthosting.co.za> Message-ID: <1465731727.2.0.345897580572.issue27289@psf.upfronthosting.co.za> Berker Peksag added the comment: Just saw this again: http://buildbot.python.org/all/builders/x86-64%20Ubuntu%2015.10%20Skylake%20CPU%203.5/builds/543/steps/test/logs/stdio ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 08:07:48 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Jun 2016 12:07:48 +0000 Subject: [issue25455] Some repr implementations don't check for self-referential structures In-Reply-To: <1445455038.6.0.824380060049.issue25455@psf.upfronthosting.co.za> Message-ID: <1465733268.09.0.716170631773.issue25455@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch for io classes needed an update. ---------- Added file: http://bugs.python.org/file43360/io_recursive_repr2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 08:09:02 2016 From: report at bugs.python.org (Christopher Hoadley) Date: Sun, 12 Jun 2016 12:09:02 +0000 Subject: [issue24869] shlex lineno inaccurate with certain inputs In-Reply-To: <1439571963.46.0.603944237065.issue24869@psf.upfronthosting.co.za> Message-ID: <1465733342.49.0.0377804460135.issue24869@psf.upfronthosting.co.za> Christopher Hoadley added the comment: This problem makes it impossible to use shlex to parse commands where a newline is intended to separate commands. In the attached sample script, I created two input strings with the same tokens in the same order: the only difference is newlines and spaces. In the first string, each token is on its own line, and in the second string the first 2 tokens are on the same line, and the third is on its own. If you look at the lineno association with each token, it is identical between the two strings. But, the two strings have completely different meanings! I have no way to distinguish the behavior. If I want to use the feature of shlex where it will automatically include other command files, then I can't just sanitize the input before sending it on. As it is, the only way that I can see that I can use shlex is if my command language uses some other symbol (i.e. ";") as a command line separator. Since I am defining my own command language, I can do that, but it adds needless complication for the users. ---------- nosy: +hoadlck versions: +Python 3.5 -Python 3.4 Added file: http://bugs.python.org/file43361/ambigious_shlex.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 08:09:27 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Jun 2016 12:09:27 +0000 Subject: [issue25455] Some repr implementations don't check for self-referential structures In-Reply-To: <1445455038.6.0.824380060049.issue25455@psf.upfronthosting.co.za> Message-ID: <20160612120923.81140.27538.DB07E083@psf.io> Roundup Robot added the comment: New changeset 7859742826b2 by Serhiy Storchaka in branch '2.7': Issue #25455: Backported tests for pickling recursive functools.partial objects. https://hg.python.org/cpython/rev/7859742826b2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 08:11:24 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 12 Jun 2016 12:11:24 +0000 Subject: [issue17239] XML vulnerabilities in Python In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za> Message-ID: <1465733484.81.0.0233284089866.issue17239@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- dependencies: +Avoid entity expansion attacks in Element Tree, xml.sax and xml.dom fetch DTDs by default _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 08:14:14 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 12:14:14 +0000 Subject: [issue17239] XML vulnerabilities in Python In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za> Message-ID: <1465733654.19.0.483121504631.issue17239@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: -christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 08:36:14 2016 From: report at bugs.python.org (James Lu) Date: Sun, 12 Jun 2016 12:36:14 +0000 Subject: [issue27295] heaps library does not have support for max heap In-Reply-To: <1465677550.59.0.123275665466.issue27295@psf.upfronthosting.co.za> Message-ID: James Lu added the comment: It's not a very pythoniic way to simply negate the value. Plus, the majority of heap users want performance (heap was made for speed), so a C version would be much better. On Sat, Jun 11, 2016 at 4:39 PM, Raymond Hettinger wrote: > > Raymond Hettinger added the comment: > > Sorry James, we don't grow the APIs without sufficient demonstrated need; > otherwise, we end-up with API sprawl. People with actual use cases haven't > requested behavior (and the occasional one-off gets by negating the numeric > argument). That is why the maxheap functions were intentionally made > private. > > FWIW, this module is very old and the core functions have long proven > themselves sufficient to meet their use cases (like being used in an event > loop to efficiently select the next scheduled event). > > ---------- > resolution: -> rejected > status: open -> closed > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 08:40:22 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Jun 2016 12:40:22 +0000 Subject: [issue25455] Some repr implementations don't check for self-referential structures In-Reply-To: <1445455038.6.0.824380060049.issue25455@psf.upfronthosting.co.za> Message-ID: <1465735222.28.0.371853192507.issue25455@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Indeed, tests for recursive partial objects create reference loops and don't clean them. Thank you Berker. I'll fix this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 08:53:34 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Jun 2016 12:53:34 +0000 Subject: [issue25455] Some repr implementations don't check for self-referential structures In-Reply-To: <1445455038.6.0.824380060049.issue25455@psf.upfronthosting.co.za> Message-ID: <20160612125331.26279.43643.7B25A2B0@psf.io> Roundup Robot added the comment: New changeset 0323b33894f2 by Serhiy Storchaka in branch '3.5': Issue #25455: Clean up reference loops created in tests for recursive https://hg.python.org/cpython/rev/0323b33894f2 New changeset 688edc946ab9 by Serhiy Storchaka in branch '2.7': Issue #25455: Clean up reference loops created in tests for recursive https://hg.python.org/cpython/rev/688edc946ab9 New changeset 818a10534e44 by Serhiy Storchaka in branch 'default': Issue #25455: Clean up reference loops created in tests for recursive https://hg.python.org/cpython/rev/818a10534e44 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 09:13:34 2016 From: report at bugs.python.org (Demur Rumed) Date: Sun, 12 Jun 2016 13:13:34 +0000 Subject: [issue27095] Simplify MAKE_FUNCTION In-Reply-To: <1464038780.83.0.81155899453.issue27095@psf.upfronthosting.co.za> Message-ID: <1465737214.44.0.0210179969502.issue27095@psf.upfronthosting.co.za> Demur Rumed added the comment: Kind of amusing how visit_argannoation logic went full circle. Makes sense considering pre-mkfu patch the ABI was quite similar on that front ---------- Added file: http://bugs.python.org/file43362/mkfu5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 09:15:50 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Jun 2016 13:15:50 +0000 Subject: [issue16182] readline: Wrong tab completion scope indices in Unicode terminals In-Reply-To: <1349813384.06.0.615857426211.issue16182@psf.upfronthosting.co.za> Message-ID: <1465737350.84.0.256931553165.issue16182@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. But the test fails with PYTHONIOENCODING=ascii. $ PYTHONIOENCODING=ascii ./python -m test test_readline Run tests sequentially 0:00:00 [1/1] test_readline test test_readline failed -- Traceback (most recent call last): File "/home/serhiy/py/cpython/Lib/test/test_readline.py", line 194, in test_nonascii self.assertIn(b"result " + expected + b"\r\n", output) AssertionError: b"result '[\\xefnserted]|t\\xebxt[after]'\r\n" not found in bytearray(b'^A^B^B^B^B^B^B^B\t\tx\t\r\n[\xc3\xafnserted]|t\xc3\xab[after]\x08\x08\x08\x08\x08\x08\x08text \'t\\xeb\'\r\nline \'[\\xefnserted]|t\\xeb[after]\'\r\nindexes 11 13\r\n\x07text \'t\\xeb\'\r\nline \'[\\xefnserted]|t\\xeb[after]\'\r\nindexes 11 13\r\nsubstitution \'t\\xeb\'\r\nmatches [\'t\\xebnt\', \'t\\xebxt\']\r\nx[after]\x08\x08\x08\x08\x08\x08\x08t[after]\x08\x08\x08\x08\x08\x08\x08\r\nTraceback (most recent call last):\r\n File "", line 39, in \r\nUnicodeDecodeError: \'ascii\' codec can\'t decode byte 0xc3 in position 1: ordinal not in range(128)\r\n') This is minor problem, since buildbots rarely configured with PYTHONIOENCODING=ascii. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 09:18:01 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Jun 2016 13:18:01 +0000 Subject: [issue27095] Simplify MAKE_FUNCTION In-Reply-To: <1464038780.83.0.81155899453.issue27095@psf.upfronthosting.co.za> Message-ID: <1465737481.19.0.139840867118.issue27095@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, this is why I wanted first push the patch with BUILD_CONST_KEY_MAP. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 09:22:51 2016 From: report at bugs.python.org (ppperry) Date: Sun, 12 Jun 2016 13:22:51 +0000 Subject: [issue20916] ssl.enum_certificates() will not return all certificates trusted by Windows In-Reply-To: <1394740101.16.0.76901026465.issue20916@psf.upfronthosting.co.za> Message-ID: <1465737771.84.0.576966421851.issue20916@psf.upfronthosting.co.za> Changes by ppperry : ---------- components: +Windows nosy: +paul.moore, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 09:28:06 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Jun 2016 13:28:06 +0000 Subject: [issue27289] test_ftp_timeout fails with EOFError In-Reply-To: <1465590845.17.0.18803116863.issue27289@psf.upfronthosting.co.za> Message-ID: <20160612132802.11395.66043.5A2BA743@psf.io> Roundup Robot added the comment: New changeset 2e3a5770e5f6 by Berker Peksag in branch '3.5': Issue #27289: Prevent test_urllib2net failures due to EOFError raised by ftplib https://hg.python.org/cpython/rev/2e3a5770e5f6 New changeset fc0e8c7235f1 by Berker Peksag in branch 'default': Issue #27289: Merge from 3.5 https://hg.python.org/cpython/rev/fc0e8c7235f1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 09:28:36 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 12 Jun 2016 13:28:36 +0000 Subject: [issue27289] test_ftp_timeout fails with EOFError In-Reply-To: <1465590845.17.0.18803116863.issue27289@psf.upfronthosting.co.za> Message-ID: <1465738116.91.0.287589920028.issue27289@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 09:28:50 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Jun 2016 13:28:50 +0000 Subject: [issue27095] Simplify MAKE_FUNCTION In-Reply-To: <1464038780.83.0.81155899453.issue27095@psf.upfronthosting.co.za> Message-ID: <1465738130.77.0.302764835635.issue27095@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Regenerated for review. ---------- Added file: http://bugs.python.org/file43363/mkfu5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 09:30:57 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 12 Jun 2016 13:30:57 +0000 Subject: [issue20916] ssl.enum_certificates() will not return all certificates trusted by Windows In-Reply-To: <1394740101.16.0.76901026465.issue20916@psf.upfronthosting.co.za> Message-ID: <1465738257.98.0.950905455064.issue20916@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: -christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 09:32:03 2016 From: report at bugs.python.org (Stefan Krah) Date: Sun, 12 Jun 2016 13:32:03 +0000 Subject: [issue26862] android: SYS_getdents64 does not need to be defined on android API 21 In-Reply-To: <1461678588.46.0.828463582716.issue26862@psf.upfronthosting.co.za> Message-ID: <1465738323.49.0.916045894053.issue26862@psf.upfronthosting.co.za> Stefan Krah added the comment: posixmodule_3.patch looks good to me. Gregory has already approved the approach, so I think you can go ahead and commit this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 09:35:31 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Jun 2016 13:35:31 +0000 Subject: [issue15657] Error in Python 3 docs for PyMethodDef In-Reply-To: <1344970966.7.0.115664419243.issue15657@psf.upfronthosting.co.za> Message-ID: <20160612133518.101651.12964.D4D22FF3@psf.io> Roundup Robot added the comment: New changeset 367b3f41710a by Berker Peksag in branch '3.5': Issue #15657: Delete incorrect statement from PyMethodDef documentation https://hg.python.org/cpython/rev/367b3f41710a New changeset 7fa4986d8218 by Berker Peksag in branch 'default': Issue #15657: Null merge from 3.5 https://hg.python.org/cpython/rev/7fa4986d8218 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 09:37:56 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Jun 2016 13:37:56 +0000 Subject: [issue15657] Error in Python 3 docs for PyMethodDef In-Reply-To: <1344970966.7.0.115664419243.issue15657@psf.upfronthosting.co.za> Message-ID: <20160612133743.120669.38395.2061CE0E@psf.io> Roundup Robot added the comment: New changeset f520ae3b537b by Berker Peksag in branch '2.7': Issue #15657: Delete incorrect statement from PyMethodDef documentation https://hg.python.org/cpython/rev/f520ae3b537b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 09:50:24 2016 From: report at bugs.python.org (A. Jesse Jiryu Davis) Date: Sun, 12 Jun 2016 13:50:24 +0000 Subject: [issue27136] sock_connect fails for bluetooth (and probably others) In-Reply-To: <1464346938.98.0.196127839357.issue27136@psf.upfronthosting.co.za> Message-ID: <1465739424.26.0.88870918022.issue27136@psf.upfronthosting.co.za> A. Jesse Jiryu Davis added the comment: Thanks Martin. That test verifies behavior that I observe in Mac OS 10.10 and other modern platforms: >>> socket.getaddrinfo('::2', 80, socket.AF_INET6, socket.SOCK_STREAM, socket.IPPROTO_TCP) [(30, 1, 6, '', ('::0.0.0.2', 80, 0, 0))] Investigating, I wrote a C program to call getaddrinfo on my Mac OS X Tiger x86 virtual machine, and indeed it resolves "::2" with family AF_INET6 in "hints" as an IPv4 address, "0.0.0.2". However, the same setup resolves "::1" as an IPv6 address, "::1". Someone who knows more about IPv6 than I might guess the cause? In any case, I wonder if replacing "::2" with "::1" at test_base_events.py:1188, and replacing the regex '::(0\.)*2' with '::(0\.)*1' at line 1195 would fix the test for Tiger. Could you try that please? I'm having trouble compiling Python for Tiger so I don't know how to test it on my virtual machine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 09:54:16 2016 From: report at bugs.python.org (Emin Ghuliev) Date: Sun, 12 Jun 2016 13:54:16 +0000 Subject: [issue27254] UAF in Tkinter module In-Reply-To: <1465324141.01.0.361051063774.issue27254@psf.upfronthosting.co.za> Message-ID: <1465739656.54.0.120564704457.issue27254@psf.upfronthosting.co.za> Changes by Emin Ghuliev : ---------- title: heap overflow in Tkinter module -> UAF in Tkinter module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 09:54:40 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 12 Jun 2016 13:54:40 +0000 Subject: [issue15657] Error in Python 3 docs for PyMethodDef In-Reply-To: <1344970966.7.0.115664419243.issue15657@psf.upfronthosting.co.za> Message-ID: <1465739680.12.0.776023219308.issue15657@psf.upfronthosting.co.za> Berker Peksag added the comment: > Then change the value of METH_KEYWORDS from 0x0002 to 0x0003 in 3.6. Here is a patch. ---------- Added file: http://bugs.python.org/file43364/issue15657_36.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 10:14:19 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 12 Jun 2016 14:14:19 +0000 Subject: [issue27136] sock_connect fails for bluetooth (and probably others) In-Reply-To: <1464346938.98.0.196127839357.issue27136@psf.upfronthosting.co.za> Message-ID: <1465740859.88.0.387650501504.issue27136@psf.upfronthosting.co.za> Martin Panter added the comment: Okay changing to ::1 might have a decent chance of success. If nobody else comes forward, I can try committing it and see if it fixes the buildbot. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 10:16:38 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 12 Jun 2016 14:16:38 +0000 Subject: [issue26721] Avoid socketserver.StreamRequestHandler.wfile doing partial writes In-Reply-To: <1460204395.72.0.250418211057.issue26721@psf.upfronthosting.co.za> Message-ID: <1465740998.45.0.381973516916.issue26721@psf.upfronthosting.co.za> Martin Panter added the comment: Merged with current code, and migrated the interrupted-write test from test_wsgiref into test_socketserver. ---------- Added file: http://bugs.python.org/file43365/buffered-wfile.v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 10:16:57 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Sun, 12 Jun 2016 14:16:57 +0000 Subject: [issue10839] email module should not allow some header field repetitions In-Reply-To: <1465680346.49.0.97445305032.issue10839@psf.upfronthosting.co.za> Message-ID: <20160612171649.29e637d3@python.org> Barry A. Warsaw added the comment: On Jun 11, 2016, at 09:25 PM, Raymond Hettinger wrote: >I think we should consider this as an API design bug and backport the fix. No, it's deliberate, required, and expected in some cases as RDM explains. Certainly for compat32 policy, this can't change. Other policies can prevent multiple additions of some headers. Probably those would go in defects if you parsed a message with prohibited duplicates. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 10:23:42 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 12 Jun 2016 14:23:42 +0000 Subject: [issue26721] Avoid socketserver.StreamRequestHandler.wfile doing partial writes In-Reply-To: <1460204395.72.0.250418211057.issue26721@psf.upfronthosting.co.za> Message-ID: <1465741422.64.0.478848521362.issue26721@psf.upfronthosting.co.za> Martin Panter added the comment: Forgot to remove the workaround added to 3.5 for wsgiref in Issue 24291 ---------- Added file: http://bugs.python.org/file43366/buffered-wfile.v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 10:30:29 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 12 Jun 2016 14:30:29 +0000 Subject: [issue27227] argparse fails to parse [] when using choices and nargs='*' In-Reply-To: <1465117156.8.0.428303445441.issue27227@psf.upfronthosting.co.za> Message-ID: <1465741829.78.0.471301485948.issue27227@psf.upfronthosting.co.za> Berker Peksag added the comment: Looking at this again, I think we should fix this in issue 9625. ---------- resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> argparse: Problem with defaults for variable nargs when using choices _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 10:30:54 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 12 Jun 2016 14:30:54 +0000 Subject: [issue9625] argparse: Problem with defaults for variable nargs when using choices In-Reply-To: <1282036744.37.0.964764969496.issue9625@psf.upfronthosting.co.za> Message-ID: <1465741854.96.0.354040227268.issue9625@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: needs patch -> patch review versions: +Python 3.5, Python 3.6 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 10:37:18 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Jun 2016 14:37:18 +0000 Subject: [issue27095] Simplify MAKE_FUNCTION In-Reply-To: <1464038780.83.0.81155899453.issue27095@psf.upfronthosting.co.za> Message-ID: <20160612143714.9983.82045.FE3CC6D9@psf.io> Roundup Robot added the comment: New changeset 8a0fe3481c91 by Serhiy Storchaka in branch 'default': Issue #27095: Simplified MAKE_FUNCTION and removed MAKE_CLOSURE opcodes. https://hg.python.org/cpython/rev/8a0fe3481c91 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 11:13:20 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Jun 2016 15:13:20 +0000 Subject: [issue27095] Simplify MAKE_FUNCTION In-Reply-To: <1464038780.83.0.81155899453.issue27095@psf.upfronthosting.co.za> Message-ID: <1465744400.84.0.793364669567.issue27095@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Pushed with minor changes. Thank you for your contribution Demur! You change to the documentation of EXTENDED_ARG isn't pushed. I would prefer to see it as a part of larger documentation patch in issue26647. After pushing I found a bug (similar bug was existing) in compile.c. I'll open separate issue for this. ---------- assignee: -> serhiy.storchaka dependencies: -ceval: use Wordcode, 16-bit bytecode resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 11:34:08 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Jun 2016 15:34:08 +0000 Subject: [issue27301] Incorrect return codes in compile.c Message-ID: <1465745648.38.0.217159225058.issue27301@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Macros ADDOP, ADDOP_I, ADDOP_O, etc are used in Python/compile.c for emitting instructions. They make functions where they are used returning 0 on error. But some functions return -1 on error and non-negative integer on success. 0 is legitimate value. In case of error in the ADDOP* macro, the error is not correctly detected in the outer function. Here is a patch that fixes this issue in 3.6. 3.5 and 2.7 need different patches. ---------- assignee: serhiy.storchaka components: Interpreter Core messages: 268390 nosy: Demur Rumed, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Incorrect return codes in compile.c type: behavior versions: Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 11:34:27 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Jun 2016 15:34:27 +0000 Subject: [issue27301] Incorrect return codes in compile.c In-Reply-To: <1465745648.38.0.217159225058.issue27301@psf.upfronthosting.co.za> Message-ID: <1465745667.92.0.228443899344.issue27301@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +patch Added file: http://bugs.python.org/file43367/compile_rc-3.6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 12:20:32 2016 From: report at bugs.python.org (Redoute) Date: Sun, 12 Jun 2016 16:20:32 +0000 Subject: [issue27302] csv.Sniffer guesses wrong when unquoted fields contain quotes Message-ID: <1465748432.82.0.331643864863.issue27302@psf.upfronthosting.co.za> New submission from Redoute: When delimited text fields are not quoted, but embedded text contains some quoted words, sniff() will guess the wrong delimiter. The attached script contains a simple tab-delimited text where sniff() detects space as delimiter. ---------- components: Library (Lib) files: humptydumpty.py messages: 268391 nosy: Redoute priority: normal severity: normal status: open title: csv.Sniffer guesses wrong when unquoted fields contain quotes type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file43368/humptydumpty.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 13:06:27 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 12 Jun 2016 17:06:27 +0000 Subject: [issue27025] More human readable generated widget names In-Reply-To: <1463299445.94.0.887025569149.issue27025@psf.upfronthosting.co.za> Message-ID: <1465751187.83.0.639713205146.issue27025@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I based my opinion on trying to actually read and understand the output of tknames.py, with your patch done both ways, in a way that I would do in use. Since class names always begin with upper case, it did not occur to me to read '1' as anything other than 'one'. '0' is just as easily confused with 'O'. In both cases, the resemblance depends on the font. For the Lucida Console I use for IDLE, there is no internal marker dot or bar and O0 only differ slightly in shape. In a mixed digits and caps string like '' I might have to type the two to be sure which is which. On the other hand 1l are much more different, as 1 has a rather long horizontal serif while l has none. Neither comments are true in the fixed font (Courier?) I see now in Firefox. The semantic clash problem, which is the bigger problem for me, may be stronger for me as a native speaker. I read '0Frame' and '1Frame' as 'zero Frame' and 'one Frame', not as arbitrary character sequences. Being able to switch to semantic reading is the point of this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 14:11:27 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Jun 2016 18:11:27 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <20160612181124.26389.48803.A01A7F03@psf.io> Roundup Robot added the comment: New changeset 6a35aa1995ab by Brett Cannon in branch 'default': Issue #27186: skip bytes path test for os.scandir() on Windows https://hg.python.org/cpython/rev/6a35aa1995ab ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 14:11:49 2016 From: report at bugs.python.org (Brett Cannon) Date: Sun, 12 Jun 2016 18:11:49 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1465755109.71.0.360625901058.issue27186@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks for the notice, Martin! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 14:20:07 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Jun 2016 18:20:07 +0000 Subject: [issue27025] More human readable generated widget names In-Reply-To: <1463299445.94.0.887025569149.issue27025@psf.upfronthosting.co.za> Message-ID: <1465755607.45.0.317481529549.issue27025@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Generated names are in lower case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 14:48:59 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Jun 2016 18:48:59 +0000 Subject: [issue27300] tempfile.TemporaryFile(): missing errors=... argument Message-ID: <1465757339.9.0.373504417484.issue27300@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 15:49:48 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Jun 2016 19:49:48 +0000 Subject: [issue27239] Make idlelib.macosx self-contained. In-Reply-To: <1465181854.1.0.00138868755932.issue27239@psf.upfronthosting.co.za> Message-ID: <20160612194934.81381.61307.51DAE280@psf.io> Roundup Robot added the comment: New changeset d8a2b6efdd4a by Terry Jan Reedy in branch 'default': Issue #27239: Continue refactoring idlelib.macosx and adding macosx tests. https://hg.python.org/cpython/rev/d8a2b6efdd4a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 15:50:23 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 12 Jun 2016 19:50:23 +0000 Subject: [issue27239] Make idlelib.macosx self-contained. In-Reply-To: <1465181854.1.0.00138868755932.issue27239@psf.upfronthosting.co.za> Message-ID: <1465761023.62.0.682073107266.issue27239@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Remove the now unneeded call in htest to _init_tk_type. It was tempting to leave the call for the 'efficiency' of the direct call with the available root, but there is a mental efficiency in removing it and making _init_tk_type completely an internal implementation detail of macosx. Remove the unneeded call in macosx.setupApp. This makes the _init_tk_type local to its section of the module. It also allows a test to set _tk_type to simulate being on a particular type of Mac and call setupApp without having the setting overwritten by the real value. Test_macosx now calls setupApp with each _tk_type set to each possible non-None value. The same objective could have been met by conditioning the call with 'if _tk_type is None:', but removing the call means that _init_tk_type is no longer ever called with a root, so the parameter can be removed and the function simplified. This section of macosx now takes care of initializing itself and the rest of IDLE can simply call the isTypeTk functions without worrying about initialization. Have macosx call its test when run as main. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 15:55:45 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 12 Jun 2016 19:55:45 +0000 Subject: [issue27262] IDLE: move Aqua context menu code to maxosx In-Reply-To: <1465352483.17.0.330062690814.issue27262@psf.upfronthosting.co.za> Message-ID: <1465761345.59.0.35078401181.issue27262@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Changeset d8a2b6efdd4a, #27239, adds a test of setupApp in test_macosx that fails on any system, in particular mine, when Ned's fix is undone. ---------- resolution: -> fixed stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 16:21:30 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Jun 2016 20:21:30 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <20160612202127.11395.23893.55556943@psf.io> Roundup Robot added the comment: New changeset 1ccd6196115a by Brett Cannon in branch 'default': Issue #27186: add Include/osmodule.h to the proper build rules https://hg.python.org/cpython/rev/1ccd6196115a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 16:21:38 2016 From: report at bugs.python.org (Memeplex) Date: Sun, 12 Jun 2016 20:21:38 +0000 Subject: [issue27303] [argparse] Unify options in help output Message-ID: <1465762898.72.0.658784279908.issue27303@psf.upfronthosting.co.za> New submission from Memeplex: Currently when you specify more than one name for an option (typically short and long versions) each name is listed with its entire arg list. This is annoying for options taking many args or choices, for example: --type {html,pdf,github,blogger}, -t {html,pdf,github,blogger} Wouldn't it be better to just show something like: --type|-t {html,pdf,github,blogger} ---------- components: Library (Lib) messages: 268400 nosy: bethard, memeplex priority: normal severity: normal status: open title: [argparse] Unify options in help output versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 16:22:46 2016 From: report at bugs.python.org (Memeplex) Date: Sun, 12 Jun 2016 20:22:46 +0000 Subject: [issue27303] [argparse] Unify options in help output In-Reply-To: <1465762898.72.0.658784279908.issue27303@psf.upfronthosting.co.za> Message-ID: <1465762966.05.0.71710541907.issue27303@psf.upfronthosting.co.za> Changes by Memeplex : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 16:26:45 2016 From: report at bugs.python.org (SilentGhost) Date: Sun, 12 Jun 2016 20:26:45 +0000 Subject: [issue27303] [argparse] Unify options in help output In-Reply-To: <1465762898.72.0.658784279908.issue27303@psf.upfronthosting.co.za> Message-ID: <1465763205.16.0.816196444882.issue27303@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 16:34:36 2016 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 12 Jun 2016 20:34:36 +0000 Subject: [issue12623] "universal newlines" subprocess support broken with select- and poll-based communicate() In-Reply-To: <1311451893.22.0.0169745025507.issue12623@psf.upfronthosting.co.za> Message-ID: <1465763676.48.0.0191648163018.issue12623@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 16:35:13 2016 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 12 Jun 2016 20:35:13 +0000 Subject: [issue18369] X509 cert class for ssl module In-Reply-To: <1373055037.38.0.259814019718.issue18369@psf.upfronthosting.co.za> Message-ID: <1465763713.21.0.925832300266.issue18369@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 16:58:28 2016 From: report at bugs.python.org (aixtools) Date: Sun, 12 Jun 2016 20:58:28 +0000 Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX) In-Reply-To: <1465724506.69.0.0996802529673.issue26439@psf.upfronthosting.co.za> Message-ID: <71f29429-9a37-5916-2bce-72a42488fd26@gmail.com> aixtools added the comment: On 6/12/2016 11:41 AM, Martin Panter wrote: > . > Michael, how are you supposed to apply your latest patch? I have Gnu Patch 2.7.5, but even in the best case it doesn?t find the files to patch: > > $ patch -p1 -n < python.Lib.ctypes.160608.patch > can't find file to patch at input line 2 > The text leading up to this was: > -------------------------- > |diff -r Python-2.7.11/Lib/ctypes/__init__.py python-2.7.11.5/Lib/ctypes/__init__.py > -------------------------- I must have forgotten the u (-r rather than -ru) (read mistyped, as I "always" use the -u option) > Perhaps can you make a ?unified? diff (-u option) like you did in your previous patches? Whatever you did with Python3.issue26439.160511.patch seemed to work best. Will redo all of them in about 24 hours. > Also, since your patches add new functionality (the automatic archive member detection), they will have to be for Python 3, not 2. Well, let me know what needs to be deleted - I see the member detection as the equivalent of reading the output of "ldconfig -p" to search for where an archive might be, or compareable with the gcc command (forgot the options) to say where it is looking. Not going into Python2 misses the whole point from my perspective. Unfortunate (for my perspective) is that noone else is saying anything one way or the other. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 17:11:21 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 12 Jun 2016 21:11:21 +0000 Subject: [issue20674] Update comments in dictobject.c In-Reply-To: <1392744795.57.0.649500024154.issue20674@psf.upfronthosting.co.za> Message-ID: <1465765881.89.0.110254684537.issue20674@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Christian, I assigned to you because I thought you had done the SIPhash work that invalidated these comments. Do you know who the right person is? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 17:19:07 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 12 Jun 2016 21:19:07 +0000 Subject: [issue10839] email module should not allow some header field repetitions In-Reply-To: <1294263603.86.0.308955870327.issue10839@psf.upfronthosting.co.za> Message-ID: <1465766347.86.0.583183306903.issue10839@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Would you consider raising an exception at least for the case of a "To:" header or perhaps a warning or someother failsafe. Using __setitem__ for appending instead of replacement is surprising and in the case of LetsEncrypt was a small disaster. There is a docstring explaining what is going on but that typically isn't visible to the user of the square brackets operator. For Python3.6, I think there should be an alternative API that doesn't use the square brackets operator: add_header, replace_header, remove_header or somesuch. The problem is that square brackets never suggests appending which is what is actually happening. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 18:33:22 2016 From: report at bugs.python.org (A. Jesse Jiryu Davis) Date: Sun, 12 Jun 2016 22:33:22 +0000 Subject: [issue27136] sock_connect fails for bluetooth (and probably others) In-Reply-To: <1464346938.98.0.196127839357.issue27136@psf.upfronthosting.co.za> Message-ID: <1465770802.29.0.496517941946.issue27136@psf.upfronthosting.co.za> A. Jesse Jiryu Davis added the comment: Thanks, I'm not a core dev or I'd try it myself. Yury, do you think that's a good approach, or should I mock getaddrinfo for that test? I fear mocking out too much and accidentally not testing anything, or of making tests that someone *else* could accidentally change so they don't test anything. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 19:17:58 2016 From: report at bugs.python.org (paul j3) Date: Sun, 12 Jun 2016 23:17:58 +0000 Subject: [issue27303] [argparse] Unify options in help output In-Reply-To: <1465762898.72.0.658784279908.issue27303@psf.upfronthosting.co.za> Message-ID: <1465773478.38.0.158194408127.issue27303@psf.upfronthosting.co.za> paul j3 added the comment: There are 2 issues here - - how to make the 'choices' list most compact - how to make the multiple option strings display (long and short) more compact, regardless of why the argument part is long. When the choices display is too long, 'metavar' is a handy alternative. You can still display the choices in the body of the help message, either as an explicit list or with the `%(choices)s` string. The long choices list will still appear in the error messages. There are other bug/issues about formatting the choices list. I have participated in discussions about replacing -f FOO, --foo FOO etc with -f/--foo FOO etc I'm sure that's been raised on Stackoverflow, but there might also be a bug/issue on the topic. I'd have to do some search to find those. I believe it can addressed with a HelpFormatter subclass that changes one method. ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 19:30:22 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 12 Jun 2016 23:30:22 +0000 Subject: [issue27025] More human readable generated widget names In-Reply-To: <1463299445.94.0.887025569149.issue27025@psf.upfronthosting.co.za> Message-ID: <1465774222.67.0.838029581009.issue27025@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I apologize for my mistake, but it is not of much relevance. My preference is based on my subjective reactions on reading both variations. I used tknames.py, which outputs < 20 names, rather than the code that output > 200 names, because the former seems more realistic and makes it easier to focus on reading one path. The intellectual justifications and explanations came after and are subsidiary. If you put yourself in the position of a naive user, do you really prefer reading 'zero toplevel zero frame zero button' or 'one toplevel one frame one button'? If you prefer the former, then we are simply different and will not agree. However, I would like to revisit the criteria for a generated name. Currently, widget names are nearly undocumented, and I don't know of any doc for the 'name=' option. Our tkinter doc only discusses pathnames in the tcl/tk section, which nearly everyone will skip. Even there, there is no mention that "button .fred -bg 'red'" translates to "Button(master, name='fred', bg='red')". The translation obliterates the distinction between 'name' being required and write-once versus 'bg' being optional and rewritable. In docstrings, 'name' is not listed in Valid resource names, because it is not one. In help(widget), the pathname only appears in the listing of __str__, nametowidget, and maybe a few other places. There is no mention of how tkinter generates the required unique name or that it even does so. The Lundh Tkinterbook makes no mentions of names that I could find. The Shipman NMU Reference says that name components *are* .n, where n is a stringified int and never mentions, that I could find, the 'name' option to make it otherwise. The use of 'name=' seems correspondingly rare. IDLE names 4 Scrollbars (out of about twice as many) 'vbar' or 'hbar'. It names just a few Menus. In my reading of stackoverflow tkinter questions, 'name=' is rare there also. To me, the near absence of name documentation and use gives us latitude in what alternative we pick. I understand the name clash problem. For a given master, a person might create a widget with no name and later create a widget of the same class with a name. The generated name for the first widget, *whatever it is*, might clash with the later name.* The only way to eliminate all clashes is to check all explicit names. Join the name to the master name and try to use it in the cheapest way possible, perhaps 'pathname.children'. If this raises tclerror 'name not recognized' (or whatever the message is), use the name. If this succeeds, the name would clash, so raise name clash error. *The virtue of injecting id(python_widget) after the widget is created is that a user could only calculate the same number before creation with detailed knowledge of id creation. On CPython, this is tricky, though on other systems, I believe it could just be as simple as id(last widget)+1. If there is no null value for a default argument, then the most likely explicit argument is a good choice. For name, that might be the class name or a lower-cased version thereof, possibly suffixed. The *only* reason to not use that is if clashes with rare but possible future explicit names are deemed too likely. Ugly, by itself, is bad. A number prefix is not required. For other prefixes that would reduce clash possibility, I tried: >>> for c in "01'|+-*&^%$#@!~` ": print(".%stoplevel.%sframe.%sbutton" % (c, c, c)) .0toplevel.0frame.0button .1toplevel.1frame.1button .'toplevel.'frame.'button .|toplevel.|frame.|button .+toplevel.+frame.+button .-toplevel.-frame.-button .*toplevel.*frame.*button .&toplevel.&frame.&button .^toplevel.^frame.^button .%toplevel.%frame.%button .$toplevel.$frame.$button .#toplevel.#frame.#button . at toplevel.@frame. at button .!toplevel.!frame.!button .~toplevel.~frame.~button .`toplevel.`frame.`button . toplevel. frame. button I like ` best (unobtrusive and meaningless), ^ second. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 19:53:48 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 12 Jun 2016 23:53:48 +0000 Subject: [issue27024] IDLE shutdown glitch when started by import In-Reply-To: <1463289946.09.0.360878393598.issue27024@psf.upfronthosting.co.za> Message-ID: <1465775628.9.0.66901851424.issue27024@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I applied to 2.7 after changing the file name. I still get F:\Python\dev\27>pcbuild\python_d.exe -m test.regrtest -ugui test_idle [1/1] test_idle can't invoke "event" command: application has been destroyed while executing "event generate $w <>" (procedure "ttk::ThemeChanged" line 6) invoked from within "ttk::ThemeChanged" can't invoke "event" command: application has been destroyed while executing "event generate $w <>" (procedure "ttk::ThemeChanged" line 6) invoked from within "ttk::ThemeChanged" This is the only instance left in all three versions after using root.update_idletasks where needed. It does not occur when running the particular test file by itself. Mark Roseman say something similar running test.test_idle with 3.6 on Mac. I do not running same on Windows. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 20:02:35 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 13 Jun 2016 00:02:35 +0000 Subject: [issue24363] httplib fails to handle semivalid HTTP headers In-Reply-To: <1433257563.79.0.772954216205.issue24363@psf.upfronthosting.co.za> Message-ID: <1465776155.5.0.471054620864.issue24363@psf.upfronthosting.co.za> Martin Panter added the comment: See also Issue 26686; the same problem, but with parsing RFC5322 header fields, rather than HTTP. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 20:09:40 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 13 Jun 2016 00:09:40 +0000 Subject: [issue10839] email module should not allow some header field repetitions In-Reply-To: <1294263603.86.0.308955870327.issue10839@psf.upfronthosting.co.za> Message-ID: <1465776580.57.0.456405221178.issue10839@psf.upfronthosting.co.za> Martin Panter added the comment: There are already the makings of an alternative API: https://docs.python.org/3.6/library/email.message.html#email.message.Message.add_header There is also replace_header(), but it only replaces the _first_ header field, and leaves later ones untouched. However there is only __del__(), which deletes all matching header fields; there is no remove_header() or similar. I think I would support deprecating the __setitem__() etc methods, perhaps with a cleanup of the alternatives, e.g. add remove_all(). Also, __getitem__() is equivalent to get(), which does not raise KeyError. Although according to Issue 12111, David said things are unlikely to change. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 20:12:12 2016 From: report at bugs.python.org (Mark Roseman) Date: Mon, 13 Jun 2016 00:12:12 +0000 Subject: [issue27024] IDLE shutdown glitch when started by import In-Reply-To: <1463289946.09.0.360878393598.issue27024@psf.upfronthosting.co.za> Message-ID: <1465776732.69.0.0451426535697.issue27024@psf.upfronthosting.co.za> Mark Roseman added the comment: tried this patch on 3.6 as per terry's previous msg; still getting same error in idle test suite on os x ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 21:45:00 2016 From: report at bugs.python.org (paul j3) Date: Mon, 13 Jun 2016 01:45:00 +0000 Subject: [issue27303] [argparse] Unify options in help output In-Reply-To: <1465762898.72.0.658784279908.issue27303@psf.upfronthosting.co.za> Message-ID: <1465782300.78.0.622098947068.issue27303@psf.upfronthosting.co.za> paul j3 added the comment: http://stackoverflow.com/questions/18275023/dont-show-long-options-twice-in-print-help-from-argparse Once answer demonstrates how to change the Formatter: class CustomHelpFormatter(argparse.HelpFormatter): def _format_action_invocation(self, action): if not action.option_strings or action.nargs == 0: return super()._format_action_invocation(action) default = self._get_default_metavar_for_optional(action) args_string = self._format_args(action, default) return ', '.join(action.option_strings) + ' ' + args_string Another answer suggests using metavar=''. Another SO question with a few more links: http://stackoverflow.com/questions/23936145/python-argparse-help-message-disable-metavar-for-short-options ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 22:14:53 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 13 Jun 2016 02:14:53 +0000 Subject: [issue25476] close() behavior on non-blocking BufferedIO objects with sockets In-Reply-To: <1445809592.17.0.674825265911.issue25476@psf.upfronthosting.co.za> Message-ID: <1465784093.94.0.541234090005.issue25476@psf.upfronthosting.co.za> Martin Panter added the comment: I propose to reject this. Close() should always close the underlying file descriptor or socket, even if there is a blocking error or other exception. ---------- resolution: -> rejected status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 22:21:37 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 13 Jun 2016 02:21:37 +0000 Subject: [issue26292] Raw I/O writelines() broken for non-blocking I/O In-Reply-To: <1454661860.28.0.473572264835.issue26292@psf.upfronthosting.co.za> Message-ID: <1465784497.95.0.824519340779.issue26292@psf.upfronthosting.co.za> Martin Panter added the comment: Victor, why did you change the title to specify non-blocking mode? I think blocking mode can also be handled at the same time. I propose: 1. In existing versions (2.7, 3.5): Document that it is undefined what IOBase.writelines() will do if a write() call does a partial write, returns None, or encounters a blocking error. Explicitly document that BufferedIOBase.writelines() and TextIOBase.writelines() will completely write all the data passed, or raise an exception. Document that BlockingIOError.characters_written is undefined even for BufferedIOBase.writelines(). 2. Commit my Issue 26721 change to socketserver, so that StreamRequestHandler.wfile implements BufferedIOBase instead of RawIOBase. 3. In a new version (3.6): Deprecate IOBase.writelines() and thus RawIOBase.writelines(), in favour of either using BufferedIOBase, or manually calling write(). Emit a DeprecationWarning, but add BufferedIOBase and TextIOBase implementations that do not emit the warning. BufferedIOBase.writelines() could be fixed to report the correct BlockingIOError.characters_written value, but that could be handled as a separate bug if anyone cares. ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 23:06:44 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 13 Jun 2016 03:06:44 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1465787204.92.0.956335257539.issue27186@psf.upfronthosting.co.za> Martin Panter added the comment: Should the skip logic perhaps check for sys.platform == "win32" instead? The buildbots are still failing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 23:38:24 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 13 Jun 2016 03:38:24 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <20160613033814.99059.81978.FF3A0728@psf.io> Roundup Robot added the comment: New changeset f384c5c14488 by Martin Panter in branch 'default': Issue #27186: Skip scandir(bytes) test with os.name == "nt" https://hg.python.org/cpython/rev/f384c5c14488 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 12 23:56:17 2016 From: report at bugs.python.org (Memeplex) Date: Mon, 13 Jun 2016 03:56:17 +0000 Subject: [issue27303] [argparse] Unify options in help output In-Reply-To: <1465762898.72.0.658784279908.issue27303@psf.upfronthosting.co.za> Message-ID: <1465790177.56.0.592246669748.issue27303@psf.upfronthosting.co.za> Memeplex added the comment: Thank you for the tips, Paul. The issue is related to the default behavior but it's always good to know about handy workarounds and extensibility hooks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 00:14:43 2016 From: report at bugs.python.org (Yoni Lavi) Date: Mon, 13 Jun 2016 04:14:43 +0000 Subject: [issue27304] Create "Source Code" links in module sections, where relevant Message-ID: <1465791283.3.0.647535904935.issue27304@psf.upfronthosting.co.za> New submission from Yoni Lavi: This is a follow to #22558. As per Terry's suggestion in #22558, for packages with multiple modules that are all documented on the same page and that currently have a "Source Code" link to an __init__ file (e.g. importlib), we should also add more specific "Source Code" links to the module sections. Attached is a patch for the documentation of the 3 such packages that I found: importlib, dbm and json ---------- assignee: docs at python components: Documentation files: mywork.patch keywords: patch messages: 268417 nosy: Yoni Lavi, docs at python, terry.reedy priority: normal severity: normal status: open title: Create "Source Code" links in module sections, where relevant versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43369/mywork.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 00:16:21 2016 From: report at bugs.python.org (Yoni Lavi) Date: Mon, 13 Jun 2016 04:16:21 +0000 Subject: [issue22558] Missing doc links to source code for Python-coded modules. In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za> Message-ID: <1465791381.34.0.725849230012.issue22558@psf.upfronthosting.co.za> Yoni Lavi added the comment: Created issue 27304 and uploaded a patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 00:43:06 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 13 Jun 2016 04:43:06 +0000 Subject: [issue27163] IDLE entry for What's New in Python 3.6 In-Reply-To: <1464677885.83.0.244887022976.issue27163@psf.upfronthosting.co.za> Message-ID: <20160613044302.26318.15333.E4EC91F2@psf.io> Roundup Robot added the comment: New changeset a3cffed2c9ad by Terry Jan Reedy in branch 'default': Issue #27163: Add idlelib/IDLE entry to What's New in 3.6. https://hg.python.org/cpython/rev/a3cffed2c9ad ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 01:24:02 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 13 Jun 2016 05:24:02 +0000 Subject: [issue10839] email module should not allow some header field repetitions In-Reply-To: <1465776580.57.0.456405221178.issue10839@psf.upfronthosting.co.za> Message-ID: <20160613082355.797f1d5f@python.org> Barry A. Warsaw added the comment: On Jun 13, 2016, at 12:09 AM, Martin Panter wrote: >I think I would support deprecating the __setitem__() etc methods, perhaps >with a cleanup of the alternatives, e.g. add remove_all(). Also, >__getitem__() is equivalent to get(), which does not raise KeyError. Although >according to Issue 12111, David said things are unlikely to change. I do not support deprecating __setitem__(). I'm okay with developing an alternative API, but setitem syntax is just too pervasive and convenient. It's been there since the very earliest days of mimelib (the precursor to the email package). If you read and understand the docs, you know exactly what the semantics are and you know how to use it effectively and safely. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 01:28:03 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 13 Jun 2016 05:28:03 +0000 Subject: [issue10839] email module should not allow some header field repetitions In-Reply-To: <1465766347.86.0.583183306903.issue10839@psf.upfronthosting.co.za> Message-ID: <20160613082756.7655a1e4@python.org> Barry A. Warsaw added the comment: On Jun 12, 2016, at 09:19 PM, Raymond Hettinger wrote: >Would you consider raising an exception at least for the case of a "To:" >header or perhaps a warning or someother failsafe. No, not for compat32 policy. Seriously, I do not want to change the semantics or syntax for existing code. This API predates even the renaming and stdlibbing of the email package from the older mimelib. By all means, let's develop API alternatives for new code, or stricter RFC compliance with defect registration for newer policies. But please leave things alone for compat32 and existing code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 02:21:09 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 13 Jun 2016 06:21:09 +0000 Subject: [issue27025] More human readable generated widget names In-Reply-To: <1463299445.94.0.887025569149.issue27025@psf.upfronthosting.co.za> Message-ID: <1465798869.11.0.483325844891.issue27025@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: ` and ^ LGTM. We can change this in any time if it looks bad. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 02:24:49 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 13 Jun 2016 06:24:49 +0000 Subject: [issue27025] More human readable generated widget names In-Reply-To: <1463299445.94.0.887025569149.issue27025@psf.upfronthosting.co.za> Message-ID: <20160613062436.99396.47543.C6C4C867@psf.io> Roundup Robot added the comment: New changeset 304c61263ae6 by Serhiy Storchaka in branch 'default': Issue #27025: Generated names for Tkinter widgets are now more meanful https://hg.python.org/cpython/rev/304c61263ae6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 02:38:20 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 13 Jun 2016 06:38:20 +0000 Subject: [issue10839] email module should not allow some header field repetitions In-Reply-To: <1294263603.86.0.308955870327.issue10839@psf.upfronthosting.co.za> Message-ID: <1465799900.66.0.664738340138.issue10839@psf.upfronthosting.co.za> Berker Peksag added the comment: I don't think a new API is needed. But we need to promote the policy keyword better in docs. See https://twitter.com/aksiksi/status/741769504817045508 for an example of confusion. I don't know if it's a good idea or API but can we add a 'policy' keyword argument to email.mime.base.MIMEBase? Right now, this is the only way to change the default policy without using high level functions like email.message_from_string(): m = MIMEMultipart() m.policy = email.policy.default ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 02:40:13 2016 From: report at bugs.python.org (Matthias Klose) Date: Mon, 13 Jun 2016 06:40:13 +0000 Subject: [issue26867] test_ssl test_options fails on ubuntu 16.04 In-Reply-To: <1461728238.71.0.110276038105.issue26867@psf.upfronthosting.co.za> Message-ID: <1465800013.82.0.840750857721.issue26867@psf.upfronthosting.co.za> Matthias Klose added the comment: Description: properly handle Ubuntu's openssl having OP_NO_SSLv3 forced on by default Author: Marc Deslauriers Forwarded: yes, http://bugs.python.org/issue25724 Index: b/Lib/test/test_ssl.py =================================================================== --- a/Lib/test/test_ssl.py +++ b/Lib/test/test_ssl.py @@ -821,7 +821,8 @@ class ContextTests(unittest.TestCase): self.assertEqual(ssl.OP_ALL | ssl.OP_NO_TLSv1 | ssl.OP_NO_SSLv3, ctx.options) ctx.options = 0 - self.assertEqual(0, ctx.options) + # Ubuntu has OP_NO_SSLv3 forced on by default + self.assertEqual(0, ctx.options & ~ssl.OP_NO_SSLv3) else: with self.assertRaises(ValueError): ctx.options = 0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 02:47:04 2016 From: report at bugs.python.org (Larry Hastings) Date: Mon, 13 Jun 2016 06:47:04 +0000 Subject: [issue26867] test_ssl test_options fails on ubuntu 16.04 In-Reply-To: <1461728238.71.0.110276038105.issue26867@psf.upfronthosting.co.za> Message-ID: <1465800424.92.0.150481000702.issue26867@psf.upfronthosting.co.za> Larry Hastings added the comment: That does seem like it'd make the test failure go away. But the fix seems a little Ubuntu-specific. Is it reasonable to do that when testing on every platform? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 03:31:33 2016 From: report at bugs.python.org (Cristi Fati) Date: Mon, 13 Jun 2016 07:31:33 +0000 Subject: [issue25413] ctypes (libffi) fails to compile on Solaris X86 In-Reply-To: <1465580563.26.0.585899938829.issue25413@psf.upfronthosting.co.za> Message-ID: Cristi Fati added the comment: Hi, sorry for spamming everyone, I couldn't find a way to reply to the last message directly on #25413 (https://bugs.python.org/issue25413). Looked over the current version (from MASTER) of the file: https://github.com/libffi/libffi/blob/master/src/x86/ffi.c, and it significantly differs from the one distributed in Python 2.7.10 (and 2.7.11). For example, all the conditional macros (out of which most are Windows related) are gone. So, the patch is not (even close) compatible with the current libffi version. On Fri, Jun 10, 2016 at 8:42 PM, Matthias Klose wrote: > > Matthias Klose added the comment: > > CristiFati, please could you check if the libffi patch is still needed with the current upstream libffi? > > See https://github.com/libffi/libffi > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 03:47:03 2016 From: report at bugs.python.org (Steven Barker) Date: Mon, 13 Jun 2016 07:47:03 +0000 Subject: [issue26631] Unable to install Python 3.5.1 on Windows 10 - Error 0x80070643: Failed to install MSI package. In-Reply-To: <1458771798.71.0.333968276616.issue26631@psf.upfronthosting.co.za> Message-ID: <1465804023.07.0.350682493345.issue26631@psf.upfronthosting.co.za> Steven Barker added the comment: I've just encountered this error when trying to update to the 3.5.2rc1 release (64-bit Python, Windows 10). I'd already had the 3.5.1 release installed, so I suppose it could have been an issue with the older installer trying to uninstall the old version. I believe the issue may be related to installing the `py.exe` launcher program. I have an alpha release of Python 3.6.0 installed, and so the 3.5.2rc1 installer gave me a popup saying that the launcher would not be updated since I already had a newer version. I assumed that was unrelated to the issue though because the installation process kept going for a couple minutes after seeing that message. However, trying the install again with custom settings and unselecting the launcher program made it work. I'll attach log the main log file for both the failed and successful runs of the installer, and the launcher_AllUsers file from the failed run. Oh, I just realized the successful run was with the web installer while the failed runs were the full download version. I have no idea if that would have made a difference or not. ---------- nosy: +Steven.Barker Added file: http://bugs.python.org/file43370/Python 3.5.2rc1 (64-bit)_20160613002148.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 03:48:07 2016 From: report at bugs.python.org (Steven Barker) Date: Mon, 13 Jun 2016 07:48:07 +0000 Subject: [issue26631] Unable to install Python 3.5.1 on Windows 10 - Error 0x80070643: Failed to install MSI package. In-Reply-To: <1458771798.71.0.333968276616.issue26631@psf.upfronthosting.co.za> Message-ID: <1465804087.69.0.866704557657.issue26631@psf.upfronthosting.co.za> Changes by Steven Barker : Added file: http://bugs.python.org/file43371/Python 3.5.2rc1 (64-bit)_20160613002950.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 03:48:52 2016 From: report at bugs.python.org (Steven Barker) Date: Mon, 13 Jun 2016 07:48:52 +0000 Subject: [issue26631] Unable to install Python 3.5.1 on Windows 10 - Error 0x80070643: Failed to install MSI package. In-Reply-To: <1458771798.71.0.333968276616.issue26631@psf.upfronthosting.co.za> Message-ID: <1465804132.17.0.687225870372.issue26631@psf.upfronthosting.co.za> Changes by Steven Barker : Added file: http://bugs.python.org/file43372/Python 3.5.2rc1 (64-bit)_20160613002148_008_launcher_AllUsers.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 03:52:23 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 13 Jun 2016 07:52:23 +0000 Subject: [issue27294] Better repr for Tkinter event objects In-Reply-To: <1465648557.25.0.737232700025.issue27294@psf.upfronthosting.co.za> Message-ID: <1465804343.37.0.315928190459.issue27294@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Terry, this information is helpful. Mod1 is Alt on X11, but not on Windows. It looks to me that on Windows Mod1 is NumLock, Mod3 is ScrollLock, 0x20000 is Alt, 0x40000 is pad keyboard. It is not clear about Win. What events are emitted if your press say Win-X? On Linux (X11) Mod1 is Alt, Mod2 is NumLock, Mod4 is Win, 0x2000, 0x4000 and 0x6000 are alternative keyboard layouts. But many of this I presume is configurable. Mac OS can have its own peculiarities. I think on this stage it is better to left standard X11 modifiers (Shift, Lock, Control, Mod1-Mod5, Button1-Button5) and output the rest modifiers in hexadecimal. End user should interpret these names and numerics in platform depending way. ---------- Added file: http://bugs.python.org/file43373/tkinter_event_repr_key_state2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 04:19:07 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 13 Jun 2016 08:19:07 +0000 Subject: [issue10839] email module should not allow some header field repetitions In-Reply-To: <1465799900.66.0.664738340138.issue10839@psf.upfronthosting.co.za> Message-ID: <20160613111823.591aba77@python.org> Barry A. Warsaw added the comment: On Jun 13, 2016, at 06:38 AM, Berker Peksag wrote: >I don't know if it's a good idea or API but can we add a 'policy' keyword >argument to email.mime.base.MIMEBase? Right now, this is the only way to >change the default policy without using high level functions like >email.message_from_string(): > > m = MIMEMultipart() > m.policy = email.policy.default I think we just need to plumb a `policy` argument through to the ultimate base class, email.message.Message ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 04:34:21 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 13 Jun 2016 08:34:21 +0000 Subject: [issue10839] email module should not allow some header field repetitions In-Reply-To: <1294263603.86.0.308955870327.issue10839@psf.upfronthosting.co.za> Message-ID: <1465806861.56.0.666508562874.issue10839@psf.upfronthosting.co.za> Berker Peksag added the comment: > I think we just need to plumb a `policy` argument through to the ultimate base > class, email.message.Message That's already possible: https://docs.python.org/dev/library/email.message.html#email.message.Message It would be nice to be able to customize 'policy' via BaseMime: https://github.com/python/cpython/blob/master/Lib/email/mime/base.py#L23 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 04:45:29 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 13 Jun 2016 08:45:29 +0000 Subject: [issue10839] email module should not allow some header field repetitions In-Reply-To: <1465806861.56.0.666508562874.issue10839@psf.upfronthosting.co.za> Message-ID: <20160613114514.59d08c27@python.org> Barry A. Warsaw added the comment: On Jun 13, 2016, at 08:34 AM, Berker Peksag wrote: >Berker Peksag added the comment: > >> I think we just need to plumb a `policy` argument through to the ultimate >> base class, email.message.Message > >That's already possible: https://docs.python.org/dev/library/email.message.html#email.message.Message > >It would be nice to be able to customize 'policy' via BaseMime: >https://github.com/python/cpython/blob/master/Lib/email/mime/base.py#L23 Right, that's what I meant by "plumb". :) Basically we want all the subclasses of email.message.Message to accept a `policy` argument and pass them to their superclass constructors. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 06:23:17 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 13 Jun 2016 10:23:17 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1465813397.52.0.912758908356.issue27186@psf.upfronthosting.co.za> Martin Panter added the comment: I went with os.name == "nt", which is what other scandir() tests use. I?m not sure there is a practical different. Anyway the buildbots seem happier now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 08:14:34 2016 From: report at bugs.python.org (James Paget) Date: Mon, 13 Jun 2016 12:14:34 +0000 Subject: [issue27305] Crash with "pip list --outdated" on Windows 10 with Python 2.7.12rc1 Message-ID: <1465820074.65.0.989290191732.issue27305@psf.upfronthosting.co.za> New submission from James Paget: On Windows 10 Professional 64-bit, typing "pip list --outdated" or "python -m pip install -U pip" at the Windows command prompt causes Python 2.7.12rc1 to crash. I get the standard "python.exe has stopped working" crash notification from Windows. I am running pip 8.1.2. ---------- components: Windows messages: 268434 nosy: James.Paget, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Crash with "pip list --outdated" on Windows 10 with Python 2.7.12rc1 type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 08:16:58 2016 From: report at bugs.python.org (Phil Jeffes) Date: Mon, 13 Jun 2016 12:16:58 +0000 Subject: [issue27306] Grammatical Error in Documentation - Tarfile page Message-ID: <1465820218.96.0.154135651878.issue27306@psf.upfronthosting.co.za> New submission from Phil Jeffes: On the tarfile page (https://docs.python.org/3.5/library/tarfile.html) there is a line which reads: mode is either 'r' to read from an existing archive, 'a' to append data to an existing file, 'w' to create a new file overwriting an existing one or 'x' to create a new file only if it?s not exists. and it should read: mode is either 'r' to read from an existing archive, 'a' to append data to an existing file, 'w' to create a new file overwriting an existing one or 'x' to create a new file only if *it does not already exist*. (Suggested changes surrounded by * *) ---------- assignee: docs at python components: Documentation messages: 268435 nosy: Phil Jeffes, docs at python priority: normal severity: normal status: open title: Grammatical Error in Documentation - Tarfile page type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 08:20:14 2016 From: report at bugs.python.org (SilentGhost) Date: Mon, 13 Jun 2016 12:20:14 +0000 Subject: [issue27306] Grammatical Error in Documentation - Tarfile page In-Reply-To: <1465820218.96.0.154135651878.issue27306@psf.upfronthosting.co.za> Message-ID: <1465820414.77.0.891239551843.issue27306@psf.upfronthosting.co.za> SilentGhost added the comment: There are more occurrences of "it is already exists" in the first table. ---------- nosy: +SilentGhost stage: -> needs patch versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 08:37:02 2016 From: report at bugs.python.org (SilentGhost) Date: Mon, 13 Jun 2016 12:37:02 +0000 Subject: [issue27305] Crash with "pip list --outdated" on Windows 10 with Python 2.7.12rc1 In-Reply-To: <1465820074.65.0.989290191732.issue27305@psf.upfronthosting.co.za> Message-ID: <1465821422.4.0.641093261483.issue27305@psf.upfronthosting.co.za> SilentGhost added the comment: pip is not part of standard library, its issue tracker is at https://github.com/pypa/pip/issues ---------- nosy: +SilentGhost resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 08:58:57 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 13 Jun 2016 12:58:57 +0000 Subject: [issue26686] email.parser stops parsing headers too soon. In-Reply-To: <1459532790.12.0.415003614976.issue26686@psf.upfronthosting.co.za> Message-ID: <1465822737.98.0.674119687358.issue26686@psf.upfronthosting.co.za> Martin Panter added the comment: FWIW in the HTTP bug , David said ?when seeing a line that doesn't look like a header the error recovery is to treat that line as the beginning of the body (ie: assume the blank line is missing).? I have no experience with email and RFC 5322 header handling, but it does make more sense to me to handle this as a defect in the header section, _not_ a genuine transition to the body (same as desired for the HTTP case). Here is a patch that revives MalformedHeaderDefect (see Issue 14925), and continues parsing the rest of the header section instead of starting the body. But I am not sure how safe this change is. I did have to fix one unrelated set of tests (see headertest_msg in the Test8BitBytesHandling class) that did not include a blank line and was relying on the old behaviour. ---------- keywords: +patch versions: +Python 3.6 Added file: http://bugs.python.org/file43374/continue-header.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 09:19:14 2016 From: report at bugs.python.org (James Paget) Date: Mon, 13 Jun 2016 13:19:14 +0000 Subject: [issue27305] Crash with "pip list --outdated" on Windows 10 with Python 2.7.12rc1 In-Reply-To: <1465820074.65.0.989290191732.issue27305@psf.upfronthosting.co.za> Message-ID: <1465823954.84.0.561882975196.issue27305@psf.upfronthosting.co.za> James Paget added the comment: I have submitted this to pip as you have suggested (see pip Issue #3795), but feel that Python.exe should not crash even if there is a problem with a third-party package. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 10:22:51 2016 From: report at bugs.python.org (Jonathan Kross) Date: Mon, 13 Jun 2016 14:22:51 +0000 Subject: [issue27131] Unit test random shuffle In-Reply-To: <1464277146.71.0.570096870767.issue27131@psf.upfronthosting.co.za> Message-ID: <1465827771.22.0.436614787723.issue27131@psf.upfronthosting.co.za> Jonathan Kross added the comment: Just checking in on this patch. Any chance of getting it applied within the next few days? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 10:38:37 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 13 Jun 2016 14:38:37 +0000 Subject: [issue27131] Unit test random shuffle In-Reply-To: <1464277146.71.0.570096870767.issue27131@psf.upfronthosting.co.za> Message-ID: <1465828717.86.0.805566639804.issue27131@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Yes ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 10:47:44 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 13 Jun 2016 14:47:44 +0000 Subject: [issue27272] random.Random should not read 2500 bytes from urandom In-Reply-To: <1465423096.81.0.204885224668.issue27272@psf.upfronthosting.co.za> Message-ID: <1465829264.98.0.686261671671.issue27272@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 11:00:27 2016 From: report at bugs.python.org (Gareth Rees) Date: Mon, 13 Jun 2016 15:00:27 +0000 Subject: [issue27306] Grammatical Error in Documentation - Tarfile page In-Reply-To: <1465820218.96.0.154135651878.issue27306@psf.upfronthosting.co.za> Message-ID: <1465830027.6.0.77279947091.issue27306@psf.upfronthosting.co.za> Gareth Rees added the comment: Here's a patch improving the grammar in the tarfile documentation. ---------- keywords: +patch nosy: +Gareth.Rees Added file: http://bugs.python.org/file43375/issue27306.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 11:03:13 2016 From: report at bugs.python.org (James Paget) Date: Mon, 13 Jun 2016 15:03:13 +0000 Subject: [issue27305] Crash with "pip list --outdated" on Windows 10 with Python 2.7.12rc1 In-Reply-To: <1465820074.65.0.989290191732.issue27305@psf.upfronthosting.co.za> Message-ID: <1465830193.69.0.852930059646.issue27305@psf.upfronthosting.co.za> James Paget added the comment: Python Packaging Authority member pfmoore from pypa/pip says "there's no ctypes-based code that could be causing the error" and "Python appears to be crashing as a result of pure Python code" and "there's no way that I can see how pip could be triggering a crash here. As this doesn't happen with 2.7.11, I'm inclined to consider it as a 2.7.12rc1 bug, I'm afraid." Please reopen this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 11:12:27 2016 From: report at bugs.python.org (Tim Golden) Date: Mon, 13 Jun 2016 15:12:27 +0000 Subject: [issue27305] Crash with "pip list --outdated" on Windows 10 with Python 2.7.12rc1 In-Reply-To: <1465820074.65.0.989290191732.issue27305@psf.upfronthosting.co.za> Message-ID: <1465830747.71.0.396339064283.issue27305@psf.upfronthosting.co.za> Tim Golden added the comment: Re-opening at user's request on Paul Moore's advice. He's already nosy so can comment here if needed. It would be good to get independent verification. I'll try to install the rc for 2.7.12 to see if I can reproduce. ---------- resolution: third party -> stage: resolved -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 11:15:45 2016 From: report at bugs.python.org (SilentGhost) Date: Mon, 13 Jun 2016 15:15:45 +0000 Subject: [issue27306] Grammatical Error in Documentation - Tarfile page In-Reply-To: <1465820218.96.0.154135651878.issue27306@psf.upfronthosting.co.za> Message-ID: <1465830945.75.0.417458963833.issue27306@psf.upfronthosting.co.za> SilentGhost added the comment: LGTM. ---------- stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 11:16:36 2016 From: report at bugs.python.org (Paul Moore) Date: Mon, 13 Jun 2016 15:16:36 +0000 Subject: [issue27305] Crash with "pip list --outdated" on Windows 10 with Python 2.7.12rc1 In-Reply-To: <1465820074.65.0.989290191732.issue27305@psf.upfronthosting.co.za> Message-ID: <1465830996.62.0.763357834147.issue27305@psf.upfronthosting.co.za> Paul Moore added the comment: Thanks Tim. To clarify, the only 2 places that pip calls ctypes is to get the user application directory (and we've confirmed that doesn't error when called direct from Python), and in the vendored colorama package (which we removed and still got the crash, so it's not that). So as far as we can tell, the crash is occurring from pure Python code, which as the OP pointed out, should not occur. The issue has also been confirmed as not happening with 2.7.11. If anyone can suggest a way for the OP to get better information out of Python as to where the problem is occurring, I'm happy to debug further with him in the pip code in order to reproduce the issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 11:22:35 2016 From: report at bugs.python.org (Paul Moore) Date: Mon, 13 Jun 2016 15:22:35 +0000 Subject: [issue27305] Crash with "pip list --outdated" on Windows 10 with Python 2.7.12rc1 In-Reply-To: <1465820074.65.0.989290191732.issue27305@psf.upfronthosting.co.za> Message-ID: <1465831355.83.0.746285382865.issue27305@psf.upfronthosting.co.za> Paul Moore added the comment: Confirmed I can reproduce the issue on Windows 7, with Python 2.7.12rc1. I don't have C debugging capabilities on this PC, so that's as far as I can go for now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 11:22:42 2016 From: report at bugs.python.org (Tim Golden) Date: Mon, 13 Jun 2016 15:22:42 +0000 Subject: [issue27305] Crash with "pip list --outdated" on Windows 10 with Python 2.7.12rc1 In-Reply-To: <1465830193.69.0.852930059646.issue27305@psf.upfronthosting.co.za> Message-ID: <575ECFBC.8000906@timgolden.me.uk> Tim Golden added the comment: James, which installer did you use (just so I can try to reproduce as closely as possible)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 11:24:01 2016 From: report at bugs.python.org (Paul Moore) Date: Mon, 13 Jun 2016 15:24:01 +0000 Subject: [issue27305] Crash with "pip list --outdated" on Windows 10 with Python 2.7.12rc1 In-Reply-To: <1465820074.65.0.989290191732.issue27305@psf.upfronthosting.co.za> Message-ID: <1465831441.65.0.663533072067.issue27305@psf.upfronthosting.co.za> Paul Moore added the comment: Tim, I just got the issue with the x64 installer from python.org (https://www.python.org/ftp/python/2.7.12/python-2.7.12rc1.amd64.msi) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 11:25:56 2016 From: report at bugs.python.org (Tim Golden) Date: Mon, 13 Jun 2016 15:25:56 +0000 Subject: [issue27305] Crash with "pip list --outdated" on Windows 10 with Python 2.7.12rc1 In-Reply-To: <1465820074.65.0.989290191732.issue27305@psf.upfronthosting.co.za> Message-ID: <1465831556.09.0.245308163623.issue27305@psf.upfronthosting.co.za> Tim Golden added the comment: Thanks, Paul. Adding Benjamin as 2.7 release manager. This looks like a release blocker to me. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 11:31:57 2016 From: report at bugs.python.org (Paul Moore) Date: Mon, 13 Jun 2016 15:31:57 +0000 Subject: [issue27305] Crash with "pip list --outdated" on Windows 10 with Python 2.7.12rc1 In-Reply-To: <1465820074.65.0.989290191732.issue27305@psf.upfronthosting.co.za> Message-ID: <1465831917.42.0.762042415706.issue27305@psf.upfronthosting.co.za> Paul Moore added the comment: The problem appears to be related to https (maybe openssl?) I just did the following test: >py -2 Python 2.7.12rc1 (v2.7.12rc1:13912cd1e7e8, Jun 12 2016, 05:57:31) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from urllib2 import urlopen >>> urlopen('http://www.google.co.uk') > >>> urlopen('https://www.google.co.uk') The HTTPS query caused the crash. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 11:32:42 2016 From: report at bugs.python.org (Tommy Beadle) Date: Mon, 13 Jun 2016 15:32:42 +0000 Subject: [issue27307] string.Formatter does not support key/attribute access on unnumbered fields Message-ID: <1465831962.68.0.949862526307.issue27307@psf.upfronthosting.co.za> New submission from Tommy Beadle: Support for unnumbered fields in string.Formatter.format was added in http://bugs.python.org/issue13598, however, it does not support accessing an index or attribute of an unnumbered field like str.format does. Instead, it raises an unhelpful "KeyError: ''": In [1]: import string In [2]: fmt = string.Formatter() In [3]: fmt.format('{[0]}', ['a', 'b']) --------------------------------------------------------------------------- KeyError Traceback (most recent call last) in () ----> 1 fmt.format('{[0]}', ['a', 'b']) /usr/lib64/python2.7/string.pyc in format(*args, **kwargs) 557 raise TypeError("format() missing 1 required positional " 558 "argument: 'format_string'") --> 559 return self.vformat(format_string, args, kwargs) 560 561 def vformat(self, format_string, args, kwargs): /usr/lib64/python2.7/string.pyc in vformat(self, format_string, args, kwargs) 561 def vformat(self, format_string, args, kwargs): 562 used_args = set() --> 563 result = self._vformat(format_string, args, kwargs, used_args, 2) 564 self.check_unused_args(used_args, args, kwargs) 565 return result /usr/lib64/python2.7/string.pyc in _vformat(self, format_string, args, kwargs, used_args, recursion_depth) 583 # given the field_name, find the object it references 584 # and the argument it came from --> 585 obj, arg_used = self.get_field(field_name, args, kwargs) 586 used_args.add(arg_used) 587 /usr/lib64/python2.7/string.pyc in get_field(self, field_name, args, kwargs) 644 first, rest = field_name._formatter_field_name_split() 645 --> 646 obj = self.get_value(first, args, kwargs) 647 648 # loop through the rest of the field_name, doing /usr/lib64/python2.7/string.pyc in get_value(self, key, args, kwargs) 603 return args[key] 604 else: --> 605 return kwargs[key] 606 607 KeyError: '' The attached patch adds this functionality. aronancher asked in http://bugs.python.org/issue13598#msg218114 if the original patch was going to make it in to python 2.7. Perhaps that could get a look? ---------- components: Library (Lib) messages: 268452 nosy: tbeadle priority: normal severity: normal status: open title: string.Formatter does not support key/attribute access on unnumbered fields type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 11:34:07 2016 From: report at bugs.python.org (Tommy Beadle) Date: Mon, 13 Jun 2016 15:34:07 +0000 Subject: [issue27307] string.Formatter does not support key/attribute access on unnumbered fields In-Reply-To: <1465831962.68.0.949862526307.issue27307@psf.upfronthosting.co.za> Message-ID: <1465832047.91.0.593867808625.issue27307@psf.upfronthosting.co.za> Changes by Tommy Beadle : ---------- keywords: +patch Added file: http://bugs.python.org/file43376/0001-Issue-27307-Support-index-attribute-access-for-unnum.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 11:35:09 2016 From: report at bugs.python.org (Tim Golden) Date: Mon, 13 Jun 2016 15:35:09 +0000 Subject: [issue27305] Crash with "pip list --outdated" on Windows 10 with Python 2.7.12rc1 In-Reply-To: <1465831917.42.0.762042415706.issue27305@psf.upfronthosting.co.za> Message-ID: <575ED2A9.7000001@timgolden.me.uk> Tim Golden added the comment: I did wonder about that. It's good that we can reproduce the issue without pip, but it's probably going to be messy to debug! I've got VS 2008 on this machine but no time at the moment to build & debug. Don't know if Zach or Steve might be able to jump in. If not, I can probably try to get to it tomorrow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 11:36:50 2016 From: report at bugs.python.org (Donald Stufft) Date: Mon, 13 Jun 2016 15:36:50 +0000 Subject: [issue27305] Crash with "pip list --outdated" on Windows 10 with Python 2.7.12rc1 In-Reply-To: <1465820074.65.0.989290191732.issue27305@psf.upfronthosting.co.za> Message-ID: <1465832210.34.0.35309274192.issue27305@psf.upfronthosting.co.za> Changes by Donald Stufft : ---------- priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 12:18:22 2016 From: report at bugs.python.org (Gareth Rees) Date: Mon, 13 Jun 2016 16:18:22 +0000 Subject: [issue24869] shlex lineno inaccurate with certain inputs In-Reply-To: <1439571963.46.0.603944237065.issue24869@psf.upfronthosting.co.za> Message-ID: <1465834702.96.0.846043889386.issue24869@psf.upfronthosting.co.za> Gareth Rees added the comment: Just to restate the problem: The use case is that when emitting an error message for a token, we want to include the number of the line containing the token (or the number of the line where the token started, if the token spans multiple lines, as it might if it's a string containing newlines). But there is no way to satisfy this use case given the features of the shlex module. In particular, shlex.lineno (which looks as if it ought to help) is actually the line number of the first character that has not yet been consumed by the lexer, and in general this is not the same as the line number of the previous (or the next) token. I can think of two alternatives that would satisfy the use case: 1. Instead of returning tokens as str objects, return them as instances of a subclass of str that has a property that gives the line number of the first character of the token. (Maybe it should also have properties for the column number of the first character, and the line and column number of the last character too? These properties would support better error messages.) 2. Add new methods that return tuples giving the token and its line number (and possibly column number etc. as in alternative 1). My preference would be for alternative (1), but I suppose there is a very tiny risk of breaking some code that relied upon get_token returning an instance of str exactly rather than an instance of a subclass of str. ---------- nosy: +Gareth.Rees _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 12:26:06 2016 From: report at bugs.python.org (Ned Deily) Date: Mon, 13 Jun 2016 16:26:06 +0000 Subject: [issue27288] secrets should use getrandom() on Linux In-Reply-To: <1465588599.3.0.867244099768.issue27288@psf.upfronthosting.co.za> Message-ID: <1465835166.53.0.732800646511.issue27288@psf.upfronthosting.co.za> Ned Deily added the comment: Setting this to "deferred blocker" priority to note that it needs to be resolved prior to feature code cutoff for 3.6.0, which is at 3.6.0b1 currently planned for 2016-09-07. ---------- priority: release blocker -> deferred blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 12:46:19 2016 From: report at bugs.python.org (Neil Schemenauer) Date: Mon, 13 Jun 2016 16:46:19 +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: <1465836379.26.0.510289751393.issue17611@psf.upfronthosting.co.za> Neil Schemenauer added the comment: This looks to be a good idea and a good time to merge it now the bytecode has changed to 16-bit. The increase in complexity to compile.c is not bad and reducing the complexity of the eval loop is worth it, IMHO. ---------- nosy: +nascheme _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 13:39:05 2016 From: report at bugs.python.org (Brett Cannon) Date: Mon, 13 Jun 2016 17:39:05 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1465839545.86.0.128121438698.issue27186@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks for catching my screw-up, Martin; I misread the checks in the file by noticing the "nt" bit but not picking up it was comparing against sys.name instead of sys.platform. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 13:53:11 2016 From: report at bugs.python.org (Gareth Rees) Date: Mon, 13 Jun 2016 17:53:11 +0000 Subject: [issue24869] shlex lineno inaccurate with certain inputs In-Reply-To: <1439571963.46.0.603944237065.issue24869@psf.upfronthosting.co.za> Message-ID: <1465840391.26.0.842032601065.issue24869@psf.upfronthosting.co.za> Gareth Rees added the comment: A third alternative: 3. Add a method whose effect is to consume comments and whitespace, but which does not yield a token. You could then call this method, and then look at shlex.lineno, which will be the line number of the first character of the next token (if there is a next token). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 14:22:31 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 13 Jun 2016 18:22:31 +0000 Subject: [issue24254] Make class definition namespace ordered by default In-Reply-To: <1432186488.39.0.20621749373.issue24254@psf.upfronthosting.co.za> Message-ID: <1465842151.7.0.139781011376.issue24254@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 14:25:03 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 13 Jun 2016 18:25:03 +0000 Subject: [issue27163] IDLE entry for What's New in Python 3.6 In-Reply-To: <1464677885.83.0.244887022976.issue27163@psf.upfronthosting.co.za> Message-ID: <1465842303.4.0.353631370727.issue27163@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Provisional addition a bit revised from above. I did not markup idlelib as a module because there is currently no section to link to. I don't know if or how IDLE can be linked to the IDLE doc. I linked to the name change issue that started the change process. I will add a link to the interface issue if and when pushed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 14:45:31 2016 From: report at bugs.python.org (Marcel Hellkamp) Date: Mon, 13 Jun 2016 18:45:31 +0000 Subject: [issue27308] Inconsistency in cgi.FieldStorage() causes unicode/byte issue. Message-ID: <1465843531.5.0.166620691183.issue27308@psf.upfronthosting.co.za> New submission from Marcel Hellkamp: Discovered here: https://github.com/bottlepy/bottle/issues/856 If a multipart section has a "Content-Length" header, but no "filename" attribute in the "Content-Disposition" header, cgi.FieldStorage tries to write binary data to a temporary file opened in text-mode. The problem here is that cgi.FieldStorage tries to decide if something is a binary file-upload or a unicode form-field, but it does so based on two different headers in two different places. If the headers contradict each other (form-fields usually don't have a Content-Length, file-uploads usually have a filename), parsing breaks with a TypeError. Unfortunately, there are some HTTP client libraries out there that trigger this bug. Here is what happens: A "Content-Length" header causes `cgi.FieldStorage.length` to be is set (which is fine). https://hg.python.org/cpython/file/3.4/Lib/cgi.py#l550 If `length` has a value, `read_binary()` is used instead of `read_lines()` (which is questionable). https://hg.python.org/cpython/file/3.4/Lib/cgi.py#l733 `read_binary()` calls `make_file()` which creates the buffer file in text mode if it does not find a `filename` attribute in the "Content-Disposition" Header (which is somewhat okay). https://hg.python.org/cpython/file/3.4/Lib/cgi.py#l515 https://hg.python.org/cpython/file/3.4/Lib/cgi.py#l893 The bug is triggered if the last two steps disagree on the bytes vs. text question. ---------- components: Library (Lib) messages: 268460 nosy: Marcel Hellkamp priority: normal severity: normal status: open title: Inconsistency in cgi.FieldStorage() causes unicode/byte issue. type: crash versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 14:46:07 2016 From: report at bugs.python.org (Marcel Hellkamp) Date: Mon, 13 Jun 2016 18:46:07 +0000 Subject: [issue27308] Inconsistency in cgi.FieldStorage() causes unicode/byte TypeError. In-Reply-To: <1465843531.5.0.166620691183.issue27308@psf.upfronthosting.co.za> Message-ID: <1465843567.07.0.941002369438.issue27308@psf.upfronthosting.co.za> Changes by Marcel Hellkamp : ---------- title: Inconsistency in cgi.FieldStorage() causes unicode/byte issue. -> Inconsistency in cgi.FieldStorage() causes unicode/byte TypeError. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 15:03:53 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 13 Jun 2016 19:03:53 +0000 Subject: [issue27308] Inconsistency in cgi.FieldStorage() causes unicode/byte TypeError. In-Reply-To: <1465843531.5.0.166620691183.issue27308@psf.upfronthosting.co.za> Message-ID: <1465844633.4.0.708396940578.issue27308@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: -> needs patch type: crash -> behavior versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 15:15:17 2016 From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=) Date: Mon, 13 Jun 2016 19:15:17 +0000 Subject: [issue19570] distutils' Command.ensure_dirname fails on Unicode In-Reply-To: <1384348317.37.0.567121673163.issue19570@psf.upfronthosting.co.za> Message-ID: <1465845317.69.0.261147879329.issue19570@psf.upfronthosting.co.za> Adam Barto? added the comment: Recently, I was also hit by this when trying to autoset `sys.argv` to a list of Unicode string (see https://github.com/Drekin/win-unicode-console/issues/20#issuecomment-225638271 ). It would be nice to have this fixed. It seems to me (I may be wrong) that every occurence of `isinstance(?, str)` is a potential bug in Python 2.7. Either it should be spelled out as `isinstance(?, bytes)` or there should be `isinstance(?, types.StringTypes)` or even `isinstance(?, unicode)`. ---------- nosy: +Drekin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 15:20:02 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 13 Jun 2016 19:20:02 +0000 Subject: [issue27294] Better repr for Tkinter event objects In-Reply-To: <1465648557.25.0.737232700025.issue27294@psf.upfronthosting.co.za> Message-ID: <1465845602.17.0.183318802713.issue27294@psf.upfronthosting.co.za> Changes by Terry J. Reedy : Added file: http://bugs.python.org/file43377/tk-win-key-events2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 15:23:05 2016 From: report at bugs.python.org (Marcel Hellkamp) Date: Mon, 13 Jun 2016 19:23:05 +0000 Subject: [issue27308] Inconsistency in cgi.FieldStorage() causes unicode/byte TypeError. In-Reply-To: <1465843531.5.0.166620691183.issue27308@psf.upfronthosting.co.za> Message-ID: <1465845785.69.0.708491552943.issue27308@psf.upfronthosting.co.za> Marcel Hellkamp added the comment: This should fix the issue. ---------- keywords: +patch Added file: http://bugs.python.org/file43378/foo.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 15:24:19 2016 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 13 Jun 2016 19:24:19 +0000 Subject: [issue27122] Hang with contextlib.ExitStack and subprocess.Popen (regression) In-Reply-To: <1464176880.25.0.308106356091.issue27122@psf.upfronthosting.co.za> Message-ID: <1465845859.76.0.761473748012.issue27122@psf.upfronthosting.co.za> Nick Coghlan added the comment: Greg, I think you should apply your change to eliminate the regression and get us back to the state of all stdlib context managers being well-behaved in this regard (we unfortunately missed the 3.5.2 release, but that will ensure it's fixed for 3.5.3). Given the challenges I had trying to reproduce the hang with a plain context manager rather than a generator, I now the problem is specifically just #25782 - in the absence of that, ExitStack() should misbehave in the same way actual nested with statements would, rather than trying to implicitly "fix" the misbehaving context managers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 15:24:44 2016 From: report at bugs.python.org (Tim Golden) Date: Mon, 13 Jun 2016 19:24:44 +0000 Subject: [issue27305] Crash with "pip list --outdated" on Windows 10 with Python 2.7.12rc1 In-Reply-To: <1465820074.65.0.989290191732.issue27305@psf.upfronthosting.co.za> Message-ID: <1465845884.68.0.337131334452.issue27305@psf.upfronthosting.co.za> Tim Golden added the comment: I can reproduce with the download build but not with a freshly-built executable ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 15:27:21 2016 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 13 Jun 2016 19:27:21 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <1465846041.51.0.888087811199.issue25782@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Yury's raises a RuntimeError in the loop situation. > Serhiy's simply reorders the exception context to put the referred to one at the front of the chain in the event of a loop. Right, and I believe that my solution is more Pythonic. Reordering feels highly unintuitive to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 15:28:16 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 13 Jun 2016 19:28:16 +0000 Subject: [issue27308] Inconsistency in cgi.FieldStorage() causes unicode/byte TypeError. In-Reply-To: <1465843531.5.0.166620691183.issue27308@psf.upfronthosting.co.za> Message-ID: <1465846096.8.0.456838493774.issue27308@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch. From a quick look, the patch looks fine but we need a test case. You can see Lib/test/test_cgi.py for existing tests. ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 15:52:50 2016 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 13 Jun 2016 19:52:50 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <1465847570.94.0.78179897347.issue25782@psf.upfronthosting.co.za> Nick Coghlan added the comment: For both of the proposed patches, could we add a test case based on contextlib.ExitStack and a variant of Victor's #27122 reproducer script at http://bugs.python.org/file42999/hang_bug2.py that uses a deliberately broken __exit__ implementation that always re-raises the exception thrown into the underlying generator? As discussed on that issue, I'm wondering if we need some additional defensive coding in ExitStack itself, or if resolving this underlying problem will be enough to also categorically prevent the hang in ExitStack. As far as possible resolutions go, I tend to prefer lying about the shape of the exception state over changing the type of the raised exception - we already know the true exception state is a tree rather than a chain (see #18861 for some related discussions), and we should be able to ensure that all active exceptions remain somewhere in the chain, even if their order is a bit surprising. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 15:57:52 2016 From: report at bugs.python.org (Marcel Hellkamp) Date: Mon, 13 Jun 2016 19:57:52 +0000 Subject: [issue27308] Inconsistency in cgi.FieldStorage() causes unicode/byte TypeError. In-Reply-To: <1465843531.5.0.166620691183.issue27308@psf.upfronthosting.co.za> Message-ID: <1465847872.26.0.983371702171.issue27308@psf.upfronthosting.co.za> Marcel Hellkamp added the comment: Looks like this is a duplicate to #24764 and already fixed. Sorry for the noise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 16:03:23 2016 From: report at bugs.python.org (Tim Golden) Date: Mon, 13 Jun 2016 20:03:23 +0000 Subject: [issue27305] Crash with "pip list --outdated" on Windows 10 with Python 2.7.12rc1 In-Reply-To: <1465845884.68.0.337131334452.issue27305@psf.upfronthosting.co.za> Message-ID: <14c08a8f-87be-5840-7d08-760f5824b671@timgolden.me.uk> Tim Golden added the comment: The crash is actually happening in Modules/_ssl.c:_get_peer_alt_names. > _ssl.pyd!_get_peer_alt_names(x509_st * certificate) Line 810 + 0x2 bytes C _ssl.pyd!_decode_certificate(x509_st * certificate) Line 1187 + 0x8 bytes C _ssl.pyd!PySSL_peercert(PySSLSocket * self, _object * args) Line 1335 C I note that Benjamin committed a leak-fix change a day or so before 2.7.12rc1 was tagged: https://hg.python.org/cpython/rev/66cd109f3f21 As it stands, I can't build 64-bit with my setup and the 32-bit build seems fine so it's hard to bisect. I'll try to get a 64-bit build working to give better information. (The trace above is from an attached debugger). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 16:03:47 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 13 Jun 2016 20:03:47 +0000 Subject: [issue27308] Inconsistency in cgi.FieldStorage() causes unicode/byte TypeError. In-Reply-To: <1465843531.5.0.166620691183.issue27308@psf.upfronthosting.co.za> Message-ID: <1465848227.49.0.465431344355.issue27308@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> duplicate stage: patch review -> resolved status: open -> closed superseder: -> cgi.FieldStorage can't parse multipart part headers with Content-Length and no filename in Content-Disposition _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 16:23:09 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 13 Jun 2016 20:23:09 +0000 Subject: [issue26386] tkinter - Treeview - .selection_add and selection_toggle In-Reply-To: <1455813008.22.0.795281140329.issue26386@psf.upfronthosting.co.za> Message-ID: <1465849389.02.0.432957436767.issue26386@psf.upfronthosting.co.za> Terry J. Reedy added the comment: LGTM, but after applying to all 3, leave open (or open new issue) to replace patch in 3.6 (before beta 1). Change signature to *items. That will automatically make a single string become a len 1 tuple. For selection (list the 4 selops and) add a note. "For back compatibility, one may also pass a single tuple (or list?) of items." and Version Changed. For 4 derivatives, 'See selection.' In the code, instead add (untested): if len(items) == 1: # Remove after deprecation. item0 = items[0] if not isinstance(items[0], isinstance(str)): raise DeprecationWarning( "The option of passing multiple items as a tuple " "rather than as multiple items is deprecated and " "will be removed in 2020 or later.") items = items0 # or more processing if lists were allowed Revise test accordingly. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 16:31:54 2016 From: report at bugs.python.org (Nathan Harold) Date: Mon, 13 Jun 2016 20:31:54 +0000 Subject: [issue26262] Cannot compile with /fp:strict with MSVC In-Reply-To: <1454349009.19.0.118531537241.issue26262@psf.upfronthosting.co.za> Message-ID: <1465849914.35.0.239081725455.issue26262@psf.upfronthosting.co.za> Nathan Harold added the comment: Here's a patch with those three replacements and related comments. ---------- keywords: +patch nosy: +nharold Added file: http://bugs.python.org/file43379/constants.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 16:34:01 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 13 Jun 2016 20:34:01 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <1465850041.39.0.536095758756.issue25782@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: With reordering the issue27122 test is passed without changes. No changes in ExitStack is needed. Here is updated patch. ---------- Added file: http://bugs.python.org/file43380/set_context_reordering2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 16:36:28 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 13 Jun 2016 20:36:28 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <1465850188.1.0.0844791796204.issue25782@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: With Yury's path the issue27122 test need to be changed (RuntimeError is now raised instead of original exception). Here is updated patch. ---------- Added file: http://bugs.python.org/file43381/Issue25782_5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 17:48:48 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 13 Jun 2016 21:48:48 +0000 Subject: [issue27306] Grammatical Error in Documentation - Tarfile page In-Reply-To: <1465820218.96.0.154135651878.issue27306@psf.upfronthosting.co.za> Message-ID: <20160613214844.20127.21533.1F1B646B@psf.io> Roundup Robot added the comment: New changeset 48052a140eed by Berker Peksag in branch '3.5': Issue #27306: Fix typo in tarfile documentation https://hg.python.org/cpython/rev/48052a140eed New changeset 9c9ed326d981 by Berker Peksag in branch 'default': Issue #27306: Merge from 3.5 https://hg.python.org/cpython/rev/9c9ed326d981 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 17:49:10 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 13 Jun 2016 21:49:10 +0000 Subject: [issue27306] Grammatical Error in Documentation - Tarfile page In-Reply-To: <1465820218.96.0.154135651878.issue27306@psf.upfronthosting.co.za> Message-ID: <1465854550.08.0.624278788463.issue27306@psf.upfronthosting.co.za> Berker Peksag added the comment: Thank you all! ---------- nosy: +berker.peksag resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 17:57:18 2016 From: report at bugs.python.org (Jarrod Petz) Date: Mon, 13 Jun 2016 21:57:18 +0000 Subject: [issue27263] Tkinter sets the HOME environment variable, breaking scripts In-Reply-To: <1465352687.77.0.957460905896.issue27263@psf.upfronthosting.co.za> Message-ID: <1465855038.4.0.260788381476.issue27263@psf.upfronthosting.co.za> Jarrod Petz added the comment: eryksun, now I understand this is a bit more challenging because tkinter is the underlying library doing this and it is shared by other apps. Though I still don't feel that just because its been like this since 1995 means it should stay this way. This is something which breaks other code following the python os.path.expanduser way(and probably other thing looking at the evitonmeny HOME). Not all people will try getting to the bottom of why, esspecially if they are a new user. It should just work. Would iy be possible for tkinter to allow the user/app to decide the behavior? Ie. Have a setting(s)/switch which allows the default behavior of setting and using HOME to be overiden. By doing that existing apps remain unchanged and apps like IDLE could change this behavior to whatever they want when they are ready. I think os.path.expanduser() behavior is by far more logical. Preference USERPROFILE if HOME is missing. USERPROFILE on windows is needed to even login. HOMEDRIVE/HOMEPATH is not. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 17:59:56 2016 From: report at bugs.python.org (HYBRID BEING) Date: Mon, 13 Jun 2016 21:59:56 +0000 Subject: [issue27309] Visual Styles support Message-ID: <1465855196.42.0.576274211307.issue27309@psf.upfronthosting.co.za> New submission from [HYBRID BEING]: This answer (http://stackoverflow.com/questions/33792008/python-tkinter-ttk-themed-message-box/33801260#33801260) to the Stack Overflow question states that Tkinter's messageboxes use non-themed controls due to the fact that python.exe and pythonw.exe lack manifest which notifies Windows that application supports Visual Styles. Is there any specific reason it's not used? ---------- components: Windows messages: 268477 nosy: [HYBRID BEING], paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Visual Styles support type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 18:06:58 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 13 Jun 2016 22:06:58 +0000 Subject: [issue27173] Modern Unix key bindings for IDLE In-Reply-To: <1464766185.36.0.150155479026.issue27173@psf.upfronthosting.co.za> Message-ID: <1465855618.31.0.334858404461.issue27173@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Ned, Serhiy's patch 4 solves one of your concerns in #20580 with + @staticmethod + def DefaultKeys(): + if sys.platform[:3] == 'win': + return 'IDLE Classic Windows' + elif sys.platform == 'darwin': + return 'IDLE Classic OSX' + else: + return 'IDLE Modern Unix' Please confirm that Classic OSX is the right choice over Classic Mac. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 18:09:44 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 13 Jun 2016 22:09:44 +0000 Subject: [issue27099] IDLE: turn builting extensions into regular modules In-Reply-To: <1464055360.13.0.626532918919.issue27099@psf.upfronthosting.co.za> Message-ID: <1465855784.34.0.963270516146.issue27099@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The first line of the last message should have said 'in addition to' instead of 'rather than', In the following expanded table, Key is the number of pseudoevents with configurable and fixed key bindings. Gen is the number of General pseudoevents. (Current, from config-main.def.) File Menu Key Gen ------------ ------------------------------ --- --- autocomplete Edit - Show Completions 1,2 1 autoexpand Edit - Expand Word 1,- - calltips Edit - Show call tip 1,2 - parenmatch Edit - Show surrounding parens 1,1 3 paragraph Format - Format Paragraph 1,- 1 rstrip Format - Strip trailing white- -,- - runscript Run - Check Module 2,0 - runscript Run - Run Module same file codecontext Options - Code Context -,- 2 zoomheight Window - Zoom Height 1,- - My initial experiment with adding a fake event and binding in the user config-keys.cfg does not affect existing versions. It appears to be completely ignored and does not appear on the list of configurable keys in the dialog. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 18:28:04 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 13 Jun 2016 22:28:04 +0000 Subject: [issue20580] IDLE should support platform-specific default config defaults In-Reply-To: <1392027551.21.0.533992391985.issue20580@psf.upfronthosting.co.za> Message-ID: <1465856884.62.0.137136239203.issue20580@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Ned, looking at config-keys.def, the Mac and Osx sections have a mixture of 'Command' and 'Control'. I have the impression from what you wrote above that every 'Control' should be 'Command'. Why are the sections as they are? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 18:32:34 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 13 Jun 2016 22:32:34 +0000 Subject: [issue27099] IDLE: turn builting extensions into regular modules In-Reply-To: <1464055360.13.0.626532918919.issue27099@psf.upfronthosting.co.za> Message-ID: <1465857154.65.0.515060994582.issue27099@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Ned, I reread #20580. It reminds me that both Control and Alt are problems. In built-in config-extensions.def, the builtin fixed bindings and one of the configurable bindings are: autocomplete: calltips: parenmatch: runscript: (configurable) I presume that these all work fine on Macs. Every other configurable binding uses 'Control' or 'Alt'. When I copy configurable bindings into the file, I have to put them in each section. Should I change each to 'Command' or 'Option' for the 'Mac' and 'Osx' sections? Also see comment on #20580. I am adding #27173 as a dependency, for now, because it might be easier to include the new key set before starting to add new bindings. ---------- dependencies: +Modern Unix key bindings for IDLE _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 18:35:37 2016 From: report at bugs.python.org (Ned Deily) Date: Mon, 13 Jun 2016 22:35:37 +0000 Subject: [issue27173] Modern Unix key bindings for IDLE In-Reply-To: <1464766185.36.0.150155479026.issue27173@psf.upfronthosting.co.za> Message-ID: <1465857337.56.0.896596596582.issue27173@psf.upfronthosting.co.za> Ned Deily added the comment: "Please confirm that Classic OSX is the right choice over Classic Mac" It is. At least, when we install IDLE on OS X, Clsssic OS X is the default set. I don't know why Classic Mac exists; I'm guessing it is left over from Mac OS 9 days (pre OS X). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 18:38:52 2016 From: report at bugs.python.org (Ned Deily) Date: Mon, 13 Jun 2016 22:38:52 +0000 Subject: [issue20580] IDLE should support platform-specific default config defaults In-Reply-To: <1392027551.21.0.533992391985.issue20580@psf.upfronthosting.co.za> Message-ID: <1465857532.5.0.0372480961246.issue20580@psf.upfronthosting.co.za> Ned Deily added the comment: "I have the impression from what you wrote above that every 'Control' should be 'Command'." I'm not sure where I gave that impression but, no, the default IDLE keyset on OS X has command accelerators with Command- modifiers and some with Control- modifiers, as is typical of OS X applications. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 18:39:48 2016 From: report at bugs.python.org (Tim Golden) Date: Mon, 13 Jun 2016 22:39:48 +0000 Subject: [issue27305] Crash with "pip list --outdated" on Windows 10 with Python 2.7.12rc1 In-Reply-To: <14c08a8f-87be-5840-7d08-760f5824b671@timgolden.me.uk> Message-ID: <2a94db25-06d5-647a-649b-7346f686caf9@timgolden.me.uk> Tim Golden added the comment: Built 64-bit 2.7 but can't reproduce on tip, 2.7.12rc1 or 2.7.11 tags. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 19:03:57 2016 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 13 Jun 2016 23:03:57 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <1465859037.17.0.208706878098.issue25782@psf.upfronthosting.co.za> Nick Coghlan added the comment: Thanks Serhiy. I've attached a new file (issue27122_broken_cm.py) with a context manager that is deliberately buggy in the same way as contextlib._GeneratorContextManager is currently, so the new test can be made independent of #27122 being fixed (Greg Smith has a pending patch to make that CM well behaved again, which would currently lead to your new test passing for the wrong reasons) issue27122_broken_cm.py also shows why I think "make it work" is the right answer here - the odd context chaining is tolerated in the case where the interpreter is implicitly setting the exception context, so I believe it should also be tolerated when ExitStack sets the context explicitly. If we "do the right thing" (where "right" = "the same as what the interpreter does") in the setter, then not only ExitStack, but anyone else setting __context__ should automatically benefit from the adjustment. ---------- Added file: http://bugs.python.org/file43382/issue27122_broken_cm.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 19:09:47 2016 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 13 Jun 2016 23:09:47 +0000 Subject: [issue27122] Hang with contextlib.ExitStack and subprocess.Popen (regression) In-Reply-To: <1464176880.25.0.308106356091.issue27122@psf.upfronthosting.co.za> Message-ID: <1465859387.32.0.97134920422.issue27122@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: ncoghlan -> gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 20:03:07 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jun 2016 00:03:07 +0000 Subject: [issue27136] sock_connect fails for bluetooth (and probably others) In-Reply-To: <1464346938.98.0.196127839357.issue27136@psf.upfronthosting.co.za> Message-ID: <20160614000302.87651.66641.7C904937@psf.io> Roundup Robot added the comment: New changeset e032ffd5ae84 by Martin Panter in branch '3.5': Issue #27136: Change test to use ::1 for better OS X Tiger compatibility https://hg.python.org/cpython/rev/e032ffd5ae84 New changeset f31b6c3e41f7 by Martin Panter in branch 'default': Issue #27136: Merge test_asyncio fix from 3.5 https://hg.python.org/cpython/rev/f31b6c3e41f7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 20:16:34 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 14 Jun 2016 00:16:34 +0000 Subject: [issue27310] 3.6.0a2 IDLE.app on OS X fails to launch, use command line idle3.6 instead Message-ID: <1465863394.35.0.0523596736089.issue27310@psf.upfronthosting.co.za> New submission from Ned Deily: For 3.6.0a2, when attempting to launch IDLE.app on OS X (for example, by double-clicking the IDLE icon in the "/Applications/Python 3.6" folder), IDLE does not launch. In the system.log there will be a log message similar to: (org.python.IDLE.917792[45897]): Service exited with abnormal code: 1 The problem is that the glue code (idlemain.py) used to launch IDLE from within the IDLE app bundle is trying to import macosxSupport which has been renamed as of 3.6.0a2. However, there is no longer any reason for the app bundle to import this module: this is vestigial code that I should have removed some releases ago when I refactored macosxSupport. It hasn't hurt up until now. As a workaround for 3.6.0a2, you can launch IDLE from a terminal command line: /usr/local/bin/idle3.6 or you *could* carefully msnuslly edit the file /Applications/Python 3.6/IDLE.app/Contents/Resources/idlemain.py to remove the two lines near the end: from idlelib import macosxSupport macosxSupport._appbundle = True Fix for 3.6.0a3 to follow. ---------- assignee: ned.deily components: IDLE messages: 268487 nosy: ned.deily priority: critical severity: normal stage: needs patch status: open title: 3.6.0a2 IDLE.app on OS X fails to launch, use command line idle3.6 instead versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 20:28:37 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jun 2016 00:28:37 +0000 Subject: [issue27310] 3.6.0a2 IDLE.app on OS X fails to launch, use command line idle3.6 instead In-Reply-To: <1465863394.35.0.0523596736089.issue27310@psf.upfronthosting.co.za> Message-ID: <20160614002831.19950.1323.F3FC5765@psf.io> Roundup Robot added the comment: New changeset 675569bee37f by Ned Deily in branch '2.7': Issue #27310: remove vestigial import in IDLE.app https://hg.python.org/cpython/rev/675569bee37f New changeset 0cf4bda2882c by Ned Deily in branch '3.5': Issue #27310: remove vestigial import in IDLE.app https://hg.python.org/cpython/rev/0cf4bda2882c New changeset 9ba934d159e3 by Ned Deily in branch 'default': Issue #27310: Fix IDLE.app failure to launch on OS X due to vestigial import. https://hg.python.org/cpython/rev/9ba934d159e3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 20:29:39 2016 From: report at bugs.python.org (A. Jesse Jiryu Davis) Date: Tue, 14 Jun 2016 00:29:39 +0000 Subject: [issue27136] sock_connect fails for bluetooth (and probably others) In-Reply-To: <1464346938.98.0.196127839357.issue27136@psf.upfronthosting.co.za> Message-ID: <1465864179.37.0.496798040533.issue27136@psf.upfronthosting.co.za> A. Jesse Jiryu Davis added the comment: Thank you Martin! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 20:30:30 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 14 Jun 2016 00:30:30 +0000 Subject: [issue27310] 3.6.0a2 IDLE.app on OS X fails to launch, use command line idle3.6 instead In-Reply-To: <1465863394.35.0.0523596736089.issue27310@psf.upfronthosting.co.za> Message-ID: <1465864230.34.0.298084648778.issue27310@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 20:42:21 2016 From: report at bugs.python.org (John Hagen) Date: Tue, 14 Jun 2016 00:42:21 +0000 Subject: [issue27311] Incorrect documentation for zipfile.writestr() Message-ID: <1465864941.05.0.345060177149.issue27311@psf.upfronthosting.co.za> New submission from John Hagen: The function signature and description for zipfile.writestr is incorrect: https://docs.python.org/3.5/library/zipfile.html#zipfile.ZipFile.writestr See: https://github.com/python/cpython/blob/master/Lib/zipfile.py#L1610 The documentation calls the parameter 'bytes', but the real parameter name is 'data'. Looks like this was not fixed when the source changed to Python 3: https://github.com/python/cpython/blob/2.7/Lib/zipfile.py#L1208 ---------- assignee: docs at python components: Documentation messages: 268490 nosy: John Hagen, docs at python priority: normal severity: normal status: open title: Incorrect documentation for zipfile.writestr() versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 20:44:22 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 14 Jun 2016 00:44:22 +0000 Subject: [issue12855] linebreak sequences should be better documented In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za> Message-ID: <1465865062.2.0.163816844064.issue12855@psf.upfronthosting.co.za> Martin Panter added the comment: Alexander: does my latest patch linebreakdoc.v5.py2.7.patch address your concerns about the 2.7 documentation? If so, I can push it to the repository. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 20:49:50 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 14 Jun 2016 00:49:50 +0000 Subject: [issue27312] test_setupapp (idlelib.idle_test.test_macosx.SetupTest) fails on OS X Message-ID: <1465865390.09.0.618470621806.issue27312@psf.upfronthosting.co.za> New submission from Ned Deily: Running tests of 3.6.0a2 with gui enabled on OS X result in various failures of the form: ====================================================================== ERROR: test_setupapp (idlelib.idle_test.test_macosx.SetupTest) (tktype='carbon') Call setupApp with each possible graphics type. ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/idlelib/idle_test/test_macosx.py", line 93, in test_setupapp macosx.setupApp(root, flist) File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/idlelib/macosx.py", line 245, in setupApp overrideRootMenu(root, flist) File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/idlelib/macosx.py", line 133, in overrideRootMenu closeItem = mainmenu.menudefs[0][1][-2] IndexError: list index out of range ====================================================================== ERROR: test_setupapp (idlelib.idle_test.test_macosx.SetupTest) (tktype='cocoa') Call setupApp with each possible graphics type. ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/idlelib/idle_test/test_macosx.py", line 93, in test_setupapp macosx.setupApp(root, flist) File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/idlelib/macosx.py", line 245, in setupApp overrideRootMenu(root, flist) File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/idlelib/macosx.py", line 133, in overrideRootMenu closeItem = mainmenu.menudefs[0][1][-2] IndexError: list index out of range ---------- components: IDLE messages: 268492 nosy: ned.deily, terry.reedy priority: high severity: normal stage: needs patch status: open title: test_setupapp (idlelib.idle_test.test_macosx.SetupTest) fails on OS X versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 20:54:07 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 14 Jun 2016 00:54:07 +0000 Subject: [issue27312] test_setupapp (idlelib.idle_test.test_macosx.SetupTest) fails on OS X In-Reply-To: <1465865390.09.0.618470621806.issue27312@psf.upfronthosting.co.za> Message-ID: <1465865647.95.0.352872478585.issue27312@psf.upfronthosting.co.za> Ned Deily added the comment: Without looking closely at it, I would speculate that the failures are due to trying to test code in overrideRootMenu() that was previously only called once during execution and may not be re-enterant: # Remove the last 3 items of the file menu: a separator, close window and # quit. Close window will be reinserted just above the save item, where # it should be according to the HIG. Quit is in the application menu. del mainmenu.menudefs[0][1][-3:] mainmenu.menudefs[0][1].insert(6, closeItem) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 21:06:20 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 14 Jun 2016 01:06:20 +0000 Subject: [issue27313] test case failures in test_widgets.ComboboxTest.of test_ttk_guionly on OS X with Cocoa Tk 8.5.18 Message-ID: <1465866380.0.0.570463827001.issue27313@psf.upfronthosting.co.za> New submission from Ned Deily: On 3.6.0a2, 3.5.2rc1, and 2.7.12rc1: ====================================================================== FAIL: test_identify (tkinter.test.test_ttk.test_widgets.ComboboxTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/tkinter/test/test_ttk/test_widgets.py", line 332, in test_identify self.assertEqual(self.entry.identify(5, 5), "textarea") AssertionError: 'Combobox.button' != 'textarea' - Combobox.button + textarea On 3.6.0a2 and 3.5.2rc1: ====================================================================== FAIL: test_virtual_event (tkinter.test.test_ttk.test_widgets.ComboboxTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/tkinter/test/test_ttk/test_widgets.py", line 455, in test_virtual_event self.assertTrue(success) AssertionError: [] is not true ---------------------------------------------------------------------- ---------- components: Tests, Tkinter messages: 268494 nosy: ned.deily, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: test case failures in test_widgets.ComboboxTest.of test_ttk_guionly on OS X with Cocoa Tk 8.5.18 versions: Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 21:06:53 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 14 Jun 2016 01:06:53 +0000 Subject: [issue27311] Incorrect documentation for zipfile.writestr() In-Reply-To: <1465864941.05.0.345060177149.issue27311@psf.upfronthosting.co.za> Message-ID: <1465866413.37.0.420043453995.issue27311@psf.upfronthosting.co.za> Martin Panter added the comment: Looks like you are right. The change in the implementation happened in revision 19196cce1431. ---------- keywords: +easy nosy: +martin.panter stage: -> needs patch versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 21:11:29 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 14 Jun 2016 01:11:29 +0000 Subject: [issue27263] Tkinter sets the HOME environment variable, breaking scripts In-Reply-To: <1465352687.77.0.957460905896.issue27263@psf.upfronthosting.co.za> Message-ID: <1465866689.49.0.20471560476.issue27263@psf.upfronthosting.co.za> Terry J. Reedy added the comment: How about wrapping the appropriate tkinter code with (untested yet) import os HOME = os.environ['HOME'] try: finally" os.environ['HOME'] = HOME # will this unset? or use a restore_env('HOME', ...) context manager? Revising os.expanduser or apps to ignore HOME while tk is running is a related but different issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 21:12:05 2016 From: report at bugs.python.org (John Hagen) Date: Tue, 14 Jun 2016 01:12:05 +0000 Subject: [issue27311] Incorrect documentation for zipfile.writestr() In-Reply-To: <1465864941.05.0.345060177149.issue27311@psf.upfronthosting.co.za> Message-ID: <1465866725.37.0.337377198746.issue27311@psf.upfronthosting.co.za> John Hagen added the comment: I'll submit a patch shortly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 21:13:03 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 14 Jun 2016 01:13:03 +0000 Subject: [issue27310] 3.6.0a2 IDLE.app on OS X fails to launch, use command line idle3.6 instead In-Reply-To: <1465863394.35.0.0523596736089.issue27310@psf.upfronthosting.co.za> Message-ID: <1465866783.46.0.50031814775.issue27310@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 21:36:08 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 14 Jun 2016 01:36:08 +0000 Subject: [issue26631] Unable to install Python 3.5.1 on Windows 10 - Error 0x80070643: Failed to install MSI package. In-Reply-To: <1458771798.71.0.333968276616.issue26631@psf.upfronthosting.co.za> Message-ID: <1465868168.78.0.233870135958.issue26631@psf.upfronthosting.co.za> Steve Dower added the comment: The launcher issue is different from the original one posted here, so I'll create a separate issue to track it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 21:44:25 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 14 Jun 2016 01:44:25 +0000 Subject: [issue16182] readline: Wrong tab completion scope indices in Unicode terminals In-Reply-To: <1349813384.06.0.615857426211.issue16182@psf.upfronthosting.co.za> Message-ID: <1465868665.28.0.397774970104.issue16182@psf.upfronthosting.co.za> Martin Panter added the comment: I get two other test suite failures if I set PYTHONIOENCODING, so I am not going to bother addressing this in test_readline :) FAIL: test_forced_io_encoding (test.test_capi.EmbeddingTests) FAIL: test_7 (test.test_pkg.TestPkg) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 21:59:24 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 14 Jun 2016 01:59:24 +0000 Subject: [issue27314] Cannot install 3.5.2 with 3.6.0a1 installed Message-ID: <1465869564.71.0.178376895895.issue27314@psf.upfronthosting.co.za> New submission from Steve Dower: (Originally posted as a comment to issue26631 but confirmed separately.) For 3.5.2 and 3.6.0a2, I updated the installer for the launcher so that it is always shared between Python versions (i.e. if you install 3.6 followed by 3.5, it won't touch the launcher because there's a "newer" one there). However, because this didn't make it into 3.6.0a1, there is actually a version conflict that breaks installation. I've marked this a deferred blocker for now and brought in the two RMs. I believe (and will test with the RCs) that this won't recur with the latest versions. It can also be easily worked around by choosing not to install the launcher. We haven't seen this before because there have been no supported "downgrade" scenarios (i.e. installing 3.5.0 over 3.5.1 aborts at the start, well before this error would be seen). ---------- assignee: steve.dower components: Windows messages: 268500 nosy: larry, ned.deily, paul.moore, steve.dower, tim.golden, zach.ware priority: deferred blocker severity: normal stage: test needed status: open title: Cannot install 3.5.2 with 3.6.0a1 installed type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 22:00:11 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 14 Jun 2016 02:00:11 +0000 Subject: [issue26631] Unable to install Python 3.5.1 on Windows 10 - Error 0x80070643: Failed to install MSI package. In-Reply-To: <1458771798.71.0.333968276616.issue26631@psf.upfronthosting.co.za> Message-ID: <1465869611.61.0.471085800648.issue26631@psf.upfronthosting.co.za> Steve Dower added the comment: Launcher issue is issue27314 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 22:00:18 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 14 Jun 2016 02:00:18 +0000 Subject: [issue27314] Cannot install 3.5.2 with 3.6.0a1 installed In-Reply-To: <1465869564.71.0.178376895895.issue27314@psf.upfronthosting.co.za> Message-ID: <1465869618.08.0.931056545873.issue27314@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- nosy: +Steven.Barker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 22:13:29 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 14 Jun 2016 02:13:29 +0000 Subject: [issue27314] Cannot install 3.5.2 with 3.6.0a1 installed In-Reply-To: <1465869564.71.0.178376895895.issue27314@psf.upfronthosting.co.za> Message-ID: <1465870409.07.0.079378932604.issue27314@psf.upfronthosting.co.za> Steve Dower added the comment: Okay, it's not an issue with the newer versions, and I don't see any reason to worry about 3.6.0a1. One issue that remains is that installing the launcher with 3.6.0 creates a separate add-remove programs entry and doesn't remove the 3.5.2rc1 entry, but the reference counting on files seems to be fine, so it's not a big deal and something I'll fix before 3.6 releases. ---------- priority: deferred blocker -> normal versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 22:38:50 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 14 Jun 2016 02:38:50 +0000 Subject: [issue27312] test_setupapp (idlelib.idle_test.test_macosx.SetupTest) fails on OS X In-Reply-To: <1465865390.09.0.618470621806.issue27312@psf.upfronthosting.co.za> Message-ID: <1465871930.16.0.416801102836.issue27312@psf.upfronthosting.co.za> Terry J. Reedy added the comment: test_setupapp calls setupApp with body if isAquaTk(): hideTkConsole(root) overrideRootMenu(root, flist) addOpenEventSupport(root, flist) fixb2context(root) isAquaTk should be True exactly twice, and it failed both times. The overall code is definitely not re-entrant On Carbon, 'application' in inserted before 'file' and becomes menudef[0]. The puzzle to me is the failure on what should be the first call. Until that is figured out, you could try decorating test_setupapp with @mock.patch(idlelib.macosx.setupApp) to see what, if anything, fails next. I have access to a small Macbook Air with 11" diag. screen -- probably too small for my eyes for routine use but I should be able to run test_idle (especially post push) and do occasional exploratory editing, as needed here. I will try to learn enough about how to use it to follow the devguide instructions on setting up a repository. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 22:56:34 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 14 Jun 2016 02:56:34 +0000 Subject: [issue27305] Crash with "pip list --outdated" on Windows 10 with Python 2.7.12rc1 In-Reply-To: <1465820074.65.0.989290191732.issue27305@psf.upfronthosting.co.za> Message-ID: <1465872994.67.0.938847819832.issue27305@psf.upfronthosting.co.za> Steve Dower added the comment: It seems to work fine on my build machine (Win Server 2012) but not my laptop (Win 10 Home). I suspect there's a different certificate being loaded that's causing the crash, but until I get a chance to debug properly I can't be sure. Hopefully I'll get a chance to look tomorrow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 23:03:43 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jun 2016 03:03:43 +0000 Subject: [issue16182] readline: Wrong tab completion scope indices in Unicode terminals In-Reply-To: <1349813384.06.0.615857426211.issue16182@psf.upfronthosting.co.za> Message-ID: <20160614030340.11339.95278.1A99663E@psf.io> Roundup Robot added the comment: New changeset 5122b3465a38 by Martin Panter in branch '3.5': Issue #16182: Fix readline begidx, endidx, and use locale encoding https://hg.python.org/cpython/rev/5122b3465a38 New changeset 2ae2657d87a6 by Martin Panter in branch 'default': Issue #16182: Merge readline locale fix from 3.5 https://hg.python.org/cpython/rev/2ae2657d87a6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 23:03:43 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jun 2016 03:03:43 +0000 Subject: [issue22636] avoid using a shell in ctypes.util: replace os.popen with subprocess In-Reply-To: <1413325975.89.0.175884398711.issue22636@psf.upfronthosting.co.za> Message-ID: <20160614030340.11339.22805.AE13BCDD@psf.io> Roundup Robot added the comment: New changeset 0715d403cae2 by Martin Panter in branch '3.5': Issue #22636: avoid using a shell in the ctypes.util module https://hg.python.org/cpython/rev/0715d403cae2 New changeset 60613ecad578 by Martin Panter in branch 'default': Issue #22636: Merge ctypes.util shell injection fixes from 3.5 https://hg.python.org/cpython/rev/60613ecad578 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 23:03:44 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jun 2016 03:03:44 +0000 Subject: [issue17500] move PC/icons/source.xar to http://www.python.org/community/logos/ In-Reply-To: <1363820002.7.0.633809398541.issue17500@psf.upfronthosting.co.za> Message-ID: <20160614030340.11339.86609.2B886137@psf.io> Roundup Robot added the comment: New changeset d9090aa75607 by Martin Panter in branch 'default': Issue #17500: Remove merge conflict scar tissue https://hg.python.org/cpython/rev/d9090aa75607 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 23:30:59 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 14 Jun 2016 03:30:59 +0000 Subject: [issue22636] avoid using a shell in ctypes.util: replace os.popen with subprocess In-Reply-To: <1413325975.89.0.175884398711.issue22636@psf.upfronthosting.co.za> Message-ID: <1465875059.31.0.828348603609.issue22636@psf.upfronthosting.co.za> Martin Panter added the comment: Updated Py 2 patch to v5 with the added GCC comment ---------- Added file: http://bugs.python.org/file43383/ctypes_util_popen-5.py2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 23:35:49 2016 From: report at bugs.python.org (Larry Hastings) Date: Tue, 14 Jun 2016 03:35:49 +0000 Subject: [issue27314] Cannot install 3.5.2 with 3.6.0a1 installed In-Reply-To: <1465869564.71.0.178376895895.issue27314@psf.upfronthosting.co.za> Message-ID: <1465875349.23.0.621112875831.issue27314@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- nosy: -larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 23:48:18 2016 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 14 Jun 2016 03:48:18 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <1465876098.31.0.986538927891.issue25782@psf.upfronthosting.co.za> Yury Selivanov added the comment: > issue27122_broken_cm.py also shows why I think "make it work" is the right answer here [..] But fixing this issue by reordering the exception chain will only mask bugs that just better to be fixed. And sometimes, this will cause weird exceptions chains, that will make *some* people spend a lot of time debugging/googling to understand what's going on. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 13 23:53:45 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 14 Jun 2016 03:53:45 +0000 Subject: [issue22636] avoid using a shell in ctypes.util: replace os.popen with subprocess In-Reply-To: <1413325975.89.0.175884398711.issue22636@psf.upfronthosting.co.za> Message-ID: <1465876425.01.0.0559998437216.issue22636@psf.upfronthosting.co.za> Martin Panter added the comment: An Open Indiana buildbot failed. The old code let the shell print any errors about missing programs to /dev/null, so I will change the subprocess calls to handle OSError. ====================================================================== ERROR: setUpModule (ctypes.test.test_loading) ---------------------------------------------------------------------- Traceback (most recent call last): File "/export/home/buildbot/32bits/3.5.cea-indiana-x86/build/Lib/ctypes/test/test_loading.py", line 19, in setUpModule libc_name = find_library("c") File "/export/home/buildbot/32bits/3.5.cea-indiana-x86/build/Lib/ctypes/util.py", line 238, in find_library return _get_soname(_findLib_crle(name, is64) or _findLib_gcc(name)) File "/export/home/buildbot/32bits/3.5.cea-indiana-x86/build/Lib/ctypes/util.py", line 145, in _get_soname stderr=subprocess.DEVNULL) File "/export/home/buildbot/32bits/3.5.cea-indiana-x86/build/Lib/subprocess.py", line 947, in __init__ restore_signals, start_new_session) File "/export/home/buildbot/32bits/3.5.cea-indiana-x86/build/Lib/subprocess.py", line 1551, in _execute_child raise child_exception_type(errno_num, err_msg) FileNotFoundError: [Errno 2] No such file or directory: '/usr/ccs/bin/dump' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 00:25:03 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 14 Jun 2016 04:25:03 +0000 Subject: [issue27099] IDLE: turn builting extensions into regular modules In-Reply-To: <1464055360.13.0.626532918919.issue27099@psf.upfronthosting.co.za> Message-ID: <1465878303.26.0.313639940118.issue27099@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Ned, from your response on 20580, there appears to be no conversion rule. Perhap you could go throuch config-main.def and make a list of what you want for Mac and Unix respectively, if different from the current binding. Serhiy, should anything be different for Linux?, or for your Modern Linux? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 00:26:31 2016 From: report at bugs.python.org (Eryk Sun) Date: Tue, 14 Jun 2016 04:26:31 +0000 Subject: [issue27305] Crash with "pip list --outdated" on Windows 10 with Python 2.7.12rc1 In-Reply-To: <1465820074.65.0.989290191732.issue27305@psf.upfronthosting.co.za> Message-ID: <1465878391.71.0.0625153310572.issue27305@psf.upfronthosting.co.za> Eryk Sun added the comment: I get an access violation due to calling the ASN1_ITEM pointer as a function: > 810: ASN1_ITEM_ptr(method->it))); _ssl!_get_peer_alt_names+0x12a: 00007ffe`17b1225a ffd0 call rax {_ssl!GENERAL_NAMES_it (00007ffe`17ca0c20)} 0:000> ?? (ASN1_ITEM *)@rax struct ASN1_ITEM_st * 0x00007ffe`17ca0c20 +0x000 itype : 0 '' +0x004 utype : 0n-1 +0x008 templates : 0x00007ffe`17ca0c00 ASN1_TEMPLATE_st +0x010 tcount : 0n0 +0x018 funcs : (null) +0x020 size : 0n0 +0x028 sname : 0x00007ffe`17cb5bf8 "GENERAL_NAMES" I know very little about OpenSSL or the _ssl module, but I think the default on Windows is to define OPENSSL_EXPORT_VAR_AS_FUNCTION, in which case: /* * Platforms that can't easily handle shared global variables * are declared as functions returning ASN1_ITEM pointers. */ /* Macro to obtain ASN1_ITEM pointer from exported type */ # define ASN1_ITEM_ptr(iptr) (iptr()) The 2.7.10 build uses a function pointer: > 810: ASN1_ITEM_ptr(method->it))); _ssl!_get_peer_alt_names+0xe8: 00000000`02681c78 ffd0 call rax {_ssl!GENERAL_NAMES_it (00000000`0269a730)} 0:000> u _ssl!GENERAL_NAMES_it l2 _ssl!GENERAL_NAMES_it [c:\build27\cpython\externals\openssl-1.0.2a\ crypto\x509v3\v3_genn.c @ 99]: 00000000`0269a730 488d05b93a1400 lea rax, [_ssl!local_it (00000000`027de1f0)] 00000000`0269a737 c3 ret 0:000> p > 810: ASN1_ITEM_ptr(method->it))); _ssl!_get_peer_alt_names+0xea: 00000000`02681c7a 488d942488080000 lea rdx,[rsp+888h] 0:000> ?? (ASN1_ITEM *)@rax struct ASN1_ITEM_st * 0x00000000`027de1f0 +0x000 itype : 0 '' +0x004 utype : 0n-1 +0x008 templates : 0x00000000`027de1d0 ASN1_TEMPLATE_st +0x010 tcount : 0n0 +0x018 funcs : (null) +0x020 size : 0n0 +0x028 sname : 0x00000000`0284aa30 "GENERAL_NAMES" Except _ssl links to OpenSSL statically, so strictly speaking this shouldn't be necessary. The 3.5 build uses a global variable here instead of a function pointer: > 847: if(!(method = X509V3_EXT_get(ext))) { _ssl_d!_get_peer_alt_names+0xe9: 00007ffe`178398d9 e88faafaff call _ssl_d!ILT+13160(X509V3_EXT_get) (00007ffe`177e436d) 0:000> p > 847: if(!(method = X509V3_EXT_get(ext))) { _ssl_d!_get_peer_alt_names+0xee: 00007ffe`178398de 48898424d8000000 mov qword ptr [rsp+0D8h],rax ss:00000076`f99eabe8= 00007ffe359475b0 0:000> ?? ((X509V3_EXT_METHOD *)@rax)->it struct ASN1_ITEM_st * 0x00007ffe`17a55b10 +0x000 itype : 0 '' +0x004 utype : 0n-1 +0x008 templates : 0x00007ffe`17a55af0 ASN1_TEMPLATE_st +0x010 tcount : 0n0 +0x018 funcs : (null) +0x020 size : 0n0 +0x028 sname : 0x00007ffe`17a55d58 "GENERAL_NAMES" ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 00:35:33 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jun 2016 04:35:33 +0000 Subject: [issue27313] test case failures in test_widgets.ComboboxTest.of test_ttk_guionly on OS X with Cocoa Tk 8.5.18 In-Reply-To: <1465866380.0.0.570463827001.issue27313@psf.upfronthosting.co.za> Message-ID: <1465878933.78.0.660249650196.issue27313@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: These tests are not new. Are failures stable? What version of Tk is used? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 00:36:18 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 14 Jun 2016 04:36:18 +0000 Subject: [issue27136] sock_connect fails for bluetooth (and probably others) In-Reply-To: <1464346938.98.0.196127839357.issue27136@psf.upfronthosting.co.za> Message-ID: <1465878978.79.0.488918045517.issue27136@psf.upfronthosting.co.za> Martin Panter added the comment: Buildbots look happy with test_asyncio now, so closing again. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 00:36:35 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jun 2016 04:36:35 +0000 Subject: [issue27313] test case failures in test_widgets.ComboboxTest.of test_ttk_guionly on OS X with Cocoa Tk 8.5.18 In-Reply-To: <1465866380.0.0.570463827001.issue27313@psf.upfronthosting.co.za> Message-ID: <1465878995.14.0.481964306554.issue27313@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ah, sorry, I missed the version in the title. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 00:40:33 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jun 2016 04:40:33 +0000 Subject: [issue22636] avoid using a shell in ctypes.util: replace os.popen with subprocess In-Reply-To: <1413325975.89.0.175884398711.issue22636@psf.upfronthosting.co.za> Message-ID: <20160614044030.20039.69116.1CD72192@psf.io> Roundup Robot added the comment: New changeset 96d297e9a8a8 by Martin Panter in branch '3.5': Issue #22636: Handle OSError from subprocess, e.g. if command not found https://hg.python.org/cpython/rev/96d297e9a8a8 New changeset a6a36bb6ee50 by Martin Panter in branch 'default': Issue #22636: Merge ctypes.util from 3.5 https://hg.python.org/cpython/rev/a6a36bb6ee50 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 00:47:09 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 14 Jun 2016 04:47:09 +0000 Subject: [issue27099] IDLE: turn builting extensions into regular modules In-Reply-To: <1464055360.13.0.626532918919.issue27099@psf.upfronthosting.co.za> Message-ID: <1465879629.28.0.317504045975.issue27099@psf.upfronthosting.co.za> Ned Deily added the comment: Terry, I don't know that much about the history of the config files. I do know that during framework installs of Python on OS X, the "install_IDLE" recipe in Mac/Makefile.in (which ./configure uses to produce a configured Mac/Makefile) has some editing steps, using sed, to alter the IDLE .def files as they are being installed. I'm attaching the two edited .def files as installed by the OS X installer. And then there's the runtime munging of "Alt-" to "Option-" in GetCurrentKeySet() of idlelib/config.py. ---------- Added file: http://bugs.python.org/file43384/config-extensions.def _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 00:47:44 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 14 Jun 2016 04:47:44 +0000 Subject: [issue27099] IDLE: turn builting extensions into regular modules In-Reply-To: <1464055360.13.0.626532918919.issue27099@psf.upfronthosting.co.za> Message-ID: <1465879664.34.0.276818027294.issue27099@psf.upfronthosting.co.za> Changes by Ned Deily : Added file: http://bugs.python.org/file43385/config-main.def _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 00:54:06 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jun 2016 04:54:06 +0000 Subject: [issue27245] IDLE: Fix deletion of custom themes and key bindings In-Reply-To: <1465263632.45.0.499678988052.issue27245@psf.upfronthosting.co.za> Message-ID: <20160614045402.101877.2002.44009CB1@psf.io> Roundup Robot added the comment: New changeset 5c8cddc4a8ee by Terry Jan Reedy in branch '2.7': Issue #27245: IDLE: Cleanly delete custom themes and key bindings. https://hg.python.org/cpython/rev/5c8cddc4a8ee New changeset 438359d00a83 by Terry Jan Reedy in branch '3.5': Issue #27245: IDLE: Cleanly delete custom themes and key bindings. https://hg.python.org/cpython/rev/438359d00a83 New changeset 7948633608d5 by Terry Jan Reedy in branch 'default': Issue #27245: temporary rename for merge. https://hg.python.org/cpython/rev/7948633608d5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 00:55:27 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jun 2016 04:55:27 +0000 Subject: [issue27245] IDLE: Fix deletion of custom themes and key bindings In-Reply-To: <1465263632.45.0.499678988052.issue27245@psf.upfronthosting.co.za> Message-ID: <20160614045524.101877.41600.64C29BFA@psf.io> Roundup Robot added the comment: New changeset 3ac9e7466d8b by Terry Jan Reedy in branch 'default': Issue #27245: revert temporary rename https://hg.python.org/cpython/rev/3ac9e7466d8b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 01:00:26 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 14 Jun 2016 05:00:26 +0000 Subject: [issue27313] test case failures in test_widgets.ComboboxTest.of test_ttk_guionly on OS X with Cocoa Tk 8.5.18 In-Reply-To: <1465866380.0.0.570463827001.issue27313@psf.upfronthosting.co.za> Message-ID: <1465880426.81.0.828681947889.issue27313@psf.upfronthosting.co.za> Ned Deily added the comment: For example, the tests pass in 3.5.1 but fail in 3.5.2rc1. I see that the changesets associated with Issue26177 altered them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 01:00:40 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 14 Jun 2016 05:00:40 +0000 Subject: [issue27245] IDLE: Fix deletion of custom themes and key bindings In-Reply-To: <1465263632.45.0.499678988052.issue27245@psf.upfronthosting.co.za> Message-ID: <1465880440.29.0.213272094067.issue27245@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Patch amounts to putting 3 lines of apply inline and moving the first up to where is it needed. Serhiy, thanks for discovering the simple fix. It worked for me so I pushed it. I backported because the cascade of error messages is nasty when visible and because the forward merge was easy enough now that I know about the case clash problem. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 01:50:29 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 14 Jun 2016 05:50:29 +0000 Subject: [issue16182] readline: Wrong tab completion scope indices in Unicode terminals In-Reply-To: <1349813384.06.0.615857426211.issue16182@psf.upfronthosting.co.za> Message-ID: <1465883429.05.0.401048093972.issue16182@psf.upfronthosting.co.za> Martin Panter added the comment: Failures from AMD64 Snow Leop buildbots: ====================================================================== FAIL: test_nonascii_history (test.test_readline.TestHistoryManipulation) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/buildbot/buildarea/3.5.murray-snowleopard/build/Lib/test/test_readline.py", line 102, in test_nonascii_history self.assertEqual(readline.get_history_item(1), "entr?e 1") AssertionError: None != 'entr?e 1' ====================================================================== FAIL: test_nonascii (test.test_readline.TestReadline) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/buildbot/buildarea/3.5.murray-snowleopard/build/Lib/test/test_readline.py", line 174, in test_nonascii self.assertIn(b"line '[\\xefnserted]|t\\xeb[after]'\r\n", output) AssertionError: b"line '[\\xefnserted]|t\\xeb[after]'\r\n" not found in bytearray(b"^A^B^B^B^B^B^B^B\t\tx\t\r\n|t\xc3\xab[after]\x08\x08\x08\x08\x08\x08\x08text \'t\\xeb\'\r\nline \'|t\\xeb[after]\'\r\nindexes 1 3\r\n\x07text \'t\\xeb\'\r\nline \'|t\\xeb[after]\'\r\nindexes 1 3\r\n\r\nt\xc3\xabxt t\xc3\xabnt \r\n\r\r\n|t\xc3\xab[after]\r|t\xc3\xabx[after]\r|t\xc3\xabxt[after]\r|t\xc3\xabxt\r\nresult \'|t\\xebxt[after]\'\r\nhistory \'|t\\xebxt[after]\'\r\n") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 01:51:15 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jun 2016 05:51:15 +0000 Subject: [issue16182] readline: Wrong tab completion scope indices in Unicode terminals In-Reply-To: <1349813384.06.0.615857426211.issue16182@psf.upfronthosting.co.za> Message-ID: <20160614055112.25983.7937.8EFA1DB5@psf.io> Roundup Robot added the comment: New changeset 0794bbfceec6 by Martin Panter in branch '3.5': Issue #16182: Attempted workarounds for Apple Editline https://hg.python.org/cpython/rev/0794bbfceec6 New changeset a1ca9c0ebc05 by Martin Panter in branch 'default': Issue #16182: Merge test_readline from 3.5 https://hg.python.org/cpython/rev/a1ca9c0ebc05 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 02:27:53 2016 From: report at bugs.python.org (Matthias Klose) Date: Tue, 14 Jun 2016 06:27:53 +0000 Subject: [issue27315] pydoc: prefer the pager command in favor of the specifc less command Message-ID: <1465885673.67.0.270326980861.issue27315@psf.upfronthosting.co.za> New submission from Matthias Klose: pydoc: prefer the pager command in favor of the specifc less command. the pager command on Debian/Ubuntu systems is an alternative which is provided by specific pagers like less or more. References: http://unix.stackexchange.com/questions/5383/which-systems-have-pager-shortcut-alias ---------- components: Library (Lib) files: pydoc-use-pager.diff keywords: patch messages: 268524 nosy: doko priority: low severity: normal status: open title: pydoc: prefer the pager command in favor of the specifc less command versions: Python 2.7, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43386/pydoc-use-pager.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 02:38:59 2016 From: report at bugs.python.org (Matthias Klose) Date: Tue, 14 Jun 2016 06:38:59 +0000 Subject: [issue8637] Add MANPAGER envvar to specify pager for pydoc In-Reply-To: <1273160026.83.0.741000260603.issue8637@psf.upfronthosting.co.za> Message-ID: <1465886339.28.0.704743909763.issue8637@psf.upfronthosting.co.za> Matthias Klose added the comment: adding MANPAGER, with the simpler logic. ---------- nosy: +doko title: Add PYDOCPAGER envvar to specify pager for pydoc -> Add MANPAGER envvar to specify pager for pydoc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 02:39:46 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jun 2016 06:39:46 +0000 Subject: [issue8637] Add MANPAGER envvar to specify pager for pydoc In-Reply-To: <1273160026.83.0.741000260603.issue8637@psf.upfronthosting.co.za> Message-ID: <20160614063941.27933.8189.1E97F4CE@psf.io> Roundup Robot added the comment: New changeset 820d21c97d66 by doko in branch 'default': - Issue #8637: Honor a pager set by the env var MANPAGER (in preference to https://hg.python.org/cpython/rev/820d21c97d66 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 02:40:45 2016 From: report at bugs.python.org (Matthias Klose) Date: Tue, 14 Jun 2016 06:40:45 +0000 Subject: [issue8637] Add MANPAGER envvar to specify pager for pydoc In-Reply-To: <1273160026.83.0.741000260603.issue8637@psf.upfronthosting.co.za> Message-ID: <1465886445.08.0.60748899941.issue8637@psf.upfronthosting.co.za> Matthias Klose added the comment: fixed for 3.6.0a3 ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 02:55:33 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jun 2016 06:55:33 +0000 Subject: [issue23968] rename the platform directory from plat-$(MACHDEP) to plat-$(PLATFORM_TRIPLET) In-Reply-To: <1429124647.47.0.946423694262.issue23968@psf.upfronthosting.co.za> Message-ID: <20160614065529.114454.64698.E0D4DEC2@psf.io> Roundup Robot added the comment: New changeset 78d2cb7f66b6 by doko in branch 'default': - Issue #23968: Rename the platform directory from plat-$(MACHDEP) to https://hg.python.org/cpython/rev/78d2cb7f66b6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 02:55:45 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 14 Jun 2016 06:55:45 +0000 Subject: [issue8637] Add MANPAGER envvar to specify pager for pydoc In-Reply-To: <1273160026.83.0.741000260603.issue8637@psf.upfronthosting.co.za> Message-ID: <1465887345.84.0.0502591405019.issue8637@psf.upfronthosting.co.za> Martin Panter added the comment: Matthias: your change causes pydoc to raise KeyError if I set MANPAGER but not PAGER. I?m guessing you intended something else? ---------- nosy: +martin.panter versions: +Python 3.6 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 02:57:27 2016 From: report at bugs.python.org (Matthias Klose) Date: Tue, 14 Jun 2016 06:57:27 +0000 Subject: [issue23968] rename the platform directory from plat-$(MACHDEP) to plat-$(PLATFORM_TRIPLET) In-Reply-To: <1429124647.47.0.946423694262.issue23968@psf.upfronthosting.co.za> Message-ID: <1465887447.95.0.470036182392.issue23968@psf.upfronthosting.co.za> Matthias Klose added the comment: now checked in, after 3.6.0a2, to watch behaviour on different platforms. Still needs doc updates. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 02:58:41 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jun 2016 06:58:41 +0000 Subject: [issue27313] test case failures in test_widgets.ComboboxTest.of test_ttk_guionly on OS X with Cocoa Tk 8.5.18 In-Reply-To: <1465866380.0.0.570463827001.issue27313@psf.upfronthosting.co.za> Message-ID: <1465887521.37.0.575712813194.issue27313@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Are there failures if run tests separately? $ ./python -m test -vu gui -m test_identify test_ttk_guionly If no, could you please find a test running before test_identify or test_virtual_event that provokes a failure? I can't reproduce failures on Linux. Needed help of Mac user for investigating this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 03:04:05 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jun 2016 07:04:05 +0000 Subject: [issue8637] Add MANPAGER envvar to specify pager for pydoc In-Reply-To: <1273160026.83.0.741000260603.issue8637@psf.upfronthosting.co.za> Message-ID: <20160614070400.81084.12837.AE6AAE81@psf.io> Roundup Robot added the comment: New changeset dea9f9b5582b by doko in branch 'default': - Issue #8637: Honor a pager set by the env var MANPAGER (in preference to https://hg.python.org/cpython/rev/dea9f9b5582b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 03:04:33 2016 From: report at bugs.python.org (Matthias Klose) Date: Tue, 14 Jun 2016 07:04:33 +0000 Subject: [issue8637] Add MANPAGER envvar to specify pager for pydoc In-Reply-To: <1273160026.83.0.741000260603.issue8637@psf.upfronthosting.co.za> Message-ID: <1465887873.65.0.508200005447.issue8637@psf.upfronthosting.co.za> Matthias Klose added the comment: sorry, updated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 03:05:47 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 14 Jun 2016 07:05:47 +0000 Subject: [issue8637] Add MANPAGER envvar to specify pager for pydoc In-Reply-To: <1273160026.83.0.741000260603.issue8637@psf.upfronthosting.co.za> Message-ID: <1465887947.02.0.445509094093.issue8637@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks, that version looks more sensible ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 03:12:10 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 14 Jun 2016 07:12:10 +0000 Subject: [issue27313] test case failures in test_widgets.ComboboxTest.of test_ttk_guionly on OS X with Cocoa Tk 8.5.18 In-Reply-To: <1465866380.0.0.570463827001.issue27313@psf.upfronthosting.co.za> Message-ID: <1465888330.58.0.0638379762036.issue27313@psf.upfronthosting.co.za> Ned Deily added the comment: test_ttk_guionly runs test_identify, doesn't it? (I'll try to take a look at it later when I have more time.) $ /usr/local/bin/python3.5 -m test -vu gui test_ttk_guionly == CPython 3.5.2rc1 (v3.5.2rc1:68feec6488b2, Jun 11 2016, 21:59:53) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] == Darwin-15.5.0-x86_64-i386-64bit little-endian == hash algorithm: siphash24 64bit Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0) [1/1] test_ttk_guionly test_horizontal_range (tkinter.test.test_ttk.test_extensions.LabeledScaleTest) ... ok test_initialization (tkinter.test.test_ttk.test_extensions.LabeledScaleTest) ... ok test_initialization_no_master (tkinter.test.test_ttk.test_extensions.LabeledScaleTest) ... ok test_resize (tkinter.test.test_ttk.test_extensions.LabeledScaleTest) ... ok test_variable_change (tkinter.test.test_ttk.test_extensions.LabeledScaleTest) ... ok test_widget_destroy (tkinter.test.test_ttk.test_extensions.LabeledScaleTest) ... ok test_initialization (tkinter.test.test_ttk.test_extensions.OptionMenuTest) ... ok test_menu (tkinter.test.test_ttk.test_extensions.OptionMenuTest) ... ok test_widget_destroy (tkinter.test.test_ttk.test_extensions.OptionMenuTest) ... ok test_configure (tkinter.test.test_ttk.test_style.StyleTest) ... ok test_layout (tkinter.test.test_ttk.test_style.StyleTest) ... ok test_lookup (tkinter.test.test_ttk.test_style.StyleTest) ... ok test_map (tkinter.test.test_ttk.test_style.StyleTest) ... ok test_theme_use (tkinter.test.test_ttk.test_style.StyleTest) ... ok patchlevel = 8.5.18 [...] test_foreground (tkinter.test.test_ttk.test_widgets.ComboboxTest) ... ok test_height (tkinter.test.test_ttk.test_widgets.ComboboxTest) ... ok test_identify (tkinter.test.test_ttk.test_widgets.ComboboxTest) ... FAIL test_invalidcommand (tkinter.test.test_ttk.test_widgets.ComboboxTest) ... ok test_justify (tkinter.test.test_ttk.test_widgets.ComboboxTest) ... ok test_keys (tkinter.test.test_ttk.test_widgets.ComboboxTest) ... ok test_postcommand (tkinter.test.test_ttk.test_widgets.ComboboxTest) ... ok [...] test_validatecommand (tkinter.test.test_ttk.test_widgets.ComboboxTest) ... ok test_validation (tkinter.test.test_ttk.test_widgets.ComboboxTest) ... ok test_validation_options (tkinter.test.test_ttk.test_widgets.ComboboxTest) ... ok test_values (tkinter.test.test_ttk.test_widgets.ComboboxTest) ... ok test_virtual_event (tkinter.test.test_ttk.test_widgets.ComboboxTest) ... FAIL test_width (tkinter.test.test_ttk.test_widgets.ComboboxTest) ... ok test_xscrollcommand (tkinter.test.test_ttk.test_widgets.ComboboxTest) ... ok test_background (tkinter.test.test_ttk.test_widgets.EntryTest) ... ok [...] test_identify (tkinter.test.test_ttk.test_widgets.WidgetTest) ... ok test_widget_state (tkinter.test.test_ttk.test_widgets.WidgetTest) ... ok ====================================================================== FAIL: test_identify (tkinter.test.test_ttk.test_widgets.ComboboxTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/tkinter/test/test_ttk/test_widgets.py", line 332, in test_identify self.assertEqual(self.entry.identify(5, 5), "textarea") AssertionError: 'Combobox.button' != 'textarea' - Combobox.button + textarea ====================================================================== FAIL: test_virtual_event (tkinter.test.test_ttk.test_widgets.ComboboxTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/tkinter/test/test_ttk/test_widgets.py", line 455, in test_virtual_event self.assertTrue(success) AssertionError: [] is not true ---------------------------------------------------------------------- Ran 271 tests in 3.242s FAILED (failures=2, skipped=11) test test_ttk_guionly failed 1 test failed: test_ttk_guionly ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 03:22:55 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jun 2016 07:22:55 +0000 Subject: [issue23968] rename the platform directory from plat-$(MACHDEP) to plat-$(PLATFORM_TRIPLET) In-Reply-To: <1429124647.47.0.946423694262.issue23968@psf.upfronthosting.co.za> Message-ID: <20160614072224.11591.94579.B4D5CC8A@psf.io> Roundup Robot added the comment: New changeset a062c60c9f7d by doko in branch 'default': - Issue #23968: Update distutils/sysconfig.py to look for the renamed https://hg.python.org/cpython/rev/a062c60c9f7d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 03:31:14 2016 From: report at bugs.python.org (Martin Altmayer) Date: Tue, 14 Jun 2016 07:31:14 +0000 Subject: [issue26923] asyncio.gather drops cancellation In-Reply-To: <1462279806.1.0.880381545595.issue26923@psf.upfronthosting.co.za> Message-ID: <1465889474.93.0.438957112466.issue26923@psf.upfronthosting.co.za> Martin Altmayer added the comment: I don't think this is a mere documentation problem: If a future cannot be cancelled because it is already done, cancel must return False. As Johannes' example demonstrates, a wrong return value from cancel might lead to a cancelled task being continued as if nothing happened: If Task.cancel receives a false positive from its _fut_waiter, it will not throw a CancelledError into the task (_must_cancel=True), but simply continue the task. ---------- nosy: +MartinAltmayer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 03:40:48 2016 From: report at bugs.python.org (Diaa Jad) Date: Tue, 14 Jun 2016 07:40:48 +0000 Subject: [issue27316] [PDB] NameError in list comprehension in PDB Message-ID: <1465890048.43.0.679878829802.issue27316@psf.upfronthosting.co.za> Changes by Diaa Jad : ---------- components: Extension Modules nosy: Diaa Jad priority: normal severity: normal status: open title: [PDB] NameError in list comprehension in PDB type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 03:41:51 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 14 Jun 2016 07:41:51 +0000 Subject: [issue27315] pydoc: prefer the pager command in favor of the specifc less command In-Reply-To: <1465885673.67.0.270326980861.issue27315@psf.upfronthosting.co.za> Message-ID: <1465890111.37.0.47712714637.issue27315@psf.upfronthosting.co.za> Martin Panter added the comment: Does Debian use PAGER or MANPAGER? What?s the advantage of the ?pager? command in addition? ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 03:44:00 2016 From: report at bugs.python.org (Diaa Jad) Date: Tue, 14 Jun 2016 07:44:00 +0000 Subject: [issue27316] [PDB] NameError in list comprehension in PDB Message-ID: <1465890240.51.0.176817661428.issue27316@psf.upfronthosting.co.za> Changes by Diaa Jad : ---------- components: +Library (Lib) -Extension Modules _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 03:46:27 2016 From: report at bugs.python.org (Diaa Jad) Date: Tue, 14 Jun 2016 07:46:27 +0000 Subject: [issue27316] [PDB] NameError in list comprehension in PDB Message-ID: <1465890387.77.0.82038148147.issue27316@psf.upfronthosting.co.za> New submission from Diaa Jad: This code fails in the python debugger: (Pdb) z = True (Pdb) p [x for x in [1,2] if z] *** NameError: name 'z' is not defined While the same code works in the interactive shell: >>> [x for x in [1,2] if z] [1, 2] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 03:47:39 2016 From: report at bugs.python.org (Matthias Klose) Date: Tue, 14 Jun 2016 07:47:39 +0000 Subject: [issue27315] pydoc: prefer the pager command in favor of the specifc less command In-Reply-To: <1465885673.67.0.270326980861.issue27315@psf.upfronthosting.co.za> Message-ID: <1465890459.52.0.672042414187.issue27315@psf.upfronthosting.co.za> Matthias Klose added the comment: Debian prefers to set these defaults without relying on env vars. There is no env var set by default. /etc/security/pam_env.conf:# be useful to be set: NNTPSERVER, LESS, PATH, PAGER, MANPAGER ..... /etc/security/pam_env.conf:#PAGER DEFAULT=less /etc/security/pam_env.conf:#MANPAGER DEFAULT=less ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 04:00:21 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 14 Jun 2016 08:00:21 +0000 Subject: [issue16182] readline: Wrong tab completion scope indices in Unicode terminals In-Reply-To: <1349813384.06.0.615857426211.issue16182@psf.upfronthosting.co.za> Message-ID: <1465891221.23.0.292747459703.issue16182@psf.upfronthosting.co.za> Martin Panter added the comment: Also need a fix for missing set_pre_input_hook() on the AIX buildbot: ====================================================================== FAIL: test_nonascii (test.test_readline.TestReadline) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/shager/cpython-buildarea/3.5.edelsohn-aix-ppc64/build/Lib/test/test_readline.py", line 173, in test_nonascii self.assertIn(b"text 't\\xeb'\r\n", output) AssertionError: b"text 't\\xeb'\r\n" not found in bytearray(b'\x01\x02\x02\x02\x02\x02\x02\x02 x \r\n\x1b[?1034hTraceback (most recent call last):\r\n File "", line 18, in \r\nAttributeError: module \'readline\' has no attribute \'set_pre_input_hook\'\r\n') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 04:12:25 2016 From: report at bugs.python.org (SilentGhost) Date: Tue, 14 Jun 2016 08:12:25 +0000 Subject: [issue27316] [PDB] NameError in list comprehension in PDB In-Reply-To: <1465890387.77.0.82038148147.issue27316@psf.upfronthosting.co.za> Message-ID: <1465891945.72.0.077310369339.issue27316@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +georg.brandl type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 04:18:46 2016 From: report at bugs.python.org (SilentGhost) Date: Tue, 14 Jun 2016 08:18:46 +0000 Subject: [issue27316] [PDB] NameError in list comprehension in PDB In-Reply-To: <1465890387.77.0.82038148147.issue27316@psf.upfronthosting.co.za> Message-ID: <1465892326.64.0.634503518661.issue27316@psf.upfronthosting.co.za> SilentGhost added the comment: I cannot reproduce this issue on 3.5, do you have a chance to test this on a 3.5 or some other version of python? Also, could you provide any more details of your system? ---------- nosy: +SilentGhost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 04:59:47 2016 From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=) Date: Tue, 14 Jun 2016 08:59:47 +0000 Subject: [issue1927] Change input() to always prompt to stderr In-Reply-To: <1201206078.95.0.997961854688.issue1927@psf.upfronthosting.co.za> Message-ID: <1465894787.49.0.280488336054.issue1927@psf.upfronthosting.co.za> Adam Barto? added the comment: Regarding the comment by Martin Panter from 2015-11-22: It would be nice if PyOS_StdioReadline worked that way. Unfortunately, it's still based on C file objects and char* for the prompt string rather than using actual Python objects. The relevant issue is issue17620 . ---------- nosy: +Drekin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 05:01:07 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 14 Jun 2016 09:01:07 +0000 Subject: [issue24363] httplib fails to handle semivalid HTTP headers In-Reply-To: <1433257563.79.0.772954216205.issue24363@psf.upfronthosting.co.za> Message-ID: <1465894867.94.0.515401990831.issue24363@psf.upfronthosting.co.za> Martin Panter added the comment: I made a patch to fix all header section parsing by default in the email module (see Issue 26686). I?m not 100% sure if it is safe in general, but if it is, it would fix this bug. ---------- dependencies: +email.parser stops parsing headers too soon. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 05:02:09 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jun 2016 09:02:09 +0000 Subject: [issue16182] readline: Wrong tab completion scope indices in Unicode terminals In-Reply-To: <1349813384.06.0.615857426211.issue16182@psf.upfronthosting.co.za> Message-ID: <20160614090204.101686.67460.F47E7B53@psf.io> Roundup Robot added the comment: New changeset 005cab4f5629 by Martin Panter in branch '3.5': Issue #16182: set_pre_input_hook() may not exist; document, and update test https://hg.python.org/cpython/rev/005cab4f5629 New changeset c4dd384ee3fa by Martin Panter in branch 'default': Issue #16182: Merge readline update from 3.5 https://hg.python.org/cpython/rev/c4dd384ee3fa New changeset cff695a0b449 by Martin Panter in branch '2.7': Issue #16182: Backport documentation of set_pre_input_hook() availability https://hg.python.org/cpython/rev/cff695a0b449 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 05:46:28 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jun 2016 09:46:28 +0000 Subject: [issue27270] 'parentheses-equality' warnings when building with clang and ccache In-Reply-To: <1465415263.12.0.159795814979.issue27270@psf.upfronthosting.co.za> Message-ID: <20160614094621.81140.33587.07687642@psf.io> Roundup Robot added the comment: New changeset 18e960f930ab by Xavier de Gaye in branch 'default': Issue #27270: `parentheses-equality` warnings when building with clang and ccache. https://hg.python.org/devguide/rev/18e960f930ab ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 05:46:48 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jun 2016 09:46:48 +0000 Subject: [issue26386] tkinter - Treeview - .selection_add and selection_toggle In-Reply-To: <1455813008.22.0.795281140329.issue26386@psf.upfronthosting.co.za> Message-ID: <20160614094642.87676.97694.49FCA6E8@psf.io> Roundup Robot added the comment: New changeset 0885477fecfd by Serhiy Storchaka in branch '3.5': Issue #26386: Fixed ttk.TreeView selection operations with item id's https://hg.python.org/cpython/rev/0885477fecfd New changeset d1c0bc1d0625 by Serhiy Storchaka in branch 'default': Issue #26386: Fixed ttk.TreeView selection operations with item id's https://hg.python.org/cpython/rev/d1c0bc1d0625 New changeset ac7c10f5e36e by Serhiy Storchaka in branch '2.7': Issue #26386: Fixed ttk.TreeView selection operations with item id's https://hg.python.org/cpython/rev/ac7c10f5e36e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 05:48:02 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 14 Jun 2016 09:48:02 +0000 Subject: [issue27270] 'parentheses-equality' warnings when building with clang and ccache In-Reply-To: <1465415263.12.0.159795814979.issue27270@psf.upfronthosting.co.za> Message-ID: <1465897682.56.0.263555680284.issue27270@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 05:56:14 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 14 Jun 2016 09:56:14 +0000 Subject: [issue22636] avoid using a shell in ctypes.util: replace os.popen with subprocess In-Reply-To: <1413325975.89.0.175884398711.issue22636@psf.upfronthosting.co.za> Message-ID: <1465898174.53.0.19062230602.issue22636@psf.upfronthosting.co.za> Martin Panter added the comment: Updated Py 2 patch to handle OSError when shell=True is not used ---------- Added file: http://bugs.python.org/file43387/ctypes_util_popen-6.py2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 06:16:54 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 14 Jun 2016 10:16:54 +0000 Subject: [issue26862] android: SYS_getdents64 does not need to be defined on android API 21 In-Reply-To: <1461678588.46.0.828463582716.issue26862@psf.upfronthosting.co.za> Message-ID: <1465899414.67.0.781350486225.issue26862@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- assignee: -> xdegaye stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 07:37:20 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jun 2016 11:37:20 +0000 Subject: [issue16182] readline: Wrong tab completion scope indices in Unicode terminals In-Reply-To: <1349813384.06.0.615857426211.issue16182@psf.upfronthosting.co.za> Message-ID: <20160614113716.11339.76992.E59DF02E@psf.io> Roundup Robot added the comment: New changeset ef234a5c5817 by Martin Panter in branch '3.5': Issue #16182: One more check for set_pre_input_hook() https://hg.python.org/cpython/rev/ef234a5c5817 New changeset 241bae60cef8 by Martin Panter in branch 'default': Issue #16182: Merge test_readline from 3.5 https://hg.python.org/cpython/rev/241bae60cef8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 07:40:59 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 14 Jun 2016 11:40:59 +0000 Subject: [issue26862] android: SYS_getdents64 does not need to be defined on android API 21 In-Reply-To: <1461678588.46.0.828463582716.issue26862@psf.upfronthosting.co.za> Message-ID: <1465904459.3.0.225500214966.issue26862@psf.upfronthosting.co.za> STINNER Victor added the comment: Stefan Krah: "posixmodule_3.patch looks good to me. Gregory has already approved the approach, so I think you can go ahead and commit this" I concur with Stefan: LGTM. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 07:49:30 2016 From: report at bugs.python.org (Sylvain Corlay) Date: Tue, 14 Jun 2016 11:49:30 +0000 Subject: [issue27317] Handling data_files: too much is removed in uninstall Message-ID: <1465904970.17.0.774152551079.issue27317@psf.upfronthosting.co.za> New submission from Sylvain Corlay: When specifying an empty list for the list of data_files in a given directory, the entire directory is being deleted on uninstall of the wheel, even if it contained other resources. Example: ``` from setuptools import setup setup(name='remover', data_files=[('share/plugins', [])]) ``` The expected behavior is that only the specified list of files is removed, (which is empty in that case). When the list is not empty, the behavior is the one expected. For example ``` from setuptools import setup setup(name='remover', data_files=[('share/plugins', ['foobar.json'])]) ``` will only remove `foobar.json` on uninstall and the `plugins` directory will not be removed if it is not empty. ---------- components: Distutils messages: 268551 nosy: dstufft, eric.araujo, sylvain.corlay priority: normal severity: normal status: open title: Handling data_files: too much is removed in uninstall type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 07:55:34 2016 From: report at bugs.python.org (=?utf-8?b?THVrw6HFoSBEb2t0b3I=?=) Date: Tue, 14 Jun 2016 11:55:34 +0000 Subject: [issue27318] Add support for symlinks to zipfile Message-ID: <1465905334.15.0.513827452466.issue27318@psf.upfronthosting.co.za> New submission from Luk?? Doktor: Currently the zipfile library extracts all files as simple files, even though it contains the information of the file attributes. This patch uses them to detect if the original file was a symlink and creates it when there is a support for symlink creation. ---------- components: Library (Lib) files: zipfile-symlink.patch keywords: patch messages: 268552 nosy: ldoktor priority: normal severity: normal status: open title: Add support for symlinks to zipfile type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file43388/zipfile-symlink.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 08:08:40 2016 From: report at bugs.python.org (SilentGhost) Date: Tue, 14 Jun 2016 12:08:40 +0000 Subject: [issue27318] Add support for symlinks to zipfile In-Reply-To: <1465905334.15.0.513827452466.issue27318@psf.upfronthosting.co.za> Message-ID: <1465906120.32.0.0420693299607.issue27318@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +alanmcintyre, serhiy.storchaka, twouters versions: +Python 3.6 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 08:25:21 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jun 2016 12:25:21 +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: <20160614122516.19970.81055.8B7D8AA0@psf.io> Roundup Robot added the comment: New changeset 2126e8cbc12f by Berker Peksag in branch 'default': Issue #16864: Cursor.lastrowid now supports REPLACE statement https://hg.python.org/cpython/rev/2126e8cbc12f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 08:26:00 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 14 Jun 2016 12:26: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: <1465907160.82.0.126250736247.issue16864@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch, Alex. ---------- nosy: +berker.peksag resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 08:53:48 2016 From: report at bugs.python.org (Larry Hastings) Date: Tue, 14 Jun 2016 12:53:48 +0000 Subject: [issue25843] code_richcompare() don't use constant type when comparing code constants In-Reply-To: <1449861793.94.0.13967463155.issue25843@psf.upfronthosting.co.za> Message-ID: <1465908828.28.0.404753764892.issue25843@psf.upfronthosting.co.za> Larry Hastings added the comment: Someone asked on reddit. The Misc/NEWS entry for this reads: Issue #25843: When compiling code, don?t merge constants if they are equal but have a different types. For example, f1, f2 = lambda: 1, lambda: 1.0 is now correctly compiled to two different functions: f1() returns 1 (int) and f2() returns 1.0 (int), even if 1 and 1.0 are equal. Shouldn't that last part read "and f2() returns 1.0 (float), even if 1 and 1.0 are equal." ^^^^^ As in, f2 returns a float, not an int. If this is a mistake, let me fix it for 3.5.2 final and I'll merge it back into trunk etc. If you fix it it wouldn't ship in 3.5.2 final. ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 09:05:47 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jun 2016 13:05:47 +0000 Subject: [issue25843] code_richcompare() don't use constant type when comparing code constants In-Reply-To: <1449861793.94.0.13967463155.issue25843@psf.upfronthosting.co.za> Message-ID: <20160614130535.99198.32512.45EC59A8@psf.io> Roundup Robot added the comment: New changeset a36238de31ae by Victor Stinner in branch '3.5': Issue #25843: Fix the NEWS entry https://hg.python.org/cpython/rev/a36238de31ae ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 09:06:03 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 14 Jun 2016 13:06:03 +0000 Subject: [issue25843] code_richcompare() don't use constant type when comparing code constants In-Reply-To: <1449861793.94.0.13967463155.issue25843@psf.upfronthosting.co.za> Message-ID: <1465909563.78.0.0220110566862.issue25843@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, I fixed the typo in the Misc/NEWS in 3.5 and default branches. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 10:04:15 2016 From: report at bugs.python.org (Andrea De Pasquale) Date: Tue, 14 Jun 2016 14:04:15 +0000 Subject: [issue27010] email library could "recover" from bad mime boundary like (some?) email clients do In-Reply-To: <1463067718.45.0.558318505018.issue27010@psf.upfronthosting.co.za> Message-ID: <1465913055.49.0.326914857588.issue27010@psf.upfronthosting.co.za> Andrea De Pasquale added the comment: Hello, did you have a chance to look at my patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 10:35:09 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jun 2016 14:35:09 +0000 Subject: [issue27278] py_getrandom() uses an int for syscall() result In-Reply-To: <1465458165.91.0.316132030988.issue27278@psf.upfronthosting.co.za> Message-ID: <20160614143358.20202.79512.B886E122@psf.io> Roundup Robot added the comment: New changeset e028e86a5b73 by Victor Stinner in branch '3.5': Fix os.urandom() using getrandom() on Linux https://hg.python.org/cpython/rev/e028e86a5b73 New changeset 0d39bd9028e8 by Victor Stinner in branch 'default': Merge 3.5 (os.urandom, issue #27278) https://hg.python.org/cpython/rev/0d39bd9028e8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 10:37:47 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 14 Jun 2016 14:37:47 +0000 Subject: [issue27278] py_getrandom() uses an int for syscall() result In-Reply-To: <1465458165.91.0.316132030988.issue27278@psf.upfronthosting.co.za> Message-ID: <1465915067.74.0.708303490444.issue27278@psf.upfronthosting.co.za> STINNER Victor added the comment: Martin: What do you think of my change? Is it enough? Or would you prefer an explicit cast on syscall() result? I hesitated to use a wider type since the manual page shows an "int" type, not long. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 10:43:20 2016 From: report at bugs.python.org (Diaa Jad) Date: Tue, 14 Jun 2016 14:43:20 +0000 Subject: [issue27316] [PDB] NameError in list comprehension in PDB In-Reply-To: <1465890387.77.0.82038148147.issue27316@psf.upfronthosting.co.za> Message-ID: <1465915400.76.0.0833542166714.issue27316@psf.upfronthosting.co.za> Diaa Jad added the comment: I actually drop to pdb from nosetests on test failure using --pdb option. I use a Fedora 23 machine. Anyway, it looks like this issue is specific to the virtual environment we use at work that uses version 3.4.4, as I couldn't reproduce it on native 3.4 . As this bug does not show up in the original release I think we can safely close the ticket and I will try to debug the issue locally. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 10:53:27 2016 From: report at bugs.python.org (SilentGhost) Date: Tue, 14 Jun 2016 14:53:27 +0000 Subject: [issue27316] [PDB] NameError in list comprehension in PDB In-Reply-To: <1465890387.77.0.82038148147.issue27316@psf.upfronthosting.co.za> Message-ID: <1465916007.83.0.733011650189.issue27316@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- resolution: -> works for me stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 11:23:20 2016 From: report at bugs.python.org (Eryk Sun) Date: Tue, 14 Jun 2016 15:23:20 +0000 Subject: [issue27318] Add support for symlinks to zipfile In-Reply-To: <1465905334.15.0.513827452466.issue27318@psf.upfronthosting.co.za> Message-ID: <1465917800.59.0.105049713065.issue27318@psf.upfronthosting.co.za> Eryk Sun added the comment: os.symlink needs the target_is_directory argument on Windows. Maybe extract() can search for the link target in namelist() to determine if it's a directory (i.e. ends in "/"). Note that the flag gets set automatically if the target exists, so this is only a problem when a link is extracted before the target. Also, I think it should fall back on creating a regular file if os.symlink raises OSError. On Windows this occurs if the user doesn't have SeCreateSymbolicLinkPrivilege. os.symlink raises a plain OSError in this case; no errno/winerror is set. (I don't know why it doesn't simply call CreateSymbolicLink and raise an exception for the last error, which would be ERROR_PRIVILEGE_NOT_HELD.) ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 11:36:15 2016 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 14 Jun 2016 15:36:15 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <1465918575.97.0.350411907333.issue25782@psf.upfronthosting.co.za> Nick Coghlan added the comment: > But fixing this issue by reordering the exception chain will only mask bugs that just better to be fixed. And sometimes, this will cause weird exceptions chains, that will make *some* people spend a lot of time debugging/googling to understand what's going on. Right, but the way to fix that is to figure out a more coherent linearisation strategy (and/or move away from linearisation by allowing __context__ to be a tuple). Both #18861 and the frame annotation idea it spawned in #19585 have some ideas on how we might be able to improve that situation. Adding *yet another* exception to an already confused exception chain isn't likely to make it easier to debug, and may mask the original exception that triggered the misbehaving error handler (entirely defeating the point of adding exception chaining in the first place). I'm not saying Serhiy's patch is the right long term solution - I'm saying I think it's a better short term mitigation measure, since it doesn't lose information the way nulling out the __context__ may do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 11:38:30 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 14 Jun 2016 15:38:30 +0000 Subject: [issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more In-Reply-To: <1464270042.87.0.0233765451432.issue27130@psf.upfronthosting.co.za> Message-ID: <1465918710.83.0.988285282132.issue27130@psf.upfronthosting.co.za> Xiang Zhang added the comment: Hello Martin. I've finished a patch to add 64bit support to zlib. I think it solves the 9 problems you mentioned and let the input and output both be larger than UINT_MAX. Hope you are willing to review and we can move this forward. :) ---------- keywords: +patch Added file: http://bugs.python.org/file43389/64bit_support_for_zlib.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 12:06:12 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 14 Jun 2016 16:06:12 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <1465920372.07.0.0514101367582.issue25782@psf.upfronthosting.co.za> Gregory P. Smith added the comment: I think I'm with Nick on this, the re-ordering fix is the closest to the right thing to do for 3.5 as it at least leaves all exceptions present in the chain. As a more accurate long term fix, it would be great if we could express the tree via tuples in exception context in 3.6 or later. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 12:22:20 2016 From: report at bugs.python.org (Hans-Peter Jansen) Date: Tue, 14 Jun 2016 16:22:20 +0000 Subject: [issue26804] Prioritize lowercase proxy variables in urllib.request In-Reply-To: <1461053909.86.0.0123928931795.issue26804@psf.upfronthosting.co.za> Message-ID: <1465921340.37.0.934845794883.issue26804@psf.upfronthosting.co.za> Hans-Peter Jansen added the comment: In a couple of systems, I have to stick with 3.4. Is there a chance to have this patch in 3.4 as well, if a new release 3.4 is made? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 12:25:00 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jun 2016 16:25:00 +0000 Subject: [issue27123] Allow `install_headers` command to follow specific directory structure In-Reply-To: <1464186275.75.0.908359845764.issue27123@psf.upfronthosting.co.za> Message-ID: <20160614162437.9646.24688.669FD7C4@psf.io> Roundup Robot added the comment: New changeset 9ee36b74b432 by Gregory P. Smith in branch '3.5': Issue #27123: When an exception is raised within the context being https://hg.python.org/cpython/rev/9ee36b74b432 New changeset 9fadeee05880 by Gregory P. Smith in branch 'default': Issue #27123: When an exception is raised within the context being https://hg.python.org/cpython/rev/9fadeee05880 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 12:25:00 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jun 2016 16:25:00 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <20160614162436.9646.84822.BDABC7CF@psf.io> Roundup Robot added the comment: New changeset 9ee36b74b432 by Gregory P. Smith in branch '3.5': Issue #27123: When an exception is raised within the context being https://hg.python.org/cpython/rev/9ee36b74b432 New changeset 9fadeee05880 by Gregory P. Smith in branch 'default': Issue #27123: When an exception is raised within the context being https://hg.python.org/cpython/rev/9fadeee05880 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 12:29:00 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 14 Jun 2016 16:29:00 +0000 Subject: [issue27122] Hang with contextlib.ExitStack and subprocess.Popen (regression) In-Reply-To: <1464176880.25.0.308106356091.issue27122@psf.upfronthosting.co.za> Message-ID: <1465921740.23.0.344321593495.issue27122@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Fixes are in 3.5 and default: remote: notified python-checkins at python.org of incoming changeset 9ee36b74b432 remote: notified python-checkins at python.org of incoming changeset 9fadeee05880 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 12:30:22 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 14 Jun 2016 16:30:22 +0000 Subject: [issue27122] Hang with contextlib.ExitStack and subprocess.Popen (regression) In-Reply-To: <1464176880.25.0.308106356091.issue27122@psf.upfronthosting.co.za> Message-ID: <1465921822.77.0.575621445038.issue27122@psf.upfronthosting.co.za> Gregory P. Smith added the comment: (with a follow up change to fix the typo in the news file which the bot hasn't seen fit to mention here yet) i'm removing the 25782 dependency as that isn't blocking fixing this. ---------- dependencies: -CPython hangs on error __context__ set to the error itself _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 12:31:01 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 14 Jun 2016 16:31:01 +0000 Subject: [issue27123] Allow `install_headers` command to follow specific directory structure In-Reply-To: <1464186275.75.0.908359845764.issue27123@psf.upfronthosting.co.za> Message-ID: <1465921861.54.0.68198972602.issue27123@psf.upfronthosting.co.za> Gregory P. Smith added the comment: (ignore that... typo in the commit log for issue27122's fix) ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 12:31:18 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 14 Jun 2016 16:31:18 +0000 Subject: [issue27123] Allow `install_headers` command to follow specific directory structure In-Reply-To: <1464186275.75.0.908359845764.issue27123@psf.upfronthosting.co.za> Message-ID: <1465921878.93.0.664950368867.issue27123@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- nosy: -gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 12:32:02 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 14 Jun 2016 16:32:02 +0000 Subject: [issue27122] Hang with contextlib.ExitStack and subprocess.Popen (regression) In-Reply-To: <1464176880.25.0.308106356091.issue27122@psf.upfronthosting.co.za> Message-ID: <1465921922.81.0.660288422169.issue27122@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- resolution: -> fixed stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 13:38:58 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jun 2016 17:38:58 +0000 Subject: [issue27123] Allow `install_headers` command to follow specific directory structure In-Reply-To: <1464186275.75.0.908359845764.issue27123@psf.upfronthosting.co.za> Message-ID: <20160614162818.11521.64631.029C91C9@psf.io> Roundup Robot added the comment: New changeset 6bb68eae63e8 by Gregory P. Smith in branch '3.5': issue27122: fix typo in the news file, wrong issue #. not issue27123. https://hg.python.org/cpython/rev/6bb68eae63e8 New changeset 4e1dbfcc9449 by Gregory P. Smith in branch 'default': issue27122: fix typo in the news file, wrong issue #. not issue27123. https://hg.python.org/cpython/rev/4e1dbfcc9449 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 13:38:58 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jun 2016 17:38:58 +0000 Subject: [issue27122] Hang with contextlib.ExitStack and subprocess.Popen (regression) In-Reply-To: <1464176880.25.0.308106356091.issue27122@psf.upfronthosting.co.za> Message-ID: <20160614162818.11521.97628.9EC97B42@psf.io> Roundup Robot added the comment: New changeset 6bb68eae63e8 by Gregory P. Smith in branch '3.5': issue27122: fix typo in the news file, wrong issue #. not issue27123. https://hg.python.org/cpython/rev/6bb68eae63e8 New changeset 4e1dbfcc9449 by Gregory P. Smith in branch 'default': issue27122: fix typo in the news file, wrong issue #. not issue27123. https://hg.python.org/cpython/rev/4e1dbfcc9449 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 13:41:00 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jun 2016 17:41:00 +0000 Subject: [issue27319] Multiple item arguments for selection operations Message-ID: <1465926060.08.0.266570766159.issue27319@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: For now methods selection_set(), selection_add(), selection_remove() and selection_toggle() of ttk.TreeView take the single argument that should be either the single item id or a tuple or list of item ids. In contrary methods delete() and detach() take item ids as a variable number of arguments. The latter interface looks more pythonic, more consistent and errorproof. Proposed patch (based on Terry's suggestion in issue26386) makes selection methods accepting a variable number of arguments. For compatibility with older versions a tuple or list of item ids can be specified as a single argument, but this interface is deprecated (with long deprecation period). In addition deprecated other weird interface. For now the selection() method can take a subcommand name and items, for example tv.selection('add', 'ITEM1'). If the first argument is None, arguments are ignored, tv.selection(None, 'spam') equals to tv.selection(). Now all this is deprecated and will be TypeError in 3.7. ---------- components: Library (Lib), Tkinter files: treeview_selection_items.patch keywords: patch messages: 268574 nosy: serhiy.storchaka, terry.reedy priority: normal severity: normal stage: patch review status: open title: Multiple item arguments for selection operations type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43390/treeview_selection_items.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 13:42:33 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jun 2016 17:42:33 +0000 Subject: [issue26386] tkinter - Treeview - .selection_add and selection_toggle In-Reply-To: <1455813008.22.0.795281140329.issue26386@psf.upfronthosting.co.za> Message-ID: <1465926153.3.0.94208993603.issue26386@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Terry. Opened issue27319 for changing the signature of selection methods. ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 13:45:47 2016 From: report at bugs.python.org (Antony Lee) Date: Tue, 14 Jun 2016 17:45:47 +0000 Subject: [issue27320] ./setup.py --help-commands should sort extra commands Message-ID: <1465926347.78.0.17877088837.issue27320@psf.upfronthosting.co.za> New submission from Antony Lee: Currently, `./setup.py --help-commands` displays extra commands in a random (dict iteration, probably?) order, as can be seen with the following minimal example: from distutils.command.build_py import build_py from distutils.core import setup class foo(build_py): pass class bar(build_py): pass setup(cmdclass={"foo": foo, "bar": bar}) (`./setup.py --help-commands` will sometimes display `foo` before `bar`, sometimes `bar` before `foo`.) For consistency, and especially because setuptools adds a lot of extra commands, it would be nice if the help listing these extra commands was sorted instead. ---------- components: Distutils messages: 268576 nosy: Antony.Lee, dstufft, eric.araujo priority: normal severity: normal status: open title: ./setup.py --help-commands should sort extra commands versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 13:49:48 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jun 2016 17:49:48 +0000 Subject: [issue27122] Hang with contextlib.ExitStack and subprocess.Popen (regression) In-Reply-To: <1464176880.25.0.308106356091.issue27122@psf.upfronthosting.co.za> Message-ID: <1465926588.74.0.302563893123.issue27122@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Is it worth to add more specific tests for __context__ and __cause__ attributes of an exception? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 13:51:28 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jun 2016 17:51:28 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <1465926688.35.0.0404084900399.issue25782@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: For reference: the correct issue number is #27122. Are there examples of creating a loop not involving ExitStack or explicit setting the __context__ attribute? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 14:39:29 2016 From: report at bugs.python.org (Ilya Kulakov) Date: Tue, 14 Jun 2016 18:39:29 +0000 Subject: [issue18378] locale.getdefaultlocale() fails on Mac OS X with default language set to English In-Reply-To: <1373113143.69.0.513997485887.issue18378@psf.upfronthosting.co.za> Message-ID: <1465929569.66.0.0394067205.issue18378@psf.upfronthosting.co.za> Ilya Kulakov added the comment: Could someone provide a patch for Python 3.5? ---------- nosy: +Ilya.Kulakov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 14:52:52 2016 From: report at bugs.python.org (Mark Sapiro) Date: Tue, 14 Jun 2016 18:52:52 +0000 Subject: [issue27321] Email parser creates a message object that can't be flattened Message-ID: <1465930372.53.0.0254623453508.issue27321@psf.upfronthosting.co.za> New submission from Mark Sapiro: The attached file, bad_email, can be parsed via msg = email.message_from_binary_file(open('bad_email', 'rb')) but then msg.as_string() prodices the following: Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.5/email/message.py", line 159, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/lib/python3.5/email/generator.py", line 115, in flatten self._write(msg) File "/usr/lib/python3.5/email/generator.py", line 189, in _write msg.replace_header('content-transfer-encoding', munge_cte[0]) File "/usr/lib/python3.5/email/message.py", line 559, in replace_header raise KeyError(_name) KeyError: 'content-transfer-encoding' ---------- components: email files: bad_email messages: 268580 nosy: barry, msapiro, r.david.murray priority: normal severity: normal status: open title: Email parser creates a message object that can't be flattened versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file43391/bad_email _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 15:08:20 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jun 2016 19:08:20 +0000 Subject: [issue27301] Incorrect return codes in compile.c In-Reply-To: <1465745648.38.0.217159225058.issue27301@psf.upfronthosting.co.za> Message-ID: <1465931300.72.0.677944768381.issue27301@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file43392/compile_rc-3.6_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 15:08:39 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jun 2016 19:08:39 +0000 Subject: [issue27301] Incorrect return codes in compile.c In-Reply-To: <1465745648.38.0.217159225058.issue27301@psf.upfronthosting.co.za> Message-ID: <1465931319.95.0.479548363157.issue27301@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file43393/compile_rc-3.5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 15:08:59 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jun 2016 19:08:59 +0000 Subject: [issue27301] Incorrect return codes in compile.c In-Reply-To: <1465745648.38.0.217159225058.issue27301@psf.upfronthosting.co.za> Message-ID: <1465931339.58.0.146247705385.issue27301@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file43367/compile_rc-3.6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 15:33:08 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jun 2016 19:33:08 +0000 Subject: [issue27298] redundant iteration over digits in _PyLong_AsUnsignedLongMask In-Reply-To: <1465680013.34.0.390511904077.issue27298@psf.upfronthosting.co.za> Message-ID: <1465932788.54.0.141409046865.issue27298@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The accurate number of digits is (sizeof(x) * 8 + PyLong_SHIFT - 1) / PyLong_SHIFT or (sizeof(x) * 8 - 1) / PyLong_SHIFT + 1. There is a similar code in _PyLong_AsUnsignedLongLongMask(). Changes of Modules/_testcapimodule.c look not related to the implementation of _PyLong_AsUnsignedLongMask. Needed some results of microbenchmarking. The patch speeds up _PyLong_AsUnsignedLongLongMask() for very large integers, but in most cases this function is called for not such larger integers, and the patch adds additional check. We should ensure that this doesn't slow down the function. ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 15:39:26 2016 From: report at bugs.python.org (Alexander Schrijver) Date: Tue, 14 Jun 2016 19:39:26 +0000 Subject: [issue12855] linebreak sequences should be better documented In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za> Message-ID: <1465933166.09.0.176586985272.issue12855@psf.upfronthosting.co.za> Alexander Schrijver added the comment: Martin: Yes, it does, thank you. Sorry, I didn't know you where waiting for my approval. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 15:40:29 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jun 2016 19:40:29 +0000 Subject: [issue27238] Bare except: usages in turtle.py In-Reply-To: <1465173486.36.0.354067909151.issue27238@psf.upfronthosting.co.za> Message-ID: <1465933229.72.0.61803469528.issue27238@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. There is no case for bare except here. Actually it is a bug, since (in this file) a bare except can swallow KeyboardInterrupt. ---------- assignee: Jelle Zijlstra -> serhiy.storchaka stage: patch review -> commit review type: enhancement -> behavior versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 15:54:31 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jun 2016 19:54:31 +0000 Subject: [issue27238] Bare except: usages in turtle.py In-Reply-To: <1465173486.36.0.354067909151.issue27238@psf.upfronthosting.co.za> Message-ID: <20160614195408.87428.15318.1A9E8CFF@psf.io> Roundup Robot added the comment: New changeset 78e5efa3dd9e by Serhiy Storchaka in branch '3.5': Issue #27238: Got rid of bare excepts in the turtle module. Original patch https://hg.python.org/cpython/rev/78e5efa3dd9e New changeset e9d023b7d676 by Serhiy Storchaka in branch '2.7': Issue #27238: Got rid of bare excepts in the turtle module. Original patch https://hg.python.org/cpython/rev/e9d023b7d676 New changeset cd68cf41adf2 by Serhiy Storchaka in branch 'default': Issue #27238: Got rid of bare excepts in the turtle module. Original patch https://hg.python.org/cpython/rev/cd68cf41adf2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 15:55:39 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jun 2016 19:55:39 +0000 Subject: [issue27238] Bare except: usages in turtle.py In-Reply-To: <1465173486.36.0.354067909151.issue27238@psf.upfronthosting.co.za> Message-ID: <1465934139.23.0.466801887411.issue27238@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your contribution Jelle. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 16:44:50 2016 From: report at bugs.python.org (Oren Milman) Date: Tue, 14 Jun 2016 20:44:50 +0000 Subject: [issue27298] redundant iteration over digits in _PyLong_AsUnsignedLongMask In-Reply-To: <1465680013.34.0.390511904077.issue27298@psf.upfronthosting.co.za> Message-ID: <1465937090.87.0.285218308318.issue27298@psf.upfronthosting.co.za> Oren Milman added the comment: Ah, that's a cool alternative to divide and ceil. I would change my patch accordingly. And would write the patch also for _PyLong_AsUnsignedLongLongMask, and work on some micro-benchmarking for it and _PyLong_AsUnsignedLongMask. Indeed _testcapimodule.c is not really related. Should I open another issue for that only? (I am often worried about opening many small issues.. Please let me know if I shouldn't be.) Now that you mention it, similar 'while (--i >= 0)' can be found in some other functions: 1. PyLong_AsLongAndOverflow 2. PyLong_AsSsize_t 3. PyLong_AsUnsignedLong 4. PyLong_AsSize_t 5. PyLong_AsLongLongAndOverflow I suspect we could optimize these 5 by first determining whether the Python int has too many bits, instead of shifting and checking for an overflow on each iteration. I would definitely give it a try when I am done with _PyLong_AsUnsignedLongLongMask and _PyLong_AsUnsignedLongMask :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 17:22:59 2016 From: report at bugs.python.org (Maciej Szulik) Date: Tue, 14 Jun 2016 21:22:59 +0000 Subject: [issue27321] Email parser creates a message object that can't be flattened In-Reply-To: <1465930372.53.0.0254623453508.issue27321@psf.upfronthosting.co.za> Message-ID: <1465939379.73.0.752687458936.issue27321@psf.upfronthosting.co.za> Changes by Maciej Szulik : ---------- nosy: +maciej.szulik _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 18:03:56 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 14 Jun 2016 22:03:56 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1465941836.55.0.418126199961.issue27051@psf.upfronthosting.co.za> Terry J. Reedy added the comment: install_page.py fails with Traceback (most recent call last): File "F:\Python\mypy\tem2.py", line 611, in install_app = InstallPage(root) TypeError: __init__() missing 1 required positional argument: 'controller' manage_installed_modules_page.py would have the same failure. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 18:44:29 2016 From: report at bugs.python.org (Larry Hastings) Date: Tue, 14 Jun 2016 22:44:29 +0000 Subject: [issue25843] code_richcompare() don't use constant type when comparing code constants In-Reply-To: <1449861793.94.0.13967463155.issue25843@psf.upfronthosting.co.za> Message-ID: <1465944269.03.0.548041103168.issue25843@psf.upfronthosting.co.za> Larry Hastings added the comment: Yes, which doesn't help 3.5.2 final as I don't pull revisions by default after rc1. :p ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 18:54:21 2016 From: report at bugs.python.org (Mark Sapiro) Date: Tue, 14 Jun 2016 22:54:21 +0000 Subject: [issue27321] Email parser creates a message object that can't be flattened In-Reply-To: <1465930372.53.0.0254623453508.issue27321@psf.upfronthosting.co.za> Message-ID: <1465944861.88.0.0753435942904.issue27321@psf.upfronthosting.co.za> Mark Sapiro added the comment: One additional observation. The original message contained no Content-Transfer-Encoding header even though the message body was raw koi8-r characters. Adding Content-Transfer-Encoding: 8bit to the message headers avoids the issue, but that is not a practical solution as the message was Russian spam received by a Mailman list and the resultant KeyError caused problems in Mailman. We can work on defending against this in Mailman, but I suggest that the munge_cte code in generator._write() avoid the documented possible KeyError raised by replace_header() by using __delitem__() and __setitem__() instead as in the attached generator.patch. ---------- keywords: +patch Added file: http://bugs.python.org/file43394/generator.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 19:10:30 2016 From: report at bugs.python.org (John Hagen) Date: Tue, 14 Jun 2016 23:10:30 +0000 Subject: [issue27311] Incorrect documentation for zipfile.writestr() In-Reply-To: <1465864941.05.0.345060177149.issue27311@psf.upfronthosting.co.za> Message-ID: <1465945830.15.0.775446290174.issue27311@psf.upfronthosting.co.za> John Hagen added the comment: Patch attached. ---------- keywords: +patch Added file: http://bugs.python.org/file43395/0001-Fix-ZipFile.writestr-data-argument-name.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 19:35:05 2016 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 14 Jun 2016 23:35:05 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465947305.83.0.943904155221.issue26839@psf.upfronthosting.co.za> Nick Coghlan added the comment: One last fix needed to fully revert this is to remove the mention from the Python 3.5 What's New documentation: https://docs.python.org/3.5/whatsnew/3.5.html#os ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 19:35:10 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 14 Jun 2016 23:35:10 +0000 Subject: [issue27311] Incorrect documentation for zipfile.writestr() In-Reply-To: <1465864941.05.0.345060177149.issue27311@psf.upfronthosting.co.za> Message-ID: <1465947310.72.0.639409051234.issue27311@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks John ---------- stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 19:40:51 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 14 Jun 2016 23:40:51 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1465947651.2.0.97045286544.issue26839@psf.upfronthosting.co.za> STINNER Victor added the comment: Nick Coghlan: "One last fix needed to fully revert this is to remove the mention from the Python 3.5 What's New documentation: https://docs.python.org/3.5/whatsnew/3.5.html#os" This sentence? "The urandom() function now uses the getrandom() syscall on Linux 3.17 or newer, and getentropy() on OpenBSD 5.6 and newer, removing the need to use /dev/urandom and avoiding failures due to potential file descriptor exhaustion." Why removing it? It's still correct that getrandom() is used by os.urandom() in the common case. The corner case (urandom entropy pool not initialized) is already documented (including a "Changed in version 3.5.2: ..."): https://docs.python.org/3.5/library/os.html#os.urandom I don't think that it's worth to mention the corner case in What's New in Python 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 20:09:14 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 15 Jun 2016 00:09:14 +0000 Subject: [issue27319] Multiple item arguments for selection operations In-Reply-To: <1465926060.08.0.266570766159.issue27319@psf.upfronthosting.co.za> Message-ID: <1465949354.06.0.529156490062.issue27319@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Code looks good, just a couple of comments. But I am puzzled by string return before patch >>> tv.selection() '' versus tuple return after patch (which seems correct). >>> tv.selection() () ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 20:11:10 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 15 Jun 2016 00:11:10 +0000 Subject: [issue27278] py_getrandom() uses an int for syscall() result In-Reply-To: <1465458165.91.0.316132030988.issue27278@psf.upfronthosting.co.za> Message-ID: <1465949470.93.0.797681694171.issue27278@psf.upfronthosting.co.za> Martin Panter added the comment: Yeah I think your change is enough. Adding a cast would solve this compiler warning: Python/random.c:168:17: warning: conversion to ?int? from ?long int? may alter its value [-Wconversion] n = syscall(SYS_getrandom, dest, n, flags); ^ But on the other hand, when I just recompiled Python with -Wconversion, I got hundreds of other warnings, so maybe there is a good reason we don?t enable that warning. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 20:55:15 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 15 Jun 2016 00:55:15 +0000 Subject: [issue26923] asyncio.gather drops cancellation In-Reply-To: <1462279806.1.0.880381545595.issue26923@psf.upfronthosting.co.za> Message-ID: <1465952115.12.0.805795024729.issue26923@psf.upfronthosting.co.za> Guido van Rossum added the comment: I think I agree with Johannes. If all children refuse to be cancelled because they are already done, the outer _GatheringFuture might as well refuse to be cancelled as well. However I'm not sure I actually understand the mechanism whereby the calling Task ends up surviving, and Johannes' description appears garbled. Can anyone add some print statements to various parts and explain it here? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 21:08:04 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 15 Jun 2016 01:08:04 +0000 Subject: [issue27311] Incorrect documentation for zipfile.writestr() In-Reply-To: <1465864941.05.0.345060177149.issue27311@psf.upfronthosting.co.za> Message-ID: <20160615010759.20145.2506.EAC54E8F@psf.io> Roundup Robot added the comment: New changeset 32af78a8b88f by Martin Panter in branch '3.5': Issue #27311: Fix ZipFile.writestr data argument name. https://hg.python.org/cpython/rev/32af78a8b88f New changeset e3bb87952c62 by Martin Panter in branch 'default': Issue #27311: Merge zipfile doc from 3.5 https://hg.python.org/cpython/rev/e3bb87952c62 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 21:08:50 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 15 Jun 2016 01:08:50 +0000 Subject: [issue16182] readline: Wrong tab completion scope indices in Unicode terminals In-Reply-To: <1349813384.06.0.615857426211.issue16182@psf.upfronthosting.co.za> Message-ID: <1465952930.34.0.645910367106.issue16182@psf.upfronthosting.co.za> Martin Panter added the comment: Think I got all the bugs fixed here. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 21:43:37 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 15 Jun 2016 01:43:37 +0000 Subject: [issue12855] linebreak sequences should be better documented In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za> Message-ID: <20160615014333.27977.85212.7AA03DCF@psf.io> Roundup Robot added the comment: New changeset 2e6fda267a20 by Martin Panter in branch '2.7': Issue #12855: Document what exactly unicode.splitlines() splits on https://hg.python.org/cpython/rev/2e6fda267a20 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 21:43:58 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 15 Jun 2016 01:43:58 +0000 Subject: [issue27311] Incorrect documentation for zipfile.writestr() In-Reply-To: <1465864941.05.0.345060177149.issue27311@psf.upfronthosting.co.za> Message-ID: <1465955038.06.0.271194775334.issue27311@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 22:01:19 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 15 Jun 2016 02:01:19 +0000 Subject: [issue12855] linebreak sequences should be better documented In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za> Message-ID: <1465956079.55.0.642915979121.issue12855@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 22:27:13 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Jun 2016 02:27:13 +0000 Subject: [issue27319] Multiple item arguments for selection operations In-Reply-To: <1465926060.08.0.266570766159.issue27319@psf.upfronthosting.co.za> Message-ID: <1465957633.0.0.438951913604.issue27319@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'm puzzled too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 23:01:25 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 15 Jun 2016 03:01:25 +0000 Subject: [issue26804] Prioritize lowercase proxy variables in urllib.request In-Reply-To: <1461053909.86.0.0123928931795.issue26804@psf.upfronthosting.co.za> Message-ID: <1465959685.74.0.0565840799485.issue26804@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Unfortunately no. 3.4 is only in security fixes mode and this doesn't qualify as a security fix. Usually the bug fixes and feature additions are incentives for developers to upgrade their python codebase. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 14 23:02:44 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Jun 2016 03:02:44 +0000 Subject: [issue27319] Multiple item arguments for selection operations In-Reply-To: <1465926060.08.0.266570766159.issue27319@psf.upfronthosting.co.za> Message-ID: <1465959764.0.0.675351999132.issue27319@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: splitlist() always returns a tuple. How selection() ca return a string?! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 00:00:38 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 15 Jun 2016 04:00:38 +0000 Subject: [issue27319] Multiple item arguments for selection operations In-Reply-To: <1465926060.08.0.266570766159.issue27319@psf.upfronthosting.co.za> Message-ID: <1465963238.5.0.743677133209.issue27319@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I reverted the patch, restarted IDLE, and now I get () as I should. Lets forget about it. Apply or ignore comments as you wish. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 01:46:43 2016 From: report at bugs.python.org (Upendra Kumar) Date: Wed, 15 Jun 2016 05:46:43 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1465969603.36.0.891650926956.issue27051@psf.upfronthosting.co.za> Upendra Kumar added the comment: For executing it currently, we need to run it like this: python -m pip_tkinter Recently, I have changed code. Therefore we can't execute individual pages/layouts by running it with "python -m pip_tkinter.". I will change the code in "__main__" section so that they can be executed independently. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 02:28:45 2016 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 15 Jun 2016 06:28:45 +0000 Subject: [issue27301] Incorrect return codes in compile.c In-Reply-To: <1465745648.38.0.217159225058.issue27301@psf.upfronthosting.co.za> Message-ID: <1465972125.61.0.424216185541.issue27301@psf.upfronthosting.co.za> Benjamin Peterson added the comment: lgtm ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 03:02:13 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 15 Jun 2016 07:02:13 +0000 Subject: [issue27177] re match.group should support __index__ In-Reply-To: <1464790808.77.0.698310162067.issue27177@psf.upfronthosting.co.za> Message-ID: <1465974133.42.0.377079942112.issue27177@psf.upfronthosting.co.za> Xiang Zhang added the comment: Attach a patch to add this feature to Py3.6. ---------- nosy: +xiang.zhang Added file: http://bugs.python.org/file43396/issue27177.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 03:20:19 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 15 Jun 2016 07:20:19 +0000 Subject: [issue27322] test_compile_path fails when python has been installed Message-ID: <1465975219.4.0.787854022028.issue27322@psf.upfronthosting.co.za> New submission from Xavier de Gaye: ====================================================================== FAIL: test_compile_path (test.test_compileall.CompileallTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/xavier/src/python/default/Lib/test/test_compileall.py", line 118, in test_compile_path self.assertTrue(compileall.compile_path(quiet=2)) AssertionError: False is not true Changing the 'quiet' flag value to 0, gives: test_compile_path (test.test_compileall.CompileallTests) ... Skipping current directory Listing '/usr/local/lib/python36.zip'... Can't list '/usr/local/lib/python36.zip' Listing '/home/xavier/src/python/default/Lib'... Listing '/home/xavier/src/python/default/Lib/plat-x86_64-linux-gnu'... Can't list '/home/xavier/src/python/default/Lib/plat-x86_64-linux-gnu' Listing '/home/xavier/src/python/default/build/lib.linux-x86_64-3.6-pydebug'... Listing '/home/xavier/.local/lib/python3.6/site-packages'... Listing '/usr/local/lib/python3.6/site-packages'... Compiling '/usr/local/lib/python3.6/site-packages/easy_install.py'... *** PermissionError: [Errno 13] Permission denied: '/usr/local/lib/python3.6/site-packages/__pycache __/easy_install.cpython-36.pyc.139734863394416' FAIL Note that this test has already been fixed for another problem in issue 26101. ---------- components: Tests messages: 268607 nosy: brett.cannon, haypo, xdegaye priority: low severity: normal stage: needs patch status: open title: test_compile_path fails when python has been installed type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 03:44:47 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 15 Jun 2016 07:44:47 +0000 Subject: [issue7769] SimpleXMLRPCServer.SimpleXMLRPCServer.register_function as decorator In-Reply-To: <1264337326.51.0.913533963705.issue7769@psf.upfronthosting.co.za> Message-ID: <1465976687.05.0.00140254515122.issue7769@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 04:15:11 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 15 Jun 2016 08:15:11 +0000 Subject: [issue27323] ncurses putwin() fails in test_module_funcs Message-ID: <1465978511.0.0.353969305887.issue27323@psf.upfronthosting.co.za> New submission from Xavier de Gaye: This is with ncurses 6.0. $ ./python -m test -v -u curses -m test_module_funcs test_curses == CPython 3.6.0a2+ (default:e3bb87952c62, Jun 15 2016, 08:24:47) [GCC 6.1.1 20160501] == Linux-4.6.1-2-ARCH-x86_64-with-arch little-endian == hash algorithm: siphash24 64bit == /home/xavier/src/python/default/build/test_python_17932 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0) Run tests sequentially 0:00:00 [1/1] test_curses test_module_funcs (test.test_curses.TestCurses) Test module-level functions ... ERROR ====================================================================== ERROR: test_module_funcs (test.test_curses.TestCurses) Test module-level functions ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/xavier/src/python/default/Lib/test/test_curses.py", line 212, in test_module_funcs self.stdscr.putwin(f) _curses.error: putwin() returned ERR ---------- components: Library (Lib) messages: 268608 nosy: serhiy.storchaka, twouters, xdegaye priority: normal severity: normal status: open title: ncurses putwin() fails in test_module_funcs type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 04:21:09 2016 From: report at bugs.python.org (Johannes Ebke) Date: Wed, 15 Jun 2016 08:21:09 +0000 Subject: [issue26923] asyncio.gather drops cancellation In-Reply-To: <1462279806.1.0.880381545595.issue26923@psf.upfronthosting.co.za> Message-ID: <1465978869.72.0.730792032977.issue26923@psf.upfronthosting.co.za> Johannes Ebke added the comment: On rereading my original description, it really is not clearly described why the calling Task ends up surviving. Attached is a patch to the 3.5.1 asyncio/tasks.py which adds some print statements in Task.cancel(). If I execute the cancellation_test.py with the patch applied, the output looks like this: ------------------------ Cancelling the task: wait_for=<_GatheringFuture pending cb=[Task._wakeup()]> cb=[Task._wakeup()]> Entered Task.cancel() for task wait_for=<_GatheringFuture pending cb=[Task._wakeup()]> cb=[Task._wakeup()]> Task is not done() and we have a _fut_waiter: Cancelling fut_waiter <_GatheringFuture pending cb=[Task._wakeup()]> Entered Task.cancel() for task result=None> Task is done(), refusing to cancel Great, _fut_waiter has agreed to be cancelled. We can now also return True Cancellation returned: True All children finished OK, setting _GatheringFuture results! Finished gathering. Proof that this is running even though it was cancelled ------------------------ The Task keeps on running because Task.cancel() trusts its _fut_waiter task to handle the cancellation correctly if its cancel() method returns True. If it returns False, it handles the Cancellation itself. In this case, that _fut_waiter continues on, and proceeds to set results etc. so that the calling tasks cannot distinguish this from a CancellationError which has been deliberately caught. I hope this explanation is a bit clearer than the first one. ---------- keywords: +patch Added file: http://bugs.python.org/file43397/asyncio_task_prints.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 04:34:18 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 15 Jun 2016 08:34:18 +0000 Subject: [issue26582] asyncio documentation links to wrong CancelledError In-Reply-To: <1458225953.38.0.399231880747.issue26582@psf.upfronthosting.co.za> Message-ID: <1465979658.76.0.384701708423.issue26582@psf.upfronthosting.co.za> Berker Peksag added the comment: CancelledError documentation needs to be updated to mention that it is an alias for 'concurrent.futures.CancelledError'. We also need to update all ``:exc:`~concurrent.futures.CancelledError``` usages in Doc/library/asyncio*.rst. I'd prefer to reuse the description of https://docs.python.org/3.5/library/concurrent.futures.html#concurrent.futures.CancelledError ---------- nosy: +berker.peksag stage: -> patch review type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 04:58:07 2016 From: report at bugs.python.org (Rolf Krahl) Date: Wed, 15 Jun 2016 08:58:07 +0000 Subject: [issue12319] [http.client] HTTPConnection.request not support "chunked" Transfer-Encoding to send data In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za> Message-ID: <1465981087.66.0.515947090726.issue12319@psf.upfronthosting.co.za> Rolf Krahl added the comment: Python 3.6.0a2 has been released this week. I guess, we need to speed up a bit. I really would like to see this issue fixed in 3.6.0 final. I updated Demian's patch to match the current Python sources, see the attachment. I also addressed the issue in urllib.request. It turned out that this was a little bit more involved then just removing the corresponding if statement from AbstractHTTPHandler.do_request_() as suggested above: if the Content-Length has been added by the lib, a caller of urllib might assume to find that header also to be set in the Request object afterwards. At least, some tests do. But I still believe, urllib.request should refrain from trying to calculate the content length itself, but rather rely on http.client for this, because it is crucial that the interpretation of the various body representations (buffer, file, iterable) while calculating this length matches the code in http.client that reads the body when sending it to the server. So, I amended Demian's patch as follows: 1. change the helper _get_content_length() in http.client to a static method of HTTPConnection in order to allow urllib.request to call it. 2. review get_content_length(), there where a few issues in special cases. 3. add an optional argument encode_chunked to http.client.HTTPConnection.request(). If set to True, HTTPConnection will do the chunk encoding also if the Transfer-Encoding header is set. This is needed, because urllib.request now sets all required headers in the request, including Transfer-Encoding if needed. But does not handle the chunk encoding itself. 4. if the request has a non-empty body and Content-Length is not set, urllib.request.AbstractHTTPHandler calls http.client.HTTPConnection.get_content_length to calculate the content length. If this returns None, it sets the Transfer-Encoding: chunked header. ---------- Added file: http://bugs.python.org/file43398/issue12319_7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 05:12:47 2016 From: report at bugs.python.org (Mark) Date: Wed, 15 Jun 2016 09:12:47 +0000 Subject: [issue27324] Error when building Python extension Message-ID: <1465981967.5.0.585980107476.issue27324@psf.upfronthosting.co.za> New submission from Mark: I'd like to build a C++ extension for Python. I took a simple C file from a tutorial and wrote the setup.py file. But when I run the command: python setup.py build_ext --inplace I get the following error: error: Unable to find vcvarsall.bat This file is located in "c:\Program Files (x86)\Microsoft Visual Studio 12.0\vc\vcvarsall.bat" but even when I run it and set all environment variables, python.exe still tries to find it. I added this path to the PATH but it didn't solve the issue. ---------- components: Distutils messages: 268612 nosy: Mark53, dstufft, eric.araujo priority: normal severity: normal status: open title: Error when building Python extension type: compile error versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 05:29:17 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 15 Jun 2016 09:29:17 +0000 Subject: [issue27325] random failure of test_builtin Message-ID: <1465982957.82.0.785145157201.issue27325@psf.upfronthosting.co.za> New submission from Xavier de Gaye: Not sure if this is relevant, I am using: readline 6.3 ncurses 6.0 The test runs fine when run alone, with the 8991930 random seed: $ ./python -bb -E -Wd -m test -r -w -uall --randseed 8991930 ====================================================================== [3/1338] FAIL: test_input_tty_non_ascii (test.test_builtin.PtyTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/xavier/src/python/default/Lib/test/test_builtin.py", line 1583, in test_input_tty_non_ ascii self.check_input_tty("prompt?", b"quux\xe9", "utf-8") File "/home/xavier/src/python/default/Lib/test/test_builtin.py", line 1574, in check_input_tty self.assertEqual(input_result, expected) AssertionError: 'quux' != 'quux\udce9' - quux + quux\udce9 ? + ====================================================================== FAIL: test_input_tty_non_ascii_unicode_errors (test.test_builtin.PtyTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/xavier/src/python/default/Lib/test/test_builtin.py", line 1587, in test_input_tty_non_ ascii_unicode_errors self.check_input_tty("prompt?", b"quux\xe9", "ascii") File "/home/xavier/src/python/default/Lib/test/test_builtin.py", line 1574, in check_input_tty self.assertEqual(input_result, expected) AssertionError: 'quux' != 'quux\udce9' - quux + quux\udce9 ? + ---------- components: Tests messages: 268613 nosy: martin.panter, xdegaye priority: normal severity: normal status: open title: random failure of test_builtin type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 05:39:00 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 15 Jun 2016 09:39:00 +0000 Subject: [issue27325] random failure of test_builtin In-Reply-To: <1465982957.82.0.785145157201.issue27325@psf.upfronthosting.co.za> Message-ID: <1465983540.78.0.534709362151.issue27325@psf.upfronthosting.co.za> Berker Peksag added the comment: This is a duplicate of issue 13886. ---------- nosy: +berker.peksag resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> readline-related test_builtin failure _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 06:02:36 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 15 Jun 2016 10:02:36 +0000 Subject: [issue26862] android: SYS_getdents64 does not need to be defined on android API 21 In-Reply-To: <1461678588.46.0.828463582716.issue26862@psf.upfronthosting.co.za> Message-ID: <20160615100153.26023.53151.BBBC30BB@psf.io> Roundup Robot added the comment: New changeset 4ef3a93e1be2 by Xavier de Gaye in branch 'default': Issue #26862: SYS_getdents64 does not need to be defined on android API 21. https://hg.python.org/cpython/rev/4ef3a93e1be2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 06:04:03 2016 From: report at bugs.python.org (SpaceOne) Date: Wed, 15 Jun 2016 10:04:03 +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: <1465985043.3.0.573831523249.issue9334@psf.upfronthosting.co.za> Changes by SpaceOne : ---------- nosy: +spaceone _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 06:04:10 2016 From: report at bugs.python.org (SpaceOne) Date: Wed, 15 Jun 2016 10:04:10 +0000 Subject: [issue26196] Argparse breaks when a switch is given an argument beginning with a dash In-Reply-To: <1453721135.68.0.519114761572.issue26196@psf.upfronthosting.co.za> Message-ID: <1465985050.53.0.561040408949.issue26196@psf.upfronthosting.co.za> Changes by SpaceOne : ---------- nosy: +spaceone _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 06:04:53 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 15 Jun 2016 10:04:53 +0000 Subject: [issue26862] android: SYS_getdents64 does not need to be defined on android API 21 In-Reply-To: <1461678588.46.0.828463582716.issue26862@psf.upfronthosting.co.za> Message-ID: <1465985093.87.0.0266614336038.issue26862@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 06:08:44 2016 From: report at bugs.python.org (=?utf-8?b?THVrw6HFoSBEb2t0b3I=?=) Date: Wed, 15 Jun 2016 10:08:44 +0000 Subject: [issue27318] Add support for symlinks to zipfile In-Reply-To: <1465905334.15.0.513827452466.issue27318@psf.upfronthosting.co.za> Message-ID: <1465985324.14.0.972532910886.issue27318@psf.upfronthosting.co.za> Luk?? Doktor added the comment: Hello Eryk, thank you for the prompt response. I have only checked that using python2.6 on `wine` and there was no `os.symlink` support there. I'm not sure how to reasonably handle the `dir` flag for Windows as theoretically the symlink can point out of the zip file. Do you know what happens when the symlink `dir` flag is set inappropriately? I guess it silently continues, but the link wont work, right? Well I added the `except OSError` part, please let me know, whether this version is acceptable. The situation could only be better as without this patch both OSs are stuck with text files instead of symlinks, this way at least on Linux it should work properly. ---------- Added file: http://bugs.python.org/file43399/zipfile-symlink.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 06:13:54 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 15 Jun 2016 10:13:54 +0000 Subject: [issue27323] ncurses putwin() fails in test_module_funcs In-Reply-To: <1465978511.0.0.353969305887.issue27323@psf.upfronthosting.co.za> Message-ID: <1465985634.48.0.320348045467.issue27323@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 06:26:37 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 15 Jun 2016 10:26:37 +0000 Subject: [issue27326] SIGSEV in test_window_funcs of test_curses Message-ID: <1465986396.24.0.604076353768.issue27326@psf.upfronthosting.co.za> New submission from Xavier de Gaye: This is with ncurses 6.0. When running the test suite with: ./python -bb -E -Wd -m test -r -w -uall test_curses fails as reported in issue 27323 and when the test runner re-runs test_curses in verbose mode at the end to test for a transient error, it happens sometimes that test_curses crashes. See the gdb backtrace attached. ---------- components: Library (Lib) files: gdb.log messages: 268617 nosy: serhiy.storchaka, twouters, xdegaye priority: normal severity: normal status: open title: SIGSEV in test_window_funcs of test_curses type: crash versions: Python 3.6 Added file: http://bugs.python.org/file43400/gdb.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 08:47:13 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Jun 2016 12:47:13 +0000 Subject: [issue27319] Multiple item arguments for selection operations In-Reply-To: <1465926060.08.0.266570766159.issue27319@psf.upfronthosting.co.za> Message-ID: <1465994833.84.0.956943511519.issue27319@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I was puzzled because on one of my machines selection() returned ''. But after updating the workspace the problem is gone. This is just a consequence of the issue26386 patch. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 09:42:36 2016 From: report at bugs.python.org (Zachary Ware) Date: Wed, 15 Jun 2016 13:42:36 +0000 Subject: [issue27324] Error when building Python extension In-Reply-To: <1465981967.5.0.585980107476.issue27324@psf.upfronthosting.co.za> Message-ID: <1465998156.24.0.0364001511648.issue27324@psf.upfronthosting.co.za> Zachary Ware added the comment: Hi Mark, To build Python extensions on Windows, you need to have a compiler that can link to the same C runtime used by the Python interpreter. For 3.5, that means you need VS2015; VS2013 won't work. ---------- nosy: +zach.ware resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 11:22:12 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 15 Jun 2016 15:22:12 +0000 Subject: [issue7769] SimpleXMLRPCServer.SimpleXMLRPCServer.register_function as decorator In-Reply-To: <1264337326.51.0.913533963705.issue7769@psf.upfronthosting.co.za> Message-ID: <1466004132.68.0.301732323436.issue7769@psf.upfronthosting.co.za> Xiang Zhang added the comment: Hi, I've written a patch to accomplish this in Py3.6. This patch is much cleaner but has one drawback, when used as decorator factory, you have to specify name as a keyword argument. But considering the codes that have to been imported to check arguments, I think it's not bad. (I don't want to check `function` is a string or not.) Also one side effect that I can not eliminate is when it is used as a normal function, the function instead of None is returned. I see the former patches get this problem too. Hope to get feedback. ---------- Added file: http://bugs.python.org/file43401/issue7769.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 12:39:29 2016 From: report at bugs.python.org (Mark) Date: Wed, 15 Jun 2016 16:39:29 +0000 Subject: [issue27324] Error when building Python extension In-Reply-To: <1465998156.24.0.0364001511648.issue27324@psf.upfronthosting.co.za> Message-ID: Mark added the comment: Hi Zach, Well,?the strange thing is that?other members of my team have successfully built C++ Python extensions with Visual Studio 13, but they compiled and built?the?pyd file?with CMake (one used SWIG). So, it is possible.?I just?wanted to?do it in a simpler way. Regards, Mark ---- Message d'origine ---- De : Zachary Ware ? : tibo53 at netcourrier.com Objet : [issue27324] Error when building Python extension Date : 15/06/2016 15:42:36 CEST Zachary Ware added the comment: Hi Mark, To build Python extensions on Windows, you need to have a compiler that can link to the same C runtime used by the Python interpreter. For 3.5, that means you need VS2015; VS2013 won't work. ---------- nosy: +zach.ware resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 12:54:39 2016 From: report at bugs.python.org (Zachary Ware) Date: Wed, 15 Jun 2016 16:54:39 +0000 Subject: [issue27324] Error when building Python extension In-Reply-To: <1465981967.5.0.585980107476.issue27324@psf.upfronthosting.co.za> Message-ID: <1466009679.44.0.343577144219.issue27324@psf.upfronthosting.co.za> Zachary Ware added the comment: Using the wrong compiler, you may wind up with an extension that appears to work, and you may never have a problem with it if conditions are just right. This article[1] looks like a pretty good explanation of why you don't want to do it, though (note: I've only skimmed the article). If you really want to shoot yourself in the foot, you can try running vcvarsall.bat yourself, then make sure MSsdk is set (distutils doesn't care what it's set to, just that it's set), and set DISTUTILS_USE_SDK (again, doesn't matter to what). Also, note that this problem should be a thing of the past with Python 3.5+ and VS2015+. [1] http://siomsystems.com/mixing-visual-studio-versions/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 13:09:12 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 15 Jun 2016 17:09:12 +0000 Subject: [issue27301] Incorrect return codes in compile.c In-Reply-To: <1465745648.38.0.217159225058.issue27301@psf.upfronthosting.co.za> Message-ID: <20160615170857.10071.20203.F8EE2CF8@psf.io> Roundup Robot added the comment: New changeset 51fe72949245 by Serhiy Storchaka in branch '3.5': Issue #27301: Fixed incorrect return codes for errors in compile.c. https://hg.python.org/cpython/rev/51fe72949245 New changeset c388b0751290 by Serhiy Storchaka in branch '2.7': Issue #27301: Fixed incorrect return code for error in compile.c. https://hg.python.org/cpython/rev/c388b0751290 New changeset 2b3cd7e4b2b6 by Serhiy Storchaka in branch 'default': Issue #27301: Fixed incorrect return codes for errors in compile.c. https://hg.python.org/cpython/rev/2b3cd7e4b2b6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 13:10:29 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Jun 2016 17:10:29 +0000 Subject: [issue27301] Incorrect return codes in compile.c In-Reply-To: <1465745648.38.0.217159225058.issue27301@psf.upfronthosting.co.za> Message-ID: <1466010629.14.0.704875720074.issue27301@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Benjamin. 2.7 needed to fix just one line. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 13:47:24 2016 From: report at bugs.python.org (ppperry) Date: Wed, 15 Jun 2016 17:47:24 +0000 Subject: [issue27314] Cannot install 3.5.2 with 3.6.0a1 installed In-Reply-To: <1465869564.71.0.178376895895.issue27314@psf.upfronthosting.co.za> Message-ID: <1466012844.25.0.340902671523.issue27314@psf.upfronthosting.co.za> Changes by ppperry : ---------- components: +Installation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 13:48:53 2016 From: report at bugs.python.org (lorenzogotuned) Date: Wed, 15 Jun 2016 17:48:53 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1466012933.24.0.849807978656.issue27051@psf.upfronthosting.co.za> lorenzogotuned added the comment: I made it run from the root directory with: python pip_tkinter/__main__.py For sure the right way should be python -m pip_tkinter The first view works fine for PyPi, the second one is just void. I added a issue for an enhancement at . We are going to fix what we have this weekend, for the sake of the first deadline. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 14:09:41 2016 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 15 Jun 2016 18:09:41 +0000 Subject: [issue27122] Hang with contextlib.ExitStack and subprocess.Popen (regression) In-Reply-To: <1464176880.25.0.308106356091.issue27122@psf.upfronthosting.co.za> Message-ID: <1466014181.06.0.832054813714.issue27122@psf.upfronthosting.co.za> Nick Coghlan added the comment: There's an existing scenario test at https://hg.python.org/cpython/file/default/Lib/test/test_contextlib.py#l600 and https://hg.python.org/cpython/file/default/Lib/test/test_contextlib.py#l648 that aims to ensure ExitStack unwinding and context setting matches the behaviour of actual with statements. It wouldn't hurt to add some explicit checks to the new test for this particular bug, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 14:14:29 2016 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 15 Jun 2016 18:14:29 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za> Message-ID: <1466014469.04.0.280696261188.issue26839@psf.upfronthosting.co.za> Nick Coghlan added the comment: Sorry, with all the different proposals kicking around, I somehow got the impression we'd reverted entirely to just reading from /dev/urandom without ever using the new syscall. Re-reviewing your patch, I agree the What's New comment is still accurate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 15:25:56 2016 From: report at bugs.python.org (Ethan Furman) Date: Wed, 15 Jun 2016 19:25:56 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1466018756.3.0.0249417960317.issue27186@psf.upfronthosting.co.za> Ethan Furman added the comment: os.fspath() will be changed to ensure the output of calling obj.__fspath__() is a str or bytes object. So the final behavior of calling os.fspath() will be to return a str or bytes or to raise an exception. I'll update the code for this change, as well is the places in the stdlib that do/should be using os.fspath(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 16:00:44 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 Jun 2016 20:00:44 +0000 Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() In-Reply-To: <1466014469.04.0.280696261188.issue26839@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > Re-reviewing your patch, I agree the What's New comment is still accurate. Thanks for double checking ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 17:38:39 2016 From: report at bugs.python.org (Jakub Wilk) Date: Wed, 15 Jun 2016 21:38:39 +0000 Subject: [issue27327] re documentation: typo "escapes consist of" Message-ID: <1466026719.49.0.251022149797.issue27327@psf.upfronthosting.co.za> New submission from Jakub Wilk: Documentation for the re module reads: Unknown escapes consist of '\' and ASCII letter now raise a deprecation warning ... This should be: ... escapes consisting of ... ---------- assignee: docs at python components: Documentation messages: 268630 nosy: docs at python, jwilk priority: normal severity: normal status: open title: re documentation: typo "escapes consist of" versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 18:10:26 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 15 Jun 2016 22:10:26 +0000 Subject: [issue27327] re documentation: typo "escapes consist of" In-Reply-To: <1466026719.49.0.251022149797.issue27327@psf.upfronthosting.co.za> Message-ID: <20160615221017.26579.21675.6DFDF293@psf.io> Roundup Robot added the comment: New changeset 2a7dd5414485 by Ned Deily in branch '3.5': Issue #27327: fix doc typo, noted by Jakub Wilk. https://hg.python.org/cpython/rev/2a7dd5414485 New changeset b3f97ed4a904 by Ned Deily in branch 'default': Issue #27327: null merge from 3.5 https://hg.python.org/cpython/rev/b3f97ed4a904 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 18:11:00 2016 From: report at bugs.python.org (Ned Deily) Date: Wed, 15 Jun 2016 22:11:00 +0000 Subject: [issue27327] re documentation: typo "escapes consist of" In-Reply-To: <1466026719.49.0.251022149797.issue27327@psf.upfronthosting.co.za> Message-ID: <1466028660.12.0.666213688795.issue27327@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the report! ---------- nosy: +ned.deily resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 18:17:18 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 15 Jun 2016 22:17:18 +0000 Subject: [issue26930] Upgrade installers to OpenSSL 1.0.2h In-Reply-To: <1462285174.78.0.332365810571.issue26930@psf.upfronthosting.co.za> Message-ID: <20160615221710.11339.91349.FED53B70@psf.io> Roundup Robot added the comment: New changeset 399d49d4acae by Zachary Ware in branch '2.7': Issue #26930: Update Windows build to OpenSSL 1.0.2h https://hg.python.org/cpython/rev/399d49d4acae New changeset 155e665428c6 by Zachary Ware in branch '3.5': Issue #26930: Update Windows build to OpenSSL 1.0.2h https://hg.python.org/cpython/rev/155e665428c6 New changeset 3d726dbfca31 by Zachary Ware in branch 'default': Issue #26930: Merge with 3.5 https://hg.python.org/cpython/rev/3d726dbfca31 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 18:21:18 2016 From: report at bugs.python.org (Zachary Ware) Date: Wed, 15 Jun 2016 22:21:18 +0000 Subject: [issue26930] Upgrade installers to OpenSSL 1.0.2h In-Reply-To: <1462285174.78.0.332365810571.issue26930@psf.upfronthosting.co.za> Message-ID: <1466029278.42.0.378642352903.issue26930@psf.upfronthosting.co.za> Zachary Ware added the comment: Finally got this done. Benjamin and Larry, it would probably be best if this made it into 2.7.12 and 3.5.2. Is there anything special I need to do to make that happen? (My sincere apologies for not getting it done before the RCs.) ---------- nosy: +benjamin.peterson, larry resolution: -> fixed stage: needs patch -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 18:34:18 2016 From: report at bugs.python.org (Ned Deily) Date: Wed, 15 Jun 2016 22:34:18 +0000 Subject: [issue26930] Upgrade installers to OpenSSL 1.0.2h In-Reply-To: <1462285174.78.0.332365810571.issue26930@psf.upfronthosting.co.za> Message-ID: <1466030058.77.0.748070292038.issue26930@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- priority: critical -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 18:40:39 2016 From: report at bugs.python.org (Larry Hastings) Date: Wed, 15 Jun 2016 22:40:39 +0000 Subject: [issue26930] Upgrade installers to OpenSSL 1.0.2h In-Reply-To: <1462285174.78.0.332365810571.issue26930@psf.upfronthosting.co.za> Message-ID: <1466030439.91.0.717059891984.issue26930@psf.upfronthosting.co.za> Larry Hastings added the comment: Yes, I'll accept this for 3.5.2 final. Steve: do I need to do anything besides cherry-pick these revisions? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 19:29:58 2016 From: report at bugs.python.org (Caleb Hattingh) Date: Wed, 15 Jun 2016 23:29:58 +0000 Subject: [issue25572] _ssl doesn't build on OSX 10.11 In-Reply-To: <1446845399.36.0.0648529481801.issue25572@psf.upfronthosting.co.za> Message-ID: <1466033398.07.0.813631549157.issue25572@psf.upfronthosting.co.za> Changes by Caleb Hattingh : ---------- nosy: +cjrh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 19:33:32 2016 From: report at bugs.python.org (Ned Deily) Date: Wed, 15 Jun 2016 23:33:32 +0000 Subject: [issue25572] _ssl doesn't build on OSX 10.11 In-Reply-To: <1446845399.36.0.0648529481801.issue25572@psf.upfronthosting.co.za> Message-ID: <1466033612.46.0.513116054238.issue25572@psf.upfronthosting.co.za> Ned Deily added the comment: Note that the Python Developer's Guide now contains instructions for how to build on OS X with third-party versions of OpenSSL: https://docs.python.org/devguide/setup.html#build-dependencies ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 22:09:24 2016 From: report at bugs.python.org (Pedro Lacerda) Date: Thu, 16 Jun 2016 02:09:24 +0000 Subject: [issue27320] ./setup.py --help-commands should sort extra commands In-Reply-To: <1465926347.78.0.17877088837.issue27320@psf.upfronthosting.co.za> Message-ID: <1466042964.22.0.0948827595234.issue27320@psf.upfronthosting.co.za> Pedro Lacerda added the comment: Please look if these simple patches are acceptable. I don't know if standard commands are already in a sane order or if it also need to be sorted. ---------- keywords: +patch nosy: +Pedro Lacerda Added file: http://bugs.python.org/file43402/sortextra.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 15 22:09:32 2016 From: report at bugs.python.org (Pedro Lacerda) Date: Thu, 16 Jun 2016 02:09:32 +0000 Subject: [issue27320] ./setup.py --help-commands should sort extra commands In-Reply-To: <1465926347.78.0.17877088837.issue27320@psf.upfronthosting.co.za> Message-ID: <1466042972.35.0.624732949076.issue27320@psf.upfronthosting.co.za> Changes by Pedro Lacerda : Added file: http://bugs.python.org/file43403/sortcommands.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 00:02:39 2016 From: report at bugs.python.org (Steve Dower) Date: Thu, 16 Jun 2016 04:02:39 +0000 Subject: [issue26930] Upgrade installers to OpenSSL 1.0.2h In-Reply-To: <1462285174.78.0.332365810571.issue26930@psf.upfronthosting.co.za> Message-ID: <1466049759.76.0.258123241343.issue26930@psf.upfronthosting.co.za> Steve Dower added the comment: That should be enough from your side, but let me run a test build before you tag in case we need to fix anything. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 00:19:55 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 16 Jun 2016 04:19:55 +0000 Subject: [issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more In-Reply-To: <1464270042.87.0.0233765451432.issue27130@psf.upfronthosting.co.za> Message-ID: <1466050795.6.0.997598199611.issue27130@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for working on this. I did a pass over your patch and left a bunch of comments. ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 00:36:20 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 16 Jun 2016 04:36:20 +0000 Subject: [issue27328] Documentation corrections for email defects Message-ID: <1466051780.69.0.693934528135.issue27328@psf.upfronthosting.co.za> New submission from Martin Panter: In trying to understand the defects from parsing an email Message object, and trying to use the raise_on_defect=True mode, I found a few inconsistencies with the documentation. I made a preliminary patch, but it may need adjusting. 1. There is no class called email.errors.Defect. My patch just removes the sentences mentioning this class. But an alternative might be to say handle/register_defect() are called with a subclass of MessageDefect. 2. Some defects are never raised, even if the policy says they should. I changed some of the wording to be less strict. But later I discovered Issue 24364, so perhaps this is actually an implementation bug instead. 3(a). MessageDefect is an exception class, and its subclasses are raised directly with raise_on_defect=True. However the documentation is explicit that defect classes are not exceptions. 3(b). If you assume defects are not exceptions, the documentation leads you to expect a defect will raise Message/Header(Parse)Error. But the defect exception classes that are raised are not even subclasses of MessageError. ---------- components: email files: defect-doc.patch keywords: patch messages: 268640 nosy: barry, martin.panter, r.david.murray priority: normal severity: normal status: open title: Documentation corrections for email defects versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43404/defect-doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 00:38:10 2016 From: report at bugs.python.org (Jeffrey Esquivel Sibaja) Date: Thu, 16 Jun 2016 04:38:10 +0000 Subject: [issue27329] Document behavior when CDLL is called with None as an argument on POSIX systems Message-ID: <1466051890.42.0.656698778102.issue27329@psf.upfronthosting.co.za> New submission from Jeffrey Esquivel Sibaja: On POSIX systems, when CDLL is called with None as an argument, it will call the system's dlopen() library function with NULL as it's filename parameter, causing the following behavior (as documented on dlopen's manpage): "If filename is NULL, then the returned handle is for the main program. When given to dlsym(), this handle causes a search for a symbol in the main program, followed by all shared objects loaded at program startup, and then all shared objects loaded by dlopen() with the flag RTLD_GLOBAL." But right now, this behavior is not explicitly documented anywhere which means users need to read ctypes' source code to find out if this would work. ---------- assignee: docs at python components: Documentation, ctypes messages: 268641 nosy: Jeffrey Esquivel Sibaja, docs at python priority: normal severity: normal status: open title: Document behavior when CDLL is called with None as an argument on POSIX systems type: enhancement versions: Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 00:38:17 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 16 Jun 2016 04:38:17 +0000 Subject: [issue24364] Not all defects pass through email policy In-Reply-To: <1433263153.11.0.33312264244.issue24364@psf.upfronthosting.co.za> Message-ID: <1466051897.22.0.558626893653.issue24364@psf.upfronthosting.co.za> Martin Panter added the comment: In particular, I noticed InvalidHeaderDefect is not raised if a header line begins with a colon (:), and also MisplacedEnvelopeHeaderDefect, if a header line begins "From ", including a space, and is neither the first or last line of the header section. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 00:48:22 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 16 Jun 2016 04:48:22 +0000 Subject: [issue27329] Document behavior when CDLL is called with None as an argument on POSIX systems In-Reply-To: <1466051890.42.0.656698778102.issue27329@psf.upfronthosting.co.za> Message-ID: <1466052502.91.0.935911120032.issue27329@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 02:00:59 2016 From: report at bugs.python.org (Pedro Lacerda) Date: Thu, 16 Jun 2016 06:00:59 +0000 Subject: [issue26836] Add memfd_create to os module In-Reply-To: <1461506163.13.0.0180353008827.issue26836@psf.upfronthosting.co.za> Message-ID: <1466056859.63.0.34840931303.issue26836@psf.upfronthosting.co.za> Pedro Lacerda added the comment: Maybe useful at mmapmodule.c replacing /* SVR4 method to map anonymous memory is to open /dev/zero */ fd = devzero = _Py_open("/dev/zero", O_RDWR); tagname is unused at UNIX version of new_mmap_object() so if provided something like could be added for Linux only fd = memfd_create(tagname, O_RDWR); ---------- nosy: +Pedro Lacerda _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 02:17:21 2016 From: report at bugs.python.org (Pedro Lacerda) Date: Thu, 16 Jun 2016 06:17:21 +0000 Subject: [issue27268] Incorrect error message on float('') In-Reply-To: <1465396464.66.0.148764915141.issue27268@psf.upfronthosting.co.za> Message-ID: <1466057841.56.0.789454752599.issue27268@psf.upfronthosting.co.za> Pedro Lacerda added the comment: Following the bug pointed by Adam and Eryk. ---------- keywords: +patch nosy: +Pedro Lacerda Added file: http://bugs.python.org/file43405/float.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 02:52:58 2016 From: report at bugs.python.org (Pedro Lacerda) Date: Thu, 16 Jun 2016 06:52:58 +0000 Subject: [issue27258] Exception in BytesGenerator.flatten In-Reply-To: <1465329163.65.0.664069941673.issue27258@psf.upfronthosting.co.za> Message-ID: <1466059978.54.0.364108003263.issue27258@psf.upfronthosting.co.za> Pedro Lacerda added the comment: I was unable to reproduce this bug using the following snippet import email, sys from email.generator import BytesGenerator from email.mime.text import MIMEText fp = open('flatten-exception.mail', 'rb') email.message_from_binary_file(fp) bs = BytesGenerator(sys.stdout.buffer) bs.flatten(MIMEText('msg', 'plain', 'utf-8')) ---------- nosy: +Pedro Lacerda _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 03:27:17 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Jun 2016 07:27:17 +0000 Subject: [issue27330] Possible leaks in ctypes Message-ID: <1466062037.29.0.101937444984.issue27330@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch fixes memory leaks in ctypes in case of errors. ---------- components: Extension Modules, ctypes files: ctypes_leaks.patch keywords: patch messages: 268646 nosy: amaury.forgeotdarc, belopolsky, meador.inge, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Possible leaks in ctypes type: resource usage versions: Python 2.7, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43406/ctypes_leaks.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 03:27:46 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Thu, 16 Jun 2016 07:27:46 +0000 Subject: [issue27165] Skip callables when displaying exception fields in cgitb In-Reply-To: <1464689112.02.0.764355408735.issue27165@psf.upfronthosting.co.za> Message-ID: <1466062066.92.0.503102656521.issue27165@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Hi Adam, Thanks for the patch. I reviewed it. It's a good change. As you mentioned in the comments, making both HTML and Text formatter behave consistently and skip, underscores, callables, _callables will be a good idea. Please include change. Also, if there is a test coverage for this change, it will be great. Thanks! ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 03:45:54 2016 From: report at bugs.python.org (Jaysinh shukla) Date: Thu, 16 Jun 2016 07:45:54 +0000 Subject: [issue6057] sqlite3 error classes should be documented In-Reply-To: <1242673346.43.0.948670169284.issue6057@psf.upfronthosting.co.za> Message-ID: <1466063154.07.0.0795527050188.issue6057@psf.upfronthosting.co.za> Changes by Jaysinh shukla : ---------- nosy: +jaysinh.shukla _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 04:09:58 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 16 Jun 2016 08:09:58 +0000 Subject: [issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more In-Reply-To: <1464270042.87.0.0233765451432.issue27130@psf.upfronthosting.co.za> Message-ID: <1466064598.09.0.70281429445.issue27130@psf.upfronthosting.co.za> Xiang Zhang added the comment: I'm willing to and thanks for your work too :) I have replied to your comments and adjusted my patch accordingly. But there are still several I am confused or want to negotiate more. I now upload the adjusted patch. ---------- Added file: http://bugs.python.org/file43407/64bit_support_for_zlib_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 04:11:05 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 16 Jun 2016 08:11:05 +0000 Subject: [issue27292] Warn users that os.urandom() can return insecure values In-Reply-To: <1465639674.0.0.865291084778.issue27292@psf.upfronthosting.co.za> Message-ID: <1466064665.35.0.584174512141.issue27292@psf.upfronthosting.co.za> Martin Panter added the comment: As far as this bug goes, 3.5 is not very different from 2.7 ---------- nosy: +martin.panter versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 04:38:46 2016 From: report at bugs.python.org (Mark) Date: Thu, 16 Jun 2016 08:38:46 +0000 Subject: [issue27324] Error when building Python extension In-Reply-To: <1466009679.44.0.343577144219.issue27324@psf.upfronthosting.co.za> Message-ID: Mark added the comment: The problem is that I don't have the choice, the compiler we use for the project is VS13. Anyway, my colleagues are aware of this limitation but they could build their extensions all the same. I set the variables?as you recommended,?and the obj files have been created. But the link fails with the following error: LINK : fatal error LNK1181: impossible?to open the input file?'ucrt.lib' This library does not exist in my VS13?environment. ---- Message d'origine ---- De : Zachary Ware ? : tibo53 at netcourrier.com Objet : [issue27324] Error when building Python extension Date : 15/06/2016 18:54:39 CEST Zachary Ware added the comment: Using the wrong compiler, you may wind up with an extension that appears to work, and you may never have a problem with it if conditions are just right. This article[1] looks like a pretty good explanation of why you don't want to do it, though (note: I've only skimmed the article). If you really want to shoot yourself in the foot, you can try running vcvarsall.bat yourself, then make sure MSsdk is set (distutils doesn't care what it's set to, just that it's set), and set DISTUTILS_USE_SDK (again, doesn't matter to what). Also, note that this problem should be a thing of the past with Python 3.5+ and VS2015+. [1] http://siomsystems.com/mixing-visual-studio-versions/ ---------- _______________________________________ Python tracker _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 04:40:16 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 16 Jun 2016 08:40:16 +0000 Subject: [issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more In-Reply-To: <1464270042.87.0.0233765451432.issue27130@psf.upfronthosting.co.za> Message-ID: <1466066416.95.0.823503471739.issue27130@psf.upfronthosting.co.za> Xiang Zhang added the comment: Sorry, I suddenly find that I've misunderstood one of your comments. I changed according then. Please use the new version. ---------- Added file: http://bugs.python.org/file43408/64bit_support_for_zlib_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 05:35:19 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Jun 2016 09:35:19 +0000 Subject: [issue27140] Opcode for creating dict with constant keys In-Reply-To: <1464381640.82.0.0689379791356.issue27140@psf.upfronthosting.co.za> Message-ID: <1466069719.29.0.455481778975.issue27140@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 05:37:32 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Jun 2016 09:37:32 +0000 Subject: [issue27213] Rework CALL_FUNCTION* opcodes In-Reply-To: <1465026334.02.0.369802561902.issue27213@psf.upfronthosting.co.za> Message-ID: <1466069852.15.0.454990853455.issue27213@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Do you take this for your Demur? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 06:40:48 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 16 Jun 2016 10:40:48 +0000 Subject: [issue27331] Add a policy argument to email.mime.MIMEBase Message-ID: <1466073647.47.0.429372959399.issue27331@psf.upfronthosting.co.za> New submission from Berker Peksag: Quoting Barry's message msg268430 from issue 10839: On Jun 13, 2016, at 06:38 AM, Berker Peksag wrote: >I don't know if it's a good idea or API but can we add a 'policy' keyword >argument to email.mime.base.MIMEBase? Right now, this is the only way to >change the default policy without using high level functions like >email.message_from_string(): > > m = MIMEMultipart() > m.policy = email.policy.default I think we just need to plumb a `policy` argument through to the ultimate base class, email.message.Message ---------- components: email files: mimebase_policy.diff keywords: patch messages: 268653 nosy: barry, berker.peksag, r.david.murray priority: normal severity: normal stage: patch review status: open title: Add a policy argument to email.mime.MIMEBase type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43409/mimebase_policy.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 06:42:48 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 16 Jun 2016 10:42:48 +0000 Subject: [issue10839] email module should not allow some header field repetitions In-Reply-To: <1294263603.86.0.308955870327.issue10839@psf.upfronthosting.co.za> Message-ID: <1466073768.3.0.776711089317.issue10839@psf.upfronthosting.co.za> Berker Peksag added the comment: > Right, that's what I meant by "plumb". :) Sorry, apparently I can't read in the mornings :) I have just opened issue 27331 to implement this idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 06:56:04 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 Jun 2016 10:56:04 +0000 Subject: [issue27140] Opcode for creating dict with constant keys In-Reply-To: <1464381640.82.0.0689379791356.issue27140@psf.upfronthosting.co.za> Message-ID: <1466074564.33.0.74977688812.issue27140@psf.upfronthosting.co.za> STINNER Victor added the comment: Nice enhancement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 07:01:24 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 16 Jun 2016 11:01:24 +0000 Subject: [issue27292] Warn users that os.urandom() can return insecure values In-Reply-To: <1465639674.0.0.865291084778.issue27292@psf.upfronthosting.co.za> Message-ID: <1466074884.32.0.244004369506.issue27292@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a possible patch for 3.5+ based on my modest understanding of the concerns about insecure results and blocking. I hope that my wording is clear, couldn?t be confused with Linux?s /dev/random blocking and running out of fresh entropy, etc. I also tried to make it clearer what APIs are used in what circumstances. It is not just Linux: we also call getrandom() on Solaris, because its getentropy() is not good enough. ---------- keywords: +patch Added file: http://bugs.python.org/file43410/urandom-doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 07:05:51 2016 From: report at bugs.python.org (Lele Gaifax) Date: Thu, 16 Jun 2016 11:05:51 +0000 Subject: [issue22228] Adapt bash readline operate-and-get-next function In-Reply-To: <1408441328.29.0.0681426449148.issue22228@psf.upfronthosting.co.za> Message-ID: <1466075151.93.0.0828931054038.issue22228@psf.upfronthosting.co.za> Lele Gaifax added the comment: The patch does not apply cleanly anymore, with current 3.6a3. If there is any chance it could be taken into consideration, I will try to rebase it on top of current version. @Berker: as I don't use Rietveld, is it possible for me to reach the comment you mentioned? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 07:08:59 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 16 Jun 2016 11:08:59 +0000 Subject: [issue27258] Exception in BytesGenerator.flatten In-Reply-To: <1465329163.65.0.664069941673.issue27258@psf.upfronthosting.co.za> Message-ID: <1466075339.42.0.618198578163.issue27258@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for helping to triage this, Pedro. I think there is a typo in your example: ``email.message_from_binary_file(fp)`` needs to be passed to ``bs.flatten()``. With the following script I'm also unable to reproduce the issue in Python 3.4+: import email import email.generator import sys with open('flatten-exception.mail', 'rb') as f: msg = email.message_from_binary_file(f) gen = email.generator.BytesGenerator(sys.stdout.buffer) gen.flatten(msg) Hans-Peter, could you share a reproducer with us? Thanks! ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 07:30:27 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 16 Jun 2016 11:30:27 +0000 Subject: [issue22228] Adapt bash readline operate-and-get-next function In-Reply-To: <1408441328.29.0.0681426449148.issue22228@psf.upfronthosting.co.za> Message-ID: <1466076627.37.0.978617663134.issue22228@psf.upfronthosting.co.za> Berker Peksag added the comment: The review comments are at http://bugs.python.org/review/22228/#ps12743 (you can also click to the 'review' link above) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 07:31:02 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 16 Jun 2016 11:31:02 +0000 Subject: [issue22228] Adapt bash readline operate-and-get-next function In-Reply-To: <1408441328.29.0.0681426449148.issue22228@psf.upfronthosting.co.za> Message-ID: <1466076662.77.0.501068255551.issue22228@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 07:46:06 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 16 Jun 2016 11:46:06 +0000 Subject: [issue27330] Possible leaks in ctypes In-Reply-To: <1466062037.29.0.101937444984.issue27330@psf.upfronthosting.co.za> Message-ID: <1466077566.65.0.250964058002.issue27330@psf.upfronthosting.co.za> Martin Panter added the comment: Mostly looks good. I left a two comments. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 07:59:02 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 16 Jun 2016 11:59:02 +0000 Subject: [issue22228] Adapt bash readline operate-and-get-next function In-Reply-To: <1408441328.29.0.0681426449148.issue22228@psf.upfronthosting.co.za> Message-ID: <1466078342.1.0.322902958937.issue22228@psf.upfronthosting.co.za> Martin Panter added the comment: I will try to have a closer look at this some time, but my immediate worry is it looks like you are directly copying Bash code (GPL) into Python (less restrictive license). Perhaps a more general solution would be to expose rl_add_defun() to native Python code, if that is possible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 08:54:08 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 Jun 2016 12:54:08 +0000 Subject: [issue27292] Warn users that os.urandom() can return insecure values In-Reply-To: <1465639674.0.0.865291084778.issue27292@psf.upfronthosting.co.za> Message-ID: <1466081648.02.0.442898073685.issue27292@psf.upfronthosting.co.za> STINNER Victor added the comment: Strange, I don't see the [Review] button. .. versionchanged:: 3.5.2 - On Linux, if ``getrandom()`` blocks (the urandom entropy pool is not + If ``getrandom()`` blocks (the urandom entropy pool is not initialized yet), fall back on reading ``/dev/urandom``. Please keep "On Linux", getrandom() is also used on Solaris, and my change is really restricted to Linux. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 09:08:56 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 16 Jun 2016 13:08:56 +0000 Subject: [issue27292] Warn users that os.urandom() can return insecure values In-Reply-To: <1465639674.0.0.865291084778.issue27292@psf.upfronthosting.co.za> Message-ID: <1466082536.07.0.243810345956.issue27292@psf.upfronthosting.co.za> Martin Panter added the comment: Rebased so Rietveld can work with it, earlier version was my fault. As far as I can see (looking at Python/random.c and configure.ac), the Solaris version should also use GRND_NONBLOCK: #ifdef MS_WINDOWS #elif defined(HAVE_GETENTROPY) && !defined(sun) #else #if defined(HAVE_GETRANDOM) || defined(HAVE_GETRANDOM_SYSCALL) const int flags = GRND_NONBLOCK; #ifdef HAVE_GETRANDOM n = getrandom(dest, n, flags); #else n = syscall(SYS_getrandom, dest, n, flags); #endif Apart from using a C function call versus syscall(), I don?t see there is much difference between the Solaris and Linux cases. Correct me if I?m wrong though. ---------- Added file: http://bugs.python.org/file43411/urandom-doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 09:09:59 2016 From: report at bugs.python.org (GuiHome) Date: Thu, 16 Jun 2016 13:09:59 +0000 Subject: [issue24424] xml.dom.minidom: performance issue with Node.insertBefore() In-Reply-To: <1433942956.66.0.599460998017.issue24424@psf.upfronthosting.co.za> Message-ID: <1466082599.37.0.0517482144205.issue24424@psf.upfronthosting.co.za> GuiHome added the comment: kindly ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 09:14:20 2016 From: report at bugs.python.org (Lele Gaifax) Date: Thu, 16 Jun 2016 13:14:20 +0000 Subject: [issue22228] Adapt bash readline operate-and-get-next function In-Reply-To: <1408441328.29.0.0681426449148.issue22228@psf.upfronthosting.co.za> Message-ID: <1466082860.44.0.0477512627037.issue22228@psf.upfronthosting.co.za> Lele Gaifax added the comment: I will try to address your concerns. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 09:14:27 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 Jun 2016 13:14:27 +0000 Subject: [issue27292] Warn users that os.urandom() can return insecure values In-Reply-To: <1465639674.0.0.865291084778.issue27292@psf.upfronthosting.co.za> Message-ID: <1466082867.89.0.114221085666.issue27292@psf.upfronthosting.co.za> STINNER Victor added the comment: > As far as I can see (looking at Python/random.c and configure.ac), the Solaris version should also use GRND_NONBLOCK: Oh, you're right: I didn't notice that GRND_NONBLOCK was also used on Solaris. The change is not deliberate, but it is good to do that :-) Solaris getrandom() is documented to fail with EAGAIN if "No entropy is available and GRND_NONBLOCK is set." https://docs.oracle.com/cd/E53394_01/html/E54765/getrandom-2.html The question is more if reading from /dev/urandom block in this case. If we don't know, I would prefer to keep the "On Linux" prefix in the doc, and don't say anything about Solaris. I'm able to check the behaviour of Solaris. You should contact the developers who get access to Solaris, you can meet them in the previous random issues specific to Solaris: issue #25003 and issue #26735. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 09:24:55 2016 From: report at bugs.python.org (Donald Stufft) Date: Thu, 16 Jun 2016 13:24:55 +0000 Subject: [issue27292] Warn users that os.urandom() can return insecure values In-Reply-To: <1465639674.0.0.865291084778.issue27292@psf.upfronthosting.co.za> Message-ID: <1466083495.46.0.33021090574.issue27292@psf.upfronthosting.co.za> Changes by Donald Stufft : ---------- nosy: -dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 09:24:57 2016 From: report at bugs.python.org (Jaysinh shukla) Date: Thu, 16 Jun 2016 13:24:57 +0000 Subject: [issue6057] sqlite3 error classes should be documented In-Reply-To: <1242673346.43.0.948670169284.issue6057@psf.upfronthosting.co.za> Message-ID: <1466083497.0.0.834556174189.issue6057@psf.upfronthosting.co.za> Jaysinh shukla added the comment: Submitting the patch for Python 3.6. ---------- keywords: +patch Added file: http://bugs.python.org/file43412/issue6057_python3_6.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 09:25:17 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Jun 2016 13:25:17 +0000 Subject: [issue22636] avoid using a shell in ctypes.util: replace os.popen with subprocess In-Reply-To: <1413325975.89.0.175884398711.issue22636@psf.upfronthosting.co.za> Message-ID: <1466083517.11.0.654037389889.issue22636@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: ctypes_util_popen-6.py2.patch LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 09:25:57 2016 From: report at bugs.python.org (Donald Stufft) Date: Thu, 16 Jun 2016 13:25:57 +0000 Subject: [issue27288] secrets should use getrandom() on Linux In-Reply-To: <1465588599.3.0.867244099768.issue27288@psf.upfronthosting.co.za> Message-ID: <1466083557.58.0.589939468617.issue27288@psf.upfronthosting.co.za> Changes by Donald Stufft : ---------- nosy: -dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 09:26:11 2016 From: report at bugs.python.org (Donald Stufft) Date: Thu, 16 Jun 2016 13:26:11 +0000 Subject: [issue27297] Add support for /dev/random to "secrets" In-Reply-To: <1465670075.28.0.237473871841.issue27297@psf.upfronthosting.co.za> Message-ID: <1466083571.08.0.449482192327.issue27297@psf.upfronthosting.co.za> Changes by Donald Stufft : ---------- nosy: -dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 09:26:26 2016 From: report at bugs.python.org (Donald Stufft) Date: Thu, 16 Jun 2016 13:26:26 +0000 Subject: [issue27250] Add os.urandom_block() In-Reply-To: <1465302067.94.0.484576804121.issue27250@psf.upfronthosting.co.za> Message-ID: <1466083586.88.0.608072052426.issue27250@psf.upfronthosting.co.za> Changes by Donald Stufft : ---------- nosy: -dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 09:26:47 2016 From: report at bugs.python.org (Donald Stufft) Date: Thu, 16 Jun 2016 13:26:47 +0000 Subject: [issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom() In-Reply-To: <1465377543.28.0.588369041234.issue27266@psf.upfronthosting.co.za> Message-ID: <1466083607.69.0.121987652541.issue27266@psf.upfronthosting.co.za> Changes by Donald Stufft : ---------- nosy: -dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 09:27:05 2016 From: report at bugs.python.org (Donald Stufft) Date: Thu, 16 Jun 2016 13:27:05 +0000 Subject: [issue27282] Raise BlockingIOError in os.urandom if kernel is not ready In-Reply-To: <1465492471.33.0.216651020658.issue27282@psf.upfronthosting.co.za> Message-ID: <1466083625.39.0.416653487658.issue27282@psf.upfronthosting.co.za> Changes by Donald Stufft : ---------- nosy: -dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 10:01:21 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 16 Jun 2016 14:01:21 +0000 Subject: [issue24424] xml.dom.minidom: performance issue with Node.insertBefore() In-Reply-To: <1433942956.66.0.599460998017.issue24424@psf.upfronthosting.co.za> Message-ID: <1466085681.67.0.566855932907.issue24424@psf.upfronthosting.co.za> Berker Peksag added the comment: Please attach the patch in unified diff format. See https://docs.python.org/devguide/patch.html for details. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 10:12:34 2016 From: report at bugs.python.org (Jaysinh shukla) Date: Thu, 16 Jun 2016 14:12:34 +0000 Subject: [issue6057] sqlite3 error classes should be documented In-Reply-To: <1242673346.43.0.948670169284.issue6057@psf.upfronthosting.co.za> Message-ID: <1466086354.05.0.450752087713.issue6057@psf.upfronthosting.co.za> Jaysinh shukla added the comment: Adding forgotten reference of ProgrammingError to last patch. Please review issue6057_python3_6_v2.diff Thanks! ---------- Added file: http://bugs.python.org/file43413/issue6057_python3_6_v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 10:52:52 2016 From: report at bugs.python.org (Robert Haschke) Date: Thu, 16 Jun 2016 14:52:52 +0000 Subject: [issue24424] xml.dom.minidom: performance issue with Node.insertBefore() In-Reply-To: <1433942956.66.0.599460998017.issue24424@psf.upfronthosting.co.za> Message-ID: <1466088772.73.0.603292219794.issue24424@psf.upfronthosting.co.za> Robert Haschke added the comment: Uploaded a "hg diff" against the recent 2.7 branch of the source repo. ---------- Added file: http://bugs.python.org/file43414/minidom.insertBefore.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 11:10:32 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 16 Jun 2016 15:10:32 +0000 Subject: [issue26985] Information about CodeType in inspect documentation is outdated In-Reply-To: <1462803102.24.0.542356144335.issue26985@psf.upfronthosting.co.za> Message-ID: <1466089832.98.0.730084188025.issue26985@psf.upfronthosting.co.za> Xiang Zhang added the comment: Hmm, when I am going to delete the list in the docstring, I find other functions get lists too in inspect.py. So maybe we should open another issue to clean them after first merging this thread? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 11:20:04 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 16 Jun 2016 15:20:04 +0000 Subject: [issue24424] xml.dom.minidom: performance issue with Node.insertBefore() In-Reply-To: <1433942956.66.0.599460998017.issue24424@psf.upfronthosting.co.za> Message-ID: <1466090404.76.0.407396256283.issue24424@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 11:31:46 2016 From: report at bugs.python.org (Hans-Peter Jansen) Date: Thu, 16 Jun 2016 15:31:46 +0000 Subject: [issue27258] Exception in BytesGenerator.flatten In-Reply-To: <1465329163.65.0.664069941673.issue27258@psf.upfronthosting.co.za> Message-ID: <1466091106.6.0.701325001635.issue27258@psf.upfronthosting.co.za> Hans-Peter Jansen added the comment: Sorry guys for not providing this earlier. It turned out, that the sub optimal behaviour is related to a unfortunate policy choice: email.policy.SMTP. ---------- Added file: http://bugs.python.org/file43415/email_flatten.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 11:33:06 2016 From: report at bugs.python.org (Hans-Peter Jansen) Date: Thu, 16 Jun 2016 15:33:06 +0000 Subject: [issue27257] get_addresses results in traceback with an addrspec with an empty local part. In-Reply-To: <1465327493.81.0.354921385455.issue27257@psf.upfronthosting.co.za> Message-ID: <1466091186.11.0.191085180175.issue27257@psf.upfronthosting.co.za> Hans-Peter Jansen added the comment: Sorry guys for not providing this earlier. It turned out, that the sub optimal behaviour is related to a unfortunate policy choice: email.policy.SMTP. ---------- Added file: http://bugs.python.org/file43416/email_flatten.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 11:33:50 2016 From: report at bugs.python.org (Hans-Peter Jansen) Date: Thu, 16 Jun 2016 15:33:50 +0000 Subject: [issue27256] email header indentation destroyed In-Reply-To: <1465326886.85.0.738328133832.issue27256@psf.upfronthosting.co.za> Message-ID: <1466091230.58.0.392740001552.issue27256@psf.upfronthosting.co.za> Hans-Peter Jansen added the comment: Sorry guys for not providing this earlier. It turned out, that the sub optimal behaviour is related to a unfortunate policy choice: email.policy.SMTP. ---------- Added file: http://bugs.python.org/file43417/email_flatten.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 11:37:13 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 Jun 2016 15:37:13 +0000 Subject: [issue26171] heap overflow in zipimporter module In-Reply-To: <1453348353.03.0.314168195173.issue26171@psf.upfronthosting.co.za> Message-ID: <1466091433.18.0.812075978496.issue26171@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- versions: +Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 12:33:33 2016 From: report at bugs.python.org (Petr Viktorin) Date: Thu, 16 Jun 2016 16:33:33 +0000 Subject: [issue27332] Clinic: first parameter for module-level functions should be PyObject*, not PyModuleDef* Message-ID: <1466094813.1.0.702835277792.issue27332@psf.upfronthosting.co.za> New submission from Petr Viktorin: Currently, Argument Clinic generates "PyModuleDef * module" for the first argument of module-level functions. But, the functions are passed the actual module object, not the ModuleDef. The correct type to use is PyObject*, which is used for modules in the PyModule_* API. (It turns out nothing in core Python currently uses the argument except passing it to other _impl functions, but this could change as PEP 489 is improved upon.) The attached patch contains manual changes only. Please run `make clinic` after applying it to regenerate allll the code. ---------- components: Argument Clinic files: 0001-clinic-Switch-the-module-argument-to-PyObject.patch keywords: patch messages: 268676 nosy: encukou, larry, ncoghlan priority: normal severity: normal status: open title: Clinic: first parameter for module-level functions should be PyObject*, not PyModuleDef* versions: Python 3.6 Added file: http://bugs.python.org/file43418/0001-clinic-Switch-the-module-argument-to-PyObject.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 12:36:25 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 16 Jun 2016 16:36:25 +0000 Subject: [issue27333] validate_step in rangeobject.c, incorrect code logic but right result Message-ID: <1466094985.85.0.664632093379.issue27333@psf.upfronthosting.co.za> New submission from Xiang Zhang: Here is a drawback in validate_step of rangeobject. PyNumber_AsSsize_t returns clipped value and won't set an exception when the argument *exc* is set NULL. So if step overflows, istep is always PY_SSIZE_MAX or PY_SSIZE_MIN. But the following code is to check if istep is -1 and there is an exception. The code actually conflicts. But fortunately the result is always right. I suggest to make the code logic right. ---------- files: incorrect_logic_in_validate_step.patch keywords: patch messages: 268677 nosy: xiang.zhang priority: normal severity: normal status: open title: validate_step in rangeobject.c, incorrect code logic but right result Added file: http://bugs.python.org/file43419/incorrect_logic_in_validate_step.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 12:41:04 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 16 Jun 2016 16:41:04 +0000 Subject: [issue27333] validate_step in rangeobject.c, incorrect code logic but right result In-Reply-To: <1466094985.85.0.664632093379.issue27333@psf.upfronthosting.co.za> Message-ID: <1466095264.31.0.0702783795086.issue27333@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- components: +Interpreter Core type: -> behavior versions: +Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 12:45:50 2016 From: report at bugs.python.org (Luca Citi) Date: Thu, 16 Jun 2016 16:45:50 +0000 Subject: [issue27334] pysqlite3 context manager not performing rollback when a database is locked elsewhere for non-DML statements Message-ID: <1466095550.35.0.353945818907.issue27334@psf.upfronthosting.co.za> New submission from Luca Citi: I have reported this bug to the pysqlite module for python2 ( https://github.com/ghaering/pysqlite/issues/103 ) but I also report it here because it applies to python3 too. The pysqlite3 context manager does not perform a rollback when a transaction fails because the database is locked by some other process performing non-DML statements (e.g. during the sqlite3 command line .dump method). To reproduce the problem, open a terminal and run the following: ```bash sqlite3 /tmp/test.db 'drop table person; create table person (id integer primary key, firstname varchar)' echo -e 'begin transaction;\nselect * from person;\n.system sleep 1000\nrollback;' | sqlite3 /tmp/test.db ``` Leave this shell running and run the python3 interpreter from a different shell, then type: ```python import sqlite3 con = sqlite3.connect('/tmp/test.db') with con: con.execute("insert into person(firstname) values (?)", ("Jan",)) pass ``` You should receive the following: ``` 1 with con: 2 con.execute("insert into person(firstname) values (?)", ("Jan",)) ----> 3 pass 4 OperationalError: database is locked ``` Without exiting python, switch back to the first shell and kill the `'echo ... | sqlite3'` process. Then run: ```bash sqlite3 /tmp/test.db .dump ``` you should get: ``` PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; /**** ERROR: (5) database is locked *****/ ROLLBACK; -- due to errors ``` This means that the python process never executed a `rollback` and is still holding the lock. To release the lock one can exit python (clearly, this is not the intended behaviour of the context manager). I believe the reason for this problem is that the exception happened in the implicit `commit` that is run on exiting the context manager, rather than inside it. In fact the exception is in the `pass` line rather than in the `execute` line. This exception did not trigger a `rollback` because the it happened after `pysqlite_connection_exit` checks for exceptions. The expected behaviour (pysqlite3 rolling back and releasing the lock) is recovered if the initial blocking process is a Data Modification Language (DML) statement, e.g.: ```bash echo -e 'begin transaction; insert into person(firstname) values ("James");\n.system sleep 1000\nrollback;' | sqlite3 /tmp/test.db ``` because this raises an exception at the `execute` time rather than at `commit` time. To fix this problem, I think the `pysqlite_connection_exit` function in src/connection.c should handle the case when the commit itself raises an exception, and invoke a rollback. Please see patch attached. ---------- components: Extension Modules files: fix_pysqlite_connection_exit.patch keywords: patch messages: 268678 nosy: lciti priority: normal severity: normal status: open title: pysqlite3 context manager not performing rollback when a database is locked elsewhere for non-DML statements versions: Python 3.6 Added file: http://bugs.python.org/file43420/fix_pysqlite_connection_exit.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 13:11:08 2016 From: report at bugs.python.org (Julio C Cardoza) Date: Thu, 16 Jun 2016 17:11:08 +0000 Subject: [issue27139] Increased test coverage for statistics.median_grouped In-Reply-To: <1464446645.63.0.403096467331.issue27139@psf.upfronthosting.co.za> Message-ID: <1466097068.41.0.486527166737.issue27139@psf.upfronthosting.co.za> Julio C Cardoza added the comment: Updated patch file to condense four functions into one function ---------- Added file: http://bugs.python.org/file43421/test_median_grouped.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 13:13:01 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 16 Jun 2016 17:13:01 +0000 Subject: [issue27334] pysqlite3 context manager not performing rollback when a database is locked elsewhere for non-DML statements In-Reply-To: <1466095550.35.0.353945818907.issue27334@psf.upfronthosting.co.za> Message-ID: <1466097181.38.0.907729066207.issue27334@psf.upfronthosting.co.za> Berker Peksag added the comment: You may also want to check that the method_name is "commit". A test case would nice to have. Note that the connection context manager will still fail cases like nested context managers. See issue 16958. ---------- nosy: +berker.peksag, ghaering stage: -> patch review type: -> behavior versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 13:17:28 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Thu, 16 Jun 2016 17:17:28 +0000 Subject: [issue27139] Increased test coverage for statistics.median_grouped In-Reply-To: <1466097068.41.0.486527166737.issue27139@psf.upfronthosting.co.za> Message-ID: <20160616171722.GE27919@ando.pearwood.info> Steven D'Aprano added the comment: Thanks Julio, I hope to get to this over the next week. Please feel free to prod me if you see no action by then. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 13:33:38 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 16 Jun 2016 17:33:38 +0000 Subject: [issue24887] Sqlite3 has no option to provide open flags In-Reply-To: <1439898126.92.0.460778309784.issue24887@psf.upfronthosting.co.za> Message-ID: <1466098418.29.0.409539316733.issue24887@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> out of date stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 13:35:01 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Thu, 16 Jun 2016 17:35:01 +0000 Subject: [issue27335] Clarify that writing to locals() inside a class body is supported Message-ID: <1466098501.84.0.0349098094976.issue27335@psf.upfronthosting.co.za> New submission from Steven D'Aprano: The docs for locals() warn not to write to the dict returned, as it may not have the intended effect of modifying the actual variables seen by the interpreter. https://docs.python.org/3/library/functions.html#locals But as I understanding it, using locals() inside a class body is intentionally supported: class K: locals()['x'] = 1 assert K.x == 1 is not just an accident of implementation, but the intended behaviour and a language guarantee. ---------- assignee: docs at python components: Documentation messages: 268682 nosy: docs at python, steven.daprano priority: normal severity: normal status: open title: Clarify that writing to locals() inside a class body is supported versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 13:37:44 2016 From: report at bugs.python.org (Alex Willmer) Date: Thu, 16 Jun 2016 17:37:44 +0000 Subject: [issue27336] --without-threads build fails due to undeclared _PyGILState_check_enabled Message-ID: <1466098664.28.0.417925542114.issue27336@psf.upfronthosting.co.za> New submission from Alex Willmer: Building current tip (rev 102062:3d726dbfca31), on Ubuntu 16.04/x86_64, using --without-thread fails; with the following error gcc -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -I. -IInclude -I./Include -DPy_BUILD_CORE -o Python/pylifecycle.o Python/pylifecycle.c Python/pylifecycle.c: In function ?Py_NewInterpreter?: Python/pylifecycle.c:751:5: error: ?_PyGILState_check_enabled? undeclared (first use in this function) _PyGILState_check_enabled = 0; ^ Python/pylifecycle.c:751:5: note: each undeclared identifier is reported only once for each function it appears in Makefile:1575: recipe for target 'Python/pylifecycle.o' failed make: *** [Python/pylifecycle.o] Error 1 I've attached the full build log. ---------- components: Build files: without-threads.build.log messages: 268683 nosy: Alex.Willmer priority: normal severity: normal status: open title: --without-threads build fails due to undeclared _PyGILState_check_enabled versions: Python 3.6 Added file: http://bugs.python.org/file43422/without-threads.build.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 14:04:30 2016 From: report at bugs.python.org (Peter Eisentraut) Date: Thu, 16 Jun 2016 18:04:30 +0000 Subject: [issue27337] 3.6.0a2 tarball has weird paths Message-ID: <1466100270.24.0.259127068452.issue27337@psf.upfronthosting.co.za> New submission from Peter Eisentraut: The file Python-3.6.0a2.tgz contains paths that start with "..", e.g., $ tar tf Python-3.6.0a2.tgz | head ../Python-3.6.0a2/ ../Python-3.6.0a2/Doc/ ../Python-3.6.0a2/Grammar/ ../Python-3.6.0a2/Include/ ../Python-3.6.0a2/LICENSE ../Python-3.6.0a2/Lib/ ../Python-3.6.0a2/Mac/ ../Python-3.6.0a2/Makefile.pre.in ../Python-3.6.0a2/Misc/ ../Python-3.6.0a2/Modules/ This causes tar to error out when unpacking the file. This was not the case in previous tarballs and also not in Python-3.6.0a2.tar.xz. ---------- components: Build messages: 268684 nosy: petere priority: normal severity: normal status: open title: 3.6.0a2 tarball has weird paths versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 14:05:15 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 16 Jun 2016 18:05:15 +0000 Subject: [issue27337] 3.6.0a2 tarball has weird paths In-Reply-To: <1466100270.24.0.259127068452.issue27337@psf.upfronthosting.co.za> Message-ID: <1466100315.31.0.00590955109935.issue27337@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 14:09:20 2016 From: report at bugs.python.org (Ned Deily) Date: Thu, 16 Jun 2016 18:09:20 +0000 Subject: [issue27337] 3.6.0a2 tarball has weird paths In-Reply-To: <1466100270.24.0.259127068452.issue27337@psf.upfronthosting.co.za> Message-ID: <1466100560.03.0.548603543033.issue27337@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- assignee: -> ned.deily priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 14:15:10 2016 From: report at bugs.python.org (Christoph Gohlke) Date: Thu, 16 Jun 2016 18:15:10 +0000 Subject: [issue27305] Crash with "pip list --outdated" on Windows 10 with Python 2.7.12rc1 In-Reply-To: <1465820074.65.0.989290191732.issue27305@psf.upfronthosting.co.za> Message-ID: <1466100910.79.0.904565113679.issue27305@psf.upfronthosting.co.za> Changes by Christoph Gohlke : ---------- nosy: +cgohlke _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 14:44:53 2016 From: report at bugs.python.org (Ned Deily) Date: Thu, 16 Jun 2016 18:44:53 +0000 Subject: [issue27337] 3.6.0a2 tarball has weird paths In-Reply-To: <1466100270.24.0.259127068452.issue27337@psf.upfronthosting.co.za> Message-ID: <1466102693.93.0.930073590566.issue27337@psf.upfronthosting.co.za> Ned Deily added the comment: That's unfortunate and my fault, basically, the .tgz tarball was built with a BSD-ish while the .xz one was built with GNU tar, as intended. I hate to do a stealth update, unless absolutely necessary, and I don't get see any errors unpacking the .tgz one with a recent GNU tar. Can you say with which version of tar and on what platform you see the tar failure? I'll make sure it doesn't happen in subsequent releases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 14:45:44 2016 From: report at bugs.python.org (Ned Deily) Date: Thu, 16 Jun 2016 18:45:44 +0000 Subject: [issue27337] 3.6.0a2 tarball has weird paths In-Reply-To: <1466100270.24.0.259127068452.issue27337@psf.upfronthosting.co.za> Message-ID: <1466102744.82.0.5545326561.issue27337@psf.upfronthosting.co.za> Ned Deily added the comment: That's unfortunate and my fault, basically, the .tgz tarball was built with a BSD-ish tar while the .xz one was built with a GNU tar, as intended. I hate to do a stealth update, unless absolutely necessary, and I don't get see any errors unpacking the .tgz one with a recent GNU tar. Can you say with which version of tar and on what platform you see the tar failure? I'll make sure it doesn't happen in subsequent releases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 14:45:54 2016 From: report at bugs.python.org (Ned Deily) Date: Thu, 16 Jun 2016 18:45:54 +0000 Subject: [issue27337] 3.6.0a2 tarball has weird paths In-Reply-To: <1466100270.24.0.259127068452.issue27337@psf.upfronthosting.co.za> Message-ID: <1466102754.61.0.779833661853.issue27337@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- Removed message: http://bugs.python.org/msg268685 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 14:47:37 2016 From: report at bugs.python.org (Audric D'Hoest (Dr. Pariolo)) Date: Thu, 16 Jun 2016 18:47:37 +0000 Subject: [issue27338] python 2.7 platform.system reports wrong Message-ID: <1466102857.11.0.587490522891.issue27338@psf.upfronthosting.co.za> New submission from Audric D'Hoest (Dr. Pariolo): Mac mini late 2014, upgraded to El capitan. Out of the box python 2.7 reports the wrong system info. platform.system() should report El Capitan platform.release() should report 10.11.5 ---------- components: Macintosh files: pybug.png messages: 268687 nosy: Audric D'Hoest (Dr. Pariolo), ned.deily, ronaldoussoren priority: normal severity: normal status: open title: python 2.7 platform.system reports wrong versions: Python 2.7 Added file: http://bugs.python.org/file43423/pybug.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 14:55:36 2016 From: report at bugs.python.org (Audric D'Hoest (Dr. Pariolo)) Date: Thu, 16 Jun 2016 18:55:36 +0000 Subject: [issue27338] python 2.7 platform.system reports wrong on Mac OS X El Capitan In-Reply-To: <1466102857.11.0.587490522891.issue27338@psf.upfronthosting.co.za> Message-ID: <1466103336.06.0.573070861304.issue27338@psf.upfronthosting.co.za> Changes by Audric D'Hoest (Dr. Pariolo) : ---------- title: python 2.7 platform.system reports wrong -> python 2.7 platform.system reports wrong on Mac OS X El Capitan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 15:10:50 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 16 Jun 2016 19:10:50 +0000 Subject: [issue27330] Possible leaks in ctypes In-Reply-To: <1466062037.29.0.101937444984.issue27330@psf.upfronthosting.co.za> Message-ID: <20160616191035.67070.29528.D9923F42@psf.io> Roundup Robot added the comment: New changeset e04c054beb53 by Serhiy Storchaka in branch '2.7': Issue #27330: Fixed possible leaks in the ctypes module. https://hg.python.org/cpython/rev/e04c054beb53 New changeset 41f99ee19804 by Serhiy Storchaka in branch '3.5': Issue #27330: Fixed possible leaks in the ctypes module. https://hg.python.org/cpython/rev/41f99ee19804 New changeset 27e7945c4ecd by Serhiy Storchaka in branch 'default': Issue #27330: Fixed possible leaks in the ctypes module. https://hg.python.org/cpython/rev/27e7945c4ecd ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 15:12:58 2016 From: report at bugs.python.org (Ned Deily) Date: Thu, 16 Jun 2016 19:12:58 +0000 Subject: [issue27338] python 2.7 platform.system reports wrong on Mac OS X El Capitan In-Reply-To: <1466102857.11.0.587490522891.issue27338@psf.upfronthosting.co.za> Message-ID: <1466104378.19.0.89055374553.issue27338@psf.upfronthosting.co.za> Ned Deily added the comment: Python's platform module has both platform-independent and platform-dependent functions as noted in its documentation. While it isn't as clearly documented as perhaps it should be, on most "Unix-y" platforms, like OS X, much of the platform-independent system information comes from the same source as the platform's "uname" command. You can see that, if you use platform.uname(), it matches the output of OS X's uname(1) command: >>> platform.uname() ('Darwin', 'kitt.local', '15.5.0', 'Darwin Kernel Version 15.5.0: Tue Apr 19 18:36:36 PDT 2016; root:xnu-3248.50.21~8/RELEASE_X86_64', 'x86_64', 'i386') >>> platform.system() 'Darwin' >>> platform.release() '15.5.0' $ uname -a Darwin kitt.local 15.5.0 Darwin Kernel Version 15.5.0: Tue Apr 19 18:36:36 PDT 2016; root:xnu-3248.50.21~8/RELEASE_X86_64 x86_64 Somewhat confusingly, "Darwin" is how the OS X kernel identifies itself and "15.5.0" is the Darwin version number that corresponds to OS X 10.11.5. And the uname output is what the platform module uses. For OS X, the platform module does provide a Mac-specific function, platform.mac_ver. From it, you can get the OS X version information, rather than the Darwin kernel information. >>> platform.mac_ver() ('10.11.5', ('', '', ''), 'x86_64') Suggestions on how to improve the documentation are welcome! But changing the results from the platform-independent functions after all these years is not likely to happen. https://docs.python.org/2.7/library/platform.html#cross-platform https://en.wikipedia.org/wiki/Darwin_(operating_system)#Release_history ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 15:14:30 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 16 Jun 2016 19:14:30 +0000 Subject: [issue27336] --without-threads build fails due to undeclared _PyGILState_check_enabled In-Reply-To: <1466098664.28.0.417925542114.issue27336@psf.upfronthosting.co.za> Message-ID: <1466104470.57.0.900437448454.issue27336@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +haypo stage: -> patch review type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 15:14:58 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 16 Jun 2016 19:14:58 +0000 Subject: [issue27336] --without-threads build fails due to undeclared _PyGILState_check_enabled In-Reply-To: <1466098664.28.0.417925542114.issue27336@psf.upfronthosting.co.za> Message-ID: <1466104498.46.0.821593027564.issue27336@psf.upfronthosting.co.za> Berker Peksag added the comment: The attached patch should fix this. ---------- keywords: +patch nosy: +berker.peksag Added file: http://bugs.python.org/file43424/issue27336.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 15:29:31 2016 From: report at bugs.python.org (Audric D'Hoest (Dr. Pariolo)) Date: Thu, 16 Jun 2016 19:29:31 +0000 Subject: [issue27338] python 2.7 platform.system reports wrong on Mac OS X El Capitan In-Reply-To: <1466102857.11.0.587490522891.issue27338@psf.upfronthosting.co.za> Message-ID: <1466105371.06.0.645107625957.issue27338@psf.upfronthosting.co.za> Audric D'Hoest (Dr. Pariolo) added the comment: Hello Ned, That is a brilliant answer! After reporting this initially, I tried with 3.5.1, and uname... Convinced it was a 2.7.1, I could not be more wrong! What a stupid and confusing output does the OS report. platform.mac_ver() does the trick! thank you! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 15:30:18 2016 From: report at bugs.python.org (Audric D'Hoest (Dr. Pariolo)) Date: Thu, 16 Jun 2016 19:30:18 +0000 Subject: [issue27338] python 2.7 platform.system reports wrong on Mac OS X El Capitan In-Reply-To: <1466102857.11.0.587490522891.issue27338@psf.upfronthosting.co.za> Message-ID: <1466105418.58.0.490794847855.issue27338@psf.upfronthosting.co.za> Changes by Audric D'Hoest (Dr. Pariolo) : ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 16:16:06 2016 From: report at bugs.python.org (YoSTEALTH) Date: Thu, 16 Jun 2016 20:16:06 +0000 Subject: [issue27339] Security Issue: Typosquatting Message-ID: <1466108166.86.0.240454355449.issue27339@psf.upfronthosting.co.za> New submission from YoSTEALTH: I read this new article that explains Typosquatting well: http://incolumitas.com/2016/06/08/typosquatting-package-managers/ making it known here so python developers can address this issue accordingly! ---------- messages: 268692 nosy: YoSTEALTH priority: normal severity: normal status: open title: Security Issue: Typosquatting _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 16:24:23 2016 From: report at bugs.python.org (Vlad K.) Date: Thu, 16 Jun 2016 20:24:23 +0000 Subject: [issue26171] heap overflow in zipimporter module In-Reply-To: <1453348353.03.0.314168195173.issue26171@psf.upfronthosting.co.za> Message-ID: <1466108663.73.0.716283578222.issue26171@psf.upfronthosting.co.za> Vlad K. added the comment: I believe this should be applied to Python 3.3 as well, since the same problem (unchecked data_size before adding +1 for bytes_size) exists there too, and is thus a security issue. ---------- nosy: +vladk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 16:53:57 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 Jun 2016 20:53:57 +0000 Subject: [issue27336] --without-threads build fails due to undeclared _PyGILState_check_enabled In-Reply-To: <1466098664.28.0.417925542114.issue27336@psf.upfronthosting.co.za> Message-ID: <1466110437.68.0.0664076941339.issue27336@psf.upfronthosting.co.za> STINNER Victor added the comment: @Alex Willmer: Why do you build Python without threads? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 16:54:18 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 Jun 2016 20:54:18 +0000 Subject: [issue27336] --without-threads build fails due to undeclared _PyGILState_check_enabled In-Reply-To: <1466098664.28.0.417925542114.issue27336@psf.upfronthosting.co.za> Message-ID: <1466110458.7.0.470833172716.issue27336@psf.upfronthosting.co.za> STINNER Victor added the comment: issue27336.diff LGTM with a minor comment on the review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 17:09:44 2016 From: report at bugs.python.org (Michael Felt) Date: Thu, 16 Jun 2016 21:09:44 +0000 Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX) In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za> Message-ID: <1466111384.81.0.458377642745.issue26439@psf.upfronthosting.co.za> Michael Felt added the comment: _aixutil.py to be paired with Python2.Lib.ctypes.16.06.11.patch ---------- Added file: http://bugs.python.org/file43425/_aixutil.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 17:15:13 2016 From: report at bugs.python.org (Michael Felt) Date: Thu, 16 Jun 2016 21:15:13 +0000 Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX) In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za> Message-ID: <1466111713.61.0.173361566364.issue26439@psf.upfronthosting.co.za> Michael Felt added the comment: The patch for Python2 - however, only now see the change in selections for version. Will need to redo/test Lib/ctypes/*.py in newer version. Note also, the additional tests in util.py are for my testing - I do not expect them to stay, but I do want you aware of how I am testing - see also change in Lib/ctypes/test/test_loading.py ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 17:19:43 2016 From: report at bugs.python.org (Ned Deily) Date: Thu, 16 Jun 2016 21:19:43 +0000 Subject: [issue26171] heap overflow in zipimporter module In-Reply-To: <1453348353.03.0.314168195173.issue26171@psf.upfronthosting.co.za> Message-ID: <1466111983.4.0.066716780747.issue26171@psf.upfronthosting.co.za> Ned Deily added the comment: reopening for 3.3.7 evaluation. Georg? ---------- nosy: +georg.brandl, ned.deily priority: normal -> resolution: fixed -> stage: resolved -> needs patch status: closed -> open versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 17:25:20 2016 From: report at bugs.python.org (Michael Felt) Date: Thu, 16 Jun 2016 21:25:20 +0000 Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX) In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za> Message-ID: <1466112320.69.0.562510621486.issue26439@psf.upfronthosting.co.za> Michael Felt added the comment: updated patch for Python 2.7 (shall adopt and submit new patch for Python3 based on this - next week) used gnu diff to generate diff output. Additional tests in util.py are for demo only, would expect them to be removed, however, the additional test in test/test_loading.py could remain. ---------- Added file: http://bugs.python.org/file43426/Python2.Lib.ctypes.160611.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 17:29:24 2016 From: report at bugs.python.org (Vlad K.) Date: Thu, 16 Jun 2016 21:29:24 +0000 Subject: [issue26171] heap overflow in zipimporter module In-Reply-To: <1453348353.03.0.314168195173.issue26171@psf.upfronthosting.co.za> Message-ID: <1466112564.91.0.21623218272.issue26171@psf.upfronthosting.co.za> Vlad K. added the comment: Here's the patch that I made for FreeBSD's Python 3.3 port. With this patch, on FreeBSD, Python 3.3 built fine and passed the zipimport related unit tests. It's basically the same code from 3.4, 3.5 and 2.7, just placed at appropriate place in the source. ---------- versions: -Python 3.3 Added file: http://bugs.python.org/file43427/patch-Modules_zipimport-CVE-2016-5636.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 17:43:14 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 Jun 2016 21:43:14 +0000 Subject: [issue27339] Security Issue: Typosquatting In-Reply-To: <1466108166.86.0.240454355449.issue27339@psf.upfronthosting.co.za> Message-ID: <1466113394.86.0.381797955715.issue27339@psf.upfronthosting.co.za> STINNER Victor added the comment: Hum, I guess that you are talking about https://pypi.python.org/pypi ? If yes, you should open an issue in their bug tracker: https://bitbucket.org/pypa/pypi/issues By the way, I don't see any obvious fix for typo squatting. ---------- nosy: +haypo resolution: -> third party status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 18:02:31 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 16 Jun 2016 22:02:31 +0000 Subject: [issue27278] py_getrandom() uses an int for syscall() result In-Reply-To: <1465458165.91.0.316132030988.issue27278@psf.upfronthosting.co.za> Message-ID: <20160616220222.20131.49708.1A34163C@psf.io> Roundup Robot added the comment: New changeset 193f50babfa4 by Victor Stinner in branch '3.5': py_getrandom(): use long type for the syscall() result https://hg.python.org/cpython/rev/193f50babfa4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 18:04:15 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 Jun 2016 22:04:15 +0000 Subject: [issue27278] py_getrandom() uses an int for syscall() result In-Reply-To: <1465458165.91.0.316132030988.issue27278@psf.upfronthosting.co.za> Message-ID: <1466114655.94.0.438347293023.issue27278@psf.upfronthosting.co.za> STINNER Victor added the comment: > Adding a cast would solve this compiler warning: I changed the code to use the long type. It should fix the warning, even if it was no more a real bug: the original bug was already fixed. I close the issue, it's now solved. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 19:58:04 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 16 Jun 2016 23:58:04 +0000 Subject: [issue27335] Clarify that writing to locals() inside a class body is supported In-Reply-To: <1466098501.84.0.0349098094976.issue27335@psf.upfronthosting.co.za> Message-ID: <1466121484.94.0.947740707426.issue27335@psf.upfronthosting.co.za> Martin Panter added the comment: I think my proposed patch for Issue 17546 addresses this. That patch was also written to address Issue 17960. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 16 21:52:49 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 17 Jun 2016 01:52:49 +0000 Subject: [issue14562] urllib2 maybe blocks too long with small chunks In-Reply-To: <1334233390.52.0.591380103695.issue14562@psf.upfronthosting.co.za> Message-ID: <1466128369.14.0.353363643221.issue14562@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 00:15:02 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 17 Jun 2016 04:15:02 +0000 Subject: [issue25724] SSLv3 test failure on Ubuntu 16.04 LTS In-Reply-To: <1448379899.26.0.590688499284.issue25724@psf.upfronthosting.co.za> Message-ID: <1466136902.03.0.563481489021.issue25724@psf.upfronthosting.co.za> Martin Panter added the comment: This patch was also posted to Issue 26867, with a bit more discussion and analysis, so closing as a duplicate. ---------- resolution: -> duplicate status: open -> closed superseder: -> test_ssl test_options fails on ubuntu 16.04 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 00:23:13 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 17 Jun 2016 04:23:13 +0000 Subject: [issue26867] test_ssl test_options fails on ubuntu 16.04 In-Reply-To: <1461728238.71.0.110276038105.issue26867@psf.upfronthosting.co.za> Message-ID: <1466137393.18.0.942724432737.issue26867@psf.upfronthosting.co.za> Martin Panter added the comment: FWIW I imagine Ubuntu overriding the option will break the example code in the documentation of clearing SSL_OP_NO_SSLv3: . If we keep that documentation, I think we should continue to test that clearing the option works, which conflicts with the proposed patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 00:25:20 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 17 Jun 2016 04:25:20 +0000 Subject: [issue27340] bytes-like objects with socket.sendall(), SSL, and http.client Message-ID: <1466137520.57.0.744540833455.issue27340@psf.upfronthosting.co.za> New submission from Martin Panter: According to the documentation, HTTPSConnection.request() should accept arbitrary bytes-like objects, but this is not the case. Currently (since Issue 23756), a ?bytes-like object? is defined to be anything that works with Python?s buffer API, as long as it is C-contiguous. These objects can be passed to socket.sendall(): >>> byteslike = (ctypes.c_ubyte * 6).from_buffer_copy(b"DATA\r\n") >>> s = socket.create_connection(("localhost", 80)) >>> s.sendall(byteslike) # Server receives b"DATA\r\n" This is not explicitly documented for socket objects. But since Issue 23539 (3.4+), HTTPConnection.request() does document support for bytes-like objects: >>> h = HTTPConnection("localhost", 80) >>> # Send Content-Length: 6 and body b"DATA\r\n" >>> h.request("POST", "/", body=byteslike) On its own, there is no problem with Python relying on its own undocumented behaviour. But Python?s ?ssl? module does not support arbitrary bytes-like objects, and as a result neither does HTTPSConnection: >>> s = ssl.wrap_socket(socket.create_connection(("localhost", 443))) >>> s.sendall(byteslike) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.5/ssl.py", line 886, in sendall v = self.send(data[count:]) File "/usr/lib/python3.5/ssl.py", line 856, in send return self._sslobj.write(data) File "/usr/lib/python3.5/ssl.py", line 581, in write return self._sslobj.write(data) TypeError: a bytes-like object is required, not 'list' >>> c = ssl.create_default_context(cafile="/lib/python3.5/test/keycert.pem") >>> h = HTTPSConnection("localhost", 443, context=c) >>> h.request("POST", "/", body=byteslike) Traceback (most recent call last): File "/usr/lib/python3.5/http/client.py", line 885, in send self.sock.sendall(data) File "/usr/lib/python3.5/ssl.py", line 886, in sendall v = self.send(data[count:]) File "/usr/lib/python3.5/ssl.py", line 856, in send return self._sslobj.write(data) File "/usr/lib/python3.5/ssl.py", line 581, in write return self._sslobj.write(data) TypeError: a bytes-like object is required, not 'list' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.5/http/client.py", line 1083, in request self._send_request(method, url, body, headers) File "/usr/lib/python3.5/http/client.py", line 1128, in _send_request self.endheaders(body) File "/usr/lib/python3.5/http/client.py", line 1079, in endheaders self._send_output(message_body) File "/usr/lib/python3.5/http/client.py", line 913, in _send_output self.send(message_body) File "/usr/lib/python3.5/http/client.py", line 892, in send "or an iterable, got %r" % type(data)) TypeError: data should be a bytes-like object or an iterable, got This could be fixed in the implementation of SSLSocket.sendall(). But I am not sure if that is an appropriate change for 3.5. Another option would be to adjust the documentation of HTTP(S)Connection in 3.5, either not mentioning bytes-like objects at all, or clarifying that they don?t work with SSL. ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 268707 nosy: docs at python, martin.panter priority: normal severity: normal status: open title: bytes-like objects with socket.sendall(), SSL, and http.client versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 00:25:59 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 17 Jun 2016 04:25:59 +0000 Subject: [issue23740] http.client request and send method have some datatype issues In-Reply-To: <1427052524.74.0.134908492197.issue23740@psf.upfronthosting.co.za> Message-ID: <1466137559.32.0.148190305909.issue23740@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- dependencies: +bytes-like objects with socket.sendall(), SSL, and http.client _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 01:33:04 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 17 Jun 2016 05:33:04 +0000 Subject: [issue23360] Content-Type when sending data with urlopen() In-Reply-To: <1422794612.5.0.505084736818.issue23360@psf.upfronthosting.co.za> Message-ID: <1466141584.19.0.127925795169.issue23360@psf.upfronthosting.co.za> Martin Panter added the comment: Fixed conflicts with recent changes ---------- versions: +Python 2.7 -Python 3.4 Added file: http://bugs.python.org/file43428/non-urlencoded.6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 01:35:08 2016 From: report at bugs.python.org (Shoshana Berleant) Date: Fri, 17 Jun 2016 05:35:08 +0000 Subject: [issue27341] mock.patch decorator fails silently on generators Message-ID: <1466141708.88.0.0388300458163.issue27341@psf.upfronthosting.co.za> New submission from Shoshana Berleant: (at least in my case) I committed two tests before I realized the tests were not being run: https://github.com/nipy/nipype/blob/abe7920a051f1570ccce4b71f26f50102d6e4e12/nipype/testing/tests/test_utils.py#L23 I realized this afternoon, while writing some more tests, that tests with the patch decorator were all reported as "OK", even when I wanted them to fail. Turns out they aren't being run at all. I commented out all the yield statements, and the tests ran just as they should. I don't know exactly what is going on here, but might raising an error or warning be good here? Originally filed here: https://github.com/testing-cabal/mock/issues/366 ---------- components: Tests messages: 268709 nosy: shoshber priority: normal severity: normal status: open title: mock.patch decorator fails silently on generators type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 02:19:42 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 Jun 2016 06:19:42 +0000 Subject: [issue24424] xml.dom.minidom: performance issue with Node.insertBefore() In-Reply-To: <1433942956.66.0.599460998017.issue24424@psf.upfronthosting.co.za> Message-ID: <1466144382.8.0.759517315178.issue24424@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please provide a simple example that benefits from this change? Besides index() Node.insertBefore() uses insert() that has linear complexity too. In any case this is a new feature that can go only in 3.6. ---------- assignee: -> serhiy.storchaka stage: -> patch review versions: +Python 3.6 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 03:39:28 2016 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 17 Jun 2016 07:39:28 +0000 Subject: [issue27342] Clean up some Py_XDECREFs in rangeobject.c and bltinmodule.c Message-ID: <1466149168.09.0.735946487659.issue27342@psf.upfronthosting.co.za> New submission from Xiang Zhang: Some Py_XDECREFs in rangeobject.c and bltinmodule.c are not necessary. Py_DECREF is enough. Clean up them. ---------- files: cleanup_some_xdecrefs.patch keywords: patch messages: 268711 nosy: xiang.zhang priority: normal severity: normal status: open title: Clean up some Py_XDECREFs in rangeobject.c and bltinmodule.c Added file: http://bugs.python.org/file43429/cleanup_some_xdecrefs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 04:14:49 2016 From: report at bugs.python.org (Christoph Gohlke) Date: Fri, 17 Jun 2016 08:14:49 +0000 Subject: [issue27305] Crash with "pip list --outdated" on Windows 10 with Python 2.7.12rc1 In-Reply-To: <1465820074.65.0.989290191732.issue27305@psf.upfronthosting.co.za> Message-ID: <1466151289.98.0.587064014543.issue27305@psf.upfronthosting.co.za> Christoph Gohlke added the comment: FWIW, this could be a build issue: 1) `_ssl.OPENSSL_VERSION` for the 2.7.12rc1 amd64 binaries is "OpenSSL 1.0.2d 9 Jul 2015", not OpenSSL 1.0.2g as expected from the changelog at . 2) Rebuilding _ssl.pyd against openssl-1.0.2h fixes this issue for me (no crash). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 04:35:06 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 Jun 2016 08:35:06 +0000 Subject: [issue27343] Incorrect error message for conflicting initializers of ctypes structure Message-ID: <1466152506.85.0.761729161431.issue27343@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: >>> from ctypes import * >>> class POINT(Structure): ... _fields_ = [("x", c_int), ("y", c_int)] ... >>> POINT(2, 3, x=4) Traceback (most recent call last): File "", line 1, in TypeError: duplicate values for field '???' The name of conflicting field is not output correctly because it is expected to be bytes. Proposed patch makes the error message always contain the name of conflicting field. ---------- components: Library (Lib), ctypes files: ctypes_conflictin_initializers_error_message.patch keywords: patch messages: 268713 nosy: amaury.forgeotdarc, belopolsky, meador.inge, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Incorrect error message for conflicting initializers of ctypes structure type: behavior versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43430/ctypes_conflictin_initializers_error_message.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 04:36:06 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 Jun 2016 08:36:06 +0000 Subject: [issue27330] Possible leaks in ctypes In-Reply-To: <1466062037.29.0.101937444984.issue27330@psf.upfronthosting.co.za> Message-ID: <1466152566.42.0.80435988564.issue27330@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your review Martin! Committed with your fixes. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 04:36:31 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 Jun 2016 08:36:31 +0000 Subject: [issue27342] Clean up some Py_XDECREFs in rangeobject.c and bltinmodule.c In-Reply-To: <1466149168.09.0.735946487659.issue27342@psf.upfronthosting.co.za> Message-ID: <1466152591.91.0.763408467037.issue27342@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 04:38:44 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 Jun 2016 08:38:44 +0000 Subject: [issue27333] validate_step in rangeobject.c, incorrect code logic but right result In-Reply-To: <1466094985.85.0.664632093379.issue27333@psf.upfronthosting.co.za> Message-ID: <1466152724.68.0.188896431018.issue27333@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 04:55:16 2016 From: report at bugs.python.org (Ned Deily) Date: Fri, 17 Jun 2016 08:55:16 +0000 Subject: [issue18751] A manager's server never joins its threads In-Reply-To: <1376590396.18.0.712968689777.issue18751@psf.upfronthosting.co.za> Message-ID: <1466153716.83.0.695866566121.issue18751@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 05:22:51 2016 From: report at bugs.python.org (Ned Deily) Date: Fri, 17 Jun 2016 09:22:51 +0000 Subject: [issue27273] subprocess.run(cmd, input='text') should pass universal_newlines=True to Popen In-Reply-To: <1465430363.96.0.915441067061.issue27273@psf.upfronthosting.co.za> Message-ID: <1466155371.62.0.944266498144.issue27273@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +gregory.p.smith stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 05:26:16 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 17 Jun 2016 09:26:16 +0000 Subject: [issue27343] Incorrect error message for conflicting initializers of ctypes structure In-Reply-To: <1466152506.85.0.761729161431.issue27343@psf.upfronthosting.co.za> Message-ID: <1466155576.39.0.340958990156.issue27343@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 05:53:05 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 17 Jun 2016 09:53:05 +0000 Subject: [issue12319] [http.client] HTTPConnection.request not support "chunked" Transfer-Encoding to send data In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za> Message-ID: <1466157185.24.0.394289163638.issue12319@psf.upfronthosting.co.za> Martin Panter added the comment: FYI instead of changing the helper into a static method, I think you could have just called http.client._get_content_length(). I don?t understand why we need the new encode_chunked=True flag. Can?t urllib.request leave the Transfer-Encoding field up to http.client? Yes it does set Content-Length in the Request object, but it does not set Accept-Encoding nor Connection. Also, it looks like you can still get chunked encoding if you set encode_chunked=False, which is confusing. I left some review comments, and I think some of my earlier comments still apply. I still find it confusing the variety of objects accepted, and the different levels that the APIs work on. Hopefully it will become less confusing if we can figure out all the corner cases. I do think unifying the data types accepted by urlopen() and HTTPConnection is good, though I am not sure allowing text in urlopen() is the right direction. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 05:56:51 2016 From: report at bugs.python.org (Ned Deily) Date: Fri, 17 Jun 2016 09:56:51 +0000 Subject: [issue27307] string.Formatter does not support key/attribute access on unnumbered fields In-Reply-To: <1465831962.68.0.949862526307.issue27307@psf.upfronthosting.co.za> Message-ID: <1466157411.28.0.0911700460951.issue27307@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +eric.smith stage: -> patch review versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 06:23:33 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 Jun 2016 10:23:33 +0000 Subject: [issue27343] Incorrect error message for conflicting initializers of ctypes structure In-Reply-To: <1466152506.85.0.761729161431.issue27343@psf.upfronthosting.co.za> Message-ID: <1466159013.23.0.227241257626.issue27343@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file43430/ctypes_conflictin_initializers_error_message.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 06:24:28 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 17 Jun 2016 10:24:28 +0000 Subject: [issue27336] --without-threads build fails due to undeclared _PyGILState_check_enabled In-Reply-To: <1466098664.28.0.417925542114.issue27336@psf.upfronthosting.co.za> Message-ID: <20160617102422.20108.900.1E9B6D2F@psf.io> Roundup Robot added the comment: New changeset 2baaf7e31b13 by Berker Peksag in branch 'default': Issue #27336: Fix compilation failures --without-threads https://hg.python.org/cpython/rev/2baaf7e31b13 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 06:24:52 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 Jun 2016 10:24:52 +0000 Subject: [issue27343] Incorrect error message for conflicting initializers of ctypes structure In-Reply-To: <1466152506.85.0.761729161431.issue27343@psf.upfronthosting.co.za> Message-ID: <1466159092.11.0.573693798503.issue27343@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file43431/ctypes_conflictin_initializers_error_message.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 06:25:04 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 17 Jun 2016 10:25:04 +0000 Subject: [issue27336] --without-threads build fails due to undeclared _PyGILState_check_enabled In-Reply-To: <1466098664.28.0.417925542114.issue27336@psf.upfronthosting.co.za> Message-ID: <1466159104.74.0.595851930074.issue27336@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 06:29:49 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 17 Jun 2016 10:29:49 +0000 Subject: [issue27336] --without-threads build fails due to undeclared _PyGILState_check_enabled In-Reply-To: <1466098664.28.0.417925542114.issue27336@psf.upfronthosting.co.za> Message-ID: <20160617102945.22953.53298.8992AE7E@psf.io> Roundup Robot added the comment: New changeset cbe977fd306f by Victor Stinner in branch 'default': Issue #27336: Fix compilation on Windows https://hg.python.org/cpython/rev/cbe977fd306f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 06:50:56 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 Jun 2016 10:50:56 +0000 Subject: [issue23360] Content-Type when sending data with urlopen() In-Reply-To: <1422794612.5.0.505084736818.issue23360@psf.upfronthosting.co.za> Message-ID: <1466160656.69.0.95152206347.issue23360@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +orsenthil, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 07:04:37 2016 From: report at bugs.python.org (Jaysinh shukla) Date: Fri, 17 Jun 2016 11:04:37 +0000 Subject: [issue15243] Misleading documentation for __prepare__ In-Reply-To: <1341328118.33.0.670602196671.issue15243@psf.upfronthosting.co.za> Message-ID: <1466161477.39.0.761178403171.issue15243@psf.upfronthosting.co.za> Jaysinh shukla added the comment: Submitting patch according to this (http://bugs.python.org/issue15243#msg268356) message. Thanks! ---------- keywords: +patch nosy: +jaysinh.shukla Added file: http://bugs.python.org/file43432/issue15243_diff_python3.5_3.6_v1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 07:35:34 2016 From: report at bugs.python.org (Demur Rumed) Date: Fri, 17 Jun 2016 11:35:34 +0000 Subject: [issue27213] Rework CALL_FUNCTION* opcodes In-Reply-To: <1465026334.02.0.369802561902.issue27213@psf.upfronthosting.co.za> Message-ID: <1466163334.49.0.792722608609.issue27213@psf.upfronthosting.co.za> Demur Rumed added the comment: I've been working on this, may have the ceval portion mostly worked out but can't test until I finish the compile portion. Haven't had time this week, will have time to focus this weekend ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 08:35:25 2016 From: report at bugs.python.org (Oren Milman) Date: Fri, 17 Jun 2016 12:35:25 +0000 Subject: [issue27298] redundant iteration over digits in _PyLong_AsUnsignedLongMask In-Reply-To: <1465680013.34.0.390511904077.issue27298@psf.upfronthosting.co.za> Message-ID: <1466166925.22.0.253272969031.issue27298@psf.upfronthosting.co.za> Oren Milman added the comment: I did some micro-benchmarking, and it looks like bad news for my patch. I wrote a simple C extension in order to call PyLong_AsUnsignedLongMask and PyLong_AsUnsignedLongLongMask from Python code (attached). Then I ran the following micro-benchmarks using both the default CPython branch and my patched CPython: 1. small ints: python.exe -m timeit -s "import capiWrapper" "print('bug') if any(i != capiWrapper.asUnsignedLongMaskWrapper(i) for i in range(10 ** 6)) else None" python.exe -m timeit -s "import capiWrapper" "print('bug') if any(i != capiWrapper.asUnsignedLongLongMaskWrapper(i) for i in range(10 ** 6)) else None" with the following results: asUnsignedLongMaskWrapper: default: 312 msec, patched: 353 msec asUnsignedLongLongMaskWrapper: default: 319 msec, patched: 356 msec 2. big ints: python.exe -m timeit -s "import capiWrapper; bigInt = 10 ** 1000" "print('bug') if any((i & 0xffffffff) != capiWrapper.asUnsignedLongMaskWrapper(i) for i in range(bigInt, bigInt + 10000)) else None" python.exe -m timeit -s "import capiWrapper; bigInt = 10 ** 1000" "print('bug') if any((i & 0xffffffffffffffff) != capiWrapper.asUnsignedLongLongMaskWrapper(i) for i in range(bigInt, bigInt + 10000)) else None" with the following results: when bigInt = 10 ** 1000: asUnsignedLongMaskWrapper: default: 23.1 msec, patched: 21.5 msec asUnsignedLongLongMaskWrapper: default: 24.1 msec, patched: 21.7 msec when bigInt = 10 ** 150: asUnsignedLongMaskWrapper: default: 7.72 msec, patched: 7.82 msec asUnsignedLongLongMaskWrapper: default: 8.03 msec, patched: 7.99 msec To sum it up, my patch degrades performance for ints smaller than (approximately) 10 ** 150, and improves performance for bigger ints. Seems to me like it doesn't worth it. I attached the patches diff file anyway, for the sake of documentation. ========================================================================== That leaves us with the proposed changes in Modules/_testcapimodule.c. The diff file for these (hopefully my final diff file for this issue) is also attached. ---------- Added file: http://bugs.python.org/file43433/capiWrapperModule.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 08:36:39 2016 From: report at bugs.python.org (Oren Milman) Date: Fri, 17 Jun 2016 12:36:39 +0000 Subject: [issue27298] redundant iteration over digits in _PyLong_AsUnsignedLongMask In-Reply-To: <1465680013.34.0.390511904077.issue27298@psf.upfronthosting.co.za> Message-ID: <1466166999.38.0.592375057913.issue27298@psf.upfronthosting.co.za> Changes by Oren Milman : Added file: http://bugs.python.org/file43434/badMicroBenchProposedPatches.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 08:37:40 2016 From: report at bugs.python.org (Oren Milman) Date: Fri, 17 Jun 2016 12:37:40 +0000 Subject: [issue27298] redundant iteration over digits in _PyLong_AsUnsignedLongMask In-Reply-To: <1465680013.34.0.390511904077.issue27298@psf.upfronthosting.co.za> Message-ID: <1466167060.0.0.805316510107.issue27298@psf.upfronthosting.co.za> Changes by Oren Milman : Added file: http://bugs.python.org/file43435/proposedPatches.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 08:45:53 2016 From: report at bugs.python.org (Robert Haschke) Date: Fri, 17 Jun 2016 12:45:53 +0000 Subject: [issue24424] xml.dom.minidom: performance issue with Node.insertBefore() In-Reply-To: <1433942956.66.0.599460998017.issue24424@psf.upfronthosting.co.za> Message-ID: <1466167553.4.0.569343533065.issue24424@psf.upfronthosting.co.za> Robert Haschke added the comment: I uploaded a simple example to illustrate the tremendous performance boost. Obviously, the example exploits the caching improvement as much as possible: The code assembles a XML document by inserting new nodes before the last one... These are the timing results: $ python minidom_example.py old new oldtime for 5000 iterations: 18.422152 newtime for 5000 iterations: 0.129384 $ python minidom_example.py old new oldtime for 10000 iterations: 68.305351 newtime for 10000 iterations: 0.142071 You see the quadratic increase of time... IMHO, this is clearly a (performance) bug and really many people in the ROS community are affected. Hence, I hope that this patch will find its way into some python versions currently used by standard Linux distributions. ---------- Added file: http://bugs.python.org/file43436/minidom_example.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 09:04:24 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 Jun 2016 13:04:24 +0000 Subject: [issue27333] validate_step in rangeobject.c, incorrect code logic but right result In-Reply-To: <1466094985.85.0.664632093379.issue27333@psf.upfronthosting.co.za> Message-ID: <1466168664.42.0.537173858587.issue27333@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Current code is valid, since neither PY_SSIZE_MAX nor PY_SSIZE_MIN equal to 0. But testing on 0 can be simpler. Following patch simplifies the code. ---------- nosy: +mark.dickinson stage: -> patch review type: behavior -> enhancement versions: -Python 2.7, Python 3.5 Added file: http://bugs.python.org/file43437/range_validate_step.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 09:19:14 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 Jun 2016 13:19:14 +0000 Subject: [issue27342] Clean up some Py_XDECREFs in rangeobject.c and bltinmodule.c In-Reply-To: <1466149168.09.0.735946487659.issue27342@psf.upfronthosting.co.za> Message-ID: <1466169554.37.0.835881064826.issue27342@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Mostly good except longrangeiter_dealloc(). ---------- components: +Interpreter Core nosy: +mark.dickinson stage: -> patch review type: -> enhancement versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 10:20:20 2016 From: report at bugs.python.org (Daniel Holth) Date: Fri, 17 Jun 2016 14:20:20 +0000 Subject: [issue18373] let code force str(bytes) to raise an exception In-Reply-To: <1373065124.82.0.249288626652.issue18373@psf.upfronthosting.co.za> Message-ID: <1466173220.64.0.646151849865.issue18373@psf.upfronthosting.co.za> Daniel Holth added the comment: What if we changed it so that Python code could only disable str_bytes() process-wide, editing the original flag? Would that be fatal to debuggers and the repl? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 10:39:06 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 Jun 2016 14:39:06 +0000 Subject: [issue24424] xml.dom.minidom: performance issue with Node.insertBefore() In-Reply-To: <1433942956.66.0.599460998017.issue24424@psf.upfronthosting.co.za> Message-ID: <1466174346.92.0.941888223874.issue24424@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your example Robert. If modify your example for inserting new nodes before the first one, it shows the slowdown with your patch. $ ./python minidom_example2.py old new oldtime for 5000 iterations: 0.189058 newtime for 5000 iterations: 0.254402 The question is whether your case is enough common to compensate the slowdown of other cases. Yest one disadvantage of your patch is increasing memory consumption (this can be partly compensated by adding '_index_cache' to slots). Have you considered the option of using Python 3? In Python 3 your example is much faster even without your patch (but still has quadratic complexity). Python 2.7: oldtime for 5000 iterations: 68.485284 newtime for 5000 iterations: 0.237943 Python 3.6: oldtime for 5000 iterations: 0.695023 newtime for 5000 iterations: 0.212854 And the best option is using ElementTree. It accepts an index instead of a subelement for insertion. $ ./python etree_example.py Python 2.7: time for 5000 iterations: 0.037805 Python 3.6: time for 5000 iterations: 0.015566 ---------- Added file: http://bugs.python.org/file43438/minidom_example2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 10:39:42 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 Jun 2016 14:39:42 +0000 Subject: [issue24424] xml.dom.minidom: performance issue with Node.insertBefore() In-Reply-To: <1433942956.66.0.599460998017.issue24424@psf.upfronthosting.co.za> Message-ID: <1466174382.53.0.156256498705.issue24424@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file43439/etree_example.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 11:08:46 2016 From: report at bugs.python.org (Daniel Holth) Date: Fri, 17 Jun 2016 15:08:46 +0000 Subject: [issue27344] zipfile *does* support utf-8 filenames Message-ID: <1466176126.21.0.0133629365393.issue27344@psf.upfronthosting.co.za> New submission from Daniel Holth: The zipfile documentation says "There is no official file name encoding for ZIP files." However ZIP and zipfile supports utf-8 filenames; this has been true for a long time, at least since Python 2.7. ---------- assignee: docs at python components: Documentation messages: 268727 nosy: dholth, docs at python priority: normal severity: normal status: open title: zipfile *does* support utf-8 filenames versions: Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 11:17:51 2016 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 17 Jun 2016 15:17:51 +0000 Subject: [issue27333] validate_step in rangeobject.c, incorrect code logic but right result In-Reply-To: <1466094985.85.0.664632093379.issue27333@psf.upfronthosting.co.za> Message-ID: <1466176671.25.0.442742166869.issue27333@psf.upfronthosting.co.za> Xiang Zhang added the comment: This looks fine. But maybe code like this looks more clear: if (step && _PyLong_Sign(step) == 0) { PyErr_SetString(PyExc_ValueError, "range() arg 3 must not be zero"); Py_CLEAR(step); } I think assert(PyLong_Check(step)) can be left out since _PyLong_Sign also checks it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 11:26:00 2016 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 17 Jun 2016 15:26:00 +0000 Subject: [issue27342] Clean up some Py_XDECREFs in rangeobject.c and bltinmodule.c In-Reply-To: <1466149168.09.0.735946487659.issue27342@psf.upfronthosting.co.za> Message-ID: <1466177160.57.0.308552948829.issue27342@psf.upfronthosting.co.za> Xiang Zhang added the comment: Thanks for review. Eliminate the wrongs ones. ---------- Added file: http://bugs.python.org/file43440/cleanup_some_xdecrefs_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 11:31:03 2016 From: report at bugs.python.org (Steve Dower) Date: Fri, 17 Jun 2016 15:31:03 +0000 Subject: [issue27305] Crash with "pip list --outdated" on Windows 10 with Python 2.7.12rc1 In-Reply-To: <1465820074.65.0.989290191732.issue27305@psf.upfronthosting.co.za> Message-ID: <1466177463.2.0.451835924993.issue27305@psf.upfronthosting.co.za> Steve Dower added the comment: A build issue like that is fairly likely - I don't touch 2.7 apart from releases and so all I did was restart my build VM, pull and hit rebuild. There may be another clean step required when the OpenSSL version changes. We're getting another update before the final release, so I'll clean up the build VM now in preparation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 12:07:17 2016 From: report at bugs.python.org (Robert Haschke) Date: Fri, 17 Jun 2016 16:07:17 +0000 Subject: [issue24424] xml.dom.minidom: performance issue with Node.insertBefore() In-Reply-To: <1433942956.66.0.599460998017.issue24424@psf.upfronthosting.co.za> Message-ID: <1466179637.6.0.609121661563.issue24424@psf.upfronthosting.co.za> Robert Haschke added the comment: Indeed there is a small slow down for insertion at the beginning. However, this is simply due to the extra function _index() and thus linear in the number of insertion operations. My patch essentially boosts insertions before /any fixed/ node. If this reference node changes between insertions (as in your "before first" example), there is no gain anymore. Of course, this optimization comes at the cost of an additional integer per node. There is no free lunch! I know, that there are other parsers (e.g. etree) available. However changing my existing code base from minidom to etree will be a heavy change, which isn't easily accepted as well. I think, my minidom patch is a clean and simple fix to a common performance issue. As it mostly effects 2.7, it should primarily go there ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 12:33:51 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 17 Jun 2016 16:33:51 +0000 Subject: [issue27048] distutils._msvccompiler._get_vc_env() fails with UnicodeDecodeError if an env var is not encodable In-Reply-To: <1463515752.85.0.457941663559.issue27048@psf.upfronthosting.co.za> Message-ID: <20160617163340.5267.49750.908EBB74@psf.io> Roundup Robot added the comment: New changeset 15900c612ca7 by Steve Dower in branch '3.5': Issue #27048: Prevents distutils failing on Windows when environment variables contain non-ASCII characters https://hg.python.org/cpython/rev/15900c612ca7 New changeset bb22ae1e1bcd by Steve Dower in branch 'default': Issue #27048: Prevents distutils failing on Windows when environment variables contain non-ASCII characters https://hg.python.org/cpython/rev/bb22ae1e1bcd ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 12:36:07 2016 From: report at bugs.python.org (Steve Dower) Date: Fri, 17 Jun 2016 16:36:07 +0000 Subject: [issue27048] distutils._msvccompiler._get_vc_env() fails with UnicodeDecodeError if an env var is not encodable In-Reply-To: <1463515752.85.0.457941663559.issue27048@psf.upfronthosting.co.za> Message-ID: <1466181367.12.0.869768973986.issue27048@psf.upfronthosting.co.za> Steve Dower added the comment: I went ahead and updated the subprocess call just in _msvccompiler to use cmd /u, as I like that fix. Not so keen on doing it for all subprocess(shell=True) calls, since we can't reliably predict whether the output will actually respect the option. ---------- assignee: -> steve.dower resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 12:37:47 2016 From: report at bugs.python.org (Steve Dower) Date: Fri, 17 Jun 2016 16:37:47 +0000 Subject: [issue27048] distutils._msvccompiler._get_vc_env() fails with UnicodeDecodeError if an env var is not encodable In-Reply-To: <1463515752.85.0.457941663559.issue27048@psf.upfronthosting.co.za> Message-ID: <1466181467.14.0.569846431559.issue27048@psf.upfronthosting.co.za> Steve Dower added the comment: Oh, and before anyone asks, I used "errors='replace'" because we get all the env variables but don't use most of them. If we do end up needing one that can't be decoded, this should make it obvious, but there's no point failing early because of a variable that we're not going to use. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 13:58:01 2016 From: report at bugs.python.org (Aaron Meurer) Date: Fri, 17 Jun 2016 17:58:01 +0000 Subject: [issue24294] DeprecationWarnings should be visible by default in the interactive REPL In-Reply-To: <1432713990.67.0.935342603332.issue24294@psf.upfronthosting.co.za> Message-ID: <1466186281.16.0.890856090053.issue24294@psf.upfronthosting.co.za> Changes by Aaron Meurer : ---------- nosy: +Aaron.Meurer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 14:48:39 2016 From: report at bugs.python.org (Steve Dower) Date: Fri, 17 Jun 2016 18:48:39 +0000 Subject: [issue27305] Crash with "pip list --outdated" on Windows 10 with Python 2.7.12rc1 In-Reply-To: <1465820074.65.0.989290191732.issue27305@psf.upfronthosting.co.za> Message-ID: <1466189319.32.0.771530026785.issue27305@psf.upfronthosting.co.za> Steve Dower added the comment: Just made another "release" build from the latest source (with OpenSSL 1.0.2h) and can no longer repro this issue, so I'm closing it. If anyone wants to try with the same build, it will be up at https://ptvs.blob.core.windows.net/temp/python-2.7.12.amd64.msi for a little while. It's not the final 2.7.12, despite the filename, so please only use it for reproducing this issue and then fully uninstall it (otherwise you'll likely encounter issues in the future): >>> sys.version '2.7.12rc1+ (2.7:dd2cc11bc170, Jun 17 2016, 16:14:27) [MSC v.1500 64 bit (AMD64)]' ---------- assignee: -> steve.dower resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 15:08:58 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 Jun 2016 19:08:58 +0000 Subject: [issue24424] xml.dom.minidom: performance issue with Node.insertBefore() In-Reply-To: <1433942956.66.0.599460998017.issue24424@psf.upfronthosting.co.za> Message-ID: <1466190538.63.0.784569781672.issue24424@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This slow down is not such small -- up to 25% for every insertBefore(). If most calls of insertBefore() are not with the same refChild, the benefit from the optimization of one special case can be dwarfed. Try to minimize the overhead of the optimization. If you succeed the chances of acceptance of the patch will increase. I think that the availability of alternatives (upgrading to Python 3 or using ElementTree) plays against the acception of this optimization. Since it looks more as new feature to me, you have to convince the maintainer of 2.7 to take the patch in 2.7. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 15:11:38 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 Jun 2016 19:11:38 +0000 Subject: [issue27344] zipfile *does* support utf-8 filenames In-Reply-To: <1466176126.21.0.0133629365393.issue27344@psf.upfronthosting.co.za> Message-ID: <1466190698.69.0.836582764601.issue27344@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka stage: -> needs patch versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 15:38:41 2016 From: report at bugs.python.org (Eryk Sun) Date: Fri, 17 Jun 2016 19:38:41 +0000 Subject: [issue27048] distutils._msvccompiler._get_vc_env() fails with UnicodeDecodeError if an env var is not encodable In-Reply-To: <1463515752.85.0.457941663559.issue27048@psf.upfronthosting.co.za> Message-ID: <1466192321.72.0.76264899979.issue27048@psf.upfronthosting.co.za> Eryk Sun added the comment: vcvarsall.bat is mostly `set` and `echo` statements, which print using UTF-16LE with "/u". It also runs reg.exe, but with stdout and stderr redirected to nul, so that's no problem. The final `set` command prints cmd's UTF-16LE environment. Using errors='replace' shouldn't be necessary. It doesn't hurt, however. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 15:52:43 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 17 Jun 2016 19:52:43 +0000 Subject: [issue26536] Add the SIO_LOOPBACK_FAST_PATH option to socket.ioctl In-Reply-To: <1457666128.63.0.278319184112.issue26536@psf.upfronthosting.co.za> Message-ID: <20160617195239.25143.96790.A1C5F987@psf.io> Roundup Robot added the comment: New changeset f8957c755c7a by Steve Dower in branch 'default': Issue #26536: socket.ioctl now supports SIO_LOOPBACK_FAST_PATH. Patch by Daniel Stokes. https://hg.python.org/cpython/rev/f8957c755c7a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 15:53:42 2016 From: report at bugs.python.org (Steve Dower) Date: Fri, 17 Jun 2016 19:53:42 +0000 Subject: [issue26536] Add the SIO_LOOPBACK_FAST_PATH option to socket.ioctl In-Reply-To: <1457666128.63.0.278319184112.issue26536@psf.upfronthosting.co.za> Message-ID: <1466193222.04.0.508273865203.issue26536@psf.upfronthosting.co.za> Steve Dower added the comment: All looked good to me, and as far as I could see all of Berker's feedback was addressed, so consider it in! ---------- assignee: -> steve.dower resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 15:59:49 2016 From: report at bugs.python.org (James Paget) Date: Fri, 17 Jun 2016 19:59:49 +0000 Subject: [issue27305] Crash with "pip list --outdated" on Windows 10 with Python 2.7.12rc1 In-Reply-To: <1465820074.65.0.989290191732.issue27305@psf.upfronthosting.co.za> Message-ID: <1466193589.67.0.0497176304521.issue27305@psf.upfronthosting.co.za> James Paget added the comment: The 2.7.12rc1+ build resolves the issue for me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 16:13:15 2016 From: report at bugs.python.org (Robert Haschke) Date: Fri, 17 Jun 2016 20:13:15 +0000 Subject: [issue24424] xml.dom.minidom: performance issue with Node.insertBefore() In-Reply-To: <1433942956.66.0.599460998017.issue24424@psf.upfronthosting.co.za> Message-ID: <1466194395.65.0.160701162788.issue24424@psf.upfronthosting.co.za> Robert Haschke added the comment: I don't see how to further minimize the checks - all of them are required. I think, the most common uses cases to create a document are appendChild(), which is not affected, and insertBefore() using the same refChild for a while. In that case, the patch gives a tremendous speedup. If you as maintainers don't want to share this improvement with the community, it's your choice and I will be fine with that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 17:20:35 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 17 Jun 2016 21:20:35 +0000 Subject: [issue19756] test_nntplib: sporadic failures, network isses? server down? In-Reply-To: <1385316451.32.0.948186129781.issue19756@psf.upfronthosting.co.za> Message-ID: <1466198435.1.0.923618725334.issue19756@psf.upfronthosting.co.za> Berker Peksag added the comment: I just saw the same test failures at http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.5/builds/998/steps/test/logs/stdio I'm attaching the test logs for future reference. ---------- nosy: +berker.peksag stage: -> needs patch type: -> behavior versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4 Added file: http://bugs.python.org/file43441/test_nntplib_logs.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 17:40:05 2016 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 17 Jun 2016 21:40:05 +0000 Subject: [issue26923] asyncio.gather drops cancellation In-Reply-To: <1465978869.72.0.730792032977.issue26923@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Thanks! I had eventually pieced together the same explanation. So yes, I think your fix is right, though I would write it like this: ret = False for child in self._children: ret |= child.cancel() return ret # True if at least one child.cancel() call returned True It would also be nice if there was a test for this behavior. I keep worrying a bit -- a similar bug could exist in other pieces of the code, or in other libraries. But I guess we can't do much about that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 18:40:07 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 17 Jun 2016 22:40:07 +0000 Subject: [issue27342] Clean up some Py_XDECREFs in rangeobject.c and bltinmodule.c In-Reply-To: <1466149168.09.0.735946487659.issue27342@psf.upfronthosting.co.za> Message-ID: <1466203207.77.0.376497844343.issue27342@psf.upfronthosting.co.za> Raymond Hettinger added the comment: v2 looks correct. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 19:29:20 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 17 Jun 2016 23:29:20 +0000 Subject: [issue19756] test_nntplib: sporadic failures, network isses? server down? In-Reply-To: <1385316451.32.0.948186129781.issue19756@psf.upfronthosting.co.za> Message-ID: <1466206160.82.0.948734761036.issue19756@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks Berker. In this case the previous tests using the same NNTP connection object were skipped. First run: test_unknown_command (test.test_nntplib.NetworkedNNTPTests) ... ok test_welcome (test.test_nntplib.NetworkedNNTPTests) ... ok test_with_statement (test.test_nntplib.NetworkedNNTPTests) ... skipped "Resource 'news.trigofacile.com' is not available" test_xhdr (test.test_nntplib.NetworkedNNTPTests) ... skipped "Resource 'news.trigofacile.com' is not available" test_xover (test.test_nntplib.NetworkedNNTPTests) ... ERROR test_zlogin (test.test_nntplib.NetworkedNNTPTests) ... ERROR test_zzquit (test.test_nntplib.NetworkedNNTPTests) ... ERROR Subsequent retry: test_xover (test.test_nntplib.NNTPv2Tests) ... ok test_article_head_body (test.test_nntplib.NetworkedNNTPTests) ... skipped "Resource 'news.trigofacile.com' is not available" test_capabilities (test.test_nntplib.NetworkedNNTPTests) ... ERROR test_date (test.test_nntplib.NetworkedNNTPTests) ... ERROR test_description (test.test_nntplib.NetworkedNNTPTests) ... ERROR test_descriptions (test.test_nntplib.NetworkedNNTPTests) ... ERROR test_group (test.test_nntplib.NetworkedNNTPTests) ... ERROR test_help (test.test_nntplib.NetworkedNNTPTests) ... ERROR test_list (test.test_nntplib.NetworkedNNTPTests) ... ERROR test_list_active (test.test_nntplib.NetworkedNNTPTests) ... ERROR test_newgroups (test.test_nntplib.NetworkedNNTPTests) ... ERROR test_over (test.test_nntplib.NetworkedNNTPTests) ... ERROR test_unknown_command (test.test_nntplib.NetworkedNNTPTests) ... ERROR test_welcome (test.test_nntplib.NetworkedNNTPTests) ... ok test_with_statement (test.test_nntplib.NetworkedNNTPTests) ... ok test_xhdr (test.test_nntplib.NetworkedNNTPTests) ... ERROR test_xover (test.test_nntplib.NetworkedNNTPTests) ... ERROR test_zlogin (test.test_nntplib.NetworkedNNTPTests) ... ERROR test_zzquit (test.test_nntplib.NetworkedNNTPTests) ... ERROR Test_with_statement() is a special case because it starts a fresh NNTP connection, rather than reusing self.server. Test_welcome() is also different because it does not send any new commands to the server. But I presume the other tests all try to reuse the old timed-out self.server object. The skipped messages are evidence of this. The easy solution which I mentioned above would be to change setUpClass() to setUp(), although this might slow the tests down a bit, reconnecting to the remote server for each test method. The solution that I prefer would be as Antoine suggested, to run our own server. I think expanding the server I created in Issue 25859 with more commands would be good enough. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 19:38:52 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 17 Jun 2016 23:38:52 +0000 Subject: [issue27309] Visual Styles support to tk/tkinter file and message dialogs In-Reply-To: <1465855196.42.0.576274211307.issue27309@psf.upfronthosting.co.za> Message-ID: <1466206732.28.0.25942953861.issue27309@psf.upfronthosting.co.za> Terry J. Reedy added the comment: tkinter.messagebox is based on tkinter.commondialog, first written in 1997. Since it works as originally designed, it does not seem to have been significantly altered since before themed widgets. Upgrading would be an enhancement for future versions, not a bugfix for all versions. The SO answer is correct that tkinter does not build the messagebox, but indeed calls into tk with, for message boxes, the command "tk_messageBox", to get the builtin box. Since I am converting IDLE on 3.6 to use ttk where appropriate, I would very mush like to be able to get the better looking versions of the builtin dialogs -- and in 3.6 -- and on all 3 majore systems, not just Windows. Since tkinter still supports 8.4 (should this change?) and ttk requires 8.5, this needs to be an option or at least version dependent. I report this issue in a comment on 'patthoyts' answer. ---------- components: +Tkinter nosy: +serhiy.storchaka, terry.reedy stage: -> test needed title: Visual Styles support -> Visual Styles support to tk/tkinter file and message dialogs type: behavior -> enhancement versions: +Python 3.6 -Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 19:56:14 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 17 Jun 2016 23:56:14 +0000 Subject: [issue27312] test_setupapp (idlelib.idle_test.test_macosx.SetupTest) fails on OS X In-Reply-To: <1465865390.09.0.618470621806.issue27312@psf.upfronthosting.co.za> Message-ID: <20160617235603.20088.7143.3A32A5B3@psf.io> Roundup Robot added the comment: New changeset 90fd1c17214b by Terry Jan Reedy in branch 'default': Issue #27312: mock out function that fails when called from setupApp during https://hg.python.org/cpython/rev/90fd1c17214b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 19:57:55 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 17 Jun 2016 23:57:55 +0000 Subject: [issue27312] test_setupapp (idlelib.idle_test.test_macosx.SetupTest) fails on OS X In-Reply-To: <1465865390.09.0.618470621806.issue27312@psf.upfronthosting.co.za> Message-ID: <1466207875.74.0.0121216819318.issue27312@psf.upfronthosting.co.za> Terry J. Reedy added the comment: My suggested mock was for the wrong function. Please let me know what happens next time you pull and run test_idle whether alone or with the suite. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 20:07:11 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 18 Jun 2016 00:07:11 +0000 Subject: [issue27341] mock.patch decorator fails silently on generators In-Reply-To: <1466141708.88.0.0388300458163.issue27341@psf.upfronthosting.co.za> Message-ID: <1466208431.93.0.0911308952318.issue27341@psf.upfronthosting.co.za> Terry J. Reedy added the comment: 3.2 to 3.4 only get security fixes please provide a simple test that fails now and that you think should pass or at least warn. ---------- nosy: +michael.foord, terry.reedy stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 20:22:16 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 18 Jun 2016 00:22:16 +0000 Subject: [issue27344] zipfile *does* support utf-8 filenames In-Reply-To: <1466176126.21.0.0133629365393.issue27344@psf.upfronthosting.co.za> Message-ID: <1466209336.26.0.529988235667.issue27344@psf.upfronthosting.co.za> Terry J. Reedy added the comment: There is a difference between 'official' and 'supported', and I don't quite know what you mean by the latter. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 21:17:46 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Jun 2016 01:17:46 +0000 Subject: [issue27312] test_setupapp (idlelib.idle_test.test_macosx.SetupTest) fails on OS X In-Reply-To: <1465865390.09.0.618470621806.issue27312@psf.upfronthosting.co.za> Message-ID: <20160618011740.78488.16201.A3DEBBD4@psf.io> Roundup Robot added the comment: New changeset 61bd6974405f by Berker Peksag in branch 'default': Issue #27312: Fix TypeError in test_setupapp https://hg.python.org/cpython/rev/61bd6974405f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 21:27:55 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 18 Jun 2016 01:27:55 +0000 Subject: [issue27292] Warn users that os.urandom() can return insecure values In-Reply-To: <1465639674.0.0.865291084778.issue27292@psf.upfronthosting.co.za> Message-ID: <1466213275.46.0.20256154567.issue27292@psf.upfronthosting.co.za> Martin Panter added the comment: Restored ?On Linux? for the changed in 3.5.2 notice. I do think it is better to be general and future-proof, but that is a separate, less important issue to the main purpose of the patch. (I don?t know if Solaris?s version can block or not.) ---------- stage: needs patch -> patch review Added file: http://bugs.python.org/file43442/urandom-doc.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 21:33:14 2016 From: report at bugs.python.org (Peter Eisentraut) Date: Sat, 18 Jun 2016 01:33:14 +0000 Subject: [issue27337] 3.6.0a2 tarball has weird paths In-Reply-To: <1466100270.24.0.259127068452.issue27337@psf.upfronthosting.co.za> Message-ID: <1466213594.93.0.263806522536.issue27337@psf.upfronthosting.co.za> Peter Eisentraut added the comment: The affected tar is indeed a BSD-ish tar (OS X). With GNU tar I can proceed. It says "gtar: Removing leading `../' from member names". So with that I agree that it's not worth rerolling this release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 22:02:49 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Jun 2016 02:02:49 +0000 Subject: [issue22636] avoid using a shell in ctypes.util: replace os.popen with subprocess In-Reply-To: <1413325975.89.0.175884398711.issue22636@psf.upfronthosting.co.za> Message-ID: <20160618020245.78473.19803.7276B8E4@psf.io> Roundup Robot added the comment: New changeset a09ae70f3489 by Victor Stinner in branch '2.7': Issue #22636: Avoid using a shell in the ctypes.util module https://hg.python.org/cpython/rev/a09ae70f3489 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 23:19:15 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 18 Jun 2016 03:19:15 +0000 Subject: [issue22636] avoid using a shell in ctypes.util: replace os.popen with subprocess In-Reply-To: <1413325975.89.0.175884398711.issue22636@psf.upfronthosting.co.za> Message-ID: <1466219955.47.0.753790929042.issue22636@psf.upfronthosting.co.za> Martin Panter added the comment: Sorry about impersonating your name as committer Victor. I have been fixing this problem in recent patches, but because I imported your patch a while ago I forgot about it. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 23:34:37 2016 From: report at bugs.python.org (Peter Williams) Date: Sat, 18 Jun 2016 03:34:37 +0000 Subject: [issue7164] pickle test failure after test_imp/test_import (_make_stat_result is not the same object as os._make_stat_result) In-Reply-To: <1255828463.78.0.430609801319.issue7164@psf.upfronthosting.co.za> Message-ID: <1466220877.15.0.759786733954.issue7164@psf.upfronthosting.co.za> Peter Williams added the comment: I'm experiencing a variation of this problem on a project where I'm trying to make an application that will work with both 2.7.x and 3.4.x and am mostly successful. The application uses a number of pickle files and I want to make it so that it doesn't matter which version created the pickle files the other can read it. By limiting the 3.4 version to pickle protocol 2 I've succeeded in having 2.7.x read 3.4.x pickle files but encountered a problem going the other way with the following error message: Traceback (most recent call last): File "/home/peter/SRC/GITHUB/epygibus.git/epygibus3", line 25, in sys.exit(ARGS.run_cmd(ARGS)) File "/home/peter/SRC/GITHUB/epygibus.git/epygibus_pkg/cli/subcmd_restore.py", line 70, in run_cmd snapshot.restore_subdir(args.archive_name, os.sep, seln_fn=lambda l: l[-1-args.back]) File "/home/peter/SRC/GITHUB/epygibus.git/epygibus_pkg/snapshot.py", line 699, in restore_subdir snapshot_fs = get_snapshot_fs(archive_name, seln_fn).get_subdir(abs_subdir_path) File "/home/peter/SRC/GITHUB/epygibus.git/epygibus_pkg/snapshot.py", line 595, in get_snapshot_fs snapshot = read_snapshot(os.path.join(archive.snapshot_dir_path, snapshot_name)) File "/home/peter/SRC/GITHUB/epygibus.git/epygibus_pkg/snapshot.py", line 236, in read_snapshot return pickle.load(fobj) AttributeError: Can't get attribute '_make_stat_result' on I'm pretty sure that this is a result of that pickle file containing instances of the output from os.lstat() generated by 2.7.x which 3.4.x is having trouble instantiating. The source code for the application with the problem is available on github as repo "epygibus" for user "pwil3058". ---------- nosy: +Peter Williams _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 23:58:59 2016 From: report at bugs.python.org (Robert Collins) Date: Sat, 18 Jun 2016 03:58:59 +0000 Subject: [issue27341] mock.patch decorating a generator returns a regular function. In-Reply-To: <1466141708.88.0.0388300458163.issue27341@psf.upfronthosting.co.za> Message-ID: <1466222339.6.0.915752159957.issue27341@psf.upfronthosting.co.za> Robert Collins added the comment: There are two related things here. Firstly, the generator's body will run without the patch (because the wrapping function has try: return decorated(..) finally: unpwatch() Secondly, the wrapping function is itself not a generator, and anything that introspects functions to see if they are generators will not detect the wrapped function as one - which is I suspect whats tripping nose up, but I haven't actually checked the nose code to see what its doing/expecting. ---------- nosy: +rbcollins title: mock.patch decorator fails silently on generators -> mock.patch decorating a generator returns a regular function. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 17 23:59:32 2016 From: report at bugs.python.org (Robert Collins) Date: Sat, 18 Jun 2016 03:59:32 +0000 Subject: [issue27341] mock.patch decorating a generator returns a regular function. In-Reply-To: <1466141708.88.0.0388300458163.issue27341@psf.upfronthosting.co.za> Message-ID: <1466222372.18.0.327785413729.issue27341@psf.upfronthosting.co.za> Robert Collins added the comment: Once fixed in CPython, we'll put the backport in mock, for folk using older Python's. ---------- versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 00:18:24 2016 From: report at bugs.python.org (Pedro Lacerda) Date: Sat, 18 Jun 2016 04:18:24 +0000 Subject: [issue27258] Exception in BytesGenerator.flatten In-Reply-To: <1465329163.65.0.664069941673.issue27258@psf.upfronthosting.co.za> Message-ID: <1466223504.73.0.399951844858.issue27258@psf.upfronthosting.co.za> Pedro Lacerda added the comment: Seems that ``token.has_fws`` evaluates to True in the following condition if token.has_fws: causing ``token._fold(self)`` where isn't needed and raising the exception. Hope it helps! By the way, why the _header_value_parser.py was removed from the repository? https://github.com/python/cpython/blob/master/Lib/email/_header_value_parser.py#L144 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 00:30:37 2016 From: report at bugs.python.org (Peter Eisentraut) Date: Sat, 18 Jun 2016 04:30:37 +0000 Subject: [issue25548] Show the address in the repr for class objects In-Reply-To: <1446576011.58.0.372024983976.issue25548@psf.upfronthosting.co.za> Message-ID: <1466224237.87.0.796448116253.issue25548@psf.upfronthosting.co.za> Peter Eisentraut added the comment: I understand the reasoning here, but I want to say booh to this change in 3.6.0a2 because it breaks my tests. It used to be that type(x) returned a predictable string, and that was an easy way to verify the result types of things. Perhaps a __str__ implementation could be added that avoids the memory address? ---------- nosy: +petere _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 00:37:27 2016 From: report at bugs.python.org (Shoshana Berleant) Date: Sat, 18 Jun 2016 04:37:27 +0000 Subject: [issue27341] mock.patch decorating a generator returns a regular function. In-Reply-To: <1466141708.88.0.0388300458163.issue27341@psf.upfronthosting.co.za> Message-ID: <1466224647.74.0.721101831129.issue27341@psf.upfronthosting.co.za> Shoshana Berleant added the comment: I attached a file with 4 tests and the output. nosetests reports that all four tests were executed. In reality, only two tests were executed. ---------- Added file: http://bugs.python.org/file43443/silentfail.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 00:37:56 2016 From: report at bugs.python.org (Shoshana Berleant) Date: Sat, 18 Jun 2016 04:37:56 +0000 Subject: [issue27341] mock.patch decorating a generator returns a regular function. In-Reply-To: <1466141708.88.0.0388300458163.issue27341@psf.upfronthosting.co.za> Message-ID: <1466224676.68.0.638979201248.issue27341@psf.upfronthosting.co.za> Shoshana Berleant added the comment: output ---------- Added file: http://bugs.python.org/file43444/actual.out _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 00:51:51 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 18 Jun 2016 04:51:51 +0000 Subject: [issue25548] Show the address in the repr for class objects In-Reply-To: <1446576011.58.0.372024983976.issue25548@psf.upfronthosting.co.za> Message-ID: <1466225511.32.0.0904263644864.issue25548@psf.upfronthosting.co.za> Martin Panter added the comment: There is also Issue 13224 proposing to change __str__() to just return the __name__ or __qualname__ if I remember correctly. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 01:02:59 2016 From: report at bugs.python.org (=?utf-8?q?J=C3=BCrgen_A=2E_Erhard?=) Date: Sat, 18 Jun 2016 05:02:59 +0000 Subject: [issue22908] ZipExtFile in zipfile can be seekable In-Reply-To: <1416496843.38.0.905339069508.issue22908@psf.upfronthosting.co.za> Message-ID: <1466226179.03.0.797865835373.issue22908@psf.upfronthosting.co.za> J?rgen A. Erhard added the comment: To add to this (without looking at the patch): I just to my astonishment learned that a ZipExtFile doesn't even support tell(). I can understand the seek being nontrivial... but the tell? It's a bytestream, and there is (isn't there?) a clear definition of what next byte a read(1) would deliver. It should be trivial to keep track of the (only ever increasing) file position. ---------- nosy: +jae _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 01:45:25 2016 From: report at bugs.python.org (Ned Deily) Date: Sat, 18 Jun 2016 05:45:25 +0000 Subject: [issue27337] 3.6.0a2 tarball has weird paths In-Reply-To: <1466100270.24.0.259127068452.issue27337@psf.upfronthosting.co.za> Message-ID: <1466228725.64.0.0534076768393.issue27337@psf.upfronthosting.co.za> Ned Deily added the comment: OK, thanks for the info. I'm going to close this issue as "won't fix" and try real hard not to do it again. ---------- resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 02:05:44 2016 From: report at bugs.python.org (STINNER Victor) Date: Sat, 18 Jun 2016 06:05:44 +0000 Subject: [issue22636] avoid using a shell in ctypes.util: replace os.popen with subprocess In-Reply-To: <1466219955.47.0.753790929042.issue22636@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: No problemo. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 02:07:58 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 18 Jun 2016 06:07:58 +0000 Subject: [issue7769] SimpleXMLRPCServer.SimpleXMLRPCServer.register_function as decorator In-Reply-To: <1264337326.51.0.913533963705.issue7769@psf.upfronthosting.co.za> Message-ID: <1466230078.46.0.0522189052182.issue7769@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- nosy: +loewis, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 02:29:12 2016 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 18 Jun 2016 06:29:12 +0000 Subject: [issue22228] Adapt bash readline operate-and-get-next function In-Reply-To: <1408441328.29.0.0681426449148.issue22228@psf.upfronthosting.co.za> Message-ID: <1466231352.44.0.0923478704452.issue22228@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 02:29:51 2016 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 18 Jun 2016 06:29:51 +0000 Subject: [issue19756] test_nntplib: sporadic failures, network isses? server down? In-Reply-To: <1385316451.32.0.948186129781.issue19756@psf.upfronthosting.co.za> Message-ID: <1466231391.54.0.288872954089.issue19756@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 02:41:49 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jun 2016 06:41:49 +0000 Subject: [issue24424] xml.dom.minidom: performance issue with Node.insertBefore() In-Reply-To: <1433942956.66.0.599460998017.issue24424@psf.upfronthosting.co.za> Message-ID: <1466232109.46.0.577033857665.issue24424@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There are different tricks that allow to minimize an overhead. Here is tuned patch. But I still not sure that this special case is worth to be optimized. ---------- Added file: http://bugs.python.org/file43445/minidom.insertBefore2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 02:44:28 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Jun 2016 06:44:28 +0000 Subject: [issue27342] Clean up some Py_XDECREFs in rangeobject.c and bltinmodule.c In-Reply-To: <1466149168.09.0.735946487659.issue27342@psf.upfronthosting.co.za> Message-ID: <20160618064425.25162.12511.AA7EFF43@psf.io> Roundup Robot added the comment: New changeset 52931189d7ee by Serhiy Storchaka in branch 'default': Issue #27342: Replaced some Py_XDECREFs with Py_DECREFs. https://hg.python.org/cpython/rev/52931189d7ee ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 02:45:18 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jun 2016 06:45:18 +0000 Subject: [issue27342] Clean up some Py_XDECREFs in rangeobject.c and bltinmodule.c In-Reply-To: <1466149168.09.0.735946487659.issue27342@psf.upfronthosting.co.za> Message-ID: <1466232318.77.0.0513548838998.issue27342@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 02:46:11 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jun 2016 06:46:11 +0000 Subject: [issue27333] validate_step in rangeobject.c, incorrect code logic but right result In-Reply-To: <1466094985.85.0.664632093379.issue27333@psf.upfronthosting.co.za> Message-ID: <1466232371.1.0.179275493677.issue27333@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Agreed. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 02:52:50 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Jun 2016 06:52:50 +0000 Subject: [issue27333] validate_step in rangeobject.c, incorrect code logic but right result In-Reply-To: <1466094985.85.0.664632093379.issue27333@psf.upfronthosting.co.za> Message-ID: <20160618065247.9830.64016.C8F297F1@psf.io> Roundup Robot added the comment: New changeset 4fbcd58df1a0 by Serhiy Storchaka in branch 'default': Issue #27333: Simplified testing step on 0. https://hg.python.org/cpython/rev/4fbcd58df1a0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 02:53:38 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jun 2016 06:53:38 +0000 Subject: [issue27333] validate_step in rangeobject.c, incorrect code logic but right result In-Reply-To: <1466094985.85.0.664632093379.issue27333@psf.upfronthosting.co.za> Message-ID: <1466232818.97.0.117863102154.issue27333@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your review Xiang. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 02:59:20 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Jun 2016 06:59:20 +0000 Subject: [issue27343] Incorrect error message for conflicting initializers of ctypes structure In-Reply-To: <1466152506.85.0.761729161431.issue27343@psf.upfronthosting.co.za> Message-ID: <20160618065916.67236.69439.BAD1BD5E@psf.io> Roundup Robot added the comment: New changeset ed81fc7e285b by Serhiy Storchaka in branch '3.5': Issue #27343: Fixed error message for conflicting initializers of ctypes.Structure. https://hg.python.org/cpython/rev/ed81fc7e285b New changeset 40e3790c2a00 by Serhiy Storchaka in branch 'default': Issue #27343: Fixed error message for conflicting initializers of ctypes.Structure. https://hg.python.org/cpython/rev/40e3790c2a00 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 03:00:07 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jun 2016 07:00:07 +0000 Subject: [issue27343] Incorrect error message for conflicting initializers of ctypes structure In-Reply-To: <1466152506.85.0.761729161431.issue27343@psf.upfronthosting.co.za> Message-ID: <1466233207.38.0.211991132963.issue27343@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 03:15:55 2016 From: report at bugs.python.org (Ryan Birmingham) Date: Sat, 18 Jun 2016 07:15:55 +0000 Subject: [issue27345] GzipFile's readinto() reads gzip data instead of file data. Message-ID: <1466234155.82.0.00888725060724.issue27345@psf.upfronthosting.co.za> New submission from Ryan Birmingham: In cases where libraries try to call readinto(), the results are unexpected (the gzip data). Shouldn't it instead raise UnsupportedOperation for readinto() (and truncate())? ---------- components: IO files: gzip_readinto.patch keywords: patch messages: 268773 nosy: Ryan Birmingham priority: normal severity: normal status: open title: GzipFile's readinto() reads gzip data instead of file data. type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file43446/gzip_readinto.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 03:36:20 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jun 2016 07:36:20 +0000 Subject: [issue27122] Hang with contextlib.ExitStack and subprocess.Popen (regression) In-Reply-To: <1464176880.25.0.308106356091.issue27122@psf.upfronthosting.co.za> Message-ID: <1466235380.1.0.765837361857.issue27122@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here are additional tests. ---------- status: closed -> open Added file: http://bugs.python.org/file43447/issue27122-additional-tests.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 03:37:37 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jun 2016 07:37:37 +0000 Subject: [issue27177] re match.group should support __index__ In-Reply-To: <1464790808.77.0.698310162067.issue27177@psf.upfronthosting.co.za> Message-ID: <1466235457.69.0.263543238501.issue27177@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What is the use case? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 04:23:15 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Jun 2016 08:23:15 +0000 Subject: [issue24314] irrelevant cross-link in documentation of user-defined functions In-Reply-To: <1432823234.49.0.975414233418.issue24314@psf.upfronthosting.co.za> Message-ID: <20160618082311.67155.32637.9D963D5E@psf.io> Roundup Robot added the comment: New changeset 1ed4e4a168bb by Martin Panter in branch '2.7': Issue #24314: Add links for general attributes like __name__, __dict__ https://hg.python.org/cpython/rev/1ed4e4a168bb New changeset 4c361e189747 by Martin Panter in branch '3.5': Issue #24314: Fix doc links for general attributes like __name__, __dict__ https://hg.python.org/cpython/rev/4c361e189747 New changeset 79a3aff60e37 by Martin Panter in branch 'default': Issue #24314: Merge doc links from 3.5 https://hg.python.org/cpython/rev/79a3aff60e37 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 05:02:34 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 18 Jun 2016 09:02:34 +0000 Subject: [issue26536] Add the SIO_LOOPBACK_FAST_PATH option to socket.ioctl In-Reply-To: <1457666128.63.0.278319184112.issue26536@psf.upfronthosting.co.za> Message-ID: <1466240554.9.0.40230400648.issue26536@psf.upfronthosting.co.za> Martin Panter added the comment: This is failing on Windows 7 buildbots: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/7849/steps/test/logs/stdio ====================================================================== ERROR: test_sio_loopback_fast_path (test.test_socket.GeneralModuleTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_socket.py", line 1226, in test_sio_loopback_fast_path s.ioctl(socket.SIO_LOOPBACK_FAST_PATH, True) OSError: [WinError 10045] The attempted operation is not supported for the type of object referenced ---------- nosy: +martin.panter status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 05:04:44 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 18 Jun 2016 09:04:44 +0000 Subject: [issue24314] irrelevant cross-link in documentation of user-defined functions In-Reply-To: <1432823234.49.0.975414233418.issue24314@psf.upfronthosting.co.za> Message-ID: <1466240684.97.0.316255004412.issue24314@psf.upfronthosting.co.za> Martin Panter added the comment: I also backported most of my changes to 2.7, although __name__ wasn?t originally linking to anything at all there. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 05:16:04 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Sat, 18 Jun 2016 09:16:04 +0000 Subject: [issue27149] Implement socket.sendmsg() for Windows In-Reply-To: <1464501034.91.0.597053336572.issue27149@psf.upfronthosting.co.za> Message-ID: <1466241364.54.0.007157427814.issue27149@psf.upfronthosting.co.za> ???? ????????? added the comment: WSASend function can send array of buffers: https://msdn.microsoft.com/en-us/library/ms742203(v=vs.85).aspx ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 05:20:21 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 18 Jun 2016 09:20:21 +0000 Subject: [issue19884] Importing readline produces erroneous output In-Reply-To: <1386158776.45.0.265770743985.issue19884@psf.upfronthosting.co.za> Message-ID: <1466241621.28.0.0450692005209.issue19884@psf.upfronthosting.co.za> Martin Panter added the comment: Yogesh: Victor?s patch has already been applied. What is left to do is another patch that enables Victor?s code on OS X when Gnu Readline is being used, as opposed to the usual Apple Editline. Also, I think it is valid to update the version check to 6.1. According to , enable-meta-key is in 6.1, but not 6.0. On 6.0 the code probably has no effect. ---------- nosy: +martin.panter stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 05:31:33 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 18 Jun 2016 09:31:33 +0000 Subject: [issue19884] Importing readline produces erroneous output In-Reply-To: <1386158776.45.0.265770743985.issue19884@psf.upfronthosting.co.za> Message-ID: <1466242293.83.0.0162720350614.issue19884@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch to enable the workaround on OS X, and to adjust the test condition to 6.1. It would be nice if someone with OS X and Gnu Readline can confirm that this fixes the problem. ---------- stage: needs patch -> patch review Added file: http://bugs.python.org/file43448/meta-osx.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 05:39:53 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Sat, 18 Jun 2016 09:39:53 +0000 Subject: [issue27346] Implement os.readv() / os.readv() Message-ID: <1466242793.09.0.103237179238.issue27346@psf.upfronthosting.co.za> New submission from ???? ?????????: These functions are not implemented natively in Windows, but the Windows API has analogous functions ReadFileScatter and WriteFileGather. ---------- components: IO, Library (Lib) messages: 268782 nosy: mmarkk priority: normal severity: normal status: open title: Implement os.readv() / os.readv() type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 05:40:03 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Sat, 18 Jun 2016 09:40:03 +0000 Subject: [issue27346] Implement os.readv() / os.writev() In-Reply-To: <1466242793.09.0.103237179238.issue27346@psf.upfronthosting.co.za> Message-ID: <1466242803.21.0.0867694730339.issue27346@psf.upfronthosting.co.za> Changes by ???? ????????? : ---------- title: Implement os.readv() / os.readv() -> Implement os.readv() / os.writev() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 05:40:25 2016 From: report at bugs.python.org (Oleg Babintsev) Date: Sat, 18 Jun 2016 09:40:25 +0000 Subject: [issue25717] tempfile.TemporaryFile fails when dir option set to directory residing on host OS mount In-Reply-To: <1448339024.55.0.65158482353.issue25717@psf.upfronthosting.co.za> Message-ID: <1466242825.85.0.103194355865.issue25717@psf.upfronthosting.co.za> Oleg Babintsev added the comment: Problem is still actual for Python 2.7 Can you provide the fix for 2.7 too? ---------- nosy: +Oleg Babintsev versions: +Python 2.7 -Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 05:40:42 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Sat, 18 Jun 2016 09:40:42 +0000 Subject: [issue27021] It is not documented that os.writev() suffer from SC_IOV_MAX In-Reply-To: <1463247246.11.0.121733863987.issue27021@psf.upfronthosting.co.za> Message-ID: <1466242842.28.0.263952166297.issue27021@psf.upfronthosting.co.za> ???? ????????? added the comment: Also it is not documented that os.writev() is not awailable on Windows (!) Also see issue27346 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 05:41:17 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Sat, 18 Jun 2016 09:41:17 +0000 Subject: [issue27346] Implement os.readv() / os.writev() In-Reply-To: <1466242793.09.0.103237179238.issue27346@psf.upfronthosting.co.za> Message-ID: <1466242877.98.0.0118050285786.issue27346@psf.upfronthosting.co.za> ???? ????????? added the comment: Also do not forget to fix documentation: issue27021 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 05:43:56 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 18 Jun 2016 09:43:56 +0000 Subject: [issue27346] Implement os.readv() / os.writev() In-Reply-To: <1466242793.09.0.103237179238.issue27346@psf.upfronthosting.co.za> Message-ID: <1466243036.37.0.215873672814.issue27346@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- components: +Extension Modules, Windows -Library (Lib) nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 05:45:11 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Sat, 18 Jun 2016 09:45:11 +0000 Subject: [issue27021] It is not documented that os.writev() suffer from SC_IOV_MAX In-Reply-To: <1463247246.11.0.121733863987.issue27021@psf.upfronthosting.co.za> Message-ID: <1466243111.01.0.115870914822.issue27021@psf.upfronthosting.co.za> ???? ????????? added the comment: Oops. It is documented in latest version... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 05:54:18 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Sat, 18 Jun 2016 09:54:18 +0000 Subject: [issue27021] It is not documented that os.writev() suffer from SC_IOV_MAX In-Reply-To: <1463247246.11.0.121733863987.issue27021@psf.upfronthosting.co.za> Message-ID: <1466243658.34.0.776924859076.issue27021@psf.upfronthosting.co.za> ???? ????????? added the comment: Attached the patch. Please review. ---------- keywords: +patch Added file: http://bugs.python.org/file43449/writev_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 05:59:08 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Sat, 18 Jun 2016 09:59:08 +0000 Subject: [issue27346] Implement os.readv() / os.writev() In-Reply-To: <1466242793.09.0.103237179238.issue27346@psf.upfronthosting.co.za> Message-ID: <1466243948.73.0.135778304923.issue27346@psf.upfronthosting.co.za> ???? ????????? added the comment: however, unlike the POSIX functions, they require the alignment of each buffer on a memory page ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 05:59:45 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jun 2016 09:59:45 +0000 Subject: [issue27319] Multiple item arguments for selection operations In-Reply-To: <1465926060.08.0.266570766159.issue27319@psf.upfronthosting.co.za> Message-ID: <1466243985.0.0.513375240117.issue27319@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'm not sure that passing multiple items as a tuple should be deprecated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 05:59:53 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 18 Jun 2016 09:59:53 +0000 Subject: [issue25717] tempfile.TemporaryFile fails when dir option set to directory residing on host OS mount In-Reply-To: <1448339024.55.0.65158482353.issue25717@psf.upfronthosting.co.za> Message-ID: <1466243993.93.0.917582676507.issue25717@psf.upfronthosting.co.za> Martin Panter added the comment: Are you sure Oleg? As far as I understand, Python 2 by default wraps C stdio file objects, and also has Python 3?s file objects in the ?io? module. But I expect TemporaryFile() would use the default stdio files, and the cause of this bug, Issue 21679, should only have affected the ?io? module in 3.5+. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 06:25:35 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 18 Jun 2016 10:25:35 +0000 Subject: [issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more In-Reply-To: <1464270042.87.0.0233765451432.issue27130@psf.upfronthosting.co.za> Message-ID: <1466245535.79.0.147257260739.issue27130@psf.upfronthosting.co.za> Xiang Zhang added the comment: Upload the new patch to fix bugs and make improvements. I'll add tests later. ---------- Added file: http://bugs.python.org/file43450/64bit_support_for_zlib_v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 06:35:39 2016 From: report at bugs.python.org (Oleg Babintsev) Date: Sat, 18 Jun 2016 10:35:39 +0000 Subject: [issue25717] tempfile.TemporaryFile fails when dir option set to directory residing on host OS mount In-Reply-To: <1448339024.55.0.65158482353.issue25717@psf.upfronthosting.co.za> Message-ID: <1466246139.27.0.206284878089.issue25717@psf.upfronthosting.co.za> Oleg Babintsev added the comment: My environment: Windows as host OS, VirtualBox VM, Linux as guest OS When temporary directory is a directory which mounted from the host OS, a "OSError: [Errno 26] Text file busy" exception is thrown. Test file: import tempfile with tempfile.TemporaryFile(dir="/tmp") as tf: tf.write("testing testing testing\n".encode('utf-8')) print("Temp file: worked") "/tmp" directory - is a shared folder (vboxsf) Result: root at 0e87f2561643:/# python /etc/odoo/tempfile-test.py Traceback (most recent call last): File "/etc/odoo/tempfile-test.py", line 3, in with tempfile.TemporaryFile(dir="/tmp") as tf: File "/usr/lib/python2.7/tempfile.py", line 513, in TemporaryFile _os.unlink(name) OSError: [Errno 26] Text file busy: '/tmp/tmpsl0JQI' root at 0e87f2561643:/# python --version Python 2.7.11+ root at 0e87f2561643:/# python Python 2.7.11+ (default, Jun 2 2016, 19:34:15) [GCC 5.3.1 20160528] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.version '2.7.11+ (default, Jun 2 2016, 19:34:15) \n[GCC 5.3.1 20160528]' >>> ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 06:38:07 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jun 2016 10:38:07 +0000 Subject: [issue27294] Better repr for Tkinter event objects In-Reply-To: <1465648557.25.0.737232700025.issue27294@psf.upfronthosting.co.za> Message-ID: <1466246287.37.0.28396171363.issue27294@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: According to Tk sources on Mac OSX: Mod1 is Command (=Meta), Mod2 is Option (=Alt), Mod3 is NumLock, Mod4 is Fn. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 06:54:16 2016 From: report at bugs.python.org (Lele Gaifax) Date: Sat, 18 Jun 2016 10:54:16 +0000 Subject: [issue22228] Adapt bash readline operate-and-get-next function In-Reply-To: <1466082860.44.0.0477512627037.issue22228@psf.upfronthosting.co.za> Message-ID: <87vb16wywa.fsf@metapensiero.it> Lele Gaifax added the comment: In https://github.com/lelit/cpython/commit/3e5e557a876831a99c21f5a173623cb05ff48abf I reimplemented the functionality in a slightly different and hopefully better way, rebasing it on current master. IANAL, but I think that the new approach is different enough from the original GNU bash code to be considered safe from the license point of view. I still could not test it against the editline alternative implementation: AFAICT all the functions and symbols I used are exposed by that library too, so it may work without resorting to #ifdefs. In that regards however, I think we could and should take a different approach in determining which underlying implementation is used: GNU readline >= 4.1 exposes a rl_gnu_readline_p flag that could be used at configure time to define a IS_GNU_READLINE, and then rely on that to implement different code paths within the readline.c module. Please let me know if I should upload a traditional patch, instead of referencing my branch on github. As usual, thank you for any review and feedback! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 06:56:41 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Jun 2016 10:56:41 +0000 Subject: [issue26754] PyUnicode_FSDecoder() accepts arbitrary iterable In-Reply-To: <1460621170.51.0.766625206789.issue26754@psf.upfronthosting.co.za> Message-ID: <20160618105637.9852.27472.724BE03C@psf.io> Roundup Robot added the comment: New changeset 2e48c2c4c733 by Serhiy Storchaka in branch '3.5': Issue #26754: PyUnicode_FSDecoder() accepted a filename argument encoded as https://hg.python.org/cpython/rev/2e48c2c4c733 New changeset e18ac7370113 by Serhiy Storchaka in branch 'default': Issue #26754: PyUnicode_FSDecoder() accepted a filename argument encoded as https://hg.python.org/cpython/rev/e18ac7370113 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 07:36:33 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 18 Jun 2016 11:36:33 +0000 Subject: [issue25717] tempfile.TemporaryFile fails when dir option set to directory residing on host OS mount In-Reply-To: <1448339024.55.0.65158482353.issue25717@psf.upfronthosting.co.za> Message-ID: <1466249793.21.0.354595975289.issue25717@psf.upfronthosting.co.za> Martin Panter added the comment: This original bug was about fstat() failing for an anonymous file (after the directory entry was removed). But in your situation the file system refuses to unlink the directory entry. If you think there is something that can be fixed in Python, I suggest open a new bug. But it seems this is working as documented: ?Under Unix, the directory entry for the file is removed immediately after the file is created.? In your case, this cannot happen, so you get the error from the OS. ---------- versions: +Python 3.5, Python 3.6 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 07:40:28 2016 From: report at bugs.python.org (Jeroen Demeyer) Date: Sat, 18 Jun 2016 11:40:28 +0000 Subject: [issue27177] re match.group should support __index__ In-Reply-To: <1464790808.77.0.698310162067.issue27177@psf.upfronthosting.co.za> Message-ID: <1466250028.24.0.497231428588.issue27177@psf.upfronthosting.co.za> Jeroen Demeyer added the comment: My use case is SageMath: http://trac.sagemath.org/ticket/20750 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 07:45:35 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jun 2016 11:45:35 +0000 Subject: [issue26754] PyUnicode_FSDecoder() accepts arbitrary iterable In-Reply-To: <1460621170.51.0.766625206789.issue26754@psf.upfronthosting.co.za> Message-ID: <1466250335.47.0.16056117254.issue26754@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Following patch deprecates the support of bytes-like objects (except bytes itself) in PyUnicode_FSDecoder() for consistency with issue26800. ---------- dependencies: +Don't accept bytearray as filenames part 2 versions: -Python 3.5 Added file: http://bugs.python.org/file43451/PyUnicode_FSDecoder-deprecate-buffer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 08:31:07 2016 From: report at bugs.python.org (Eryk Sun) Date: Sat, 18 Jun 2016 12:31:07 +0000 Subject: [issue27346] Implement os.readv() / os.writev() In-Reply-To: <1466242793.09.0.103237179238.issue27346@psf.upfronthosting.co.za> Message-ID: <1466253067.71.0.338283929852.issue27346@psf.upfronthosting.co.za> Eryk Sun added the comment: ReadFileScatter and WriteFileGather also require a handle for a file that's opened with FILE_FLAG_OVERLAPPED (asynchronous access; the file pointer is not updated) and FILE_FLAG_NO_BUFFERING (buffers must be a multiple of the physical sector size and aligned to the physical sector size). So Python wouldn't be able to use the C runtime's POSIX (low) I/O implementation. ISTM this requires resolving issue 12939, with support for overlapped I/O. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 08:32:39 2016 From: report at bugs.python.org (Eryk Sun) Date: Sat, 18 Jun 2016 12:32:39 +0000 Subject: [issue27346] Implement os.readv() / os.writev() In-Reply-To: <1466242793.09.0.103237179238.issue27346@psf.upfronthosting.co.za> Message-ID: <1466253159.58.0.828053794272.issue27346@psf.upfronthosting.co.za> Changes by Eryk Sun : ---------- components: +Library (Lib) -Extension Modules _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 09:06:55 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jun 2016 13:06:55 +0000 Subject: [issue27177] re match.group should support __index__ In-Reply-To: <1464790808.77.0.698310162067.issue27177@psf.upfronthosting.co.za> Message-ID: <1466255215.97.0.134135455249.issue27177@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Interesting. This is very unusual but reasonable use case. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 09:09:29 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Jun 2016 13:09:29 +0000 Subject: [issue26536] Add the SIO_LOOPBACK_FAST_PATH option to socket.ioctl In-Reply-To: <1457666128.63.0.278319184112.issue26536@psf.upfronthosting.co.za> Message-ID: <20160618130925.9852.84026.A33D4C4E@psf.io> Roundup Robot added the comment: New changeset e8b10ed64e63 by Berker Peksag in branch 'default': Issue #26536: Skip test_sio_loopback_fast_path under Windows 7 https://hg.python.org/cpython/rev/e8b10ed64e63 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 09:40:54 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 18 Jun 2016 13:40:54 +0000 Subject: [issue26536] Add the SIO_LOOPBACK_FAST_PATH option to socket.ioctl In-Reply-To: <1457666128.63.0.278319184112.issue26536@psf.upfronthosting.co.za> Message-ID: <1466257254.47.0.542005817264.issue26536@psf.upfronthosting.co.za> Berker Peksag added the comment: It looks like SIO_LOOPBACK_FAST_PATH is also defined in older Windows versions. I updated the test to skip if SIO_LOOPBACK_FAST_PATH is defined and exc.winerror is WSAEOPNOTSUPP. Buildbot is now green: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/7855 Please reopen if I did something wrong. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 09:42:43 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Jun 2016 13:42:43 +0000 Subject: [issue26536] Add the SIO_LOOPBACK_FAST_PATH option to socket.ioctl In-Reply-To: <1457666128.63.0.278319184112.issue26536@psf.upfronthosting.co.za> Message-ID: <20160618134240.67048.57940.54E9464B@psf.io> Roundup Robot added the comment: New changeset 213c240cce0a by Berker Peksag in branch 'default': Issue #26536: Use spaces instead of tabs https://hg.python.org/cpython/rev/213c240cce0a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 09:48:29 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Jun 2016 13:48:29 +0000 Subject: [issue27177] re match.group should support __index__ In-Reply-To: <1464790808.77.0.698310162067.issue27177@psf.upfronthosting.co.za> Message-ID: <20160618134826.5022.71965.8DB5BEF1@psf.io> Roundup Robot added the comment: New changeset 0303ab246152 by Serhiy Storchaka in branch 'default': Issue #27177: Match objects in the re module now support index-like objects https://hg.python.org/cpython/rev/0303ab246152 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 10:02:25 2016 From: report at bugs.python.org (Steve Dower) Date: Sat, 18 Jun 2016 14:02:25 +0000 Subject: [issue26536] Add the SIO_LOOPBACK_FAST_PATH option to socket.ioctl In-Reply-To: <1457666128.63.0.278319184112.issue26536@psf.upfronthosting.co.za> Message-ID: <1466258545.22.0.24764846218.issue26536@psf.upfronthosting.co.za> Steve Dower added the comment: That'll handle the test fine, though I wonder whether we should try and conditionally define the constant at runtime? Probably at least want to add a note to the docs about Win 8 being the minimum, especially since so many people are still on 7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 10:13:40 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jun 2016 14:13:40 +0000 Subject: [issue27177] re match.group should support __index__ In-Reply-To: <1464790808.77.0.698310162067.issue27177@psf.upfronthosting.co.za> Message-ID: <1466259220.05.0.247322187651.issue27177@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 10:18:49 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 18 Jun 2016 14:18:49 +0000 Subject: [issue26536] Add the SIO_LOOPBACK_FAST_PATH option to socket.ioctl In-Reply-To: <1457666128.63.0.278319184112.issue26536@psf.upfronthosting.co.za> Message-ID: <1466259529.43.0.328295482808.issue26536@psf.upfronthosting.co.za> Berker Peksag added the comment: > That'll handle the test fine, though I wonder whether we should try and conditionally define the constant at runtime? +1. Is it safe to use IsWindows8OrGreater()? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 10:29:01 2016 From: report at bugs.python.org (Pedro Lacerda) Date: Sat, 18 Jun 2016 14:29:01 +0000 Subject: [issue27258] Exception in BytesGenerator.flatten In-Reply-To: <1465329163.65.0.664069941673.issue27258@psf.upfronthosting.co.za> Message-ID: <1466260141.15.0.833350205439.issue27258@psf.upfronthosting.co.za> Pedro Lacerda added the comment: Now the file is back! If any previous header has a newline before the value the error will not happen. But even with the output correct it isn't as expected. ---------- Added file: http://bugs.python.org/file43456/flatten-no-exception.mail _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 10:29:48 2016 From: report at bugs.python.org (Pedro Lacerda) Date: Sat, 18 Jun 2016 14:29:48 +0000 Subject: [issue27258] Exception in BytesGenerator.flatten In-Reply-To: <1465329163.65.0.664069941673.issue27258@psf.upfronthosting.co.za> Message-ID: <1466260188.44.0.327749011393.issue27258@psf.upfronthosting.co.za> Pedro Lacerda added the comment: Now the file is back! If any previous header has a newline before the value the error will not happen. But even with the output correct it isn't as expected. ---------- Added file: http://bugs.python.org/file43457/flatten-no-exception.mail _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 10:29:48 2016 From: report at bugs.python.org (Daniel Griffin) Date: Sat, 18 Jun 2016 14:29:48 +0000 Subject: [issue22228] Adapt bash readline operate-and-get-next function In-Reply-To: <1408441328.29.0.0681426449148.issue22228@psf.upfronthosting.co.za> Message-ID: <1466260188.51.0.015172141741.issue22228@psf.upfronthosting.co.za> Daniel Griffin added the comment: Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License. ---------- nosy: +Daniel Griffin Added file: http://bugs.python.org/file43453/bugreport-2016-05-18-03-28-01.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 10:30:05 2016 From: report at bugs.python.org (Daniel Griffin) Date: Sat, 18 Jun 2016 14:30:05 +0000 Subject: [issue22228] Adapt bash readline operate-and-get-next function In-Reply-To: <1408441328.29.0.0681426449148.issue22228@psf.upfronthosting.co.za> Message-ID: <1466260188.51.0.015172141741.issue22228@psf.upfronthosting.co.za> Daniel Griffin added the comment: Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License. ---------- components: +Tests nosy: +Daniel Griffin, Daniel Griffin Added file: http://bugs.python.org/file43453/bugreport-2016-05-18-03-28-01.txt Added file: http://bugs.python.org/file43454/bugreport-2016-05-18-03-28-01.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 10:30:05 2016 From: report at bugs.python.org (Daniel Griffin) Date: Sat, 18 Jun 2016 14:30:05 +0000 Subject: [issue22228] Adapt bash readline operate-and-get-next function In-Reply-To: <1408441328.29.0.0681426449148.issue22228@psf.upfronthosting.co.za> Message-ID: <1466260205.95.0.522663243917.issue22228@psf.upfronthosting.co.za> Daniel Griffin added the comment: Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License. ---------- components: +Tests nosy: +Daniel Griffin, Daniel Griffin Added file: http://bugs.python.org/file43453/bugreport-2016-05-18-03-28-01.txt Added file: http://bugs.python.org/file43454/bugreport-2016-05-18-03-28-01.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 10:30:17 2016 From: report at bugs.python.org (Daniel Griffin) Date: Sat, 18 Jun 2016 14:30:17 +0000 Subject: [issue22228] Adapt bash readline operate-and-get-next function In-Reply-To: <1408441328.29.0.0681426449148.issue22228@psf.upfronthosting.co.za> Message-ID: <1466260217.32.0.62383599432.issue22228@psf.upfronthosting.co.za> Daniel Griffin added the comment: example ---------- components: +Tests nosy: +Daniel Griffin, Daniel Griffin, Daniel Griffin Added file: http://bugs.python.org/file43455/bugreport-2016-05-18-03-28-01.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 10:38:49 2016 From: report at bugs.python.org (Lele Gaifax) Date: Sat, 18 Jun 2016 14:38:49 +0000 Subject: [issue22228] Adapt bash readline operate-and-get-next function In-Reply-To: <1466260217.32.0.62383599432.issue22228@psf.upfronthosting.co.za> Message-ID: <87r3buwoi3.fsf@metapensiero.it> Lele Gaifax added the comment: Daniel, are these misplaced comments, or should your quite big attachments tell me something I'm missing? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 10:42:37 2016 From: report at bugs.python.org (Daniel Griffin) Date: Sat, 18 Jun 2016 14:42:37 +0000 Subject: [issue27347] Private Message-ID: <1466260936.45.0.785321947044.issue27347@psf.upfronthosting.co.za> New submission from Daniel Griffin: Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License. ---------- components: Installation, Interpreter Core, Tests files: bugreport-2016-05-29-03-43-39.txt messages: 268813 nosy: Daniel Griffin priority: normal severity: normal status: open title: Private versions: Python 3.6 Added file: http://bugs.python.org/file43458/bugreport-2016-05-29-03-43-39.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 10:44:15 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 18 Jun 2016 14:44:15 +0000 Subject: [issue22228] Adapt bash readline operate-and-get-next function In-Reply-To: <1408441328.29.0.0681426449148.issue22228@psf.upfronthosting.co.za> Message-ID: <1466261055.02.0.0955609401705.issue22228@psf.upfronthosting.co.za> Changes by Berker Peksag : Removed file: http://bugs.python.org/file43455/bugreport-2016-05-18-03-28-01.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 10:44:22 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 18 Jun 2016 14:44:22 +0000 Subject: [issue22228] Adapt bash readline operate-and-get-next function In-Reply-To: <1408441328.29.0.0681426449148.issue22228@psf.upfronthosting.co.za> Message-ID: <1466261062.87.0.708483648135.issue22228@psf.upfronthosting.co.za> Changes by Berker Peksag : Removed file: http://bugs.python.org/file43454/bugreport-2016-05-18-03-28-01.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 10:44:28 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 18 Jun 2016 14:44:28 +0000 Subject: [issue22228] Adapt bash readline operate-and-get-next function In-Reply-To: <1408441328.29.0.0681426449148.issue22228@psf.upfronthosting.co.za> Message-ID: <1466261068.73.0.605514647335.issue22228@psf.upfronthosting.co.za> Changes by Berker Peksag : Removed file: http://bugs.python.org/file43453/bugreport-2016-05-18-03-28-01.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 10:45:27 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 18 Jun 2016 14:45:27 +0000 Subject: [issue22228] Adapt bash readline operate-and-get-next function In-Reply-To: <1408441328.29.0.0681426449148.issue22228@psf.upfronthosting.co.za> Message-ID: <1466261127.38.0.547328970689.issue22228@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- components: -Tests nosy: -Daniel Griffin, Daniel Griffin, Daniel Griffin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 10:45:46 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 18 Jun 2016 14:45:46 +0000 Subject: [issue22228] Adapt bash readline operate-and-get-next function In-Reply-To: <1408441328.29.0.0681426449148.issue22228@psf.upfronthosting.co.za> Message-ID: <1466261146.12.0.272216736033.issue22228@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- Removed message: http://bugs.python.org/msg268808 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 10:45:52 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 18 Jun 2016 14:45:52 +0000 Subject: [issue22228] Adapt bash readline operate-and-get-next function In-Reply-To: <1408441328.29.0.0681426449148.issue22228@psf.upfronthosting.co.za> Message-ID: <1466261152.52.0.12714714991.issue22228@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- Removed message: http://bugs.python.org/msg268809 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 10:45:58 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 18 Jun 2016 14:45:58 +0000 Subject: [issue22228] Adapt bash readline operate-and-get-next function In-Reply-To: <1408441328.29.0.0681426449148.issue22228@psf.upfronthosting.co.za> Message-ID: <1466261158.66.0.944344253473.issue22228@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- Removed message: http://bugs.python.org/msg268811 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 10:46:06 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 18 Jun 2016 14:46:06 +0000 Subject: [issue22228] Adapt bash readline operate-and-get-next function In-Reply-To: <1408441328.29.0.0681426449148.issue22228@psf.upfronthosting.co.za> Message-ID: <1466261166.38.0.872951923106.issue22228@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- Removed message: http://bugs.python.org/msg268812 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 10:46:29 2016 From: report at bugs.python.org (SilentGhost) Date: Sat, 18 Jun 2016 14:46:29 +0000 Subject: [issue27347] Private In-Reply-To: <1466260936.45.0.785321947044.issue27347@psf.upfronthosting.co.za> Message-ID: <1466261189.76.0.722949628178.issue27347@psf.upfronthosting.co.za> Changes by SilentGhost : Removed file: http://bugs.python.org/file43458/bugreport-2016-05-29-03-43-39.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 10:46:37 2016 From: report at bugs.python.org (SilentGhost) Date: Sat, 18 Jun 2016 14:46:37 +0000 Subject: [issue27347] Private Message-ID: <1466261197.9.0.138510524412.issue27347@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- Removed message: http://bugs.python.org/msg268813 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 10:46:59 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 18 Jun 2016 14:46:59 +0000 Subject: [issue27347] Spam Message-ID: <1466261219.77.0.644277277619.issue27347@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: -Daniel Griffin resolution: -> not a bug stage: -> resolved status: open -> closed title: Private -> Spam _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 10:57:36 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 18 Jun 2016 14:57:36 +0000 Subject: [issue27348] Non-main thread exception handler drops exception message Message-ID: <1466261856.58.0.470780414166.issue27348@psf.upfronthosting.co.za> New submission from Martin Panter: If the exception argument is None or repr(None), it is omitted from the report when a thread raises an unhandled exception: >>> def raise_exception(e): ... raise e ... >>> t = Thread(target=raise_exception, args=(Exception(None),)); t.start(); t.join() Exception in thread Thread-1: Traceback (most recent call last): File "/home/proj/python/cpython/Lib/threading.py", line 916, in _bootstrap_inner self.run() File "/home/proj/python/cpython/Lib/threading.py", line 864, in run self._target(*self._args, **self._kwargs) File "", line 2, in raise_exception Exception >>> t = Thread(target=raise_exception, args=(Exception("None"),)); t.start(); t.join() Exception in thread Thread-2: Traceback (most recent call last): File "/home/proj/python/cpython/Lib/threading.py", line 916, in _bootstrap_inner self.run() File "/home/proj/python/cpython/Lib/threading.py", line 864, in run self._target(*self._args, **self._kwargs) File "", line 2, in raise_exception Exception Compare the result with other exception messages, the normal sys.excepthook() report, and Python 2: >>> t = Thread(target=raise_exception, args=(Exception("NONE"),)); t.start(); t.join() Exception in thread Thread-3: Traceback (most recent call last): File "/home/proj/python/cpython/Lib/threading.py", line 916, in _bootstrap_inner self.run() File "/home/proj/python/cpython/Lib/threading.py", line 864, in run self._target(*self._args, **self._kwargs) File "", line 2, in raise_exception Exception: NONE >>> raise Exception(None) Traceback (most recent call last): File "", line 1, in Exception: None ---------- messages: 268814 nosy: martin.panter priority: normal severity: normal status: open title: Non-main thread exception handler drops exception message versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 11:21:46 2016 From: report at bugs.python.org (Robert Haschke) Date: Sat, 18 Jun 2016 15:21:46 +0000 Subject: [issue24424] xml.dom.minidom: performance issue with Node.insertBefore() In-Reply-To: <1433942956.66.0.599460998017.issue24424@psf.upfronthosting.co.za> Message-ID: <1466263306.05.0.103158284876.issue24424@psf.upfronthosting.co.za> Robert Haschke added the comment: Thank you very much for further improving the code. As I understand it, the trick is to use temporary variables to minimize access time. Learned something new. I adapted your patch to python 2.7 again. Now, in python3, the new code is even faster than the old one (sometimes) for front insertions: 36 time for 10000 insertions at front: 0.117563 opt36 time for 10000 insertions at front: 0.116014 36 time for 10000 insertions at front: 0.114282 opt36 time for 10000 insertions at front: 0.116710 old time for 5000 insertions at front: 0.044055 new time for 5000 insertions at front: 0.075433 opt27 time for 5000 insertions at front: 0.052135 old time for 5000 insertions at back: 15.241450 new time for 5000 insertions at back: 0.071004 opt27 time for 5000 insertions at back: 0.046850 I hope you can consider, the patch for python 2.7. There the performance gain is most significant. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 11:45:48 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 18 Jun 2016 15:45:48 +0000 Subject: [issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more In-Reply-To: <1464270042.87.0.0233765451432.issue27130@psf.upfronthosting.co.za> Message-ID: <1466264748.98.0.0400910326983.issue27130@psf.upfronthosting.co.za> Changes by Xiang Zhang : Removed file: http://bugs.python.org/file43450/64bit_support_for_zlib_v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 11:46:03 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 18 Jun 2016 15:46:03 +0000 Subject: [issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more In-Reply-To: <1464270042.87.0.0233765451432.issue27130@psf.upfronthosting.co.za> Message-ID: <1466264763.06.0.00315640664806.issue27130@psf.upfronthosting.co.za> Changes by Xiang Zhang : Added file: http://bugs.python.org/file43459/64bit_support_for_zlib_v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 13:17:47 2016 From: report at bugs.python.org (Steve Dower) Date: Sat, 18 Jun 2016 17:17:47 +0000 Subject: [issue26536] Add the SIO_LOOPBACK_FAST_PATH option to socket.ioctl In-Reply-To: <1457666128.63.0.278319184112.issue26536@psf.upfronthosting.co.za> Message-ID: <1466270267.24.0.685323794655.issue26536@psf.upfronthosting.co.za> Steve Dower added the comment: That's the best function to use. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 13:57:53 2016 From: report at bugs.python.org (Doug Hellmann) Date: Sat, 18 Jun 2016 17:57:53 +0000 Subject: [issue24955] webbrowser broken on Mac OS X when using the BROWSER variable In-Reply-To: <1440842500.82.0.168118984503.issue24955@psf.upfronthosting.co.za> Message-ID: <1466272673.17.0.663074258451.issue24955@psf.upfronthosting.co.za> Changes by Doug Hellmann : ---------- nosy: +doughellmann _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 13:58:37 2016 From: report at bugs.python.org (Doug Hellmann) Date: Sat, 18 Jun 2016 17:58:37 +0000 Subject: [issue24452] Make webbrowser support Chrome on Mac OS X In-Reply-To: <1434317605.99.0.218705045555.issue24452@psf.upfronthosting.co.za> Message-ID: <1466272717.64.0.475793021811.issue24452@psf.upfronthosting.co.za> Changes by Doug Hellmann : ---------- nosy: +doughellmann _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 14:21:32 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 18 Jun 2016 18:21:32 +0000 Subject: [issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more In-Reply-To: <1464270042.87.0.0233765451432.issue27130@psf.upfronthosting.co.za> Message-ID: <1466274092.16.0.60736823847.issue27130@psf.upfronthosting.co.za> Xiang Zhang added the comment: Attach patch to restore argument parsing support for __int__. ---------- Added file: http://bugs.python.org/file43460/64bit_support_for_zlib_v5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 14:23:12 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Jun 2016 18:23:12 +0000 Subject: [issue27021] It is not documented that os.writev() suffer from SC_IOV_MAX In-Reply-To: <1463247246.11.0.121733863987.issue27021@psf.upfronthosting.co.za> Message-ID: <20160618182309.11596.79824.05150187@psf.io> Roundup Robot added the comment: New changeset eddbf14f451b by Senthil Kumaran in branch '3.5': issue27021 - Document SC_IOV_MAX limitation imposed by OS on os.writev. https://hg.python.org/cpython/rev/eddbf14f451b New changeset 0b1cd695e7aa by Senthil Kumaran in branch 'default': [merge from 3.5] - issue27021 - Document SC_IOV_MAX limitation imposed by OS on os.writev. https://hg.python.org/cpython/rev/0b1cd695e7aa ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 14:23:59 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Sat, 18 Jun 2016 18:23:59 +0000 Subject: [issue27021] It is not documented that os.writev() suffer from SC_IOV_MAX In-Reply-To: <1463247246.11.0.121733863987.issue27021@psf.upfronthosting.co.za> Message-ID: <1466274239.92.0.828071878921.issue27021@psf.upfronthosting.co.za> Senthil Kumaran added the comment: ????, it's documented now. Thank you for the patch. ---------- nosy: +orsenthil resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 14:24:38 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 18 Jun 2016 18:24:38 +0000 Subject: [issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more In-Reply-To: <1464270042.87.0.0233765451432.issue27130@psf.upfronthosting.co.za> Message-ID: <1466274278.81.0.205532241634.issue27130@psf.upfronthosting.co.za> Changes by Xiang Zhang : Removed file: http://bugs.python.org/file43460/64bit_support_for_zlib_v5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 14:25:01 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 18 Jun 2016 18:25:01 +0000 Subject: [issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more In-Reply-To: <1464270042.87.0.0233765451432.issue27130@psf.upfronthosting.co.za> Message-ID: <1466274301.37.0.464061115597.issue27130@psf.upfronthosting.co.za> Changes by Xiang Zhang : Added file: http://bugs.python.org/file43461/64bit_support_for_zlib_v5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 14:26:42 2016 From: report at bugs.python.org (Jakub Wilk) Date: Sat, 18 Jun 2016 18:26:42 +0000 Subject: [issue27349] distutils.command.upload: typo "protcol_version" Message-ID: <1466274402.68.0.283801716839.issue27349@psf.upfronthosting.co.za> New submission from Jakub Wilk: distutils/command/upload.py reads: data = { # action ':action': 'file_upload', 'protcol_version': '1', ... } It should be of course 'protocol_version'. I checked the PyPI code, and it's spelled correctly there. This misspelling was found using mwic: http://jwilk.net/software/mwic ---------- components: Distutils messages: 268820 nosy: dstufft, eric.araujo, jwilk priority: normal severity: normal status: open title: distutils.command.upload: typo "protcol_version" _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 14:42:34 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Jun 2016 18:42:34 +0000 Subject: [issue27349] distutils.command.upload: typo "protcol_version" In-Reply-To: <1466274402.68.0.283801716839.issue27349@psf.upfronthosting.co.za> Message-ID: <20160618184231.119669.29353.8ED39CD1@psf.io> Roundup Robot added the comment: New changeset 81a9ce02b49b by Berker Peksag in branch '3.5': Issue #27349: Fix typo in distutils upload command https://hg.python.org/cpython/rev/81a9ce02b49b New changeset a4d00ae53e35 by Berker Peksag in branch 'default': Issue #27349: Merge from 3.5 https://hg.python.org/cpython/rev/a4d00ae53e35 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 14:42:55 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 18 Jun 2016 18:42:55 +0000 Subject: [issue27349] distutils.command.upload: typo "protcol_version" In-Reply-To: <1466274402.68.0.283801716839.issue27349@psf.upfronthosting.co.za> Message-ID: <1466275375.68.0.361769852449.issue27349@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks! ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed type: -> behavior versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 14:55:47 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Jun 2016 18:55:47 +0000 Subject: [issue27294] Better repr for Tkinter event objects In-Reply-To: <1465648557.25.0.737232700025.issue27294@psf.upfronthosting.co.za> Message-ID: <20160618185544.11531.70838.6E4BA250@psf.io> Roundup Robot added the comment: New changeset e0ec4abe659f by Serhiy Storchaka in branch 'default': Issue #27294: Numerical state in the repr for Tkinter event objects is now https://hg.python.org/cpython/rev/e0ec4abe659f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 15:01:02 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jun 2016 19:01:02 +0000 Subject: [issue27079] Bugs in curses.ascii predicates In-Reply-To: <1463861399.98.0.689088484472.issue27079@psf.upfronthosting.co.za> Message-ID: <1466276462.09.0.0920760008348.issue27079@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 15:10:02 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Jun 2016 19:10:02 +0000 Subject: [issue27294] Better repr for Tkinter event objects In-Reply-To: <1465648557.25.0.737232700025.issue27294@psf.upfronthosting.co.za> Message-ID: <20160618190959.5058.3648.5AF39098@psf.io> Roundup Robot added the comment: New changeset d7b6c07bc713 by Serhiy Storchaka in branch '3.5': Issue #27294: Numerical state in the repr for Tkinter event objects is now https://hg.python.org/cpython/rev/d7b6c07bc713 New changeset ac8338546ca8 by Serhiy Storchaka in branch '2.7': Issue #27294: Numerical state in the repr for Tkinter event objects is now https://hg.python.org/cpython/rev/ac8338546ca8 New changeset d03c8d0a6a73 by Serhiy Storchaka in branch 'default': Issue #27294: Numerical state in the repr for Tkinter event objects is now https://hg.python.org/cpython/rev/d03c8d0a6a73 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 15:14:55 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jun 2016 19:14:55 +0000 Subject: [issue27079] Bugs in curses.ascii predicates In-Reply-To: <1463861399.98.0.689088484472.issue27079@psf.upfronthosting.co.za> Message-ID: <1466277295.94.0.452299985355.issue27079@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Committed with wrong commit message (damn two clipboards on X11) in ac8338546ca8, d7b6c07bc713, d03c8d0a6a73. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 15:16:26 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jun 2016 19:16:26 +0000 Subject: [issue27294] Better repr for Tkinter event objects In-Reply-To: <1465648557.25.0.737232700025.issue27294@psf.upfronthosting.co.za> Message-ID: <1466277386.17.0.726860156504.issue27294@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The last three commits actually are related to issue27079. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 15:30:11 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 18 Jun 2016 19:30:11 +0000 Subject: [issue27299] urllib does not splitport while putrequest realhost to HTTP headers In-Reply-To: <1465704649.89.0.0364976733052.issue27299@psf.upfronthosting.co.za> Message-ID: <1466278211.28.0.788639972025.issue27299@psf.upfronthosting.co.za> R. David Murray added the comment: httplib (which is what you are actually calling in your example) does not interpret headers set with putheader. It is the application's responsibility to get the header contents correct. As Xiang said, this looks like a server side issue. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 15:42:01 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 18 Jun 2016 19:42:01 +0000 Subject: [issue10839] email module should not allow some header field repetitions In-Reply-To: <1294263603.86.0.308955870327.issue10839@psf.upfronthosting.co.za> Message-ID: <1466278921.79.0.734783980288.issue10839@psf.upfronthosting.co.za> R. David Murray added the comment: In the new API there's no real reason to use the old MIME classes. If you want to add the keyword I have no objection, though. I started a documentation revision last year but haven't had time to get back to it. Hopefully I'll dust it off Real Soon Now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 15:59:23 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Jun 2016 19:59:23 +0000 Subject: [issue23968] rename the platform directory from plat-$(MACHDEP) to plat-$(PLATFORM_TRIPLET) In-Reply-To: <1429124647.47.0.946423694262.issue23968@psf.upfronthosting.co.za> Message-ID: <20160618195919.20420.27960.EBD6E748@psf.io> Roundup Robot added the comment: New changeset e2b09c00ee24 by Ned Deily in branch 'default': Issue #23968: Fix installs of the renamed config directory for OS X https://hg.python.org/cpython/rev/e2b09c00ee24 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 15:59:45 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jun 2016 19:59:45 +0000 Subject: [issue26579] Support pickling slots in subclasses of common classes In-Reply-To: <1458204186.54.0.651323931278.issue26579@psf.upfronthosting.co.za> Message-ID: <1466279985.81.0.993495343437.issue26579@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Synchronized with current sources. ---------- Added file: http://bugs.python.org/file43462/copyreg_getstate2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 16:00:28 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 18 Jun 2016 20:00:28 +0000 Subject: [issue27302] csv.Sniffer guesses wrong when unquoted fields contain quotes In-Reply-To: <1465748432.82.0.331643864863.issue27302@psf.upfronthosting.co.za> Message-ID: <1466280028.0.0.999459584837.issue27302@psf.upfronthosting.co.za> R. David Murray added the comment: Sniff is a heuristic. If you can suggest a way to improve the heuristic, great. A particular failed guess isn't really a bug, though. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 16:09:22 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jun 2016 20:09:22 +0000 Subject: [issue27294] Better repr for Tkinter event objects In-Reply-To: <1465648557.25.0.737232700025.issue27294@psf.upfronthosting.co.za> Message-ID: <1466280562.46.0.270206330545.issue27294@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: That's with this issue. I think we will return to Event repr after implementing named flags and providing standard mechanism for parsing and creating keystrokes (there are elements of this in IDLE). ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 16:47:38 2016 From: report at bugs.python.org (Ned Deily) Date: Sat, 18 Jun 2016 20:47:38 +0000 Subject: [issue23968] rename the platform directory from plat-$(MACHDEP) to plat-$(PLATFORM_TRIPLET) In-Reply-To: <1429124647.47.0.946423694262.issue23968@psf.upfronthosting.co.za> Message-ID: <1466282857.99.0.222728773674.issue23968@psf.upfronthosting.co.za> Ned Deily added the comment: There is a problem with the current implementation. When running ./configure using compilers other than a current gcc, for example, when using clang or older versions of gcc, the build variable MULTIARCH may not get set because those compilers do not support --print-multiarch: configure.ac:744 MULTIARCH=$($CC --print-multiarch 2>/dev/null) But, a bit later in ./configure, PLATFORM_TRIPLET gets set as a result of running conftest.c. The end result is that PLATFORM_TRIPET is non-empty but MULTIARCH is empty. Still later in configure.ac (around 4477: if test x$PLATFORM_TRIPLET = x; then LIBPL='$(prefix)'"/lib/python${VERSION}/config-${LDVERSION}" else LIBPL='$(prefix)'"/lib/python${VERSION}/config-${LDVERSION}-${PLATFORM_TRIPLET}" fi So, the value of LIBPL is extended to include PLATFORM_TRIPLET regardless of whether MULTIARCH has a value. This causes problems at runtime because get_makefile_filename() in Lib/sysconfig.py now uses the value of sys.implemntation's _multiarch attribute (whose value is compiled in sysmodule.c from MULTIARCH) to form the path to the config directory (the equivalent of LIBPL). In these cases, sys.implementation will have no_multiarch attribute so sysconfig looks for the config directory in the pre-3.6 location (e.g. .../lib/python3.6/config-3.6m) even though it was installed in the new location (.../lib/python3.6/config-3.6m-darwin). Fortunately, both test_sysconfig and test_distutils catch this: ====================================================================== FAIL: test_srcdir (test.test_sysconfig.TestSysConfig) ---------------------------------------------------------------------- Traceback (most recent call last): File "/py/dev/3x/root/uxd/lib/python3.6/test/test_sysconfig.py", line 346, in test_srcdir self.assertTrue(os.path.isdir(srcdir), srcdir) AssertionError: False is not true : /py/dev/3x/root/uxd/lib/python3.6/config-3.6dm ====================================================================== FAIL: test_get_makefile_filename (test.test_sysconfig.MakefileTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/py/dev/3x/root/uxd/lib/python3.6/test/test_sysconfig.py", line 414, in test_get_makefile_filename self.assertTrue(os.path.isfile(makefile), makefile) AssertionError: False is not true : /py/dev/3x/root/uxd/lib/python3.6/config-3.6dm/Makefile ====================================================================== FAIL: test_srcdir (distutils.tests.test_sysconfig.SysconfigTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/py/dev/3x/root/uxd/lib/python3.6/distutils/tests/test_sysconfig.py", line 61, in test_srcdir self.assertTrue(os.path.isdir(srcdir), srcdir) AssertionError: False is not true : /py/dev/3x/root/uxd/lib/python3.6/config-3.6dm ---------------------------------------------------------------------- I'm not sure what the best solution is. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 16:50:56 2016 From: report at bugs.python.org (Ned Deily) Date: Sat, 18 Jun 2016 20:50:56 +0000 Subject: [issue23968] rename the platform directory from plat-$(MACHDEP) to plat-$(PLATFORM_TRIPLET) In-Reply-To: <1429124647.47.0.946423694262.issue23968@psf.upfronthosting.co.za> Message-ID: <1466283056.59.0.441187516266.issue23968@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- priority: normal -> critical stage: -> needs patch versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 18:37:07 2016 From: report at bugs.python.org (Oleg Babintsev) Date: Sat, 18 Jun 2016 22:37:07 +0000 Subject: [issue25717] tempfile.TemporaryFile fails when dir option set to directory residing on host OS mount In-Reply-To: <1448339024.55.0.65158482353.issue25717@psf.upfronthosting.co.za> Message-ID: <1466289427.84.0.576710266085.issue25717@psf.upfronthosting.co.za> Oleg Babintsev added the comment: Thanks for explanation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 22:19:35 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 19 Jun 2016 02:19:35 +0000 Subject: [issue27319] Multiple item arguments for selection operations In-Reply-To: <1465926060.08.0.266570766159.issue27319@psf.upfronthosting.co.za> Message-ID: <1466302775.84.0.439761987491.issue27319@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Then don't. Better to do nothing until sure than to deprecate and then undeprecate. Thinking about it, I am not sure either. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 23:08:14 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 19 Jun 2016 03:08:14 +0000 Subject: [issue27312] test_setupapp (idlelib.idle_test.test_macosx.SetupTest) fails on OS X In-Reply-To: <1465865390.09.0.618470621806.issue27312@psf.upfronthosting.co.za> Message-ID: <1466305694.66.0.181298264925.issue27312@psf.upfronthosting.co.za> Ned Deily added the comment: test_idle now runs without failing. Thanks, Terry and Berker. ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 23:43:16 2016 From: report at bugs.python.org (INADA Naoki) Date: Sun, 19 Jun 2016 03:43:16 +0000 Subject: [issue27350] Compact and ordered dict Message-ID: <1466307796.29.0.980579044792.issue27350@psf.upfronthosting.co.za> New submission from INADA Naoki: I've implemented compact ordered dictionary, introduced in PyPy blog [1]. To finish my work, I really need core developer's help. Please see TODO comment in the patch. [1]: https://morepypy.blogspot.jp/2015/01/faster-more-memory-efficient-and-more.html See also: https://mail.python.org/pipermail/python-dev/2016-June/145299.html https://github.com/methane/cpython/pull/1 (same to attached patch) ---------- components: Interpreter Core files: compact-dict.patch keywords: patch messages: 268837 nosy: naoki priority: normal severity: normal status: open title: Compact and ordered dict versions: Python 3.6 Added file: http://bugs.python.org/file43463/compact-dict.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 18 23:43:45 2016 From: report at bugs.python.org (INADA Naoki) Date: Sun, 19 Jun 2016 03:43:45 +0000 Subject: [issue27350] Compact and ordered dict In-Reply-To: <1466307796.29.0.980579044792.issue27350@psf.upfronthosting.co.za> Message-ID: <1466307825.67.0.88353498388.issue27350@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- type: -> resource usage _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 00:50:27 2016 From: report at bugs.python.org (Rich Rauenzahn) Date: Sun, 19 Jun 2016 04:50:27 +0000 Subject: [issue27351] Unexpected ConfigParser.read() behavior when passed fileobject Message-ID: <1466311827.21.0.0107030173129.issue27351@psf.upfronthosting.co.za> New submission from Rich Rauenzahn: This came up on StackOverflow: http://stackoverflow.com/a/37903779/2077386 I wanted to bring it to your attention in case it hasn't been notice before. It turns out that if you pass a fileobject (i.e., ConfigParser().read(open("foo"))) ConfigParser.read() will look at the argument, see it isn't a basestring, and then will iterate over it. fileobjects are iterables. This results in iterating over the contents of the file 'foo'. It then attempts to open a file named after every line read from 'foo'. For example, I made a file foo and filled it with a-g, each letter per line. strace shows: open("foo", O_RDONLY) = 3 open("a\n", O_RDONLY) = -1 ENOENT (No such file or directory) open("b\n", O_RDONLY) = -1 ENOENT (No such file or directory) open("c\n", O_RDONLY) = -1 ENOENT (No such file or directory) open("d\n", O_RDONLY) = -1 ENOENT (No such file or directory) open("e\n", O_RDONLY) = -1 ENOENT (No such file or directory) open("f\n", O_RDONLY) = -1 ENOENT (No such file or directory) open("g\n", O_RDONLY) = -1 ENOENT (No such file or directory) ...and since the API is designed to ignore files it can't open, it just ignores the open errors. I wonder if this fileobject case ought to be checked for when checking the arguments passed into ConfigParser.read(). Thank you. ---------- components: Library (Lib) messages: 268838 nosy: Rich.Rauenzahn priority: normal severity: normal status: open title: Unexpected ConfigParser.read() behavior when passed fileobject type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 01:05:57 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 19 Jun 2016 05:05:57 +0000 Subject: [issue27351] Unexpected ConfigParser.read() behavior when passed fileobject In-Reply-To: <1466311827.21.0.0107030173129.issue27351@psf.upfronthosting.co.za> Message-ID: <1466312757.62.0.381172976405.issue27351@psf.upfronthosting.co.za> Xiang Zhang added the comment: The doc tells ConfigParser.read accepts a filename or a list of filenames. Why do you pass it fileobject? If you want to use fileobject, why not read_file? ---------- nosy: +lukasz.langa, xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 01:16:01 2016 From: report at bugs.python.org (Rich Rauenzahn) Date: Sun, 19 Jun 2016 05:16:01 +0000 Subject: [issue27351] Unexpected ConfigParser.read() behavior when passed fileobject In-Reply-To: <1466311827.21.0.0107030173129.issue27351@psf.upfronthosting.co.za> Message-ID: <1466313361.37.0.519043910977.issue27351@psf.upfronthosting.co.za> Rich Rauenzahn added the comment: Given that write() accepts a fileobject, but read() accepts a list of strings or a string (and readfp() is the one that accepts a fileobject instead), this seems like it could be a common enough error that just iterating over the fileobject could be undesirable and an exception might be thrown instead. I'm throwing this out here to see if the library maintainers were aware of this odd edge case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 01:31:25 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 19 Jun 2016 05:31:25 +0000 Subject: [issue19756] test_nntplib: sporadic failures, network isses? server down? In-Reply-To: <1385316451.32.0.948186129781.issue19756@psf.upfronthosting.co.za> Message-ID: <1466314285.54.0.224281395608.issue19756@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch that changes all affected tests to use a custom server running on localhost: * Local server is based on the existing NNTPv2Handler class, and the LocalServerTests class * Reintegrate test_starttls() back into NetworkedNNTPTestsMixin * Only test_with_statement() talks to the remote NNTP_HOST now (not affected by this bug) * Make tests in NetworkedNNTPTestsMixin stricter, because the server responses are predetermined now * Add mock comp.lang.python support to NNTPv1Handler.handle_GROUP() * Add support for rejecting passwords in NNTPv1Handler.handle_AUTHINFO() * New message number with non-UTF-8 message body for ARTICLE, HEAD, BODY, and non-UTF-8 subject for OVER, XOVER ---------- keywords: +patch Added file: http://bugs.python.org/file43464/nntp-server.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 01:41:04 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Jun 2016 05:41:04 +0000 Subject: [issue27350] Compact and ordered dict In-Reply-To: <1466307796.29.0.980579044792.issue27350@psf.upfronthosting.co.za> Message-ID: <1466314864.43.0.456931315392.issue27350@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > How to support sizeof(Py_ssize_t) == 4? #if SIZEOF_VOID_P == 4 > Can I use int8_t, int16_t and int32_t You can use PY_INT32_T for 32-bit signed integers, short for 16-bit signed integers (if SIZEOF_SHORT == 2) and signed char for 8-bit signed integers. Or introduce PY_INT16_T and PY_INT8_T similarly as it was done for PY_INT32_T. ---------- nosy: +rhettinger, serhiy.storchaka stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 02:26:07 2016 From: report at bugs.python.org (INADA Naoki) Date: Sun, 19 Jun 2016 06:26:07 +0000 Subject: [issue27350] Compact and ordered dict In-Reply-To: <1466307796.29.0.980579044792.issue27350@psf.upfronthosting.co.za> Message-ID: <1466317567.14.0.934135932054.issue27350@psf.upfronthosting.co.za> INADA Naoki added the comment: >> How to support sizeof(Py_ssize_t) == 4? >#if SIZEOF_VOID_P == 4 Thanks! >> Can I use int8_t, int16_t and int32_t > You can use PY_INT32_T for 32-bit signed integers, short for 16-bit signed integers (if SIZEOF_SHORT == 2) and signed char for 8-bit signed integers. Or introduce PY_INT16_T and PY_INT8_T similarly as it was done for PY_INT32_T. I found PY_INT32_T in pyport.h. It seems only available when stdint.h is available. What is the meaning of using PY_INT32_T instead of int32_t ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 02:41:13 2016 From: report at bugs.python.org (INADA Naoki) Date: Sun, 19 Jun 2016 06:41:13 +0000 Subject: [issue27350] Compact and ordered dict In-Reply-To: <1466307796.29.0.980579044792.issue27350@psf.upfronthosting.co.za> Message-ID: <1466318473.85.0.121664793519.issue27350@psf.upfronthosting.co.za> Changes by INADA Naoki : Added file: http://bugs.python.org/file43465/compact-dict.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 03:01:12 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Jun 2016 07:01:12 +0000 Subject: [issue27350] Compact and ordered dict In-Reply-To: <1466307796.29.0.980579044792.issue27350@psf.upfronthosting.co.za> Message-ID: <1466319672.12.0.438756356358.issue27350@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: When stdint.h is not available you can define PY_INT32_T externally. E.g. CFLAGS="-DPY_INT32_T=__int32". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 03:47:35 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Jun 2016 07:47:35 +0000 Subject: [issue22115] Add new methods to trace Tkinter variables In-Reply-To: <1406818071.8.0.276271200629.issue22115@psf.upfronthosting.co.za> Message-ID: <1466322455.82.0.228471474659.issue22115@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated patch provides simplified interface. The support of passing callback arguments is removed. This complicates an interface and is not needed since Python supports closure and the support of callback arguments was more limited (supported only limited set of types and arguments are converted to str). Added an entry in What's News. ---------- assignee: -> serhiy.storchaka versions: +Python 3.6 -Python 3.5 Added file: http://bugs.python.org/file43466/tkinter_trace_variable_5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 03:51:36 2016 From: report at bugs.python.org (INADA Naoki) Date: Sun, 19 Jun 2016 07:51:36 +0000 Subject: [issue27350] Compact and ordered dict In-Reply-To: <1466307796.29.0.980579044792.issue27350@psf.upfronthosting.co.za> Message-ID: <1466322696.3.0.960002251451.issue27350@psf.upfronthosting.co.za> INADA Naoki added the comment: Make sense! I did it. ---------- Added file: http://bugs.python.org/file43467/compact-dict.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 04:56:07 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Jun 2016 08:56:07 +0000 Subject: [issue22214] Tkinter: Don't stringify callbacks arguments In-Reply-To: <1408285449.26.0.836464630135.issue22214@psf.upfronthosting.co.za> Message-ID: <1466326567.6.0.363452534805.issue22214@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated patch. Added NEWS and What's New entries. ---------- assignee: -> serhiy.storchaka versions: +Python 3.6 -Python 3.5 Added file: http://bugs.python.org/file43468/tkinter_obj_cmd_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 07:06:42 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 19 Jun 2016 11:06:42 +0000 Subject: [issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more In-Reply-To: <1464270042.87.0.0233765451432.issue27130@psf.upfronthosting.co.za> Message-ID: <1466334402.47.0.706898896477.issue27130@psf.upfronthosting.co.za> Xiang Zhang added the comment: Upload the near-final patch. This one adds large buffer tests on 64bit platforms. I have tested them on a server with enough memory. I don't add the @support.requires_resource('cpu') since large memory tests are born to be slow. And actually when I experiment, they are not that slow, at least not obviously slower than other large memory tests in test_zlib. So I ignore it. ---------- Added file: http://bugs.python.org/file43469/64bit_support_for_zlib_v6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 07:53:12 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Jun 2016 11:53:12 +0000 Subject: [issue27352] Bug in IMPORT_NAME Message-ID: <1466337192.83.0.569731150376.issue27352@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Seems there is a bug in the implementation of the IMPORT_NAME opcode in ceval.c. If the level argument is -1, it is not passed to __import__ (should never happen, but looks correct). If it is an integer != -1 in C long range, it is passed to __import__ (this is correct). But if it is not integer (e.g. None) or can't be converted to C long, an exception is set and __import__ is called with level and not cleared error (this is wrong). In correct bytecode the level argument can be either integer or None. Default __import__ accepts only integers as the level argument and checks the range. Proposed patch makes the code always passing the level argument to __import__ unless it is None. ---------- components: Interpreter Core files: import_name_level.patch keywords: patch messages: 268849 nosy: brett.cannon, eric.snow, ncoghlan, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Bug in IMPORT_NAME type: behavior versions: Python 2.7, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43470/import_name_level.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 08:01:09 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Jun 2016 12:01:09 +0000 Subject: [issue22557] Local import is too slow In-Reply-To: <1412512141.77.0.0512115045124.issue22557@psf.upfronthosting.co.za> Message-ID: <1466337669.2.0.193833385692.issue22557@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Fixed bugs making test_importlib failing. Microbenchmark results on faster machine: $ ./python -m timeit 'import locale' Unpatched: 1000000 loops, best of 3: 0.839 usec per loop Patched: 10000000 loops, best of 3: 0.176 usec per loop $ ./python -m timeit 'import os.path' Unpatched: 100000 loops, best of 3: 2.02 usec per loop Patched: 1000000 loops, best of 3: 1.77 usec per loop $ ./python -m timeit 'from locale import getlocale' Unpatched: 100000 loops, best of 3: 3.69 usec per loop Patched: 100000 loops, best of 3: 3.39 usec per loop And it looks to me that there is a bug in existing code (opened separate issue27352). 0.839 usec is not very slow by CPython's standards, but is equal to about 50 assignments to local variable, 15 attribute revolvings or 5 simple function calls. If some module is optionally needed in fast function, the overhead of local import can be significant. We can lazily initialize global variable (the second example in msg228561), but this code looks more cumbersome. ---------- stage: -> patch review versions: +Python 3.6 -Python 3.5 Added file: http://bugs.python.org/file43471/faster_import_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 08:03:08 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Jun 2016 12:03:08 +0000 Subject: [issue17711] Persistent id in pickle with protocol version 0 In-Reply-To: <1365853309.55.0.468755952624.issue17711@psf.upfronthosting.co.za> Message-ID: <1466337788.0.0.0215448677896.issue17711@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 09:55:11 2016 From: report at bugs.python.org (INADA Naoki) Date: Sun, 19 Jun 2016 13:55:11 +0000 Subject: [issue27350] Compact and ordered dict In-Reply-To: <1466307796.29.0.980579044792.issue27350@psf.upfronthosting.co.za> Message-ID: <1466344511.04.0.908943817136.issue27350@psf.upfronthosting.co.za> Changes by INADA Naoki : Added file: http://bugs.python.org/file43472/compact-dict.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 11:32:30 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 19 Jun 2016 15:32:30 +0000 Subject: [issue23641] Got rid of bad dunder names In-Reply-To: <1426084934.72.0.0668161558437.issue23641@psf.upfronthosting.co.za> Message-ID: <20160619153226.20032.26719.C0664E9B@psf.io> Roundup Robot added the comment: New changeset 75cec736f87d by Serhiy Storchaka in branch '3.5': Issue #23641: Added __getnewargs_ex__ to the list of special mock attributes. https://hg.python.org/cpython/rev/75cec736f87d New changeset 4c5f7b61b6c5 by Serhiy Storchaka in branch 'default': Issue #23641: Added __getnewargs_ex__ to the list of special mock attributes. https://hg.python.org/cpython/rev/4c5f7b61b6c5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 11:34:19 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Jun 2016 15:34:19 +0000 Subject: [issue23641] Got rid of bad dunder names In-Reply-To: <1426084934.72.0.0668161558437.issue23641@psf.upfronthosting.co.za> Message-ID: <1466350459.45.0.741142909121.issue23641@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'm not sure about removing __getslice__ and __setslice__ from multiprocessing.sharedctypes and __div__ from unittest.mock, and left them as is. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 12:06:28 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Jun 2016 16:06:28 +0000 Subject: [issue23148] Missing the charset parameter in as_encoded_word() In-Reply-To: <1420195099.17.0.393236049779.issue23148@psf.upfronthosting.co.za> Message-ID: <1466352388.15.0.0150682460299.issue23148@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The only tests that call cte_encode() are test_address_list_with_unicode_names and test_address_list_with_unicode_names_in_quotes. The only method that calls cte_encode() (besides recursive cte_encode) is TokenList._fold(). Methods UnstructuredTokenList.cte_encode() and Phrase._fold() are not covered by tests. ---------- versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 12:15:04 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Jun 2016 16:15:04 +0000 Subject: [issue20256] Argument Clinic: compare signed and unsigned ints In-Reply-To: <1389688549.54.0.106907827652.issue20256@psf.upfronthosting.co.za> Message-ID: <1466352903.99.0.48380612404.issue20256@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Was fixed in duplicate issue22120. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Return converter code generated by Argument Clinic has a warning for unsigned types _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 12:48:13 2016 From: report at bugs.python.org (Johannes S.) Date: Sun, 19 Jun 2016 16:48:13 +0000 Subject: [issue26971] python v3.5.1: sys.paths not respecting DESTDIRS and DESTSHARED In-Reply-To: <1462628482.0.0.926875224828.issue26971@psf.upfronthosting.co.za> Message-ID: <1466354893.33.0.638639322255.issue26971@psf.upfronthosting.co.za> Johannes S. added the comment: Maybe my last comment was not clear enogth. I used the tarballs from 3.5 and 3.6 which are linked in my last comment. I extracted them and run the the following commands on Arch (64 Bit) and Linux SuSE 13.1 (64 Bit): mkdir build cd build ../configure --prefix=/some/dir make make install The path `/some/dir` is a placeholder. The path did not exist before running this commands. After running them on Linux SuSE, I discovered that `libpython3.5m.a`, `pkgconfig/` and `python3.5/lib-dynload` was placed in `/some/dir/lib64` instead of `/some/dir/lib`. On Arch, everything is placed in `/some/dir/lib` but I have the same behavior if I add `--libdir=/some/dir/lib64` to `configure`. With other words: `--libdir` seems to have a default value of "EPREFIX/lib64" instead of "EPREFIX/lib" on my instance of Linux SuSE. Maybe `configure` uses some global configurations here? The problem is, that `sys.path` does point to `/some/dir/lib/lib-dynload` in all cases described above. Since `python3.5/lib-dynload` may be placed in `lib64`, this may cause that python does not run properly after installing it. (Unfortunately, I cannot say much about the configuration of "my instance of Linux SuSE" since I am not the person who set it up. It is a server of my university.) ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 13:09:19 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Jun 2016 17:09:19 +0000 Subject: [issue23782] Leak in _PyTraceback_Add In-Reply-To: <1427365502.47.0.105321888995.issue23782@psf.upfronthosting.co.za> Message-ID: <1466356159.49.0.52034589488.issue23782@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Proposed patch fixes a leak. ---------- components: +Interpreter Core keywords: +patch stage: -> patch review versions: +Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43473/_PyTraceback_Add_leak.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 13:11:24 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 19 Jun 2016 17:11:24 +0000 Subject: [issue27025] More human readable generated widget names In-Reply-To: <1463299445.94.0.887025569149.issue27025@psf.upfronthosting.co.za> Message-ID: <1466356284.24.0.856890934051.issue27025@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The change is a super great idea (see below), but I now think (my suggestion of) '`' is a bad idea because it conflicts with the use of '`' as markup for code and output, as in rst and stackoverflow. https://stackoverflow.com/questions/37904750/tkinter-tclerror-invalid-command-name-54600176-error-what-is-going-on basically asks What does '''_tkinter.TclError: invalid command name ".54600176"''' mean? In my comment to the answer, I noted that 3.6.0a2 now says '''invalid command name ".`label"'''. I wanted to write `invalid command name ".`label"` to quote it properly, SO style, but this would not work. So I suggest we invoke your last comment and instead try '^' (or even '~' or '-' if you prefer). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 13:36:46 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 19 Jun 2016 17:36:46 +0000 Subject: [issue27025] More human readable generated widget names In-Reply-To: <1463299445.94.0.887025569149.issue27025@psf.upfronthosting.co.za> Message-ID: <1466357806.21.0.0249406255526.issue27025@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Worse yet, SO replaces a single ` with a space, so that ".`label" is displayed as ". label" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 13:38:15 2016 From: report at bugs.python.org (Demur Rumed) Date: Sun, 19 Jun 2016 17:38:15 +0000 Subject: [issue27213] Rework CALL_FUNCTION* opcodes In-Reply-To: <1465026334.02.0.369802561902.issue27213@psf.upfronthosting.co.za> Message-ID: <1466357895.74.0.187195733298.issue27213@psf.upfronthosting.co.za> Demur Rumed added the comment: Attaching first iteration. Very drafty. Still need to fix test_dis; will run test suite this evening. Perf on pybench went from 16.5s to 17.5s. It was 18.3s prior to reintroducing use of fast_function. Code still needs clean up besides investigation into how to optimize Changes not described in the original patch concept: I made CALL_FUNCTION_EX oparg carry 2 flag bits on whether there's a kwdict or a vararg tuple. Code may be simpler to only have kwdict be optional. BUILD_MAP_UNPACK_WITH_CALL was modified to only use the highest bit of the 2nd byte to track where function_pos is. Most uses of BUILD_MAP_UNPACK_WITH_CALL is f(*va,**kw) so I chose to only set the highest bit when there isn't a positional unpacking. If we pushed an empty tuple then that flag bit could be removed ---------- keywords: +patch Added file: http://bugs.python.org/file43474/callfunc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 13:43:09 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 19 Jun 2016 17:43:09 +0000 Subject: [issue27196] Eliminate 'ThemeChanged' warning when running IDLE tests In-Reply-To: <1464940807.02.0.170350027457.issue27196@psf.upfronthosting.co.za> Message-ID: <1466358189.96.0.672958066742.issue27196@psf.upfronthosting.co.za> Ned Deily added the comment: FWIW, I'm still seeing these errors on OS X (10.11.5 with ActiveTcl 8.5.18) using 2.7.12rc1, 3.5.2rc1, and top-of-trunk 3.6.0. They do not occur on the same platform when using 2.7.11 or 3.5.1. For example: $ /usr/local/bin/python2.7 Python 2.7.12rc1 (v2.7.12rc1:13912cd1e7e8, Jun 11 2016, 15:32:34) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin [...] $ /usr/local/bin/python2.7 -m test.regrtest -ugui -j3 test_idle can't invoke "event" command: application has been destroyed while executing "event generate $w <>" (procedure "ttk::ThemeChanged" line 6) invoked from within "ttk::ThemeChanged" can't invoke "event" command: application has been destroyed while executing "event generate $w <>" (procedure "ttk::ThemeChanged" line 6) invoked from within "ttk::ThemeChanged" [1/1] test_idle 1 test OK. $ /usr/local/bin/python3.5 Python 3.5.2rc1 (v3.5.2rc1:68feec6488b2, Jun 11 2016, 21:59:53) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin [...] $ /usr/local/bin/python3.5 -m test.regrtest -ugui test_idle [1/1] test_idle can't invoke "event" command: application has been destroyed while executing "event generate $w <>" (procedure "ttk::ThemeChanged" line 6) invoked from within "ttk::ThemeChanged" 1 test OK. $ ./bin/python3.6 Python 3.6.0a2+ (default, Jun 19 2016, 13:19:06) [GCC 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.29)] on darwin [...] $ ./bin/python3.6 -m test -ugui -j3 test_idle Run tests in parallel using 3 child processes 0:00:02 [1/1] test_idle passed can't invoke "event" command: application has been destroyed while executing "event generate $w <>" (procedure "ttk::ThemeChanged" line 6) invoked from within "ttk::ThemeChanged" 1 test OK. Total duration: 0:00:03 ---------- nosy: +ned.deily resolution: fixed -> stage: resolved -> needs patch status: closed -> open versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 14:42:49 2016 From: report at bugs.python.org (Mark Shannon) Date: Sun, 19 Jun 2016 18:42:49 +0000 Subject: [issue27213] Rework CALL_FUNCTION* opcodes In-Reply-To: <1465026334.02.0.369802561902.issue27213@psf.upfronthosting.co.za> Message-ID: <1466361769.58.0.815030541765.issue27213@psf.upfronthosting.co.za> Mark Shannon added the comment: I seemed to have been added to the nosy list. I guess that means that my opinions are wanted ;) I have wanted to clean up the code around making calls for quite a while. I just haven't had time. I agree that adding a simpler opcode for making calls with positional only args is worthwhile. However creating the tuple and/or dict at every call site is going to lead to slow downs. It gets even worse for bound-methods, as yet another tuple will need to be created to accommodate self. What I would suggest is a new internal calling convention which embodies the six-part form of CALL_FUNCTION_VAR_KW, that is (number-of-postionals, pointer-to-positionals, number-of-keywords, pointer-to-keywords, starargs-tuple, doublestarargs-dict). As a first step, each of the four current CALL_FUNCTION variants could then call this function, filling in the relevant parameters. The new function would look something like this: PyEval_Call_Callable( PyObject *callable, int npos, PyObject **positionals, int nkws, PyObject **keywords, PyObject *starargs, PyObject *dictargs) { if (Is_PyFunction(callable)) return PyFunction_Call(callable, npos, ...); if (Is_CFunction(callable)) return CFunction_Call(callable, npos, ...); // Otherwise general object... // We might want PyType_Call as well, since object creation is // another common form of call. // Create tuple and dict from args. return PyObject_Call(callable, tuple, dict); } This would mean that the logic for frame creation would be where it belongs (in the code for the Function object) and that special casing the various forms of CFunctions could be moved to where that belongs. Given what Serhiy says about calls with just positional parameters being by far the most common, it sounds as if it would make sense to add PyFunction_CallSimple(PyObject *callable, int npos, PyObject**args) and CFuntion_CallSimple(PyObject *callable, int npos, PyObject**args) variants for the new CALL_FUNCTION opcode to use. With those changes, it would then make sense to replace the four opcodes CALL_FUNCTION, CALL_FUNCTION_VAR, CALL_FUNCTION_KW, CALL_FUNCTION_VAR_KW with CALL_FUNCTION -- As Serhiy suggests CALL_FUNCTION_KW -- As Serhiy suggests CALL_FUNCTION_VAR_KW -- As currently exists ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 15:01:05 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 19 Jun 2016 19:01:05 +0000 Subject: [issue27297] Add support for /dev/random to "secrets" In-Reply-To: <1465670075.28.0.237473871841.issue27297@psf.upfronthosting.co.za> Message-ID: <1466362865.32.0.812030132915.issue27297@psf.upfronthosting.co.za> Nick Coghlan added the comment: Please don't use /dev/random for anything, ever. It can block applications unpredictably for no good reason. ---------- nosy: +ncoghlan resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 15:11:21 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 19 Jun 2016 19:11:21 +0000 Subject: [issue27244] print(';;') fails in pdb with SyntaxError In-Reply-To: <1465245825.04.0.474122067055.issue27244@psf.upfronthosting.co.za> Message-ID: <1466363481.76.0.866931626565.issue27244@psf.upfronthosting.co.za> Ned Deily added the comment: As Wim notes, that behavior is documented. So, until someone wants to provide an enhancement patch, we should close this issue. Sorry! ---------- nosy: +ned.deily resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 15:48:27 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 19 Jun 2016 19:48:27 +0000 Subject: [issue25602] Add support for EVFILT_USER kqueue filter In-Reply-To: <1447242368.46.0.687277732517.issue25602@psf.upfronthosting.co.za> Message-ID: <1466365707.7.0.992973017615.issue25602@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for contributing the patch, Jakub. I'm sorry that there's been no action on it; unfortunately, the BSD platforms don't get as much attention here as some others. I took a cursory look at it and the patch looks pretty good to me and applies/builds cleanly on OS X (even though support for EVFILT_USER is known to not be documented there). I think it would be good to add a test case to Lib/test/test_kqueue.py. Any other opinions? ---------- nosy: +ned.deily, neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 16:10:21 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Jun 2016 20:10:21 +0000 Subject: [issue16334] Faster unicode-escape and raw-unicode-escape codecs In-Reply-To: <1351291705.86.0.638624862326.issue16334@psf.upfronthosting.co.za> Message-ID: <1466367021.04.0.582283428842.issue16334@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Victor's patch harvested most fruits, but there is a place for further optimization. Benchmark results for new patch: Py3.2 Py3.3 Py3.6 Py3.6+patch 451 (-47%) 77 (+209%) 140 (+70%) 238 decode unicode-escape 'A'*10000 269 (-14%) 161 (+44%) 187 (+24%) 232 decode unicode-escape '\x80'*10000 453 (-48%) 85 (+178%) 181 (+30%) 236 decode unicode-escape '\x80'+'A'*9999 295 (-4%) 185 (+54%) 229 (+24%) 284 decode unicode-escape '\u0100'*10000 452 (-47%) 75 (+221%) 213 (+13%) 241 decode unicode-escape '\u0100'+'A'*9999 275 (-11%) 149 (+64%) 187 (+30%) 244 decode unicode-escape '\u0100'+'\x80'*9999 297 (-4%) 185 (+54%) 230 (+23%) 284 decode unicode-escape '\u8000'*10000 452 (-47%) 75 (+221%) 213 (+13%) 241 decode unicode-escape '\u8000'+'A'*9999 275 (-11%) 149 (+64%) 187 (+30%) 244 decode unicode-escape '\u8000'+'\x80'*9999 295 (-3%) 185 (+54%) 230 (+24%) 285 decode unicode-escape '\u8000'+'\u0100'*9999 318 (-29%) 203 (+11%) 220 (+2%) 225 decode unicode-escape '\U00010000'*10000 452 (-51%) 72 (+207%) 163 (+36%) 221 decode unicode-escape '\U00010000'+'A'*9999 275 (-31%) 128 (+49%) 160 (+19%) 191 decode unicode-escape '\U00010000'+'\x80'*9999 295 (-36%) 164 (+16%) 201 (-5%) 190 decode unicode-escape '\U00010000'+'\u0100'*9999 297 (-36%) 166 (+14%) 199 (-5%) 190 decode unicode-escape '\U00010000'+'\u8000'*9999 559 (-62%) 88 (+143%) 194 (+10%) 214 decode raw-unicode-escape 'A'*10000 555 (-62%) 88 (+142%) 195 (+9%) 213 decode raw-unicode-escape '\x80'*10000 559 (-62%) 88 (+142%) 195 (+9%) 213 decode raw-unicode-escape '\x80'+'A'*9999 265 (+29%) 133 (+156%) 212 (+61%) 341 decode raw-unicode-escape '\u0100'*10000 563 (-54%) 77 (+235%) 195 (+32%) 258 decode raw-unicode-escape '\u0100'+'A'*9999 559 (-54%) 77 (+234%) 194 (+32%) 257 decode raw-unicode-escape '\u0100'+'\x80'*9999 269 (+27%) 138 (+147%) 208 (+64%) 341 decode raw-unicode-escape '\u8000'*10000 562 (-54%) 77 (+235%) 193 (+34%) 258 decode raw-unicode-escape '\u8000'+'A'*9999 559 (-54%) 77 (+234%) 194 (+32%) 257 decode raw-unicode-escape '\u8000'+'\x80'*9999 265 (+29%) 138 (+147%) 208 (+64%) 341 decode raw-unicode-escape '\u8000'+'\u0100'*9999 281 (-13%) 152 (+61%) 228 (+7%) 244 decode raw-unicode-escape '\U00010000'*10000 562 (-65%) 74 (+164%) 200 (-2%) 195 decode raw-unicode-escape '\U00010000'+'A'*9999 557 (-65%) 74 (+162%) 200 (-3%) 194 decode raw-unicode-escape '\U00010000'+'\x80'*9999 265 (-2%) 122 (+114%) 184 (+42%) 261 decode raw-unicode-escape '\U00010000'+'\u0100'*9999 269 (-3%) 122 (+113%) 185 (+41%) 260 decode raw-unicode-escape '\U00010000'+'\u8000'*9999 195 (+136%) 109 (+323%) 258 (+79%) 461 encode unicode-escape 'A'*10000 673 (-23%) 522 (-1%) 254 (+103%) 516 encode unicode-escape '\x80'*10000 197 (+134%) 132 (+248%) 247 (+86%) 460 encode unicode-escape '\x80'+'A'*9999 869 (-22%) 627 (+9%) 333 (+105%) 682 encode unicode-escape '\u0100'*10000 197 (-19%) 124 (+28%) 158 (+1%) 159 encode unicode-escape '\u0100'+'A'*9999 669 (-35%) 493 (-12%) 236 (+83%) 432 encode unicode-escape '\u0100'+'\x80'*9999 866 (-20%) 628 (+10%) 333 (+108%) 692 encode unicode-escape '\u8000'*10000 197 (-19%) 125 (+27%) 158 (+1%) 159 encode unicode-escape '\u8000'+'A'*9999 669 (-35%) 492 (-12%) 236 (+83%) 433 encode unicode-escape '\u8000'+'\x80'*9999 869 (-20%) 627 (+11%) 324 (+114%) 694 encode unicode-escape '\u8000'+'\u0100'*9999 870 (-1%) 897 (-4%) 501 (+72%) 861 encode unicode-escape '\U00010000'*10000 197 (+20%) 139 (+70%) 234 (+1%) 236 encode unicode-escape '\U00010000'+'A'*9999 668 (-27%) 533 (-9%) 249 (+96%) 487 encode unicode-escape '\U00010000'+'\x80'*9999 869 (-12%) 646 (+18%) 344 (+122%) 764 encode unicode-escape '\U00010000'+'\u0100'*9999 864 (-12%) 643 (+19%) 344 (+122%) 762 encode unicode-escape '\U00010000'+'\u8000'*9999 391 (+1310%) 333 (+1556%) 575 (+859%) 5514 encode raw-unicode-escape 'A'*10000 391 (+1229%) 334 (+1456%) 576 (+802%) 5198 encode raw-unicode-escape '\x80'*10000 391 (+1402%) 335 (+1653%) 579 (+914%) 5873 encode raw-unicode-escape '\x80'+'A'*9999 869 (-25%) 687 (-5%) 356 (+83%) 652 encode raw-unicode-escape '\u0100'*10000 391 (+46%) 158 (+260%) 214 (+166%) 569 encode raw-unicode-escape '\u0100'+'A'*9999 391 (+46%) 158 (+260%) 214 (+166%) 569 encode raw-unicode-escape '\u0100'+'\x80'*9999 873 (-25%) 682 (-4%) 356 (+83%) 652 encode raw-unicode-escape '\u8000'*10000 391 (+46%) 158 (+260%) 214 (+166%) 569 encode raw-unicode-escape '\u8000'+'A'*9999 391 (+46%) 157 (+262%) 214 (+166%) 569 encode raw-unicode-escape '\u8000'+'\x80'*9999 869 (-25%) 688 (-5%) 345 (+90%) 656 encode raw-unicode-escape '\u8000'+'\u0100'*9999 917 (+4%) 859 (+11%) 532 (+79%) 952 encode raw-unicode-escape '\U00010000'*10000 392 (-15%) 182 (+84%) 260 (+28%) 334 encode raw-unicode-escape '\U00010000'+'A'*9999 392 (-15%) 182 (+83%) 260 (+28%) 333 encode raw-unicode-escape '\U00010000'+'\x80'*9999 870 (-15%) 672 (+10%) 355 (+108%) 738 encode raw-unicode-escape '\U00010000'+'\u0100'*9999 871 (-16%) 672 (+9%) 355 (+106%) 730 encode raw-unicode-escape '\U00010000'+'\u8000'*9999 ---------- versions: +Python 3.6 -Python 3.4 Added file: http://bugs.python.org/file43475/faster_unicode_escape_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 16:21:19 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 19 Jun 2016 20:21:19 +0000 Subject: [issue27287] SIGSEGV when calling os.forkpty() In-Reply-To: <1465561630.72.0.359750002725.issue27287@psf.upfronthosting.co.za> Message-ID: <1466367679.94.0.375152837954.issue27287@psf.upfronthosting.co.za> Ned Deily added the comment: >From a quick search of the issue tracker, I didn't find any previous reports of this. We do have a couple of gentoo buildbots but probably not gentoo-hardened. So I don't think this issue is going to go anywhere here and I'm going to close it. If anyone does find evidence of a problem in Python, please reopen. Good luck! ---------- nosy: +ned.deily resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 16:26:36 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 19 Jun 2016 20:26:36 +0000 Subject: [issue22214] Tkinter: Don't stringify callback arguments In-Reply-To: <1408285449.26.0.836464630135.issue22214@psf.upfronthosting.co.za> Message-ID: <1466367996.95.0.516468204447.issue22214@psf.upfronthosting.co.za> Terry J. Reedy added the comment: There is no review button for the new patch (don't know why), so: in the News and What's New entries, change "if call" to "if one calls" and "or set" to "or sets". More importantly, question your use of 'callback' in the entries. To me, a callback is a function that is passed to a recipient to be called *by the recipient* at some later time. For tkinter, there are command callbacks, which get no arguments, validatecommand callbacks, which get string arguments, event callbacks, which get a tkinter event object as argument, and after callbacks, which get as arguments the Python objects given to the after call. In all cases, there is no visible issue of passing non-strings as strings to the callback. The following duplicates the testfunc and interp.call in test_tcl.py as closely as I know how, but with a different result. import tkinter as tk root = tk.Tk() def test(*args): for arg in args: print(type(arg), '', repr(arg)) root.after(1, test, True, 1, '1') root.mainloop() To me, the revised test does not involve a callback. The test registers a name for the python function so it can be passes by name to Tk().call, as required by the .call signature. So I would replace 'callback' with 'Python function registered with tk'. Registered functions can, of course, be used as callback if they have the proper signature. ConfigDialog registers an 'is_int' function so it can be passed to an Entry as a validatecommand callback. The patch does not affect registered validate commands because they receive string args. After grepping idlelib for "register(", I believe this is the only function IDLE registers with tk (two of its classes have non-tk .register methods). Hence, IDLE should not be affected by the patch and seems not as far as I tested. I can't properly review the _tkinter patch as it requires too much knowledge of tcl/tk interfaces. ---------- title: Tkinter: Don't stringify callbacks arguments -> Tkinter: Don't stringify callback arguments _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 17:06:03 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 19 Jun 2016 21:06:03 +0000 Subject: [issue27319] Multiple item arguments for selection operations In-Reply-To: <1465926060.08.0.266570766159.issue27319@psf.upfronthosting.co.za> Message-ID: <20160619210558.19960.33470.32E7DE62@psf.io> Roundup Robot added the comment: New changeset 7b9ad68db14e by Serhiy Storchaka in branch 'default': Issue #27319: Methods selection_set(), selection_add(), selection_remove() https://hg.python.org/cpython/rev/7b9ad68db14e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 17:07:37 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Jun 2016 21:07:37 +0000 Subject: [issue27319] Multiple item arguments for selection operations In-Reply-To: <1465926060.08.0.266570766159.issue27319@psf.upfronthosting.co.za> Message-ID: <1466370457.65.0.906951855767.issue27319@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your review Terry. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 17:31:23 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Jun 2016 21:31:23 +0000 Subject: [issue22214] Tkinter: Don't stringify callback arguments In-Reply-To: <1408285449.26.0.836464630135.issue22214@psf.upfronthosting.co.za> Message-ID: <1466371883.95.0.581289138006.issue22214@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Terry for your review. Here is updated patch fith fixed wording as you suggested. Hope it will be available to review on Rietveld. The original purpose of this patch was to help fixing some IDLE "crashes". Percolator is registered in text widgets for highlighting pasted text. If you paste invalid string containing a lone surrogate on Windows (clipboard uses UTF-8), it first converted by Tcl to char*, and then Tkinter should convert it to Python string for passing to registered Python function, but fails. Since the information is lost during conversion in Tcl, we can't use say "surrogatepass" error handler fo representing non-well-formed data. With this patch we can decode just from Tcl unicode string. ---------- Added file: http://bugs.python.org/file43476/tkinter_obj_cmd_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 17:42:38 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Jun 2016 21:42:38 +0000 Subject: [issue20350] Replace tkapp.split() to tkapp.splitlist() In-Reply-To: <1390411522.89.0.349086871577.issue20350@psf.upfronthosting.co.za> Message-ID: <1466372558.49.0.799814340629.issue20350@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Most methods are tested now. There is a difference between split() and splitlist() in Variable.trace_vinfo() if the tracer was assigned not by Tkinter method Variable.trace_variable(), but by direct execution of Tcl command "trace add variable" and additional arguments were included in commandPrefix. This is very unusual case, and I think that the result would be more expectable if use splitlist() in Variable.trace_vinfo(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 17:45:33 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Jun 2016 21:45:33 +0000 Subject: [issue24137] Force not using _default_root in IDLE In-Reply-To: <1430925977.27.0.721479362057.issue24137@psf.upfronthosting.co.za> Message-ID: <1466372733.17.0.191951665074.issue24137@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What your thoughts about this Terry? ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 18:06:08 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Jun 2016 22:06:08 +0000 Subject: [issue21708] Deprecate nonstandard behavior of a dumbdbm database In-Reply-To: <1402425082.25.0.679069092867.issue21708@psf.upfronthosting.co.za> Message-ID: <1466373968.44.0.0762788714029.issue21708@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Patch updated. Added What's New entry. We already lost 2 years and the 3.5 release. I don't want to lost 3.6 too. ---------- assignee: -> serhiy.storchaka components: +Library (Lib) versions: +Python 3.6 -Python 3.5 Added file: http://bugs.python.org/file43477/dbm_dumb_deprecations2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 18:08:13 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Jun 2016 22:08:13 +0000 Subject: [issue27213] Rework CALL_FUNCTION* opcodes In-Reply-To: <1465026334.02.0.369802561902.issue27213@psf.upfronthosting.co.za> Message-ID: <1466374093.74.0.188649540843.issue27213@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 18:34:37 2016 From: report at bugs.python.org (dg1727) Date: Sun, 19 Jun 2016 22:34:37 +0000 Subject: [issue14191] argparse doesn't allow optionals within positionals In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za> Message-ID: <1466375677.04.0.849174066283.issue14191@psf.upfronthosting.co.za> Changes by dg1727 : ---------- nosy: +dg1727 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 18:43:37 2016 From: report at bugs.python.org (Pam McA'Nulty) Date: Sun, 19 Jun 2016 22:43:37 +0000 Subject: [issue27198] Adding an assertClose() method to unittest.TestCase In-Reply-To: <1464979712.74.0.398203716413.issue27198@psf.upfronthosting.co.za> Message-ID: <1466376217.87.0.968102925031.issue27198@psf.upfronthosting.co.za> Changes by Pam McA'Nulty : ---------- nosy: +Pam.McANulty _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 18:43:56 2016 From: report at bugs.python.org (Pam McA'Nulty) Date: Sun, 19 Jun 2016 22:43:56 +0000 Subject: [issue27152] Additional assert methods for unittest In-Reply-To: <1464535519.92.0.0853489345335.issue27152@psf.upfronthosting.co.za> Message-ID: <1466376236.03.0.516510042703.issue27152@psf.upfronthosting.co.za> Changes by Pam McA'Nulty : ---------- nosy: +Pam.McANulty _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 20:13:00 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 20 Jun 2016 00:13:00 +0000 Subject: [issue19756] test_nntplib: sporadic failures, network isses? server down? In-Reply-To: <1385316451.32.0.948186129781.issue19756@psf.upfronthosting.co.za> Message-ID: <1466381580.4.0.790677840872.issue19756@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 20:22:40 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Mon, 20 Jun 2016 00:22:40 +0000 Subject: [issue27353] Add nroot function to math Message-ID: <1466382160.58.0.562689353089.issue27353@psf.upfronthosting.co.za> New submission from Steven D'Aprano: For Issue27181 (add geometric mean to statistics module), I need a function to calculate nth roots that is more accurate than pow(x, 1/n). E.g. math.pow(1000, 1/3) returns 9.999999999999998 instead of 10.0. I have a pure-Python implementation of nroot which I believe is satisfactory, and I could use that, but I'm uncomfortable about making it a public function in statistics. It's not really a statistics function, its more general, and I think it would be generally useful enough that it should go into math. To recap the options: - leave nroot in statistics as a private function; - leave it in statistics, but make it public; - add it to math I'm willing to do the first if there is no other alternative, reluctant to do the second, and think that the third is the most useful, but I don't have the ability to write a pure C version. If the math library was written in Python that would be the obvious place for it. ---------- components: Library (Lib) messages: 268875 nosy: steven.daprano priority: normal severity: normal status: open title: Add nroot function to math type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 20:58:29 2016 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 20 Jun 2016 00:58:29 +0000 Subject: [issue27122] Hang with contextlib.ExitStack and subprocess.Popen (regression) In-Reply-To: <1464176880.25.0.308106356091.issue27122@psf.upfronthosting.co.za> Message-ID: <1466384309.39.0.720737663967.issue27122@psf.upfronthosting.co.za> Nick Coghlan added the comment: Serhiy's test changes look good to me! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 21:29:56 2016 From: report at bugs.python.org (Pam McA'Nulty) Date: Mon, 20 Jun 2016 01:29:56 +0000 Subject: [issue26859] unittest fails with "Start directory is not importable" when trying to run sourceless tests In-Reply-To: <1461678137.48.0.743276761028.issue26859@psf.upfronthosting.co.za> Message-ID: <1466386196.28.0.746997988272.issue26859@psf.upfronthosting.co.za> Changes by Pam McA'Nulty : ---------- nosy: +Pam.McANulty _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 21:33:47 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 20 Jun 2016 01:33:47 +0000 Subject: [issue27152] Additional assert methods for unittest In-Reply-To: <1464535519.92.0.0853489345335.issue27152@psf.upfronthosting.co.za> Message-ID: <1466386427.24.0.445454713456.issue27152@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Ask five people to spell "assertEndsWith" and see how many of them capitalize the "W". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 22:29:01 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 20 Jun 2016 02:29:01 +0000 Subject: [issue27198] Adding an assertClose() method to unittest.TestCase In-Reply-To: <1464979712.74.0.398203716413.issue27198@psf.upfronthosting.co.za> Message-ID: <1466389741.58.0.0867726235944.issue27198@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > Embrace the API and add useful asserts like this one. This kind of philosophy is going to lead to egregious API expansion, making Python harder to learn and remember. You're suggesting that we have a nearly zero resistance to adding new assert variants. Please keep in mind that once something is added to the standard library, it is very painful to remove it later. As far as I can tell, there has been zero usability testing of this method with actual users and there have been no user requests for it ever. I don't see any analog for it in the unittest modules for other languages. I don't like the method name at all and think we will regret this method if later an assertIsClosed() method is added for making sure objects have had a close() method called. If recall correctly, Kent Beck himself opposed this kind of expansion of unittest modules, "Some of the implementations have gotten a little complicated for my taste." He believed that the tool itself should be minimal so that it could be easily learned and mastered while letting "tests be expressed in ordinary source code". > it is clearly DESIGNED to have specialized asserts for > many common use cases. Actually, is wasn't at all. When unittest was added, there were no specialized asserts (see https://docs.python.org/2.1/lib/testcase-objects.html ). It was a translation of the successful and well respected JUnit module. Its design goal was to provide user extendability rather than throwing in everything including the kitchen sink. Python's unittest module was around for a very long time before the zoo of specialized asserts was added (courtesy of code donated by Google). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 22:30:58 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 Jun 2016 02:30:58 +0000 Subject: [issue27122] Hang with contextlib.ExitStack and subprocess.Popen (regression) In-Reply-To: <1464176880.25.0.308106356091.issue27122@psf.upfronthosting.co.za> Message-ID: <20160620023055.78488.63280.1A6265F0@psf.io> Roundup Robot added the comment: New changeset a14b93a4eb49 by Serhiy Storchaka in branch '3.5': Added more tests for issue #27122. https://hg.python.org/cpython/rev/a14b93a4eb49 New changeset ebc82b840163 by Serhiy Storchaka in branch 'default': Added more tests for issue #27122. https://hg.python.org/cpython/rev/ebc82b840163 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 22:31:31 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Jun 2016 02:31:31 +0000 Subject: [issue27122] Hang with contextlib.ExitStack and subprocess.Popen (regression) In-Reply-To: <1464176880.25.0.308106356091.issue27122@psf.upfronthosting.co.za> Message-ID: <1466389891.36.0.724318649959.issue27122@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 22:32:09 2016 From: report at bugs.python.org (Ilya Kulakov) Date: Mon, 20 Jun 2016 02:32:09 +0000 Subject: [issue27354] SSLContext.load_verify_locations cannot handle paths on Windows which cannot be encoded using mbcs Message-ID: <1466389929.18.0.227515818606.issue27354@psf.upfronthosting.co.za> New submission from Ilya Kulakov: On Windows 8.1 x64 with Python 3.5.1 I was able to reproduce the issue by attempting to load a file at "C:\Users\????\AppData\Local\Temp\_????_70e5wbxo\cacert.pem". locale.getdefaultlocale() > ('en_US', 'cp1252') locale.getpreferredencoding() > 'cp1252' sys.getfilesystemencoding() > 'mbcs' sys.getdefaultencoding() > 'utf-8' c = ssl.SSLContext(ssl.PROTOCOL_TLSv1_2) c.load_verify_locations(cafile=r"C:\Users\????\AppData\Local\Temp\_????_70e5wbxo\cacert.pem") > TypeError: cafile should be a valid filesystem path c.load_verify_locations(cafile=r"C:\Users\????\AppData\Local\Temp\_????_70e5wbxo\cacert.pem".encode(sys.getfilesystemencoding())) > UnicodeEncodeError: 'mbcs' codec can't encode characters in positions 0--1: invalid character c.load_verify_locations(cafile=r"C:\Users\????\AppData\Local\Temp\_????_70e5wbxo\cacert.pem".encode('utf-8')) > ok ---------- components: Extension Modules, Unicode, Windows messages: 268880 nosy: Ilya.Kulakov, ezio.melotti, haypo, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: SSLContext.load_verify_locations cannot handle paths on Windows which cannot be encoded using mbcs versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 23:13:53 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 20 Jun 2016 03:13:53 +0000 Subject: [issue27198] Adding an assertClose() method to unittest.TestCase In-Reply-To: <1464979712.74.0.398203716413.issue27198@psf.upfronthosting.co.za> Message-ID: <1466392433.67.0.939509927935.issue27198@psf.upfronthosting.co.za> Berker Peksag added the comment: I agree with Raymond. I doubt most of the unittest users would ever need a builtin assertClose() method in unittest. I suggest closing this as 'rejected'. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 23:15:18 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 20 Jun 2016 03:15:18 +0000 Subject: [issue19756] test_nntplib: sporadic failures, network isses? server down? In-Reply-To: <1385316451.32.0.948186129781.issue19756@psf.upfronthosting.co.za> Message-ID: <1466392518.62.0.0535881815917.issue19756@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a diff that shows my changes better. I temporarily moved some classes back to their original positions to reduce the diff size, though it won?t work in practice because Python needs the classes defined before using them. ---------- Added file: http://bugs.python.org/file43478/original-order.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 23:25:20 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 20 Jun 2016 03:25:20 +0000 Subject: [issue22214] Tkinter: Don't stringify callback arguments In-Reply-To: <1408285449.26.0.836464630135.issue22214@psf.upfronthosting.co.za> Message-ID: <1466393120.57.0.596231927009.issue22214@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Review works. "to Python function" should be either "to a Python function" or "to Python functions". Preventing crashes is a justifying use case. Percolator registers its 'insert' and 'delete' methods with a WidgetRedirector. It then patches them into to text instance, thereby inducing tk to call its replacements without their being registered with tk. Can you add a test case based on this? I tried the following, based on what Redirector does, without and with the patch and got the same result each time. import tkinter as tk root = tk.Tk() text = tk.Text(root) s = '\ud800' text.insert('1.0', s) print(text.get('1.0')) def insert(index, s): Text.insert(text, index, s) text.insert('1.1', s) print(text.get('1.1')) root.clipboard_append(s) text.insert('1.2', text.clipboard_get()) print(text.get('1.2')) ### output ? ? Traceback (most recent call last): File "F:\Python\mypy\tem2.py", line 12, in text.insert('1.2', text.clipboard_get()) File "F:\Python\dev\36\lib\tkinter\__init__.py", line 730, in clipboard_get return self.tk.call(('clipboard', 'get') + self._options(kw)) UnicodeDecodeError: 'utf-8' codec can't decode byte 0xed in position 0: invalid continuation byte Can the above be changed to fail, then succeed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 19 23:52:59 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 20 Jun 2016 03:52:59 +0000 Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX) In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za> Message-ID: <1466394779.91.0.355787202447.issue26439@psf.upfronthosting.co.za> Martin Panter added the comment: Uploading a combined patch that should work with Rietveld, and I will leave some comments. I don?t think there is much that I am comfortable changing in Python 2.7. In general it is a bad idea to add new features that are only going to be available in e.g. 2.7.13+ and won?t work in older versions of 2.7. One rule of thumb is if a change would require additional documentation, then it is probably a new feature. In this case, find_library() is returning something that is not a plain filename or path name, so the documentation also needs changing. If we added a version of find_library() that returned only file or path names (and not archive members!), I might consider that acceptable for 2.7, because it is filling in missing AIX functionality, and sticks to the current documentation. But it sounds like most libraries are archive members, so I can understand if that sort of change is not worth the effort. ---------- Added file: http://bugs.python.org/file43479/Python2.Lib.ctypes.160611.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 01:14:40 2016 From: report at bugs.python.org (INADA Naoki) Date: Mon, 20 Jun 2016 05:14:40 +0000 Subject: [issue27350] Compact and ordered dict In-Reply-To: <1466307796.29.0.980579044792.issue27350@psf.upfronthosting.co.za> Message-ID: <1466399680.12.0.250569760807.issue27350@psf.upfronthosting.co.za> Changes by INADA Naoki : Added file: http://bugs.python.org/file43480/compact-dict.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 02:52:15 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 20 Jun 2016 06:52:15 +0000 Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX) In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za> Message-ID: <1466405535.03.0.248031971499.issue26439@psf.upfronthosting.co.za> Martin Panter added the comment: I left a few more comments, but I see that many of my earlier comments (both in Rietveld and main bug thread) still apply. I?m still struggling to understand all the special cases for the find_library() argument. You seem to have added even more recently (although I think you removed some as well). Can you point to any documentation, command lines, etc demonstrating why Python should support: find_library("libNAME") find_library("search:paths/NAME") find_library("NAME.so*") find_library("/NAME") # Not sure if this case is even relevant Perhaps it would help if you explained what a typical AIX compiler or linker command line looks like. Or if you updated the documentation to explain the cases for AIX. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 03:36:22 2016 From: report at bugs.python.org (Larry Hastings) Date: Mon, 20 Jun 2016 07:36:22 +0000 Subject: [issue27355] Strip out the last lingering vestiges of Windows CE support Message-ID: <1466408180.27.0.0873204690606.issue27355@psf.upfronthosting.co.za> New submission from Larry Hastings: I can't tell if CPython ever really officially supported Windows CE or not. There are some checkins around 2.5 that suggest there was at least partial support. However posixmodule was supposed to be renamed "ce" on Windows CE, and that was never checked in. (There was an external fork called "Python CE" for a while which *did* make this change.) In any case, Windows CE support never survived the transition to Python 3. It has clearly never even been compiled since Python 3.0 shipped. In addition, the external "Python CE" project is dead; their last supported Python version was 2.5, back in 2007. Windows CE appears to still be around as an embedded OS, but I don't think it's a user-visible OS. The days of Windows CE palmtops is long gone. And it's incontrevertably true: Python is no longer supported on Windows CE--if indeed it ever was. So it's time for some late-spring cleaning! The attached patch removes all remaining vestiges of Python's support for Windows CE. A couple of minor questions/notes: * I did a search-and-destroy for "ce", which lead me to _WIN32_WCE and MS_WINCE. * I wasn't sure if I should touch Lib/platform.py. (MAL?) * I'm pretty sure I shouldn't touch config.sub, zlib, or ctypes. Could one of you Windows guys apply the patch and tell me if anything blows up? ---------- assignee: larry components: Interpreter Core, Library (Lib), Tests files: larry.dont.wince.1.patch.txt messages: 268886 nosy: larry, lemburg, steve.dower, tim.golden, zach.ware priority: low severity: normal stage: patch review status: open title: Strip out the last lingering vestiges of Windows CE support type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43481/larry.dont.wince.1.patch.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 04:49:57 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 20 Jun 2016 08:49:57 +0000 Subject: [issue27328] Documentation corrections for email defects In-Reply-To: <1466051780.69.0.693934528135.issue27328@psf.upfronthosting.co.za> Message-ID: <1466412597.15.0.668881117539.issue27328@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a new version which I think should be okay to apply. I restored the references to the base class, but now using the MessageDefect name. I removed the changes relating to raise_on_defect not being strict, in favour of fixing Issue 24364. ---------- dependencies: +Not all defects pass through email policy stage: -> patch review Added file: http://bugs.python.org/file43482/defect-doc.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 05:04:41 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 20 Jun 2016 09:04:41 +0000 Subject: [issue24137] Force not using _default_root in IDLE In-Reply-To: <1430925977.27.0.721479362057.issue24137@psf.upfronthosting.co.za> Message-ID: <1466413481.49.0.0383253772157.issue24137@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Time to do it, at least for tests. I think patch is ready to push, with running without default root disabled until I do more testing. In particular, reread in Rietveld, do suggested actions when run through htest, and try all menu items. ---------- assignee: -> terry.reedy keywords: +patch stage: needs patch -> patch review versions: +Python 3.6 -Python 3.5 Added file: http://bugs.python.org/file43483/nodefaultroot.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 05:59:04 2016 From: report at bugs.python.org (INADA Naoki) Date: Mon, 20 Jun 2016 09:59:04 +0000 Subject: [issue27350] Compact and ordered dict In-Reply-To: <1466307796.29.0.980579044792.issue27350@psf.upfronthosting.co.za> Message-ID: <1466416744.58.0.644909651819.issue27350@psf.upfronthosting.co.za> Changes by INADA Naoki : Added file: http://bugs.python.org/file43484/compact-dict.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 06:11:28 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 Jun 2016 10:11:28 +0000 Subject: [issue27006] C implementation of Decimal.from_float() bypasses __new__ and __init__ In-Reply-To: <1463037344.61.0.425475414297.issue27006@psf.upfronthosting.co.za> Message-ID: <20160620101123.78518.7398.9243CE1A@psf.io> Roundup Robot added the comment: New changeset dd3f48f1df86 by Stefan Krah in branch '3.5': Issue #27006: from_float(): call the subclass' __new__() and __init__(). https://hg.python.org/cpython/rev/dd3f48f1df86 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 06:32:21 2016 From: report at bugs.python.org (Stefan Krah) Date: Mon, 20 Jun 2016 10:32:21 +0000 Subject: [issue27006] C implementation of Decimal.from_float() bypasses __new__ and __init__ In-Reply-To: <1463037344.61.0.425475414297.issue27006@psf.upfronthosting.co.za> Message-ID: <1466418741.93.0.408363403203.issue27006@psf.upfronthosting.co.za> Stefan Krah added the comment: Thank you for the detailed summary! ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 06:59:16 2016 From: report at bugs.python.org (HYBRID BEING) Date: Mon, 20 Jun 2016 10:59:16 +0000 Subject: [issue27309] Visual Styles support to tk/tkinter file and message dialogs In-Reply-To: <1465855196.42.0.576274211307.issue27309@psf.upfronthosting.co.za> Message-ID: <1466420356.49.0.831662216319.issue27309@psf.upfronthosting.co.za> [HYBRID BEING] added the comment: Ok, you sorta lost me. Would patthoyts's solution not work with Tk <8.5? As i understood (which i may did wrong), message box is returned by system (or is it actually Tk, and not system?), and it uses styled/non-styled controls based on calling process manifests, right? Then where does tkinter comes into equation? Moreover, on OS X and Ubuntu message boxes seem to use themed controls (at least simple message boxes do) just fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 07:27:13 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Jun 2016 11:27:13 +0000 Subject: [issue27006] C implementation of Decimal.from_float() bypasses __new__ and __init__ In-Reply-To: <1463037344.61.0.425475414297.issue27006@psf.upfronthosting.co.za> Message-ID: <1466422033.45.0.989276279214.issue27006@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: PyDec_CheckExact(type) always return 0. Should be PyDec_CheckExact(result). And what about other calls of PyDecType_FromFloatExact()? Can they produce broken instance of Decimal subtype? ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 07:27:20 2016 From: report at bugs.python.org (Johannes Ebke) Date: Mon, 20 Jun 2016 11:27:20 +0000 Subject: [issue26923] asyncio.gather drops cancellation In-Reply-To: <1462279806.1.0.880381545595.issue26923@psf.upfronthosting.co.za> Message-ID: <1466422040.03.0.352357258375.issue26923@psf.upfronthosting.co.za> Johannes Ebke added the comment: Right, that's neater. Attached is a patch with your version and a test. I checked that it fails with the old version of cancel() and passes with the new one. Concerning possible other bugs, I've had a look in the standard library, but could not find another instance where Future.cancel() is overwritten and has special handling. I also had a look at the try/except Exception blocks in lib/asyncio, but possible Cancellations are handled correctly there. I believe the main source of bugs in this context will probably be other asyncio-based libraries. Either by inadvertently catching CancellationErrors in a try/except Exception block and treating them like other errors, or by not protecting resources with try/finally across yield points which might throw a CancellationError. Not all libraries use cancel() internally, so the authors might not be aware that they have to write "cancellation-safe" code. ---------- Added file: http://bugs.python.org/file43485/fix_and_test_26923.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 07:48:33 2016 From: report at bugs.python.org (Rolf Krahl) Date: Mon, 20 Jun 2016 11:48:33 +0000 Subject: [issue12319] [http.client] HTTPConnection.request not support "chunked" Transfer-Encoding to send data In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za> Message-ID: <1466423313.28.0.768781122323.issue12319@psf.upfronthosting.co.za> Rolf Krahl added the comment: Martin, thank you for your review! I have to work through the list of comments and get back to you when I'm done. Please note that I didn't got your earlier reviews, so I don't know which comments are new and which are left over from earlier reviews. Of course, I could also have called http.client._get_content_length(). But I believe it would be bad coding style to call an internal helper function from outside of the module. Furthermore, get_content_length() is closely related to HTTPConnection.send(), because it's vital that both methods share the same interpretation of the various body representations. That is why I felt that this should rather be a method of HTTPConnection. But I do not have a strong opinion about this. I would be happy to change it back if you prefer so. Concerning the new encode_chunked=True flag in HTTPConnection.request(), I guess there is no ideal solution. I can see the following alternatives, all of them having advantages and problems: 1. Leave it to http.client. Do not add the Content-Length or Transfer-Encoding header in the Request object in urllib.request. Pro: simple & clean, no extra flag. Con: changes current behavior, possibly breaks existing code. 2. Add Content-Length, but not Transfer-Encoding in urllib.request. Pro: no extra flag. Con: inconsistent, Content-Length and Transfer-Encoding are closely related and serve the same purpose, so it's unlogic to treat them differently in urllib. 3. Care about both headers in urllib.request, adding either Content-Length or Transfer-Encoding. Always do the chunk encoding in http.client, also if the Transfer-Encoding header is already set. Pro: the most consistent solution, no extra flag. Con: changes current behavior, possibly breaks existing code. 4. Care about both headers in urllib.request, add either Content-Length or Transfer-Encoding. Add the extra flag to HTTPConnection.request(). Do the chunk encoding in http.client if either Transfer-Encoding header is not set or if the extra flag is set. Pro: consistent & compatible. Con: extra flag. In this situation, my patch implements option 4, also because I believe, it's most important to keep the high level API clean and consistent. But I would also be happy to switch to option 2. And yes, the encode_chunked flag in HTTPConnection.request() is only relevant if the Transfer-Encoding header is set. If Content-Length is set, chunked encoding is illegal anyway. If neither Content-Length nor Transfer-Encoding is set, http.client must decide on its own to set either the one or the other. If it takes this decision, it must also implement it. In either case, the question whether http.client should do the chunk encoding or not, does not arise. Concerning the variety body types, it is essentially just bytes like, file like, and iterables of bytes like. All three have important use cases, so we need to support them. By text, I guess you mean str? Yes, I agree, disallowing str would make things much cleaner, so I would be happy to drop them. But they are currently explicitly supported in http.client, so I guess, we can't get rid of them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 07:49:07 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 20 Jun 2016 11:49:07 +0000 Subject: [issue24364] Not all defects pass through email policy In-Reply-To: <1433263153.11.0.33312264244.issue24364@psf.upfronthosting.co.za> Message-ID: <1466423347.73.0.993577213393.issue24364@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch to fix the two defects in Lib/email/feedparser.py. I also made some extra changes to the tests: * Remove some tests from Lib/test/test_email/test_email.py, because I think they were redundant with methods of the same name in test_defect_handling.py. * Change a couple of the tests in test_defect_handling.py to verify there are no defects recorded at all even in raise_on_defect=True mode. ---------- keywords: +patch stage: needs patch -> patch review versions: -Python 3.4 Added file: http://bugs.python.org/file43486/defect-fixes.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 08:13:58 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 Jun 2016 12:13:58 +0000 Subject: [issue27006] C implementation of Decimal.from_float() bypasses __new__ and __init__ In-Reply-To: <1463037344.61.0.425475414297.issue27006@psf.upfronthosting.co.za> Message-ID: <20160620121343.2860.48561.41369974@psf.io> Roundup Robot added the comment: New changeset 51a7a97c3ed4 by Stefan Krah in branch '3.5': Issue #27006: Do not use PyDec_CheckExact() on a type. https://hg.python.org/cpython/rev/51a7a97c3ed4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 08:18:46 2016 From: report at bugs.python.org (Pat Thoyts) Date: Mon, 20 Jun 2016 12:18:46 +0000 Subject: [issue27309] Visual Styles support to tk/tkinter file and message dialogs In-Reply-To: <1465855196.42.0.576274211307.issue27309@psf.upfronthosting.co.za> Message-ID: <1466425126.17.0.338103368481.issue27309@psf.upfronthosting.co.za> Pat Thoyts added the comment: As explained in the SO answer, in Tk on Windows the messagebox, file open dialog, save as dialog and in 8.6 up the font dialog are all system standard dialogs. Tk gets Windows to show the common dialog or messagebox and just wraps the Win32 API calls. As a result these dialogs are not themed using ttk as the various elements are not Tk controls at all. The theming control is therefore provided by Windows and is controlled at an application level by the use of an RT_MANIFST resource. This contains various chunk of XML and one of these is used to declare that theming may be applied by the Visual Styles API. The Tk executables include this bit of manifest but the python exe does not. You can test this out using the attached python.exe.manifest file. To allow this to work you have to remove the existing RT_MANIFEST resource from the python executable as an embedded resource overrides a sibling manifest file. I find the easiest way to work with this is to open the exe in Visual Studio and use the resources view to change the resource in place. You can copy the contents of the manifest file over the existing RT_MANIFEST resource or you can remove the embedded resource and let the system pick up the python.exe.manifest file from the same folder as python.exe. This is not dependent on Tk version. All versions of Tk since around 8.0 have delegated to the Win32 MessageBox and GetOpenFileName API calls. With the introduction of Window XP and the Visual Styles API Microsoft added this requirement to declare support for theming via manifests. So if you have the right manifest and theming is enabled on your system then Tk 8.4 and 8.3 will all show themed common dialogs and messageboxes. This does not affect OS X or X Windows. On X Windows Tk provides all these dialogs itself and so they use Tk widgets (or ttk widgets in more recent versions). On OS X I believe the messagebox and common dialogs are all system provided but it will have its own system for controlling that. In short, python needs to merge it this manifest with the manifest being put in place already. The Visual Studio 'mt' tool can do that if you want to merge manifests. ---------- nosy: +Pat Thoyts Added file: http://bugs.python.org/file43487/python.exe.manifest _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 08:22:33 2016 From: report at bugs.python.org (Stefan Krah) Date: Mon, 20 Jun 2016 12:22:33 +0000 Subject: [issue27006] C implementation of Decimal.from_float() bypasses __new__ and __init__ In-Reply-To: <1463037344.61.0.425475414297.issue27006@psf.upfronthosting.co.za> Message-ID: <1466425353.5.0.71577056818.issue27006@psf.upfronthosting.co.za> Stefan Krah added the comment: > PyDec_CheckExact(type) always return 0. Should be PyDec_CheckExact(result). 'result' is always an exact decimal, because your enum example won't work otherwise. > And what about other calls of PyDecType_FromFloatExact()? Can they produce broken instance of Decimal subtype? The PyDecType* functions handle calling the correct allocator, they don't handle calling __new__(). Why should they? The regular non-class-method enum examples worked. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 08:58:32 2016 From: report at bugs.python.org (Stefan Krah) Date: Mon, 20 Jun 2016 12:58:32 +0000 Subject: [issue27006] C implementation of Decimal.from_float() bypasses __new__ and __init__ In-Reply-To: <1463037344.61.0.425475414297.issue27006@psf.upfronthosting.co.za> Message-ID: <1466427512.24.0.0938490485932.issue27006@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 09:10:08 2016 From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=) Date: Mon, 20 Jun 2016 13:10:08 +0000 Subject: [issue13592] repr(regex) doesn't include actual regex In-Reply-To: <1323772944.14.0.269599775604.issue13592@psf.upfronthosting.co.za> Message-ID: <1466428208.4.0.213905758045.issue13592@psf.upfronthosting.co.za> Adam Barto? added the comment: Isn't the trucation of long patterns too rough? Currently, repr(re.compile("a" * 1000)) returns something like "re.compile('aaaaaaaaaaaaa)", i.e. no ending quote and no indication that something was truncated (besides the missing quote). It looked like a bug to me at first sight. ---------- nosy: +Drekin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 09:30:22 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 20 Jun 2016 13:30:22 +0000 Subject: [issue26292] Raw I/O writelines() broken for non-blocking I/O In-Reply-To: <1454661860.28.0.473572264835.issue26292@psf.upfronthosting.co.za> Message-ID: <1466429422.37.0.313751793779.issue26292@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch documenting that RawIOBase.writelines() is undefined for partial writes and blocking errors, as mentioned in (1) above. The alternative of requiring write() to be retried would IMO be unfair to existing writelines() implementations. It also seems out of place considering we don?t even have a RawIOBase.writeexactly() type of method. ---------- keywords: +patch Added file: http://bugs.python.org/file43488/writelines-doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 09:42:12 2016 From: report at bugs.python.org (Carol Willing) Date: Mon, 20 Jun 2016 13:42:12 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1466430132.52.0.193123290866.issue8232@psf.upfronthosting.co.za> Changes by Carol Willing : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 10:29:04 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Jun 2016 14:29:04 +0000 Subject: [issue24137] Force not using _default_root in IDLE In-Reply-To: <1430925977.27.0.721479362057.issue24137@psf.upfronthosting.co.za> Message-ID: <1466432944.45.0.206980392964.issue24137@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I ran IDLE and tests and found yet few needed changes. NoDefaultRoot() should be called only if run IDLE with a subprocess support. ---------- Added file: http://bugs.python.org/file43489/nodefaultroot2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 10:31:49 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Jun 2016 14:31:49 +0000 Subject: [issue24137] Force not using _default_root in IDLE In-Reply-To: <1430925977.27.0.721479362057.issue24137@psf.upfronthosting.co.za> Message-ID: <1466433109.95.0.586442426109.issue24137@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And I thing changes to tests can be applied to all versions (especially since they become diverge), but NoDefaultRoot() should be called in IDLE only in 3.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 10:36:06 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Jun 2016 14:36:06 +0000 Subject: [issue13592] repr(regex) doesn't include actual regex In-Reply-To: <1323772944.14.0.269599775604.issue13592@psf.upfronthosting.co.za> Message-ID: <1466433366.36.0.178633519268.issue13592@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This looks weird, but is not a bug. See issue26090. After implementing that feature truncating a pattern would look more explicit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 11:24:24 2016 From: report at bugs.python.org (Fabian) Date: Mon, 20 Jun 2016 15:24:24 +0000 Subject: [issue27356] csv Message-ID: <1466436264.58.0.694730033551.issue27356@psf.upfronthosting.co.za> New submission from Fabian: Hi, I am running Canopy on Windows 7 64 bit. When I run the attached file, I get the following error: ----> 5 with open('C:\Users\Anwender\Desktop\Test\blub.txt') as csvfile: 6 dialekt = csv.Sniffer().sniff(csvfile.read(1024)) IOError: [Errno 22] invalid mode ('r') or filename: 'C:\\Users\\Anwender\\Desktop\\Test\x08lub.txt' As you see, Python complains about the file name after it changes the file name for no reason. The thing is, when I use a capital letter after every back slash it is fine, but I needed quite some time to figure that out. So it is very annoying for everyone encountering the problem for the first time. Also numbers at the beginning of a file name seem not to work either. Thank you for developing Python! ---------- components: Unicode files: MesspunkteAusKurven.py messages: 268904 nosy: bethard, ezio.melotti, fabian_b, haypo priority: normal severity: normal status: open title: csv Added file: http://bugs.python.org/file43490/MesspunkteAusKurven.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 11:28:06 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 20 Jun 2016 15:28:06 +0000 Subject: [issue27356] csv In-Reply-To: <1466436264.58.0.694730033551.issue27356@psf.upfronthosting.co.za> Message-ID: <1466436486.08.0.959302938063.issue27356@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report. \t is a tab character. You can use 'C:\\Users\\Anwender\\Desktop\\Test\\blub.txt' or r'C:\Users\Anwender\Desktop\Test\blub.txt' or 'C:/Users/Anwender/Desktop/Test/blub.txt' ---------- nosy: +berker.peksag resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 11:33:11 2016 From: report at bugs.python.org (Emanuel Barry) Date: Mon, 20 Jun 2016 15:33:11 +0000 Subject: [issue27356] csv In-Reply-To: <1466436264.58.0.694730033551.issue27356@psf.upfronthosting.co.za> Message-ID: <1466436791.17.0.499950110823.issue27356@psf.upfronthosting.co.za> Emanuel Barry added the comment: (Berker beat me to it, but posting anyway since it is more detailed) Backslashes are escape characters, and "\b" is treated as "\x08". Invalid combinations (e.g. "\A", "\D"...) automatically escape the backslash, but you shouldn't rely on this behaviour - as you can see, it can break in various ways. To fix your issue, you can either: - Add a single 'r' before the beginning of your string, i.e. r"C:\Users\Anwender\Desktop\Test\blub.txt" - the 'r' prefix tells Python to automatically escape all backslashes it sees (unless it's at the end of the string, in that case you need to escape it yourself). - Escape each backslash in your string, i.e. "C:\\Users\\Anwender\\Desktop\\Test\\blub.txt" - the extra backslash tells Python "treat this as a literal backslash, don't use it to escape anything" - Since this is Windows, you can use forward slashes, i.e. "C:/Users/Anwnder/Desktop/Test/blub.txt", it will work all the same for Python. ---------- nosy: +ebarry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 11:45:41 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Jun 2016 15:45:41 +0000 Subject: [issue27213] Rework CALL_FUNCTION* opcodes In-Reply-To: <1465026334.02.0.369802561902.issue27213@psf.upfronthosting.co.za> Message-ID: <1466437541.42.0.232973869979.issue27213@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Demur. I left few comments on Rietveld (this is only the quick glance). Good news that this change allows to simplify BUILD_MAP_UNPACK_WITH_CALL. But using 15th bit means using EXTENDED_ARG. I think it would be simpler to just push an empty tuple with LOAD_CONST. The same number of opcodes, but simpler implementation and nicer disassemble output. Mark's idea about using oparg of the general variant for specifying a number of positional arguments without packing them in a tuple looks interesting. But I don't bother about this case. According to the statistics of running CPython tests *args or *kwargs are used only in 0.4% of calls. This is hardly worth optimizing. I'm going to collect more detailed statistics for number of args and function/method distinguishing. As about PyFunction_CallSimple() etc, see issue26814 and issue27128. _PyObject_FastCall() protocol and new calling protocol should cover the case of new CALL_FUNCTION and may be CALL_FUNCTION_KW (>99% of calls in sum). ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 11:53:48 2016 From: report at bugs.python.org (Sworddragon) Date: Mon, 20 Jun 2016 15:53:48 +0000 Subject: [issue27357] Enhancing the installer Message-ID: <1466438028.41.0.887417379593.issue27357@psf.upfronthosting.co.za> New submission from Sworddragon: On installing Python 3.5.1 with the Windows installer I have noticed some things that could maybe be enhanced: - The launcher provides the option "Add Python 3.5 to PATH" on the first page. But if a custom installation is choosen the option appears again as "Add Python to environment variables". I think this option should not appear twice in this case so one of them could be removed. If both should be kept I think they should then at least reference to the same text. - On a custom installation if the option "py launcher" is disabled the suboption "for all users (requires elevation)" does not get disabled. Since the option "Associate files with Python (requires the py launcher)" seems to get disabled in this case the other option should probably get disabled too. - On a custom installation the option "Create shortcuts for installed applications" sounds confusing. What shortcuts are being created for what applications? Currently I'm assuming that the last word has a typo and this option creates the startmenu and desktop shortcuts. If this is the case maybe this option should be separated into 2 for the startmenu and the desktop shortcuts. ---------- components: Installation messages: 268908 nosy: Sworddragon priority: normal severity: normal status: open title: Enhancing the installer type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 12:05:13 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 20 Jun 2016 16:05:13 +0000 Subject: [issue27010] email library could "recover" from bad mime boundary like (some?) email clients do In-Reply-To: <1463067718.45.0.558318505018.issue27010@psf.upfronthosting.co.za> Message-ID: <1466438713.38.0.629234097589.issue27010@psf.upfronthosting.co.za> R. David Murray added the comment: Unfortunatley no, things were too busy. I'm hoping to have time to review email patches in the not too distant future, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 12:16:37 2016 From: report at bugs.python.org (Sworddragon) Date: Mon, 20 Jun 2016 16:16:37 +0000 Subject: [issue27357] Enhancing the installer In-Reply-To: <1466438028.41.0.887417379593.issue27357@psf.upfronthosting.co.za> Message-ID: <1466439397.4.0.273886313132.issue27357@psf.upfronthosting.co.za> Sworddragon added the comment: Edit: Forgot to say that the first point also applies to the options "Install launcher for all users (recommended)" and "for all users (requires elevation)" or "Install for all users" dependent on what the first one actually means. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 12:27:06 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 20 Jun 2016 16:27:06 +0000 Subject: [issue27353] Add nroot function to math In-Reply-To: <1466382160.58.0.562689353089.issue27353@psf.upfronthosting.co.za> Message-ID: <1466440026.04.0.445922453399.issue27353@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 12:28:32 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 20 Jun 2016 16:28:32 +0000 Subject: [issue27353] Add nroot function to math In-Reply-To: <1466382160.58.0.562689353089.issue27353@psf.upfronthosting.co.za> Message-ID: <1466440112.43.0.329627632726.issue27353@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +mark.dickinson, tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 13:04:45 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Jun 2016 17:04:45 +0000 Subject: [issue27353] Add nroot function to math In-Reply-To: <1466382160.58.0.562689353089.issue27353@psf.upfronthosting.co.za> Message-ID: <1466442285.06.0.630760827529.issue27353@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Looking at issue27181, nroot() wouldn't help too much to implement geometric mean (msg267990). ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 13:15:46 2016 From: report at bugs.python.org (Ilya Kulakov) Date: Mon, 20 Jun 2016 17:15:46 +0000 Subject: [issue27354] SSLContext.load_verify_locations cannot handle paths on Windows which cannot be encoded using mbcs In-Reply-To: <1466389929.18.0.227515818606.issue27354@psf.upfronthosting.co.za> Message-ID: <1466442946.06.0.682551309993.issue27354@psf.upfronthosting.co.za> Ilya Kulakov added the comment: I believe this is a bug, because path suitable for os.path (or pathlib), should be equally suitable for load_verify_locations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 13:23:51 2016 From: report at bugs.python.org (Upendra Kumar) Date: Mon, 20 Jun 2016 17:23:51 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1466443431.64.0.566949916253.issue27051@psf.upfronthosting.co.za> Upendra Kumar added the comment: For blog posts related to this project, here is the blog link : https://scorython.wordpress.com For now, there are following posts : 1. Application Screenshots 2. Design Patterns: How to write reusable and tidy software? ( to be completed) 3. Menace of Global Variables : Just a light post 4. Page Layouts and Application Flow of Logic 5. Ist Design Iteration of ?pip? GUI 6. My First GSoC Post : Notes on process of designing a GUI application ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 13:28:09 2016 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Mon, 20 Jun 2016 17:28:09 +0000 Subject: [issue27351] Unexpected ConfigParser.read() behavior when passed fileobject In-Reply-To: <1466311827.21.0.0107030173129.issue27351@psf.upfronthosting.co.za> Message-ID: <1466443689.6.0.504468715223.issue27351@psf.upfronthosting.co.za> ?ukasz Langa added the comment: Thanks for your report, Rich. configparser is one of the oldest libraries in the standard library. Its behavior might sometimes not be intuitive to newcomers but is burdened by years of backwards compatibility. Changing the behavior now to raise a type error on an open file passed to read would inevitably cause some program in the wild to break. Given this constraint, there's not much we can do besides documentation. If you have suggestions how we could improve it, let me know here. ---------- assignee: -> lukasz.langa stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 13:36:59 2016 From: report at bugs.python.org (Rich Rauenzahn) Date: Mon, 20 Jun 2016 17:36:59 +0000 Subject: [issue27351] Unexpected ConfigParser.read() behavior when passed fileobject In-Reply-To: <1466311827.21.0.0107030173129.issue27351@psf.upfronthosting.co.za> Message-ID: <1466444219.85.0.662051338424.issue27351@psf.upfronthosting.co.za> Rich Rauenzahn added the comment: Thank you, lukasz. That's the answer I anticipated -- I can appreciate the backwards compatibility aspect very much. Regarding the docs, the docs say: "Attempt to read and parse a list of filenames, returning a list of filenames which were successfully parsed." I don't know if the convention in the docs is that list always means *list*, but it could be changed to be iterable since that is the implementation. That fileobjects are also iterables could be pointed out here, but I think anyone making this mistake isn't going to make the mistake from misreading the docs, it's from skipping the docs and assuming read() is consistent with write(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 13:45:06 2016 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Mon, 20 Jun 2016 17:45:06 +0000 Subject: [issue27199] TarFile expose copyfileobj bufsize to improve throughput In-Reply-To: <1464980137.78.0.803567676795.issue27199@psf.upfronthosting.co.za> Message-ID: <1466444706.26.0.551566303588.issue27199@psf.upfronthosting.co.za> Changes by ?ukasz Langa : ---------- nosy: +lars.gustaebel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 13:47:32 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Mon, 20 Jun 2016 17:47:32 +0000 Subject: [issue27353] Add nroot function to math In-Reply-To: <1466382160.58.0.562689353089.issue27353@psf.upfronthosting.co.za> Message-ID: <1466444852.38.0.335096102081.issue27353@psf.upfronthosting.co.za> Steven D'Aprano added the comment: I suggested on python-ideas that the math module be given a pure-Python front end. Guido wasn't too keen on that idea, so I won't push for it. He did agree that having nroot in math was a reasonable idea. If I attach a pure Python implementation and tests, is anyone interested in porting it to C? I'm afraid that "Hello World" is about the level of my C skills. As far as the geometric mean goes, Serhiy refers to a comment about the naive calculation likely overflowing. That's true, but I don't intend to do a naive calculation. In any case, even if I don't end up use nroot for geometric mean, it will still be useful as a more explicit and more accurate alternative to pow(x, 1/n). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 13:57:46 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Jun 2016 17:57:46 +0000 Subject: [issue27353] Add nroot function to math In-Reply-To: <1466382160.58.0.562689353089.issue27353@psf.upfronthosting.co.za> Message-ID: <1466445466.96.0.767380256396.issue27353@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: For general use I think it would be more useful to make pow() supporting fractions (using as_integer_ration()). >>> math.pow(1000, fractions.Fraction(2, 3)) 100.0 >>> math.pow(100000, decimal.Decimal('0.4')) 100.0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 14:36:50 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 20 Jun 2016 18:36:50 +0000 Subject: [issue26859] unittest fails with "Start directory is not importable" when trying to run sourceless tests In-Reply-To: <1461678137.48.0.743276761028.issue26859@psf.upfronthosting.co.za> Message-ID: <1466447810.51.0.578760338533.issue26859@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Thanks for the review Pamela, indeed self.vfs is not defined. The patched test_unittest runs without failure because the list_dir() nested function is never called. It is also never called in the un-patched version. Actually the un-patched test_discover_start_dir_is_package_calls_package_load_tests runs without failure when changing '__init__.py' of vfs to 'foo' or whatever :( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 14:41:23 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 Jun 2016 18:41:23 +0000 Subject: [issue20120] Percent-signs (%) in .pypirc should not be interpolated In-Reply-To: <1388825675.42.0.435893533792.issue20120@psf.upfronthosting.co.za> Message-ID: <20160620184109.5135.68682.9DB993D6@psf.io> Roundup Robot added the comment: New changeset 83d731f01dde by Berker Peksag in branch '3.5': Issue #20120: Add a test case to verify the % char can be used in .pypirc https://hg.python.org/cpython/rev/83d731f01dde New changeset 703d9066c459 by Berker Peksag in branch 'default': Issue #20120: Merge from 3.5 https://hg.python.org/cpython/rev/703d9066c459 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 15:42:38 2016 From: report at bugs.python.org (tzickel) Date: Mon, 20 Jun 2016 19:42:38 +0000 Subject: [issue25083] Python can sometimes create incorrect .pyc files In-Reply-To: <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za> Message-ID: <1466451758.45.0.33918778317.issue25083@psf.upfronthosting.co.za> tzickel added the comment: any chance for 2.6.12 ? 4 line patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 15:46:24 2016 From: report at bugs.python.org (Brett Cannon) Date: Mon, 20 Jun 2016 19:46:24 +0000 Subject: [issue25083] Python can sometimes create incorrect .pyc files In-Reply-To: <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za> Message-ID: <1466451984.97.0.988273805425.issue25083@psf.upfronthosting.co.za> Brett Cannon added the comment: Python 2.6 is no longer supported. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 15:46:31 2016 From: report at bugs.python.org (Brett Cannon) Date: Mon, 20 Jun 2016 19:46:31 +0000 Subject: [issue25083] Python can sometimes create incorrect .pyc files In-Reply-To: <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za> Message-ID: <1466451991.97.0.54576014545.issue25083@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: -brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 15:58:05 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 20 Jun 2016 19:58:05 +0000 Subject: [issue27354] SSLContext.load_verify_locations cannot handle paths on Windows which cannot be encoded using mbcs In-Reply-To: <1466389929.18.0.227515818606.issue27354@psf.upfronthosting.co.za> Message-ID: <1466452685.29.0.677512557321.issue27354@psf.upfronthosting.co.za> STINNER Victor added the comment: The Python ssl module is a wrapper to the OpenSSL library. For this issue, we are talking about the function SSL_CTX_load_verify_locations(): https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_load_verify_locations.html OpenSSL expects a byte string for CAfile and CApath. On Windows, it means a string encoded to the ANSI code page. OpenSSL doesn't seem to support paths not encodable to the ANSI code page on Windows. I suggest you to report the issue to the OpenSSL bug tracker: https://www.openssl.org/community/#bugs A workaround is to avoid characters not encodable to the ANSI code page, maybe by using symbolic links? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 15:58:26 2016 From: report at bugs.python.org (Zachary Ware) Date: Mon, 20 Jun 2016 19:58:26 +0000 Subject: [issue27355] Strip out the last lingering vestiges of Windows CE support In-Reply-To: <1466408180.27.0.0873204690606.issue27355@psf.upfronthosting.co.za> Message-ID: <1466452706.51.0.00292984078483.issue27355@psf.upfronthosting.co.za> Zachary Ware added the comment: +1 Doesn't break anything in a x64 build for me. Modules/_ctypes/libffi_arm_wince/ should also be removed, though (it's a private, ancient copy of libffi that has never actually been used as far as I can tell). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 16:01:41 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 20 Jun 2016 20:01:41 +0000 Subject: [issue27354] SSLContext.load_verify_locations cannot handle paths on Windows which cannot be encoded using mbcs In-Reply-To: <1466389929.18.0.227515818606.issue27354@psf.upfronthosting.co.za> Message-ID: <1466452901.4.0.0926469906675.issue27354@psf.upfronthosting.co.za> STINNER Victor added the comment: "OpenSSL doesn't seem to support paths not encodable to the ANSI code page on Windows. I suggest you to report the issue to the OpenSSL bug tracker: (...)" For example, it wass already requested 6 years ago on the openssl-users at openssl.org mailing list: http://comments.gmane.org/gmane.comp.encryption.openssl.user/38104 -- Oh, another link is more useful: https://stackoverflow.com/questions/2401059/openssl-with-unicode-paths "you will have to manually load the certificate files yourself using standard OS file I/O functions that support Unicode paths, and then parse the raw data and load it into OpenSSL, such as via PEM_read_bio_X509 with sk_X509_NAME_push, PEM_read_bio_PrivateKey/d2i_PrivateKey_bio with SSL_CTX_use_PrivateKey, d2i_X509_bio/PEM_read_bio_X509 with SSL_CTX_use_certificate, etc." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 16:18:34 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 20 Jun 2016 20:18:34 +0000 Subject: [issue26930] Upgrade installers to OpenSSL 1.0.2h In-Reply-To: <1462285174.78.0.332365810571.issue26930@psf.upfronthosting.co.za> Message-ID: <1466453914.83.0.191806205978.issue26930@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 16:18:58 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 20 Jun 2016 20:18:58 +0000 Subject: [issue26930] Upgrade installers to OpenSSL 1.0.2h In-Reply-To: <1462285174.78.0.332365810571.issue26930@psf.upfronthosting.co.za> Message-ID: <1466453938.82.0.774827194197.issue26930@psf.upfronthosting.co.za> Steve Dower added the comment: Test build went fine, was validated in another thread. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 16:19:58 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 20 Jun 2016 20:19:58 +0000 Subject: [issue27353] Add nroot function to math In-Reply-To: <1466382160.58.0.562689353089.issue27353@psf.upfronthosting.co.za> Message-ID: <1466453998.45.0.507252447891.issue27353@psf.upfronthosting.co.za> Raymond Hettinger added the comment: If this ends up going forward (and I'm don't believe a good case has been made), I would prefer the function to be called "nth_root" which is unequivocal and readable (it is also close to what Matlab uses: http://www.mathworks.com/help/matlab/ref/nthroot.html ) It seems that Matlab's reason for inclusion doesn't have anything to do with precision; instead, they say "While power is a more efficient function for computing the roots of numbers, in cases where both real and complex roots exist, power returns only the complex roots. In these cases, use nthroot to obtain the real roots." Mathematica uses Surd[n, x] for that purpose. Outside of Matlab and Mathematica, I'm not seeing this function elsewhere (on my calculator, in Java math, etc.). This suggests that the need is minimal. As an alternative, we could follow the model used in the itertools module and include "recipes" for functions that don't meet that bar for inclusion in the standard library. Here's one recipe I found after a few seconds of googling: from decimal import Decimal, getcontext def nthroot (n, A, precision): getcontext().prec = precision n = Decimal(n) x_0 = A / n #step 1: make a while guess. x_1 = 1 #need it to exist before step 2 while True: #step 2: x_0, x_1 = x_1, (1 / n)*((n - 1)*x_0 + (A / (x_0 ** (n - 1)))) if x_0 == x_1: return x_1 Out of Steven's original suggestions, I most prefer "leave nth_root in statistics as a private function". ---------- nosy: +rhettinger, skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 16:28:38 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 20 Jun 2016 20:28:38 +0000 Subject: [issue27309] Visual Styles support to tk/tkinter file and message dialogs In-Reply-To: <1465855196.42.0.576274211307.issue27309@psf.upfronthosting.co.za> Message-ID: <1466454518.42.0.387573741308.issue27309@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Pat, thank you for the explanation, xml, and link. I was a bit confused by the overlapping yet different meanings of 'ttk theme' and 'Windows theme'. For 3.6, I am converting IDLE to use ttk widgets. From the example on the SO page, which links to https://i.stack.imgur.com/36MnO.png, the new Windows common controls better fit the default ttk theme on Windows. However, for the same reason, the old set better fits standard tk widgets. My impression from Stackoverflow tkinter questions is that most beginers start with tk widgets only. Therefore, using the new set should not be forced on all Windows tkinter users. Tkinter would need to be enhanced to optionally tell tk to use the new set. I don't know if this is possible or how it would be done. I leave this to Serhiy. For an example, open IDLE on Windows with 3.6.0a2 or before. Select Options => Configure IDLE => Highlighting. Click [Save as New Custom Theme] to bring up a constructed entry box. Without entering anything, click [Ok]. The commondialog messagebox error popup has an [Ok] button with a similar relief. IDLE does not here use the commondialog entry messagebox because these disappear as soon as [Ok] is clicked, before error checking. For an annoying example, select File => Open Module (Alt-m) and enter something that is not exactly 'idlelib.configdialog' (or 'idlelib.configDialog' before 3.6.0a2). After dismissing the error box, one has to begin over. I plan to replace with a custom validating entry popup. > On X Windows Tk provides all these dialogs itself and so they use Tk widgets (or ttk widgets in more recent versions). I wish these were available, at least as an option, on all systems. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 16:33:13 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 20 Jun 2016 20:33:13 +0000 Subject: [issue26923] asyncio.gather drops cancellation In-Reply-To: <1462279806.1.0.880381545595.issue26923@psf.upfronthosting.co.za> Message-ID: <1466454793.51.0.166887392017.issue26923@psf.upfronthosting.co.za> Guido van Rossum added the comment: @Yury, any comments? The fix looks fine to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 16:41:27 2016 From: report at bugs.python.org (Larry Hastings) Date: Mon, 20 Jun 2016 20:41:27 +0000 Subject: [issue27355] Strip out the last lingering vestiges of Windows CE support In-Reply-To: <1466408180.27.0.0873204690606.issue27355@psf.upfronthosting.co.za> Message-ID: <1466455287.53.0.52186732662.issue27355@psf.upfronthosting.co.za> Larry Hastings added the comment: Nosying two people who I know worked on the port originally, just in case they have an opinion about removing WinCE. (Remind me. Why is our private copy of libffi a divergent unmaintained fork? libffi still gets updates; last update was two years ago. Why can't we just... update ours?) ---------- nosy: +mhammond, tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 16:42:25 2016 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 20 Jun 2016 20:42:25 +0000 Subject: [issue26923] asyncio.gather drops cancellation In-Reply-To: <1462279806.1.0.880381545595.issue26923@psf.upfronthosting.co.za> Message-ID: <1466455345.0.0.515018114996.issue26923@psf.upfronthosting.co.za> Yury Selivanov added the comment: > @Yury, any comments? The fix looks fine to me. I've left a comment in code review. Other than that, the patch/approach looks good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 16:57:41 2016 From: report at bugs.python.org (Brett Cannon) Date: Mon, 20 Jun 2016 20:57:41 +0000 Subject: [issue27352] Bug in IMPORT_NAME In-Reply-To: <1466337192.83.0.569731150376.issue27352@psf.upfronthosting.co.za> Message-ID: <1466456261.14.0.363816341391.issue27352@psf.upfronthosting.co.za> Brett Cannon added the comment: My suspicion is the -1 aspect is a hold-over from that being the default level value in Python 2.7 that no one removed. The patch LGTM. Do we need a test for this for some reason? ---------- assignee: -> serhiy.storchaka stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 16:57:57 2016 From: report at bugs.python.org (Ryan Petrello) Date: Mon, 20 Jun 2016 20:57:57 +0000 Subject: [issue27172] Add skip_bound_arg argument to inspect.Signature.from_callable() In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za> Message-ID: <1466456277.45.0.261671297753.issue27172@psf.upfronthosting.co.za> Ryan Petrello added the comment: Yury/Nick, Any word on this? I know it's minor, but I'd love to see this make it into Python3.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 17:02:08 2016 From: report at bugs.python.org (Tim Peters) Date: Mon, 20 Jun 2016 21:02:08 +0000 Subject: [issue27353] Add nroot function to math In-Reply-To: <1466382160.58.0.562689353089.issue27353@psf.upfronthosting.co.za> Message-ID: <1466456528.83.0.960818231433.issue27353@psf.upfronthosting.co.za> Tim Peters added the comment: Note that the very popular TI graphics calculators have had a distinct nth-root function at least since the TI-83. It's a minor convenience there. I'm +0 on adding it to Python's math module, which means not enough to do any work ;-) Note that if it is added to `math`, it should also be added to `cmath`. Short of that, a private function in `statistics` seems best to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 17:11:31 2016 From: report at bugs.python.org (Brett Cannon) Date: Mon, 20 Jun 2016 21:11:31 +0000 Subject: [issue22557] Local import is too slow In-Reply-To: <1412512141.77.0.0512115045124.issue22557@psf.upfronthosting.co.za> Message-ID: <1466457091.9.0.615332194301.issue22557@psf.upfronthosting.co.za> Brett Cannon added the comment: Do you happen to know why you didn't get a review link for your patch, Serhiy? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 17:15:56 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 20 Jun 2016 21:15:56 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1466457356.3.0.659650368493.issue27051@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Upendra, Lorenzo is doing your midterm evaluation. 3.6.0a3 is scheduled for 7/11. A week before that, I would like to see a patch posted here that I could potentially commit. Work out the details of what to include with Lorenzo. The patch should include adding yourself alphabetically (currently between Adnan Umer and Roger Upole) to misc.ACKS. It could include a patch for the idlelib section of docs/whatsnew.rst. It should not include the misc.NEWS entry. You could instead post suggested text for both here. The patch should include some automated tests, but I know that some will be tricky. A suggested protocol for human testing, posted here, can initially substitute for some automated tests. Start by writing down, if you have not already, an outline of what you do to test your code, and what I might do to verify that it works. I am working on an IDLE patch that already includes the sort of end-to-end testing I have talked about: enter data into gui, simulate 'go' click, and then check final result. I will post the new issue number when there is something to look at. ---------- assignee: -> terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 17:17:36 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 20 Jun 2016 21:17:36 +0000 Subject: [issue22557] Local import is too slow In-Reply-To: <1412512141.77.0.0512115045124.issue22557@psf.upfronthosting.co.za> Message-ID: <1466457456.3.0.656641239662.issue22557@psf.upfronthosting.co.za> STINNER Victor added the comment: > Do you happen to know why you didn't get a review link for your patch, Serhiy? faster_import_4.patch is based on the revision d736c9490333 which is not part of the CPython repository. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 17:18:44 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 20 Jun 2016 21:18:44 +0000 Subject: [issue22557] Local import is too slow In-Reply-To: <1412512141.77.0.0512115045124.issue22557@psf.upfronthosting.co.za> Message-ID: <1466457524.42.0.408545725612.issue22557@psf.upfronthosting.co.za> STINNER Victor added the comment: I rebased faster_import_4.patch on default. ---------- Added file: http://bugs.python.org/file43491/faster_import_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 17:28:28 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Jun 2016 21:28:28 +0000 Subject: [issue22557] Local import is too slow In-Reply-To: <1412512141.77.0.0512115045124.issue22557@psf.upfronthosting.co.za> Message-ID: <1466458108.79.0.860975860411.issue22557@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Victor. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 17:35:38 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Jun 2016 21:35:38 +0000 Subject: [issue27352] Bug in IMPORT_NAME In-Reply-To: <1466337192.83.0.569731150376.issue27352@psf.upfronthosting.co.za> Message-ID: <1466458538.68.0.934303070225.issue27352@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thak you for the explanation Brett. Since current "import" without "from" is not broken, I suppose that the raised exception is cleared somewhere later. The patch doesn't have visible effect (unless may be using nonstandard loaders or __import__, don't know). It just cleans up the code, avoid raising unneeded exception (small performance boost) and may be fix some hidden non-reproducible bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 17:36:30 2016 From: report at bugs.python.org (Brett Cannon) Date: Mon, 20 Jun 2016 21:36:30 +0000 Subject: [issue27352] Bug in IMPORT_NAME In-Reply-To: <1466337192.83.0.569731150376.issue27352@psf.upfronthosting.co.za> Message-ID: <1466458590.81.0.20371151372.issue27352@psf.upfronthosting.co.za> Brett Cannon added the comment: Then I say go ahead and commit it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 17:40:24 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 20 Jun 2016 21:40:24 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1466458824.59.0.86743449931.issue27051@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I should mention that the reason we have multiple alpha and beta releases for a new version is that new modules such as this are *typically* incomplete, a bit rough in the API, and even buggy, when first committed. We have had the most problems when modules are first committed just before the beta release. Getting in an alpha release gives more time for feedback and polishing before that. As soon as I commit something, I will notify #23551 and ask people nosy there to test and comment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 17:52:07 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Jun 2016 21:52:07 +0000 Subject: [issue23908] Check path arguments of os functions for null character In-Reply-To: <1428684232.77.0.530667773352.issue23908@psf.upfronthosting.co.za> Message-ID: <1466459527.13.0.898912102004.issue23908@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Proposed patch fixes this issue and issue13848 in 2.7. ---------- nosy: +benjamin.peterson stage: needs patch -> patch review Added file: http://bugs.python.org/file43492/unicode_converter_null_char-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 17:53:16 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Jun 2016 21:53:16 +0000 Subject: [issue23908] Check path arguments of os functions for null character In-Reply-To: <1428684232.77.0.530667773352.issue23908@psf.upfronthosting.co.za> Message-ID: <1466459596.47.0.642653062736.issue23908@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Since the large part of code is Windows specific (and even is not compiled on Linux), the patch needs testing on Windows. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 18:16:19 2016 From: report at bugs.python.org (tzickel) Date: Mon, 20 Jun 2016 22:16:19 +0000 Subject: [issue25083] Python can sometimes create incorrect .pyc files In-Reply-To: <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za> Message-ID: <1466460979.9.0.995008454713.issue25083@psf.upfronthosting.co.za> tzickel added the comment: Sorry Brett of course I meant the upcoming 2.7.12 .... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 18:31:09 2016 From: report at bugs.python.org (Ilya Kulakov) Date: Mon, 20 Jun 2016 22:31:09 +0000 Subject: [issue27354] SSLContext.load_verify_locations cannot handle paths on Windows which cannot be encoded using mbcs In-Reply-To: <1466389929.18.0.227515818606.issue27354@psf.upfronthosting.co.za> Message-ID: <1466461869.31.0.0737243268023.issue27354@psf.upfronthosting.co.za> Ilya Kulakov added the comment: Viktor, I also came across this thread but it is rather old (we're using OpenSSL 1.0.2h). And it would only explain if _neither_ of my methods had worked. But as you can see, the last one (passing UTF-8 encoded bytes) works. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 18:39:25 2016 From: report at bugs.python.org (Ilya Kulakov) Date: Mon, 20 Jun 2016 22:39:25 +0000 Subject: [issue27354] SSLContext.load_verify_locations cannot handle paths on Windows which cannot be encoded using mbcs In-Reply-To: <1466389929.18.0.227515818606.issue27354@psf.upfronthosting.co.za> Message-ID: <1466462365.93.0.929736057962.issue27354@psf.upfronthosting.co.za> Ilya Kulakov added the comment: I checked the source code of OpenSSL, specifically the `bss_file.c:file_fopen` function (https://github.com/openssl/openssl/blob/OpenSSL_1_0_2h/crypto/bio/bss_file.c#L118-L167). As you can see it support UTF-8 encoded strings under Windows. Python must follow up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 19:09:25 2016 From: report at bugs.python.org (Ned Deily) Date: Mon, 20 Jun 2016 23:09:25 +0000 Subject: [issue27357] Enhancing the Windows installer In-Reply-To: <1466438028.41.0.887417379593.issue27357@psf.upfronthosting.co.za> Message-ID: <1466464165.28.0.638435657143.issue27357@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware title: Enhancing the installer -> Enhancing the Windows installer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 19:27:07 2016 From: report at bugs.python.org (Ned Deily) Date: Mon, 20 Jun 2016 23:27:07 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1466465227.91.0.766786690303.issue27051@psf.upfronthosting.co.za> Ned Deily added the comment: Terry et al: is anyone from the Python Packaging Authority (and or distutils-sig) involved in this project? After all, pip is developed and maintained by them, not by python-dev. I don't think we should be committing code to the Python Standard library for an interface they control that does not at least have their blessing. Nick, what do you think? https://pip.pypa.io/en/stable/ ---------- nosy: +ncoghlan, ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 19:45:47 2016 From: report at bugs.python.org (Demur Rumed) Date: Mon, 20 Jun 2016 23:45:47 +0000 Subject: [issue27213] Rework CALL_FUNCTION* opcodes In-Reply-To: <1465026334.02.0.369802561902.issue27213@psf.upfronthosting.co.za> Message-ID: <1466466347.93.0.255588386601.issue27213@psf.upfronthosting.co.za> Demur Rumed added the comment: callfunc2 fixes test_dis, addresses code review, currently implements a copy of _PyEval_EvalCodeWithName as _PyEval_EvalCodeWithName2 which changes a few lines to work with new keyword stack layout so that we can use fast_function with kwargs CALL_FUNCTION_EX is benchmarking much slower (4x slower when using **kw), but unpatched hits similar perf when using multiple **kw. So most slowdown is due to BUILD_MAP_UNPACK_WITH_CALL being slow. So some patch which speeds up intersection check (eg optimize to not allocate intersection when disjoint) should greatly diminish the perf loss on this simpler implementation. I'll open a separate issue for this ---------- Added file: http://bugs.python.org/file43493/callfunc2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 21:18:20 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 21 Jun 2016 01:18:20 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1466471900.41.0.447281892068.issue27051@psf.upfronthosting.co.za> Ned Deily added the comment: Let me just expand on my concerns here. I apologize for not thinking about these earlier: I haven't been paying enough attention to this project. And I certainly do not intend this to be a criticism of anyone's work on this, especially your work, Upendra and your mentoring, Lorenzo and Terry. Thank you! The issues I'm concerned about here are not so much technical but rather related to process and long-term maintenance. As is discussed in PEP 453, https://www.python.org/dev/peps/pep-0453/, which describes how pip was made available through the Python Standard Library, there was a clear boundary drawn between pip development and the standard library: "This PEP does not propose making pip (or any dependencies) directly available as part of the standard library. Instead, pip will be a bundled application provided along with CPython for the convenience of Python users, but subject to its own development life cycle and able to be upgraded independently of the core interpreter and standard library." What the standard library provides are mechanisms to deliver pip in a standard library (for example, via the "ensurepip" module) but there is deliberately almost no documentation in the standard library about the use of pip. Rather there are links to the official Python Packaging Authority pip documentation. This was to ensure that pip development remains decoupled from Python development; both can operate on their own cycles and have different goals and requirements. For example, a given pip release typically supports a broad range of Python releases; pip has intimate dependencies on other resources, like PyPI, ones that Python itself doesn't (or at least as tightly coupled as pip has). Yes, it's not 100% clean but the separation of concerns and design authority was and remains a very important part of the relationship between pip and Python as independent projects. And that independence also means that the details of how users interface with pip in the current command line environment - what commands are available, what options each has, default values, current best practices - are the purview of the Python Packaging Authority and the pip project, not Python development. This translates directly into the whole user experience when using a gui instead of a cli. As we all know, user experience and user interface design is *hard*, especially in the multi-platform environment that Python and pip operate in and especially for relatively naive users, presumably the primary audience for such a gui. It's nice to think of having an IDLE gui interface for pip but treating it as an IDLE feature rather than a pip feature violates the intent of PEP 453 (IMO) and jeopardizes the chance for this feature being successful and has the potential to disrupt the success of PEP 453. In the spirit of PEP 453, I think the gui interface (or at least the bulk of it) needs to be design-reviewed and approved by the Python Packaging Authority and somehow be part of the pip development and release process. Python releases would deliver it initially via the current ensurepip and third-party packager mechanisms and the gui would be updated through normal pip mechanisms, asynchronously of Python releases, so that the gui remains synchronized with pip. Ideally, the gui would be not dependent on IDLE at all; IDLE would just provide convenience UI elements to launch the gui. Perhaps this has been discussed before and included in the project plans. If not, I think it needs to be now before we commit ourselves to creating a new set of potentially problematic dependencies for the future. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 21:45:52 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 21 Jun 2016 01:45:52 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1466473552.43.0.462471676519.issue27051@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Ned, I agree with you in principle, and would have preferred that this had been handled by PPA/distutils/PIP folk. But see at least the first 4 messages on the original issue #23551, Feb 28 2015, where Donald Stufft says he would like to see it happen but would not do it. Hightlights of the rest: In the first month of discussion others said yes, great idea. 6 months later, in September, I posted some proof of concept results. About 5 months later, I suggested on core-mentorship that this would be a good GSOC project and a few days later Upendra expressed interest. Another student joined the competition in March. March 27, I posted on pydev "Adding a Pip GUI to IDLE and idlelib (GSOC project)" https://mail.python.org/pipermail/python-dev/2016-March/143586.html and said at the top "Before I commit to mentoring a student (sometime in April), I would like to be sure, by addressing any objections now, that I will be able to commit the code when ready (August or before)." I ended the post with two possible objections. As it turns out, no one objected. Ethan Furman and Nick Coughlin strongly approved, the latter at https://mail.python.org/pipermail/python-dev/2016-April/143611.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 21:46:01 2016 From: report at bugs.python.org (Demur Rumed) Date: Tue, 21 Jun 2016 01:46:01 +0000 Subject: [issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow Message-ID: <1466473561.23.0.768330028286.issue27358@psf.upfronthosting.co.za> New submission from Demur Rumed: BUILD_MAP_UNPACK_WITH_CALL is _really_ slow, wasting much of its time asserting that keys are non overlapping. This patch optimizes a fast path for distinct dicts, especially useful for #27213 where BUILD_MAP_UNPACK_WITH_CALL is generated for a single **kw rather than needing **kw1,**kw2 to hit this slow opcode This patch tracks size of dictionary, if size doesn't increase by same size as the dict we updated sum with, then we scan to find where collision is. Further optimization can be done by scanning size of dicts to preallocate dictionary Microbenchmark: from timeit import timeit def f(**x):return x timeit(lambda:f(**{'a':2},**{'b':2})) Unpatched takes ~15s Patched takes ~5s ---------- files: mapaca.patch keywords: patch messages: 268951 nosy: Demur Rumed priority: normal severity: normal status: open title: BUILD_MAP_UNPACK_WITH_CALL is slow Added file: http://bugs.python.org/file43494/mapaca.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 21:46:29 2016 From: report at bugs.python.org (Demur Rumed) Date: Tue, 21 Jun 2016 01:46:29 +0000 Subject: [issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow In-Reply-To: <1466473561.23.0.768330028286.issue27358@psf.upfronthosting.co.za> Message-ID: <1466473589.77.0.25815250179.issue27358@psf.upfronthosting.co.za> Changes by Demur Rumed : ---------- components: +Interpreter Core type: -> performance versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 21:49:20 2016 From: report at bugs.python.org (Demur Rumed) Date: Tue, 21 Jun 2016 01:49:20 +0000 Subject: [issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow In-Reply-To: <1466473561.23.0.768330028286.issue27358@psf.upfronthosting.co.za> Message-ID: <1466473760.1.0.772568276584.issue27358@psf.upfronthosting.co.za> Changes by Demur Rumed : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 21:50:06 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 21 Jun 2016 01:50:06 +0000 Subject: [issue26894] Readline not aborting line edition on sigint In-Reply-To: <1462027506.98.0.545203031593.issue26894@psf.upfronthosting.co.za> Message-ID: <1466473806.44.0.249624565152.issue26894@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 21:53:31 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 21 Jun 2016 01:53:31 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1466474011.79.0.676349761328.issue27051@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Ned, my response was to your first message. I am just now reading the second. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 22:10:31 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 21 Jun 2016 02:10:31 +0000 Subject: [issue12833] Document the need to pass the prompt to raw_input() with readline In-Reply-To: <1314205212.4.0.313319940132.issue12833@psf.upfronthosting.co.za> Message-ID: <1466475031.04.0.750723918058.issue12833@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- stage: patch review -> needs patch title: raw_input misbehaves when readline is imported -> Document the need to pass the prompt to raw_input() with readline versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 22:14:42 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 21 Jun 2016 02:14:42 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1466475282.93.0.113295127518.issue27051@psf.upfronthosting.co.za> Ned Deily added the comment: One other possibility: decouple the gui from both Python and pip releases by packaging and, at least initially, releasing it through PyPI as an independent project. That is, after all, the preferred mechanism for adding new functionality to the standard library. The only thing that would need to be in the standard library then is an IDLE version of "ensuregui", serving the same purpose as "ensurepip", to provide an easy way for IDLE users to initially install the gui using pip and PyPI. If, down the road, the gui is a success and the long-term support issues can be addressed, bringing the gui directly under the pip project could happen in the future. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 22:17:07 2016 From: report at bugs.python.org (Joe Jevnik) Date: Tue, 21 Jun 2016 02:17:07 +0000 Subject: [issue27359] OrderedDict pseudo-literals (WIP) Message-ID: <1466475427.25.0.285635253324.issue27359@psf.upfronthosting.co.za> New submission from Joe Jevnik: This proposes the following syntax for creating OrderedDict literals: OrderedDict[k1: v1, k2: v2, ...] This is implemented by putting a metaclass on OrderedDict which has a getitem that turns the slices into a list of tuples (after validation). The idea is taken from the library datashape where we have done this to implement pseudo literals for the Record type. This is marked as WIP because I am not quite sure why, but this patch is causing subclasses of OrderedDict to segfault in PyObject_SetItem. ---------- components: Library (Lib) files: odict_literals.patch keywords: patch messages: 268954 nosy: llllllllll priority: normal severity: normal status: open title: OrderedDict pseudo-literals (WIP) versions: Python 3.6 Added file: http://bugs.python.org/file43495/odict_literals.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 22:24:30 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 21 Jun 2016 02:24:30 +0000 Subject: [issue27359] OrderedDict pseudo-literals (WIP) In-Reply-To: <1466475427.25.0.285635253324.issue27359@psf.upfronthosting.co.za> Message-ID: <1466475870.78.0.0549109724415.issue27359@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This needs to tabled pending the outcome of the python-dev discussion to make all dicts ordered dictionaries. If it does get revived, there need to be clear motivating use cases. In most of the use cases I've seen for ordered dicts, the key/value pairs are either generated by code or loaded from an external source. The need for a dict literal is minimal at best (that is also why we don't have a literal for decimals). ---------- nosy: +rhettinger resolution: -> later status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 22:32:27 2016 From: report at bugs.python.org (Joe Jevnik) Date: Tue, 21 Jun 2016 02:32:27 +0000 Subject: [issue27359] OrderedDict pseudo-literals (WIP) In-Reply-To: <1466475427.25.0.285635253324.issue27359@psf.upfronthosting.co.za> Message-ID: <1466476347.13.0.805413814785.issue27359@psf.upfronthosting.co.za> Joe Jevnik added the comment: Assuming all dicts are ordered, there will be no need for this (as long as the parser preserves order) so I am okay with dropping this. One of the main use cases I have for wanting nice literals is when I am working on tests. I find it very nice to be able to write out the expected results in a clear way. While the app code might not be using the literals, it improves the readability of the tests, which make it easier to see that the test is correct. ---------- resolution: later -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 22:55:14 2016 From: report at bugs.python.org (paul j3) Date: Tue, 21 Jun 2016 02:55:14 +0000 Subject: [issue24419] In argparse action append_const doesn't work for positional arguments In-Reply-To: <1433891109.51.0.989129061245.issue24419@psf.upfronthosting.co.za> Message-ID: <1466477714.16.0.89415285554.issue24419@psf.upfronthosting.co.za> Changes by paul j3 : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 22:56:29 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 21 Jun 2016 02:56:29 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1466477789.51.0.586857777336.issue27051@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I seem to have anticipated some of your expansion, but I note this: while Raymond's first post could be interpreted as suggesting a new IDLE feature, with its own PIP menu with multiple options, I immediately said it should be a standalone module that IDLE starts in a separate process, with one menu entry and a few lines of code, just as with turtledemo. Putting the module (or package) in idlelib defines it as private and subject to change. I can repeat that in the package itself. The public interface will be "click on menu entry 'Run PIP". If it were moved to pip, the internal IDLE change should just be to change 'idlelib.pipgui' to 'pip.pipgui' (or whatever). I have not decided whether test_pipgui should be added to test or subsumed under test_idle by being added to idle_test. Do you or Nick have an opinion? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 23:01:39 2016 From: report at bugs.python.org (paul j3) Date: Tue, 21 Jun 2016 03:01:39 +0000 Subject: [issue8538] Add FlagAction to argparse In-Reply-To: <1272303487.22.0.380388489779.issue8538@psf.upfronthosting.co.za> Message-ID: <1466478099.46.0.334050307898.issue8538@psf.upfronthosting.co.za> Changes by paul j3 : ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 23:05:51 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 21 Jun 2016 03:05:51 +0000 Subject: [issue10116] Sporadic failures in test_urllibnet In-Reply-To: <1287150282.16.0.127032822399.issue10116@psf.upfronthosting.co.za> Message-ID: <1466478351.41.0.11659779254.issue10116@psf.upfronthosting.co.za> Martin Panter added the comment: It looks like Antoine?s second failure (test_getcode) should be fixed now that transient_internet() is used (Issue 12138). Looking at Antoine?s first failure, it will always be possible for it to fail depending on the conditions of the buildbot, internet, and the www.example.com server: def setUp(self): socket.setdefaulttimeout(self.TIMEOUT) def testURLread(self): f = _open_with_retry(urllib.urlopen, "http://www.example.com/") x = f.read() # Timed out! I would suggest changing this to connect to a server running on localhost in a background thread, and moving it into test_urllib.py because it would no longer need the ?network? resource. That should eliminate enough causes of a timeout, the remaining one being a very slow buildbot, which I don?t think is worth worrying about. Also see revision aa46bdbe641d in Python 3, where the read() call was shifted under the transient_internet() handler, and seems to defeat the purpose of the test. ---------- nosy: +martin.panter versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 23:10:57 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 21 Jun 2016 03:10:57 +0000 Subject: [issue1606233] readline on popen3 file returns empty string before end Message-ID: <1466478657.37.0.675145207441.issue1606233@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- versions: -Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 23:26:56 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 21 Jun 2016 03:26:56 +0000 Subject: [issue18300] script_helper._assert_python should set TERM='' by default. In-Reply-To: <1372164040.52.0.568545505593.issue18300@psf.upfronthosting.co.za> Message-ID: <1466479616.07.0.337033819845.issue18300@psf.upfronthosting.co.za> Martin Panter added the comment: More recently, Issue 19884 has worked around the problem where practical on non-Apple platforms, so perhaps this problem is not so important now. However it could still be present with older Gnu Readline versions, and slightly newer versions on Apple (pending my latest patch in Issue 19884). Both patches look okay to me, and since the Readline bug could still happen in some cases, I think it is worth applying them. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 23:44:55 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 21 Jun 2016 03:44:55 +0000 Subject: [issue27359] OrderedDict pseudo-literals (WIP) In-Reply-To: <1466475427.25.0.285635253324.issue27359@psf.upfronthosting.co.za> Message-ID: <1466480695.54.0.502580999895.issue27359@psf.upfronthosting.co.za> Raymond Hettinger added the comment: BTW, there's no way this particular syntax suggestion is going in without a discussion on python-dev. I think the square brackets will be a non-starter. ---------- assignee: -> rhettinger resolution: -> later status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 23:50:02 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 21 Jun 2016 03:50:02 +0000 Subject: [issue12186] readline.replace_history_item still leaks memory In-Reply-To: <1306412402.14.0.859641157612.issue12186@psf.upfronthosting.co.za> Message-ID: <1466481002.37.0.156735112052.issue12186@psf.upfronthosting.co.za> Martin Panter added the comment: This seems like something that should be fixed in Readline, rather than Python. Judging by the rl_clear_history() documentation, it sounds like this is private data. Maybe we need a version of rl_free_undo_list() that works for old history items, or a Readline library wrapper for free_history_entry(). ---------- nosy: +martin.panter resolution: -> third party _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 23:52:26 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 21 Jun 2016 03:52:26 +0000 Subject: [issue27359] OrderedDict pseudo-literals (WIP) In-Reply-To: <1466475427.25.0.285635253324.issue27359@psf.upfronthosting.co.za> Message-ID: <1466481146.04.0.443664462211.issue27359@psf.upfronthosting.co.za> Raymond Hettinger added the comment: One other thought is that the threshold for syntax changes to the language should be very high and should benefit the many, many who use Python, not just ourselves for something that might have been a little more convenient for a particular use. We've never had a user request for this before, so it suggests that the need is minimal. I'll leave this open for now, but think it was inappropriate for you to undo the status and resolution settings, especially after I referred you to an active discussion on python-dev that would make the question moot. ---------- components: +Interpreter Core -Library (Lib) status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 23:59:33 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 21 Jun 2016 03:59:33 +0000 Subject: =?utf-8?q?=5Bissue23297=5D_Clarify_error_when_=E2=80=98tokenize=2Edetect?= =?utf-8?q?=5Fencoding=E2=80=99_receives_text?= In-Reply-To: <1421901626.89.0.392776519963.issue23297@psf.upfronthosting.co.za> Message-ID: <1466481573.55.0.515276331556.issue23297@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- stage: -> needs patch title: ?tokenize.detect_encoding? is confused between text and bytes: no ?startswith? method on a byte string -> Clarify error when ?tokenize.detect_encoding? receives text type: crash -> behavior versions: +Python 3.5, Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 20 23:59:43 2016 From: report at bugs.python.org (Joe Jevnik) Date: Tue, 21 Jun 2016 03:59:43 +0000 Subject: [issue27359] OrderedDict pseudo-literals (WIP) In-Reply-To: <1466475427.25.0.285635253324.issue27359@psf.upfronthosting.co.za> Message-ID: <1466481583.78.0.255560296875.issue27359@psf.upfronthosting.co.za> Joe Jevnik added the comment: Sorry about undoing the settings, that was unintentional. The UI around these settings is sort of unintuitive. I was waiting to propose this on python-dev until I got it working, but I wanted to push up what I did have as a work in progress so I could try to get some help with the crash I am seeing. In the future I will upload the patch somewhere else until it is done. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 00:07:46 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 21 Jun 2016 04:07:46 +0000 Subject: [issue27359] OrderedDict pseudo-literals (WIP) In-Reply-To: <1466475427.25.0.285635253324.issue27359@psf.upfronthosting.co.za> Message-ID: <1466482066.19.0.791938191521.issue27359@psf.upfronthosting.co.za> Raymond Hettinger added the comment: No worries, it just seemed a little brash ;-) Go ahead and continue to post patch variants here. Once it's working, going to python-dev is the right thing to do (to see whether it meets a threshold of need and to endlessly debate what the syntax would be). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 00:23:10 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 21 Jun 2016 04:23:10 +0000 Subject: [issue24727] Wrap rl_forced_update_display() and lock readline module while active In-Reply-To: <1437908271.28.0.296512613048.issue24727@psf.upfronthosting.co.za> Message-ID: <1466482990.38.0.521546755278.issue24727@psf.upfronthosting.co.za> Martin Panter added the comment: I wonder why you can?t add the locking around input() calls at a higher level, rather than needing to change the readline module itself. ---------- stage: -> patch review title: Expand readline module -> Wrap rl_forced_update_display() and lock readline module while active _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 00:26:23 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 21 Jun 2016 04:26:23 +0000 Subject: [issue17507] To add history time format in readline In-Reply-To: <1363859983.51.0.876342279361.issue17507@psf.upfronthosting.co.za> Message-ID: <1466483183.59.0.118414676916.issue17507@psf.upfronthosting.co.za> Martin Panter added the comment: Is this related to Readline?s history_write_timestamps() feature, or is this a request for Python to make a custom history file? ---------- components: +Extension Modules -Library (Lib) nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 01:00:19 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Jun 2016 05:00:19 +0000 Subject: [issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow In-Reply-To: <1466473561.23.0.768330028286.issue27358@psf.upfronthosting.co.za> Message-ID: <1466485219.93.0.23004754985.issue27358@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The problem is that var-keyword argument can be not a dict, but general mapping. This optimization is applicable only if it is a dict. ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 01:18:33 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Jun 2016 05:18:33 +0000 Subject: [issue27359] OrderedDict pseudo-literals (WIP) In-Reply-To: <1466475427.25.0.285635253324.issue27359@psf.upfronthosting.co.za> Message-ID: <1466486313.45.0.786295086603.issue27359@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: FYI the proposition about OrderedDict literals was raised on Python-Ideas or Python-Dev multiple times. http://comments.gmane.org/gmane.comp.python.ideas/4888 http://comments.gmane.org/gmane.comp.python.ideas/6569 http://comments.gmane.org/gmane.comp.python.devel/121140 http://comments.gmane.org/gmane.comp.python.ideas/27218 http://comments.gmane.org/gmane.comp.python.ideas/33873 http://comments.gmane.org/gmane.comp.python.ideas/37439 ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 01:19:46 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 21 Jun 2016 05:19:46 +0000 Subject: [issue25259] readline macros can segfault Python In-Reply-To: <1443473589.61.0.823349470149.issue25259@psf.upfronthosting.co.za> Message-ID: <1466486386.89.0.290196967283.issue25259@psf.upfronthosting.co.za> Martin Panter added the comment: I think Victor may be on the right track. Since the macro contains two newlines, a single call to rl_callback_read_char() is going to produce two calls back to the rl_callback_handler_install() handler to receive each line. I can make the example from the Readline documentation crash the same way that Python does. First, add a macro to ~/.inputrc, which causes an exclamation mark (!) to enter two lines at once: "!": "exit\ncrash\n" Now, typing an exclamation mark will cause the example program (and Python!) to crash. In the description of rl_callback_read_char() , it says ?If the ?lhandler? function returns . . .?. That seems to be hinting at using something like setjmp() to avoid the function returning, which might help, but I am not sure. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 01:40:03 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 21 Jun 2016 05:40:03 +0000 Subject: [issue27359] OrderedDict pseudo-literals (WIP) In-Reply-To: <1466475427.25.0.285635253324.issue27359@psf.upfronthosting.co.za> Message-ID: <1466487603.51.0.823798078032.issue27359@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: rhettinger -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 01:43:38 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 21 Jun 2016 05:43:38 +0000 Subject: [issue13376] readline: pre_input_hook not getting called In-Reply-To: <1320825555.41.0.989618903693.issue13376@psf.upfronthosting.co.za> Message-ID: <1466487818.17.0.956498514327.issue13376@psf.upfronthosting.co.za> Martin Panter added the comment: Surely this should be fixed in Editline, not Python? ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 01:52:48 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 21 Jun 2016 05:52:48 +0000 Subject: [issue10415] readline.insert_text documentation incomplete In-Reply-To: <1289718734.94.0.0887962692453.issue10415@psf.upfronthosting.co.za> Message-ID: <1466488368.08.0.378519919803.issue10415@psf.upfronthosting.co.za> Martin Panter added the comment: In Issue 6953, I updated the documentation to indicate which underlying Readline functions etc are accessed. So perhaps that helps, so the reader knows what function to look up in the Readline documentation. Other than that, I?m not sure what else to do. It would be more helpful to suggest an improvement, rather than just quoting the existing documentation back. ---------- nosy: +martin.panter stage: -> needs patch status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 02:07:52 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 21 Jun 2016 06:07:52 +0000 Subject: [issue19613] test_nntplib: sporadic failures, test_article_head_body() In-Reply-To: <1384536645.9.0.862907413915.issue19613@psf.upfronthosting.co.za> Message-ID: <1466489272.91.0.678423161872.issue19613@psf.upfronthosting.co.za> Martin Panter added the comment: I presume the original report was due to testing when the server happened to return an article with an empty body. The failing test is # XXX this could exceptionally happen... self.assertNotIn(article.lines[-1], (b".", b".\n", b".\r\n")) The test code already admits that what it is testing cannot be guaranteed (an article body could end with a full stop). And we have found another case where the test is not valid (an article with zero lines). I say remove this part of the test, at least when testing the article() and body() methods. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 02:24:07 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 21 Jun 2016 06:24:07 +0000 Subject: [issue1690201] Added support for custom readline functions Message-ID: <1466490247.54.0.874394459695.issue1690201@psf.upfronthosting.co.za> Martin Panter added the comment: See also Issue 1175004, proposing the same sort of custom function, but called ?py_callback?. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 03:22:59 2016 From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=) Date: Tue, 21 Jun 2016 07:22:59 +0000 Subject: [issue26090] More correct string truncating in PyUnicode_FromFormat() In-Reply-To: <1452592454.92.0.0368970992087.issue26090@psf.upfronthosting.co.za> Message-ID: <1466493779.9.0.38537285045.issue26090@psf.upfronthosting.co.za> Changes by Adam Barto? : ---------- nosy: +Drekin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 04:22:50 2016 From: report at bugs.python.org (David Delassus) Date: Tue, 21 Jun 2016 08:22:50 +0000 Subject: [issue27360] _deque and _islice are sometimes None Message-ID: <1466497370.43.0.610992999114.issue27360@psf.upfronthosting.co.za> New submission from David Delassus: With Python 3.4.3-r1 (on Gentoo x86_64), I have encountered a strange behavior with the library "riak==2.5.3". When closing the client connection, the library calls ``self._stop.set()`` where ``self._stop`` is a ``threading.Event``. The following error is raised (sometimes): ``` Exception ignored in: > Traceback (most recent call last): File "/home/linkdd/devel/projects/link-framework/venv3/lib/python3.4/site-packages/riak/client/multi.py", line 110, in __del__ File "/home/linkdd/devel/projects/link-framework/venv3/lib/python3.4/site-packages/riak/client/multi.py", line 97, in stop File "/usr/lib64/python3.4/threading.py", line 518, in set File "/usr/lib64/python3.4/threading.py", line 360, in notify_all File "/usr/lib64/python3.4/threading.py", line 343, in notify TypeError: 'NoneType' object is not callable ``` When going in the ``threading`` module, I have found the following line: ``` waiters_to_notify = _deque(_islice(all_waiters, n)) ``` I added just before: ``` print(_deque, _islice, all_waiters, n) ``` Just to see that ``_deque`` and ``_islice`` are both **None**. They are imported from the modules ``collections`` and ``itertools`` correctly though. ---------- components: Library (Lib) messages: 268974 nosy: linkdd priority: normal severity: normal status: open title: _deque and _islice are sometimes None type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 04:59:40 2016 From: report at bugs.python.org (Eric Sprigg) Date: Tue, 21 Jun 2016 08:59:40 +0000 Subject: [issue27361] ValueError on eval after 'from pandas import *' Message-ID: <1466499580.5.0.314875374842.issue27361@psf.upfronthosting.co.za> New submission from Eric Sprigg: Using 'from pandas import *' leads to a ValueError exception being raised when eval tries to execute an expression like eval("df['Country'] == 'Brazil'") When the alternative form 'import pandas' is used, the expression evaluates as expected. The test program in the attached file demonstrates the problem. I use anaconda with Python 3.4.4 on OS X 10.11.5 ---------- components: Interpreter Core files: eval problem.ipynb messages: 268975 nosy: espri priority: normal severity: normal status: open title: ValueError on eval after 'from pandas import *' type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file43496/eval problem.ipynb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 05:23:25 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 21 Jun 2016 09:23:25 +0000 Subject: [issue25259] readline macros can segfault Python In-Reply-To: <1443473589.61.0.823349470149.issue25259@psf.upfronthosting.co.za> Message-ID: <1466501005.64.0.0287147272156.issue25259@psf.upfronthosting.co.za> STINNER Victor added the comment: "I can make the example from the Readline documentation ... crash the same way that Python does." Hum, so maybe the bug should be reported to readline, no? http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html#Bugs ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 05:25:34 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 21 Jun 2016 09:25:34 +0000 Subject: [issue15730] Silence unused value warnings under Mac OS X 10.8/clang In-Reply-To: <1345423593.46.0.41871412241.issue15730@psf.upfronthosting.co.za> Message-ID: <1466501134.0.0.833883571262.issue15730@psf.upfronthosting.co.za> Martin Panter added the comment: Revisions 12e53abec5d0 and 0c7fff783b32 look like they do the same thing as Benno?s patch. Perhaps we can close this? ---------- nosy: +martin.panter resolution: -> out of date _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 05:26:32 2016 From: report at bugs.python.org (SilentGhost) Date: Tue, 21 Jun 2016 09:26:32 +0000 Subject: [issue27361] ValueError on eval after 'from pandas import *' In-Reply-To: <1466499580.5.0.314875374842.issue27361@psf.upfronthosting.co.za> Message-ID: <1466501192.6.0.114612865484.issue27361@psf.upfronthosting.co.za> SilentGhost added the comment: Pandas is not part of the standard library. Their issue tracker is at https://github.com/pydata/pandas/issues ---------- nosy: +SilentGhost resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 05:38:29 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 21 Jun 2016 09:38:29 +0000 Subject: [issue24137] Force not using _default_root in IDLE In-Reply-To: <1430925977.27.0.721479362057.issue24137@psf.upfronthosting.co.za> Message-ID: <1466501909.43.0.284300695894.issue24137@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I made htest run without default root, just list test_idel, and found a few more. I grepped for 'Toplevel()'. Also for bad Tk() calls. I still need to move the call in pyshell and check this over. But I think it close. ---------- Added file: http://bugs.python.org/file43497/nodefaultroot3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 05:40:36 2016 From: report at bugs.python.org (SilentGhost) Date: Tue, 21 Jun 2016 09:40:36 +0000 Subject: [issue27360] _deque and _islice are sometimes None In-Reply-To: <1466497370.43.0.610992999114.issue27360@psf.upfronthosting.co.za> Message-ID: <1466502036.26.0.218214458814.issue27360@psf.upfronthosting.co.za> SilentGhost added the comment: This seems to have been reported on riak's tracker: https://github.com/basho/riak-python-client/issues/449 ---------- nosy: +SilentGhost resolution: -> third party stage: -> resolved status: open -> closed type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 06:14:40 2016 From: report at bugs.python.org (Steve Piercy) Date: Tue, 21 Jun 2016 10:14:40 +0000 Subject: [issue27285] Document the deprecation of pyvenv in favor of `python3 -m venv` In-Reply-To: <1465544944.16.0.549761687921.issue27285@psf.upfronthosting.co.za> Message-ID: <1466504080.83.0.992014343371.issue27285@psf.upfronthosting.co.za> Steve Piercy added the comment: I'd like to take on this issue and submit a patch for consideration by 2016-06-26. Please let me know if anyone is working on it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 06:50:57 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 21 Jun 2016 10:50:57 +0000 Subject: [issue22463] Warnings when building on AIX In-Reply-To: <1411407169.47.0.841951681699.issue22463@psf.upfronthosting.co.za> Message-ID: <1466506257.2.0.251977804249.issue22463@psf.upfronthosting.co.za> Martin Panter added the comment: The most serious of these IMO is the signed overflow warnings in Modules/cPickle.c. I get the same warnings if I disable the ?gcc -fwrapv? mode: /media/disk/home/proj/python/cpython/Modules/cPickle.c: In function ?Unpickler_noload?: /media/disk/home/proj/python/cpython/Modules/cPickle.c:5462:1: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false [-Wstrict-overflow] Unpickler_noload(Unpicklerobject *self, PyObject *unused) ^ /media/disk/home/proj/python/cpython/Modules/cPickle.c:5462:1: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false [-Wstrict-overflow] /media/disk/home/proj/python/cpython/Modules/cPickle.c:202:8: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false [-Wstrict-overflow] if (clearto >= self->length) return 0; ^ /media/disk/home/proj/python/cpython/Modules/cPickle.c:202:8: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false [-Wstrict-overflow] if (clearto >= self->length) return 0; ^ It is not clear to me where the overflows actually happen. See Issue 1608, Issue 1621, where some of these bugs were fixed, and the ?gcc -fwrapv? workaround was enabled. Perhaps your compiler has a similar flag to use as a workaround, though IMO it would be good to fix the code as well. Most of the other warnings have been fixed or worked around in Python 3. I propose to port the following revisions to Python 2. All but one are still in effect today: 83a55ca935f0: Parser/pgen.c 12e53abec5d0, 0c7fff783b32: Include/objimpl.h ce9f5ce33ad2: Modules/readline.c a7a9e0f46b8a: Modules/tkappinit.c (change present in 3.3, 3.4, but eliminated in 3.5) e2f96bd29252 (partial): Modules/_ctypes/cfield.c b04557ae099a (partial): Modules/expat/xmlparse.c (assuming this was the cause of the ./pyconfig.h warnings) That leaves the two warnings about CTYPES_CAPSULE_WCHAR_T. If necessary, they could be worked around by adding an #if condition around the definitions: #if defined(CTYPES_UNICODE) && !defined(HAVE_USABLE_WCHAR_T) # define CTYPES_CAPSULE_WCHAR_T "_ctypes/[. . .].c wchar_t buffer from unicode" CTYPES_CAPSULE_INSTANTIATE_DESTRUCTOR(CTYPES_CAPSULE_WCHAR_T) #endif ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 06:54:53 2016 From: report at bugs.python.org (Upendra Kumar) Date: Tue, 21 Jun 2016 10:54:53 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1466506493.81.0.952323203784.issue27051@psf.upfronthosting.co.za> Upendra Kumar added the comment: Hey, can anyone help me with this code : ################################################################### Python 3.4.3 (default, Oct 14 2015, 20:33:09) [GCC 4.8.4] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import pip >>> pip.main(["install","-U","wheel"]) Requirement already up-to-date: wheel in /usr/local/lib/python3.4/dist-packages Cleaning up... 0 >>> pip.main(["install","-U","timingwheel"]) Downloading/unpacking timingwheel Downloading/unpacking timingwheel Downloading timingwheel-0.4.tar.gz Downloading timingwheel-0.4.tar.gz Running setup.py (path:/tmp/pip_build_scorpio/timingwheel/setup.py) egg_info for package timingwheel Running setup.py (path:/tmp/pip_build_scorpio/timingwheel/setup.py) egg_info for package timingwheel Traceback (most recent call last): Traceback (most recent call last): File "", line 17, in File "", line 17, in File "/tmp/pip_build_scorpio/timingwheel/setup.py", line 3, in File "/tmp/pip_build_scorpio/timingwheel/setup.py", line 3, in from timingwheel import version from timingwheel import version File "/tmp/pip_build_scorpio/timingwheel/timingwheel/__init__.py", line 1, in File "/tmp/pip_build_scorpio/timingwheel/timingwheel/__init__.py", line 1, in from timingwheel import BaseWheel, TimingWheel from timingwheel import BaseWheel, TimingWheel ImportError: cannot import name 'BaseWheel' ImportError: cannot import name 'BaseWheel' Complete output from command python setup.py egg_info: Complete output from command python setup.py egg_info: Traceback (most recent call last): File "", line 17, in File "/tmp/pip_build_scorpio/timingwheel/setup.py", line 3, in from timingwheel import version File "/tmp/pip_build_scorpio/timingwheel/timingwheel/__init__.py", line 1, in from timingwheel import BaseWheel, TimingWheel ImportError: cannot import name 'BaseWheel' ---------------------------------------- Traceback (most recent call last): File "", line 17, in File "/tmp/pip_build_scorpio/timingwheel/setup.py", line 3, in from timingwheel import version File "/tmp/pip_build_scorpio/timingwheel/timingwheel/__init__.py", line 1, in from timingwheel import BaseWheel, TimingWheel ImportError: cannot import name 'BaseWheel' ---------------------------------------- Cleaning up... Cleaning up... Command python setup.py egg_info failed with error code 1 in /tmp/pip_build_scorpio/timingwheel Command python setup.py egg_info failed with error code 1 in /tmp/pip_build_scorpio/timingwheel Storing debug log for failure in /home/scorpio/.pip/pip.log Storing debug log for failure in /home/scorpio/.pip/pip.log 1 ############################################################### ############################################################### In the above failure, pip install functionality fails. I don't know why. Other functionalities like "search" and "list" works perfectly. But, when I tried to connect this pip install command with my GUI button, I got the above error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 07:38:06 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 21 Jun 2016 11:38:06 +0000 Subject: [issue22463] Warnings when building on AIX In-Reply-To: <1411407169.47.0.841951681699.issue22463@psf.upfronthosting.co.za> Message-ID: <1466509086.19.0.669934658656.issue22463@psf.upfronthosting.co.za> Martin Panter added the comment: Looking closer at cPickle.c (after upgrading my GCC), I think there are two warnings happening, when Pdata_clear() is inlined into each of noload_reduce() and noload_setitem(). I think both cases are false positives; there is no actual signed overflow possible. Ismail Donmez has provided patches that work around this warning in Issue 1621, but IMO, and maybe in the general consensus, we shouldn?t add these workarounds. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 08:36:36 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 21 Jun 2016 12:36:36 +0000 Subject: [issue14826] urlopen URL with unescaped space In-Reply-To: <1337158473.64.0.398540003062.issue14826@psf.upfronthosting.co.za> Message-ID: <1466512596.31.0.54699417408.issue14826@psf.upfronthosting.co.za> Martin Panter added the comment: I think this should be treated as a feature, not a bug, since as Christian said, the documentation currently does not support this case. ---------- title: urllib2.urlopen fails to load URL -> urlopen URL with unescaped space type: -> enhancement versions: +Python 3.6 -Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 08:37:51 2016 From: report at bugs.python.org (Upendra Kumar) Date: Tue, 21 Jun 2016 12:37:51 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1466512671.33.0.92986428138.issue27051@psf.upfronthosting.co.za> Upendra Kumar added the comment: Sorry for trouble. I think I messed up with my Python installation. I reinstalled Python and pip. The "pip install command issue" is fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 08:43:11 2016 From: report at bugs.python.org (Petr Viktorin) Date: Tue, 21 Jun 2016 12:43:11 +0000 Subject: [issue27201] expose the ABI name as a config variable In-Reply-To: <1464993442.58.0.656419844053.issue27201@psf.upfronthosting.co.za> Message-ID: <1466512991.15.0.386027058296.issue27201@psf.upfronthosting.co.za> Changes by Petr Viktorin : ---------- nosy: +encukou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 08:45:53 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 21 Jun 2016 12:45:53 +0000 Subject: [issue24364] Not all defects pass through email policy In-Reply-To: <1433263153.11.0.33312264244.issue24364@psf.upfronthosting.co.za> Message-ID: <1466513153.65.0.0302696371061.issue24364@psf.upfronthosting.co.za> R. David Murray added the comment: test_email/test_email tests the compat32 policy. test_defect_handling tests the default policy. Thus they are not redundant, except of course that they are...it would be better to run the same test with both policies in turn, but I never got as far as setting up that infrastructure. That said, for defects it may not matter, and for the other "redudant" tests sometimes the result is different, which is the point of the new policy. So, things are in a bit of a limbo currently and could use some sorting out. You'll note that in some cases in test_email I've noted where the corresponding test for the new policy is in the new test files. There are a bunch more tests in test_email that need equivalents for the new policies (and I'm sure we'll find some bugs when that happens, unfortunately). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 08:58:01 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 21 Jun 2016 12:58:01 +0000 Subject: [issue26290] fileinput and 'for line in sys.stdin' do strange mockery of input buffering In-Reply-To: <1454639426.39.0.789860369492.issue26290@psf.upfronthosting.co.za> Message-ID: <1466513881.07.0.926573782388.issue26290@psf.upfronthosting.co.za> Martin Panter added the comment: Issue 15068 as been fixed in 3.5+ and 2.7, and it looks like it fixes the fileinput aspect of this bug. That leaves the sys.stdin aspect, which only affects Python 2, and I think is a duplicate of Issue 1633941. ---------- nosy: +martin.panter resolution: -> duplicate status: open -> closed superseder: -> for line in sys.stdin: doesn't notice EOF the first time versions: +Python 3.5, Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 09:03:20 2016 From: report at bugs.python.org (Demur Rumed) Date: Tue, 21 Jun 2016 13:03:20 +0000 Subject: [issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow In-Reply-To: <1466473561.23.0.768330028286.issue27358@psf.upfronthosting.co.za> Message-ID: <1466514200.62.0.956318976492.issue27358@psf.upfronthosting.co.za> Demur Rumed added the comment: mapaca2 heavy handily deals with the must-work-with-all-mappings by converting any non dict mappings on the stack with dicts when with_call is true I'm not sure if it'd be better to seek a less opcode centric fix-- ie introduce a method to dictobject which returns None if no collision occurs otherwise it returns the first key which collides and stops updating at that point. PyDict_DistinctUpdate ---------- Added file: http://bugs.python.org/file43498/mapaca2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 09:05:39 2016 From: report at bugs.python.org (Demur Rumed) Date: Tue, 21 Jun 2016 13:05:39 +0000 Subject: [issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow In-Reply-To: <1466473561.23.0.768330028286.issue27358@psf.upfronthosting.co.za> Message-ID: <1466514339.71.0.784280763752.issue27358@psf.upfronthosting.co.za> Demur Rumed added the comment: (returning None wouldn't work because that may be the key, but something like returning the dict itself (ie an unhashable) or keeping this as a C API & returning NULL would work) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 09:09:18 2016 From: report at bugs.python.org (Daniel Ward) Date: Tue, 21 Jun 2016 13:09:18 +0000 Subject: [issue27362] json.dumps to check for obj.__json__ before raising TypeError Message-ID: <1466514558.58.0.537455774899.issue27362@psf.upfronthosting.co.za> New submission from Daniel Ward: To help prevent retrospective JSONEncoder overrides when failing to serialize a given object, the intention of this issue is to propose that the JSON encoder checks if a given object has a __json__ attribute, using that rather than raising a TypeError. This will help in maintaining easier-to-follow code and keeps the responsibility of determining how an object should be represented in JSON objects firmly within the object itself. The obj.__json__ callable/attribute should behave in the same way as __repr__ or __str__, for example. I'm happy to look in to contributing this enhancement myself if that's preferred. Any pointers as to how I go about contributing are greatly appreciated. ---------- components: Library (Lib) messages: 268991 nosy: Daniel Ward priority: normal severity: normal status: open title: json.dumps to check for obj.__json__ before raising TypeError type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 09:15:19 2016 From: report at bugs.python.org (Emanuel Barry) Date: Tue, 21 Jun 2016 13:15:19 +0000 Subject: [issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow In-Reply-To: <1466473561.23.0.768330028286.issue27358@psf.upfronthosting.co.za> Message-ID: <1466514919.04.0.866435460311.issue27358@psf.upfronthosting.co.za> Emanuel Barry added the comment: `dict` subclasses can be hashable - it's a very bad idea, but not guarded against. If you were to do this, I'd suggest going the exception way, ? la StopIteration. I wonder how feasible it would be for e.g. dict.__setitem__ to check if a key already exists; it would be a special path that's not taken normally, but filling the mapping on call enables it, and it raises if it sees a duplicate. I think that inserting the check in there would reduce complexity and probably have a negligible impact on performance. I don't know if that's a good idea, just throwing this out here. ---------- nosy: +ebarry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 09:19:55 2016 From: report at bugs.python.org (Emanuel Barry) Date: Tue, 21 Jun 2016 13:19:55 +0000 Subject: [issue27362] json.dumps to check for obj.__json__ before raising TypeError In-Reply-To: <1466514558.58.0.537455774899.issue27362@psf.upfronthosting.co.za> Message-ID: <1466515195.07.0.204574183216.issue27362@psf.upfronthosting.co.za> Emanuel Barry added the comment: I'm not too familiar with the json package, but what should __json__ return when called? ---------- nosy: +ebarry stage: -> test needed versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 09:21:28 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 21 Jun 2016 13:21:28 +0000 Subject: [issue26990] file.tell affect decoding In-Reply-To: <1462851273.73.0.390821132844.issue26990@psf.upfronthosting.co.za> Message-ID: <1466515288.52.0.786882515638.issue26990@psf.upfronthosting.co.za> Martin Panter added the comment: See also the second part of Issue 25863, a similar symptom with the iso-2022-jp codec. I suspect many of the multibyte CJK type codecs don?t properly support saving and restoring their state. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 09:32:49 2016 From: report at bugs.python.org (Daniel Ward) Date: Tue, 21 Jun 2016 13:32:49 +0000 Subject: [issue27362] json.dumps to check for obj.__json__ before raising TypeError In-Reply-To: <1466514558.58.0.537455774899.issue27362@psf.upfronthosting.co.za> Message-ID: <1466515969.96.0.483864181864.issue27362@psf.upfronthosting.co.za> Daniel Ward added the comment: Sure, so for example: ========= import json class ObjectCounter: def __init__(self, name, count): self.name = name self.count = count def __json__(self): return '[{name}] {count}'.format(name=self.name, count=self.count) object_counter = ObjectCounter('DC1', 3789) my_json_string = json.dumps({'success': True, 'counter': object_counter}) ============ In the above example, the value stored in my_json_string would be: '{"success": true, "counter": "[DC1] 3789"}' This is an untested and quick example, but I hope it explains what I'm aiming to achieve. Without the __json__ method, the json.dumps call would raise an exception along the lines of the below message, unless we create a new JSONEncoder object and call json.dumps(..., cls=MyJSONEncoder), which becomes difficult to manage and follow on larger projects. TypeError: is not JSON serializable ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 09:38:39 2016 From: report at bugs.python.org (David Edelsohn) Date: Tue, 21 Jun 2016 13:38:39 +0000 Subject: [issue22463] Warnings when building on AIX In-Reply-To: <1411407169.47.0.841951681699.issue22463@psf.upfronthosting.co.za> Message-ID: <1466516319.45.0.605818668926.issue22463@psf.upfronthosting.co.za> David Edelsohn added the comment: These look like false positives or noise to me as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 09:42:31 2016 From: report at bugs.python.org (Ollie Ford) Date: Tue, 21 Jun 2016 13:42:31 +0000 Subject: [issue27362] json.dumps to check for obj.__json__ before raising TypeError In-Reply-To: <1466514558.58.0.537455774899.issue27362@psf.upfronthosting.co.za> Message-ID: <1466516551.23.0.492768534219.issue27362@psf.upfronthosting.co.za> Changes by Ollie Ford : ---------- nosy: +Ollie Ford _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 09:43:10 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Jun 2016 13:43:10 +0000 Subject: [issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow In-Reply-To: <1466473561.23.0.768330028286.issue27358@psf.upfronthosting.co.za> Message-ID: <1466516590.47.0.552105966321.issue27358@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think this kills the optimization effect for non-dicts. See on PyDict_Merge(). It takes the boolean parameter that controls the behavior in case of matching keys. I think the best would be to rename it to say _PyDict_MergeEx(), extend the boolean parameter to ternary parameter, and raise an exception if it is in the third state and matching keys are found. PyDict_Merge() would be implemented as a simple wrapper around _PyDict_MergeEx(). We should check wherever this affects the performance of dict.update(). ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 09:44:38 2016 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 21 Jun 2016 13:44:38 +0000 Subject: [issue10116] Sporadic failures in test_urllibnet In-Reply-To: <1287150282.16.0.127032822399.issue10116@psf.upfronthosting.co.za> Message-ID: <1466516678.76.0.315653217734.issue10116@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 09:45:11 2016 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 21 Jun 2016 13:45:11 +0000 Subject: [issue19613] test_nntplib: sporadic failures, test_article_head_body() In-Reply-To: <1384536645.9.0.862907413915.issue19613@psf.upfronthosting.co.za> Message-ID: <1466516711.82.0.662742108362.issue19613@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 09:50:26 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Jun 2016 13:50:26 +0000 Subject: [issue27213] Rework CALL_FUNCTION* opcodes In-Reply-To: <1465026334.02.0.369802561902.issue27213@psf.upfronthosting.co.za> Message-ID: <1466517026.69.0.913571206344.issue27213@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Issue27358 is too complex, more complex than this issue. But I think the simple fix the regression in case of the single **kw is checking wherever the sum dict is empty. - if (with_call) { + if (with_call && PyDict_Size(sum)) { ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 09:53:25 2016 From: report at bugs.python.org (Emanuel Barry) Date: Tue, 21 Jun 2016 13:53:25 +0000 Subject: [issue27362] json.dumps to check for obj.__json__ before raising TypeError In-Reply-To: <1466514558.58.0.537455774899.issue27362@psf.upfronthosting.co.za> Message-ID: <1466517205.92.0.967457294736.issue27362@psf.upfronthosting.co.za> Emanuel Barry added the comment: So __json__ returns a string meant to be serializable. I'm not too keen on using a dunder name (although my word doesn't weigh anything ;) and I'd personally prefer something like as_json_string(). I think the idea in general is good, though. Mind submitting a patch? ---------- stage: test needed -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 10:03:34 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 21 Jun 2016 14:03:34 +0000 Subject: [issue20631] python readline module crashing on NULL access In-Reply-To: <1392423131.28.0.0178138253347.issue20631@psf.upfronthosting.co.za> Message-ID: <1466517814.87.0.85252656092.issue20631@psf.upfronthosting.co.za> Martin Panter added the comment: I think an answer to Benjamin?s question is necessary to move this forward. The code already checks the index before calling history_get(). How do you manage to get null pointers returned for every history item? In the LLVM bug thread, I noticed ?libedit? a.k.a. Editline mentioned a few times. Are you sure Python is using Gnu Readline, or is it somehow hooking into Editline? Python only really supports Editline on Apple, not Linux (see Issue 13501 for expanding that support). ---------- nosy: +martin.panter status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 10:22:33 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 21 Jun 2016 14:22:33 +0000 Subject: [issue9156] socket._fileobject: read raises AttributeError when closed in another thread In-Reply-To: <1278292895.39.0.187416203103.issue9156@psf.upfronthosting.co.za> Message-ID: <1466518953.44.0.505864969463.issue9156@psf.upfronthosting.co.za> Martin Panter added the comment: IMO closing an OS-level file descriptor in one thread while it is in use by another thread is a bad idea, full of race conditions and undefined behaviour. An AttributeError sounds like a best-case scenario. It is like freeing a memory allocation in one thread while another thread is accessing the memory. What if the other thread was slow, or a syscall was interrupted, and hasn?t (re-)started the recv() call in time? What if a third thread opens a file and reuses the file descriptor you just closed? I suggest to close this. ---------- nosy: +martin.panter resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 10:43:11 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Tue, 21 Jun 2016 14:43:11 +0000 Subject: [issue27362] json.dumps to check for obj.__json__ before raising TypeError In-Reply-To: <1466514558.58.0.537455774899.issue27362@psf.upfronthosting.co.za> Message-ID: <1466520191.29.0.181236194348.issue27362@psf.upfronthosting.co.za> Steven D'Aprano added the comment: For starters, dunder names like __json__ are reserved for Python's own use, so you would have to get the core developers to officially bless this use. But... I'm not really sure that "the responsibility of determining how an object should be represented in JSON objects firmly within the object itself" is a good idea. For a general purpose protocol, I don't think you can trust any object to return valid JSON. What if my object.__json__ returned "}key='c" or some other invalid string? Whose responsibility is it to check that __json__ returns valid JSON? I don't think there is any need to make this an official protocol. You know your own objects, you know if you can trust them, and you can call any method you like. So your example becomes: my_json_string = json.dumps( {'success': True, 'counter': object_counter.to_json()}) which is okay because that's clearly *your* responsibility to make sure that your object's to_json method returns a valid string. If you make it an official language wide protocol, it's unclear whose responsibility it is: the object (dangerous!), the caller (difficult), the Python interpreter (unlikely), json.dumps (unlikely). ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 10:47:30 2016 From: report at bugs.python.org (Daniel Ward) Date: Tue, 21 Jun 2016 14:47:30 +0000 Subject: [issue27362] json.dumps to check for obj.__json__ before raising TypeError In-Reply-To: <1466514558.58.0.537455774899.issue27362@psf.upfronthosting.co.za> Message-ID: <1466520450.91.0.458526850149.issue27362@psf.upfronthosting.co.za> Daniel Ward added the comment: I don't think I explained the response very well, effectively the __json__ call would return an object which is JSON-serializable. This would include dict objects containing JSON-serializable objects albeit natively-supporting JSON serialisation or by means of subsequent obj.__json__ calls. The reason I gave it __json__ is purely for easily-remembered implementation, separating it out from calls which may potentially clash with existing codebases, because let's face it, people don't often get to start again ;) I'm not adverse to changing the method name at all, but I do believe this is a progressive way to go regarding JSON-serialization. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 11:38:46 2016 From: report at bugs.python.org (INADA Naoki) Date: Tue, 21 Jun 2016 15:38:46 +0000 Subject: [issue27350] Compact and ordered dict In-Reply-To: <1466307796.29.0.980579044792.issue27350@psf.upfronthosting.co.za> Message-ID: <1466523526.6.0.803102988223.issue27350@psf.upfronthosting.co.za> INADA Naoki added the comment: As I posted to python-dev ML, this compact ordered dict doesn't keep insertion order for key-shared dict. >>> class A: ... ... ... >>> a = A() >>> b = A() >>> a.a = 1 >>> a.b = 2 >>> b.b = 3 >>> b.a = 4 >>> a.__dict__.items() dict_items([('a', 1), ('b', 2)]) >>> b.__dict__.items() dict_items([('a', 4), ('b', 3)]) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 11:41:29 2016 From: report at bugs.python.org (Brett Cannon) Date: Tue, 21 Jun 2016 15:41:29 +0000 Subject: [issue27285] Document the deprecation of pyvenv in favor of `python3 -m venv` In-Reply-To: <1465544944.16.0.549761687921.issue27285@psf.upfronthosting.co.za> Message-ID: <1466523689.7.0.667827046996.issue27285@psf.upfronthosting.co.za> Brett Cannon added the comment: No one is working on it, Steve, so feel free to write a patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 11:59:21 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 21 Jun 2016 15:59:21 +0000 Subject: [issue27309] Visual Styles support to tk/tkinter file and message dialogs In-Reply-To: <1465855196.42.0.576274211307.issue27309@psf.upfronthosting.co.za> Message-ID: <1466524761.75.0.780880043599.issue27309@psf.upfronthosting.co.za> Steve Dower added the comment: If someone wants to make a patch, the manifest we embed is in PC/python.manifest ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 12:16:03 2016 From: report at bugs.python.org (Zachary Ware) Date: Tue, 21 Jun 2016 16:16:03 +0000 Subject: [issue27309] Visual Styles support to tk/tkinter file and message dialogs In-Reply-To: <1465855196.42.0.576274211307.issue27309@psf.upfronthosting.co.za> Message-ID: <1466525763.57.0.677518155853.issue27309@psf.upfronthosting.co.za> Zachary Ware added the comment: I wonder whether this manifest change would affect other GUI toolkit packages (though frankly I'm having trouble finding any others that work with Python 3 on Windows...), positively or negatively. Would it be possible to tie this to _tkinter.pyd instead of python{w}.exe? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 12:27:23 2016 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 21 Jun 2016 16:27:23 +0000 Subject: [issue27353] Add nroot function to math In-Reply-To: <1466382160.58.0.562689353089.issue27353@psf.upfronthosting.co.za> Message-ID: <1466526443.02.0.0208423287981.issue27353@psf.upfronthosting.co.za> Mark Dickinson added the comment: [Raymond, quoting Matlab] > in cases where both real and complex roots exist, power returns only the complex roots. Yes, this would be the main motivation for me, too, if only to be able to answer the many StackOverflow questions like this one: http://stackoverflow.com/questions/30923838/how-to-get-the-real-cube-root-of-a-negative-number-in-python3 +1 for a private function in the statistics module for now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 12:33:59 2016 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 21 Jun 2016 16:33:59 +0000 Subject: [issue27353] Add nroot function to math In-Reply-To: <1466382160.58.0.562689353089.issue27353@psf.upfronthosting.co.za> Message-ID: <1466526839.72.0.0664614422904.issue27353@psf.upfronthosting.co.za> Mark Dickinson added the comment: [Serhiy] > ... nroot() wouldn't help too much to implement geometric mean It's fine, so long as it's only being called once or twice at the end of the calculation (it's even helpful to have the last operation be an nth root call, since that's a contracting operation that tends to reduce relative error). It's calling it on every single item in the input list and *then* multiplying that would be bad. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 12:56:34 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 21 Jun 2016 16:56:34 +0000 Subject: [issue27309] Visual Styles support to tk/tkinter file and message dialogs In-Reply-To: <1465855196.42.0.576274211307.issue27309@psf.upfronthosting.co.za> Message-ID: <1466528194.73.0.363459963879.issue27309@psf.upfronthosting.co.za> Steve Dower added the comment: > Would it be possible to tie this to _tkinter.pyd instead of python{w}.exe? Afraid not, Windows needs to load a different version of a particular DLL for the entire process. But at this stage it shouldn't negatively affect anyone. I'd even be okay adding it into 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 13:04:53 2016 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 21 Jun 2016 17:04:53 +0000 Subject: [issue27350] Compact and ordered dict In-Reply-To: <1466307796.29.0.980579044792.issue27350@psf.upfronthosting.co.za> Message-ID: <1466528693.23.0.57216865801.issue27350@psf.upfronthosting.co.za> Mark Dickinson added the comment: > I found PY_INT32_T in pyport.h. It seems only available when stdint.h is available. That doesn't sound right. It should be available always. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 13:10:47 2016 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 21 Jun 2016 17:10:47 +0000 Subject: [issue27350] Compact and ordered dict In-Reply-To: <1466307796.29.0.980579044792.issue27350@psf.upfronthosting.co.za> Message-ID: <1466529047.92.0.445379518776.issue27350@psf.upfronthosting.co.za> Mark Dickinson added the comment: > That doesn't sound right. It should be available always. To elaborate: assuming not Windows, the configure script has two checks: if AC_CHECK_TYPE(int32_t, ...) succeeds (which should happen whenever int32_t is defined in either stdint.h or inttypes.h), it #defines HAVE_INT32_T. If AC_TYPE_INT32_T succeeds (which should happen whenever int32_t is *not* defined in either stdint.h or inttypes.h), it #defines int32_t to be a suitable type. Then the pyport check makes sure than in both circumstances, PY_INT32_T is #defined. I don't believe there are any platforms out there that we care about for Python for which both checks fail. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 15:02:08 2016 From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=) Date: Tue, 21 Jun 2016 19:02:08 +0000 Subject: [issue27363] Complex with negative zero imaginary part Message-ID: <1466535728.31.0.514028528898.issue27363@psf.upfronthosting.co.za> New submission from Vedran ?a?i?: Look: >>> complex('1-0j') (1-0j) >>> 1-0j (1+0j) Yes, I understand what's going on, and it's probably wrong / too much to expect 1-0j to work properly, but I'd really like the complex from string constructor to be consistent with that. Even more because (of course): >>> import ast >>> ast.literal_eval('1-0j') (1+0j) ---------- messages: 269013 nosy: Vedran.?a?i? priority: normal severity: normal status: open title: Complex with negative zero imaginary part type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 15:27:37 2016 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 21 Jun 2016 19:27:37 +0000 Subject: [issue27363] Complex with negative zero imaginary part In-Reply-To: <1466535728.31.0.514028528898.issue27363@psf.upfronthosting.co.za> Message-ID: <1466537257.85.0.0618133456754.issue27363@psf.upfronthosting.co.za> Mark Dickinson added the comment: This has been discussed in multiple issues before this one. Currently, `complex` from a string provides one of two ways to get a complex number with the correct signs for the real and imaginary parts; I'd hate to change that to give wrong results instead. The other important property here is that `complex(repr(z))` recovers `z` for a complex number `z`. That would break with your suggested change. Strong -1 from me. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 15:38:12 2016 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 21 Jun 2016 19:38:12 +0000 Subject: [issue27363] Complex with negative zero imaginary part In-Reply-To: <1466535728.31.0.514028528898.issue27363@psf.upfronthosting.co.za> Message-ID: <1466537892.1.0.584389391175.issue27363@psf.upfronthosting.co.za> Mark Dickinson added the comment: Related: #17336, #22548, #25839 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 15:43:10 2016 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 21 Jun 2016 19:43:10 +0000 Subject: [issue27172] Add skip_bound_arg argument to inspect.Signature.from_callable() In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za> Message-ID: <1466538190.48.0.488395767392.issue27172@psf.upfronthosting.co.za> Nick Coghlan added the comment: Hi Ryan, sorry for the delayed response. My own concern with this proposal is that I don't understand the use case for it. We changed the inspect.signature behaviour away from that of inspect.getfullargspec because we considered the latter behaviour to be *wrong*: it reported a parameter the already bound method didn't actually accept when called. The "skip_bound_arg" functionality then remains *within* the inspect module for the sake of providing backwards compatible implementations of getargspec and getfullargspec without duplicating a lot of other callable introspection logic. If you can provide more information on the motivating use case, we can better determine if exposing this option directly is a suitable design response, or if there may be better alternatives available. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 15:59:07 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Jun 2016 19:59:07 +0000 Subject: [issue23545] Turn on extra warnings on GCC In-Reply-To: <1425076183.98.0.20319163057.issue23545@psf.upfronthosting.co.za> Message-ID: <1466539147.02.0.14603293452.issue23545@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could anyone please make a review? ---------- versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 16:01:54 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Jun 2016 20:01:54 +0000 Subject: [issue23034] Dynamically control debugging output In-Reply-To: <1418332173.89.0.386427809737.issue23034@psf.upfronthosting.co.za> Message-ID: <1466539314.5.0.355771484477.issue23034@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 16:04:35 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Jun 2016 20:04:35 +0000 Subject: [issue23839] Clear caches after every test In-Reply-To: <1427887841.84.0.393130432881.issue23839@psf.upfronthosting.co.za> Message-ID: <1466539475.71.0.981108659799.issue23839@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 16:10:40 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Jun 2016 20:10:40 +0000 Subject: [issue23591] Add IntFlags In-Reply-To: <1425569483.33.0.144069723147.issue23591@psf.upfronthosting.co.za> Message-ID: <1466539840.62.0.0371396409148.issue23591@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What should be done for landing this in 3.6? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 16:11:57 2016 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 21 Jun 2016 20:11:57 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1466539917.01.0.181086729527.issue27051@psf.upfronthosting.co.za> Nick Coghlan added the comment: Unfortunately, Ned's right in highlighting a potential pip integration problem here: pip DOES NOT expose a supported Python API, but pip_tkinter currently imports APIs from within the pip package. This means that somebody doing "pip install --upgrade pip" may break a version of the GUI that is implemented this way, contradicting our promise that a post-install "pip install --upgrade pip" is a fully supported operation that won't break anything else in CPython. That's 100% fine for a proof of concept that demonstrates the general principle of a Tkinter based package management GUI and it's integration into IDLE (and Upendra's work on that front looks excellent to me), but isn't reasonable for a version that actually lands in CPython as a supported component. Where this work could really help move the "Stable Python API for package management" discussion forward is by providing a clear set of use cases, as well as spelling out the internal pip APIs used to implement that feature in the proof-of-concept, The reason I believe that will be helpful is that one of the big problems in this area to date has been the lack of a clear statement of the problem that a stable Python API would be aimed at solving - "provide a stable API that meets the needs of the default package management GUI shipped with IDLE" is a far more tractable problem than "provide a stable API for pip". ---------- nosy: +dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 16:14:58 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Jun 2016 20:14:58 +0000 Subject: [issue24821] The optimization of string search can cause pessimization In-Reply-To: <1438927886.02.0.407236930114.issue24821@psf.upfronthosting.co.za> Message-ID: <1466540098.38.0.178212916662.issue24821@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 16:15:55 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 21 Jun 2016 20:15:55 +0000 Subject: [issue23545] Turn on extra warnings on GCC In-Reply-To: <1425076183.98.0.20319163057.issue23545@psf.upfronthosting.co.za> Message-ID: <1466540155.97.0.74783357617.issue23545@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 16:33:12 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 21 Jun 2016 20:33:12 +0000 Subject: [issue27362] json.dumps to check for obj.__json__ before raising TypeError In-Reply-To: <1466514558.58.0.537455774899.issue27362@psf.upfronthosting.co.za> Message-ID: <1466541192.87.0.480101854543.issue27362@psf.upfronthosting.co.za> Berker Peksag added the comment: This was discussed on python-ideas before: * https://groups.google.com/forum/#!msg/python-ideas/MbvpK21nUNA/DwYpOFOVuYMJ * https://groups.google.com/forum/#!msg/python-ideas/JVLuo-L0reU/zLNnBa9THqgJ I don't think there was an agreement on the idea so I suggest to send your proposal to python-ideas first. ---------- nosy: +berker.peksag stage: needs patch -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 16:34:21 2016 From: report at bugs.python.org (Emanuel Barry) Date: Tue, 21 Jun 2016 20:34:21 +0000 Subject: [issue27364] Deprecate invalid unicode escape sequences Message-ID: <1466541260.02.0.320668077341.issue27364@psf.upfronthosting.co.za> New submission from Emanuel Barry: Attached patch deprecates invalid escape sequences in unicode strings. The point of this is to prevent issues such as #27356 (and possibly other similar ones) in the future. Without the patch: >>> "hello \world" 'hello \\world' With the patch: >>> "hello \world" DeprecationWarning: invalid escape sequence 'w' I'll need some help (patch isn't mergeable yet): test_doctest fails on my machine with the patch (and -W), and I don't know how to fix it. test_ast fails an assertion (!PyErr_Occurred() in PyObject_Call in abstract.c) when -W is on, and I also don't know how to fix it (I don't even know what causes it). Of course, I went ahead and fixed all instances of invalid escape sequences in the stdlib (that I could find) so that no DeprecationWarning is encountered. Lastly, I thought about also doing this to bytes, but I ran into some issues with some invalid escapes such as \u, and _codecs.escape_decode would trigger the warning when passed br"\8" (for example). Ultimately, I decided to leave bytes alone for now, since it's mostly on the lower-level side of things. If there's interest I can add it back. ---------- components: Interpreter Core, Library (Lib), Unicode files: deprecate_invalid_unicode_escapes.patch keywords: patch messages: 269022 nosy: ebarry, ezio.melotti, haypo priority: normal severity: normal stage: patch review status: open title: Deprecate invalid unicode escape sequences type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file43499/deprecate_invalid_unicode_escapes.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 16:40:12 2016 From: report at bugs.python.org (Ethan Furman) Date: Tue, 21 Jun 2016 20:40:12 +0000 Subject: [issue23591] Add IntFlags In-Reply-To: <1425569483.33.0.144069723147.issue23591@psf.upfronthosting.co.za> Message-ID: <1466541612.26.0.953288985664.issue23591@psf.upfronthosting.co.za> Ethan Furman added the comment: Just look briefly through your patches, and they look pretty good. I'll take a more in-depth look in the next couple weeks. (Feel free to ping again if you don't see any activity from me, and thanks for your patience.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 17:03:56 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 21 Jun 2016 21:03:56 +0000 Subject: [issue18726] json functions have too many positional parameters In-Reply-To: <1376392694.75.0.457946059126.issue18726@psf.upfronthosting.co.za> Message-ID: <20160621210338.27353.1062.D7B1E452@psf.io> Roundup Robot added the comment: New changeset db5fe5c4d09d by Serhiy Storchaka in branch 'default': Issue #18726: All optional parameters of the dump(), dumps(), https://hg.python.org/cpython/rev/db5fe5c4d09d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 17:06:31 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Jun 2016 21:06:31 +0000 Subject: [issue26974] Crash in Decimal.from_float In-Reply-To: <1462684427.76.0.86950702335.issue26974@psf.upfronthosting.co.za> Message-ID: <1466543191.24.0.730818204578.issue26974@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Stefan? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 17:08:54 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Jun 2016 21:08:54 +0000 Subject: [issue27007] Alternate constructors bytes.fromhex() and bytearray.fromhex() return an instance of base type In-Reply-To: <1463040199.11.0.588158577385.issue27007@psf.upfronthosting.co.za> Message-ID: <1466543334.4.0.136387953321.issue27007@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 17:11:23 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Jun 2016 21:11:23 +0000 Subject: [issue27033] Change the decode_data default in smtpd to False In-Reply-To: <1463340039.51.0.670985844702.issue27033@psf.upfronthosting.co.za> Message-ID: <1466543483.07.0.457167979399.issue27033@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Can this issue be closed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 17:22:26 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 21 Jun 2016 21:22:26 +0000 Subject: [issue24137] Force not using _default_root in IDLE In-Reply-To: <1430925977.27.0.721479362057.issue24137@psf.upfronthosting.co.za> Message-ID: <1466544146.17.0.749793488789.issue24137@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Conditioned NoDefaultRoot() on use_subprocess. Ran through menu. Will push soon after rechecking patches with Rietveld. Thanks for the additional review. I don't know that this caught any real bugs in IDLE itself. But many of the htests needed upgrading to consistently use a Toplevel with the exiting root as parent (and never start a second mainloop). Not worth backporting en masse though. ---------- Added file: http://bugs.python.org/file43500/nodefaultroot4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 17:31:25 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 21 Jun 2016 21:31:25 +0000 Subject: [issue26975] Decimal.from_float works incorrectly for non-binary floats In-Reply-To: <1462689945.43.0.203317585545.issue26975@psf.upfronthosting.co.za> Message-ID: <1466544685.0.0.683764720059.issue26975@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I vote for ignoring this and calling it not-a-bug. In a way, it is no more interesting than a dict like object defining __hash__ to return a random number. The intention for from_float() is to convert binary floats. It was not meant to be generalized to handle arbitrary fractions. I concur with Mark's comment, "Note that by overriding as_integer_ratio, you're breaking its "contract"". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 17:58:01 2016 From: report at bugs.python.org (Stefan Krah) Date: Tue, 21 Jun 2016 21:58:01 +0000 Subject: [issue26975] Decimal.from_float works incorrectly for non-binary floats In-Reply-To: <1462689945.43.0.203317585545.issue26975@psf.upfronthosting.co.za> Message-ID: <1466546281.37.0.43873932333.issue26975@psf.upfronthosting.co.za> Stefan Krah added the comment: Let's close it then. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 17:59:59 2016 From: report at bugs.python.org (Carson Lam) Date: Tue, 21 Jun 2016 21:59:59 +0000 Subject: [issue26556] Update expat to 2.1.1 In-Reply-To: <1457951495.3.0.910401967595.issue26556@psf.upfronthosting.co.za> Message-ID: <1466546399.39.0.696784539932.issue26556@psf.upfronthosting.co.za> Changes by Carson Lam : ---------- title: Update expat to 2.2.1 -> Update expat to 2.1.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 18:05:15 2016 From: report at bugs.python.org (Stefan Krah) Date: Tue, 21 Jun 2016 22:05:15 +0000 Subject: [issue26974] Crash in Decimal.from_float In-Reply-To: <1462684427.76.0.86950702335.issue26974@psf.upfronthosting.co.za> Message-ID: <1466546715.46.0.445716967735.issue26974@psf.upfronthosting.co.za> Stefan Krah added the comment: I'll look at it soon -- I just don't have much time right now. ---------- assignee: -> skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 18:39:04 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 21 Jun 2016 22:39:04 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1466548744.63.0.788788812798.issue27051@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I rechecked #23351 and in msg249924 Donald did disclaim any guarantee that using main() would work forever. He suggested instead using subprocess and the command line interface as presumably more stable. In tem_pip_v3.py Upendra switched to using subprocess and I presume he stuck with that in spite of any suggestion otherwise from me. If the pip command line interface is changed, *every* program that uses it could be broken. I agree with Ned that pip_gui should ideally be part of the pip package, I would be happy if Donald were to review what Upendra has and will produce, pronounce it good, and ask to have it for pip. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 18:42:02 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 21 Jun 2016 22:42:02 +0000 Subject: [issue24137] Force not using _default_root in IDLE In-Reply-To: <1430925977.27.0.721479362057.issue24137@psf.upfronthosting.co.za> Message-ID: <20160621224159.10821.79759.6DB8AF2F@psf.io> Roundup Robot added the comment: New changeset 064b29dde096 by Terry Jan Reedy in branch 'default': Issue #24137: Run IDLE, test_idle, and htest with tkinter default root disabled. https://hg.python.org/cpython/rev/064b29dde096 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 18:43:58 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 21 Jun 2016 22:43:58 +0000 Subject: [issue24137] Force not using _default_root in IDLE In-Reply-To: <1430925977.27.0.721479362057.issue24137@psf.upfronthosting.co.za> Message-ID: <1466549038.71.0.150455199571.issue24137@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 Jun 21 19:55:26 2016 From: report at bugs.python.org (Chris Barker) Date: Tue, 21 Jun 2016 23:55:26 +0000 Subject: [issue27198] Adding an assertClose() method to unittest.TestCase In-Reply-To: <1464979712.74.0.398203716413.issue27198@psf.upfronthosting.co.za> Message-ID: <1466553326.29.0.789274471457.issue27198@psf.upfronthosting.co.za> Chris Barker added the comment: Did my comments not get posted, or are they not being read? Anyway: Could we keep the issues separate here? 1) If you don't like the name, propose another name -- no none has defended this name since an objection was first raised. I"m sure we can find one that would work, if we want to add it. 2) regardless of the original intent, the current API: - requires fairly substantial effort to write a new assertion, whether as a method or a function. Thus it's a good idea to provide generally useful ones - has a bunch of assert methods, many of which are no more commonly useful than the proposed method. So adding this is very much in keeping with the current API. However, it seems there is much resistance to adding new asserts to the base TestCase. Fine. I have trouble defending that as I don't like the API anyway (and yes, of course, it comes from Java -- that's actually the source of the problem :-) ) But: this is a generally useful and non-trivial assert (indeed, as way too many people are confused about floating point, I think it's pretty critical to provide appropriate tools -- and assertAlmostEqual is NOT the appropriate tool in many cases. So how to provide this? Options: 1) Robert suggested a stand alone function -- sure, but where to put it? 2) Apparently there is a movement afoot to add a mixin with extra stuff -- sure, that would be fine, but only if there actually is such a mixin. 3) add the functionality to assertAlmostEqual, with a new optional parameter -- I suggested this a few comments back, and have had no feedback. (that at least avoids bike shedding the name...) My key points: 1) This is generally useful and non-trivial -- so would be good to add to the stdlib. 2) it should be discoverable -- as pointed out, folks have not been clamoring for it -- which means they won't know to go digging for it -- they should find it easily (as many folks will use assertAlmostEqual, when they would be better served by this) which leaves us with adding to a library of functions or a mixin, only if such a thing will actually be build and documented, with more than one function it it :-) or adding to assertAlmostEqual. Feedback on this? (note: adding assertClose as is now off the table, no more need to argue about that) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 20:24:20 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 22 Jun 2016 00:24:20 +0000 Subject: [issue27344] zipfile *does* support utf-8 filenames In-Reply-To: <1466176126.21.0.0133629365393.issue27344@psf.upfronthosting.co.za> Message-ID: <1466555060.8.0.858742972459.issue27344@psf.upfronthosting.co.za> R. David Murray added the comment: See issue 10614 for the current state of play. This issue should probably be closed in favor of that one. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 20:34:37 2016 From: report at bugs.python.org (Robert Collins) Date: Wed, 22 Jun 2016 00:34:37 +0000 Subject: [issue27198] Adding an assertClose() method to unittest.TestCase In-Reply-To: <1464979712.74.0.398203716413.issue27198@psf.upfronthosting.co.za> Message-ID: <1466555677.2.0.842094604789.issue27198@psf.upfronthosting.co.za> Robert Collins added the comment: Chris, I suggested altering assertAlmostEqual in http://bugs.python.org/issue27198#msg267187 :) - I took your agreement with that as a good thing and didn't reply because I had nothing more to add. IMO the status of this issue is as you indicated: you needed time to code up the changes, so that its an extension to assertAlmostEquals, rather than a new assertion. When thats done I'll happily review it and commit it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 20:49:29 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 22 Jun 2016 00:49:29 +0000 Subject: [issue22463] Warnings when building on AIX In-Reply-To: <1411407169.47.0.841951681699.issue22463@psf.upfronthosting.co.za> Message-ID: <20160622004925.119651.26241.6B3EA127@psf.io> Roundup Robot added the comment: New changeset 0b63465a1796 by Martin Panter in branch '2.7': Issue #22463: Backport compiler warning fixes and workarounds https://hg.python.org/cpython/rev/0b63465a1796 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 21:00:08 2016 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 22 Jun 2016 01:00:08 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1466557208.87.0.0832026217078.issue27051@psf.upfronthosting.co.za> Nick Coghlan added the comment: pip_gui.pip_tkinter.utils.runpip has indeed switched to using subprocess (and yes, the PyPA crew are significantly more careful with backwards compatibility there), but there are still a couple of other API imports in that module: https://github.com/upendra-k14/pip_gui/blob/dump_code/pip_tkinter/utils.py#L7 (I didn't check other code to see if the affected APIs are used anywhere) I do like the idea of *bundling* pip_gui in a variant of the ensurepip style, rather than having it as a conventional standard library component, though - it means we can simplify the backwards compatibility guarantee by noting that, if you're using the provided GUI, doing "pip install --upgrade pip" may also require doing "pip install --upgrade pip-tkinter". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 22:09:26 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 22 Jun 2016 02:09:26 +0000 Subject: [issue22463] Warnings when building on AIX In-Reply-To: <1411407169.47.0.841951681699.issue22463@psf.upfronthosting.co.za> Message-ID: <20160622020923.119610.14196.BA0424C0@psf.io> Roundup Robot added the comment: New changeset b1c1c297bead by Martin Panter in branch '2.7': Issue #22463: Correct #endif placement; patch by Senthil Kumaran https://hg.python.org/cpython/rev/b1c1c297bead ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 22:50:00 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 22 Jun 2016 02:50:00 +0000 Subject: [issue22463] Warnings when building on AIX In-Reply-To: <1411407169.47.0.841951681699.issue22463@psf.upfronthosting.co.za> Message-ID: <20160622024957.6281.62777.9B10E5D8@psf.io> Roundup Robot added the comment: New changeset ffe866aa86a8 by Martin Panter in branch '2.7': Issue #22463: Cure unused function warnings on AIX https://hg.python.org/cpython/rev/ffe866aa86a8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 22:50:33 2016 From: report at bugs.python.org (Daniel Holth) Date: Wed, 22 Jun 2016 02:50:33 +0000 Subject: [issue27344] zipfile *does* support utf-8 filenames In-Reply-To: <1466176126.21.0.0133629365393.issue27344@psf.upfronthosting.co.za> Message-ID: <1466563833.53.0.92259532849.issue27344@psf.upfronthosting.co.za> Daniel Holth added the comment: This is a simple documentation bug about the ZIP file format supporting utf-8 and 'no encoding' filenames depending on whether two bits are set in a flag inside the archive member. Bug 10614 appears to be a different issue about out-of-band encoding information that you could pass to Python's zipfile implementation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 23:04:05 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Jun 2016 03:04:05 +0000 Subject: [issue27365] Allow non-ascii chars in IDLE NEWS.txt (for contributor names) Message-ID: <1466564645.25.0.829598827477.issue27365@psf.upfronthosting.co.za> New submission from Terry J. Reedy: A month ago, for 3.5 and 3.6, I added a test file by Westley Mart?nez (note accent on i) and then his name into Misc/NEWS and idlelib/NEWS.txt. As a result, the latter will not display when the button on About IDLE is clicked. Instead, a UnicodeDecodeError is sent to stderr. I will add a test for the About box. ---------- assignee: terry.reedy messages: 269042 nosy: terry.reedy priority: normal severity: normal stage: test needed status: open title: Allow non-ascii chars in IDLE NEWS.txt (for contributor names) type: behavior versions: Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 23:05:19 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Jun 2016 03:05:19 +0000 Subject: [issue27365] Allow non-ascii chars in IDLE NEWS.txt (for contributor names) In-Reply-To: <1466564645.25.0.829598827477.issue27365@psf.upfronthosting.co.za> Message-ID: <1466564719.61.0.346285794296.issue27365@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- keywords: +patch Added file: http://bugs.python.org/file43502/idle-news.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 21 23:14:27 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 22 Jun 2016 03:14:27 +0000 Subject: [issue22463] Warnings when building on AIX In-Reply-To: <1411407169.47.0.841951681699.issue22463@psf.upfronthosting.co.za> Message-ID: <1466565267.4.0.557638710763.issue22463@psf.upfronthosting.co.za> Martin Panter added the comment: FWIW on the current AIX buildbot I don?t see any cPickle.c warnings. (Nor on the earliest build available on that buildbot, from Nov 2015.) ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 00:33:23 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 22 Jun 2016 04:33:23 +0000 Subject: [issue22228] Adapt bash readline operate-and-get-next function In-Reply-To: <1408441328.29.0.0681426449148.issue22228@psf.upfronthosting.co.za> Message-ID: <1466570003.7.0.504364363829.issue22228@psf.upfronthosting.co.za> Martin Panter added the comment: For the record, this ?operate-and-get-next? function is documented in Bash at . It is supposed to finish entering the current line, and it was taken from the history, bring up the following history item for editing. It hasn?t been added to Readline directly because it relies on how the application uses history (e.g. it is flawed in Bash for me because I use HISTCONTROL=erasedups). Python?s ?readline? module currently has runtime detection of Editline vs Gnu Readline. I am not sure if it is strictly needed, or just that it was easier than build-time detection, as hinted in . It is confusing, because we have other build-time detection of particular Readline features. Perhaps you may be able to try out Editline using my patch for Issue 13501, but in my experience, the non-Apple patched Editline is too buggy to be useful in Python for much more than experimentation. I left a couple comments on Git Hub. I would prefer to expose more of this at the Python level, but that seems hard to do. See Issue 1690201 and Issue 1175004 for other attempts to add a custom function at the Python level. It is hard to do in a general way because rl_add_defun() only accepts a function pointer, and no opaque object to pass to the callback. I wonder how the ctypes library handles this when creating general function pointer objects. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 01:30:36 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Jun 2016 05:30:36 +0000 Subject: [issue27365] Allow non-ascii chars in IDLE NEWS.txt (for contributor names) In-Reply-To: <1466564645.25.0.829598827477.issue27365@psf.upfronthosting.co.za> Message-ID: <1466573436.29.0.589061568127.issue27365@psf.upfronthosting.co.za> Changes by Terry J. Reedy : Added file: http://bugs.python.org/file43503/idle-news-27.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 01:30:53 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Jun 2016 05:30:53 +0000 Subject: [issue27365] Allow non-ascii chars in IDLE NEWS.txt (for contributor names) In-Reply-To: <1466564645.25.0.829598827477.issue27365@psf.upfronthosting.co.za> Message-ID: <1466573453.61.0.681513963579.issue27365@psf.upfronthosting.co.za> Changes by Terry J. Reedy : Added file: http://bugs.python.org/file43504/idle-news-36.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 01:44:28 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Jun 2016 05:44:28 +0000 Subject: [issue27365] Allow non-ascii chars in IDLE NEWS.txt (for contributor names) In-Reply-To: <1466564645.25.0.829598827477.issue27365@psf.upfronthosting.co.za> Message-ID: <1466574268.86.0.421106351733.issue27365@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Larry, there is a slight reversion in 3.5.2rc that I think should be fixed: idlelib/NEWS.txt will not display from About IDLE dialog because it had a couple of non-ascii chars. idle_news-35.diff has the full patch. A minimal fix for 3.5.2 final would consist of changing 'ascii' to 'utf-8' in idlelib/aboutDialog.py and the recoding the 2 characters in NEWS. Testing changes in the other 2 files could wait. Since I don't know how you want to do this now, I have not pushed anything yet. ---------- nosy: +benjamin.peterson, larry priority: normal -> release blocker Added file: http://bugs.python.org/file43505/idle-news-35.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 01:44:39 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Jun 2016 05:44:39 +0000 Subject: [issue27365] Allow non-ascii chars in IDLE NEWS.txt (for contributor names) In-Reply-To: <1466564645.25.0.829598827477.issue27365@psf.upfronthosting.co.za> Message-ID: <1466574279.5.0.744207204183.issue27365@psf.upfronthosting.co.za> Changes by Terry J. Reedy : Removed file: http://bugs.python.org/file43502/idle-news.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 01:59:17 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Jun 2016 05:59:17 +0000 Subject: [issue23551] IDLE to provide menu link to PIP gui. In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za> Message-ID: <1466575157.3.0.436489845134.issue23551@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- dependencies: +Create PIP gui _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 02:06:11 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Jun 2016 06:06:11 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1466575571.48.0.499485669468.issue27051@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I am unassigning myself because this has moved out of my sphere of expertise and authority. Someone else should take responsibility for getting this committed. I added this as a dependency of #23551, which is about the IDLE menu entry and invocation of the gui, wherever it ends up. ---------- assignee: terry.reedy -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 02:13:56 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 22 Jun 2016 06:13:56 +0000 Subject: [issue26930] Upgrade installers to OpenSSL 1.0.2h In-Reply-To: <1462285174.78.0.332365810571.issue26930@psf.upfronthosting.co.za> Message-ID: <20160622061353.32761.39183.373A5905@psf.io> Roundup Robot added the comment: New changeset ad037bba60bb by Zachary Ware in branch '2.7': Issue #26930: Update Windows build to OpenSSL 1.0.2h https://hg.python.org/cpython/rev/ad037bba60bb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 02:13:56 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 22 Jun 2016 06:13:56 +0000 Subject: [issue27365] Allow non-ascii chars in IDLE NEWS.txt (for contributor names) In-Reply-To: <1466564645.25.0.829598827477.issue27365@psf.upfronthosting.co.za> Message-ID: <20160622061353.32761.47051.9965BC43@psf.io> Roundup Robot added the comment: New changeset 45d4cea97b04 by Benjamin Peterson in branch '2.7': fix idle about dialog #27365 https://hg.python.org/cpython/rev/45d4cea97b04 ---------- nosy: +ned.deily, python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 03:10:19 2016 From: report at bugs.python.org (Lele Gaifax) Date: Wed, 22 Jun 2016 07:10:19 +0000 Subject: [issue22228] Adapt bash readline operate-and-get-next function In-Reply-To: <1466570003.7.0.504364363829.issue22228@psf.upfronthosting.co.za> Message-ID: <877fdhitrc.fsf@metapensiero.it> Lele Gaifax added the comment: I addressed Martin's comments (thank you!) in https://github.com/lelit/cpython/commits/issue22228_2, removing pointless usage of a macro and avoiding usage of module's state to store the "next line index", keeping it in a plain static variable. Let me know how it looks now. Martin Panter writes: > Python?s ?readline? module currently has runtime detection of Editline vs > Gnu Readline. I am not sure if it is strictly needed, or just that it was > easier than build-time detection, as hinted in > . It is confusing, because we > have other build-time detection of particular Readline features. Yes, it confused me too. Also, there is at least one spot in setup_readline() that seems wrong to me, because it does not consider if it's effectively using libedit: #ifndef __APPLE__ if (!isatty(STDOUT_FILENO)) { /* Issue #19884: stdout is not a terminal. Disable meta modifier keys to not write the ANSI sequence "\033[1034h" into stdout. On terminals supporting 8 bit characters like TERM=xterm-256color (which is now the default Fedora since Fedora 18), the meta key is used to enable support of 8 bit characters (ANSI sequence "\033[1034h"). With libedit, this call makes readline() crash. */ rl_variable_bind ("enable-meta-key", "off"); } #endif > Perhaps you may be able to try out Editline using my patch for Issue 13501, > but in my experience, the non-Apple patched Editline is too buggy to be > useful in Python for much more than experimentation. I will try to find some spare time to spend on this, but unfortunately I can not promise I'll be able to do that in the near future, sorry. > I would prefer to expose more of this at the Python level, but that seems > hard to do. Yeah, I know (I've been here nearly from the beginning ;-). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 03:19:27 2016 From: report at bugs.python.org (Martin Teichmann) Date: Wed, 22 Jun 2016 07:19:27 +0000 Subject: [issue27366] PEP487: Simpler customization of class creation Message-ID: <1466579967.76.0.483118833643.issue27366@psf.upfronthosting.co.za> New submission from Martin Teichmann: This is the implementation of PEP 487. It adds a metaclass to types that calls a method on a class once it is subclassed. This way one can customize the creation of classes without the need to write an own metaclass. As a second functionality, it calls a method on each descriptor in a class, such that descriptors know their name. ---------- components: Library (Lib) files: pep487.patch keywords: patch messages: 269050 nosy: Martin.Teichmann priority: normal severity: normal status: open title: PEP487: Simpler customization of class creation type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43506/pep487.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 03:33:45 2016 From: report at bugs.python.org (Larry Hastings) Date: Wed, 22 Jun 2016 07:33:45 +0000 Subject: [issue27365] Allow non-ascii chars in IDLE NEWS.txt (for contributor names) In-Reply-To: <1466564645.25.0.829598827477.issue27365@psf.upfronthosting.co.za> Message-ID: <1466580825.55.0.624746770789.issue27365@psf.upfronthosting.co.za> Larry Hastings added the comment: If the diff is literally changing two lines, I'll accept it. Guido relaxed the rules for IDLE changes. If it breaks something it's on *your* head ;-) Please just check it in normally. Either I'm going to use hg to cherry-pick the changes for 3.5.2 final, or I'm going to have to apply patches manually anyway. Either way an hg checkin is fine. Please check in this minimal change *as a separate checkin* from the larger changes, if you're committing the other changes any time soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 03:41:12 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Jun 2016 07:41:12 +0000 Subject: [issue27365] Allow non-ascii chars in IDLE NEWS.txt (for contributor names) In-Reply-To: <1466564645.25.0.829598827477.issue27365@psf.upfronthosting.co.za> Message-ID: <1466581272.87.0.731140292535.issue27365@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I should mention that I have separate 3.5 and 3.6 patches because I know that the merge will not work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 03:45:35 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Jun 2016 07:45:35 +0000 Subject: [issue27365] Allow non-ascii chars in IDLE NEWS.txt (for contributor names) In-Reply-To: <1466564645.25.0.829598827477.issue27365@psf.upfronthosting.co.za> Message-ID: <1466581535.65.0.111365615555.issue27365@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I was wondering if splitting the patch would be better. Shelve makes it easy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 03:57:56 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 22 Jun 2016 07:57:56 +0000 Subject: [issue27365] Allow non-ascii chars in IDLE NEWS.txt (for contributor names) In-Reply-To: <1466564645.25.0.829598827477.issue27365@psf.upfronthosting.co.za> Message-ID: <20160622075752.32534.77122.9ED77DAC@psf.io> Roundup Robot added the comment: New changeset 783dfd77e4c1 by Terry Jan Reedy in branch '3.5': Issue #27365: Allow non-ascii in idlelib/NEWS.txt - minimal part for 3.5.2. https://hg.python.org/cpython/rev/783dfd77e4c1 New changeset b8926908d2a0 by Terry Jan Reedy in branch 'default': Issue #27365: Merge minimal part. https://hg.python.org/cpython/rev/b8926908d2a0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 04:03:09 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 22 Jun 2016 08:03:09 +0000 Subject: [issue26859] unittest fails with "Start directory is not importable" when trying to run sourceless tests In-Reply-To: <1461678137.48.0.743276761028.issue26859@psf.upfronthosting.co.za> Message-ID: <1466582589.28.0.977885568821.issue26859@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > the list_dir() nested function is never called Verifying that load_tests is called is the purpose of this test. In this case should_recurse is false in _find_tests() and os.listdir() is not invoked by this method. This new patch does not use vfs and list_dir and uses subtests to also check that TestLoader.discover() does consider that a path refers to a package directory when it contains an '__init__.pyc' file and no '__init__.py' file, and vice-versa. ---------- Added file: http://bugs.python.org/file43507/unittest_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 04:04:01 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Jun 2016 08:04:01 +0000 Subject: [issue27365] Allow non-ascii chars in IDLE NEWS.txt (for contributor names) In-Reply-To: <1466564645.25.0.829598827477.issue27365@psf.upfronthosting.co.za> Message-ID: <1466582641.44.0.840062013362.issue27365@psf.upfronthosting.co.za> Terry J. Reedy added the comment: 783dfd77e4c1 is the one to pick for 3.5, then null merge if you merge to 3.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 04:24:53 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 22 Jun 2016 08:24:53 +0000 Subject: [issue27365] Allow non-ascii chars in IDLE NEWS.txt (for contributor names) In-Reply-To: <1466564645.25.0.829598827477.issue27365@psf.upfronthosting.co.za> Message-ID: <20160622082449.10047.81770.FC919C75@psf.io> Roundup Robot added the comment: New changeset d5ee1e5c1ac0 by Terry Jan Reedy in branch '3.5': Issue #27365: Allow non-ascii in idlelib/NEWS.txt, for contributor names. https://hg.python.org/cpython/rev/d5ee1e5c1ac0 New changeset e7ecad98a785 by Terry Jan Reedy in branch 'default': Issue #27365: temporary rename https://hg.python.org/cpython/rev/e7ecad98a785 New changeset a4aa45859b5c by Terry Jan Reedy in branch 'default': Issue #27365: partial merge https://hg.python.org/cpython/rev/a4aa45859b5c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 04:29:46 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 22 Jun 2016 08:29:46 +0000 Subject: [issue27367] Windows buildbot: random timeout failure on test_threading Message-ID: <1466584186.93.0.689178719863.issue27367@psf.upfronthosting.co.za> New submission from STINNER Victor: test_threading fails with a timeout, but it is probably a random failure caused by a slow Windows buildbot. http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/7871/steps/test/logs/stdio 0:21:16 [351/401] test_threading crashed -- running: test_concurrent_futures (93 sec) Timeout (0:15:00)! Thread 0x000014a0 (most recent call first): File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\threading.py", line 295 in wait File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\lock_tests.py", line 473 in f File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\lock_tests.py", line 38 in task Thread 0x00001704 (most recent call first): File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\lock_tests.py", line 17 in _wait File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\lock_tests.py", line 511 in _check_notify File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\lock_tests.py", line 520 in test_notify File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\case.py", line 600 in run File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\case.py", line 648 in __call__ File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py", line 122 in run File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py", line 84 in __call__ File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py", line 122 in run File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py", line 84 in __call__ File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py", line 122 in run File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py", line 84 in __call__ File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\runner.py", line 176 in run File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", line 1803 in _run_suite File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", line 1837 in run_unittest File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\libregrtest\runtest.py", line 179 in test_runner File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\libregrtest\runtest.py", line 180 in runtest_inner File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\libregrtest\runtest.py", line 133 in runtest File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\libregrtest\runtest_mp.py", line 71 in run_tests_slave File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\libregrtest\main.py", line 453 in _main File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\libregrtest\main.py", line 446 in main File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\libregrtest\main.py", line 508 in main File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\regrtest.py", line 46 in _main File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\regrtest.py", line 50 in File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\runpy.py", line 85 in _run_code File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\runpy.py", line 184 in _run_module_as_main Traceback (most recent call last): File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\runpy.py", line 184, in _run_module_as_main "__main__", mod_spec) File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\runpy.py", line 85, in _run_code exec(code, run_globals) File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\__main__.py", line 2, in main() File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\libregrtest\main.py", line 508, in main Regrtest().main(tests=tests, **kwargs) File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\libregrtest\main.py", line 446, in main self._main(tests, kwargs) File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\libregrtest\main.py", line 466, in _main self.run_tests() File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\libregrtest\main.py", line 404, in run_tests run_tests_multiprocess(self) File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\libregrtest\runtest_mp.py", line 221, in run_tests_multiprocess raise Exception(msg) Exception: Child error on test_threading: Exit code 1 ---------- components: Tests keywords: buildbot messages: 269058 nosy: haypo priority: normal severity: normal status: open title: Windows buildbot: random timeout failure on test_threading versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 04:51:08 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 22 Jun 2016 08:51:08 +0000 Subject: [issue27365] Allow non-ascii chars in IDLE NEWS.txt (for contributor names) In-Reply-To: <1466564645.25.0.829598827477.issue27365@psf.upfronthosting.co.za> Message-ID: <20160622085105.3827.24200.E7065E1E@psf.io> Roundup Robot added the comment: New changeset 54dde0cb10f9 by Terry Jan Reedy in branch 'default': Issue #27365: revert temporary rename https://hg.python.org/cpython/rev/54dde0cb10f9 New changeset be0dec826982 by Terry Jan Reedy in branch 'default': Issue #27365: add chunk https://hg.python.org/cpython/rev/be0dec826982 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 04:54:40 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 22 Jun 2016 08:54:40 +0000 Subject: [issue27365] Allow non-ascii chars in IDLE NEWS.txt (for contributor names) In-Reply-To: <1466564645.25.0.829598827477.issue27365@psf.upfronthosting.co.za> Message-ID: <20160622085437.657.23851.ED4C59BC@psf.io> Roundup Robot added the comment: New changeset 3a122d0e4187 by Terry Jan Reedy in branch 'default': Issue #27365: add chunk https://hg.python.org/cpython/rev/3a122d0e4187 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 04:57:50 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 22 Jun 2016 08:57:50 +0000 Subject: [issue27365] Allow non-ascii chars in IDLE NEWS.txt (for contributor names) In-Reply-To: <1466564645.25.0.829598827477.issue27365@psf.upfronthosting.co.za> Message-ID: <20160622085745.32563.4667.D9BC0DFC@psf.io> Roundup Robot added the comment: New changeset 49323bb44229 by Terry Jan Reedy in branch 'default': Issue #27365: revert temporary rename https://hg.python.org/cpython/rev/49323bb44229 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 04:59:07 2016 From: report at bugs.python.org (Chandrajyoti) Date: Wed, 22 Jun 2016 08:59:07 +0000 Subject: [issue27368] os.mkdir is not working for multiple level of directory creation in windows environment Message-ID: <1466585947.59.0.278104796576.issue27368@psf.upfronthosting.co.za> New submission from Chandrajyoti: Problem: os.mkdir is not working for multiple level of directory creation in windows environment. Explanation: Suppose there is a directory whose path is "D:\Output" Now to create 2 levels of directory in side the path "D:\Output", when os.mkdir("D:\Output\Dir1\Dir2") is used, python 2.7 throws errors as below: Traceback (most recent call last): File "", line 1, in WindowsError: [Error 3] The system cannot find the path specified: 'D:\\Output\\Dir1\\Dir2' Please update python to create multiple level of directory. ---------- components: Library (Lib) messages: 269062 nosy: ChandrajyotiDas priority: normal severity: normal status: open title: os.mkdir is not working for multiple level of directory creation in windows environment type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 05:00:21 2016 From: report at bugs.python.org (Johannes Ebke) Date: Wed, 22 Jun 2016 09:00:21 +0000 Subject: [issue26923] asyncio.gather drops cancellation In-Reply-To: <1462279806.1.0.880381545595.issue26923@psf.upfronthosting.co.za> Message-ID: <1466586021.93.0.160810630486.issue26923@psf.upfronthosting.co.za> Johannes Ebke added the comment: Attached is a new version of the patch incorporating the review results. ---------- Added file: http://bugs.python.org/file43508/fix_and_test_26923_reviewed.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 05:03:04 2016 From: report at bugs.python.org (SilentGhost) Date: Wed, 22 Jun 2016 09:03:04 +0000 Subject: [issue27368] os.mkdir is not working for multiple level of directory creation in windows environment In-Reply-To: <1466585947.59.0.278104796576.issue27368@psf.upfronthosting.co.za> Message-ID: <1466586184.31.0.667638097704.issue27368@psf.upfronthosting.co.za> SilentGhost added the comment: You need to use os.makedirs ---------- nosy: +SilentGhost resolution: -> not a bug stage: -> resolved status: open -> closed type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 05:04:55 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Jun 2016 09:04:55 +0000 Subject: [issue27365] Allow non-ascii chars in IDLE NEWS.txt (for contributor names) In-Reply-To: <1466564645.25.0.829598827477.issue27365@psf.upfronthosting.co.za> Message-ID: <1466586295.24.0.0998217166487.issue27365@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Because of the case conflict I did not notice soon enough, the rest of the patch and merge did not go well and I got this test test_idle crashed -- Traceback (most recent call last): File "F:\Python\dev\36\lib\test\libregrtest\runtest.py", line 180, in runtest_inner test_runner() File "F:\Python\dev\36\lib\test\libregrtest\runtest.py", line 178, in test_runner raise Exception("errors while loading tests") Exception: errors while loading tests I suspect it is a problem with textView/textview, so I will temporarily disable test files to find the culprit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 05:49:51 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 22 Jun 2016 09:49:51 +0000 Subject: [issue27365] Allow non-ascii chars in IDLE NEWS.txt (for contributor names) In-Reply-To: <1466564645.25.0.829598827477.issue27365@psf.upfronthosting.co.za> Message-ID: <20160622094948.4202.71569.DF6ADB56@psf.io> Roundup Robot added the comment: New changeset 33769ce40b47 by Terry Jan Reedy in branch 'default': Issue #27365: Finish merge so tests pass. https://hg.python.org/cpython/rev/33769ce40b47 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 05:53:08 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Jun 2016 09:53:08 +0000 Subject: [issue27365] Allow non-ascii chars in IDLE NEWS.txt (for contributor names) In-Reply-To: <1466564645.25.0.829598827477.issue27365@psf.upfronthosting.co.za> Message-ID: <1466589188.31.0.740043968555.issue27365@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Suspicion wrong. idle_test and hand tests pass. Larry, I am done with this. I left it open until you are also. ---------- resolution: -> fixed stage: test needed -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 07:01:05 2016 From: report at bugs.python.org (INADA Naoki) Date: Wed, 22 Jun 2016 11:01:05 +0000 Subject: [issue27350] Compact and ordered dict In-Reply-To: <1466307796.29.0.980579044792.issue27350@psf.upfronthosting.co.za> Message-ID: <1466593265.27.0.290160538919.issue27350@psf.upfronthosting.co.za> INADA Naoki added the comment: Thank you, mark. I've added PY_INT16_T and PY_UINT16_T for windows, too. https://github.com/methane/cpython/pull/1/commits/dfaa44c051b2dbf580701729944cd0fda00cb541 https://github.com/methane/cpython/pull/1/commits/af80dc27dd381af9d211792963a23c5cecfa7009 I'll post next patchset soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 07:29:45 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Jun 2016 11:29:45 +0000 Subject: [issue27365] Allow non-ascii chars in IDLE NEWS.txt (for contributor names) In-Reply-To: <1466564645.25.0.829598827477.issue27365@psf.upfronthosting.co.za> Message-ID: <1466594985.93.0.4514447378.issue27365@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Is this dance with renaming forever? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 07:38:16 2016 From: report at bugs.python.org (INADA Naoki) Date: Wed, 22 Jun 2016 11:38:16 +0000 Subject: [issue27350] Compact and ordered dict In-Reply-To: <1466307796.29.0.980579044792.issue27350@psf.upfronthosting.co.za> Message-ID: <1466595496.47.0.64148076446.issue27350@psf.upfronthosting.co.za> Changes by INADA Naoki : Added file: http://bugs.python.org/file43509/compact-dict.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 07:40:20 2016 From: report at bugs.python.org (Jaysinh shukla) Date: Wed, 22 Jun 2016 11:40:20 +0000 Subject: [issue20674] Update comments in dictobject.c In-Reply-To: <1392744795.57.0.649500024154.issue20674@psf.upfronthosting.co.za> Message-ID: <1466595620.62.0.700469660332.issue20674@psf.upfronthosting.co.za> Jaysinh shukla added the comment: Submitting patch which tries to cover mentioned change. I request Core-developers to verify the approach I took for fixing this change. Thanks! ---------- keywords: +patch nosy: +jaysinh.shukla Added file: http://bugs.python.org/file43510/issue20674_patch_v1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 08:08:34 2016 From: report at bugs.python.org (Ryan Petrello) Date: Wed, 22 Jun 2016 12:08:34 +0000 Subject: [issue27172] Add skip_bound_arg argument to inspect.Signature.from_callable() In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za> Message-ID: <1466597314.59.0.950925946316.issue27172@psf.upfronthosting.co.za> Ryan Petrello added the comment: Nick, My use case is an issue of backwards compatibility and multiple Python version support for a library that makes prolific use of the legacy argspec (args, varargs, varkw, defaults) namedtuple, *including* the bound self argument behavior. argspec and signature are quite different, and supporting a Py26-Py36 codebase that handles both simultaneously seemed like quite a burden, so I opted to write a compatibility shim that returned an Argspec-like object for all versions of Python; this seemed the simplest approach to bridge the gap in a codebase that supports Python 2.6 through 3.6, and it's the approach that I've seen other major libraries (like Django) take: https://github.com/pecan/pecan/pull/61 I'm using a similar approach to Python 3.5's getfullargspec() implementation: https://github.com/python/cpython/blob/3.5/Lib/inspect.py#L1069 ...but I don't have a long-term public API for doing it (so I have to rely on the private inspect._signature_from_callable call, which seems icky). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 08:32:49 2016 From: report at bugs.python.org (INADA Naoki) Date: Wed, 22 Jun 2016 12:32:49 +0000 Subject: [issue27350] Compact and ordered dict In-Reply-To: <1466307796.29.0.980579044792.issue27350@psf.upfronthosting.co.za> Message-ID: <1466598769.08.0.591373751475.issue27350@psf.upfronthosting.co.za> INADA Naoki added the comment: FYI, bench result of USABLE_FRACTION(n) = (n/2): Report on Linux ip-10-0-1-249 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-1 (2016-03-06) x86_64 Total CPU cores: 2 +--------------+---------+------------+--------------+------------------------+ | Benchmark | default | usable n/2 | Change | Significance | +==============+=========+============+==============+========================+ | 2to3 | 5.18 | 5.17 | 1.00x faster | Not significant | +--------------+---------+------------+--------------+------------------------+ | chameleon_v2 | 4.03 | 3.87 | 1.04x faster | Significant (t=61.85) | +--------------+---------+------------+--------------+------------------------+ | django_v3 | 0.4 | 0.39 | 1.01x faster | Not significant | +--------------+---------+------------+--------------+------------------------+ | fastpickle | 0.33 | 0.33 | 1.00x slower | Not significant | +--------------+---------+------------+--------------+------------------------+ | fastunpickle | 0.41 | 0.42 | 1.04x slower | Significant (t=-56.83) | +--------------+---------+------------+--------------+------------------------+ | json_dump_v2 | 1.93 | 1.94 | 1.01x slower | Not significant | +--------------+---------+------------+--------------+------------------------+ | json_load | 0.33 | 0.33 | 1.01x faster | Not significant | +--------------+---------+------------+--------------+------------------------+ | nbody | 0.19 | 0.19 | 1.00x slower | Not significant | +--------------+---------+------------+--------------+------------------------+ | regex_v8 | 0.04 | 0.04 | 1.00x faster | Not significant | +--------------+---------+------------+--------------+------------------------+ | tornado_http | 0.19 | 0.2 | 1.01x slower | Not significant | +--------------+---------+------------+--------------+------------------------+ I've changed recommended usable fraction from 5/8~2/3 to 1/2~2/3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 09:28:59 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 22 Jun 2016 13:28:59 +0000 Subject: [issue27345] GzipFile's readinto() reads gzip data instead of file data. In-Reply-To: <1466234155.82.0.00888725060724.issue27345@psf.upfronthosting.co.za> Message-ID: <1466602139.68.0.52949187571.issue27345@psf.upfronthosting.co.za> R. David Murray added the comment: Probably not in 2.7. It may be broken, but what if someone is depending on it? (Unlikely, but the chance of it outweighs the benefit of changing it in a mainteance release.) Does the same problem exist in 3.6? That's probably the only version where we would change it. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 10:03:21 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 22 Jun 2016 14:03:21 +0000 Subject: [issue27152] Additional assert methods for unittest In-Reply-To: <1464535519.92.0.0853489345335.issue27152@psf.upfronthosting.co.za> Message-ID: <1466604201.21.0.773125996959.issue27152@psf.upfronthosting.co.za> R. David Murray added the comment: I would expect it to be assertEndswith, etc. You will note that all the other cases of multiple capitals are either englishification of symbolic operators or concatenations of separate type words and/or syntactically distinct operators. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 10:38:25 2016 From: report at bugs.python.org (Tim Graham) Date: Wed, 22 Jun 2016 14:38:25 +0000 Subject: [issue25548] Show the address in the repr for class objects In-Reply-To: <1446576011.58.0.372024983976.issue25548@psf.upfronthosting.co.za> Message-ID: <1466606305.19.0.0733946823192.issue25548@psf.upfronthosting.co.za> Tim Graham added the comment: I'll echo what Peter said and say that this breaks 5 tests in Django's test suite which are checking error messages. If it stays, perhaps it could be added to the release notes instead of just NEWS. ---------- nosy: +Tim.Graham _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 11:52:49 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Jun 2016 15:52:49 +0000 Subject: [issue27365] Allow non-ascii chars in IDLE NEWS.txt (for contributor names) In-Reply-To: <1466564645.25.0.829598827477.issue27365@psf.upfronthosting.co.za> Message-ID: <1466610769.88.0.469287026888.issue27365@psf.upfronthosting.co.za> Terry J. Reedy added the comment: No, it ends with the last 3.5 maintenance release in about 6 months. When I did it right, as in #27245, which was otherwise a clean single file merge, there was no problem and it took at most an extra 30 seconds. I know what I did wrong this time, starting with not writing down the steps needed, and in which order, for a much more complicated merge. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 12:26:57 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Jun 2016 16:26:57 +0000 Subject: [issue4945] json checks True/False by identity, not boolean value In-Reply-To: <1231911098.49.0.621266929609.issue4945@psf.upfronthosting.co.za> Message-ID: <1466612817.41.0.639737670139.issue4945@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated patches are synchronized with current sources and address Ezio's comments (sorry for the delay Ezio, I missed your comments). ---------- versions: +Python 3.6 -Python 3.4 Added file: http://bugs.python.org/file43511/json_doc_truefalse_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 12:27:17 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Jun 2016 16:27:17 +0000 Subject: [issue4945] json checks True/False by identity, not boolean value In-Reply-To: <1231911098.49.0.621266929609.issue4945@psf.upfronthosting.co.za> Message-ID: <1466612837.95.0.748359487948.issue4945@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file43512/json_doc_truefalse-2.7_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 12:49:27 2016 From: report at bugs.python.org (Ryan Birmingham) Date: Wed, 22 Jun 2016 16:49:27 +0000 Subject: [issue27345] GzipFile's readinto() reads gzip data instead of file data. In-Reply-To: <1466234155.82.0.00888725060724.issue27345@psf.upfronthosting.co.za> Message-ID: <1466614167.31.0.707929956692.issue27345@psf.upfronthosting.co.za> Ryan Birmingham added the comment: It seems to work as expected in python 3.5 (and at least up, presumably). I'll close it. Thank you. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 12:57:38 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Jun 2016 16:57:38 +0000 Subject: [issue17909] Autodetecting JSON encoding In-Reply-To: <1367759430.76.0.988181674037.issue17909@psf.upfronthosting.co.za> Message-ID: <1466614658.72.0.900950266306.issue17909@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- versions: +Python 3.6 -Python 3.5 Added file: http://bugs.python.org/file43513/json_detect_encoding_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 14:17:23 2016 From: report at bugs.python.org (sping) Date: Wed, 22 Jun 2016 18:17:23 +0000 Subject: [issue27369] [PATCH] Tests break with --with-system-expat and Expat 2.2.0 Message-ID: <1466619443.74.0.364754178665.issue27369@psf.upfronthosting.co.za> New submission from sping: Expat commit https://sourceforge.net/p/expat/code_git/ci/550eb6bbaa7e6efc44e94cab945fe9c781c01211 introduced with the recent release of Expat 2.2.0 fixed a bug that the current Python test suite relies on. Attached you find patches to fix the test suite for all versions in a backwards-compatible way. Please consider application upstream. Thanks! Best, Sebastian ---------- components: Tests files: 0001-Fix-Python-2.7.11-tests-for-Expat-2.2.0.patch keywords: patch messages: 269079 nosy: sping priority: normal severity: normal status: open title: [PATCH] Tests break with --with-system-expat and Expat 2.2.0 type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43514/0001-Fix-Python-2.7.11-tests-for-Expat-2.2.0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 14:17:40 2016 From: report at bugs.python.org (sping) Date: Wed, 22 Jun 2016 18:17:40 +0000 Subject: [issue27369] [PATCH] Tests break with --with-system-expat and Expat 2.2.0 In-Reply-To: <1466619443.74.0.364754178665.issue27369@psf.upfronthosting.co.za> Message-ID: <1466619460.05.0.271322074713.issue27369@psf.upfronthosting.co.za> Changes by sping : Added file: http://bugs.python.org/file43515/0001-Fix-Python-3.x.x-tests-for-Expat-2.2.0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 14:29:00 2016 From: report at bugs.python.org (Andrew Cameron) Date: Wed, 22 Jun 2016 18:29:00 +0000 Subject: [issue27370] Inconsistency in docs for list.extend Message-ID: <1466620140.79.0.360465596161.issue27370@psf.upfronthosting.co.za> New submission from Andrew Cameron: The documentation for Mutable Sequence Types states that, for operation: s.extend(x) or s += t the expected result is: for the most part the same as s[len(s):len(s)] = x Note that if you perform operation 's += t' the result is not the same as 's[len(s):len(s)] = x' unless 't == x'. This does not occur with the Python 3 docs, which uses exclusively 't' (not 'x'). However for people reading the Python 2 docs the variable mix-up could cause confusion. ---------- assignee: docs at python components: Documentation messages: 269080 nosy: Andrew Cameron, docs at python priority: normal severity: normal status: open title: Inconsistency in docs for list.extend versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 14:46:01 2016 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 22 Jun 2016 18:46:01 +0000 Subject: [issue27172] Add skip_bound_arg argument to inspect.Signature.from_callable() In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za> Message-ID: <1466621161.78.0.550479395113.issue27172@psf.upfronthosting.co.za> Nick Coghlan added the comment: Are you able to use inspect.getfullargspec() on Python 3 rather than inspect.getargspec()? While both are technically deprecated, only inspect.getargspec() actually emits a deprecation warning - inspect.getfullargspec() still works without complaint and is in no danger of being removed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 15:18:10 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Jun 2016 19:18:10 +0000 Subject: [issue16218] Python launcher does not support unicode characters In-Reply-To: <1350138278.8.0.551817049969.issue16218@psf.upfronthosting.co.za> Message-ID: <1466623090.19.0.610330408113.issue16218@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: commit review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 16:01:58 2016 From: report at bugs.python.org (Ryan Petrello) Date: Wed, 22 Jun 2016 20:01:58 +0000 Subject: [issue27172] Add skip_bound_arg argument to inspect.Signature.from_callable() In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za> Message-ID: <1466625718.29.0.667184109691.issue27172@psf.upfronthosting.co.za> Ryan Petrello added the comment: Nick, My main reasoning for not using it is that it's marked as deprecated in the docstring, and I want to avoid relying on it if disappears in the future :) Warnings or not, the shim that I wrote doesn't use any deprecated code, so that's why I took that approach. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 16:12:55 2016 From: report at bugs.python.org (Julio C Cardoza) Date: Wed, 22 Jun 2016 20:12:55 +0000 Subject: [issue27139] Increased test coverage for statistics.median_grouped In-Reply-To: <20160616171722.GE27919@ando.pearwood.info> Message-ID: Julio C Cardoza added the comment: Hi Steve! Just giving you a hello! and, like you asked, to remind you about my case. Thanks men! On Thu, Jun 16, 2016 at 1:17 PM, Steven D'Aprano wrote: > > Steven D'Aprano added the comment: > > Thanks Julio, > > I hope to get to this over the next week. Please feel free to prod me if > you see no action by then. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 16:26:38 2016 From: report at bugs.python.org (Larry Hastings) Date: Wed, 22 Jun 2016 20:26:38 +0000 Subject: [issue27365] Allow non-ascii chars in IDLE NEWS.txt (for contributor names) In-Reply-To: <1466564645.25.0.829598827477.issue27365@psf.upfronthosting.co.za> Message-ID: <1466627198.93.0.793829531706.issue27365@psf.upfronthosting.co.za> Larry Hastings added the comment: You speak confidently, for a guy who hasn't seen any sort of schedule from the 3.5 RM. :-O After 3.6 comes out, I expect 3.5 to get one more "bug fix" release. And *then* it will transition to "security fixes only" mode. Six months is the absolute minimum, and I'd expect it to be longer than that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 16:42:21 2016 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 22 Jun 2016 20:42:21 +0000 Subject: [issue27172] Add skip_bound_arg argument to inspect.Signature.from_callable() In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za> Message-ID: <1466628141.5.0.274923011722.issue27172@psf.upfronthosting.co.za> Nick Coghlan added the comment: OK, so maybe the right answer here is to officially undeprecate inspect.getfullargspec(), as we definitely *don't* want people feeling obliged to write their own version of that, and potentially introducing inconsistencies between different tools. Then the deprecation warning on inspect.getargspec() can be updated to point people towards "inspect.signature() or inspect.getfullargspec()", while the docs for getfullargspec() itself can be updated to say it isn't recommended for use in new code, rather than that it's deprecated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 17:01:32 2016 From: report at bugs.python.org (Jeremy Blow) Date: Wed, 22 Jun 2016 21:01:32 +0000 Subject: [issue27371] Runaway memory consumption using update() Message-ID: <1466629289.92.0.827863623566.issue27371@psf.upfronthosting.co.za> New submission from Jeremy Blow: Hi folks, While going about running tkinter's update() call within a coroutine/asyncio event loop in lieu of using mainloop(), I came across odd memory behavior on MacOS where the cpython process gradually increases memory consumption. Suspicious that there may be some unfavorable interaction between asyncio's use of KqueueSelector and the lower level tk calls, I stripped things down to a simple implementation and found the behavior exhibits itself without asyncio involved at all. ``` import tkinter as tk def start(root): while True: root.update() # tk update loop: mem consumption increases start(tk.Tk()) # tk mainloop: mem consumption stable # tk.Tk().mainloop() ``` # Using tk mainloop, ~1 minute /Users/jeremy$ /usr/bin/time -l python3.5 tk_perf.py 60.26 real 0.16 user 0.07 sys 31756288 maximum resident set size 0 average shared memory size 0 average unshared data size 0 average unshared stack size 10215 page reclaims 0 page faults 0 swaps 0 block input operations 7 block output operations 0 messages sent 0 messages received 0 signals received 7 voluntary context switches 1788 involuntary context switches # tk update loop, ~1 minute /Users/jeremy$ /usr/bin/time -l python3.5 tk_perf.py Traceback (most recent call last): File "tk_perf.py", line 10, in start(tk.Tk()) File "tk_perf.py", line 7, in start root.update() File "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.5/tkinter/__init__.py", line 1025, in update self.tk.call('update') _tkinter.TclError: can't invoke "update" command: application has been destroyed 60.37 real 38.09 user 20.54 sys 545976320 maximum resident set size 0 average shared memory size 0 average unshared data size 0 average unshared stack size 135760 page reclaims 2 page faults 0 swaps 0 block input operations 9 block output operations 0 messages sent 0 messages received 0 signals received 474742 voluntary context switches 1672276 involuntary context switches That's 31,756,288 versus 545,976,320 after ~1 minute. If I let the update loop continue, it eventually consumes many gigabytes of memory. Obviously something is very wrong here. To further the fun, I've tested this across three Macs, and only two exhibit the behavior. This may or may not be interesting to those who are already aware of Tk / Cocoa event loop interaction issues. +---------------+----------------+----------------+----------+ | MacOS Version | Python Version | Tcl/Tk Version | Exhibits | +---------------+----------------+----------------+----------+ | 10.11.3/15D21 | 3.5.1 | 8.5/8.5 | Yes | | 10.9.4/13E28 | 3.5.1 | 8.5/8.5 | No | | 10.11.2/15C50 | 3.5.1 | 8.5/8.5 | Yes | +---------------+----------------+----------------+----------+ Could someone illuminate me as to as whether I'm facing a PEBKAC, update() is lacking some housekeeping that exists in the mainloop routine, a new/known bug, or other? Further troubleshooting steps I can take are appreciated, I'm happy to try to isolate it further. My use case is a tkinter app written solely w/ coroutines thus the event loop selection is constrained. Env details below.. Cheers. ~~~ENV~~~~ /Users/jeremy$ sw_vers ProductName: Mac OS X ProductVersion: 10.11.3 BuildVersion: 15D21 /Users/jeremy$ python3.5 --version Python 3.5.1 >>> import _tkinter >>> _tkinter.__spec__ ModuleSpec(name='_tkinter', loader=<_frozen_importlib_external.ExtensionFileLoader object at 0x1028ae5c0>, origin='/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.5/lib-dynload/_tkinter.cpython-35m-darwin.so') >>> _tkinter.TCL_VERSION, _tkinter.TK_VERSION ('8.5', '8.5') /Users/jeremy$ python3.5 -m sysconfig "sysconfig.get_config_vars()" Platform: "macosx-10.11-x86_64" Python version: "3.5" Current installation scheme: "posix_prefix" Paths: data = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5" include = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/include/python3.5m" platinclude = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/include/python3.5m" platlib = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages" platstdlib = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.5" purelib = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages" scripts = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/bin" stdlib = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.5" Variables: ABIFLAGS = "m" AC_APPLE_UNIVERSAL_BUILD = "0" AIX_GENUINE_CPLUSPLUS = "0" AR = "ar" ARFLAGS = "rc" ASDLGEN = "python ./Parser/asdl_c.py" ASDLGEN_FILES = "./Parser/asdl.py ./Parser/asdl_c.py" AST_ASDL = "./Parser/Python.asdl" AST_C = "Python/Python-ast.c" AST_C_DIR = "Python" AST_H = "Include/Python-ast.h" AST_H_DIR = "Include" BASECFLAGS = "-Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic" BASECPPFLAGS = "" BASEMODLIBS = "" BINDIR = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/bin" BINLIBDEST = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.5" BLDLIBRARY = "" BLDSHARED = "clang -bundle -undefined dynamic_lookup" BUILDEXE = ".exe" BUILDPYTHON = "python.exe" BUILD_GNU_TYPE = "x86_64-apple-darwin15.4.0" BYTESTR_DEPS = "\" CC = "clang" CCSHARED = "" CFLAGS = "-Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes" CFLAGSFORSHARED = "" CFLAGS_NODIST = "" CONFIGFILES = "configure configure.ac acconfig.h pyconfig.h.in Makefile.pre.in" CONFIGURE_CFLAGS = "" CONFIGURE_CFLAGS_NODIST = "-Werror=declaration-after-statement" CONFIGURE_CPPFLAGS = "" CONFIGURE_LDFLAGS = "" CONFIG_ARGS = "'--prefix=/usr/local/Cellar/python3/3.5.1' '--enable-ipv6' '--datarootdir=/usr/local/Cellar/python3/3.5.1/share' '--datadir=/usr/local/Cellar/python3/3.5.1/share' '--enable-framework=/usr/local/Cellar/python3/3.5.1/Frameworks' '--without-ensurepip' '--without-gcc' 'MACOSX_DEPLOYMENT_TARGET=10.11' 'CC=clang' 'PKG_CONFIG_PATH=/usr/local/opt/xz/lib/pkgconfig:/usr/local/opt/sqlite/lib/pkgconfig:/usr/local/opt/openssl/lib/pkgconfig' 'PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig:/usr/local/Library/ENV/pkgconfig/10.11'" CONFINCLUDEDIR = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/include" CONFINCLUDEPY = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/include/python3.5m" COREPYTHONPATH = ":plat-darwin" COVERAGE_INFO = "/private/tmp/python320160418-12904-1t6reri/Python-3.5.1/coverage.info" COVERAGE_REPORT = "/private/tmp/python320160418-12904-1t6reri/Python-3.5.1/lcov-report" COVERAGE_REPORT_OPTIONS = "--no-branch-coverage --title "CPython lcov report"" CPPFLAGS = "-I. -IInclude -I./Include" CXX = "clang++" DESTDIRS = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5 /usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib /usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.5 /usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.5/lib-dynload" DESTLIB = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.5" DESTPATH = "" DESTSHARED = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.5/lib-dynload" DIRMODE = "755" DIST = "README ChangeLog configure configure.ac acconfig.h pyconfig.h.in Makefile.pre.in Include Lib Misc Ext-dummy" DISTDIRS = "Include Lib Misc Ext-dummy" DISTFILES = "README ChangeLog configure configure.ac acconfig.h pyconfig.h.in Makefile.pre.in" DLINCLDIR = "." DLLLIBRARY = "" DOUBLE_IS_ARM_MIXED_ENDIAN_IEEE754 = "0" DOUBLE_IS_BIG_ENDIAN_IEEE754 = "0" DOUBLE_IS_LITTLE_ENDIAN_IEEE754 = "1" DYNLOADFILE = "dynload_shlib.o" ENABLE_IPV6 = "1" ENSUREPIP = "no" EXE = "" EXEMODE = "755" EXTRAMACHDEPPATH = "" EXTRATESTOPTS = "" EXTRA_CFLAGS = "" EXT_SUFFIX = ".cpython-35m-darwin.so" FILEMODE = "644" FLOCK_NEEDS_LIBBSD = "0" GETPGRP_HAVE_ARG = "0" GETTIMEOFDAY_NO_TZ = "0" GNULD = "no" GRAMMAR_C = "Python/graminit.c" GRAMMAR_H = "Include/graminit.h" GRAMMAR_INPUT = "./Grammar/Grammar" HAVE_ACCEPT4 = "0" HAVE_ACOSH = "1" HAVE_ADDRINFO = "1" HAVE_ALARM = "1" HAVE_ALIGNED_REQUIRED = "0" HAVE_ALLOCA_H = "1" HAVE_ALTZONE = "0" HAVE_ASINH = "1" HAVE_ASM_TYPES_H = "0" HAVE_ATANH = "1" HAVE_BIND_TEXTDOMAIN_CODESET = "0" HAVE_BLUETOOTH_BLUETOOTH_H = "0" HAVE_BLUETOOTH_H = "0" HAVE_BROKEN_MBSTOWCS = "0" HAVE_BROKEN_NICE = "0" HAVE_BROKEN_PIPE_BUF = "0" HAVE_BROKEN_POLL = "0" HAVE_BROKEN_POSIX_SEMAPHORES = "0" HAVE_BROKEN_PTHREAD_SIGMASK = "0" HAVE_BROKEN_SEM_GETVALUE = "1" HAVE_BROKEN_UNSETENV = "0" HAVE_BUILTIN_ATOMIC = "1" HAVE_C99_BOOL = "1" HAVE_CHFLAGS = "1" HAVE_CHOWN = "1" HAVE_CHROOT = "1" HAVE_CLOCK = "1" HAVE_CLOCK_GETRES = "0" HAVE_CLOCK_GETTIME = "0" HAVE_COMPUTED_GOTOS = "1" HAVE_CONFSTR = "1" HAVE_CONIO_H = "0" HAVE_COPYSIGN = "1" HAVE_CTERMID = "1" HAVE_CTERMID_R = "1" HAVE_CURSES_H = "1" HAVE_CURSES_IS_TERM_RESIZED = "1" HAVE_CURSES_RESIZETERM = "1" HAVE_CURSES_RESIZE_TERM = "1" HAVE_DECL_ISFINITE = "1" HAVE_DECL_ISINF = "1" HAVE_DECL_ISNAN = "1" HAVE_DECL_TZNAME = "0" HAVE_DEVICE_MACROS = "1" HAVE_DEV_PTC = "0" HAVE_DEV_PTMX = "1" HAVE_DIRECT_H = "0" HAVE_DIRENT_D_TYPE = "1" HAVE_DIRENT_H = "1" HAVE_DIRFD = "1" HAVE_DLFCN_H = "1" HAVE_DLOPEN = "1" HAVE_DUP2 = "1" HAVE_DUP3 = "0" HAVE_DYNAMIC_LOADING = "1" HAVE_ENDIAN_H = "0" HAVE_EPOLL = "0" HAVE_EPOLL_CREATE1 = "0" HAVE_ERF = "1" HAVE_ERFC = "1" HAVE_ERRNO_H = "1" HAVE_EXECV = "1" HAVE_EXPM1 = "1" HAVE_FACCESSAT = "1" HAVE_FCHDIR = "1" HAVE_FCHMOD = "1" HAVE_FCHMODAT = "1" HAVE_FCHOWN = "1" HAVE_FCHOWNAT = "1" HAVE_FCNTL_H = "1" HAVE_FDATASYNC = "0" HAVE_FDOPENDIR = "1" HAVE_FEXECVE = "0" HAVE_FINITE = "1" HAVE_FLOCK = "1" HAVE_FORK = "1" HAVE_FORKPTY = "1" HAVE_FPATHCONF = "1" HAVE_FSEEK64 = "0" HAVE_FSEEKO = "1" HAVE_FSTATAT = "1" HAVE_FSTATVFS = "1" HAVE_FSYNC = "1" HAVE_FTELL64 = "0" HAVE_FTELLO = "1" HAVE_FTIME = "1" HAVE_FTRUNCATE = "1" HAVE_FUTIMENS = "0" HAVE_FUTIMES = "1" HAVE_FUTIMESAT = "0" HAVE_GAI_STRERROR = "1" HAVE_GAMMA = "1" HAVE_GCC_ASM_FOR_MC68881 = "0" HAVE_GCC_ASM_FOR_X64 = "1" HAVE_GCC_ASM_FOR_X87 = "1" HAVE_GCC_UINT128_T = "1" HAVE_GETADDRINFO = "1" HAVE_GETC_UNLOCKED = "1" HAVE_GETENTROPY = "0" HAVE_GETGROUPLIST = "1" HAVE_GETGROUPS = "1" HAVE_GETHOSTBYNAME = "1" HAVE_GETHOSTBYNAME_R = "0" HAVE_GETHOSTBYNAME_R_3_ARG = "0" HAVE_GETHOSTBYNAME_R_5_ARG = "0" HAVE_GETHOSTBYNAME_R_6_ARG = "0" HAVE_GETITIMER = "1" HAVE_GETLOADAVG = "1" HAVE_GETLOGIN = "1" HAVE_GETNAMEINFO = "1" HAVE_GETPAGESIZE = "1" HAVE_GETPEERNAME = "1" HAVE_GETPGID = "1" HAVE_GETPGRP = "1" HAVE_GETPID = "1" HAVE_GETPRIORITY = "1" HAVE_GETPWENT = "1" HAVE_GETRANDOM = "0" HAVE_GETRANDOM_SYSCALL = "0" HAVE_GETRESGID = "0" HAVE_GETRESUID = "0" HAVE_GETSID = "1" HAVE_GETSPENT = "0" HAVE_GETSPNAM = "0" HAVE_GETTIMEOFDAY = "1" HAVE_GETWD = "1" HAVE_GLIBC_MEMMOVE_BUG = "0" HAVE_GRP_H = "1" HAVE_HSTRERROR = "1" HAVE_HTOLE64 = "0" HAVE_HYPOT = "1" HAVE_IEEEFP_H = "0" HAVE_IF_NAMEINDEX = "1" HAVE_INET_ATON = "1" HAVE_INET_PTON = "1" HAVE_INITGROUPS = "1" HAVE_INT32_T = "1" HAVE_INT64_T = "1" HAVE_INTTYPES_H = "1" HAVE_IO_H = "0" HAVE_IPA_PURE_CONST_BUG = "0" HAVE_KILL = "1" HAVE_KILLPG = "1" HAVE_KQUEUE = "1" HAVE_LANGINFO_H = "1" HAVE_LARGEFILE_SUPPORT = "0" HAVE_LCHFLAGS = "1" HAVE_LCHMOD = "1" HAVE_LCHOWN = "1" HAVE_LGAMMA = "1" HAVE_LIBDL = "1" HAVE_LIBDLD = "0" HAVE_LIBIEEE = "0" HAVE_LIBINTL_H = "0" HAVE_LIBREADLINE = "1" HAVE_LIBRESOLV = "0" HAVE_LIBSENDFILE = "0" HAVE_LIBUTIL_H = "0" HAVE_LINK = "1" HAVE_LINKAT = "1" HAVE_LINUX_CAN_BCM_H = "0" HAVE_LINUX_CAN_H = "0" HAVE_LINUX_CAN_RAW_FD_FRAMES = "0" HAVE_LINUX_CAN_RAW_H = "0" HAVE_LINUX_NETLINK_H = "0" HAVE_LINUX_TIPC_H = "0" HAVE_LOCKF = "1" HAVE_LOG1P = "1" HAVE_LOG2 = "1" HAVE_LONG_DOUBLE = "1" HAVE_LONG_LONG = "1" HAVE_LSTAT = "1" HAVE_LUTIMES = "1" HAVE_MAKEDEV = "1" HAVE_MBRTOWC = "1" HAVE_MEMMOVE = "1" HAVE_MEMORY_H = "1" HAVE_MEMRCHR = "0" HAVE_MKDIRAT = "1" HAVE_MKFIFO = "1" HAVE_MKFIFOAT = "0" HAVE_MKNOD = "1" HAVE_MKNODAT = "0" HAVE_MKTIME = "1" HAVE_MMAP = "1" HAVE_MREMAP = "0" HAVE_NCURSES_H = "1" HAVE_NDIR_H = "0" HAVE_NETPACKET_PACKET_H = "0" HAVE_NET_IF_H = "1" HAVE_NICE = "1" HAVE_OPENAT = "1" HAVE_OPENPTY = "1" HAVE_OSX105_SDK = "1" HAVE_PATHCONF = "1" HAVE_PAUSE = "1" HAVE_PIPE2 = "0" HAVE_PLOCK = "0" HAVE_POLL = "1" HAVE_POLL_H = "1" HAVE_POSIX_FADVISE = "0" HAVE_POSIX_FALLOCATE = "0" HAVE_PREAD = "1" HAVE_PRLIMIT = "0" HAVE_PROCESS_H = "0" HAVE_PROTOTYPES = "1" HAVE_PTHREAD_ATFORK = "1" HAVE_PTHREAD_DESTRUCTOR = "0" HAVE_PTHREAD_H = "1" HAVE_PTHREAD_INIT = "0" HAVE_PTHREAD_KILL = "1" HAVE_PTHREAD_SIGMASK = "1" HAVE_PTY_H = "0" HAVE_PUTENV = "1" HAVE_PWRITE = "1" HAVE_RAND_EGD = "1" HAVE_READLINK = "1" HAVE_READLINKAT = "1" HAVE_READV = "1" HAVE_REALPATH = "1" HAVE_RENAMEAT = "1" HAVE_RL_APPEND_HISTORY = "1" HAVE_RL_CALLBACK = "1" HAVE_RL_CATCH_SIGNAL = "1" HAVE_RL_COMPLETION_APPEND_CHARACTER = "1" HAVE_RL_COMPLETION_DISPLAY_MATCHES_HOOK = "1" HAVE_RL_COMPLETION_MATCHES = "1" HAVE_RL_COMPLETION_SUPPRESS_APPEND = "1" HAVE_RL_PRE_INPUT_HOOK = "1" HAVE_ROUND = "1" HAVE_SCHED_GET_PRIORITY_MAX = "1" HAVE_SCHED_H = "1" HAVE_SCHED_RR_GET_INTERVAL = "0" HAVE_SCHED_SETAFFINITY = "0" HAVE_SCHED_SETPARAM = "0" HAVE_SCHED_SETSCHEDULER = "0" HAVE_SELECT = "1" HAVE_SEM_GETVALUE = "1" HAVE_SEM_OPEN = "1" HAVE_SEM_TIMEDWAIT = "0" HAVE_SEM_UNLINK = "1" HAVE_SENDFILE = "1" HAVE_SETEGID = "1" HAVE_SETEUID = "1" HAVE_SETGID = "1" HAVE_SETGROUPS = "1" HAVE_SETHOSTNAME = "1" HAVE_SETITIMER = "1" HAVE_SETLOCALE = "1" HAVE_SETPGID = "1" HAVE_SETPGRP = "1" HAVE_SETPRIORITY = "1" HAVE_SETREGID = "1" HAVE_SETRESGID = "0" HAVE_SETRESUID = "0" HAVE_SETREUID = "1" HAVE_SETSID = "1" HAVE_SETUID = "1" HAVE_SETVBUF = "1" HAVE_SHADOW_H = "0" HAVE_SIGACTION = "1" HAVE_SIGALTSTACK = "1" HAVE_SIGINTERRUPT = "1" HAVE_SIGNAL_H = "1" HAVE_SIGPENDING = "1" HAVE_SIGRELSE = "1" HAVE_SIGTIMEDWAIT = "0" HAVE_SIGWAIT = "1" HAVE_SIGWAITINFO = "0" HAVE_SNPRINTF = "1" HAVE_SOCKADDR_SA_LEN = "1" HAVE_SOCKADDR_STORAGE = "1" HAVE_SOCKETPAIR = "1" HAVE_SPAWN_H = "1" HAVE_SSIZE_T = "1" HAVE_STATVFS = "1" HAVE_STAT_TV_NSEC = "0" HAVE_STAT_TV_NSEC2 = "1" HAVE_STDARG_PROTOTYPES = "1" HAVE_STDINT_H = "1" HAVE_STDLIB_H = "1" HAVE_STD_ATOMIC = "0" HAVE_STRDUP = "1" HAVE_STRFTIME = "1" HAVE_STRINGS_H = "1" HAVE_STRING_H = "1" HAVE_STRLCPY = "1" HAVE_STROPTS_H = "0" HAVE_STRUCT_STAT_ST_BIRTHTIME = "1" HAVE_STRUCT_STAT_ST_BLKSIZE = "1" HAVE_STRUCT_STAT_ST_BLOCKS = "1" HAVE_STRUCT_STAT_ST_FLAGS = "1" HAVE_STRUCT_STAT_ST_GEN = "1" HAVE_STRUCT_STAT_ST_RDEV = "1" HAVE_STRUCT_TM_TM_ZONE = "1" HAVE_ST_BLOCKS = "1" HAVE_SYMLINK = "1" HAVE_SYMLINKAT = "1" HAVE_SYNC = "1" HAVE_SYSCONF = "1" HAVE_SYSEXITS_H = "1" HAVE_SYS_AUDIOIO_H = "0" HAVE_SYS_BSDTTY_H = "0" HAVE_SYS_DEVPOLL_H = "0" HAVE_SYS_DIR_H = "0" HAVE_SYS_ENDIAN_H = "0" HAVE_SYS_EPOLL_H = "0" HAVE_SYS_EVENT_H = "1" HAVE_SYS_FILE_H = "1" HAVE_SYS_IOCTL_H = "1" HAVE_SYS_KERN_CONTROL_H = "1" HAVE_SYS_LOADAVG_H = "0" HAVE_SYS_LOCK_H = "1" HAVE_SYS_MKDEV_H = "0" HAVE_SYS_MODEM_H = "0" HAVE_SYS_NDIR_H = "0" HAVE_SYS_PARAM_H = "1" HAVE_SYS_POLL_H = "1" HAVE_SYS_RESOURCE_H = "1" HAVE_SYS_SELECT_H = "1" HAVE_SYS_SENDFILE_H = "0" HAVE_SYS_SOCKET_H = "1" HAVE_SYS_STATVFS_H = "1" HAVE_SYS_STAT_H = "1" HAVE_SYS_SYSCALL_H = "1" HAVE_SYS_SYS_DOMAIN_H = "1" HAVE_SYS_TERMIO_H = "0" HAVE_SYS_TIMES_H = "1" HAVE_SYS_TIME_H = "1" HAVE_SYS_TYPES_H = "1" HAVE_SYS_UIO_H = "1" HAVE_SYS_UN_H = "1" HAVE_SYS_UTSNAME_H = "1" HAVE_SYS_WAIT_H = "1" HAVE_SYS_XATTR_H = "1" HAVE_TCGETPGRP = "1" HAVE_TCSETPGRP = "1" HAVE_TEMPNAM = "1" HAVE_TERMIOS_H = "1" HAVE_TERM_H = "1" HAVE_TGAMMA = "1" HAVE_TIMEGM = "1" HAVE_TIMES = "1" HAVE_TMPFILE = "1" HAVE_TMPNAM = "1" HAVE_TMPNAM_R = "0" HAVE_TM_ZONE = "1" HAVE_TRUNCATE = "1" HAVE_TZNAME = "0" HAVE_UCS4_TCL = "0" HAVE_UINT32_T = "1" HAVE_UINT64_T = "1" HAVE_UINTPTR_T = "1" HAVE_UNAME = "1" HAVE_UNISTD_H = "1" HAVE_UNLINKAT = "1" HAVE_UNSETENV = "1" HAVE_USABLE_WCHAR_T = "0" HAVE_UTIL_H = "1" HAVE_UTIMENSAT = "0" HAVE_UTIMES = "1" HAVE_UTIME_H = "1" HAVE_WAIT3 = "1" HAVE_WAIT4 = "1" HAVE_WAITID = "1" HAVE_WAITPID = "1" HAVE_WCHAR_H = "1" HAVE_WCSCOLL = "1" HAVE_WCSFTIME = "1" HAVE_WCSXFRM = "1" HAVE_WMEMCMP = "1" HAVE_WORKING_TZSET = "1" HAVE_WRITEV = "1" HAVE_ZLIB_COPY = "1" HAVE__GETPTY = "0" HGBRANCH = "" HGTAG = "" HGVERSION = "" HOST_GNU_TYPE = "x86_64-apple-darwin15.4.0" INCLDIRSTOMAKE = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/include /usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/include /usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/include/python3.5m /usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/include/python3.5m" INCLUDEDIR = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/include" INCLUDEPY = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/include/python3.5m" INSTALL = "/usr/bin/install -c" INSTALL_DATA = "/usr/bin/install -c -m 644" INSTALL_PROGRAM = "/usr/bin/install -c" INSTALL_SCRIPT = "/usr/bin/install -c" INSTALL_SHARED = "/usr/bin/install -c -m 555" INSTSONAME = "Python.framework/Versions/3.5/Python" IO_H = "Modules/_io/_iomodule.h" IO_OBJS = "\" LDCXXSHARED = "clang++ -bundle -undefined dynamic_lookup" LDFLAGS = "" LDLAST = "" LDLIBRARY = "Python.framework/Versions/3.5/Python" LDLIBRARYDIR = "" LDSHARED = "clang -bundle -undefined dynamic_lookup" LDVERSION = "3.5m" LIBC = "" LIBDEST = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.5" LIBDIR = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib" LIBFFI_INCLUDEDIR = "" LIBM = "" LIBOBJDIR = "Python/" LIBOBJS = "" LIBPC = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/pkgconfig" LIBPL = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.5/config-3.5m" LIBRARY = "libpython3.5m.a" LIBRARY_OBJS = "\" LIBRARY_OBJS_OMIT_FROZEN = "\" LIBS = "-ldl -framework CoreFoundation" LIBSUBDIRS = "tkinter tkinter/test tkinter/test/test_tkinter \" LINKCC = "clang" LINKFORSHARED = "-Wl,-stack_size,1000000 -framework CoreFoundation Python.framework/Versions/3.5/Python" LIPO_32BIT_FLAGS = "" LLVM_PROF_ERR = "yes" LLVM_PROF_FILE = "LLVM_PROFILE_FILE="code-%p.profclangr"" LLVM_PROF_MERGER = "llvm-profdata merge -output=code.profclangd *.profclangr" LN = "ln" LOCALMODLIBS = "" LOG1P_DROPS_ZERO_SIGN = "0" MACHDEP = "darwin" MACHDEPPATH = ":plat-darwin" MACHDEPS = "plat-darwin" MACHDEP_OBJS = "" MACHDESTLIB = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.5" MACOSX_DEPLOYMENT_TARGET = "10.11" MAINCC = "clang" MAJOR_IN_MKDEV = "0" MAJOR_IN_SYSMACROS = "0" MAKESETUP = "./Modules/makesetup" MANDIR = "/usr/local/Cellar/python3/3.5.1/share/man" MKDIR_P = "./install-sh -c -d" MODLIBS = "" MODOBJS = "Modules/_threadmodule.o Modules/signalmodule.o Modules/posixmodule.o Modules/errnomodule.o Modules/pwdmodule.o Modules/_sre.o Modules/_codecsmodule.o Modules/_weakref.o Modules/_functoolsmodule.o Modules/_operator.o Modules/_collectionsmodule.o Modules/itertoolsmodule.o Modules/atexitmodule.o Modules/_stat.o Modules/timemodule.o Modules/_localemodule.o Modules/_iomodule.o Modules/iobase.o Modules/fileio.o Modules/bytesio.o Modules/bufferedio.o Modules/textio.o Modules/stringio.o Modules/zipimport.o Modules/faulthandler.o Modules/_tracemalloc.o Modules/hashtable.o Modules/symtablemodule.o Modules/xxsubtype.o" MODULE_OBJS = "\" MULTIARCH = "" MVWDELCH_IS_EXPRESSION = "1" NO_AS_NEEDED = "" OBJECT_OBJS = "\" OPCODETARGETGEN = "\" OPCODETARGETGEN_FILES = "\" OPCODETARGETS_H = "\" OPCODE_H = "./Include/opcode.h" OPCODE_H_DIR = "./Include" OPCODE_H_GEN = "python ./Tools/scripts/generate_opcode_h.py ./Lib/opcode.py ./Include/opcode.h" OPCODE_H_SCRIPT = "./Tools/scripts/generate_opcode_h.py" OPT = "-DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes" OTHER_LIBTOOL_OPT = "" PACKAGE_BUGREPORT = "0" PACKAGE_NAME = "0" PACKAGE_STRING = "0" PACKAGE_TARNAME = "0" PACKAGE_URL = "0" PACKAGE_VERSION = "0" PARSER_HEADERS = "\" PARSER_OBJS = "\ Parser/myreadline.o Parser/parsetok.o Parser/tokenizer.o" PGEN = "Parser/pgen" PGENOBJS = "\ \" PGENSRCS = "\ \" PGOBJS = "\" PGO_PROF_GEN_FLAG = "-fprofile-instr-generate" PGO_PROF_USE_FLAG = "-fprofile-instr-use=code.profclangd" PGSRCS = "\" PLATDIR = "plat-darwin" POBJS = "\" POSIX_SEMAPHORES_NOT_ENABLED = "0" PROFILE_TASK = "-m test.regrtest --pgo" PSRCS = "\" PTHREAD_SYSTEM_SCHED_SUPPORTED = "1" PURIFY = "" PY3LIBRARY = "" PYLONG_BITS_IN_DIGIT = "0" PYTHON = "python" PYTHONFRAMEWORK = "Python" PYTHONFRAMEWORKDIR = "Python.framework" PYTHONFRAMEWORKINSTALLDIR = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework" PYTHONFRAMEWORKPREFIX = "/usr/local/Cellar/python3/3.5.1/Frameworks" PYTHONPATH = ":plat-darwin" PYTHON_FOR_BUILD = "./python.exe -E" PYTHON_HEADERS = "\" PYTHON_OBJS = "\" PY_CFLAGS = "-Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes" PY_CFLAGS_NODIST = "-Werror=declaration-after-statement" PY_CORE_CFLAGS = "-Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -I. -IInclude -I./Include -DPy_BUILD_CORE" PY_CPPFLAGS = "-I. -IInclude -I./Include" PY_FORMAT_LONG_LONG = ""ll"" PY_FORMAT_SIZE_T = ""z"" PY_LDFLAGS = "" Py_DEBUG = "0" Py_ENABLE_SHARED = "0" Py_HASH_ALGORITHM = "0" QUICKTESTOPTS = "-x test_subprocess test_io test_lib2to3 \" RANLIB = "ranlib" READELF = ":" RESSRCDIR = "Mac/Resources/framework" RETSIGTYPE = "void" RUNSHARED = "DYLD_FRAMEWORK_PATH=/private/tmp/python320160418-12904-1t6reri/Python-3.5.1" SCRIPTDIR = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib" SETPGRP_HAVE_ARG = "0" SGI_ABI = "" SHELL = "/bin/sh" SHLIBS = "-ldl -framework CoreFoundation" SHLIB_SUFFIX = ".so" SIGNAL_OBJS = "" SIGNED_RIGHT_SHIFT_ZERO_FILLS = "0" SITEPATH = "" SIZEOF_DOUBLE = "8" SIZEOF_FLOAT = "4" SIZEOF_FPOS_T = "8" SIZEOF_INT = "4" SIZEOF_LONG = "8" SIZEOF_LONG_DOUBLE = "16" SIZEOF_LONG_LONG = "8" SIZEOF_OFF_T = "8" SIZEOF_PID_T = "4" SIZEOF_PTHREAD_T = "8" SIZEOF_SHORT = "2" SIZEOF_SIZE_T = "8" SIZEOF_TIME_T = "8" SIZEOF_UINTPTR_T = "8" SIZEOF_VOID_P = "8" SIZEOF_WCHAR_T = "4" SIZEOF__BOOL = "1" SO = ".cpython-35m-darwin.so" SOABI = "cpython-35m-darwin" SRCDIRS = "Parser Grammar Objects Python Modules Mac Programs" SRC_GDB_HOOKS = "./Tools/gdb/libpython.py" STDC_HEADERS = "1" STRICT_SYSV_CURSES = "/* Don't use ncurses extensions */" STRIPFLAG = "-s" SUBDIRS = "" SUBDIRSTOO = "Include Lib Misc" SYSLIBS = "" SYS_SELECT_WITH_SYS_TIME = "1" TANH_PRESERVES_ZERO_SIGN = "1" TCLTK_INCLUDES = "" TCLTK_LIBS = "" TESTOPTS = "" TESTPATH = "" TESTPYTHON = "DYLD_FRAMEWORK_PATH=/private/tmp/python320160418-12904-1t6reri/Python-3.5.1 ./python.exe" TESTPYTHONOPTS = "" TESTRUNNER = "DYLD_FRAMEWORK_PATH=/private/tmp/python320160418-12904-1t6reri/Python-3.5.1 ./python.exe ./Tools/scripts/run_tests.py" TESTTIMEOUT = "3600" THREADOBJ = "Python/thread.o" TIMEMODULE_LIB = "0" TIME_WITH_SYS_TIME = "1" TM_IN_SYS_TIME = "0" UNICODE_DEPS = "\" UNIVERSALSDK = "" USE_COMPUTED_GOTOS = "0" USE_INLINE = "1" VA_LIST_IS_ARRAY = "1" VERSION = "3.5" WANT_SIGFPE_HANDLER = "0" WINDOW_HAS_FLAGS = "0" WITH_DOC_STRINGS = "1" WITH_DYLD = "1" WITH_LIBINTL = "0" WITH_NEXT_FRAMEWORK = "1" WITH_PYMALLOC = "1" WITH_THREAD = "1" WITH_TSC = "0" WITH_VALGRIND = "0" X87_DOUBLE_ROUNDING = "0" XMLLIBSUBDIRS = "xml xml/dom xml/etree xml/parsers xml/sax" abiflags = "m" abs_builddir = "/private/tmp/python320160418-12904-1t6reri/Python-3.5.1" abs_srcdir = "/private/tmp/python320160418-12904-1t6reri/Python-3.5.1" base = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5" datarootdir = "/usr/local/Cellar/python3/3.5.1/share" exec_prefix = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5" installed_base = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5" installed_platbase = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5" platbase = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5" prefix = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5" projectbase = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/bin" py_version = "3.5.1" py_version_nodot = "35" py_version_short = "3.5" srcdir = "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.5/config-3.5m" userbase = "/Users/jeremy/Library/Python/3.5" ---------- components: Tkinter messages: 269086 nosy: jeremyblow priority: normal severity: normal status: open title: Runaway memory consumption using update() type: resource usage versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 17:04:29 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Jun 2016 21:04:29 +0000 Subject: [issue27372] Test_idle should stop changing locale Message-ID: <1466629469.32.0.618350098053.issue27372@psf.upfronthosting.co.za> New submission from Terry J. Reedy: test.test_idle has long resulted in warnings about the locale being changed. In 3.6, this warning causes test_idle to be tagged a failure. Though this does not (yet) turn the overall run of a buildbot from green to red, it is annoying to have success reported as a failure. The culprit is in iomenu: locale.setlocale(locale.LC_CTYPE, "") Commenting it out removed the warning and tests pass. But I don't know the real effect, if it would work for tests on all systems, and the consequence when running IDLE normally. The problem cannot be monkey-patched away since the damage is done on import. Instead I added 'testing = False' to idlelib.__init__, made test_idle change it to True, and replace the locale-encoding code with "encoding = 'utf-8'" when testing is True. Serhiy, I *think* this is ready. However, another eagle-eye review would be welcome. Tests also pass with 'ascii'. Would that be better? --- Side note: the locale and encoding code could use a review from someone who knows more that me. For instance, suppressing ImportError here: try: import locale locale.setlocale(locale.LC_CTYPE, "") except (ImportError, locale.Error): pass guarantees a NameError a few lines further. There is another chunk labelled deprecated, and more might be obsolete in 3.x. But this is another issue. ---------- assignee: terry.reedy files: locale-change.diff keywords: patch messages: 269087 nosy: serhiy.storchaka, terry.reedy priority: normal severity: normal stage: patch review status: open title: Test_idle should stop changing locale type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file43516/locale-change.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 17:21:37 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Jun 2016 21:21:37 +0000 Subject: [issue27365] Allow non-ascii chars in IDLE NEWS.txt (for contributor names) In-Reply-To: <1466564645.25.0.829598827477.issue27365@psf.upfronthosting.co.za> Message-ID: <1466630497.9.0.85599879257.issue27365@psf.upfronthosting.co.za> Terry J. Reedy added the comment: As a practical matter, I have no plans to backport except in exceptional cases. If the regression had only affected 3.6, I would have left 2.7 and 3.5 alone. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 17:47:44 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Jun 2016 21:47:44 +0000 Subject: [issue27196] Eliminate 'ThemeChanged' warning when running IDLE tests In-Reply-To: <1464940807.02.0.170350027457.issue27196@psf.upfronthosting.co.za> Message-ID: <1466632064.74.0.76100256701.issue27196@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The only thing I still see is a pair of ThemeChanged warnings from 2.7. Using binary search, I identified test_editmenu as the culprit. This in spite of all the cleanup I can think of @classmethod def tearDownClass(cls): del cls.text, cls.entry, cls.spin cls.root.clipboard_clear() cls.root.update_idletasks() cls.root.update() cls.root.destroy() del cls.root When I tried to determine which test method(s) gave the warning, as disable all to make sure the warnings vanished, which then did. But after re-enabling, the warnings did not come back -- until they did after a few more runs. I suspect that the only permanent solution will be Serhiy's patch to have .destroy cancel pending callbacks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 17:55:10 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Jun 2016 21:55:10 +0000 Subject: [issue20350] Replace tkapp.split() to tkapp.splitlist() In-Reply-To: <1390411522.89.0.349086871577.issue20350@psf.upfronthosting.co.za> Message-ID: <1466632510.3.0.735261886099.issue20350@psf.upfronthosting.co.za> Terry J. Reedy added the comment: FWIW, patch applies cleanly to 3.6 on Windows and test_idle passes. ---------- versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 18:28:29 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 22 Jun 2016 22:28:29 +0000 Subject: [issue27362] json.dumps to check for obj.__json__ before raising TypeError In-Reply-To: <1466514558.58.0.537455774899.issue27362@psf.upfronthosting.co.za> Message-ID: <1466634509.94.0.542892098255.issue27362@psf.upfronthosting.co.za> R. David Murray added the comment: Pretty much any project that makes non-trivial use of json ends up implementing a jsonification protocol, usually by creating either a __json__ method or (more commonly, I think) a to_json method. But, yeah, this is python-ideas material and would get into the stdlib only as an officially blessed protocol, in which case using __json__ would make sense. So I'm going to close the issue pending a consensus on python-ideas. If it gets accepted the issue can be reopened. ---------- nosy: +r.david.murray resolution: -> later stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 18:53:48 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Jun 2016 22:53:48 +0000 Subject: [issue22115] Add new methods to trace Tkinter variables In-Reply-To: <1406818071.8.0.276271200629.issue22115@psf.upfronthosting.co.za> Message-ID: <1466636028.51.0.139656045457.issue22115@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I gather that 'add', 'delete', and 'info' replace 'variable', 'vdelete', and 'vinfo'. Also see review. Deprecation period should be fairly long. Of course, a currently hypothetical tcl/tk 9.0 with old stuff gone would make it immediate for users of 9.0. Applies cleanly and tests pass, but do not hardly interact with the patch. More importantly, IDLE starts fresh, option dialog comes up and appears to work. So old functions continue to work. The real test from IDLE would be to recode configdialog to use the new functions and then test. I am thinking about how to test configdialog enough that I am willing to refactor it for real. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 19:08:07 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 22 Jun 2016 23:08:07 +0000 Subject: [issue27369] [PATCH] Tests break with --with-system-expat and Expat 2.2.0 In-Reply-To: <1466619443.74.0.364754178665.issue27369@psf.upfronthosting.co.za> Message-ID: <1466636887.14.0.881488428712.issue27369@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for the patches. This test was added in r74435, presumably to test for a crash. IMO it would be sufficient to test for the first part of the error message, without checking the column number. The test could also use assertRaisesRegex(). Should this actually be applied to all security versions, or just 3.5+ and 2.7? I guess can see the benefit of fixing 3.2+, and I remember doing this once before when the test suite fell over and it was not Python?s fault. ---------- nosy: +martin.panter stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 19:50:10 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Jun 2016 23:50:10 +0000 Subject: [issue25588] Run test suite from IDLE idlelib.run subprocess In-Reply-To: <1447056283.03.0.330229894782.issue25588@psf.upfronthosting.co.za> Message-ID: <1466639410.98.0.125658419843.issue25588@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The premise of the issue is this: if IDLE is started with 'pythonx', then running 'filex' from a IDLE editor is equivalent to running "python x -i filex" at a command line. For instance, loading test.__main__ into an editor and running should give the same result as f:/python/dev> 36\pcbuild\win32\python_d.exe -i 36\Lib\test.__main__ However, Traceback (most recent call last): File "F:\Python\dev\36\Lib\test\__main__.py", line 2, in main() File "F:\Python\dev\36\lib\test\libregrtest\main.py", line 508, in main Regrtest().main(tests=tests, **kwargs) File "F:\Python\dev\36\lib\test\libregrtest\main.py", line 446, in main self._main(tests, kwargs) File "F:\Python\dev\36\lib\test\libregrtest\main.py", line 458, in _main setup_tests(self.ns) File "F:\Python\dev\36\lib\test\libregrtest\setup.py", line 18, in setup_tests faulthandler.enable(all_threads=True) io.UnsupportedOperation: fileno The pseudofile socket wrappers are not real files with a fileno. I should take a better look as sys.stdout and _stdout (and stderr) when connected to a console, ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 19:51:27 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Jun 2016 23:51:27 +0000 Subject: [issue25588] Run test suite from IDLE idlelib.run subprocess In-Reply-To: <1447056283.03.0.330229894782.issue25588@psf.upfronthosting.co.za> Message-ID: <1466639487.06.0.176284094388.issue25588@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: -Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 19:59:52 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Jun 2016 23:59:52 +0000 Subject: [issue27304] Create "Source Code" links in module sections, where relevant In-Reply-To: <1465791283.3.0.647535904935.issue27304@psf.upfronthosting.co.za> Message-ID: <1466639992.3.0.757681062527.issue27304@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Looks good at first review on Rietveld. Will test next. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 20:50:47 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 23 Jun 2016 00:50:47 +0000 Subject: [issue22228] Adapt bash readline operate-and-get-next function In-Reply-To: <1408441328.29.0.0681426449148.issue22228@psf.upfronthosting.co.za> Message-ID: <1466643047.83.0.153882025782.issue22228@psf.upfronthosting.co.za> Martin Panter added the comment: It looks like ctypes uses ffi_closure_alloc() to allocate an executable function on demand. So it should be possible for readline to also call libffi and do this, but certainly not trivial. >>> from ctypes import * >>> @CFUNCTYPE(c_int, c_int, c_int) ... def operate_and_get_next(count, char): ... print("Boo!", count, char) ... return 0 ... >>> libreadline = CDLL("libreadline.so.6") >>> libreadline.rl_add_defun("operate-and-get-next", operate_and_get_next, ord("O") & 0x1F) 0 >>> # Press Ctrl-O ==> Boo! 1 15 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 20:57:58 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 23 Jun 2016 00:57:58 +0000 Subject: [issue27370] Inconsistency in docs for list.extend In-Reply-To: <1466620140.79.0.360465596161.issue27370@psf.upfronthosting.co.za> Message-ID: <20160623005753.22331.98638.6326877C@psf.io> Roundup Robot added the comment: New changeset c91007ab3fda by Martin Panter in branch '2.7': Issue #27370: Use t for an iterable in mutable sequence ops https://hg.python.org/cpython/rev/c91007ab3fda ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 21:09:08 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 23 Jun 2016 01:09:08 +0000 Subject: [issue26243] zlib.compress level as keyword argument In-Reply-To: <1454179267.96.0.292283649228.issue26243@psf.upfronthosting.co.za> Message-ID: <1466644148.47.0.862313730257.issue26243@psf.upfronthosting.co.za> Martin Panter added the comment: The patch (with Berker?s fix) looks okay. Personally, I don?t see a big problem with the first argument also having a keyword name, but I don?t mind if it doesn?t either. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 21:11:07 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 23 Jun 2016 01:11:07 +0000 Subject: [issue27370] Inconsistency in docs for list.extend In-Reply-To: <1466620140.79.0.360465596161.issue27370@psf.upfronthosting.co.za> Message-ID: <1466644267.56.0.459041650643.issue27370@psf.upfronthosting.co.za> Martin Panter added the comment: The t vs x mixup was introduced by my sloppy backport in Issue 16701. The other problem here is x is generally defined as any arbitrary object, but redefined as an iterable in the footnote. I think we should use t instead, as in the other two slice assignment operations and in Python 3. My commit should have fixed both these problems. ---------- nosy: +martin.panter resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 22:47:16 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 23 Jun 2016 02:47:16 +0000 Subject: [issue27304] Create "Source Code" links in module sections, where relevant In-Reply-To: <1465791283.3.0.647535904935.issue27304@psf.upfronthosting.co.za> Message-ID: <20160623024713.657.65257.9783C8A4@psf.io> Roundup Robot added the comment: New changeset e3b4033e0ea7 by Terry Jan Reedy in branch '3.5': Issue #27304: Source code links for sub-packages in the same file. https://hg.python.org/cpython/rev/e3b4033e0ea7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 22:55:14 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 23 Jun 2016 02:55:14 +0000 Subject: [issue27304] Create "Source Code" links in module sections, where relevant In-Reply-To: <1465791283.3.0.647535904935.issue27304@psf.upfronthosting.co.za> Message-ID: <1466650514.16.0.500950108195.issue27304@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Three of the links are to one- or two- line modules that import the C implementation. I considered dropping them, but decided that the only way to know that they are not worth looking at is to let someone take a look. A counter argument is that we don't have links to CPython C implementations, and we could pretend that the Python wrappers are not there. Another core developer who feels strongly enough can remove the three. Thanks for the nice patch. I hope you do some more. ---------- resolution: -> fixed stage: -> resolved status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 22 23:30:24 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 23 Jun 2016 03:30:24 +0000 Subject: [issue26547] Undocumented use of the term dictproxy in vars() documentation In-Reply-To: <1457821404.83.0.465984707802.issue26547@psf.upfronthosting.co.za> Message-ID: <1466652624.53.0.459019569494.issue26547@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: -> patch review type: enhancement -> behavior versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 00:48:20 2016 From: report at bugs.python.org (Carol Willing) Date: Thu, 23 Jun 2016 04:48:20 +0000 Subject: [issue25572] _ssl doesn't build on OSX 10.11 In-Reply-To: <1446845399.36.0.0648529481801.issue25572@psf.upfronthosting.co.za> Message-ID: <1466657300.87.0.952318511368.issue25572@psf.upfronthosting.co.za> Carol Willing added the comment: After Ned's last message, perhaps it would be best to close this issue. ---------- nosy: +willingc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 00:49:57 2016 From: report at bugs.python.org (Carol Willing) Date: Thu, 23 Jun 2016 04:49:57 +0000 Subject: [issue8406] Make some setup.py paths exclude-able In-Reply-To: <1271301152.77.0.297402624492.issue8406@psf.upfronthosting.co.za> Message-ID: <1466657397.72.0.445941237407.issue8406@psf.upfronthosting.co.za> Carol Willing added the comment: This issue is languishing. Recommend closing the issue. ---------- nosy: +willingc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 00:51:11 2016 From: report at bugs.python.org (Carol Willing) Date: Thu, 23 Jun 2016 04:51:11 +0000 Subject: [issue8406] Make some setup.py paths exclude-able In-Reply-To: <1271301152.77.0.297402624492.issue8406@psf.upfronthosting.co.za> Message-ID: <1466657471.59.0.00672853720318.issue8406@psf.upfronthosting.co.za> Changes by Carol Willing : ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 00:52:27 2016 From: report at bugs.python.org (Carol Willing) Date: Thu, 23 Jun 2016 04:52:27 +0000 Subject: [issue11623] Distutils is reporting OSX 10.6 w/ XCode 4 as "universal" In-Reply-To: <1300725819.97.0.991086015608.issue11623@psf.upfronthosting.co.za> Message-ID: <1466657547.9.0.00114179258111.issue11623@psf.upfronthosting.co.za> Carol Willing added the comment: Closing this out of date issue. ---------- nosy: +willingc resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 00:53:51 2016 From: report at bugs.python.org (Carol Willing) Date: Thu, 23 Jun 2016 04:53:51 +0000 Subject: [issue5225] OS X "Update Shell Profile" may not update $PATH if run more than once In-Reply-To: <1234440346.58.0.444916712806.issue5225@psf.upfronthosting.co.za> Message-ID: <1466657631.33.0.580439790567.issue5225@psf.upfronthosting.co.za> Carol Willing added the comment: Closed as an out of date issue. ---------- nosy: +willingc resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 00:57:15 2016 From: report at bugs.python.org (Carol Willing) Date: Thu, 23 Jun 2016 04:57:15 +0000 Subject: [issue14354] Crash in _ctypes_alloc_callback In-Reply-To: <1332017744.32.0.532482393485.issue14354@psf.upfronthosting.co.za> Message-ID: <1466657835.98.0.167124714619.issue14354@psf.upfronthosting.co.za> Carol Willing added the comment: As per Ronald's last comment "close this as a duplicate of #16575 as that better explains the underlying problem". Closing this dated and duplicate issue. ---------- components: +Benchmarks -Macintosh, ctypes nosy: +brett.cannon, pitrou, willingc resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 00:59:22 2016 From: report at bugs.python.org (Carol Willing) Date: Thu, 23 Jun 2016 04:59:22 +0000 Subject: [issue16821] bundlebuilder broken in 2.7 In-Reply-To: <1356903579.79.0.644714985612.issue16821@psf.upfronthosting.co.za> Message-ID: <1466657962.19.0.110931208355.issue16821@psf.upfronthosting.co.za> Carol Willing added the comment: Closed as an out of date issue. ---------- nosy: +willingc resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 01:00:46 2016 From: report at bugs.python.org (Carol Willing) Date: Thu, 23 Jun 2016 05:00:46 +0000 Subject: [issue13759] Python 3.2.2 Mac installer version doesn't accept multibyte character in interactive mode In-Reply-To: <1326267416.18.0.541225422796.issue13759@psf.upfronthosting.co.za> Message-ID: <1466658046.08.0.479470869975.issue13759@psf.upfronthosting.co.za> Carol Willing added the comment: Ned, Closing as an out of date issue. ---------- nosy: +willingc resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 01:03:36 2016 From: report at bugs.python.org (Carol Willing) Date: Thu, 23 Jun 2016 05:03:36 +0000 Subject: [issue13829] exception error in _scproxy.so In-Reply-To: <1326998522.6.0.790472668429.issue13829@psf.upfronthosting.co.za> Message-ID: <1466658216.89.0.829113126649.issue13829@psf.upfronthosting.co.za> Carol Willing added the comment: Closed as an out of date issue. ---------- nosy: +willingc resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 01:09:51 2016 From: report at bugs.python.org (Carol Willing) Date: Thu, 23 Jun 2016 05:09:51 +0000 Subject: [issue21106] Updated Mac folder icon In-Reply-To: <1396214057.84.0.0230664527626.issue21106@psf.upfronthosting.co.za> Message-ID: <1466658591.2.0.0246864246685.issue21106@psf.upfronthosting.co.za> Carol Willing added the comment: Closing as an out of date issue (greater than 2 years old). ---------- nosy: +willingc resolution: -> out of date stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 02:00:46 2016 From: report at bugs.python.org (Caleb Hattingh) Date: Thu, 23 Jun 2016 06:00:46 +0000 Subject: [issue25572] _ssl doesn't build on OSX 10.11 In-Reply-To: <1446845399.36.0.0648529481801.issue25572@psf.upfronthosting.co.za> Message-ID: <1466661646.15.0.292890045343.issue25572@psf.upfronthosting.co.za> Caleb Hattingh added the comment: I struggled with this issue, and eventually found the recommendations about linking with homebrew's OpenSSL on StackOverflow or similar, and then only later found this issue here (and with it the link to the devguide); but the *first* places I looked were the README in the source root, and then the README in the Mac/ directory. That may however just be ignorance on my part of where I should have been looking. Yet another reminder that I need to become much more familiar with the devguide. The README only mentions the devguide in the context of contributing, but not that it will contain further information required for building. Under "Build Instructions", the README says: *** Build Instructions ------------------ On Unix, Linux, BSD, OSX, and Cygwin: ./configure make make test sudo make install This will install Python as python3. You can pass many options to the configure script; run "./configure --help" to find out more. On OSX and Cygwin, the executable is called python.exe; elsewhere it's just python. On Mac OS X, if you have configured Python with --enable-framework, you should use "make frameworkinstall" to do the installation. Note that this installs the Python executable in a place that is not normally on your PATH, you may want to set up a symlink in /usr/local/bin. *** It might be helpful to add to the README (in the "Build Instructions" section): "The devguide may include further information about specific build dependencies for your platform here: https://docs.python.org/devguide/setup.html#build-dependencies" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 03:24:38 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Jun 2016 07:24:38 +0000 Subject: [issue14061] Misc fixes and cleanups in archiving code in shutil and test_shutil In-Reply-To: <1329705067.15.0.02936958618.issue14061@psf.upfronthosting.co.za> Message-ID: <1466666678.31.0.477546203435.issue14061@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- versions: -Python 3.4 Added file: http://bugs.python.org/file43517/shutil_make_archive_misc_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 04:21:31 2016 From: report at bugs.python.org (SilentGhost) Date: Thu, 23 Jun 2016 08:21:31 +0000 Subject: [issue27371] Runaway memory consumption using update() In-Reply-To: <1466629289.92.0.827863623566.issue27371@psf.upfronthosting.co.za> Message-ID: <1466670091.32.0.0224255057128.issue27371@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +gpolo, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 05:04:31 2016 From: report at bugs.python.org (=?utf-8?b?5ZC05YaJ5rOi?=) Date: Thu, 23 Jun 2016 09:04:31 +0000 Subject: [issue27373] logging.handlers.SysLogHandler with TCP not working on rsyslog5.8 Message-ID: <1466672671.84.0.9141309622.issue27373@psf.upfronthosting.co.za> New submission from ???: logging.handlers.SysLogHandler with TCP not working on rsyslog5.8, but newer version rsyslog8.19 is fine. I use SysLogHandler with TCP to send message to remote rsyslog server failed, but success with bash below: echo "<133>$0[$$]: Test syslog message from Netcat" | nc -w1 -t 192.168.1.23 514 this is my script: #!/usr/bin/env python # -*- coding: utf-8 -*- import logging import logging.handlers import socket import syslog my_logger = logging.getLogger('MyLogger') # logger is singleton my_logger.setLevel(logging.DEBUG) if __name__ == '__main__': handler = logging.handlers.SysLogHandler(address=('192.168.1.23', 514), facility="auth", socktype=socket.SOCK_STREAM) my_logger.addHandler(handler) my_logger.critical('this is critical') handler.flush() handler.close() my_logger.removeHandler(handler) CentOS version is 6.6 Python version is 2.7.10 This is easy to repeat on my serval CentOS Server. And I attach tcpdump result of script and bash. ---------- components: Library (Lib) files: fail.log messages: 269112 nosy: vinay.sajip, ??? priority: normal severity: normal status: open title: logging.handlers.SysLogHandler with TCP not working on rsyslog5.8 type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file43518/fail.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 05:30:49 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 23 Jun 2016 09:30:49 +0000 Subject: [issue14354] Crash in _ctypes_alloc_callback In-Reply-To: <1332017744.32.0.532482393485.issue14354@psf.upfronthosting.co.za> Message-ID: <1466674249.0.0.320295512677.issue14354@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- components: +ctypes -Benchmarks stage: -> resolved superseder: -> ctypes: unions as arguments _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 10:35:27 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 23 Jun 2016 14:35:27 +0000 Subject: [issue27363] Complex with negative zero imaginary part In-Reply-To: <1466535728.31.0.514028528898.issue27363@psf.upfronthosting.co.za> Message-ID: <1466692527.99.0.045745347657.issue27363@psf.upfronthosting.co.za> R. David Murray added the comment: Breaking the repr invariant would be bad. Agree with rejection. ---------- nosy: +r.david.murray resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 10:41:14 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 23 Jun 2016 14:41:14 +0000 Subject: [issue27364] Deprecate invalid unicode escape sequences In-Reply-To: <1466541260.02.0.320668077341.issue27364@psf.upfronthosting.co.za> Message-ID: <1466692874.19.0.19972189474.issue27364@psf.upfronthosting.co.za> R. David Murray added the comment: Have you searched the python-dev and python-ideas archives for the previous discussions of this issue? I don't remember for sure, but I think Guido might have made a ruling (not that the discussion couldn't be reopened if he has, but, well...) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 10:47:06 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 23 Jun 2016 14:47:06 +0000 Subject: [issue27033] Change the decode_data default in smtpd to False In-Reply-To: <1463340039.51.0.670985844702.issue27033@psf.upfronthosting.co.za> Message-ID: <1466693226.29.0.680786942491.issue27033@psf.upfronthosting.co.za> R. David Murray added the comment: Yes. Thanks, Serhiy. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 11:20:38 2016 From: report at bugs.python.org (Erik Bray) Date: Thu, 23 Jun 2016 15:20:38 +0000 Subject: [issue27374] Cygwin: Makefile does not install DLL import library Message-ID: <1466695238.23.0.601958974473.issue27374@psf.upfronthosting.co.za> New submission from Erik Bray: When building Python on Cygwin, both a libpython-X.Y.dll and a libpython-X.Y.dll.a are created (see https://cygwin.com/cygwin-ug-net/dll.html). The latter is an "import library" consisting of stubs for functions in the DLL so that it can be linked to statically when building, for example, extension modules. The odd bit is that in the altbininstall target if the $(DLLLIBRARY) variable (which references the .dll itself) is defined then only it is installed, while $(LDLIBRARY) (which in this cases references the .dll.a import library) is *not* installed, except in $(prefix)/lib/pythonX.Y/config, which is not normally on the linker search path, or even included by python-config --ldflags. Therefore static linking to libpython fails, unless the search path is explicitly modified, or a symlink is created from $(prefix)/lib/pythonX.Y/config/libpython.dll.a to $(prefix)/lib. In fact the Makefile already does the latter, again not if $(DLLLIBRARY) is defined. In fact Cygwin's own package for Python manually creates the latter symlink in its install script. But I would consider it a bug in Python's Makefile that it doesn't handle this. I first asked on Python-dev about this back in April but got no reply (understandably) probably due to the lack of core devs who can comment on Cygwin :) ---------- components: Installation files: cygwin-ldlibrary.patch keywords: patch messages: 269116 nosy: erik.bray priority: normal severity: normal status: open title: Cygwin: Makefile does not install DLL import library type: behavior Added file: http://bugs.python.org/file43519/cygwin-ldlibrary.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 11:24:39 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 23 Jun 2016 15:24:39 +0000 Subject: [issue27344] zipfile *does* support utf-8 filenames In-Reply-To: <1466176126.21.0.0133629365393.issue27344@psf.upfronthosting.co.za> Message-ID: <1466695479.82.0.206684229247.issue27344@psf.upfronthosting.co.za> R. David Murray added the comment: OK, what do you propose as a documentation change? The current doc is accurate, but incomplete. New phrasing could include something about the two de-facto standards but that one can not be sure that filenames will be in one of those two encodings. Issue 10614 addresses the fact that the zipfile module doesn't make it easy to specify the encoding of filenames when creating an archive, IIUC, which also still needs to be addressed in any documentation change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 11:25:51 2016 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 23 Jun 2016 15:25:51 +0000 Subject: [issue27373] logging.handlers.SysLogHandler with TCP not working on rsyslog5.8 In-Reply-To: <1466672671.84.0.9141309622.issue27373@psf.upfronthosting.co.za> Message-ID: <1466695551.62.0.97019479409.issue27373@psf.upfronthosting.co.za> Vinay Sajip added the comment: If it works fine with rsyslog 8.19 but fails with rsyslog 5.8, what exactly is logging doing wrong? How is rsyslog configured in the two cases? How exactly was the fail.log generated (I know you said tcpdump was used, but can you provide more detail)? I'm not sure I'll be able to reproduce this, so you may need to identify what you think logging is doing wrong (there have been no changes in SysLogHandler for quite a while, AFAIK). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 11:26:16 2016 From: report at bugs.python.org (Emanuel Barry) Date: Thu, 23 Jun 2016 15:26:16 +0000 Subject: [issue27364] Deprecate invalid unicode escape sequences In-Reply-To: <1466541260.02.0.320668077341.issue27364@psf.upfronthosting.co.za> Message-ID: <1466695576.46.0.435912911828.issue27364@psf.upfronthosting.co.za> Emanuel Barry added the comment: Now I have! I found nothing on Python-Dev, but apparently it's been discussed on Python-ideas before: https://mail.python.org/pipermail/python-ideas/2015-August/035031.html Guido hasn't participated in that discussion, and most of it was "This will break people's code", with people both for and against the idea, without an apparent consensus. Should I try a second round on Python-ideas, to try and get a consensus (or a BDFL ruling)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 11:46:24 2016 From: report at bugs.python.org (Daniel Holth) Date: Thu, 23 Jun 2016 15:46:24 +0000 Subject: [issue27344] zipfile *does* support utf-8 filenames In-Reply-To: <1466176126.21.0.0133629365393.issue27344@psf.upfronthosting.co.za> Message-ID: <1466696784.31.0.0667812978991.issue27344@psf.upfronthosting.co.za> Daniel Holth added the comment: The current documentation says "Note There is no official file name encoding for ZIP files. If you have unicode file names, you must convert them to byte strings in your desired encoding before passing them to write(). WinZip interprets all file names as encoded in CP437, also known as DOS Latin." This is bad advice because if you convert the filenames to bytes before passing them to zipfile, it won't remember that they should be unicode. Instead it should say "The ZIP file format supports Unicode filenames. If you have unicode filenames, zipfile will encode them to and from utf-8 internally. If you pass bytes filenames to write() then they will be stored without a specified encoding." I am not sure what current versions of WinZip or Windows file manager do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 11:47:29 2016 From: report at bugs.python.org (Daniel Holth) Date: Thu, 23 Jun 2016 15:47:29 +0000 Subject: [issue27344] zipfile *does* support utf-8 filenames In-Reply-To: <1466176126.21.0.0133629365393.issue27344@psf.upfronthosting.co.za> Message-ID: <1466696849.98.0.303922499992.issue27344@psf.upfronthosting.co.za> Daniel Holth added the comment: " ... zipfile will encode them to and from utf-8 internally, and the encoding is marked in a standard flag inside the archive member." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 11:59:29 2016 From: report at bugs.python.org (Antti Haapala) Date: Thu, 23 Jun 2016 15:59:29 +0000 Subject: [issue27364] Deprecate invalid unicode escape sequences In-Reply-To: <1466541260.02.0.320668077341.issue27364@psf.upfronthosting.co.za> Message-ID: <1466697569.5.0.892089985505.issue27364@psf.upfronthosting.co.za> Antti Haapala added the comment: it is handy to be able to use `\w` and `\d` in non-raw-string *regular expressions*, without too much backslashitis. Seems to be in use in Python standard library as well, for example in csv.py ---------- nosy: +ztane _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 12:08:32 2016 From: report at bugs.python.org (Daniel Holth) Date: Thu, 23 Jun 2016 16:08:32 +0000 Subject: [issue27344] zipfile *does* support utf-8 filenames In-Reply-To: <1466176126.21.0.0133629365393.issue27344@psf.upfronthosting.co.za> Message-ID: <1466698112.8.0.958381304649.issue27344@psf.upfronthosting.co.za> Daniel Holth added the comment: The documentation should read The ZIP file format supports Unicode filenames. If you have unicode filenames, zipfile will encode them to and from utf-8 internally, but if you pass bytes filenames to write() then they will be stored without a specified encoding. Even though the format itself supports Unicode, historically Windows' built-in ZIP utility has interpreted all ZIP filenames as CP437 also known as DOS Latin. There is a fix from Microsoft for Windows 7 available here: https://support.microsoft.com/en-us/kb/2704299 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 12:33:32 2016 From: report at bugs.python.org (raphi rose) Date: Thu, 23 Jun 2016 16:33:32 +0000 Subject: [issue27375] error in "make test", while trying to install python on linux computer Message-ID: <1466699612.27.0.651436554447.issue27375@psf.upfronthosting.co.za> New submission from raphi rose: I am using ubuntu 14.04, and I am trying to install a newer version of python, instead of 2.7.6 I'm trying to use 3.5.1. to do this I downloaded the tar.xz file, extracted it to a directory in my computer (not the /usr/local/bin/). I then went into the terminal and changed to the directory it was in, used $./configure, $make, $make test, and in the test it came up with an error, i then did $make testall, same error, finally i used $./python -m test -v test_nntplib, and it came up with this: == CPython 3.5.1 (default, Jun 23 2016, 10:51:23) [GCC 4.8.4] == Linux-3.13.0-88-generic-x86_64-with-debian-jessie-sid little-endian == hash algorithm: siphash24 64bit == /home/rrose/temp/Python-3.5.1/build/test_python_18970 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0) [1/1] test_nntplib test_caps_only_after_login (test.test_nntplib.CapsAfterLoginNNTPv2Tests) ... ok test_decode_header (test.test_nntplib.MiscTests) ... ok test_parse_datetime (test.test_nntplib.MiscTests) ... ok test_parse_overview (test.test_nntplib.MiscTests) ... ok test_parse_overview_fmt (test.test_nntplib.MiscTests) ... ok test_ssl_support (test.test_nntplib.MiscTests) ... skipped 'requires SSL support' test_unparse_datetime (test.test_nntplib.MiscTests) ... ok test_unparse_datetime_legacy (test.test_nntplib.MiscTests) ... ok test_bad_capabilities (test.test_nntplib.MockSocketTests) ... ok test_bad_welcome (test.test_nntplib.MockSocketTests) ... ok test_login_aborted (test.test_nntplib.MockSocketTests) ... ok test_service_permanently_unavailable (test.test_nntplib.MockSocketTests) ... ok test_service_temporarily_unavailable (test.test_nntplib.MockSocketTests) ... ok test_bad_capabilities (test.test_nntplib.MockSslTests) ... skipped 'requires SSL support' test_bad_welcome (test.test_nntplib.MockSslTests) ... skipped 'requires SSL support' test_login_aborted (test.test_nntplib.MockSslTests) ... skipped 'requires SSL support' test_service_permanently_unavailable (test.test_nntplib.MockSslTests) ... skipped 'requires SSL support' test_service_temporarily_unavailable (test.test_nntplib.MockSslTests) ... skipped 'requires SSL support' test_article (test.test_nntplib.NNTPv1Tests) ... ok test_article_file (test.test_nntplib.NNTPv1Tests) ... ok test_authinfo (test.test_nntplib.NNTPv1Tests) ... ok test_body (test.test_nntplib.NNTPv1Tests) ... ok test_body_file (test.test_nntplib.NNTPv1Tests) ... ok test_caps (test.test_nntplib.NNTPv1Tests) ... ok test_date (test.test_nntplib.NNTPv1Tests) ... ok test_description (test.test_nntplib.NNTPv1Tests) ... ok test_descriptions (test.test_nntplib.NNTPv1Tests) ... ok test_group (test.test_nntplib.NNTPv1Tests) ... ok test_head (test.test_nntplib.NNTPv1Tests) ... ok test_head_file (test.test_nntplib.NNTPv1Tests) ... ok test_help (test.test_nntplib.NNTPv1Tests) ... ok test_ihave (test.test_nntplib.NNTPv1Tests) ... ok test_last (test.test_nntplib.NNTPv1Tests) ... ok test_list (test.test_nntplib.NNTPv1Tests) ... ok test_newnews (test.test_nntplib.NNTPv1Tests) ... ok test_next (test.test_nntplib.NNTPv1Tests) ... ok test_over (test.test_nntplib.NNTPv1Tests) ... ok test_post (test.test_nntplib.NNTPv1Tests) ... ok test_quit (test.test_nntplib.NNTPv1Tests) ... ok test_stat (test.test_nntplib.NNTPv1Tests) ... ok test_too_long_lines (test.test_nntplib.NNTPv1Tests) ... ok test_welcome (test.test_nntplib.NNTPv1Tests) ... ok test_xover (test.test_nntplib.NNTPv1Tests) ... ok test_article (test.test_nntplib.NNTPv2Tests) ... ok test_article_file (test.test_nntplib.NNTPv2Tests) ... ok test_authinfo (test.test_nntplib.NNTPv2Tests) ... ok test_body (test.test_nntplib.NNTPv2Tests) ... ok test_body_file (test.test_nntplib.NNTPv2Tests) ... ok test_caps (test.test_nntplib.NNTPv2Tests) ... ok test_date (test.test_nntplib.NNTPv2Tests) ... ok test_description (test.test_nntplib.NNTPv2Tests) ... ok test_descriptions (test.test_nntplib.NNTPv2Tests) ... ok test_group (test.test_nntplib.NNTPv2Tests) ... ok test_head (test.test_nntplib.NNTPv2Tests) ... ok test_head_file (test.test_nntplib.NNTPv2Tests) ... ok test_help (test.test_nntplib.NNTPv2Tests) ... ok test_ihave (test.test_nntplib.NNTPv2Tests) ... ok test_last (test.test_nntplib.NNTPv2Tests) ... ok test_list (test.test_nntplib.NNTPv2Tests) ... ok test_newnews (test.test_nntplib.NNTPv2Tests) ... ok test_next (test.test_nntplib.NNTPv2Tests) ... ok test_over (test.test_nntplib.NNTPv2Tests) ... ok test_post (test.test_nntplib.NNTPv2Tests) ... ok test_quit (test.test_nntplib.NNTPv2Tests) ... ok test_stat (test.test_nntplib.NNTPv2Tests) ... ok test_too_long_lines (test.test_nntplib.NNTPv2Tests) ... ok test_welcome (test.test_nntplib.NNTPv2Tests) ... ok test_xover (test.test_nntplib.NNTPv2Tests) ... ok skipped "Use of the 'network' resource not enabled" test_module_all_attribute (test.test_nntplib.PublicAPITests) ... ok test_we_are_in_reader_mode_after_connect (test.test_nntplib.SendReaderNNTPv2Tests) ... ok ---------------------------------------------------------------------- Ran 70 tests in 0.035s OK (skipped=7) 1 test OK. if anyone could tell me how to fix this that would be great, thanks! ---------- components: Build, Installation, Tests messages: 269124 nosy: raphros priority: normal severity: normal status: open title: error in "make test", while trying to install python on linux computer type: compile error versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 12:36:34 2016 From: report at bugs.python.org (INADA Naoki) Date: Thu, 23 Jun 2016 16:36:34 +0000 Subject: [issue27350] Compact and ordered dict In-Reply-To: <1466307796.29.0.980579044792.issue27350@psf.upfronthosting.co.za> Message-ID: <1466699794.2.0.506301661592.issue27350@psf.upfronthosting.co.za> Changes by INADA Naoki : Added file: http://bugs.python.org/file43520/compact-dict.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 12:37:19 2016 From: report at bugs.python.org (raphi rose) Date: Thu, 23 Jun 2016 16:37:19 +0000 Subject: [issue27375] error in "make test", while trying to install python on linux computer In-Reply-To: <1466699612.27.0.651436554447.issue27375@psf.upfronthosting.co.za> Message-ID: <1466699839.26.0.0532724330784.issue27375@psf.upfronthosting.co.za> Changes by raphi rose : ---------- components: -Tests _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 12:42:03 2016 From: report at bugs.python.org (Stefan Krah) Date: Thu, 23 Jun 2016 16:42:03 +0000 Subject: [issue27375] error in "make test", while trying to install python on linux computer In-Reply-To: <1466699612.27.0.651436554447.issue27375@psf.upfronthosting.co.za> Message-ID: <1466700123.05.0.177323733733.issue27375@psf.upfronthosting.co.za> Stefan Krah added the comment: You need to install at least these development libraries: sudo apt-get install libssl-dev liblzma-dev libbz2-dev libreadline-dev libgdbm-dev libffi-dev Possibly some are missing in this list, tkinter and zip for example. Use "apt-cache search tkinter" to figure out the name of the library, always use the "dev" versions. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 13:03:02 2016 From: report at bugs.python.org (Jaysinh shukla) Date: Thu, 23 Jun 2016 17:03:02 +0000 Subject: [issue20842] pkgutil docs should reference glossary terms not PEP 302 In-Reply-To: <1393846400.67.0.723549613222.issue20842@psf.upfronthosting.co.za> Message-ID: <1466701382.45.0.604751170527.issue20842@psf.upfronthosting.co.za> Jaysinh shukla added the comment: Submitting the patch for this issue. I observed the last message of respected Kushal but because the message was posted too earlier decided to submit patch. Thanks! ---------- keywords: +patch nosy: +jaysinh.shukla Added file: http://bugs.python.org/file43521/issue20842_v1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 13:12:17 2016 From: report at bugs.python.org (Eyal Posener) Date: Thu, 23 Jun 2016 17:12:17 +0000 Subject: [issue27376] Add mock_import method to mock module Message-ID: <1466701937.33.0.949904358819.issue27376@psf.upfronthosting.co.za> New submission from Eyal Posener: Add mock_import method. A helper function to mask ``ImportError``s on a scoped code, using the ``with`` statement, or in method a method used as a decorator. Failed imports will be ignored, unless specified by the *do_not_mock* argument. The *do_not_mock* argument is a package or module name, or package or module names list. When specified, and imported in the scoped mocked code, importing them must succeed. If ``None`` (the default) then no import must succeed. ---------- components: Library (Lib) files: mock_import.patch keywords: patch messages: 269127 nosy: Eyal Posener priority: normal severity: normal status: open title: Add mock_import method to mock module type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43522/mock_import.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 13:49:07 2016 From: report at bugs.python.org (raphi rose) Date: Thu, 23 Jun 2016 17:49:07 +0000 Subject: [issue27375] error in "make test", while trying to install python on linux computer In-Reply-To: <1466699612.27.0.651436554447.issue27375@psf.upfronthosting.co.za> Message-ID: <1466704147.7.0.64506695896.issue27375@psf.upfronthosting.co.za> raphi rose added the comment: the only one listed as dev was "tcl-snack-dev - Sound extension to Tcl/Tk and Python/Tkinter - development files," or instead of doing that one should i just use "python3-tk - Tkinter - Writing Tk applications with Python 3.x" and put a "-dev" at the end of the command? also, I'm a bit confused, should i only be looking at ones that have "lib" at the beginning? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 14:06:17 2016 From: report at bugs.python.org (Ryan Petrello) Date: Thu, 23 Jun 2016 18:06:17 +0000 Subject: [issue27172] Add skip_bound_arg argument to inspect.Signature.from_callable() In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za> Message-ID: <1466705177.65.0.0133504280643.issue27172@psf.upfronthosting.co.za> Ryan Petrello added the comment: Nick, That seems reasonable to me :) I've updated my library to just use inspect.getfullargspec for Py3. Thanks for taking the time to walk through this with me! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 14:18:21 2016 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 23 Jun 2016 18:18:21 +0000 Subject: [issue27172] Undeprecate inspect.getfullargspec() In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za> Message-ID: <1466705901.74.0.206595858814.issue27172@psf.upfronthosting.co.za> Nick Coghlan added the comment: OK, as per the above discussion, I've changed the title of this issue to be to undeprecate inspect.getfullargspec(). That change involves two pieces: - change the documented deprecation of inspect.getfullargspec() to instead be a recommendation to avoid using it in new code, and instead use inspect.signature() - update the inspect.getargspec() documentation and programmatic deprecation warning to point to both inspect.signature() and inspect.getfullargspec() as potential replacements That gives folks already using inspect.getfullargspec assurance that it isn't going away anytime soon (if ever), while folks using inspect.getargspec get a lower impact migration path to a more Python 3 friendly version of the callable introspection API. ---------- title: Add skip_bound_arg argument to inspect.Signature.from_callable() -> Undeprecate inspect.getfullargspec() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 14:33:36 2016 From: report at bugs.python.org (Neil Schemenauer) Date: Thu, 23 Jun 2016 18:33:36 +0000 Subject: [issue27377] Add smarter socket.fromfd() Message-ID: <1466706816.6.0.72770597716.issue27377@psf.upfronthosting.co.za> New submission from Neil Schemenauer: When implementing server software that inherits a socket via a file descriptor, it is useful to be able to query the descriptor and find out what kind of socket has been passed. This can be done with getsockopt() and getsockname(). Python does not expose a clean way to do this. One example use case is receiving an open socket from systemd. For example, systemd will pass the open socket using file descriptor 3. It would be handy if the Python server did not have to hard-code the type of the socket but instead could determine it. This patch provides a function that, when given an integer file descriptor, returns a Python socket object with the correct family and kind/type attributes. This seems like a useful, high-level interface. This patch adds two new functions to the socket module. I'm not so happy about the names. Suggestions welcome. The fromfd2() function does not duplicate the file descriptor. I think this was a design mistake in fromfd(). If it wasn't for the duplication, I would change fromfd() to have None as default arguments and then use fdtype() to get the family, kind and protocol. The fdtype() function returns (family, type, proto) for an integer file descriptor. There does not appear to be any way to query the protocol of the passed socket. I just assume it is zero. ---------- components: Library (Lib) files: fromfd2.txt messages: 269131 nosy: nascheme priority: normal severity: normal stage: patch review status: open title: Add smarter socket.fromfd() type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43523/fromfd2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 14:36:35 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 23 Jun 2016 18:36:35 +0000 Subject: [issue20674] Update comments in dictobject.c In-Reply-To: <1392744795.57.0.649500024154.issue20674@psf.upfronthosting.co.za> Message-ID: <1466706995.11.0.393515805656.issue20674@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Completely remove all reference to strings as it is normally completely wrong. In three runs of list(map(hash, ("namea", "nameb", "namec", "named"))) I get [-7801965690653662103, -712276634514874737, 4394438508544812081, -6975951345912708912] [-1171799829, 419385606, 1995488749, 1433346153] [551304887, -285234584, -553876274, -279423320] Rewrite for ints only. I am willing to apply, but cannot patch 3.4, so Raymond, if you want that, you will have to do it. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 14:55:13 2016 From: report at bugs.python.org (Stefan Krah) Date: Thu, 23 Jun 2016 18:55:13 +0000 Subject: [issue27375] error in "make test", while trying to install python on linux computer In-Reply-To: <1466699612.27.0.651436554447.issue27375@psf.upfronthosting.co.za> Message-ID: <1466708113.0.0.561464699338.issue27375@psf.upfronthosting.co.za> Stefan Krah added the comment: I think you need tcl8.4-dev and tk8.4-dev and perhaps zlib1g-dev. Actually the point is that it's expected that some modules don't build if the corresponding libraries aren't installed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 15:16:37 2016 From: report at bugs.python.org (raphi rose) Date: Thu, 23 Jun 2016 19:16:37 +0000 Subject: [issue27375] error in "make test", while trying to install python on linux computer In-Reply-To: <1466699612.27.0.651436554447.issue27375@psf.upfronthosting.co.za> Message-ID: <1466709397.13.0.591856011466.issue27375@psf.upfronthosting.co.za> raphi rose added the comment: hmm, well i installed all the ones you told me to, ran make test again, and now it comes up with ERROR: test_article_head_body (test.test_nntplib.NetworkedNNTPTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/rrose/temp/Python-3.5.1/Lib/test/test_nntplib.py", line 252, in wrapped meth(self) File "/home/rrose/temp/Python-3.5.1/Lib/test/test_nntplib.py", line 189, in test_article_head_body self.assertEqual(filtered_lines, filtered_head_lines + [b''] + body.lines) File "/home/rrose/temp/Python-3.5.1/Lib/unittest/case.py", line 820, in assertEqual assertion_func(first, second, msg=msg) File "/home/rrose/temp/Python-3.5.1/Lib/unittest/case.py", line 1018, in assertListEqual self.assertSequenceEqual(list1, list2, msg, seq_type=list) File "/home/rrose/temp/Python-3.5.1/Lib/unittest/case.py", line 967, in assertSequenceEqual (i, item1, item2)) BytesWarning: str() on a bytes instance ---------------------------------------------------------------------- Ran 106 tests in 12.949s FAILED (errors=1) test test_nntplib failed 3 tests failed again: test_httplib test_nntplib test_ssl make: *** [test] Error 1 I am about to run each of those tests manually and will report the output ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 15:18:38 2016 From: report at bugs.python.org (raphi rose) Date: Thu, 23 Jun 2016 19:18:38 +0000 Subject: [issue27375] error in "make test", while trying to install python on linux computer In-Reply-To: <1466699612.27.0.651436554447.issue27375@psf.upfronthosting.co.za> Message-ID: <1466709518.84.0.745612170635.issue27375@psf.upfronthosting.co.za> raphi rose added the comment: the test_nntplib rrose at intern:~/temp/Python-3.5.1$ ./python -m test -v test_nntplib == CPython 3.5.1 (default, Jun 23 2016, 15:03:20) [GCC 4.8.4] == Linux-3.13.0-88-generic-x86_64-with-debian-jessie-sid little-endian == hash algorithm: siphash24 64bit == /home/rrose/temp/Python-3.5.1/build/test_python_28873 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0) [1/1] test_nntplib test_caps_only_after_login (test.test_nntplib.CapsAfterLoginNNTPv2Tests) ... ok test_decode_header (test.test_nntplib.MiscTests) ... ok test_parse_datetime (test.test_nntplib.MiscTests) ... ok test_parse_overview (test.test_nntplib.MiscTests) ... ok test_parse_overview_fmt (test.test_nntplib.MiscTests) ... ok test_ssl_support (test.test_nntplib.MiscTests) ... ok test_unparse_datetime (test.test_nntplib.MiscTests) ... ok test_unparse_datetime_legacy (test.test_nntplib.MiscTests) ... ok test_bad_capabilities (test.test_nntplib.MockSocketTests) ... ok test_bad_welcome (test.test_nntplib.MockSocketTests) ... ok test_login_aborted (test.test_nntplib.MockSocketTests) ... ok test_service_permanently_unavailable (test.test_nntplib.MockSocketTests) ... ok test_service_temporarily_unavailable (test.test_nntplib.MockSocketTests) ... ok test_bad_capabilities (test.test_nntplib.MockSslTests) ... ok test_bad_welcome (test.test_nntplib.MockSslTests) ... ok test_login_aborted (test.test_nntplib.MockSslTests) ... ok test_service_permanently_unavailable (test.test_nntplib.MockSslTests) ... ok test_service_temporarily_unavailable (test.test_nntplib.MockSslTests) ... ok test_article (test.test_nntplib.NNTPv1Tests) ... ok test_article_file (test.test_nntplib.NNTPv1Tests) ... ok test_authinfo (test.test_nntplib.NNTPv1Tests) ... ok test_body (test.test_nntplib.NNTPv1Tests) ... ok test_body_file (test.test_nntplib.NNTPv1Tests) ... ok test_caps (test.test_nntplib.NNTPv1Tests) ... ok test_date (test.test_nntplib.NNTPv1Tests) ... ok test_description (test.test_nntplib.NNTPv1Tests) ... ok test_descriptions (test.test_nntplib.NNTPv1Tests) ... ok test_group (test.test_nntplib.NNTPv1Tests) ... ok test_head (test.test_nntplib.NNTPv1Tests) ... ok test_head_file (test.test_nntplib.NNTPv1Tests) ... ok test_help (test.test_nntplib.NNTPv1Tests) ... ok test_ihave (test.test_nntplib.NNTPv1Tests) ... ok test_last (test.test_nntplib.NNTPv1Tests) ... ok test_list (test.test_nntplib.NNTPv1Tests) ... ok test_newnews (test.test_nntplib.NNTPv1Tests) ... ok test_next (test.test_nntplib.NNTPv1Tests) ... ok test_over (test.test_nntplib.NNTPv1Tests) ... ok test_post (test.test_nntplib.NNTPv1Tests) ... ok test_quit (test.test_nntplib.NNTPv1Tests) ... ok test_stat (test.test_nntplib.NNTPv1Tests) ... ok test_too_long_lines (test.test_nntplib.NNTPv1Tests) ... ok test_welcome (test.test_nntplib.NNTPv1Tests) ... ok test_xover (test.test_nntplib.NNTPv1Tests) ... ok test_article (test.test_nntplib.NNTPv2Tests) ... ok test_article_file (test.test_nntplib.NNTPv2Tests) ... ok test_authinfo (test.test_nntplib.NNTPv2Tests) ... ok test_body (test.test_nntplib.NNTPv2Tests) ... ok test_body_file (test.test_nntplib.NNTPv2Tests) ... ok test_caps (test.test_nntplib.NNTPv2Tests) ... ok test_date (test.test_nntplib.NNTPv2Tests) ... ok test_description (test.test_nntplib.NNTPv2Tests) ... ok test_descriptions (test.test_nntplib.NNTPv2Tests) ... ok test_group (test.test_nntplib.NNTPv2Tests) ... ok test_head (test.test_nntplib.NNTPv2Tests) ... ok test_head_file (test.test_nntplib.NNTPv2Tests) ... ok test_help (test.test_nntplib.NNTPv2Tests) ... ok test_ihave (test.test_nntplib.NNTPv2Tests) ... ok test_last (test.test_nntplib.NNTPv2Tests) ... ok test_list (test.test_nntplib.NNTPv2Tests) ... ok test_newnews (test.test_nntplib.NNTPv2Tests) ... ok test_next (test.test_nntplib.NNTPv2Tests) ... ok test_over (test.test_nntplib.NNTPv2Tests) ... ok test_post (test.test_nntplib.NNTPv2Tests) ... ok test_quit (test.test_nntplib.NNTPv2Tests) ... ok test_stat (test.test_nntplib.NNTPv2Tests) ... ok test_too_long_lines (test.test_nntplib.NNTPv2Tests) ... ok test_welcome (test.test_nntplib.NNTPv2Tests) ... ok test_xover (test.test_nntplib.NNTPv2Tests) ... ok skipped "Use of the 'network' resource not enabled" skipped "Use of the 'network' resource not enabled" test_module_all_attribute (test.test_nntplib.PublicAPITests) ... ok test_we_are_in_reader_mode_after_connect (test.test_nntplib.SendReaderNNTPv2Tests) ... ok ---------------------------------------------------------------------- Ran 70 tests in 0.037s OK (skipped=2) 1 test OK. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 15:19:49 2016 From: report at bugs.python.org (raphi rose) Date: Thu, 23 Jun 2016 19:19:49 +0000 Subject: [issue27375] error in "make test", while trying to install python on linux computer In-Reply-To: <1466699612.27.0.651436554447.issue27375@psf.upfronthosting.co.za> Message-ID: <1466709589.28.0.843459993682.issue27375@psf.upfronthosting.co.za> raphi rose added the comment: the test_httplib rrose at intern:~/temp/Python-3.5.1$ ./python -m test -v test_httplib == CPython 3.5.1 (default, Jun 23 2016, 15:03:20) [GCC 4.8.4] == Linux-3.13.0-88-generic-x86_64-with-debian-jessie-sid little-endian == hash algorithm: siphash24 64bit == /home/rrose/temp/Python-3.5.1/build/test_python_28888 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0) [1/1] test_httplib test_auto_headers (test.test_httplib.HeaderTests) ... ok test_content_length_0 (test.test_httplib.HeaderTests) ... ok test_invalid_headers (test.test_httplib.HeaderTests) ... ok test_ipv6host_header (test.test_httplib.HeaderTests) ... ok test_malformed_headers_coped_with (test.test_httplib.HeaderTests) ... ok test_putheader (test.test_httplib.HeaderTests) ... ok test_all (test.test_httplib.OfflineTest) ... ok test_client_constants (test.test_httplib.OfflineTest) ... ok test_responses (test.test_httplib.OfflineTest) ... ok test_bad_status_repr (test.test_httplib.BasicTest) ... ok test_chunked (test.test_httplib.BasicTest) ... ok test_chunked_extension (test.test_httplib.BasicTest) ... ok test_chunked_head (test.test_httplib.BasicTest) ... ok test_chunked_missing_end (test.test_httplib.BasicTest) some servers may serve up a short chunked encoding stream ... ok test_chunked_sync (test.test_httplib.BasicTest) Check that we don't read past the end of the chunked-encoding stream ... ok test_chunked_trailers (test.test_httplib.BasicTest) See that trailers are read and ignored ... ok test_content_length_sync (test.test_httplib.BasicTest) Check that we don't read past the end of the Content-Length stream ... ok test_early_eof (test.test_httplib.BasicTest) ... ok test_epipe (test.test_httplib.BasicTest) ... ok test_error_leak (test.test_httplib.BasicTest) ... ok test_host_port (test.test_httplib.BasicTest) ... ok test_incomplete_read (test.test_httplib.BasicTest) ... ok test_negative_content_length (test.test_httplib.BasicTest) ... ok test_overflowing_chunked_line (test.test_httplib.BasicTest) ... ok test_overflowing_header_line (test.test_httplib.BasicTest) ... ok test_overflowing_status_line (test.test_httplib.BasicTest) ... ok test_partial_readintos (test.test_httplib.BasicTest) ... ok test_partial_readintos_incomplete_body (test.test_httplib.BasicTest) ... ok test_partial_readintos_no_content_length (test.test_httplib.BasicTest) ... ok test_partial_reads (test.test_httplib.BasicTest) ... ok test_partial_reads_incomplete_body (test.test_httplib.BasicTest) ... ok test_partial_reads_no_content_length (test.test_httplib.BasicTest) ... ok test_read_head (test.test_httplib.BasicTest) ... ok test_readinto_chunked (test.test_httplib.BasicTest) ... ok test_readinto_chunked_head (test.test_httplib.BasicTest) ... ok test_readinto_head (test.test_httplib.BasicTest) ... ok test_response_headers (test.test_httplib.BasicTest) ... ok test_send (test.test_httplib.BasicTest) ... ok test_send_file (test.test_httplib.BasicTest) ... ok test_send_iter (test.test_httplib.BasicTest) ... ok test_send_type_error (test.test_httplib.BasicTest) ... ok test_send_updating_file (test.test_httplib.BasicTest) ... ok test_status_lines (test.test_httplib.BasicTest) ... ok test_too_many_headers (test.test_httplib.BasicTest) ... ok testTimeoutAttribute (test.test_httplib.TimeoutTest) ... ok test_100_close (test.test_httplib.PersistenceTest) ... ok test_disconnected (test.test_httplib.PersistenceTest) ... ok test_reuse_reconnect (test.test_httplib.PersistenceTest) ... ok test_attributes (test.test_httplib.HTTPSTest) ... ok test_host_port (test.test_httplib.HTTPSTest) ... ok test_local_bad_hostname (test.test_httplib.HTTPSTest) ... server (('127.0.0.1', 42358):42358 ('ECDHE-RSA-AES256-SHA', 'TLSv1/SSLv3', 256)): [23/Jun/2016 15:18:58] code 404, message File not found server (('127.0.0.1', 42358):42358 ('ECDHE-RSA-AES256-SHA', 'TLSv1/SSLv3', 256)): [23/Jun/2016 15:18:58] "GET /nonexistent HTTP/1.1" 404 - server (('127.0.0.1', 42358):42358 ('ECDHE-RSA-AES256-SHA', 'TLSv1/SSLv3', 256)): [23/Jun/2016 15:18:58] code 404, message File not found server (('127.0.0.1', 42358):42358 ('ECDHE-RSA-AES256-SHA', 'TLSv1/SSLv3', 256)): [23/Jun/2016 15:18:58] "GET /nonexistent HTTP/1.1" 404 - stopping HTTPS server joining HTTPS thread ok test_local_good_hostname (test.test_httplib.HTTPSTest) ... server (('127.0.0.1', 50574):50574 ('ECDHE-RSA-AES256-SHA', 'TLSv1/SSLv3', 256)): [23/Jun/2016 15:18:58] code 404, message File not found server (('127.0.0.1', 50574):50574 ('ECDHE-RSA-AES256-SHA', 'TLSv1/SSLv3', 256)): [23/Jun/2016 15:18:58] "GET /nonexistent HTTP/1.1" 404 - stopping HTTPS server joining HTTPS thread ok test_local_unknown_cert (test.test_httplib.HTTPSTest) ... stopping HTTPS server Got an error: [SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:645) joining HTTPS thread ok test_networked (test.test_httplib.HTTPSTest) ... skipped "Use of the 'network' resource not enabled" test_networked_bad_cert (test.test_httplib.HTTPSTest) ... skipped "Use of the 'network' resource not enabled" test_networked_good_cert (test.test_httplib.HTTPSTest) ... skipped "Use of the 'network' resource not enabled" test_networked_noverification (test.test_httplib.HTTPSTest) ... skipped "Use of the 'network' resource not enabled" test_networked_trusted_by_default_cert (test.test_httplib.HTTPSTest) ... skipped "Use of the 'network' resource not enabled" test_ascii_body (test.test_httplib.RequestBodyTest) ... ok test_binary_file_body (test.test_httplib.RequestBodyTest) ... ok test_bytes_body (test.test_httplib.RequestBodyTest) ... ok test_file_body (test.test_httplib.RequestBodyTest) ... ok test_latin1_body (test.test_httplib.RequestBodyTest) ... ok test_manual_content_length (test.test_httplib.RequestBodyTest) ... ok testHTTPConnectionSourceAddress (test.test_httplib.SourceAddressTest) ... ok testHTTPSConnectionSourceAddress (test.test_httplib.SourceAddressTest) ... ok test_getting_header (test.test_httplib.HTTPResponseTest) ... ok test_getting_header_defaultint (test.test_httplib.HTTPResponseTest) ... ok test_getting_nonexistent_header_with_iterable_default (test.test_httplib.HTTPResponseTest) ... ok test_getting_nonexistent_header_with_string_default (test.test_httplib.HTTPResponseTest) ... ok test_getting_nonexistent_header_without_default (test.test_httplib.HTTPResponseTest) ... ok test_peek (test.test_httplib.ExtendedReadTest) ... ok test_peek_0 (test.test_httplib.ExtendedReadTest) ... ok test_read1 (test.test_httplib.ExtendedReadTest) ... ok test_read1_0 (test.test_httplib.ExtendedReadTest) ... ok test_read1_bounded (test.test_httplib.ExtendedReadTest) ... ok test_read1_unbounded (test.test_httplib.ExtendedReadTest) ... ok test_readline (test.test_httplib.ExtendedReadTest) ... ok test_peek (test.test_httplib.ExtendedReadTestChunked) ... ok test_peek_0 (test.test_httplib.ExtendedReadTestChunked) ... ok test_read1 (test.test_httplib.ExtendedReadTestChunked) ... ok test_read1_0 (test.test_httplib.ExtendedReadTestChunked) ... ok test_read1_bounded (test.test_httplib.ExtendedReadTestChunked) ... ok test_read1_unbounded (test.test_httplib.ExtendedReadTestChunked) ... ok test_readline (test.test_httplib.ExtendedReadTestChunked) ... ok test_connect_put_request (test.test_httplib.TunnelTests) ... ok test_connect_with_tunnel (test.test_httplib.TunnelTests) ... ok test_disallow_set_tunnel_after_connect (test.test_httplib.TunnelTests) ... ok test_set_tunnel_host_port_headers (test.test_httplib.TunnelTests) ... ok test_tunnel_debuglog (test.test_httplib.TunnelTests) ... ok ---------------------------------------------------------------------- Ran 90 tests in 0.177s OK (skipped=5) 1 test OK. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 15:21:18 2016 From: report at bugs.python.org (raphi rose) Date: Thu, 23 Jun 2016 19:21:18 +0000 Subject: [issue27375] error in "make test", while trying to install python on linux computer In-Reply-To: <1466699612.27.0.651436554447.issue27375@psf.upfronthosting.co.za> Message-ID: <1466709678.91.0.541526572292.issue27375@psf.upfronthosting.co.za> raphi rose added the comment: the test_ssl rrose at intern:~/temp/Python-3.5.1$ ./python -m test -v test_ssl == CPython 3.5.1 (default, Jun 23 2016, 15:03:20) [GCC 4.8.4] == Linux-3.13.0-88-generic-x86_64-with-debian-jessie-sid little-endian == hash algorithm: siphash24 64bit == /home/rrose/temp/Python-3.5.1/build/test_python_28902 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0) [1/1] test_ssl test_ssl: testing with 'OpenSSL 1.0.1f 6 Jan 2014' (1, 0, 1, 6, 15) under Linux ('debian', 'jessie/sid', '') HAS_SNI = True OP_ALL = 0x800003ff OP_NO_TLSv1_1 = 0x10000000 test__create_stdlib_context (test.test_ssl.ContextTests) ... ok test_cert_store_stats (test.test_ssl.ContextTests) ... ok test_check_hostname (test.test_ssl.ContextTests) ... ok test_ciphers (test.test_ssl.ContextTests) ... ok test_constructor (test.test_ssl.ContextTests) ... ok test_create_default_context (test.test_ssl.ContextTests) ... ok test_get_ca_certs (test.test_ssl.ContextTests) ... ok test_load_cert_chain (test.test_ssl.ContextTests) ... ok test_load_default_certs (test.test_ssl.ContextTests) ... ok test_load_default_certs_env (test.test_ssl.ContextTests) ... ok test_load_default_certs_env_windows (test.test_ssl.ContextTests) ... skipped 'Windows specific' test_load_dh_params (test.test_ssl.ContextTests) ... ok test_load_verify_cadata (test.test_ssl.ContextTests) ... ok test_load_verify_locations (test.test_ssl.ContextTests) ... ok test_options (test.test_ssl.ContextTests) ... ok test_protocol (test.test_ssl.ContextTests) ... ok test_session_stats (test.test_ssl.ContextTests) ... ok test_set_default_verify_paths (test.test_ssl.ContextTests) ... ok test_set_ecdh_curve (test.test_ssl.ContextTests) ... ok test_sni_callback (test.test_ssl.ContextTests) ... ok test_sni_callback_refcycle (test.test_ssl.ContextTests) ... ok test_verify_flags (test.test_ssl.ContextTests) ... ok test_verify_mode (test.test_ssl.ContextTests) ... ok test_DER_to_PEM (test.test_ssl.BasicSocketTests) ... ok test_asn1object (test.test_ssl.BasicSocketTests) ... ok test_cert_time_to_seconds (test.test_ssl.BasicSocketTests) ... ok test_cert_time_to_seconds_locale (test.test_ssl.BasicSocketTests) ... skipped 'locale-specific month name needs to be different from C locale' test_cert_time_to_seconds_timezone (test.test_ssl.BasicSocketTests) ... ok test_constants (test.test_ssl.BasicSocketTests) ... ok test_dealloc_warn (test.test_ssl.BasicSocketTests) ... ok test_enum_certificates (test.test_ssl.BasicSocketTests) ... skipped 'Windows specific' test_enum_crls (test.test_ssl.BasicSocketTests) ... skipped 'Windows specific' test_errors (test.test_ssl.BasicSocketTests) ... ok test_get_default_verify_paths (test.test_ssl.BasicSocketTests) ... ok test_match_hostname (test.test_ssl.BasicSocketTests) ... ok test_openssl_version (test.test_ssl.BasicSocketTests) ... ok test_parse_cert (test.test_ssl.BasicSocketTests) ... {'issuer': ((('countryName', 'XY'),), (('localityName', 'Castle Anthrax'),), (('organizationName', 'Python Software Foundation'),), (('commonName', 'localhost'),)), 'notAfter': 'Oct 5 23:01:56 2020 GMT', 'notBefore': 'Oct 8 23:01:56 2010 GMT', 'serialNumber': 'D7C7381919AFC24E', 'subject': ((('countryName', 'XY'),), (('localityName', 'Castle Anthrax'),), (('organizationName', 'Python Software Foundation'),), (('commonName', 'localhost'),)), 'subjectAltName': (('DNS', 'localhost'),), 'version': 3} {'OCSP': ('http://ocsp.verisign.com',), 'caIssuers': ('http://SVRIntl-G3-aia.verisign.com/SVRIntlG3.cer',), 'crlDistributionPoints': ('http://SVRIntl-G3-crl.verisign.com/SVRIntlG3.crl',), 'issuer': ((('countryName', 'US'),), (('organizationName', 'VeriSign, Inc.'),), (('organizationalUnitName', 'VeriSign Trust Network'),), (('organizationalUnitName', 'Terms of use at https://www.verisign.com/rpa (c)10'),), (('commonName', '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', 'FI'),), (('stateOrProvinceName', 'Espoo'),), (('localityName', 'Espoo'),), (('organizationName', 'Nokia'),), (('organizationalUnitName', 'BI'),), (('commonName', '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', 'US'),), (('stateOrProvinceName', 'Oregon'),), (('localityName', 'Beaverton'),), (('organizationName', 'Python Software Foundation'),), (('organizationalUnitName', 'Python Core Development'),), (('commonName', 'null.python.org\x00example.org'),), (('emailAddress', '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', 'US'),), (('stateOrProvinceName', 'Oregon'),), (('localityName', 'Beaverton'),), (('organizationName', 'Python Software Foundation'),), (('organizationalUnitName', 'Python Core Development'),), (('commonName', 'null.python.org\x00example.org'),), (('emailAddress', '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_purpose_enum (test.test_ssl.BasicSocketTests) ... ok test_random (test.test_ssl.BasicSocketTests) ... RAND_status is 1 (sufficient randomness) ok test_random_fork (test.test_ssl.BasicSocketTests) ... ok test_refcycle (test.test_ssl.BasicSocketTests) ... ok test_server_side (test.test_ssl.BasicSocketTests) ... ok test_str_for_enums (test.test_ssl.BasicSocketTests) ... ok test_timeout (test.test_ssl.BasicSocketTests) ... ok test_tls_unique_channel_binding (test.test_ssl.BasicSocketTests) ... ok test_unknown_channel_binding (test.test_ssl.BasicSocketTests) ... ok test_unsupported_dtls (test.test_ssl.BasicSocketTests) ... ok test_wrapped_unconnected (test.test_ssl.BasicSocketTests) ... ok test_lib_reason (test.test_ssl.SSLErrorTests) ... ok test_str (test.test_ssl.SSLErrorTests) ... ok test_subclass (test.test_ssl.SSLErrorTests) ... ok test_buffer_types (test.test_ssl.MemoryBIOTests) ... ok test_eof (test.test_ssl.MemoryBIOTests) ... ok test_error_types (test.test_ssl.MemoryBIOTests) ... ok test_pending (test.test_ssl.MemoryBIOTests) ... ok test_read_write (test.test_ssl.MemoryBIOTests) ... ok test_alpn_protocols (test.test_ssl.ThreadedTests) ... skipped 'ALPN support needed for this test' test_asyncore_server (test.test_ssl.ThreadedTests) Check the example asyncore integration. ... server: new connection from 127.0.0.1:33233 client: sending b'FOO\n'... server: read b'FOO\n' from client client: read b'foo\n' client: closing connection. client: connection closed. cleanup: stopping server. cleanup: joining server thread. server: read b'over\n' from client server: closed connection server: read b'' from client cleanup: successfully joined. ok test_check_hostname (test.test_ssl.ThreadedTests) ... server: new connection from ('127.0.0.1', 41287) server: connection cipher is now ('ECDHE-RSA-AES256-SHA', 'TLSv1/SSLv3', 256) server: selected protocol is now None server: new connection from ('127.0.0.1', 40438) server: connection cipher is now ('ECDHE-RSA-AES256-SHA', 'TLSv1/SSLv3', 256) server: selected protocol is now None ok test_compression (test.test_ssl.ThreadedTests) ... server: new connection from ('127.0.0.1', 40540) server: connection cipher is now ('ECDHE-RSA-AES256-SHA', 'TLSv1/SSLv3', 256) server: selected protocol is now None client: sending b'FOO\n'... client: read b'foo\n' client: sending b'FOO\n'... client: read b'foo\n' client: sending b'FOO\n'... client: read b'foo\n' client: closing connection. got compression: None ok test_compression_disabled (test.test_ssl.ThreadedTests) ... server: new connection from ('127.0.0.1', 39154) server: connection cipher is now ('ECDHE-RSA-AES256-SHA', 'TLSv1/SSLv3', 256) client: sending b'FOO\n'... server: selected protocol is now None client: read b'foo\n' client: sending b'FOO\n'... client: read b'foo\n' client: sending b'FOO\n'... client: read b'foo\n' client: closing connection. ok test_crl_check (test.test_ssl.ThreadedTests) ... server: new connection from ('127.0.0.1', 54316) server: connection cipher is now ('ECDHE-RSA-AES256-SHA', 'TLSv1/SSLv3', 256) server: selected protocol is now None server: new connection from ('127.0.0.1', 58773) server: bad connection attempt from ('127.0.0.1', 58773): Traceback (most recent call last): File "/home/rrose/temp/Python-3.5.1/Lib/test/test_ssl.py", line 1789, in wrap_conn self.sock, server_side=True) File "/home/rrose/temp/Python-3.5.1/Lib/ssl.py", line 376, in wrap_socket _context=self) File "/home/rrose/temp/Python-3.5.1/Lib/ssl.py", line 747, in __init__ self.do_handshake() File "/home/rrose/temp/Python-3.5.1/Lib/ssl.py", line 983, in do_handshake self._sslobj.do_handshake() File "/home/rrose/temp/Python-3.5.1/Lib/ssl.py", line 628, in do_handshake self._sslobj.do_handshake() ssl.SSLError: [SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:645) server: new connection from ('127.0.0.1', 34821) server: connection cipher is now ('ECDHE-RSA-AES256-SHA', 'TLSv1/SSLv3', 256) server: selected protocol is now None ok test_default_ciphers (test.test_ssl.ThreadedTests) ... ok test_default_ecdh_curve (test.test_ssl.ThreadedTests) ... server: new connection from ('127.0.0.1', 47715) server: connection cipher is now ('ECDHE-RSA-AES256-GCM-SHA384', 'TLSv1/SSLv3', 256) server: selected protocol is now None ok test_dh_params (test.test_ssl.ThreadedTests) ... server: new connection from ('127.0.0.1', 48140) server: connection cipher is now ('DHE-RSA-AES256-SHA', 'TLSv1/SSLv3', 256) client: sending b'FOO\n'... server: selected protocol is now None client: read b'foo\n' client: sending b'FOO\n'... client: read b'foo\n' client: sending b'FOO\n'... client: read b'foo\n' client: closing connection. ok test_do_handshake_enotconn (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', 47352) server: connection cipher is now ('ECDHE-RSA-AES256-SHA', 'TLSv1/SSLv3', 256) server: selected protocol is now None client: sending b'FOO\n'... client: read b'foo\n' client: sending b'FOO\n'... client: read b'foo\n' client: sending b'FOO\n'... client: read b'foo\n' client: closing connection. server: new connection from ('127.0.0.1', 52027) server: connection cipher is now ('ECDHE-RSA-AES256-GCM-SHA384', 'TLSv1/SSLv3', 256) server: selected protocol is now None client: sending b'FOO\n'... client: read b'foo\n' client: sending b'FOO\n'... client: read b'foo\n' client: sending b'FOO\n'... client: read b'foo\n' client: closing connection. server: new connection from ('127.0.0.1', 35909) server: connection cipher is now ('ECDHE-RSA-AES256-SHA', 'TLSv1/SSLv3', 256) client: sending b'FOO\n'... server: selected protocol is now None client: read b'foo\n' client: sending b'FOO\n'... client: read b'foo\n' client: sending b'FOO\n'... client: read b'foo\n' client: closing connection. server: new connection from ('127.0.0.1', 53560) server: connection cipher is now ('ECDHE-RSA-AES256-SHA', 'TLSv1/SSLv3', 256) client: sending b'FOO\n'... server: selected protocol is now None client: read b'foo\n' client: sending b'FOO\n'... client: read b'foo\n' client: sending b'FOO\n'... client: read b'foo\n' client: closing connection. server: new connection from ('127.0.0.1', 52272) server: connection cipher is now ('ECDHE-RSA-AES256-GCM-SHA384', 'TLSv1/SSLv3', 256) server: selected protocol is now None client: sending b'FOO\n'... client: read b'foo\n' client: sending b'FOO\n'... client: read b'foo\n' client: sending b'FOO\n'... client: read b'foo\n' client: closing connection. ok test_empty_cert (test.test_ssl.ThreadedTests) Connecting with an empty cert file ... SSLError is [SSL] PEM lib (_ssl.c:2803) ok test_getpeercert (test.test_ssl.ThreadedTests) ... {'issuer': ((('countryName', 'XY'),), (('localityName', 'Castle Anthrax'),), (('organizationName', 'Python Software Foundation'),), (('commonName', 'localhost'),)), 'notAfter': 'Oct 5 23:01:56 2020 GMT', 'notBefore': 'Oct 8 23:01:56 2010 GMT', 'serialNumber': 'D7C7381919AFC24E', 'subject': ((('countryName', 'XY'),), (('localityName', 'Castle Anthrax'),), (('organizationName', 'Python Software Foundation'),), (('commonName', 'localhost'),)), 'subjectAltName': (('DNS', 'localhost'),), 'version': 3} Connection cipher is ('ECDHE-RSA-AES256-GCM-SHA384', 'TLSv1/SSLv3', 256). ok test_getpeercert_enotconn (test.test_ssl.ThreadedTests) ... 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] PEM lib (_ssl.c:2803) ok test_malformed_key (test.test_ssl.ThreadedTests) Connecting with a badly formatted key (syntax error) ... SSLError is [SSL] PEM lib (_ssl.c:2803) ok test_nonblocking_send (test.test_ssl.ThreadedTests) ... server: new connection from ('127.0.0.1', 33178) server: connection cipher is now ('ECDHE-RSA-AES256-SHA', 'TLSv1/SSLv3', 256) server: selected protocol is now None Test server failure: Traceback (most recent call last): File "/home/rrose/temp/Python-3.5.1/Lib/test/test_ssl.py", line 1886, in run self.write(msg.lower()) File "/home/rrose/temp/Python-3.5.1/Lib/test/test_ssl.py", line 1831, in write return self.sslconn.write(bytes) File "/home/rrose/temp/Python-3.5.1/Lib/ssl.py", line 803, in write return self._sslobj.write(data) File "/home/rrose/temp/Python-3.5.1/Lib/ssl.py", line 581, in write return self._sslobj.write(data) ConnectionResetError: [Errno 104] Connection reset by peer ok test_nonexisting_cert (test.test_ssl.ThreadedTests) Connecting with a non-existing cert file ... OSError is No such file or directory ok test_npn_protocols (test.test_ssl.ThreadedTests) ... server: new connection from ('127.0.0.1', 45702) server: connection cipher is now ('ECDHE-RSA-AES256-SHA', 'TLSv1/SSLv3', 256) client: sending b'FOO\n'... server: selected protocol is now http/1.1 client: read b'foo\n' client: sending b'FOO\n'... client: read b'foo\n' client: sending b'FOO\n'... client: read b'foo\n' client: closing connection. server: new connection from ('127.0.0.1', 56144) client: sending b'FOO\n'... server: connection cipher is now ('ECDHE-RSA-AES256-SHA', 'TLSv1/SSLv3', 256) server: selected protocol is now http/1.1 client: read b'foo\n' client: sending b'FOO\n'... client: read b'foo\n' client: sending b'FOO\n'... client: read b'foo\n' client: closing connection. server: new connection from ('127.0.0.1', 50837) server: connection cipher is now ('ECDHE-RSA-AES256-SHA', 'TLSv1/SSLv3', 256) server: selected protocol is now spdy/2 client: sending b'FOO\n'... client: read b'foo\n' client: sending b'FOO\n'... client: read b'foo\n' client: sending b'FOO\n'... client: read b'foo\n' client: closing connection. server: new connection from ('127.0.0.1', 49364) server: connection cipher is now ('ECDHE-RSA-AES256-SHA', 'TLSv1/SSLv3', 256) client: sending b'FOO\n'... server: selected protocol is now abc client: read b'foo\n' client: sending b'FOO\n'... client: read b'foo\n' client: sending b'FOO\n'... client: read b'foo\n' client: closing connection. ok test_protocol_sslv2 (test.test_ssl.ThreadedTests) Connecting to an SSLv2 server with various client options ... skipped 'OpenSSL is compiled without SSLv2 support' test_protocol_sslv23 (test.test_ssl.ThreadedTests) Connecting to an SSLv23 server with various client options ... {PROTOCOL_SSLv3->PROTOCOL_SSLv23} CERT_NONE PROTOCOL_SSLv23->PROTOCOL_SSLv23 CERT_NONE PROTOCOL_TLSv1->PROTOCOL_SSLv23 CERT_NONE {PROTOCOL_SSLv3->PROTOCOL_SSLv23} CERT_OPTIONAL PROTOCOL_SSLv23->PROTOCOL_SSLv23 CERT_OPTIONAL PROTOCOL_TLSv1->PROTOCOL_SSLv23 CERT_OPTIONAL {PROTOCOL_SSLv3->PROTOCOL_SSLv23} CERT_REQUIRED PROTOCOL_SSLv23->PROTOCOL_SSLv23 CERT_REQUIRED PROTOCOL_TLSv1->PROTOCOL_SSLv23 CERT_REQUIRED {PROTOCOL_SSLv3->PROTOCOL_SSLv23} CERT_NONE PROTOCOL_SSLv23->PROTOCOL_SSLv23 CERT_NONE {PROTOCOL_TLSv1->PROTOCOL_SSLv23} CERT_NONE ok test_protocol_sslv3 (test.test_ssl.ThreadedTests) Connecting to an SSLv3 server with various client options ... PROTOCOL_SSLv3->PROTOCOL_SSLv3 CERT_NONE PROTOCOL_SSLv3->PROTOCOL_SSLv3 CERT_OPTIONAL PROTOCOL_SSLv3->PROTOCOL_SSLv3 CERT_REQUIRED {PROTOCOL_SSLv23->PROTOCOL_SSLv3} CERT_NONE {PROTOCOL_TLSv1->PROTOCOL_SSLv3} CERT_NONE {PROTOCOL_SSLv23->PROTOCOL_SSLv3} CERT_NONE ok test_protocol_tlsv1 (test.test_ssl.ThreadedTests) Connecting to a TLSv1 server with various client options ... PROTOCOL_TLSv1->PROTOCOL_TLSv1 CERT_NONE PROTOCOL_TLSv1->PROTOCOL_TLSv1 CERT_OPTIONAL PROTOCOL_TLSv1->PROTOCOL_TLSv1 CERT_REQUIRED {PROTOCOL_SSLv3->PROTOCOL_TLSv1} CERT_NONE {PROTOCOL_SSLv23->PROTOCOL_TLSv1} CERT_NONE ok test_protocol_tlsv1_1 (test.test_ssl.ThreadedTests) Connecting to a TLSv1.1 server with various client options. ... PROTOCOL_TLSv1_1->PROTOCOL_TLSv1_1 CERT_NONE {PROTOCOL_SSLv3->PROTOCOL_TLSv1_1} CERT_NONE {PROTOCOL_SSLv23->PROTOCOL_TLSv1_1} CERT_NONE PROTOCOL_TLSv1_1->PROTOCOL_SSLv23 CERT_NONE {PROTOCOL_TLSv1->PROTOCOL_TLSv1_1} CERT_NONE {PROTOCOL_TLSv1_1->PROTOCOL_TLSv1} CERT_NONE ok test_protocol_tlsv1_2 (test.test_ssl.ThreadedTests) Connecting to a TLSv1.2 server with various client options. ... PROTOCOL_TLSv1_2->PROTOCOL_TLSv1_2 CERT_NONE {PROTOCOL_SSLv3->PROTOCOL_TLSv1_2} CERT_NONE {PROTOCOL_SSLv23->PROTOCOL_TLSv1_2} CERT_NONE PROTOCOL_TLSv1_2->PROTOCOL_SSLv23 CERT_NONE {PROTOCOL_TLSv1->PROTOCOL_TLSv1_2} CERT_NONE {PROTOCOL_TLSv1_2->PROTOCOL_TLSv1} CERT_NONE {PROTOCOL_TLSv1_1->PROTOCOL_TLSv1_2} CERT_NONE {PROTOCOL_TLSv1_2->PROTOCOL_TLSv1_1} CERT_NONE ok test_read_write_after_close_raises_valuerror (test.test_ssl.ThreadedTests) ... ok test_recv_send (test.test_ssl.ThreadedTests) Test recv(), send() and friends. ... server: new connection from ('127.0.0.1', 37197) server: connection cipher is now ('ECDHE-RSA-AES256-SHA', 'TLSv1/SSLv3', 256) server: selected protocol is now None ok test_rude_shutdown (test.test_ssl.ThreadedTests) A brutal shutdown of an SSL server should raise an OSError ... ok test_selected_alpn_protocol (test.test_ssl.ThreadedTests) ... server: new connection from ('127.0.0.1', 55355) server: connection cipher is now ('ECDHE-RSA-AES256-SHA', 'TLSv1/SSLv3', 256) client: sending b'FOO\n'... server: selected protocol is now None client: read b'foo\n' client: sending b'FOO\n'... client: read b'foo\n' client: sending b'FOO\n'... client: read b'foo\n' client: closing connection. ok test_selected_alpn_protocol_if_server_uses_alpn (test.test_ssl.ThreadedTests) ... skipped 'ALPN support required' test_selected_npn_protocol (test.test_ssl.ThreadedTests) ... server: new connection from ('127.0.0.1', 57433) server: connection cipher is now ('ECDHE-RSA-AES256-SHA', 'TLSv1/SSLv3', 256) client: sending b'FOO\n'... server: selected protocol is now None client: read b'foo\n' client: sending b'FOO\n'... client: read b'foo\n' client: sending b'FOO\n'... client: read b'foo\n' client: closing connection. ok test_sendfile (test.test_ssl.ThreadedTests) ... ok test_server_accept (test.test_ssl.ThreadedTests) ... ok test_shared_ciphers (test.test_ssl.ThreadedTests) ... server: new connection from ('127.0.0.1', 44231) server: connection cipher is now ('ECDHE-RSA-RC4-SHA', 'TLSv1/SSLv3', 128) server: selected protocol is now None ok test_sni_callback (test.test_ssl.ThreadedTests) ... server: new connection from ('127.0.0.1', 37285) server: connection cipher is now ('ECDHE-RSA-AES256-SHA', 'TLSv1/SSLv3', 256) server: selected protocol is now None server: new connection from ('127.0.0.1', 56968) server: connection cipher is now ('ECDHE-RSA-AES256-SHA', 'TLSv1/SSLv3', 256) server: selected protocol is now None server: new connection from ('127.0.0.1', 34528) server: connection cipher is now ('ECDHE-RSA-AES256-SHA', 'TLSv1/SSLv3', 256) server: selected protocol is now None ok test_sni_callback_alert (test.test_ssl.ThreadedTests) ... ok test_sni_callback_raising (test.test_ssl.ThreadedTests) ... ok test_sni_callback_wrong_return_type (test.test_ssl.ThreadedTests) ... ok test_socketserver (test.test_ssl.ThreadedTests) Using a SocketServer to create and manage SSL connections. ... server (('127.0.0.1', 36048):36048 ('ECDHE-RSA-AES256-GCM-SHA384', 'TLSv1/SSLv3', 256)): [23/Jun/2016 15:20:36] "GET /keycert.pem HTTP/1.1" 200 - client: read 1783 bytes from remote server '>' stopping HTTPS server joining HTTPS thread ok test_starttls (test.test_ssl.ThreadedTests) Switching from clear text to encrypted and back again. ... client: sending b'msg 1'... server: new connection from ('127.0.0.1', 33860) server: read b'msg 1' (unencrypted), sending back b'msg 1' (unencrypted)... client: read b'msg 1' from server client: sending b'MSG 2'... server: read b'MSG 2' (unencrypted), sending back b'msg 2' (unencrypted)... client: read b'msg 2' from server client: sending b'STARTTLS'... server: read STARTTLS from client, sending OK... client: read b'ok' from server, starting TLS... server: connection cipher is now ('ECDHE-RSA-AES256-SHA', 'TLSv1/SSLv3', 256) server: selected protocol is now None client: sending b'MSG 3'... server: read b'MSG 3' (encrypted), sending back b'msg 3' (encrypted)... client: read b'msg 3' from server client: sending b'msg 4'... server: read b'msg 4' (encrypted), sending back b'msg 4' (encrypted)... client: read b'msg 4' from server client: sending b'ENDTLS'... server: read ENDTLS from client, sending OK... client: read b'ok' from server, ending TLS... server: connection is now unencrypted... client: sending b'msg 5'... server: read b'msg 5' (unencrypted), sending back b'msg 5' (unencrypted)... client: read b'msg 5' from server client: sending b'msg 6'... server: read b'msg 6' (unencrypted), sending back b'msg 6' (unencrypted)... client: read b'msg 6' from server client: closing connection. server: client closed connection ok test_tls_unique_channel_binding (test.test_ssl.ThreadedTests) Test tls-unique channel binding. ... server: new connection from ('127.0.0.1', 43512) server: connection cipher is now ('ECDHE-RSA-AES256-SHA', 'TLSv1/SSLv3', 256) got channel binding data: b'\xdf\xfa\xed\x05gGz0\xe5\xa5fP' server: selected protocol is now None server: new connection from ('127.0.0.1', 43513) got another channel binding data: b'\xe4\xc1\xfb\xbaW\xe32\x85\xea:$T' server: connection cipher is now ('ECDHE-RSA-AES256-SHA', 'TLSv1/SSLv3', 256) server: selected protocol is now None ok test_version_basic (test.test_ssl.ThreadedTests) ... ok ---------------------------------------------------------------------- Ran 100 tests in 1.347s OK (skipped=7) 1 test OK. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 15:25:21 2016 From: report at bugs.python.org (raphi rose) Date: Thu, 23 Jun 2016 19:25:21 +0000 Subject: [issue27375] error in "make test", while trying to install python on linux computer In-Reply-To: <1466699612.27.0.651436554447.issue27375@psf.upfronthosting.co.za> Message-ID: <1466709921.89.0.860618041022.issue27375@psf.upfronthosting.co.za> raphi rose added the comment: also, after installing this library liblzma-dev it said that i had redundant files (not in those words) and that I should run "apt-get autoremove," which I did, this may have been what caused the other failures? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 15:38:10 2016 From: report at bugs.python.org (Stefan Krah) Date: Thu, 23 Jun 2016 19:38:10 +0000 Subject: [issue27375] error in "make test", while trying to install python on linux computer In-Reply-To: <1466699612.27.0.651436554447.issue27375@psf.upfronthosting.co.za> Message-ID: <1466710690.56.0.807112738426.issue27375@psf.upfronthosting.co.za> Stefan Krah added the comment: Ah, so the tests pass when you run them manually but "make test" fails. This looks like https://bugs.python.org/issue26837 , which is fixed in the next release. You can just ignore this failure, it's harmless. [BTW, using autoremove is fine.] ---------- components: +Tests -Build, Installation resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> assertSequenceEqual() raises BytesWarning when format message type: compile error -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 15:44:18 2016 From: report at bugs.python.org (Neil Schemenauer) Date: Thu, 23 Jun 2016 19:44:18 +0000 Subject: [issue27377] Add smarter socket.fromfd() In-Reply-To: <1466706816.6.0.72770597716.issue27377@psf.upfronthosting.co.za> Message-ID: <1466711058.25.0.293603318561.issue27377@psf.upfronthosting.co.za> Neil Schemenauer added the comment: Add documentation for new functions. ---------- Added file: http://bugs.python.org/file43524/fromfd2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 15:44:31 2016 From: report at bugs.python.org (Neil Schemenauer) Date: Thu, 23 Jun 2016 19:44:31 +0000 Subject: [issue27377] Add smarter socket.fromfd() In-Reply-To: <1466706816.6.0.72770597716.issue27377@psf.upfronthosting.co.za> Message-ID: <1466711071.65.0.552731020159.issue27377@psf.upfronthosting.co.za> Changes by Neil Schemenauer : Removed file: http://bugs.python.org/file43523/fromfd2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 15:47:04 2016 From: report at bugs.python.org (raphi rose) Date: Thu, 23 Jun 2016 19:47:04 +0000 Subject: [issue27375] error in "make test", while trying to install python on linux computer In-Reply-To: <1466699612.27.0.651436554447.issue27375@psf.upfronthosting.co.za> Message-ID: <1466711224.35.0.0679610732104.issue27375@psf.upfronthosting.co.za> raphi rose added the comment: ok great, thanks for your help! ---------- components: +Build, Installation -Tests resolution: duplicate -> status: closed -> open type: behavior -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 15:49:24 2016 From: report at bugs.python.org (raphi rose) Date: Thu, 23 Jun 2016 19:49:24 +0000 Subject: [issue27375] error in "make test", while trying to install python on linux computer In-Reply-To: <1466699612.27.0.651436554447.issue27375@psf.upfronthosting.co.za> Message-ID: <1466711364.99.0.918783719629.issue27375@psf.upfronthosting.co.za> Changes by raphi rose : ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 15:58:16 2016 From: report at bugs.python.org (Matt Morrison) Date: Thu, 23 Jun 2016 19:58:16 +0000 Subject: [issue27378] remove ref to Phil Schwartz's 'Kodos' in regex HOWTO Message-ID: <1466711896.95.0.020858113879.issue27378@psf.upfronthosting.co.za> New submission from Matt Morrison: In the Regular Expressions HOWTO (https://docs.python.org/3/howto/regex.html#performing-matches, Doc/howto/regex.rst), there is the following paragraph: ===== You can learn about this by interactively experimenting with the :mod:`re` module. If you have :mod:`tkinter` available, you may also want to look at :source:`Tools/demo/redemo.py`, a demonstration program included with the Python distribution. It allows you to enter REs and strings, and displays whether the RE matches or fails. :file:`redemo.py` can be quite useful when trying to debug a complicated RE. Phil Schwartz's `Kodos `_ is also an interactive tool for developing and testing RE patterns. ===== I checked the Kodos site on SourceForge, and the latest release is exactly 10 years old. I couldn't get it to work with 2.7.11 on Ubuntu 16.04 and PyQt4 - Qt3 is one of its requirements. I didn't bother running 2to3 on it. I propose we delete the last sentence of the above paragraph altogether. There are many good regex sites out there, including regex101, regexr, Debuggex, regexpal, and more (those are just the first few in my bookmarks list), and I don't feel we should be promoting one outdated tool. Here is the diff: ===== @@ -374,9 +374,7 @@ :source:`Tools/demo/redemo.py`, a demonstration program included with the Python distribution. It allows you to enter REs and strings, and displays whether the RE matches or fails. :file:`redemo.py` can be quite useful when -trying to debug a complicated RE. Phil Schwartz's `Kodos -`_ is also an interactive tool for developing and -testing RE patterns. +trying to debug a complicated RE. This HOWTO uses the standard Python interpreter for its examples. First, run the Python interpreter, import the :mod:`re` module, and compile a RE:: ===== I've also attached it as a file. ---------- assignee: docs at python components: Documentation files: regex.diff keywords: patch messages: 269142 nosy: MattDMo, docs at python priority: normal severity: normal status: open title: remove ref to Phil Schwartz's 'Kodos' in regex HOWTO type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43525/regex.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 16:00:58 2016 From: report at bugs.python.org (Stefan Krah) Date: Thu, 23 Jun 2016 20:00:58 +0000 Subject: [issue27375] error in "make test", while trying to install python on linux computer In-Reply-To: <1466699612.27.0.651436554447.issue27375@psf.upfronthosting.co.za> Message-ID: <1466712058.41.0.896239359974.issue27375@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- components: +Tests -Build, Installation resolution: fixed -> duplicate status: open -> closed type: compile error -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 16:13:40 2016 From: report at bugs.python.org (SilentGhost) Date: Thu, 23 Jun 2016 20:13:40 +0000 Subject: [issue27377] Add smarter socket.fromfd() In-Reply-To: <1466706816.6.0.72770597716.issue27377@psf.upfronthosting.co.za> Message-ID: <1466712820.56.0.0903891248866.issue27377@psf.upfronthosting.co.za> SilentGhost added the comment: The patch applies cleanly, not sure why the rietveld link doesn't appear. Perhaps because of the extension? In test, I noticed, that you're not testing that OSError is raised, perhaps something to add? ---------- nosy: +SilentGhost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 16:14:31 2016 From: report at bugs.python.org (SilentGhost) Date: Thu, 23 Jun 2016 20:14:31 +0000 Subject: [issue27376] Add mock_import method to mock module In-Reply-To: <1466701937.33.0.949904358819.issue27376@psf.upfronthosting.co.za> Message-ID: <1466712871.26.0.764819538836.issue27376@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +michael.foord stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 17:32:06 2016 From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=) Date: Thu, 23 Jun 2016 21:32:06 +0000 Subject: [issue27363] Complex with negative zero imaginary part In-Reply-To: <1466535728.31.0.514028528898.issue27363@psf.upfronthosting.co.za> Message-ID: <1466717526.67.0.585801975002.issue27363@psf.upfronthosting.co.za> Vedran ?a?i? added the comment: Funny, I thought the "repr invariant" was exactly the opposite thing, that _eval_ (or literal_eval) of repr should give back the starting object. And that's what I intended to preserve here. It's obviously broken now. Ok, alternate suggestion: can at least ast.literal_eval be fixed to work in the same way as complex constructor? Because it's not much of a "literal" otherwise... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 17:40:16 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 23 Jun 2016 21:40:16 +0000 Subject: [issue27371] Runaway memory consumption using tkinter update() In-Reply-To: <1466629289.92.0.827863623566.issue27371@psf.upfronthosting.co.za> Message-ID: <1466718016.97.0.425587441767.issue27371@psf.upfronthosting.co.za> R. David Murray added the comment: You might want to try stripping it further, and see if you can reproduce it just using tk, without python involved. ---------- nosy: +r.david.murray title: Runaway memory consumption using update() -> Runaway memory consumption using tkinter update() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 17:43:04 2016 From: report at bugs.python.org (Jeremy Blow) Date: Thu, 23 Jun 2016 21:43:04 +0000 Subject: [issue27371] Runaway memory consumption using tkinter update() In-Reply-To: <1466629289.92.0.827863623566.issue27371@psf.upfronthosting.co.za> Message-ID: <1466718184.96.0.363870808832.issue27371@psf.upfronthosting.co.za> Jeremy Blow added the comment: That seems like a good idea, will do so and report back findings. Hey, good meeting you at PyCon, by the way. Met you at the freelance open space. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 18:08:07 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 23 Jun 2016 22:08:07 +0000 Subject: [issue27365] Allow non-ascii chars in IDLE NEWS.txt (for contributor names) In-Reply-To: <1466564645.25.0.829598827477.issue27365@psf.upfronthosting.co.za> Message-ID: <20160623220759.7607.60429.DF489156@psf.io> Roundup Robot added the comment: New changeset cbc6407fa393 by Terry Jan Reedy in branch '2.7': Issue #27365: Add blank lines. to 2.7 test_editmenu https://hg.python.org/cpython/rev/cbc6407fa393 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 22:20:45 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 24 Jun 2016 02:20:45 +0000 Subject: [issue13344] closed sockets don't raise EBADF anymore In-Reply-To: <1320441286.92.0.465148592312.issue13344@psf.upfronthosting.co.za> Message-ID: <1466734845.4.0.414845480565.issue13344@psf.upfronthosting.co.za> Martin Panter added the comment: According to strace, Python 3 is calling send(-1, ...): sendto(-1, "x", 1, 0, NULL, 0) = -1 EBADF (Bad file descriptor) A related discrepancy between Python 2 and 3 is how the socket.makefile() objects affect the original socket. In Python 2: >>> f = sock.makefile("wb") >>> sock.close() # Should ?close? Python?s sock object, but not f >>> sock.send(b"x") socket.error: [Errno 9] Bad file descriptor In Python 3: >>> sock.send(b"x") # Actually sent to remote end! 1 ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 22:33:57 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 24 Jun 2016 02:33:57 +0000 Subject: [issue27377] Add smarter socket.fromfd() In-Reply-To: <1466706816.6.0.72770597716.issue27377@psf.upfronthosting.co.za> Message-ID: <1466735637.77.0.644651182063.issue27377@psf.upfronthosting.co.za> Martin Panter added the comment: Maybe if the patch was regenerated with Mercurial off a public revision, it would work with Rietveld. I have seen non-Mercurial patches work too though. Perhaps this one doesn?t because the line numbers are off compared to the default branch? See also Issue 18391 discussing extending the existing fromfd() function to automatically determine the socket parameters. I agree that the name fromfd2() is a bit ugly, although there is precedence at least in Python 2: urllib2, os.popen2(), popen2 module, etc. Maybe other bike shed colours might be from_existing_fd(), using_fd(), fdopen(). Something that suggests creating an object from an FD without duplication. I wonder if fdtype() is really needed as a public API. The new fromfd2() API is missing when you do ?from socket import * ?. There is a new function that may be useful to automate checking for this error. What prevents this from working on Windows? I understand there is less of a need, but I imagine it would be relatively easy to support. It looks like some platforms support SO_PROTOCOL and/or SO_PROTOTYPE to get a socket?s protocol: . Also, there might be a Windows-specific SO_PROTOCOL_INFO option. >>> s >>> SO_PROTOCOL = 38 # On Linux x86-64; see Issue 18391 >>> protocol_struct = Struct("I") >>> protocol = s.getsockopt(SOL_SOCKET, SO_PROTOCOL, protocol_struct.size) >>> protocol_struct.unpack(protocol) (6,) >>> IPPROTO_TCP 6 IMO if Python grows the ability to determine a socket?s protocol, it might be better for socket.proto to use it automatically, at least if proto=0 was specified to the socket() function. diff --git a/Doc/library/socket.rst b/Doc/library/socket.rst +.. function:: fromfd2(fd) + + Create a socket object from a file descriptor. The file descriptor is + not duplicated. The family, type and protocol for the socket are This needs fixing about how and if the protocol is determined. + determined from the file descriptor. If the file descriptor is not a + socket, OSError is raised. The socket is assumed to be in blocking mode. :exc:`OSError` + The newly created socket is :ref:`non-inheritable `. This does not seem to be true, nor desirable: >>> s = socket() >>> s.get_inheritable() False >>> s.set_inheritable(True) >>> ss = fromfd2(s.fileno()) >>> ss.get_inheritable() True >>> s.get_inheritable() True + .. versionadded:: 3.6 + The returned socket is now non-inheritable. The whole function is new, not just process inheritance. diff --git a/Lib/test/test_socket.py b/Lib/test/test_socket.py + with s: + s2 = socket.fromfd2(s.fileno()) + with s2: Isn?t this incorrect due to closing the same file descriptor twice? I think you should use socket.detach(). See Issue 26685, whose changes should raise an exception for this bug in 3.6. diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c + if (!S_ISSOCK(st_fd.st_mode)) { + PyErr_SetString(PyExc_ValueError, "fdtype: " + "file descriptor is not a socket"); This seems to be contrary to your documentation. Also, perhaps it is good enough to let getsockopt() later raising ENOTSOCK? + union sockaddr_union sockaddr = {}; Why not just use a struct sockaddr? All we need is the sa.sa_family field right? ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 22:42:43 2016 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 24 Jun 2016 02:42:43 +0000 Subject: [issue26537] ConfigParser has optionxform, but not sectionxform In-Reply-To: <1457678417.52.0.410667040467.issue26537@psf.upfronthosting.co.za> Message-ID: <1466736163.68.0.980088173864.issue26537@psf.upfronthosting.co.za> Xiang Zhang added the comment: ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 22:43:21 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 24 Jun 2016 02:43:21 +0000 Subject: [issue20842] pkgutil docs should reference glossary terms not PEP 302 In-Reply-To: <1393846400.67.0.723549613222.issue20842@psf.upfronthosting.co.za> Message-ID: <1466736201.0.0.410024922796.issue20842@psf.upfronthosting.co.za> Martin Panter added the comment: See also Issue 26896. Apparently some of the terms you are linking are used wrongly. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 22:59:45 2016 From: report at bugs.python.org (Emanuel Barry) Date: Fri, 24 Jun 2016 02:59:45 +0000 Subject: [issue27364] Deprecate invalid unicode escape sequences In-Reply-To: <1466541260.02.0.320668077341.issue27364@psf.upfronthosting.co.za> Message-ID: <1466737185.04.0.749877082683.issue27364@psf.upfronthosting.co.za> Emanuel Barry added the comment: Yes, it's in use in an awful lot of places (see my patch). The proper fix is to use raw strings, or, if you need actual escapes in the same string, manually escape them. However, as you'll see by looking at the patch, the vast majority of cases are fixed by prepending a single 'r' to the front of the string. In fact, only csv.py and html/parser.py needed more finer-grained escaping. I think that the argument "It works in non-raw strings" is weak. I've always used raw strings for regular expressions, and this patch would simply move this from being a style issue to being a syntax one (and I think it's fine :). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 23 23:19:57 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 24 Jun 2016 03:19:57 +0000 Subject: [issue27379] SocketType changed in Python 3 Message-ID: <1466738397.82.0.0999219877747.issue27379@psf.upfronthosting.co.za> New submission from Martin Panter: In the documentation for Python 2 and 3, socket.SocketType is defined as: This is a Python type object that represents the socket object type. It is the same as ?type(socket(...))?. In Python 2 it is a standalone ?socket._socketobject? class, which holds a ?_socket.socket? instance as an internal ?_sock? attribute. So the documentation and implementation are consistent. But since revision 8e062e572ea4, Python 3 no longer defines SocketType directly, and just imports the ?_socket.SocketType? definition, which is an alias of ?_socket.socket?. The change also defines ?socket.socket? as a subclass of this low-level class. The result is that SocketType is not the exact type, but only a base class: >>> s = socket.socket() >>> type(s) >>> SocketType >>> type(s) is SocketType # Should be true according to documentation False >>> isinstance(s, SocketType) True Should the documentation just be amended, or should SocketType be changed? If SocketType is not changed, perhaps we should document that socket.socket() is a class, not just a function, and maybe deprecate SocketType. ---------- messages: 269153 nosy: martin.panter priority: normal severity: normal status: open title: SocketType changed in Python 3 versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 00:15:18 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 24 Jun 2016 04:15:18 +0000 Subject: [issue27380] IDLE: add base Query dialog with ttk widgets Message-ID: <1466741717.27.0.533147933113.issue27380@psf.upfronthosting.co.za> New submission from Terry J. Reedy: The custom popup entry dialogs in config_sec and config_help have a common structure and overlapping code. When one hits OK and the entry is not valid, both display a specific message and let the user edit the entry (or Cancel). File => Load Module, on the other hand, uses tkSimpleDialog.askstring. No error checking is done before the box disappears. If there is an error, even a simple misspelling, one must start over. It is really annoying to use. I want to replace this with a custom popup that would be the same as the one in config_sec, except for title, prompt, and validation function. If the name given has multiple conponents, such as idlelib.idelhelp.help_xyz, I would like to report which is the first invalid component (going from left to right). I am therefore adding a new module, query.py, with a new Query class that will be the baseclass for three derived classes. The partial patch renames config_sec.py (formerly configSectionNameDialog.py) to query.py. The corresponding test_config_sec) becomes test_query. It splits class GetCfgSectionNameDialog into a base class Query and a subclass SectionName. Query is responsible for the popup, and used ttk widgets as appropriate. SectionName overrides the entry validation function entry_ok (formerly name_ok). The test functions have been similarly split. What remains are ModuleName and HelpSource subclasses, corresponding tests, and integration with the software that would use them. ---------- assignee: terry.reedy files: query.diff keywords: patch messages: 269154 nosy: terry.reedy priority: normal severity: normal stage: patch review status: open title: IDLE: add base Query dialog with ttk widgets type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43526/query.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 00:22:39 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Jun 2016 04:22:39 +0000 Subject: [issue27364] Deprecate invalid unicode escape sequences In-Reply-To: <1466541260.02.0.320668077341.issue27364@psf.upfronthosting.co.za> Message-ID: <1466742159.79.0.792002231304.issue27364@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There was a long discussion on Python-Dev. [1] Guido taken part in it. [1] http://comments.gmane.org/gmane.comp.python.devel/151612 ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 00:43:28 2016 From: report at bugs.python.org (Emanuel Barry) Date: Fri, 24 Jun 2016 04:43:28 +0000 Subject: [issue27364] Deprecate invalid unicode escape sequences In-Reply-To: <1466541260.02.0.320668077341.issue27364@psf.upfronthosting.co.za> Message-ID: <1466743408.61.0.178571607596.issue27364@psf.upfronthosting.co.za> Emanuel Barry added the comment: Thanks, didn't find that one. Apparently Guido's stance is "Make this a silent warning, then we can discuss about preventing it later", which happens to be what I'm doing here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 01:36:13 2016 From: report at bugs.python.org (Jeremy Blow) Date: Fri, 24 Jun 2016 05:36:13 +0000 Subject: [issue27371] Runaway memory consumption using tkinter update() In-Reply-To: <1466629289.92.0.827863623566.issue27371@psf.upfronthosting.co.za> Message-ID: <1466746573.48.0.00476453821759.issue27371@psf.upfronthosting.co.za> Jeremy Blow added the comment: Confirmed the problem is with Tk/MacOS. Running a simple TCL script yielded the same behavior in terms of memory. The hunt goes elsewhere... Thank you R. David for the suggestion. ``` package require Tk while 1 { update } ``` # MacOS 10.9.4 /Users/jeremy$ /usr/bin/time -l tclsh update_loop.tcl 60.20 real 34.67 user 21.42 sys 18219008 maximum resident set size 0 average shared memory size 0 average unshared data size 0 average unshared stack size 5836 page reclaims 26 page faults 0 swaps 0 block input operations 9 block output operations 0 messages sent 0 messages received 0 signals received 830419 voluntary context switches 1663224 involuntary context switches # MacOS 10.11.3 /Users/jeremy$ /usr/bin/time -l tclsh update_loop.tcl 60.44 real 39.06 user 21.45 sys 571715584 maximum resident set size 0 average shared memory size 0 average unshared data size 0 average unshared stack size 141633 page reclaims 0 page faults 0 swaps 0 block input operations 3 block output operations 0 messages sent 0 messages received 0 signals received 521744 voluntary context switches 1833399 involuntary context switches ---------- resolution: -> third party status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 01:47:03 2016 From: report at bugs.python.org (Emanuel Barry) Date: Fri, 24 Jun 2016 05:47:03 +0000 Subject: [issue27364] Deprecate invalid unicode escape sequences In-Reply-To: <1466541260.02.0.320668077341.issue27364@psf.upfronthosting.co.za> Message-ID: <1466747223.72.0.46742023964.issue27364@psf.upfronthosting.co.za> Emanuel Barry added the comment: I found the cause of the failed assertion, an invalid escape sequence slipped through in a file. Patch attached (also with Serhiy's comments). It worries me a little though that pure Python code can cause a hard crash. Ok, it worries me a lot. Please don't merge this until it's fixed. I'm guessing this is a combination of unittest catching warnings and compiling the faulty source file. As to why a malformed node (i.e. one that raised a DeprecationWarning) managed to pass through unharmed is beyond me. ---------- Added file: http://bugs.python.org/file43527/deprecate_invalid_unicode_escapes_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 01:53:51 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Jun 2016 05:53:51 +0000 Subject: [issue27378] remove ref to Phil Schwartz's 'Kodos' in regex HOWTO In-Reply-To: <1466711896.95.0.020858113879.issue27378@psf.upfronthosting.co.za> Message-ID: <20160624055347.102344.1289.29018AC8@psf.io> Roundup Robot added the comment: New changeset 23182404a85c by Berker Peksag in branch '3.5': Issue #27378: Remove an outdated reference from regex HOWTO https://hg.python.org/cpython/rev/23182404a85c New changeset 21cb299a9626 by Berker Peksag in branch 'default': Issue #27378: Merge from 3.5 https://hg.python.org/cpython/rev/21cb299a9626 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 01:54:16 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 24 Jun 2016 05:54:16 +0000 Subject: [issue27378] remove ref to Phil Schwartz's 'Kodos' in regex HOWTO In-Reply-To: <1466711896.95.0.020858113879.issue27378@psf.upfronthosting.co.za> Message-ID: <1466747656.19.0.0879268439981.issue27378@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks! ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 02:11:04 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Jun 2016 06:11:04 +0000 Subject: [issue26547] Undocumented use of the term dictproxy in vars() documentation In-Reply-To: <1457821404.83.0.465984707802.issue26547@psf.upfronthosting.co.za> Message-ID: <20160624061101.102161.93373.0CCDD853@psf.io> Roundup Robot added the comment: New changeset 79e4593ce746 by Berker Peksag in branch '3.5': Issue #26547: Remove outdated term dictproxy from vars() documentation https://hg.python.org/cpython/rev/79e4593ce746 New changeset 45544b868f7b by Berker Peksag in branch 'default': Issue #26547: Merge from 3.5 https://hg.python.org/cpython/rev/45544b868f7b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 02:11:39 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 24 Jun 2016 06:11:39 +0000 Subject: [issue26547] Undocumented use of the term dictproxy in vars() documentation In-Reply-To: <1457821404.83.0.465984707802.issue26547@psf.upfronthosting.co.za> Message-ID: <1466748699.11.0.854029918478.issue26547@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks, Julien. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 02:28:06 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Jun 2016 06:28:06 +0000 Subject: [issue18300] script_helper._assert_python should set TERM='' by default. In-Reply-To: <1372164040.52.0.568545505593.issue18300@psf.upfronthosting.co.za> Message-ID: <20160624062803.22078.96676.06B266A1@psf.io> Roundup Robot added the comment: New changeset 983fe8f96b08 by Berker Peksag in branch '3.5': Issue #18300: Set TERM='' by default in assert_python_* https://hg.python.org/cpython/rev/983fe8f96b08 New changeset 1c49cf82d115 by Berker Peksag in branch 'default': Issue #18300: Merge from 3.5 https://hg.python.org/cpython/rev/1c49cf82d115 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 02:29:30 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 24 Jun 2016 06:29:30 +0000 Subject: [issue18300] script_helper._assert_python should set TERM='' by default. In-Reply-To: <1372164040.52.0.568545505593.issue18300@psf.upfronthosting.co.za> Message-ID: <1466749770.75.0.0880887944229.issue18300@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the review, Martin. ---------- components: +Tests resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.5, Python 3.6 -Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 03:04:53 2016 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Jun 2016 07:04:53 +0000 Subject: [issue26867] test_ssl test_options fails on ubuntu 16.04 In-Reply-To: <1461728238.71.0.110276038105.issue26867@psf.upfronthosting.co.za> Message-ID: <1466751893.57.0.103509930698.issue26867@psf.upfronthosting.co.za> Larry Hastings added the comment: Well, I want this fixed in 3.5.2 final. If nobody can propose a better patch in the next 24 hours then I'm going with Matthias's patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 05:38:13 2016 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 24 Jun 2016 09:38:13 +0000 Subject: [issue27381] Typo in zipfile documentation Message-ID: <1466761093.81.0.0650336824478.issue27381@psf.upfronthosting.co.za> New submission from Xiang Zhang: There is a redundant ')' in zipfile doc. Remove it. ---------- assignee: docs at python components: Documentation files: zipfile_doc.patch keywords: patch messages: 269166 nosy: docs at python, xiang.zhang priority: normal severity: normal status: open title: Typo in zipfile documentation versions: Python 3.6 Added file: http://bugs.python.org/file43528/zipfile_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 05:56:02 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Jun 2016 09:56:02 +0000 Subject: [issue27381] Typo in zipfile documentation In-Reply-To: <1466761093.81.0.0650336824478.issue27381@psf.upfronthosting.co.za> Message-ID: <20160624095559.32735.51498.B263BD76@psf.io> Roundup Robot added the comment: New changeset be435520e493 by Berker Peksag in branch '3.5': Issue #27381: Remove superfluous paren in zipfile documentation https://hg.python.org/cpython/rev/be435520e493 New changeset f859380d4708 by Berker Peksag in branch 'default': Issue #27381: Merge from 3.5 https://hg.python.org/cpython/rev/f859380d4708 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 05:56:30 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 24 Jun 2016 09:56:30 +0000 Subject: [issue27381] Typo in zipfile documentation In-Reply-To: <1466761093.81.0.0650336824478.issue27381@psf.upfronthosting.co.za> Message-ID: <1466762190.52.0.23048542509.issue27381@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks! ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed type: -> behavior versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 09:51:33 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 24 Jun 2016 13:51:33 +0000 Subject: [issue16821] bundlebuilder broken in 2.7 In-Reply-To: <1356903579.79.0.644714985612.issue16821@psf.upfronthosting.co.za> Message-ID: <1466776293.45.0.741814199493.issue16821@psf.upfronthosting.co.za> R. David Murray added the comment: It's not obvious that this issue would be out of date by our normal policies; however, since bundlebuilder doesn't exist in python3 it seems reasonable to close it. What functionality python2 has at this point is what it has. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 09:56:40 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 24 Jun 2016 13:56:40 +0000 Subject: [issue8406] Make some setup.py paths exclude-able In-Reply-To: <1271301152.77.0.297402624492.issue8406@psf.upfronthosting.co.za> Message-ID: <1466776600.11.0.22517679078.issue8406@psf.upfronthosting.co.za> R. David Murray added the comment: We don't close issues just because they are languishing. We'd need to know that the issue has been superseded or is otherwise no longer an issue. It sounds like this one falls into that category, since another issue is noted as a possible superseder, but I don't know enough about the issues involved to be sure. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 09:59:54 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 24 Jun 2016 13:59:54 +0000 Subject: [issue5225] OS X "Update Shell Profile" may not update $PATH if run more than once In-Reply-To: <1234440346.58.0.444916712806.issue5225@psf.upfronthosting.co.za> Message-ID: <1466776794.89.0.625316933235.issue5225@psf.upfronthosting.co.za> R. David Murray added the comment: Why is it out of date? Did Ned solve this another way at some point? What I'm getting at is just closing an issue as "out of date" is not enough, really, it is best to record *why* the issue is out of date. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 10:03:19 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 24 Jun 2016 14:03:19 +0000 Subject: [issue13759] Python 3.2.2 Mac installer version doesn't accept multibyte character in interactive mode In-Reply-To: <1326267416.18.0.541225422796.issue13759@psf.upfronthosting.co.za> Message-ID: <1466776999.15.0.876621034907.issue13759@psf.upfronthosting.co.za> R. David Murray added the comment: This isn't out of date, it appears that it was not a bug in the first place, but the OP never got back to us with confirmation one way or the other. ---------- nosy: +r.david.murray resolution: out of date -> works for me _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 10:07:21 2016 From: report at bugs.python.org (Carol Willing) Date: Fri, 24 Jun 2016 14:07:21 +0000 Subject: [issue5225] OS X "Update Shell Profile" may not update $PATH if run more than once In-Reply-To: <1234440346.58.0.444916712806.issue5225@psf.upfronthosting.co.za> Message-ID: <1466777241.78.0.869291228686.issue5225@psf.upfronthosting.co.za> Carol Willing added the comment: This issue was closed as "out of date" since there has been no activity on the issue in 7 years. IMHO the issue, if still relevant, should be opened as a new issue with better scope based on today's technology. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 10:08:53 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 24 Jun 2016 14:08:53 +0000 Subject: [issue13829] exception error in _scproxy.so when called after fork In-Reply-To: <1326998522.6.0.790472668429.issue13829@psf.upfronthosting.co.za> Message-ID: <1466777333.54.0.190123791978.issue13829@psf.upfronthosting.co.za> R. David Murray added the comment: Why is it out of date? Has it been fixed? Has apple changed their abort policy? Obviously it isn't high priority, though :) ---------- assignee: ronaldoussoren -> nosy: +r.david.murray priority: normal -> low resolution: out of date -> status: closed -> open title: exception error in _scproxy.so -> exception error in _scproxy.so when called after fork _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 10:10:26 2016 From: report at bugs.python.org (Carol Willing) Date: Fri, 24 Jun 2016 14:10:26 +0000 Subject: [issue5225] OS X "Update Shell Profile" may not update $PATH if run more than once In-Reply-To: <1234440346.58.0.444916712806.issue5225@psf.upfronthosting.co.za> Message-ID: <1466777426.75.0.784110815919.issue5225@psf.upfronthosting.co.za> Carol Willing added the comment: Perhaps it would be prudent to update the dev guide, or the contribution process, to close issues that have stagnated for years as opposed to marking them languishing. It would likely help with the issue backlog. Also, expanding out of date to reflect that an issue has not been touched in over 'x' years would be helpful too. Perhaps that should be an addition to the dev guide. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 10:12:27 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 24 Jun 2016 14:12:27 +0000 Subject: [issue21106] Updated Mac folder icon In-Reply-To: <1396214057.84.0.0230664527626.issue21106@psf.upfronthosting.co.za> Message-ID: <1466777547.58.0.0276280860287.issue21106@psf.upfronthosting.co.za> R. David Murray added the comment: We do not close issues just because they are old. Someone could still pick this up and contact psf legal and get this merged. ---------- nosy: +r.david.murray resolution: out of date -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 10:15:18 2016 From: report at bugs.python.org (Carol Willing) Date: Fri, 24 Jun 2016 14:15:18 +0000 Subject: [issue21106] Updated Mac folder icon In-Reply-To: <1396214057.84.0.0230664527626.issue21106@psf.upfronthosting.co.za> Message-ID: <1466777718.14.0.33675198289.issue21106@psf.upfronthosting.co.za> Carol Willing added the comment: R. David, I'm confused. There isn't anything actionable from a development standpoint on this issue. Why wouldn't it be marked languishing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 10:18:38 2016 From: report at bugs.python.org (Carol Willing) Date: Fri, 24 Jun 2016 14:18:38 +0000 Subject: [issue13759] Python 3.2.2 Mac installer version doesn't accept multibyte character in interactive mode In-Reply-To: <1326267416.18.0.541225422796.issue13759@psf.upfronthosting.co.za> Message-ID: <1466777918.6.0.275697160042.issue13759@psf.upfronthosting.co.za> Carol Willing added the comment: R. David, Fair enough. Thanks for pointing out the difference between 'out of date' and 'works for me'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 10:21:15 2016 From: report at bugs.python.org (Carol Willing) Date: Fri, 24 Jun 2016 14:21:15 +0000 Subject: [issue16821] bundlebuilder broken in 2.7 In-Reply-To: <1356903579.79.0.644714985612.issue16821@psf.upfronthosting.co.za> Message-ID: <1466778075.34.0.9270809681.issue16821@psf.upfronthosting.co.za> Carol Willing added the comment: R. David, Would there be a better resolution than 'out of date'? The other resolutions didn't really seem to fit either. Agree, that the issue is a moot point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 10:28:02 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 24 Jun 2016 14:28:02 +0000 Subject: [issue27344] zipfile *does* support utf-8 filenames In-Reply-To: <1466176126.21.0.0133629365393.issue27344@psf.upfronthosting.co.za> Message-ID: <1466778482.54.0.127257876889.issue27344@psf.upfronthosting.co.za> R. David Murray added the comment: I bet the existing wording is just left over from the python2 docs. I think cp437 should still be mentioned explicitly. And mentioning "setting the utf-8 flag" would probably make the explanation clearer, though I'm not sure. Tecnically speaking, I think zipfile supports utf8, not unicode. Or it supports unicode via utf-8. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 10:29:36 2016 From: report at bugs.python.org (Josh Lee) Date: Fri, 24 Jun 2016 14:29:36 +0000 Subject: [issue22455] idna/punycode give wrong results on narrow builds In-Reply-To: <1411337375.42.0.97875155095.issue22455@psf.upfronthosting.co.za> Message-ID: <1466778576.31.0.642229698634.issue22455@psf.upfronthosting.co.za> Changes by Josh Lee : ---------- nosy: +jleedev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 10:39:34 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 24 Jun 2016 14:39:34 +0000 Subject: [issue27363] Complex with negative zero imaginary part In-Reply-To: <1466535728.31.0.514028528898.issue27363@psf.upfronthosting.co.za> Message-ID: <1466779174.69.0.805112922398.issue27363@psf.upfronthosting.co.za> R. David Murray added the comment: That's a good point; however the goal of the "repr invariant" is to be able to losslessly reproduce the object when possible. The fact that you have to use the complex constructor to do that is unfortunate, but is a consequence of the underlying problem. I suspect that literal_eval, on the other hand, should reproduce what the interpreter does, but since I think it already doesn't do that 100% (though I can't offhand remember what makes me think that) perhaps that is a possibility. I'll reopen the issue to discuss that. ---------- resolution: rejected -> stage: resolved -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 10:41:08 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 24 Jun 2016 14:41:08 +0000 Subject: [issue27371] Runaway memory consumption using tkinter update() In-Reply-To: <1466629289.92.0.827863623566.issue27371@psf.upfronthosting.co.za> Message-ID: <1466779268.77.0.100179904307.issue27371@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 10:52:17 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 24 Jun 2016 14:52:17 +0000 Subject: [issue21106] Updated Mac folder icon In-Reply-To: <1396214057.84.0.0230664527626.issue21106@psf.upfronthosting.co.za> Message-ID: <1466779937.16.0.23396914197.issue21106@psf.upfronthosting.co.za> R. David Murray added the comment: Someone from the development team can contact legal, so yes there is a development action item here. It could be marked as languishing, but that status hasn't actually proven useful in practice and I think we should drop it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 10:52:56 2016 From: report at bugs.python.org (Dyl Tuckey) Date: Fri, 24 Jun 2016 14:52:56 +0000 Subject: [issue27382] calendar module .isleap() probleam Message-ID: <1466779976.93.0.849803568402.issue27382@psf.upfronthosting.co.za> New submission from Dyl Tuckey: I don't know why but whenever I try and run this code: import calendar import time calendar = calendar.month(2016,6) print ("Loading date, time, month and leap year status") time.sleep(5) print (calendar) localtime = time.asctime(time.localtime(time.time())) print (localtime) if calendar.isleap(2016) == True: print("This year is a leap year") else: print("This year is not a leap year") It come up with: Loading date, time, month and leap year status June 2016 Mo Tu We Th Fr Sa Su 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 Fri Jun 24 15:46:12 2016 Traceback (most recent call last): File "C:\Users\Dylan\Desktop\Python\Calendar.py", line 9, in if calendar.isleap(2016) == True: AttributeError: 'str' object has no attribute 'isleap' And I don't know why I keep getting error messages ---------- components: IDLE messages: 269183 nosy: Dyl Tuckey priority: normal severity: normal status: open title: calendar module .isleap() probleam type: compile error versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 10:56:31 2016 From: report at bugs.python.org (Emanuel Barry) Date: Fri, 24 Jun 2016 14:56:31 +0000 Subject: [issue27382] calendar module .isleap() probleam In-Reply-To: <1466779976.93.0.849803568402.issue27382@psf.upfronthosting.co.za> Message-ID: <1466780191.11.0.78253641487.issue27382@psf.upfronthosting.co.za> Emanuel Barry added the comment: You're overriding the 'calendar' variable, holding the module, by the result of your 'calender.month' call, which happens to be a str. Use a different variable name (e.g. 'result') and the error will disappear. Unrelated, but don't check for 'if x == True' - just do 'if x' and the result will be the same (also allows for any other result than booleans). ---------- components: -IDLE nosy: +ebarry resolution: -> not a bug stage: -> resolved status: open -> closed type: compile error -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 10:59:15 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 24 Jun 2016 14:59:15 +0000 Subject: [issue16821] bundlebuilder broken in 2.7 In-Reply-To: <1356903579.79.0.644714985612.issue16821@psf.upfronthosting.co.za> Message-ID: <1466780355.51.0.0781816949656.issue16821@psf.upfronthosting.co.za> R. David Murray added the comment: No, I think out of date is closest. It's no longer relevant because it no longer exists in python3, so its support date has effectively passed EOL :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 11:03:41 2016 From: report at bugs.python.org (Rob Bairos) Date: Fri, 24 Jun 2016 15:03:41 +0000 Subject: [issue27383] executuable in distutils triggering microsoft anti virus Message-ID: <1466780621.95.0.0684107940642.issue27383@psf.upfronthosting.co.za> New submission from Rob Bairos: python 3.5: wininst-14.0.exe Is triggering Microsoft Security Essentials virus detection: Recommended action: Remove this software immediately. Items: file:D:\PythonBuilds\202ee57ca3\py\Lib\distutils\command\wininst-14.0.exe I've tried on two separate machines so far, with same quarantine. Microsoft Security Essentials (running on Windows 7) Antimalware Client Version: 4.9.218.0 Engine Version: 1.1.12805.0 Antivirus definition: 1.223.2544.0 Antispyware definition: 1.223.2544.0 Network Inspection System Engine Version: 2.1.12706.0 Network Inspection System Definition Version: 116.10.0.0 ---------- components: Distutils messages: 269186 nosy: Rob Bairos, dstufft, eric.araujo priority: normal severity: normal status: open title: executuable in distutils triggering microsoft anti virus type: security versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 11:04:41 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 24 Jun 2016 15:04:41 +0000 Subject: [issue5225] OS X "Update Shell Profile" may not update $PATH if run more than once In-Reply-To: <1234440346.58.0.444916712806.issue5225@psf.upfronthosting.co.za> Message-ID: <1466780681.33.0.850562112233.issue5225@psf.upfronthosting.co.za> R. David Murray added the comment: I don't think "out of date" means "hasn't been touched in X years", I think it means "there is no longer any need to fix this issue". That might mean it is a bug in something we no longer support, or a bug that has been fixed accidentally by later development. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 11:06:48 2016 From: report at bugs.python.org (Zachary Ware) Date: Fri, 24 Jun 2016 15:06:48 +0000 Subject: [issue27383] executuable in distutils triggering microsoft anti virus In-Reply-To: <1466780621.95.0.0684107940642.issue27383@psf.upfronthosting.co.za> Message-ID: <1466780808.29.0.513037875384.issue27383@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 11:33:11 2016 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 24 Jun 2016 15:33:11 +0000 Subject: [issue22455] idna/punycode give wrong results on narrow builds In-Reply-To: <1411337375.42.0.97875155095.issue22455@psf.upfronthosting.co.za> Message-ID: <1466782391.89.0.525979498457.issue22455@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 11:33:17 2016 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 24 Jun 2016 15:33:17 +0000 Subject: [issue22079] Ensure in PyType_Ready() that base class of static type is static In-Reply-To: <1406378199.04.0.952325428414.issue22079@psf.upfronthosting.co.za> Message-ID: <1466782397.09.0.935823966665.issue22079@psf.upfronthosting.co.za> Xiang Zhang added the comment: I think we can start from index 1 instead of 0. ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 11:55:24 2016 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 24 Jun 2016 15:55:24 +0000 Subject: [issue27363] Complex with negative zero imaginary part In-Reply-To: <1466535728.31.0.514028528898.issue27363@psf.upfronthosting.co.za> Message-ID: <1466783724.68.0.684222638525.issue27363@psf.upfronthosting.co.za> Mark Dickinson added the comment: > I suspect that literal_eval, on the other hand, should reproduce what the interpreter does I think that's going to be awkward to achieve without making the behaviour of literal_eval significantly less obvious and more DWIMmy. And I'm not convinced that `literal_eval` should follow the behaviour of the complex constructor rather than the behaviour of plain `eval`. Of course, the "right" fix here is to change the complex repr entirely so that it looks like the compound object that it is rather than an eval-able expression: >>> repr(1+2j) complex(1.0, 2.0) That would break backwards compatibility, but given the number of times complaints come up on this tracker, I'm beginning to think it might be worth it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 12:24:41 2016 From: report at bugs.python.org (Daniel Holth) Date: Fri, 24 Jun 2016 16:24:41 +0000 Subject: [issue27344] zipfile *does* support utf-8 filenames In-Reply-To: <1466176126.21.0.0133629365393.issue27344@psf.upfronthosting.co.za> Message-ID: <1466785481.0.0.148483398629.issue27344@psf.upfronthosting.co.za> Daniel Holth added the comment: https://hg.python.org/cpython/file/2.6/Lib/zipfile.py#l331 Python 2.6 zipfile supports utf8 properly. It has only improved since then. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 12:40:27 2016 From: report at bugs.python.org (Dyl Tuckey) Date: Fri, 24 Jun 2016 16:40:27 +0000 Subject: [issue27382] calendar module .isleap() probleam In-Reply-To: <1466779976.93.0.849803568402.issue27382@psf.upfronthosting.co.za> Message-ID: <1466786427.96.0.874040524874.issue27382@psf.upfronthosting.co.za> Dyl Tuckey added the comment: Thank you ebarry. I would probably never have figured that out ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 12:44:00 2016 From: report at bugs.python.org (Chris Barker) Date: Fri, 24 Jun 2016 16:44:00 +0000 Subject: [issue27198] Adding an assertClose() method to unittest.TestCase In-Reply-To: <1464979712.74.0.398203716413.issue27198@psf.upfronthosting.co.za> Message-ID: <1466786640.64.0.860802233242.issue27198@psf.upfronthosting.co.za> Chris Barker added the comment: Thanks Robert. I'll try to find time to re-do the patch soon. There was enough resistance to the whole idea that I wanted some confirmation that is was worth my time to do that! Stay tuned. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 12:56:32 2016 From: report at bugs.python.org (Steve Dower) Date: Fri, 24 Jun 2016 16:56:32 +0000 Subject: [issue27383] executuable in distutils triggering microsoft anti virus In-Reply-To: <1466780621.95.0.0684107940642.issue27383@psf.upfronthosting.co.za> Message-ID: <1466787392.45.0.658359345364.issue27383@psf.upfronthosting.co.za> Steve Dower added the comment: Wow, that sucks. I just rebuilt it and it's still detected, so presumably somebody distributed malware as a bdist_exe and it made it into the signature. There haven't been any unexpected modifications to the sources. I've submitted the file to the right people, so hopefully it will be removed from the signature soon. ---------- assignee: -> steve.dower resolution: -> third party status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 13:10:12 2016 From: report at bugs.python.org (Vlad K.) Date: Fri, 24 Jun 2016 17:10:12 +0000 Subject: [issue26171] heap overflow in zipimporter module In-Reply-To: <1453348353.03.0.314168195173.issue26171@psf.upfronthosting.co.za> Message-ID: <1466788212.23.0.40212037547.issue26171@psf.upfronthosting.co.za> Vlad K. added the comment: Any updates on this? We've committed the patch for Python 3.3 as well in FreeBSD. https://svnweb.freebsd.org/ports?view=revision&revision=417019 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 13:15:23 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Jun 2016 17:15:23 +0000 Subject: [issue22079] Ensure in PyType_Ready() that base class of static type is static In-Reply-To: <1406378199.04.0.952325428414.issue22079@psf.upfronthosting.co.za> Message-ID: <1466788523.89.0.687180772708.issue22079@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Can you please explain? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 13:17:11 2016 From: report at bugs.python.org (Neil Schemenauer) Date: Fri, 24 Jun 2016 17:17:11 +0000 Subject: [issue27377] Add smarter socket.fromfd() In-Reply-To: <1466706816.6.0.72770597716.issue27377@psf.upfronthosting.co.za> Message-ID: <1466788631.48.0.620909577176.issue27377@psf.upfronthosting.co.za> Neil Schemenauer added the comment: Thank you for the excellent review Martin. I'm attaching a new patch which I think addresses your points. I created it from hg, maybe that works nicer. I've added constants for SO_DOMAIN, SO_PROTOCOL, SO_PASSCRED, SO_PEERSEC, and SO_PASSEC. Using SO_PROTOCOL to get the protocol value seems to work fine on Linux. I've dropped the union as you suggest. I think the docs have been fixed. I would be okay with making fdtype() a non-public function. It seems possibly useful though. Regarding the name, currently I think fromfd2 is best. It really does what fromfd() should have done if SO_TYPE/SO_PROTOCOL was available and portable. Extending fromfd() seems a bad idea. I don't want dup() and it seems better that application code can use hasattr() to test for new functionality. You can work around not having fromfd2() by using getsockname() and then using some ugly text matching to work out what kind of socket you have. ---------- Added file: http://bugs.python.org/file43530/fromfd2_v2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 13:18:12 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Jun 2016 17:18:12 +0000 Subject: [issue27371] Runaway memory consumption using tkinter update() In-Reply-To: <1466629289.92.0.827863623566.issue27371@psf.upfronthosting.co.za> Message-ID: <1466788692.46.0.846692848752.issue27371@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please file a report on Tk bugtracker? https://core.tcl.tk/tk/ticket ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 13:20:33 2016 From: report at bugs.python.org (Neil Schemenauer) Date: Fri, 24 Jun 2016 17:20:33 +0000 Subject: [issue18391] socket.fromfd()'s API is difficult or impossible to use correctly in general In-Reply-To: <1373153632.08.0.45299629619.issue18391@psf.upfronthosting.co.za> Message-ID: <1466788833.34.0.614218441399.issue18391@psf.upfronthosting.co.za> Neil Schemenauer added the comment: I've created a patch to add fromfd2(). I think it addresses the original concern of this issue. My patch also adds the constants suggested by Issue #26907. ---------- nosy: +nascheme _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 13:22:46 2016 From: report at bugs.python.org (Neil Schemenauer) Date: Fri, 24 Jun 2016 17:22:46 +0000 Subject: [issue18391] socket.fromfd()'s API is difficult or impossible to use correctly in general In-Reply-To: <1373153632.08.0.45299629619.issue18391@psf.upfronthosting.co.za> Message-ID: <1466788966.97.0.151785553846.issue18391@psf.upfronthosting.co.za> Neil Schemenauer added the comment: Sorry, forgot to link the patch: Issue #27377. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 13:23:20 2016 From: report at bugs.python.org (Neil Schemenauer) Date: Fri, 24 Jun 2016 17:23:20 +0000 Subject: [issue26907] Add missing getsockopt constants In-Reply-To: <1462199363.91.0.625327027717.issue26907@psf.upfronthosting.co.za> Message-ID: <1466789000.34.0.0470953993481.issue26907@psf.upfronthosting.co.za> Neil Schemenauer added the comment: Issue #27377 adds these constants. ---------- nosy: +nascheme _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 13:29:11 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Jun 2016 17:29:11 +0000 Subject: [issue27344] zipfile *does* support utf-8 filenames In-Reply-To: <1466176126.21.0.0133629365393.issue27344@psf.upfronthosting.co.za> Message-ID: <1466789351.97.0.808044726831.issue27344@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This note looks outdated. In 2.x 8-bit file names are written as is, implying cp437 or what your consumers expect. Unicode file names are encoded to ascii or utf-8 (with setting utf-8 flag). In 3.x only Unicode file names are accepted, and they always are encoded to ascii or utf-8. There is no way to write non-ascii non-utf-8 file names. cp437 is not used at all. Maybe just remove this misleading note? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 13:29:50 2016 From: report at bugs.python.org (Steve Dower) Date: Fri, 24 Jun 2016 17:29:50 +0000 Subject: [issue25042] Create an "embedding SDK" distribution? In-Reply-To: <1441806495.82.0.106064192938.issue25042@psf.upfronthosting.co.za> Message-ID: <1466789390.72.0.612390379703.issue25042@psf.upfronthosting.co.za> Steve Dower added the comment: This was done! Just never closed ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 13:40:33 2016 From: report at bugs.python.org (Rob Bairos) Date: Fri, 24 Jun 2016 17:40:33 +0000 Subject: [issue27383] executuable in distutils triggering microsoft anti virus In-Reply-To: <1466780621.95.0.0684107940642.issue27383@psf.upfronthosting.co.za> Message-ID: <1466790033.27.0.473467552986.issue27383@psf.upfronthosting.co.za> Rob Bairos added the comment: thanks for the quick action! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 15:03:52 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Jun 2016 19:03:52 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <20160624190348.17687.51134.C1F8DF71@psf.io> Roundup Robot added the comment: New changeset ea7b6a7827a4 by Brett Cannon in branch 'default': Issue #27186: Update os.fspath()/PyOS_FSPath() to check the return https://hg.python.org/cpython/rev/ea7b6a7827a4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 15:06:26 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 24 Jun 2016 19:06:26 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1466795186.1.0.491536638355.issue27186@psf.upfronthosting.co.za> Brett Cannon added the comment: And now that I have updated os.fspath() I realize that Ethan said he was going to implement the update. :( If you started on the work, Ethan, I'm really sorry for duplicating your (potential) work. I'm going to commit Dusty's glossary term next and then go through and update the docs to use it. At that point that will leave updating os.path as the last explicit step in PEP 519 that needs to be short of updating "What's New". We're getting there. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 15:13:32 2016 From: report at bugs.python.org (Matthew Malcomson) Date: Fri, 24 Jun 2016 19:13:32 +0000 Subject: [issue27384] itertools islice consumes items when given negative range Message-ID: <1466795612.87.0.341578291618.issue27384@psf.upfronthosting.co.za> New submission from Matthew Malcomson: While the itertools.islice(iterator, n, n) trick is useful as used in the consume recipe, I find the current behaviour if stop is less than start (e.g. itertools.islice(iterator, 3, 0) ) to be surprising. It still consumes the first three elements of the iterator, in the same manner as when start and stop are equal. This is what the documentation implies, but I don't know whether that coincidence is by accident or design. I would expect an iterator that immediately raises StopIteration but doesn't consume anything, but whether that's what most people would expect or not is another matter. This would match the python version of islice() in the documentation, though I realise that implementation already diverges from the actual one via Issue 27212 . ---------- components: Library (Lib) messages: 269206 nosy: Matthew Malcomson priority: normal severity: normal status: open title: itertools islice consumes items when given negative range type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 15:15:58 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Jun 2016 19:15:58 +0000 Subject: [issue27384] itertools islice consumes items when given negative range In-Reply-To: <1466795612.87.0.341578291618.issue27384@psf.upfronthosting.co.za> Message-ID: <1466795758.88.0.554596995981.issue27384@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 15:21:55 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Jun 2016 19:21:55 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <20160624192152.8029.32458.8EC68BFD@psf.io> Roundup Robot added the comment: New changeset 9c57178f13dc by Brett Cannon in branch 'default': Issue #27186: Define what a "path-like object" is. https://hg.python.org/cpython/rev/9c57178f13dc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 15:28:56 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 24 Jun 2016 19:28:56 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1466796536.72.0.783910631411.issue27186@psf.upfronthosting.co.za> Brett Cannon added the comment: I think with the glossary change, this issue is done! Thanks everyone for the help with getting this far! Now on to os.path... ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 15:33:23 2016 From: report at bugs.python.org (Ethan Furman) Date: Fri, 24 Jun 2016 19:33:23 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1466796803.06.0.669010538617.issue27186@psf.upfronthosting.co.za> Ethan Furman added the comment: Brett, no worries. My time has been extremely limited. I'll get the other locations in the stdlib fixed sometime in the next two months if no one beats me to it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 16:15:14 2016 From: report at bugs.python.org (Vlad K.) Date: Fri, 24 Jun 2016 20:15:14 +0000 Subject: [issue22928] HTTP header injection in urrlib2/urllib/httplib/http.client In-Reply-To: <1416797425.29.0.948172439575.issue22928@psf.upfronthosting.co.za> Message-ID: <1466799314.69.0.998109728006.issue22928@psf.upfronthosting.co.za> Vlad K. added the comment: Doesn't this affect Python 3.3 as well, which is in security-only mode? Shouldn't that version be patched as well? ---------- nosy: +vladk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 16:43:30 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 24 Jun 2016 20:43:30 +0000 Subject: [issue27182] PEP 519 support in the stdlib In-Reply-To: <1464887789.1.0.970652730446.issue27182@psf.upfronthosting.co.za> Message-ID: <1466801010.26.0.518977667151.issue27182@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- dependencies: -Add a "What's New" entry for PEP 519 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 16:58:00 2016 From: report at bugs.python.org (Grant Mathews) Date: Fri, 24 Jun 2016 20:58:00 +0000 Subject: [issue27385] itertools.groupby has misleading doc string Message-ID: <1466801880.76.0.293579802764.issue27385@psf.upfronthosting.co.za> New submission from Grant Mathews: The itertools.groupby function is generally well-documented, but the fact that it only groups consecutive occurrences of keys is not mentioned in the doc string, which is where that information is most needed. ---------- assignee: docs at python components: Documentation files: groupby_doc.patch keywords: patch messages: 269211 nosy: docs at python, gmathews priority: normal severity: normal status: open title: itertools.groupby has misleading doc string versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43531/groupby_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 17:03:23 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 24 Jun 2016 21:03:23 +0000 Subject: [issue26027] Support Path objects in the posix module In-Reply-To: <1452114329.99.0.617690911804.issue26027@psf.upfronthosting.co.za> Message-ID: <1466802203.95.0.381781506533.issue26027@psf.upfronthosting.co.za> Brett Cannon added the comment: Did you still want to handle this, Serhiy, or should I assign the issue to myself? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 17:14:53 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Jun 2016 21:14:53 +0000 Subject: [issue27038] Make os.DirEntry exist In-Reply-To: <1463413415.02.0.145090656269.issue27038@psf.upfronthosting.co.za> Message-ID: <20160624211450.618.78546.C8A825F5@psf.io> Roundup Robot added the comment: New changeset b841972ed0bd by Brett Cannon in branch 'default': Issue #27038: Expose DirEntry as os.DirEntry. https://hg.python.org/cpython/rev/b841972ed0bd ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 17:15:15 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 24 Jun 2016 21:15:15 +0000 Subject: [issue27038] Make os.DirEntry exist In-Reply-To: <1463413415.02.0.145090656269.issue27038@psf.upfronthosting.co.za> Message-ID: <1466802915.69.0.545034638885.issue27038@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks for the patch, Jelle! ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 17:47:53 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 24 Jun 2016 21:47:53 +0000 Subject: [issue27351] Unexpected ConfigParser.read() behavior when passed fileobject In-Reply-To: <1466311827.21.0.0107030173129.issue27351@psf.upfronthosting.co.za> Message-ID: <1466804873.07.0.826849680261.issue27351@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Doing what the doc says is not a bug. The doc being obsolete in saying 'list' (which was once true) instead of the now correct 'iterable' is. The 3.6 ConfigParser.__doc___ also says 'list', so both docstrings and docs for all current versions should be fixed. ---------- components: +Documentation nosy: +terry.reedy versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 19:03:07 2016 From: report at bugs.python.org (Ned Deily) Date: Fri, 24 Jun 2016 23:03:07 +0000 Subject: [issue27385] itertools.groupby has misleading doc string In-Reply-To: <1466801880.76.0.293579802764.issue27385@psf.upfronthosting.co.za> Message-ID: <1466809387.78.0.922877257403.issue27385@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +rhettinger stage: -> patch review versions: -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 19:46:32 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 24 Jun 2016 23:46:32 +0000 Subject: [issue26867] test_ssl test_options fails on ubuntu 16.04 In-Reply-To: <1461728238.71.0.110276038105.issue26867@psf.upfronthosting.co.za> Message-ID: <1466811992.03.0.715464065967.issue26867@psf.upfronthosting.co.za> Martin Panter added the comment: FWIW I had a quick look at ways to detect if you are running on Ubuntu. But platform.linux_distribution() seems to be deprecated and looks like it might have trouble differentiating Debian and Ubuntu. So it may be easier to just go with the current patch on all platforms, at least for the moment. Maybe if someone that uses Ubuntu could suggest a specific file or config the test can check for. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 22:14:02 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 25 Jun 2016 02:14:02 +0000 Subject: [issue26907] Add missing getsockopt constants In-Reply-To: <1462199363.91.0.625327027717.issue26907@psf.upfronthosting.co.za> Message-ID: <1466820842.49.0.335250593255.issue26907@psf.upfronthosting.co.za> Martin Panter added the comment: SO_PASSCRED was added to Python 3.3 as part of Issue 6560; it is just missing documentation. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 22:24:31 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 25 Jun 2016 02:24:31 +0000 Subject: [issue27385] itertools.groupby has misleading doc string In-Reply-To: <1466801880.76.0.293579802764.issue27385@psf.upfronthosting.co.za> Message-ID: <1466821471.2.0.847194718291.issue27385@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The patch is fine. ---------- assignee: docs at python -> rhettinger priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 24 22:29:45 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 25 Jun 2016 02:29:45 +0000 Subject: [issue27377] Add smarter socket.fromfd() In-Reply-To: <1466706816.6.0.72770597716.issue27377@psf.upfronthosting.co.za> Message-ID: <1466821785.38.0.960017672274.issue27377@psf.upfronthosting.co.za> Martin Panter added the comment: Okay, I guess the fdtype() API could be useful if we don?t alter fromfd(), i.e. as a workaround for Issue 18391. IMO the specific SO_* constants should at least be listed in the documentation, so users know which versions of Python have which constants. Although exposing them is not necessary for the fromfd() implementation. See also more comments on the code review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 01:34:47 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jun 2016 05:34:47 +0000 Subject: [issue27364] Deprecate invalid unicode escape sequences In-Reply-To: <1466541260.02.0.320668077341.issue27364@psf.upfronthosting.co.za> Message-ID: <1466832887.65.0.759558290929.issue27364@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 01:41:27 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jun 2016 05:41:27 +0000 Subject: [issue26027] Support Path objects in the posix module In-Reply-To: <1452114329.99.0.617690911804.issue26027@psf.upfronthosting.co.za> Message-ID: <1466833287.37.0.473404511032.issue26027@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'll take a look. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 02:36:11 2016 From: report at bugs.python.org (Jaysinh shukla) Date: Sat, 25 Jun 2016 06:36:11 +0000 Subject: [issue20674] Update comments in dictobject.c In-Reply-To: <1392744795.57.0.649500024154.issue20674@psf.upfronthosting.co.za> Message-ID: <1466836571.24.0.223457967083.issue20674@psf.upfronthosting.co.za> Jaysinh shukla added the comment: Improving last with with following points: 1. Removing string related examples 2. Updating int example with more readable way (According to me). Reviewer review the patch file named "issue20674_patch_v3.diff" ---------- Added file: http://bugs.python.org/file43532/issue20674_patch_v3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 02:42:32 2016 From: report at bugs.python.org (SilentGhost) Date: Sat, 25 Jun 2016 06:42:32 +0000 Subject: [issue20674] Update comments in dictobject.c In-Reply-To: <1392744795.57.0.649500024154.issue20674@psf.upfronthosting.co.za> Message-ID: <1466836952.62.0.845168294628.issue20674@psf.upfronthosting.co.za> SilentGhost added the comment: I've left comments on rietveld. Not sure if everyone's seeing them. ---------- nosy: +SilentGhost stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 03:09:13 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 25 Jun 2016 07:09:13 +0000 Subject: [issue22079] Ensure in PyType_Ready() that base class of static type is static In-Reply-To: <1406378199.04.0.952325428414.issue22079@psf.upfronthosting.co.za> Message-ID: <1466838553.26.0.132326370688.issue22079@psf.upfronthosting.co.za> Xiang Zhang added the comment: In the mro list I think the first is always the type itself which has already been checked to be a statically allocated type if we can touch the loop. Starting from 0 checks it twice and it's not a base either. BTW, I don't receive an email from the tracker. :( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 06:27:58 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 25 Jun 2016 10:27:58 +0000 Subject: [issue24364] Not all defects pass through email policy In-Reply-To: <1433263153.11.0.33312264244.issue24364@psf.upfronthosting.co.za> Message-ID: <1466850478.81.0.468244540829.issue24364@psf.upfronthosting.co.za> Martin Panter added the comment: I see that ?compat32? and ?default? are actually different things (Compat32 vs EmailPolicy classes). IMO ?default? was a bad choice of name, but I guess that ship has already sailed. This patch adds a test_defect_handling.TestCompat32 subclass, so the test methods are now run with compat32 as well as the ?default? policy. ---------- Added file: http://bugs.python.org/file43533/defect-fixes.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 06:30:38 2016 From: report at bugs.python.org (Michel Albert) Date: Sat, 25 Jun 2016 10:30:38 +0000 Subject: [issue20825] containment test for "ip_network in ip_network" In-Reply-To: <1393766299.38.0.300697561376.issue20825@psf.upfronthosting.co.za> Message-ID: <1466850638.19.0.175998632743.issue20825@psf.upfronthosting.co.za> Michel Albert added the comment: I just realised that the latest patch on this no longer applies properly. I have fixed the issue and I am currently in the process of running the unit-tests which takes a while. Once those pass, I'll update some metadata and resubmit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 06:47:15 2016 From: report at bugs.python.org (Michel Albert) Date: Sat, 25 Jun 2016 10:47:15 +0000 Subject: [issue20825] containment test for "ip_network in ip_network" In-Reply-To: <1393766299.38.0.300697561376.issue20825@psf.upfronthosting.co.za> Message-ID: <1466851635.35.0.563190628226.issue20825@psf.upfronthosting.co.za> Michel Albert added the comment: Test pass properly. Is there anything else left to do? Here's the fixed patch (net-in-net-r4.patch) ---------- Added file: http://bugs.python.org/file43534/net-in-net-r4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 06:52:02 2016 From: report at bugs.python.org (Jaysinh shukla) Date: Sat, 25 Jun 2016 10:52:02 +0000 Subject: [issue20842] pkgutil docs should reference glossary terms not PEP 302 In-Reply-To: <1393846400.67.0.723549613222.issue20842@psf.upfronthosting.co.za> Message-ID: <1466851922.66.0.986288662984.issue20842@psf.upfronthosting.co.za> Jaysinh shukla added the comment: Dear Martin, I observed your comment. I can see, issue mentioned by you http://bugs.python.org/issue26896 contains patch of clarifying the reference of Importer, Finder. The issue-26896 is still under review phase. It will be good step to update doc in this issue according to http://bugs.python.org/file42666/issue.diff patch? Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 06:58:52 2016 From: report at bugs.python.org (SilentGhost) Date: Sat, 25 Jun 2016 10:58:52 +0000 Subject: [issue20825] containment test for "ip_network in ip_network" In-Reply-To: <1393766299.38.0.300697561376.issue20825@psf.upfronthosting.co.za> Message-ID: <1466852332.96.0.847489667148.issue20825@psf.upfronthosting.co.za> SilentGhost added the comment: Have you seen my comments on rietveld re you previous patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 07:33:41 2016 From: report at bugs.python.org (Michel Albert) Date: Sat, 25 Jun 2016 11:33:41 +0000 Subject: [issue20825] containment test for "ip_network in ip_network" In-Reply-To: <1393766299.38.0.300697561376.issue20825@psf.upfronthosting.co.za> Message-ID: <1466854421.16.0.27719000194.issue20825@psf.upfronthosting.co.za> Michel Albert added the comment: Updated patch, taking into account notes from the previous patch-reviews ---------- Added file: http://bugs.python.org/file43535/net-in-net-r5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 07:36:37 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Sat, 25 Jun 2016 11:36:37 +0000 Subject: [issue27353] Add nroot function to math In-Reply-To: <1466456528.83.0.960818231433.issue27353@psf.upfronthosting.co.za> Message-ID: <20160625113628.GC27919@ando.pearwood.info> Steven D'Aprano added the comment: On Mon, Jun 20, 2016 at 09:02:09PM +0000, Tim Peters wrote: > Note that the very popular TI graphics calculators have had a distinct > nth-root function at least since the TI-83. It's a minor convenience > there. Likewise HP calculators ("xroot") and at least one Javascript library. But it does seem to be uncommon among programming languages. Which surprises me, because it is not just a convenience, it can be more accurate than using the generic pow(x, 1/n). But seeing as there isn't that much interest, I'll stick with a private function in statistics. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 07:46:09 2016 From: report at bugs.python.org (Jaysinh shukla) Date: Sat, 25 Jun 2016 11:46:09 +0000 Subject: [issue20674] Update comments in dictobject.c In-Reply-To: <1392744795.57.0.649500024154.issue20674@psf.upfronthosting.co.za> Message-ID: <1466855169.82.0.654114284519.issue20674@psf.upfronthosting.co.za> Jaysinh shukla added the comment: Agreeing with "SilentGhost". Demonstrating `hash()` example for type int using list comprehension. Review issue20674_patch_v5.diff Thanks! ---------- Added file: http://bugs.python.org/file43536/issue20674_patch_v5.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 07:46:51 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 25 Jun 2016 11:46:51 +0000 Subject: [issue20825] containment test for "ip_network in ip_network" In-Reply-To: <1393766299.38.0.300697561376.issue20825@psf.upfronthosting.co.za> Message-ID: <1466855211.54.0.441640395496.issue20825@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the updated patch. Some comments from a quick review: * We need tests for the TypeError branches in both methods * + 'of type %s' % type(other) type(other) -> type(other).__name__ * You can drop the XXX part in +XXX Instances of * Perhaps code duplication mentioned by SilentGhost can be eliminated by using the operator module ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 08:22:50 2016 From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=) Date: Sat, 25 Jun 2016 12:22:50 +0000 Subject: [issue27363] Complex with negative zero imaginary part In-Reply-To: <1466535728.31.0.514028528898.issue27363@psf.upfronthosting.co.za> Message-ID: <1466857370.88.0.9298473656.issue27363@psf.upfronthosting.co.za> Vedran ?a?i? added the comment: Mark, I think it would be a great idea. It would be consistent with both "str is straightforward, repr is reproducible", and with the idea that (evalable) repr is almost always of the form `typename(arguments)`. It would also get rid of that "supefluous-looking" parentheses around the repr, and put them in the right place: a call. :-) [ On the other hand, I started to think deeply about the reason why we cannot make 1-0j do the right thing, and I'm not so sure anymore. People usually say it's because we don't have separate imaginary type, but we don't need it: all we need is a separate _real_ type, and we have it: float. When Python subtracts 0j from a float 1.0, there is no absolute imperative that it has to do it in the same way as subtracting 0j from a complex(1.0, 0.0). We _can_ make it so the result of the former is complex(1.0, -0.0), and result of the latter is complex(1.0, 0.0). Of course, now even the imaginary complex numbers couldn't be outputed simply, and -0 real part should become -0.0, but it might be worth it. I understand it's enormously complicated though, and I'd be satisfied with a "normal" repr. Or a literal_eval that really understand complex numbers' repr. ] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 08:26:20 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 25 Jun 2016 12:26:20 +0000 Subject: [issue26896] mix-up with the terms 'importer', 'finder', 'loader' in the import system and related code In-Reply-To: <1462046496.61.0.778323150916.issue26896@psf.upfronthosting.co.za> Message-ID: <1466857580.82.0.941426270212.issue26896@psf.upfronthosting.co.za> Martin Panter added the comment: Oren: If you have extra changes to make on the same topic, it is probably best to make a new patch that combines both the original changes plus the new changes. Brett: Since you were responsible for the two dead assignments, your input would be helpful. Perhaps you meant to add extra code and forgot, or perhaps they are just useless and we can remove them. I skimmed over PEP 302, and it seems it uses the term ?importer? more or less to mean what the current glossary terms ?finder?. I.e. the first object to help with importing a module. Or maybe it means the system behind both the finder and loader stages, even if one object does not perform both steps. I don?t know much about this, but another option could be to redefine ?importer? as it is more generally used. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 08:41:51 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 25 Jun 2016 12:41:51 +0000 Subject: [issue20842] pkgutil docs should reference glossary terms not PEP 302 In-Reply-To: <1393846400.67.0.723549613222.issue20842@psf.upfronthosting.co.za> Message-ID: <1466858511.55.0.874899588966.issue20842@psf.upfronthosting.co.za> Martin Panter added the comment: I?m not sure what the best solution is. I am just pointing out the problem. It seems an ?importer? as mentioned in PEP 302 is more general than the current glossary definition. E.g. ImpImporter() returns an object that has a find_module() method (which partially makes it both a ?meta path finder? and a ?path entry finder?), but it has no load_module() method. So it fails the ?importer? definition according to the current glossary. ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 08:53:42 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 25 Jun 2016 12:53:42 +0000 Subject: [issue26865] Meta-issue: support of the android platform In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za> Message-ID: <1466859222.73.0.91774372523.issue26865@psf.upfronthosting.co.za> Xavier de Gaye added the comment: issue #23968: rename the platform directory from plat-$(MACHDEP) to plat-$(PLATFORM_TRIPLET) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 09:24:34 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 25 Jun 2016 13:24:34 +0000 Subject: [issue23968] rename the platform directory from plat-$(MACHDEP) to plat-$(PLATFORM_TRIPLET) In-Reply-To: <1429124647.47.0.946423694262.issue23968@psf.upfronthosting.co.za> Message-ID: <1466861074.08.0.252097150694.issue23968@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The same problem occurs when cross-compiling for Android and running test_sysconfig and test_distutils. Some other points: * The generation of the platform directory breaks the support of read only source trees. The files of this directory are not tracked by mercurial and printed by 'hg status'. * The new files in the platform directory are regenerated from C headers of the build machine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 08:55:48 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 25 Jun 2016 12:55:48 +0000 Subject: [issue26865] Meta-issue: support of the android platform In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za> Message-ID: <1466859348.96.0.183916691786.issue26865@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- dependencies: +rename the platform directory from plat-$(MACHDEP) to plat-$(PLATFORM_TRIPLET) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 09:46:49 2016 From: report at bugs.python.org (Michel Albert) Date: Sat, 25 Jun 2016 13:46:49 +0000 Subject: [issue20825] containment test for "ip_network in ip_network" In-Reply-To: <1393766299.38.0.300697561376.issue20825@psf.upfronthosting.co.za> Message-ID: <1466862409.3.0.967007895594.issue20825@psf.upfronthosting.co.za> Michel Albert added the comment: I don't quite see how the operator module could help. I don't have much experience with it though, so I might be missing something... I don't see how I can relate one check to the other. The example I gave in the patch review was the following: With the existing implementation: '192.168.1.0/25' subnet of '192.168.1.128/25' -> False '192.168.1.0/25' supernet of '192.168.1.128/25' -> False With the proposal to simply return "not subnet_of(...)" it would become: '192.168.1.0/25' subnet of '192.168.1.128/25' -> False '192.168.1.0/25' supernet of '192.168.1.128/25' -> True which would be wrong. I have now added the new test-cases for the TypeError and removed the code-duplication by introducing a new "private" function. Let me know what you think. I am running all test cases again and I'll uploaded it once they finished. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 10:35:37 2016 From: report at bugs.python.org (Michel Albert) Date: Sat, 25 Jun 2016 14:35:37 +0000 Subject: [issue20825] containment test for "ip_network in ip_network" In-Reply-To: <1393766299.38.0.300697561376.issue20825@psf.upfronthosting.co.za> Message-ID: <1466865337.95.0.501386018825.issue20825@psf.upfronthosting.co.za> Michel Albert added the comment: New patch with proposed changes. ---------- Added file: http://bugs.python.org/file43537/net-in-net-r6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 10:55:34 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 25 Jun 2016 14:55:34 +0000 Subject: [issue23968] rename the platform directory from plat-$(MACHDEP) to plat-$(PLATFORM_TRIPLET) In-Reply-To: <1429124647.47.0.946423694262.issue23968@psf.upfronthosting.co.za> Message-ID: <1466866534.63.0.286619910285.issue23968@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > The same problem occurs when cross-compiling for Android and running test_sysconfig and test_distutils. This is misleading. Actually, test_sysconfig and test_distutils do not fail when run from the source tree, but fail on an installed python, whatever the compilation mode: native or cross-compilation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 11:10:46 2016 From: report at bugs.python.org (Oren Milman) Date: Sat, 25 Jun 2016 15:10:46 +0000 Subject: [issue26896] mix-up with the terms 'importer', 'finder', 'loader' in the import system and related code In-Reply-To: <1462046496.61.0.778323150916.issue26896@psf.upfronthosting.co.za> Message-ID: <1466867446.57.0.861555164841.issue26896@psf.upfronthosting.co.za> Oren Milman added the comment: Except for some trailing spaces I have just found in my original proposed patches, I don't have any extra changes to add. So as soon as Brett answers about those two assignments, I would update and upload the patches diff file. With regard to terminology, I believe 'Explicit is better than implicit' fits here. IMHO using (in the code and docs) each of the three terms explicitly, with accordance to the glossary (https://docs.python.org/3/glossary.html#term-finder, https://docs.python.org/3/glossary.html#term-loader, https://docs.python.org/3/glossary.html#term-importer, all of which were first added back in revision 51025, BTW), makes the import mechanism clearer (than using 'importer' as an ambiguous term). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 11:17:51 2016 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 25 Jun 2016 15:17:51 +0000 Subject: [issue27363] Complex with negative zero imaginary part In-Reply-To: <1466535728.31.0.514028528898.issue27363@psf.upfronthosting.co.za> Message-ID: <1466867871.17.0.960817926468.issue27363@psf.upfronthosting.co.za> Mark Dickinson added the comment: > People usually say it's because we don't have separate imaginary type, but we don't need it. I think we do. Consider the case of something like -0 + 1j (the `repr` of complex(-0.0, 1.0)). That currently evaluates to `complex(0.0, 1.0)`, because the `-0.0` is combined with the `+0.0` real part of `1j`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 11:24:29 2016 From: report at bugs.python.org (Oren Milman) Date: Sat, 25 Jun 2016 15:24:29 +0000 Subject: [issue26896] mix-up with the terms 'importer', 'finder', 'loader' in the import system and related code In-Reply-To: <1462046496.61.0.778323150916.issue26896@psf.upfronthosting.co.za> Message-ID: <1466868269.15.0.470327350129.issue26896@psf.upfronthosting.co.za> Oren Milman added the comment: Also, Brett was the one who added the three terms to the glossary in https://hg.python.org/cpython/rev/ea5767ebd903, and a clarification of 'finder' in https://hg.python.org/cpython/rev/88cee7d16ccb, so I guess his input in this matter also would be helpful. (If both of you think the other way, I am probably wrong :) ) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 13:58:24 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 25 Jun 2016 17:58:24 +0000 Subject: [issue26186] LazyLoader rejecting use of SourceFileLoader In-Reply-To: <1453577280.26.0.226746274701.issue26186@psf.upfronthosting.co.za> Message-ID: <20160625175821.32495.78602.D2ECA0A8@psf.io> Roundup Robot added the comment: New changeset 7af4b3ad75b7 by Brett Cannon in branch 'default': Issue #26186: Remove the restriction that built-in and extension https://hg.python.org/cpython/rev/7af4b3ad75b7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 13:59:11 2016 From: report at bugs.python.org (Brett Cannon) Date: Sat, 25 Jun 2016 17:59:11 +0000 Subject: [issue26186] LazyLoader rejecting use of SourceFileLoader In-Reply-To: <1453577280.26.0.226746274701.issue26186@psf.upfronthosting.co.za> Message-ID: <1466877551.04.0.397593360188.issue26186@psf.upfronthosting.co.za> Brett Cannon added the comment: The restriction of lazily loading built-ins and extensions is now lifted! ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 14:01:40 2016 From: report at bugs.python.org (Brett Cannon) Date: Sat, 25 Jun 2016 18:01:40 +0000 Subject: [issue26896] mix-up with the terms 'importer', 'finder', 'loader' in the import system and related code In-Reply-To: <1462046496.61.0.778323150916.issue26896@psf.upfronthosting.co.za> Message-ID: <1466877700.01.0.768103206935.issue26896@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 14:02:11 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 25 Jun 2016 18:02:11 +0000 Subject: [issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more In-Reply-To: <1464270042.87.0.0233765451432.issue27130@psf.upfronthosting.co.za> Message-ID: <1466877731.69.0.925088216006.issue27130@psf.upfronthosting.co.za> Xiang Zhang added the comment: Add the newest version applying Martin's comments. ---------- Added file: http://bugs.python.org/file43538/64bit_support_for_zlib_v7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 15:21:09 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jun 2016 19:21:09 +0000 Subject: [issue22079] Ensure in PyType_Ready() that base class of static type is static In-Reply-To: <1406378199.04.0.952325428414.issue22079@psf.upfronthosting.co.za> Message-ID: <1466882469.79.0.352564297477.issue22079@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: __bases__ != mro() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 15:25:02 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jun 2016 19:25:02 +0000 Subject: [issue22928] HTTP header injection in urrlib2/urllib/httplib/http.client In-Reply-To: <1416797425.29.0.948172439575.issue22928@psf.upfronthosting.co.za> Message-ID: <1466882702.8.0.866873715523.issue22928@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 15:42:58 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 25 Jun 2016 19:42:58 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1466883778.77.0.525103804789.issue27051@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Raymond, since you are the one who proposed making a pip-gui accessible from IDLE, you might want to comment on where and how it should be installed. Ned Deily and Nick Coughlin are dubious about putting it anywhere in the stdlib, including idlelib. One alternative is putting it on PyPI. The discussion starts with Ned's first post, msg268947, on July 20. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 15:43:24 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 25 Jun 2016 19:43:24 +0000 Subject: [issue26243] zlib.compress level as keyword argument In-Reply-To: <1454179267.96.0.292283649228.issue26243@psf.upfronthosting.co.za> Message-ID: <20160625194321.22365.33723.6885F191@psf.io> Roundup Robot added the comment: New changeset 01f82a7a1250 by Serhiy Storchaka in branch 'default': Issue #26243: Only the level argument to zlib.compress() is keyword argument https://hg.python.org/cpython/rev/01f82a7a1250 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 15:47:27 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 25 Jun 2016 19:47:27 +0000 Subject: [issue26243] zlib.compress level as keyword argument In-Reply-To: <1454179267.96.0.292283649228.issue26243@psf.upfronthosting.co.za> Message-ID: <20160625194724.575.14700.DED042E7@psf.io> Roundup Robot added the comment: New changeset ab2e7e51869d by Serhiy Storchaka in branch 'default': Issue #26243: Correct a wording in docs. https://hg.python.org/cpython/rev/ab2e7e51869d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 15:48:19 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jun 2016 19:48:19 +0000 Subject: [issue26243] zlib.compress level as keyword argument In-Reply-To: <1454179267.96.0.292283649228.issue26243@psf.upfronthosting.co.za> Message-ID: <1466884099.46.0.864544658181.issue26243@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Berker and Martin. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 16:32:46 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 25 Jun 2016 20:32:46 +0000 Subject: [issue23551] IDLE to provide menu link to PIP gui. In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za> Message-ID: <1466886766.33.0.682561501818.issue23551@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Starting with June 20 msg268947 of #27051, Ned Deily raised the issue of adding something to the stdlib that depends on an external interface. Nick Coughlin agreed that this is problematical. Pipgui might have to be installed into site-packages from PyPI. Once pipgui is installed on somewhere on the path, it does not matter where, as IDLE will use some variant of ' -m pipgui'. The issue is getting it installed *somewhere*. Module mainmenu (Bindings in 3.5) uses the following code to conditionally add 'Turtle Demo' to the IDLE menu. from importlib.util import find_spec menudefs = ... if find_spec('turtledemo'): menudefs[-1][1].append(('Turtle Demo', '<>')) I believe the issue is that some Linux distributions either do or might make installing turtle-turtledemo a separate option from Tkinter and IDLE, so that IDLE might be installed but turtledemo not. If turtledemo is not present, there is nothing for IDLE to do. If pipgui is pip-installable, the same condition could be used , but in the menu event handler. When "if find_spec('pip') and not find_spec('pipgui')" is true, IDLE could offer to run 'python -m pip install pipgui' in a subprocess. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 16:36:26 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jun 2016 20:36:26 +0000 Subject: [issue22115] Add new methods to trace Tkinter variables In-Reply-To: <1406818071.8.0.276271200629.issue22115@psf.upfronthosting.co.za> Message-ID: <1466886986.94.0.0288720842594.issue22115@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your review Terry. Here is updated patch. IDLE now uses new API. ---------- Added file: http://bugs.python.org/file43539/tkinter_trace_variable_6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 16:53:16 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 25 Jun 2016 20:53:16 +0000 Subject: [issue24137] Force not using _default_root in IDLE In-Reply-To: <1430925977.27.0.721479362057.issue24137@psf.upfronthosting.co.za> Message-ID: <20160625205313.129695.57081.E03CF378@psf.io> Roundup Robot added the comment: New changeset a8d611eb6173 by Serhiy Storchaka in branch 'default': Issue #24137: Fixed IDLE on Linux with tkinter default root disabled. https://hg.python.org/cpython/rev/a8d611eb6173 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 16:54:09 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jun 2016 20:54:09 +0000 Subject: [issue24137] Force not using _default_root in IDLE In-Reply-To: <1430925977.27.0.721479362057.issue24137@psf.upfronthosting.co.za> Message-ID: <1466888049.04.0.0124686387744.issue24137@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: You have missed my changes in nodefaultroot2.diff. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 16:56:34 2016 From: report at bugs.python.org (Jim Fulton) Date: Sat, 25 Jun 2016 20:56:34 +0000 Subject: [issue27386] Asyncio server hang when clients connect and immediately disconnect Message-ID: <1466888194.59.0.640833210662.issue27386@psf.upfronthosting.co.za> New submission from Jim Fulton: I recently ported ZEO to asyncio. We'd had a bug in our old asyncore-based server where the server would hang if several connections were made and then immediately disconnected on Mac OS X. This was due to an error-handling bug in our code that we fixed. We have a regression test for this case. The regression test for this case fails using asyncio.Server. I've attached a (ZEO-independent) script that demonstrates the problem. If you run the script with Python 3.4 or 3.5, I expect the script will hang. It does for me on Mac OS X 10.10.5 and Ubuntu 14.04. ---------- components: asyncio files: echo.py messages: 269256 nosy: gvanrossum, haypo, j1m, yselivanov priority: normal severity: normal status: open title: Asyncio server hang when clients connect and immediately disconnect type: behavior versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file43540/echo.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 17:03:42 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 25 Jun 2016 21:03:42 +0000 Subject: [issue24364] Not all defects pass through email policy In-Reply-To: <1433263153.11.0.33312264244.issue24364@psf.upfronthosting.co.za> Message-ID: <1466888622.38.0.460737725638.issue24364@psf.upfronthosting.co.za> R. David Murray added the comment: The name default is future proofing. It will be the default...eventually :) And it is the default now if you use EmailMessage to construct your messages. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 17:05:01 2016 From: report at bugs.python.org (Larry Hastings) Date: Sat, 25 Jun 2016 21:05:01 +0000 Subject: [issue27365] Allow non-ascii chars in IDLE NEWS.txt (for contributor names) In-Reply-To: <1466564645.25.0.829598827477.issue27365@psf.upfronthosting.co.za> Message-ID: <1466888701.02.0.0902656800107.issue27365@psf.upfronthosting.co.za> Larry Hastings added the comment: If this is fixed, and resolved, why is it still open? Closing. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 17:05:24 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Jun 2016 21:05:24 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1466888724.7.0.051382088045.issue27051@psf.upfronthosting.co.za> Nick Coghlan added the comment: Terry, would you be open to overseeing the merge of a version that bootstrapped itself as follows: - IDLE gained a pip GUI launcher that, if the pip GUI was not importable, offered to install it from PyPI (always using a "--user" install if it doesn't detect an active virtual environment) - if the GUI was already importable, it would just launch it Then, pip-gui itself could just be a normal PyPI package, without any dependency vendoring, and without any specific coupling to the CPython release process. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 17:09:44 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 25 Jun 2016 21:09:44 +0000 Subject: [issue20350] Replace tkapp.split() to tkapp.splitlist() In-Reply-To: <1390411522.89.0.349086871577.issue20350@psf.upfronthosting.co.za> Message-ID: <20160625210941.4089.3618.A62B2B0E@psf.io> Roundup Robot added the comment: New changeset 8d78cd7c4a9e by Serhiy Storchaka in branch 'default': Issue #20350. tkapp.splitlist() is now always used instead of unreliable https://hg.python.org/cpython/rev/8d78cd7c4a9e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 17:11:27 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jun 2016 21:11:27 +0000 Subject: [issue20350] Replace tkapp.split() to tkapp.splitlist() In-Reply-To: <1390411522.89.0.349086871577.issue20350@psf.upfronthosting.co.za> Message-ID: <1466889087.73.0.379511821935.issue20350@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 17:16:39 2016 From: report at bugs.python.org (Larry Hastings) Date: Sat, 25 Jun 2016 21:16:39 +0000 Subject: [issue26867] test_ssl test_options fails on ubuntu 16.04 In-Reply-To: <1461728238.71.0.110276038105.issue26867@psf.upfronthosting.co.za> Message-ID: <1466889399.97.0.95505477226.issue26867@psf.upfronthosting.co.za> Larry Hastings added the comment: Well, as Donald Rumsfeld said in 2008: "As you know, you go to war with the army you have, not the army you might want or wish to have at a later time." 3.5.2 final and 3.4.5 final will ship with Matthias's patch as proposed. FWIW I'd accept an improved patch in both versions for the next release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 18:03:39 2016 From: report at bugs.python.org (Josh Purvis) Date: Sat, 25 Jun 2016 22:03:39 +0000 Subject: [issue27387] Thread hangs on str.encode() when locale is not set Message-ID: <1466892219.46.0.416121805197.issue27387@psf.upfronthosting.co.za> New submission from Josh Purvis: This bug manifest itself in at least one very specific situation: 1. No locale is set on the machine 2. A file (test1.py) imports a second (test2.py) 3. The second file (test2.py) calls str.encode() from inside a thread 4. Running Python 2.7 [Environment with no locale set]: # both of these are unset: $ echo $LC_CTYPE $ echo $LANG $ [test1.py]: import test2 [test2.py]: from threading import Thread class TestThread(Thread): def run(self): msg = 'Error from server: code=000a' print msg msg = msg.encode('utf-8') t = TestThread() t.start() t.join() print 'done' [Expected behavior]: $ python test1.py Error from server: code=000a done [Actual behavior]: $ python test1.py Error from server: code=000a [script hangs here indefinitely] Much thanks to Alan Boudreault, a developer of the cassandra-driver Python package, for helping me locate this bug and further narrow it down to the threading module. The above code snippet was copied from his comment on my issue over there (https://datastax-oss.atlassian.net/browse/PYTHON-592). Another curious behavior is that if you modify test1.py to decode any string prior to the import, it implicitly fixes the issue: [test1.py']: "any string".decode('utf-8') import test2 I realize that one should probably always have a locale set, however, this proved to be very difficult to isolate, especially given that it works if no import occurs or a string is decoded prior to the import. ---------- components: Interpreter Core, Unicode messages: 269262 nosy: ezio.melotti, haypo, joshpurvis priority: normal severity: normal status: open title: Thread hangs on str.encode() when locale is not set type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 18:17:36 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 25 Jun 2016 22:17:36 +0000 Subject: [issue23551] IDLE to provide menu link to PIP gui. In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za> Message-ID: <1466893056.01.0.00886600638695.issue23551@psf.upfronthosting.co.za> Terry J. Reedy added the comment: It is possible that some institution might block or remove a pip install. IDLE should check for the presence of pip itself before adding the menu entry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 18:35:35 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 25 Jun 2016 22:35:35 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1466894135.73.0.534784291079.issue27051@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Upendra: you own the code you are writing. Are you willing to create and maintain for some time a PyPI project? If so, Nick, Donald, or someone should be willing and able to help. If you do so, please make someone a backup co-owner, to make it less likely that it becomes an orphan project. It would be silly to tell beginners that they must learn to use a console to run pip to install pipgui so they can avoid using a console to run pip. If we go this route, I could, at least as a backup, have the IDLE menu event handle conditionally offer to install pipgui. See msg269252 of #23551. A separate 'ensurepipgui' doesn't seem necessary to me. Once pip is known to be installed, it can be used to install pipgui. Once pipgui exists, ensurepip should just install it as its last step. Nick, what do you think? One concern I have is that installing pipgui from PyPI seems more of a security risk than pre-installing it. Before committing to idlelib, I would review it before testing on my own machine. Any further changes would have to be by a core developer, and would be published on Python-checkins for anyone to review. The latter does not happen for external projects. (Upendra, please don't take offense from this. Donald is a core developer with a long history, including with security issues. You aren't. And I have not much experience with security issues either.) Another issue with pip and pipgui is that PyPI is apparently vulnerable to typosquatting attacks, see http://arstechnica.co.uk/security/2016/06/german-student-university-of-hamburg-typosquatting-attack/ I believe beginners are more susceptible to mistyping package names. The above report makes me realize that installing from a stored requirements list is a good idea, and think that pipgui, at least when run from IDLE, should install from a whitelist, (in idlelib, for IDLE?). Some instructors might require this or want to add or subtract names. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 19:18:29 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 25 Jun 2016 23:18:29 +0000 Subject: [issue24137] Force not using _default_root in IDLE In-Reply-To: <1430925977.27.0.721479362057.issue24137@psf.upfronthosting.co.za> Message-ID: <1466896709.73.0.779543549471.issue24137@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Using Rietveld to make a 1-2 diff for each file, it appears you made 3 changes. I incorporated 2, and missed 1 (which you just pushed). I believe I incorporated your changes by hand because I had already made additional changes myself. I suspect that at that time I failed to middle-click the '1' for 'pyshell' hard enough to get the 1-2 diff for pyshell. I should have counted and checked to make sure I had all 8 diffs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 19:37:25 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 25 Jun 2016 23:37:25 +0000 Subject: [issue23551] IDLE to provide menu link to PIP gui. In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za> Message-ID: <1466897845.62.0.756475843139.issue23551@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Nick, in answer to msg269259, see last two messages above. The commit would be here and I would want your review before committing. > always using a "--user" install if it doesn't detect an active virtual environment) I will look up what --user does. You will have to educate me (preferably with code) about 'detect an active virtual environment'. I have never used such. Is running in a venv safer with respect to downloading 3rd party code? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 19:38:30 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 25 Jun 2016 23:38:30 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1466897910.36.0.69665126083.issue27051@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Our messages crossed. See msg269266 for fuller response. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 19:44:07 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Jun 2016 23:44:07 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1466898246.98.0.864990890773.issue27051@psf.upfronthosting.co.za> Nick Coghlan added the comment: Right, I think we need to separate two questions here: 1. Making a GUI for pip available *at all*. At the moment, there isn't really one, so even if instructors want to offer one, they can't without writing it first. That's a reported PyPA issue here: https://github.com/pypa/packaging-problems/issues/57 2. Whether to endorse and bundle such a GUI with CPython, and integrate it with IDLE. I think the first aspect is an unequivocally good idea, and I'd encourage Upendra to head down that path to make it available to folks that are interested in having a cross-platform GUI for working with pip packages, regardless of what happens on the CPython integration front. For the second point, I'll note that Donald was a trusted *PyPA* developer prior to our collaboration on PEP 453 - he became a CPython core developer specifically to maintain ensurepip. I believe that "cross-community collaboration" model would also be a good fit for integration of a pip GUI distributed that was otherwise distributed via PyPI - we'd want core developers, or folks trusted by core developers, reviewing and maintaining the PyPI package, without necessarily pulling it directly into the CPython maintenance workflows. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 19:48:20 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Jun 2016 23:48:20 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1466898500.66.0.012943659135.issue27051@psf.upfronthosting.co.za> Nick Coghlan added the comment: As far as the security questions go, yes, this is one of the benefits of education focused stributions like the Raspbian used on the Raspberry Pi - they can make extra packages available without introducing kids to the idea of downloading and running arbitrary components from the internet before they're adequately equipped to judge the risks of what they're running. That's the other big reason I think the PyPI approach will be valuable - by offering educators something that's potentially useful to them (a pip GUI), you'd hopefully be able to attract more direct feedback around how to make it ever more suitable to that use case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 21:05:26 2016 From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=) Date: Sun, 26 Jun 2016 01:05:26 +0000 Subject: [issue27363] Complex with negative zero imaginary part In-Reply-To: <1466535728.31.0.514028528898.issue27363@psf.upfronthosting.co.za> Message-ID: <1466903126.58.0.269374591681.issue27363@psf.upfronthosting.co.za> Vedran ?a?i? added the comment: Yes, but IMO that's a separate issue. And if complex analysis has taught me anything, it's that the sign of zero of .imag is much more important than the sign of zero of .real part (most elementary functions have branch cuts along real axis, where sign of .imag ensures continuity on both sides). Of course, having both would be even better, but having only this part is a good part of a good thing. However, as I said, I know it's complicated. How about giving a "conventional" repr to complex? As far as I see, it's really not hard to implement - the only problem is backwards compatibility. But that was a problem when parentheses were added, too, right? [ And there would be one more benefit: We could finally say goodbye to weird "names" (infj, nanj) in the repr. By analogy with float, this could just be complex('nan', '-inf') or whatever. ] For what it's worth, I'm not sure we should try too hard to preserve complex(repr(z)) being z given isinstance(z, complex). For example, Fraction and Decimal don't have this property (while it does kinda hold for str instead of repr, and it would continue to kinda hold for str here). Yes, I know Fraction and Decimal aren't builtins and complex is, but I really think it's only because of syntax support for j-based literals. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 22:23:36 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 26 Jun 2016 02:23:36 +0000 Subject: [issue27388] IDLE configdialog: reduce multiple references to Var names Message-ID: <1466907816.0.0.0265609699186.issue27388@psf.upfronthosting.co.za> New submission from Terry J. Reedy: ConfigDialog uses nearl 20 tkinter Vars, and I expect to add more. The name of each appears in at least 6 places. In one of 'create tab frame' methods: 1. create the Var 2. use the Var with at least 1 tk widget In AttachVarCallbacks method: 3, 4. attach trace with callback with derived name self.varname.trace_add('write', self.VarChanged_varname) In remove_var_callbacks method (with delete call already factored out): 5. include Var in for loop tuple, to remove callback with "var.trace_remove('write', var.trace_info()[0][1])" In callback definition: 6. def VarChanged_varname The above uses the new trace method names that will be introduced in #22115, which I expect will be applied first. (I might also replace 'VarChanged_' with 'var_changed_' or something shorter, but this is not relevant here.) I propose to consolidate 1, 3, & 4 by replacing AttachVarCallbacks with def add_traced_var(varname): """Create var; bind to varname, append to list, and trace with callback. varname must match use in caller and callback def. """ var = tk.StringVar(self.root) setattr(self, varname, var) self.vars.append(var) cbsuffix = 'font' if varname.startswith('font') else varname var.trace_add('write', self.getattr('VarChanged_' + cbsuffix)) The cbsuffix local takes care of the complication that the 3 'fontWxyz' vars need the same callback. In any Var are not StringVars, add vartype parameter. Each tab frame creation method would call add_traced_var within a varname loop. The current varname tuple for 5. would be replaced with self.vars, which should then be cleared. This will leave 3 name occurrences that must match instead of 6. --- I believe 1-6 is complete. Varnames are translated to config item names within the callbacks, so do not have to match. For instance, def VarChanged_spaceNum(self, *params): value = self.spaceNum.get() self.AddChangedItem('main', 'Indent', 'num-spaces', value) translated 'spaceNum' to 'num-spaces'. On the other hand, I an not sure why the difference. For back compatibility, config names are fixed. The varnames, like method names, are internal to configdialog and can lowercased (PEP8) and otherwised changed. --- For testing, I will embed the add and delete methods in a dummy class with a couple of dummy callbacks. Then add, introspect, delete, and introspect again. ---------- assignee: terry.reedy messages: 269271 nosy: terry.reedy priority: normal severity: normal stage: test needed status: open title: IDLE configdialog: reduce multiple references to Var names type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 22:26:20 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 26 Jun 2016 02:26:20 +0000 Subject: [issue22115] Add new methods to trace Tkinter variables In-Reply-To: <1406818071.8.0.276271200629.issue22115@psf.upfronthosting.co.za> Message-ID: <1466907980.04.0.753445057084.issue22115@psf.upfronthosting.co.za> Terry J. Reedy added the comment: What's New: patchcheck found trailing whitespace to remove; it contains some additions that appear to belong to another issue. configdialog change looks good and dialog still works. I am expecting to add more Vars sometime soon, though probably not in the next few days. Before I do, I want to reduce the repetition of names and remove the repetition of trace_add calls. I just opened #27388. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 23:28:48 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 26 Jun 2016 03:28:48 +0000 Subject: [issue23551] IDLE to provide menu link to PIP gui. In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za> Message-ID: <1466911728.65.0.995578799649.issue23551@psf.upfronthosting.co.za> Nick Coghlan added the comment: Virtual environments don't provide any sandboxing, they just let you isolate different dependency sets from each other when switching between working on different applications. If you're inside a venv, you'll see either: sys.prefix != sys.base_prefix (venv created by Py3 stdlib) or: hasattr(sys, "real_prefix") (venv created by virtualenv) In this case, you can assume the user has write permissions to the virtual environment and just invoke sys.executable with "-m pip install pipgui" as arguments. If you're *not* in a virtual environment, you're running directly in the system Python, and the user may not have permission to install new packages for everyone (and even if they do, it's not necessarily a good idea). In that case, you want to pass "-m pip install --user pipgui", so the GUI components get installed in the user's home directory, rather than system wide. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 25 23:35:42 2016 From: report at bugs.python.org (Steven Barker) Date: Sun, 26 Jun 2016 03:35:42 +0000 Subject: [issue27389] When a TypeError is raised due to invalid arguments to a method, it should use __qualname__ to identify the class the method is in Message-ID: <1466912142.66.0.184362452129.issue27389@psf.upfronthosting.co.za> New submission from Steven Barker: When a method is called with incorrect arguments (too many or too few, for instance), a TypeError is raised. The message in the TypeError generally of the form: foo() takes 2 positional arguments but 3 were given I think the message should include the class name along with the method name, so it would say `SomeClass.foo` instead of just `foo`. Since that is `SomeClass.foo`'s __qualname__, it should not be too hard to get the right name in most situations. Here's an example showing how the current error messages can be ambiguous: class A: def foo(self, x): pass class B: def foo(self, x, y): # different method signature! pass lst = [A(), B()] for item in lst: item.foo(1) # raises TypeError: foo() missing 1 required positional argument: 'y'" for item in lst: item.foo(1, 2) # raises "TypeError: foo() takes 2 positional arguments but 3 were given" In neither loop is is clear which class's `foo` method is causing the exception (nor does the traceback help, since it only shows the `item.foo(...)` line). Of course, in this example it's easy to see the two classes have `foo` methods with different signatures, but if there were hundreds of objects in the list and they were instances of dozens of different classes it would be rather more annoying to figure out which class has the incorrect method signature. I've looked through the code and the two exceptions above come from the `format_missing` and `too_many_positional` functions in Python/ceval.c . It's not obvious how to patch them to use `__qualname__` instead of `__name__`, since they are taking the name from a code object, rather than a function object or bound method object (and code objects don't have an equivalent to `__qualname__`, only `co_name` which is related to `__name__`). Several other argument related TypeError exceptions are raised directly in _PyEval_EvalCodeWithName, which *does* have a `qualname` parameter, though the function doesn't use it for much. It's also where the other functions described above get called from, so it could probably pass the `qualname` along to them. Alas, it seems that in some common cases (such as calling a Python function with any kind of argument unpacking like `*foo` or `**foo`), the value of the `qualname` parameter is actually Null, so it may not be of much help. A few extra TypeErrors related to function calls are raised directly in the gigantic `PyEval_EvalFrameEx` function. These seem to all use `PyEval_GetFuncName` to get the name, so perhaps we could modify its behavior to return the method's `__qualname__` rather than the `__name__`. (I have no idea what backwards compatibility issues this might cause. Perhaps a new function that returns the qualname would be better.) ---------- messages: 269274 nosy: Steven.Barker priority: normal severity: normal status: open title: When a TypeError is raised due to invalid arguments to a method, it should use __qualname__ to identify the class the method is in type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 01:10:57 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 26 Jun 2016 05:10:57 +0000 Subject: [issue22079] Ensure in PyType_Ready() that base class of static type is static In-Reply-To: <1406378199.04.0.952325428414.issue22079@psf.upfronthosting.co.za> Message-ID: <1466917857.04.0.675062041111.issue22079@psf.upfronthosting.co.za> Xiang Zhang added the comment: Of course, I know it. But doesn't the local variable `bases` refer to mro[1]? [1] https://hg.python.org/cpython/file/tip/Objects/typeobject.c#l4900 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 01:41:23 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jun 2016 05:41:23 +0000 Subject: [issue22115] Add new methods to trace Tkinter variables In-Reply-To: <1406818071.8.0.276271200629.issue22115@psf.upfronthosting.co.za> Message-ID: <1466919683.36.0.536764356613.issue22115@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Maybe omit the mention of the array mode since it can't be used with variables created with Tkinter wrapper? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 01:44:45 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jun 2016 05:44:45 +0000 Subject: [issue27387] Thread hangs on str.encode() when locale is not set In-Reply-To: <1466892219.46.0.416121805197.issue27387@psf.upfronthosting.co.za> Message-ID: <1466919885.89.0.950481194995.issue27387@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +brett.cannon, eric.snow, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 01:59:47 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 26 Jun 2016 05:59:47 +0000 Subject: [issue22115] Add new methods to trace Tkinter variables In-Reply-To: <1406818071.8.0.276271200629.issue22115@psf.upfronthosting.co.za> Message-ID: <1466920787.36.0.26259814904.issue22115@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Good idea. Anyone who knows enough to create one by calling into tcl, assuming that is possible, should know that the methods apply. Everyone else, like me, will just be confused. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 02:28:03 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jun 2016 06:28:03 +0000 Subject: [issue22079] Ensure in PyType_Ready() that base class of static type is static In-Reply-To: <1406378199.04.0.952325428414.issue22079@psf.upfronthosting.co.za> Message-ID: <1466922483.66.0.854405734809.issue22079@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Good point! tp_bases should be iterated instead of tp_mro in this check. ---------- resolution: fixed -> stage: resolved -> patch review status: closed -> open Added file: http://bugs.python.org/file43541/issue22079-tp_bases.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 02:40:23 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 26 Jun 2016 06:40:23 +0000 Subject: [issue22079] Ensure in PyType_Ready() that base class of static type is static In-Reply-To: <1406378199.04.0.952325428414.issue22079@psf.upfronthosting.co.za> Message-ID: <1466923223.67.0.00366514922592.issue22079@psf.upfronthosting.co.za> Xiang Zhang added the comment: I thought that too at first. But if we use __bases__, can we still guarantee that 'all bases of statically allocated type should be statically allocated'? How about its grand bases? Is it possible that a statically allocated type inherit a dynamic type but does not go through PyType_Ready and then be inherited? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 02:47:23 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 26 Jun 2016 06:47:23 +0000 Subject: [issue22115] Add new methods to trace Tkinter variables In-Reply-To: <1406818071.8.0.276271200629.issue22115@psf.upfronthosting.co.za> Message-ID: <20160626064719.26828.31501.9D741E1C@psf.io> Roundup Robot added the comment: New changeset a201180c0f77 by Serhiy Storchaka in branch 'default': Issue #22115: Added methods trace_add, trace_remove and trace_info in the https://hg.python.org/cpython/rev/a201180c0f77 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 04:58:24 2016 From: report at bugs.python.org (STINNER Victor) Date: Sun, 26 Jun 2016 08:58:24 +0000 Subject: [issue27387] Thread hangs on str.encode() when locale is not set In-Reply-To: <1466892219.46.0.416121805197.issue27387@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: It is a deadlock on the import lock. You should avoid creating and waiting for a thread when a module is imported. Defer the creation of the thread. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 07:24:11 2016 From: report at bugs.python.org (INADA Naoki) Date: Sun, 26 Jun 2016 11:24:11 +0000 Subject: [issue27350] Compact and ordered dict In-Reply-To: <1466307796.29.0.980579044792.issue27350@psf.upfronthosting.co.za> Message-ID: <1466940251.4.0.781794681425.issue27350@psf.upfronthosting.co.za> Changes by INADA Naoki : Added file: http://bugs.python.org/file43542/compact-dict.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 08:47:32 2016 From: report at bugs.python.org (Thomas Klausner) Date: Sun, 26 Jun 2016 12:47:32 +0000 Subject: [issue27390] state of the 3.3 branch unclear Message-ID: <1466945252.66.0.729536599683.issue27390@psf.upfronthosting.co.za> New submission from Thomas Klausner: https://www.python.org/dev/peps/pep-0398/ mentions that a 3.3.7 release was planned for February 27, 2016. It appears this never happened. It also mentions that there will be source-only security updates for 3.3.x until September 2017. However, it appears that for example https://bugs.python.org/issue22417 from 2014 was never fixed for 3.3.x. (perhaps it did not affect 3.3.x, but it affected 2.7 and 3.4, so the chances are high it did) I'm not particularly interested in a release -- I'm fine with declaring 3.3.x end-of-life, but the documentation should match the reality. Thanks. ---------- components: Interpreter Core messages: 269282 nosy: wiz priority: normal severity: normal status: open title: state of the 3.3 branch unclear type: security versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 09:04:16 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 26 Jun 2016 13:04:16 +0000 Subject: [issue27389] When a TypeError is raised due to invalid arguments to a method, it should use __qualname__ to identify the class the method is in In-Reply-To: <1466912142.66.0.184362452129.issue27389@psf.upfronthosting.co.za> Message-ID: <1466946256.61.0.356667588727.issue27389@psf.upfronthosting.co.za> Martin Panter added the comment: Have a look at Issue 2786. I think it might be the same thing. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 09:11:17 2016 From: report at bugs.python.org (Upendra Kumar) Date: Sun, 26 Jun 2016 13:11:17 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1466946677.41.0.0538031851191.issue27051@psf.upfronthosting.co.za> Upendra Kumar added the comment: In ref. to msg269264: @Terry, I am ready to maintain this project. But for as backup is concerned I really don't know a lot of people and where should I look for them. In reference to msg269038: I was more engrossed in reading through other messages related to pip gui that I forgot to clarify about it. For pip install and uninstall command, I have used the pip.main() instead of subprocess module. There were two reasons for it ( what I thought): 1. More reliable, because I thought the output on CLI may change more frequently than arguments in pip.main(). (I think may be this assumption is wrong). 2. I figured out a way to clear pip loggers ( which caused to produce duplicate output ). I found it on a issue in pip Github repo : Adding one line of : pip.logger.consumers = [] in runpip(). It cleared the pip loggers responsible for producing duplicate output. ( due to this I liked pip.main(). The only troubling part about it was duplicate output ) This is just what I thought. I can very easily switch to subprocess module. Very less changes will be required in the code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 09:41:12 2016 From: report at bugs.python.org (Upendra Kumar) Date: Sun, 26 Jun 2016 13:41:12 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1466948472.23.0.659074718013.issue27051@psf.upfronthosting.co.za> Upendra Kumar added the comment: I am trying something similar to BrownTruck in issue : https://github.com/pypa/pip/pull/3733 I tried to execute pip.main('install','-U',) from a thread. I got a similar error : Traceback (most recent call last): File "/usr/local/lib/python3.4/dist-packages/pip/commands/install.py", line 299, in run requirement_set.prepare_files(finder) File "/usr/local/lib/python3.4/dist-packages/pip/req/req_set.py", line 370, in prepare_files ignore_dependencies=self.ignore_dependencies)) File "/usr/local/lib/python3.4/dist-packages/pip/req/req_set.py", line 476, in _prepare_file with indent_log(): File "/usr/lib/python3.4/contextlib.py", line 59, in __enter__ return next(self.gen) File "/usr/local/lib/python3.4/dist-packages/pip/utils/logging.py", line 34, in indent_log _log_state.indentation += num AttributeError: '_thread._local' object has no attribute 'indentation' There is some problem with threading.local() in pip.utils.logging. Can anyone please suggest a workaround for it. It is necessary for me to use threads other than the main GUI thread to update text. I need to update text and do long processes ( like searching for results using pip search command or installing or uninstalling) when someone presses a button. When I don't use threading to update text, the GUI text is updated only after the callback returns. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 09:44:25 2016 From: report at bugs.python.org (Upendra Kumar) Date: Sun, 26 Jun 2016 13:44:25 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1466948665.42.0.88600526473.issue27051@psf.upfronthosting.co.za> Upendra Kumar added the comment: Refer to : msg269285 This is the code : ............... from pip_tkinter.utils import pip_install_from_PyPI curr_item = self.multi_items_list.scroll_tree.focus() item_dict = self.multi_items_list.scroll_tree.item(curr_item) selected_module = item_dict['values'][0] self.controller.debug_bar.config( text='Installing package {}...Please wait'.format(selected_module)) self.install_queue = queue.Queue() self.install_thread = threading.Thread( target=pip_install_from_PyPI, kwargs={ 'package_args':selected_module, 'thread_queue':self.install_queue}) self.install_thread.start() self.after(100, self.check_install_queue) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 10:31:02 2016 From: report at bugs.python.org (Andre Merzky) Date: Sun, 26 Jun 2016 14:31:02 +0000 Subject: [issue23395] _thread.interrupt_main() errors if SIGINT handler in SIG_DFL, SIG_IGN In-Reply-To: <1423093850.42.0.241477195496.issue23395@psf.upfronthosting.co.za> Message-ID: <1466951462.01.0.970744069409.issue23395@psf.upfronthosting.co.za> Andre Merzky added the comment: Did anything ever come of this? I also frequently stumble over that error -- but alas not in a debug setting, but on actual running code... :/ ---------- nosy: +Andre Merzky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 10:48:18 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 26 Jun 2016 14:48:18 +0000 Subject: [issue22115] Add new methods to trace Tkinter variables In-Reply-To: <1406818071.8.0.276271200629.issue22115@psf.upfronthosting.co.za> Message-ID: <20160626144812.16172.47947.6948B219@psf.io> Roundup Robot added the comment: New changeset 77378dce6bcf by Serhiy Storchaka in branch '2.7': Issue #22115: Fixed tracing Tkinter variables. https://hg.python.org/cpython/rev/77378dce6bcf New changeset 293ec9547334 by Serhiy Storchaka in branch '3.5': Issue #22115: Fixed tracing Tkinter variables: https://hg.python.org/cpython/rev/293ec9547334 New changeset c4839c36a71f by Serhiy Storchaka in branch 'default': Issue #22115: Updated Misc/NEWS. https://hg.python.org/cpython/rev/c4839c36a71f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 10:49:33 2016 From: report at bugs.python.org (Thomas Kluyver) Date: Sun, 26 Jun 2016 14:49:33 +0000 Subject: [issue23395] _thread.interrupt_main() errors if SIGINT handler in SIG_DFL, SIG_IGN In-Reply-To: <1423093850.42.0.241477195496.issue23395@psf.upfronthosting.co.za> Message-ID: <1466952573.19.0.839681609144.issue23395@psf.upfronthosting.co.za> Thomas Kluyver added the comment: As far as I know it has not been fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 10:51:23 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jun 2016 14:51:23 +0000 Subject: [issue22115] Add new methods to trace Tkinter variables In-Reply-To: <1406818071.8.0.276271200629.issue22115@psf.upfronthosting.co.za> Message-ID: <1466952683.3.0.117784934216.issue22115@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Backported fixes for old tracing methods. Unfortunately the tracing in the "u" mode doesn't work in 2.7. This is related to some differences in GC. I don't think this is important and close this issue. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 11:02:27 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jun 2016 15:02:27 +0000 Subject: [issue22079] Ensure in PyType_Ready() that base class of static type is static In-Reply-To: <1406378199.04.0.952325428414.issue22079@psf.upfronthosting.co.za> Message-ID: <1466953347.16.0.791662648648.issue22079@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is interesting question. It looks that base classes (as well as mro classes) may not go through PyType_Ready. There is no even a check that mro() returns only ancestor classes and contains the initial class itself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 11:43:57 2016 From: report at bugs.python.org (Jim Fulton) Date: Sun, 26 Jun 2016 15:43:57 +0000 Subject: [issue27391] server_hostname should only be required when checking host names Message-ID: <1466955837.8.0.0746303655033.issue27391@psf.upfronthosting.co.za> New submission from Jim Fulton: If the given ssl context has check_hostname set to False, then the server_hostname shouldn't be required. ---------- components: asyncio messages: 269292 nosy: gvanrossum, haypo, j1m, yselivanov priority: normal severity: normal status: open title: server_hostname should only be required when checking host names type: behavior versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 12:05:17 2016 From: report at bugs.python.org (Jim Fulton) Date: Sun, 26 Jun 2016 16:05:17 +0000 Subject: [issue27392] Add a server_side keyword parameter to create_connection Message-ID: <1466957117.0.0.423625085233.issue27392@psf.upfronthosting.co.za> New submission from Jim Fulton: The event loop create_connection method can take a socket to create a connection on an existing socket, including sockets obtained via an external listener. If an SSL context is provided, however, it assumes it's creating a client connection, making it impossible to use it in a server. I've recently ported ZEO to asyncio. My original implementation used a separate thread for each connection and a thread for listening for connections. I think there are cases where this makes a lot of sense. Blocky operations only affect one client and, IMO, using an asynchronous model can simplify networking code even when there's only one connection. Unfortunately, this didn't work on Linux with SSL due to issues with SSL and non-blocking sockets. (Oddly, it worked fine on Mac OS X.) I've switched my code to use create_server, but this has led to stability problems. Beyond http://bugs.python.org/issue27386, I'm seeing a lot of test instability. I can't get through the ZEO tests without some test failing, although the tests pass when run individually. I suspect that this is due to a problem in my error handling, asyncio's error handling, or likely both. Note that the ZEO test suite is pretty ruthless, doing whatever they can to break ZEO servers and clients. I have a version of my multi-threaded code that monkey-patches loop instances to pass server_side=True to _make_ssl_transport. With that awful hack, I can use an external listener and tests usually run without errors. :) I'd be more than happy to create a PR that adds this option (including test and docs). Please just give me the word. :) ---------- components: asyncio messages: 269293 nosy: gvanrossum, haypo, j1m, yselivanov priority: normal severity: normal status: open title: Add a server_side keyword parameter to create_connection type: enhancement versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 12:14:55 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jun 2016 16:14:55 +0000 Subject: [issue16137] Using time.asctime() with an array with negative tm_hour causes Python Crash. In-Reply-To: <1349390143.92.0.685174043431.issue16137@psf.upfronthosting.co.za> Message-ID: <1466957695.28.0.810146528685.issue16137@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Benjamin, there is a crash, and there is a simple patch that presumably fixes a crash. I think fixing crashes has high priority. The patch is tested on Linux and needs to be tested on Windows. ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 12:17:15 2016 From: report at bugs.python.org (Brett Cannon) Date: Sun, 26 Jun 2016 16:17:15 +0000 Subject: [issue27390] state of the 3.3 branch unclear In-Reply-To: <1466945252.66.0.729536599683.issue27390@psf.upfronthosting.co.za> Message-ID: <1466957835.02.0.901102835551.issue27390@psf.upfronthosting.co.za> Brett Cannon added the comment: New releases of Python 3.3 are on hold pending a security fix: https://mail.python.org/pipermail/python-dev/2016-February/143400.html ---------- nosy: +brett.cannon, georg.brandl resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 12:32:52 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 26 Jun 2016 16:32:52 +0000 Subject: [issue26865] Meta-issue: support of the android platform In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za> Message-ID: <1466958772.62.0.62910075488.issue26865@psf.upfronthosting.co.za> Xavier de Gaye added the comment: issue #22724: byte-compile fails for cross-builds ---------- dependencies: +byte-compile fails for cross-builds _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 12:41:39 2016 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 26 Jun 2016 16:41:39 +0000 Subject: [issue27392] Add a server_side keyword parameter to create_connection In-Reply-To: <1466957117.0.0.423625085233.issue27392@psf.upfronthosting.co.za> Message-ID: Yury Selivanov added the comment: > On Jun 26, 2016, at 12:05 PM, Jim Fulton wrote: > > I've switched my code to use create_server, but this has led to stability problems. BTW, did you try to run ZEO tests on uvloop? I'm just curious if stability is somehow related to asyncio design, or its just implementation quirks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 13:21:57 2016 From: report at bugs.python.org (Andre Merzky) Date: Sun, 26 Jun 2016 17:21:57 +0000 Subject: [issue23395] _thread.interrupt_main() errors if SIGINT handler in SIG_DFL, SIG_IGN In-Reply-To: <1423093850.42.0.241477195496.issue23395@psf.upfronthosting.co.za> Message-ID: <1466961717.71.0.729804765205.issue23395@psf.upfronthosting.co.za> Andre Merzky added the comment: Thanks for the PingBack, Thomas. I am not very familiar with the Python community approach to bug reports, so can someone comment if that is worth waiting for to get fixed, or is it that a rather futile hope without providing a patch myself? I don't think I currently have the resources to dig into the details... Thanks, Andre. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 13:24:07 2016 From: report at bugs.python.org (Andre Merzky) Date: Sun, 26 Jun 2016 17:24:07 +0000 Subject: [issue23395] _thread.interrupt_main() errors if SIGINT handler in SIG_DFL, SIG_IGN In-Reply-To: <1423093850.42.0.241477195496.issue23395@psf.upfronthosting.co.za> Message-ID: <1466961847.18.0.783886823289.issue23395@psf.upfronthosting.co.za> Changes by Andre Merzky : ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 13:28:33 2016 From: report at bugs.python.org (Manuel Kaufmann) Date: Sun, 26 Jun 2016 17:28:33 +0000 Subject: [issue27393] Command to activate venv in Windows has wrong path Message-ID: <1466962113.91.0.904493080486.issue27393@psf.upfronthosting.co.za> New submission from Manuel Kaufmann: The `venv` module has a bug in the command to activate it on Windows. In 3.3 and 3.4 the bar used is wrong: `/` instead `\` * https://docs.python.org/3.4/library/venv.html#creating-virtual-environments * https://docs.python.org/3.3/library/venv.html#creating-virtual-environments In 3.5 and 3.6 that section was converted to a table with the commands and they are missing the `\` in the command path: * https://docs.python.org/3.5/library/venv.html#creating-virtual-environments * https://docs.python.org/dev/library/venv.html#creating-virtual-environments ---------- assignee: docs at python components: Documentation files: venv-windows-command.patch keywords: patch messages: 269299 nosy: docs at python, facundobatista, humitos priority: normal severity: normal status: open title: Command to activate venv in Windows has wrong path type: enhancement versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43543/venv-windows-command.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 13:40:16 2016 From: report at bugs.python.org (Thomas Kluyver) Date: Sun, 26 Jun 2016 17:40:16 +0000 Subject: [issue23395] _thread.interrupt_main() errors if SIGINT handler in SIG_DFL, SIG_IGN In-Reply-To: <1423093850.42.0.241477195496.issue23395@psf.upfronthosting.co.za> Message-ID: <1466962816.69.0.609072870478.issue23395@psf.upfronthosting.co.za> Thomas Kluyver added the comment: It's waiting for someone to make a patch - I'm no longer running into it, so it's not high on my priority list. Given that it's been over a year since I created this issue, it's probably not about to get fixed unless you've got some time to work on it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 13:44:04 2016 From: report at bugs.python.org (Andre Merzky) Date: Sun, 26 Jun 2016 17:44:04 +0000 Subject: [issue23395] _thread.interrupt_main() errors if SIGINT handler in SIG_DFL, SIG_IGN In-Reply-To: <1423093850.42.0.241477195496.issue23395@psf.upfronthosting.co.za> Message-ID: <1466963044.5.0.2839493557.issue23395@psf.upfronthosting.co.za> Andre Merzky added the comment: Thanks Thomas. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 13:46:10 2016 From: report at bugs.python.org (Jim Fulton) Date: Sun, 26 Jun 2016 17:46:10 +0000 Subject: [issue27386] Asyncio server hang when clients connect and immediately disconnect In-Reply-To: <1466888194.59.0.640833210662.issue27386@psf.upfronthosting.co.za> Message-ID: <1466963170.44.0.289579911954.issue27386@psf.upfronthosting.co.za> Jim Fulton added the comment: FWIW, using uvloop avoids the hang. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 15:08:33 2016 From: report at bugs.python.org (Andre Merzky) Date: Sun, 26 Jun 2016 19:08:33 +0000 Subject: [issue23395] _thread.interrupt_main() errors if SIGINT handler in SIG_DFL, SIG_IGN In-Reply-To: <1423093850.42.0.241477195496.issue23395@psf.upfronthosting.co.za> Message-ID: <1466968113.56.0.192537009483.issue23395@psf.upfronthosting.co.za> Andre Merzky added the comment: Attached is a patch which seems to resolve the issue for me -- this now triggers the expected `KeyboardInterrupt` in the main thread. For verification one can run the unaltered code as provided by Thomas. I would very much appreciate feedback, to make sure that the semantics is actually what one would expect. The patch is against the 2.7 branch from https://github.com/python/cpython.git, and I did not test it against any other branch. I also opened a pull request (https://github.com/python/cpython/pull/39). ---------- keywords: +patch Added file: http://bugs.python.org/file43544/issue23395.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 15:20:17 2016 From: report at bugs.python.org (Thomas Kluyver) Date: Sun, 26 Jun 2016 19:20:17 +0000 Subject: [issue23395] _thread.interrupt_main() errors if SIGINT handler in SIG_DFL, SIG_IGN In-Reply-To: <1423093850.42.0.241477195496.issue23395@psf.upfronthosting.co.za> Message-ID: <1466968817.03.0.297014293269.issue23395@psf.upfronthosting.co.za> Thomas Kluyver added the comment: Does Py_DECREF(arglist); need to be called in all cases? I'm genuinely unsure, as I don't usually work on C code, but my guess would be that it does. I'm not sure whether review is now done on Github. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 15:37:05 2016 From: report at bugs.python.org (Eryk Sun) Date: Sun, 26 Jun 2016 19:37:05 +0000 Subject: [issue16137] Using time.asctime() with an array with negative tm_hour causes Python Crash. In-Reply-To: <1349390143.92.0.685174043431.issue16137@psf.upfronthosting.co.za> Message-ID: <1466969825.68.0.0882350960979.issue16137@psf.upfronthosting.co.za> Eryk Sun added the comment: To resolve the crash on Windows in 2.7 requires backporting checktm(). Using asctime_s doesn't solve the problem. The CRT still calls the default invalid parameter handler, which kills the process -- as shown by the following ctypes example: from ctypes import * libc = CDLL('msvcr90') class tm(Structure): _fields_ = (('tm_sec', c_int), ('tm_min', c_int), ('tm_hour', c_int), ('tm_mday', c_int), ('tm_mon', c_int), ('tm_year', c_int), ('tm_wday', c_int), ('tm_yday', c_int), ('tm_isdst', c_int)) libc._localtime32.restype = POINTER(tm) libc.asctime_s.restype = c_char_p t = c_int() libc._time32(byref(t)) lt = libc._localtime32(byref(t)) sbuf = (c_char * 100)() >>> libc.asctime_s(sbuf, sizeof(sbuf), lt) >>> sbuf.value 'Sun Jun 26 19:22:47 2016\n' >>> lt[0].tm_hour = -1 >>> libc.asctime_s(sbuf, sizeof(sbuf), lt) Breakpoint 0 hit MSVCR90!_invoke_watson: 00000000`6b8950e4 4053 push rbx 0:000> k5 Child-SP RetAddr Call Site 00000000`005ef628 00000000`6b8952d4 MSVCR90!_invoke_watson 00000000`005ef630 00000000`6b859830 MSVCR90!_invalid_parameter+0x70 00000000`005ef670 00000000`1d1aff53 MSVCR90!asctime_s+0x2fc 00000000`005ef6b0 00000000`1d1ae7fc _ctypes!ffi_call_AMD64+0x77 00000000`005ef700 00000000`1d1aa4c6 _ctypes!ffi_call+0x8c ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 15:51:42 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jun 2016 19:51:42 +0000 Subject: [issue27352] Bug in IMPORT_NAME In-Reply-To: <1466337192.83.0.569731150376.issue27352@psf.upfronthosting.co.za> Message-ID: <1466970702.25.0.370595421864.issue27352@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Sorry, I was wrong. The level argument is always non-negative integer (if a bytecode is not corrupted). The second branch can be just removed. Following patch also fixes the validation of the ImportFrom AST node. ---------- nosy: +benjamin.peterson, georg.brandl, yselivanov stage: commit review -> patch review type: behavior -> enhancement versions: -Python 2.7, Python 3.5 Added file: http://bugs.python.org/file43545/import_name_level_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 15:53:29 2016 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 26 Jun 2016 19:53:29 +0000 Subject: [issue16137] Using time.asctime() with an array with negative tm_hour causes Python Crash. In-Reply-To: <1349390143.92.0.685174043431.issue16137@psf.upfronthosting.co.za> Message-ID: <1466970809.56.0.511247175286.issue16137@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 15:58:58 2016 From: report at bugs.python.org (Andre Merzky) Date: Sun, 26 Jun 2016 19:58:58 +0000 Subject: [issue23395] _thread.interrupt_main() errors if SIGINT handler in SIG_DFL, SIG_IGN In-Reply-To: <1423093850.42.0.241477195496.issue23395@psf.upfronthosting.co.za> Message-ID: <1466971138.33.0.267225875579.issue23395@psf.upfronthosting.co.za> Andre Merzky added the comment: thanks for looking into this! And also, thanks for the details in the original bug report -- I found this by chance, after unsuccessfully banging my head against this very problem for quite a while! I am not sure if the DecRef needs to be called really if the arglist is not stored or passed on. But thanks for pointing that out, I'll check if I can find where the corresponding IncRef is called (assuming that happens somewhere). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 16:09:35 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Sun, 26 Jun 2016 20:09:35 +0000 Subject: [issue27386] Asyncio server hang when clients connect and immediately disconnect In-Reply-To: <1466888194.59.0.640833210662.issue27386@psf.upfronthosting.co.za> Message-ID: <1466971775.46.0.942539295066.issue27386@psf.upfronthosting.co.za> ???? ????????? added the comment: Please reduce program, and make sure it still hangs. ---------- nosy: +mmarkk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 16:18:53 2016 From: report at bugs.python.org (Andre Merzky) Date: Sun, 26 Jun 2016 20:18:53 +0000 Subject: [issue23395] _thread.interrupt_main() errors if SIGINT handler in SIG_DFL, SIG_IGN In-Reply-To: <1423093850.42.0.241477195496.issue23395@psf.upfronthosting.co.za> Message-ID: <1466972333.26.0.666325730565.issue23395@psf.upfronthosting.co.za> Andre Merzky added the comment: It seems you were right, that needed a DecRef indeed: the IncRef is already called on construction. The DecRef for the result also needed fixing - an updated patch is attached. ---------- Added file: http://bugs.python.org/file43546/issue23395.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 16:54:07 2016 From: report at bugs.python.org (R. David Murray) Date: Sun, 26 Jun 2016 20:54:07 +0000 Subject: [issue27387] Thread hangs on str.encode() when locale is not set In-Reply-To: <1466892219.46.0.416121805197.issue27387@psf.upfronthosting.co.za> Message-ID: <1466974447.19.0.856768238866.issue27387@psf.upfronthosting.co.za> R. David Murray added the comment: This situation is warned about explicitly in the threading docs (https://docs.python.org/2/library/threading.html#importing-in-threaded-code). The import deadlock is fixed in python3, but it is still a really bad idea to launch threads on module import. What isn't obvious, of course, is that calling encode for the first time for a given encoding does an implicit import of the relevant encoding. I don't think encodings is the only stdlib module that does implicit imports, but it is probably the most used case. Maybe it is worth adding a warning to that section of the 2.7 docs about implicit imports in general and encode/decode in particular? ---------- assignee: -> docs at python components: +Documentation -Interpreter Core, Unicode nosy: +docs at python, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 17:01:45 2016 From: report at bugs.python.org (R. David Murray) Date: Sun, 26 Jun 2016 21:01:45 +0000 Subject: [issue27391] server_hostname should only be required when checking host names In-Reply-To: <1466955837.8.0.0746303655033.issue27391@psf.upfronthosting.co.za> Message-ID: <1466974905.51.0.475642707267.issue27391@psf.upfronthosting.co.za> R. David Murray added the comment: Where is it required? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 17:02:54 2016 From: report at bugs.python.org (R. David Murray) Date: Sun, 26 Jun 2016 21:02:54 +0000 Subject: [issue27391] server_hostname should only be required when checking host names In-Reply-To: <1466955837.8.0.0746303655033.issue27391@psf.upfronthosting.co.za> Message-ID: <1466974974.16.0.645642629655.issue27391@psf.upfronthosting.co.za> R. David Murray added the comment: (To clarify: I haven't used the ssl interface enough for it to be obvious to me where the bug is.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 17:17:09 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 26 Jun 2016 21:17:09 +0000 Subject: [issue24833] IDLE tabnanny check fails In-Reply-To: <1439106719.71.0.370110584661.issue24833@psf.upfronthosting.co.za> Message-ID: <1466975829.82.0.217091082322.issue24833@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- assignee: -> terry.reedy resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 17:37:56 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 26 Jun 2016 21:37:56 +0000 Subject: [issue27386] Asyncio server hang when clients connect and immediately disconnect In-Reply-To: <1466971775.46.0.942539295066.issue27386@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Yeah, I'd like to see a more minimal repro to understand what's going in. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 17:38:15 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jun 2016 21:38:15 +0000 Subject: [issue27255] More opcode predictions In-Reply-To: <1465324904.47.0.783952984943.issue27255@psf.upfronthosting.co.za> Message-ID: <1466977095.49.0.863637745837.issue27255@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Since existing predictions were added many new opcodes and opcode combinations were added. Predictions need to be updated to reflect current status. The patch contained only predictions for highly predictive (>=94%) pairs of commonly used opcodes or 100% predictive pairs of uncommonly used opcodes (but they can be more common in specific applications). The second version of the patch contains only 100% predictions. It doesn't depend on any statistics, the compiler always generate these opcodes in pairs. ---------- Added file: http://bugs.python.org/file43547/more_opcode_predicts_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 17:41:12 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 26 Jun 2016 21:41:12 +0000 Subject: [issue27392] Add a server_side keyword parameter to create_connection In-Reply-To: Message-ID: Guido van Rossum added the comment: I'm confused. create_connection() is meant for creating client connection, so I don't think a server_side flag makes sense. (There are lower-level internal APIs that do take a server_side flag, but create_connection() is just one caller for these.) If create_server() is buggy we should fix those bugs! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 17:41:52 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jun 2016 21:41:52 +0000 Subject: [issue27253] More efficient deepcopying of Mapping In-Reply-To: <1465320913.02.0.739523600127.issue27253@psf.upfronthosting.co.za> Message-ID: <1466977312.83.0.999506536584.issue27253@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 17:41:58 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jun 2016 21:41:58 +0000 Subject: [issue27252] Make dict views copyable In-Reply-To: <1465316849.69.0.0784684578474.issue27252@psf.upfronthosting.co.za> Message-ID: <1466977318.4.0.491212075974.issue27252@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 17:43:05 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 26 Jun 2016 21:43:05 +0000 Subject: [issue27372] Test_idle should stop changing locale In-Reply-To: <1466629469.32.0.618350098053.issue27372@psf.upfronthosting.co.za> Message-ID: <1466977385.33.0.773439066824.issue27372@psf.upfronthosting.co.za> Changes by Terry J. Reedy : Added file: http://bugs.python.org/file43548/locale-change2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 17:43:28 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jun 2016 21:43:28 +0000 Subject: [issue23401] Add pickle support of Mapping views In-Reply-To: <1423216735.87.0.773240969368.issue23401@psf.upfronthosting.co.za> Message-ID: <1466977408.51.0.670548577343.issue23401@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Can this issue be closed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 17:44:46 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 26 Jun 2016 21:44:46 +0000 Subject: [issue23401] Add pickle support of Mapping views In-Reply-To: <1466977408.51.0.670548577343.issue23401@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Please close. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 17:47:37 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 26 Jun 2016 21:47:37 +0000 Subject: [issue27372] Test_idle should stop changing locale In-Reply-To: <1466629469.32.0.618350098053.issue27372@psf.upfronthosting.co.za> Message-ID: <1466977657.66.0.99069025186.issue27372@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Added a couple of blank lines and expanded a comment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 17:48:18 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 26 Jun 2016 21:48:18 +0000 Subject: [issue27372] Test_idle should stop changing locale In-Reply-To: <1466629469.32.0.618350098053.issue27372@psf.upfronthosting.co.za> Message-ID: <20160626214815.3354.4302.19C11854@psf.io> Roundup Robot added the comment: New changeset 3ffdb9277054 by Terry Jan Reedy in branch 'default': Issue 27372: Stop test_idle from changing locale, so test passes. https://hg.python.org/cpython/rev/3ffdb9277054 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 17:49:20 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 26 Jun 2016 21:49:20 +0000 Subject: [issue27372] Test_idle should stop changing locale In-Reply-To: <1466629469.32.0.618350098053.issue27372@psf.upfronthosting.co.za> Message-ID: <1466977760.11.0.296355491099.issue27372@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 Sun Jun 26 17:59:59 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jun 2016 21:59:59 +0000 Subject: [issue22890] StringIO.StringIO pickled in 2.7 is not unpickleable on 3.x In-Reply-To: <1416210085.6.0.932097721403.issue22890@psf.upfronthosting.co.za> Message-ID: <1466978399.56.0.39385482636.issue22890@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There is the _compat_pickle module that purposed to support backward and forward compatibility for renamed or moved classes and modules. StringIO.StringIO in 2.x corresponds to io.StringIO or io.BytesIO. The problem is that we can't determine what of classes is a match in every concrete case, especially if StringIO.StringIO is empty. But since cStringIO.StringIO is not pickleable either, I now think that it is not worth to support to support compatibility with pickled StringIO.StringIO instances. ---------- resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 18:00:37 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jun 2016 22:00:37 +0000 Subject: [issue27173] Modern Unix key bindings for IDLE In-Reply-To: <1464766185.36.0.150155479026.issue27173@psf.upfronthosting.co.za> Message-ID: <1466978437.38.0.825346145702.issue27173@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 18:03:01 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jun 2016 22:03:01 +0000 Subject: [issue23401] Add pickle support of Mapping views In-Reply-To: <1423216735.87.0.773240969368.issue23401@psf.upfronthosting.co.za> Message-ID: <1466978581.95.0.787530108894.issue23401@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 18:19:53 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 26 Jun 2016 22:19:53 +0000 Subject: [issue27364] Deprecate invalid unicode escape sequences In-Reply-To: <1466541260.02.0.320668077341.issue27364@psf.upfronthosting.co.za> Message-ID: <1466979593.39.0.0983323261364.issue27364@psf.upfronthosting.co.za> Guido van Rossum added the comment: I am okay with making it a silent warning. Can we do it in two stages though? It doesn't have to be two releases, I just mean two separate commits: (1) fix all places in the stdlib that violate this principle; (2) separately commit the code that causes the silent deprecation (and tests for it). What exactly was the hard crash you got? Do you think it was a bug in your own C code or in existing C code? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 19:04:24 2016 From: report at bugs.python.org (Emanuel Barry) Date: Sun, 26 Jun 2016 23:04:24 +0000 Subject: [issue27364] Deprecate invalid unicode escape sequences In-Reply-To: <1466541260.02.0.320668077341.issue27364@psf.upfronthosting.co.za> Message-ID: <1466982264.35.0.873174930784.issue27364@psf.upfronthosting.co.za> Emanuel Barry added the comment: I originally considered making two different patches, so there you go. deprecate_invalid_escapes_only_1.patch has the deprecation plus a test, and invalid_stdlib_escapes_1.patch fixes all invalid escapes in the stdlib. My code was the cause, although no directly; it was 'assert(!PyErr_Occurred())' at the beginning of PyObject_Call in Objects/abstract.c which failed. This happened when I ran the whole test suite (although just running test_ast was fine to reproduce it) with the '-W error' command line switch. One stdlib module (I don't remember which one) had one single invalid escape sequence in it, and then test_ast.ASTValidatorTests.test_stdlib_validates triggered the failed assertion. Fixing the invalid escape removes the failure and all tests pass. One can reliably reproduce the crash with the patch by adding a string with an invalid escape in any of the stdlib files (and running with '-W error'): No invalid sequence: >>> import unittest, test.test_ast >>> unittest.main(test.test_ast) .............................................................................. ---------------------------------------------------------------------- Ran 78 tests in 5.538s OK With an invalid sequence in a file: >>> import unittest, test.test_ast >>> unittest.main(test.test_ast) ............................................Fatal Python error: a function returned a result with an error set DeprecationWarning: invalid escape sequence 'w' During handling of the above exception, another exception occurred: SystemError: returned a result with an error set Current thread 0x00001ba0 (most recent call first): File "E:\GitHub\cpython\lib\ast.py", line 35 in parse File "E:\GitHub\cpython\lib\test\test_ast.py", line 944 in test_stdlib_validates File "E:\GitHub\cpython\lib\unittest\case.py", line 600 in run File "E:\GitHub\cpython\lib\unittest\case.py", line 648 in __call__ File "E:\GitHub\cpython\lib\unittest\suite.py", line 122 in run File "E:\GitHub\cpython\lib\unittest\suite.py", line 84 in __call__ File "E:\GitHub\cpython\lib\unittest\suite.py", line 122 in run File "E:\GitHub\cpython\lib\unittest\suite.py", line 84 in __call__ File "E:\GitHub\cpython\lib\unittest\runner.py", line 176 in run File "E:\GitHub\cpython\lib\unittest\main.py", line 255 in runTests File "E:\GitHub\cpython\lib\unittest\main.py", line 94 in __init__ File "", line 1 in Then I get the usual "Python has stopped working" Windows prompt (strangely enough, before I'd get a prompt saying "Assertion failed" with the line, but not this time). I'm not sure where the error lies exactly. Should I open another issue for that? ---------- Added file: http://bugs.python.org/file43549/deprecate_invalid_escapes_only_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 19:04:39 2016 From: report at bugs.python.org (Emanuel Barry) Date: Sun, 26 Jun 2016 23:04:39 +0000 Subject: [issue27364] Deprecate invalid unicode escape sequences In-Reply-To: <1466541260.02.0.320668077341.issue27364@psf.upfronthosting.co.za> Message-ID: <1466982279.08.0.651089443873.issue27364@psf.upfronthosting.co.za> Changes by Emanuel Barry : Added file: http://bugs.python.org/file43550/invalid_stdlib_escapes_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 19:16:29 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 26 Jun 2016 23:16:29 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1466982989.49.0.350939764871.issue27051@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Upendra, with respect to the error installing timingwheel, msg268983, that looks like a bug in timingwheel. Report it to the pip or timingwheel list or tracker. I ran the command normally and got the same exception, with less noise. It is not a problem with using main. C:\Programs\Python36>python -m pip install -U timingwheel Collecting timingwheel Downloading timingwheel-0.4.tar.gz Complete output from command python setup.py egg_info: Traceback (most recent call last): File "", line 1, in File "C:\Users\Terry\AppData\Local\Temp\pip-build-ypf8yppj\timingwheel\setup.py", line 3, in from timingwheel import version File "C:\Users\Terry\AppData\Local\Temp\pip-build-ypf8yppj\timingwheel\timingwheel\__init__.py", line 1, in from timingwheel import BaseWheel, TimingWheel ImportError: cannot import name 'BaseWheel' ---------------------------------------- Command "python setup.py egg_info" failed with error code 1 in C:\Users\Terry\AppData\Local\Temp\pip-build-ypf8yppj\timingwheel\ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 19:41:19 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 26 Jun 2016 23:41:19 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1466984479.89.0.57514465794.issue27051@psf.upfronthosting.co.za> Terry J. Reedy added the comment: With respect to threading: I have close to 0 experience. I know that tkinter is supposed to be 'thread-safe' (Martin Loewis) and that people have real problems mixing threads with tkinter. If you can create a minimal complete verifiable example (SO MCVE), try asking on python-list, or SO, so you can reach people who do know threading. I suppose you can already guess my thought: for a first draft, block and let users wait. For anything I have done with pip, that would not be very long. I have done preliminary successful experiments with integrating asyncio and tkinter loop. When I posted to the python-ideas thread on the subject, I got no response, so I moved on. Perhaps I should work on it some more, but I am also busy with IDLE. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 20:05:31 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 27 Jun 2016 00:05:31 +0000 Subject: [issue27364] Deprecate invalid unicode escape sequences In-Reply-To: <1466982281.31.0.0266140770325.issue27364@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Hm, if you manage to trigger an assert() in the C code by writing some evil Python code, the C code is considered broken (unless it was using ctypes or one or two other explicit "void-the-warranty" exceptions). Maybe someone who has worked more with the C code recently could help you dig into this more; my memory is unreliable when it comes to these details. Maybe assert() calls are disabled by default? In general the error "... returned a result with an error set" means there's a problem at the C level where a function should have either returned an object or returned NULL with the per-thread exception state set, but it was found to return an object *and* set the exception state. IIRC only debug mode checks for that, so such a bug occasionally creeps into the code. But you shouldn't assume everything is fine until you've tracked down the cause. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 20:23:20 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 27 Jun 2016 00:23:20 +0000 Subject: [issue27173] Modern Unix key bindings for IDLE In-Reply-To: <1464766185.36.0.150155479026.issue27173@psf.upfronthosting.co.za> Message-ID: <1466987000.15.0.667260670787.issue27173@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The change in v4 is the addition of self.AddChangedItem('main', 'Keys', 'name2', '') There is a bug in the get keys function. After applying, when I restart IDLE and go to 'Keys', my custom key set is 'Modern Unix' instead of 'Terry'. It is still 'Terry' on other, unpatched IDLEs. I shelved the patch, restarted, back to 'Terry'. Repeated unshelving and shelving restarts switched each time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 20:26:36 2016 From: report at bugs.python.org (Emanuel Barry) Date: Mon, 27 Jun 2016 00:26:36 +0000 Subject: [issue27394] Crash with compile returning a value with an error set Message-ID: <1466987196.42.0.363723016695.issue27394@psf.upfronthosting.co.za> New submission from Emanuel Barry: My trivial patch exposed a bug in the ast/compiler, where compile() would return a value and set an exception. See http://bugs.python.org/issue27364#msg269323 for more information and steps to reproduce. I looked a bit into it, but I don't know enough about it to be of much help. (This is just a shot in the dark, but maybe compile() doesn't handle warnings-as-errors properly?) ---------- components: Interpreter Core messages: 269328 nosy: benjamin.peterson, brett.cannon, ebarry, georg.brandl, ncoghlan, yselivanov priority: normal severity: normal stage: needs patch status: open title: Crash with compile returning a value with an error set type: crash versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 20:27:00 2016 From: report at bugs.python.org (Emanuel Barry) Date: Mon, 27 Jun 2016 00:27:00 +0000 Subject: [issue27364] Deprecate invalid unicode escape sequences In-Reply-To: <1466541260.02.0.320668077341.issue27364@psf.upfronthosting.co.za> Message-ID: <1466987220.01.0.427075785136.issue27364@psf.upfronthosting.co.za> Emanuel Barry added the comment: Ah right, assert() is only enabled in debug mode, I forgot that. My (very uneducated) guess is that compile() got the error (which was a warning) but then decided to return a value anyway, and the next thing that tries to call anything crashes Python. I opened #27394 to get some experts' advice. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 21:32:11 2016 From: report at bugs.python.org (Pam McA'Nulty) Date: Mon, 27 Jun 2016 01:32:11 +0000 Subject: [issue27395] Increase test coverage of unittest.runner.TextTestResult Message-ID: <1466991131.29.0.133038879004.issue27395@psf.upfronthosting.co.za> New submission from Pam McA'Nulty: While working on another issue, I added a test to increase (low-hanging fruit) test coverage in unittest.runner.TextTestResult ---------- components: Tests files: textresult_coverage.patch keywords: patch messages: 269330 nosy: Pam.McANulty priority: normal severity: normal status: open title: Increase test coverage of unittest.runner.TextTestResult versions: Python 3.6 Added file: http://bugs.python.org/file43551/textresult_coverage.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 21:37:49 2016 From: report at bugs.python.org (Emanuel Barry) Date: Mon, 27 Jun 2016 01:37:49 +0000 Subject: [issue27394] Crash with compile returning a value with an error set In-Reply-To: <1466987196.42.0.363723016695.issue27394@psf.upfronthosting.co.za> Message-ID: <1466991469.58.0.269498704235.issue27394@psf.upfronthosting.co.za> Emanuel Barry added the comment: Nevermind, my mistake. ---------- resolution: -> not a bug stage: needs patch -> resolved status: open -> closed type: crash -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 21:40:30 2016 From: report at bugs.python.org (Emanuel Barry) Date: Mon, 27 Jun 2016 01:40:30 +0000 Subject: [issue27364] Deprecate invalid unicode escape sequences In-Reply-To: <1466541260.02.0.320668077341.issue27364@psf.upfronthosting.co.za> Message-ID: <1466991630.26.0.0713848426151.issue27364@psf.upfronthosting.co.za> Emanuel Barry added the comment: Aaand I feel pretty stupid; I didn't check the return value of PyErr_WarnFormat, so it was my mistake. Attached new patch, actually done right this time. ---------- Added file: http://bugs.python.org/file43552/deprecate_invalid_escapes_only_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 21:42:52 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 27 Jun 2016 01:42:52 +0000 Subject: [issue27364] Deprecate invalid unicode escape sequences In-Reply-To: <1466541260.02.0.320668077341.issue27364@psf.upfronthosting.co.za> Message-ID: <1466991772.33.0.552452819215.issue27364@psf.upfronthosting.co.za> Martin Panter added the comment: Hello Emanual, I think I have fixed your problem with -Werror, by handling the exception returned by PyErr_WarnFormat() (see my patch). Thanks for separating the actual change from the escape violation fixes; it made it easier to spot the real problem :) Also, I like the general idea of the change. It would be good to update the documentation as well (e.g. What?s New, and ). It would be good to do the same for byte string literals, at least to keep things consistent. What did you try so far? Do you have a partial patch for it? ---------- nosy: +martin.panter Added file: http://bugs.python.org/file43553/deprecate_invalid_escapes_only_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 21:43:55 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 27 Jun 2016 01:43:55 +0000 Subject: [issue27364] Deprecate invalid unicode escape sequences In-Reply-To: <1466541260.02.0.320668077341.issue27364@psf.upfronthosting.co.za> Message-ID: <1466991835.48.0.293497735257.issue27364@psf.upfronthosting.co.za> Martin Panter added the comment: Hah, we posted the same fix almost at the same time :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 21:53:54 2016 From: report at bugs.python.org (Emanuel Barry) Date: Mon, 27 Jun 2016 01:53:54 +0000 Subject: [issue27364] Deprecate invalid unicode escape sequences In-Reply-To: <1466541260.02.0.320668077341.issue27364@psf.upfronthosting.co.za> Message-ID: <1466992434.36.0.797558168844.issue27364@psf.upfronthosting.co.za> Emanuel Barry added the comment: Indeed, we did, thanks for letting me know my mistake :) I didn't get very far into making bytes literal disallow invalid sequences, as I ran into issues with _codecs.escape_decode throwing the warning even when the literal was fine, and I think I stopped there and figured I'd at least post that patch and see if people are interested in extending that modification to bytes (turns out so). I forgot about docs, will do so soon, but I'll try to extend the patch for bytes first. I'll see if I can make literals warn but not e.g. _codecs.escape_decode (or anything else, really). Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 21:57:36 2016 From: report at bugs.python.org (Gabriel Hackebeil) Date: Mon, 27 Jun 2016 01:57:36 +0000 Subject: [issue27396] Change default filecmp.cmp shallow option Message-ID: <1466992656.21.0.518759698734.issue27396@psf.upfronthosting.co.za> New submission from Gabriel Hackebeil: I would like to propose changing the default setting for the shallow compare option in filecmp.cmp to False (or providing access an exact comparison function that does not use various performance optimizations). I think many users will turn to this module as a replacement for the ?diff? command on Unix systems, and it is far too easy of a trap to fall into thinking a full comparison takes place when calling filecmp.cmp. I agree that the shallow compare option is a useful feature, but I think it should be something to opt into as it is more of a performance optimization (the same applies to the caching behavior, but that is for another time). I understand that the documentation explains the default behavior, but the reality is that many users probably do not understand the consequences of this setting (or simply did not pay close enough attention to the documentation), making it easy for people to use this module wrong and write code that does not work as advertised. I admit to falling into this trap myself. ---------- components: Library (Lib) messages: 269336 nosy: ghackebeil priority: normal severity: normal status: open title: Change default filecmp.cmp shallow option type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 22:05:26 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 27 Jun 2016 02:05:26 +0000 Subject: [issue27380] IDLE: add base Query dialog with ttk widgets In-Reply-To: <1466741717.27.0.533147933113.issue27380@psf.upfronthosting.co.za> Message-ID: <20160627020523.25486.7041.EE5CCBB3@psf.io> Roundup Robot added the comment: New changeset 4796d7fb00c5 by Terry Jan Reedy in branch 'default': Issue #27380: IDLE: add base Query dialog, with ttk widgets and subclass https://hg.python.org/cpython/rev/4796d7fb00c5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 22:08:06 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 27 Jun 2016 02:08:06 +0000 Subject: [issue27380] IDLE: add base Query dialog with ttk widgets In-Reply-To: <1466741717.27.0.533147933113.issue27380@psf.upfronthosting.co.za> Message-ID: <1466993286.78.0.558456357086.issue27380@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Pushed with minor changes. I decided not to wait until I added more subclasses because file renames with post rename changes do not survive shelving. Reloading from the diff requires 'rediscovering' the renames. ---------- Added file: http://bugs.python.org/file43554/query2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 22:21:28 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 27 Jun 2016 02:21:28 +0000 Subject: [issue22079] Ensure in PyType_Ready() that base class of static type is static In-Reply-To: <1406378199.04.0.952325428414.issue22079@psf.upfronthosting.co.za> Message-ID: <1466994088.19.0.308124940867.issue22079@psf.upfronthosting.co.za> Xiang Zhang added the comment: Oh yes. The mro list can be customized so we can not even guarantee the type appears at index 0 and object at index n-1. It seems we should still keep what it is now, iterating the whole mro list. Sorry that my previous comments seem to be noise. But maybe we can add one comment to clarify that iterating the whole list is needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 22:59:05 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 27 Jun 2016 02:59:05 +0000 Subject: [issue27364] Deprecate invalid unicode escape sequences In-Reply-To: <1466541260.02.0.320668077341.issue27364@psf.upfronthosting.co.za> Message-ID: <1466996345.47.0.397076268923.issue27364@psf.upfronthosting.co.za> Martin Panter added the comment: Code samples in the documentation should also be fixed, like at . I think you can run ?make -C Doc doctest? or something similar, which may help find some of these. Also, playing with your current patch, it seems to affect the ?unicode-escape? codec. Not sure if that is a problem, but it probably deserves also documenting the change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 23:02:12 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 27 Jun 2016 03:02:12 +0000 Subject: [issue27365] Allow non-ascii chars in IDLE NEWS.txt (for contributor names) In-Reply-To: <1466564645.25.0.829598827477.issue27365@psf.upfronthosting.co.za> Message-ID: <20160627030209.3141.80655.0787B0BE@psf.io> Roundup Robot added the comment: New changeset 30e563e2702e by Terry Jan Reedy in branch '3.5': Issue #27365: Allow non-ascii in idlelib/NEWS.txt - minimal part for 3.5.2. https://hg.python.org/cpython/rev/30e563e2702e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 23:02:12 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 27 Jun 2016 03:02:12 +0000 Subject: [issue26867] test_ssl test_options fails on ubuntu 16.04 In-Reply-To: <1461728238.71.0.110276038105.issue26867@psf.upfronthosting.co.za> Message-ID: <20160627030209.3141.90112.219E81C2@psf.io> Roundup Robot added the comment: New changeset 4d04aca4afb0 by Matthias Klose in branch '3.5': Issue #26867: Ubuntu's openssl OP_NO_SSLv3 is forced on by default; fix test. https://hg.python.org/cpython/rev/4d04aca4afb0 New changeset 8f028d04df11 by Matthias Klose in branch '3.4': Issue #26867: Ubuntu's openssl OP_NO_SSLv3 is forced on by default; fix test. https://hg.python.org/cpython/rev/8f028d04df11 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 26 23:02:14 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 27 Jun 2016 03:02:14 +0000 Subject: [issue26930] Upgrade installers to OpenSSL 1.0.2h In-Reply-To: <1462285174.78.0.332365810571.issue26930@psf.upfronthosting.co.za> Message-ID: <20160627030209.3141.28952.F912B21E@psf.io> Roundup Robot added the comment: New changeset e1e5691d02d8 by Zachary Ware in branch '3.5': Issue #26930: Update Windows build to OpenSSL 1.0.2h https://hg.python.org/cpython/rev/e1e5691d02d8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 00:32:24 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 27 Jun 2016 04:32:24 +0000 Subject: [issue23804] SSLSocket.recv(0) receives up to 1024 bytes In-Reply-To: <1427625023.61.0.148010223441.issue23804@psf.upfronthosting.co.za> Message-ID: <1467001944.4.0.332088556747.issue23804@psf.upfronthosting.co.za> Martin Panter added the comment: This was not fixed properly. The first symptom is that recv(0) etc still blocks if the other end sends no data. The second symptom is that it does not work with suppress_ragged_eofs=False. The problem is SSL is still called to do a read, which returns zero, and that seems to be interpreted as some kind of EOF or shutdown indicator. (IMO suppress_ragged_eofs=True is a bad default. It essentially treats a man-in-the-middle shutdown as a genuine secure shutdown, but that would be a separate issue.) ---------- stage: resolved -> patch review status: closed -> open Added file: http://bugs.python.org/file43555/recv-zero.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 00:48:16 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 27 Jun 2016 04:48:16 +0000 Subject: [issue27396] Change default filecmp.cmp shallow option In-Reply-To: <1466992656.21.0.518759698734.issue27396@psf.upfronthosting.co.za> Message-ID: <1467002896.09.0.253405676362.issue27396@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Changing an existing API is painful, especially so for cases like this that have existed for a very, very long time. Such as a change would likely have a detrimental effect on long-standing code relying on the existing behavior. The module itself is all about "comparing files efficiently" and most of its code is about bypassing direct file reads. The original purpose of the module seems to be about providing shallow compares, so your suggested change goes directly against the grain of the module and its original intention of being "fast by default". The docs are very clear about there being trade-offs between correctness and time. If the module were just being released, you might have a good case (in general, the safest options should be the default); however, the time for this decision was a very long time ago. This ship has already sailed. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 00:52:48 2016 From: report at bugs.python.org (Claudiu Saftoiu) Date: Mon, 27 Jun 2016 04:52:48 +0000 Subject: [issue27397] email.message.Message.get_payload(decode=True) raises AssertionError that "should never happen" Message-ID: <1467003168.77.0.181135273122.issue27397@psf.upfronthosting.co.za> New submission from Claudiu Saftoiu: I'm processing Yahoo! Groups backup archives, and came across an email message which causes the `.get_payload(decode=True)` step to raise an AssertionError. Particularly, the following exception is raised in `lib/python3.5/email/_encoded_words.py`, line 124: # This should never happen. raise AssertionError("unexpected binascii.Error") Attached is the file which, when run under Python 3.5.1, causes the exception to be raised. ---------- components: Library (Lib) files: bugreport.py messages: 269346 nosy: Claudiu Saftoiu priority: normal severity: normal status: open title: email.message.Message.get_payload(decode=True) raises AssertionError that "should never happen" type: crash versions: Python 3.5 Added file: http://bugs.python.org/file43556/bugreport.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 00:57:28 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Jun 2016 04:57:28 +0000 Subject: [issue27380] IDLE: add base Query dialog with ttk widgets In-Reply-To: <1466741717.27.0.533147933113.issue27380@psf.upfronthosting.co.za> Message-ID: <1467003448.43.0.764906253589.issue27380@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: You can use True and False instead of TRUE and FALSE. You can import constants with "from tkinter.constants import *". The benefit of using constants instead of string literals is early failing in case of typo. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 00:58:54 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Jun 2016 04:58:54 +0000 Subject: [issue27397] email.message.Message.get_payload(decode=True) raises AssertionError that "should never happen" In-Reply-To: <1467003168.77.0.181135273122.issue27397@psf.upfronthosting.co.za> Message-ID: <1467003534.5.0.150573968552.issue27397@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> r.david.murray nosy: +r.david.murray priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 01:09:46 2016 From: report at bugs.python.org (Claudiu Saftoiu) Date: Mon, 27 Jun 2016 05:09:46 +0000 Subject: [issue27397] email.message.Message.get_payload(decode=True) raises AssertionError that "should never happen" In-Reply-To: <1467003168.77.0.181135273122.issue27397@psf.upfronthosting.co.za> Message-ID: <1467004186.9.0.855732033355.issue27397@psf.upfronthosting.co.za> Claudiu Saftoiu added the comment: See attached another file with more test cases. ---------- Added file: http://bugs.python.org/file43557/bugreport_moretests.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 01:14:16 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Jun 2016 05:14:16 +0000 Subject: [issue27173] Modern Unix key bindings for IDLE In-Reply-To: <1464766185.36.0.150155479026.issue27173@psf.upfronthosting.co.za> Message-ID: <1467004456.91.0.397922900182.issue27173@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I can't reproduce your issue (or understand it correctly). Could you please show the [Keys] section in your config-main.cfg? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 01:20:07 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 27 Jun 2016 05:20:07 +0000 Subject: [issue27255] More opcode predictions In-Reply-To: <1465324904.47.0.783952984943.issue27255@psf.upfronthosting.co.za> Message-ID: <1467004807.75.0.147153455192.issue27255@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The second version of the patch mostly looks fine. The prediction from DUP_TOP_TWO to BINARY_SUBSCR is questionable. Because compile.c only uses it one context, the prediction rate is 100%; however, there is no intrinsic relationship between the two opcodes, so the prediction is happenstance and fragile. Reconsider whether you really want this prediction pairing. ---------- assignee: rhettinger -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 01:24:47 2016 From: report at bugs.python.org (Gabriel Hackebeil) Date: Mon, 27 Jun 2016 05:24:47 +0000 Subject: [issue27396] Change default filecmp.cmp shallow option In-Reply-To: <1467002896.09.0.253405676362.issue27396@psf.upfronthosting.co.za> Message-ID: <952E678C-E6C3-45CB-BE70-BC5BDA47CEB0@gmail.com> Gabriel Hackebeil added the comment: All good points. Perhaps further emphasis on this in the documentation would be helpful to. As it stands, this module is a dangerous one for a naive user (like me) to stumble across. Maybe introducing an ?exact? or ?slow" diff function to the module would help distinguish that behavior from the cmp function. One could then deprecate the shallow keyword for the cmp function. Gabe > On Jun 26, 2016, at 9:48 PM, Raymond Hettinger wrote: > > > Raymond Hettinger added the comment: > > Changing an existing API is painful, especially so for cases like this that have existed for a very, very long time. Such as a change would likely have a detrimental effect on long-standing code relying on the existing behavior. > > The module itself is all about "comparing files efficiently" and most of its code is about bypassing direct file reads. The original purpose of the module seems to be about providing shallow compares, so your suggested change goes directly against the grain of the module and its original intention of being "fast by default". The docs are very clear about there being trade-offs between correctness and time. > > If the module were just being released, you might have a good case (in general, the safest options should be the default); however, the time for this decision was a very long time ago. This ship has already sailed. > > ---------- > nosy: +rhettinger > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 01:54:33 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 27 Jun 2016 05:54:33 +0000 Subject: [issue27396] Change default filecmp.cmp shallow option In-Reply-To: <1466992656.21.0.518759698734.issue27396@psf.upfronthosting.co.za> Message-ID: <1467006873.99.0.827525043852.issue27396@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The docs are already pretty clear. In general, there isn't a defense against a naive use of anything in the computing world. We can write docs but can't make a person read them and realize that their pre-existing mental model is off base. Sorry, but I'm going to close this. The module is doing what it was designed for and what it want documented to do. It has mostly had a successful history and I don't see anything worth churning the API. I think you will just have to chalk this up to experience :-) ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 02:41:43 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 27 Jun 2016 06:41:43 +0000 Subject: [issue19536] MatchObject should offer __getitem__() In-Reply-To: <1384010127.61.0.754728433968.issue19536@psf.upfronthosting.co.za> Message-ID: <1467009703.11.0.713428399866.issue19536@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the detailed report! Issue 24454 is actually a duplicate of this but it has a patch and the idea was discussed by several core developers there. I'm going to close this one. ---------- nosy: +berker.peksag resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> Improve the usability of the match object named group API _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 02:50:35 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 27 Jun 2016 06:50:35 +0000 Subject: [issue27393] Command to activate venv in Windows has wrong path In-Reply-To: <1466962113.91.0.904493080486.issue27393@psf.upfronthosting.co.za> Message-ID: <20160627065032.25345.81420.0D75B6E8@psf.io> Roundup Robot added the comment: New changeset fd1236294b88 by Berker Peksag in branch '3.5': Issue #27393: Fix escaping of venv activate commands on Windows https://hg.python.org/cpython/rev/fd1236294b88 New changeset cf560010e6f8 by Berker Peksag in branch 'default': Issue #27393: Merge from 3.5 https://hg.python.org/cpython/rev/cf560010e6f8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 02:52:35 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 27 Jun 2016 06:52:35 +0000 Subject: [issue27393] Command to activate venv in Windows has wrong path In-Reply-To: <1466962113.91.0.904493080486.issue27393@psf.upfronthosting.co.za> Message-ID: <1467010355.68.0.605458270074.issue27393@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks! 3.3 and 3.4 docs are not maintained anymore. ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed type: enhancement -> behavior versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 03:04:51 2016 From: report at bugs.python.org (David) Date: Mon, 27 Jun 2016 07:04:51 +0000 Subject: [issue27398] configure warning for Python 3.5.2 during compilation Message-ID: <1467011091.26.0.498872044054.issue27398@psf.upfronthosting.co.za> New submission from David: Hi there. 3.5.1 final didn't have this problem, 3.5.2 final does have this problem. I'm compiling Python 3.5.2 under Debian, and get this warning during the ./configure step: --------------- configure: WARNING: linux/random.h: present but cannot be compiled configure: WARNING: linux/random.h: check for missing prerequisite headers? configure: WARNING: linux/random.h: see the Autoconf documentation configure: WARNING: linux/random.h: section "Present But Cannot Be Compiled" configure: WARNING: linux/random.h: proceeding with the compiler's result configure: WARNING: ## -------------------------------------- ## configure: WARNING: ## Report this to http://bugs.python.org/ ## configure: WARNING: ## -------------------------------------- ## --------------- Please check this? ---------- components: Build messages: 269356 nosy: wizzardx priority: normal severity: normal status: open title: configure warning for Python 3.5.2 during compilation versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 03:06:36 2016 From: report at bugs.python.org (David) Date: Mon, 27 Jun 2016 07:06:36 +0000 Subject: [issue27398] configure warning for Python 3.5.2 during compilation In-Reply-To: <1467011091.26.0.498872044054.issue27398@psf.upfronthosting.co.za> Message-ID: <1467011196.88.0.13669748071.issue27398@psf.upfronthosting.co.za> David added the comment: Forgot to mention - this is for Debian 4. A really old legacy system we're running, but where we like to use new versions of Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 03:40:11 2016 From: report at bugs.python.org (INADA Naoki) Date: Mon, 27 Jun 2016 07:40:11 +0000 Subject: [issue27350] Compact and ordered dict In-Reply-To: <1466307796.29.0.980579044792.issue27350@psf.upfronthosting.co.za> Message-ID: <1467013211.93.0.0235901130599.issue27350@psf.upfronthosting.co.za> Changes by INADA Naoki : Added file: http://bugs.python.org/file43558/compact-dict.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 04:20:44 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 27 Jun 2016 08:20:44 +0000 Subject: [issue27364] Deprecate invalid unicode escape sequences In-Reply-To: <1466541260.02.0.320668077341.issue27364@psf.upfronthosting.co.za> Message-ID: <1467015644.06.0.282541787553.issue27364@psf.upfronthosting.co.za> STINNER Victor added the comment: Guido: "I am okay with making it a silent warning." The current patch raises a DeprecationWarning which is silent by default, but seen using python3 -Wd. What is the "long term" plan: always raise an *exception* in Python 3.7? Which exception? Another option is to always emit a SyntaxWarning, but don't raise an exception in long term. It is possible to get an exception using python3 -Werror. There is also FutureWarning: "Base class for warnings about constructs that will change semantically in the future" or RuntimeWarning "Base class for warnings about dubious runtime behavior". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 04:22:57 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 27 Jun 2016 08:22:57 +0000 Subject: [issue22724] byte-compile fails for cross-builds In-Reply-To: <1414194759.57.0.515625475535.issue22724@psf.upfronthosting.co.za> Message-ID: <1467015777.79.0.240906876829.issue22724@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The byte-compiling for cross-builds fails because PYTHON_FOR_BUILD defined in configure, sets PYTHONPATH with the directory of the newly built extension modules shared libraries and because PYTHON_FOR_BUILD is used to run compileall.py in the Makefile. PYTHON_FOR_BUILD, i.e. the native python running on the build system, attempts to load the newly compiled libraries for the foreign host system and fails. The problem is more difficult to reproduce after changeset 11c4f3f936e7 in issue 22980 since the shared libraries names include now a PLATFORM_TRIPLET that prevents the wrong library to be loaded in most cases. On Android cross-builds, it should be possible to reproduce the failure when the build system and the host system have the same PLATFORM_TRIPLET. In all cases, the interpreter used to run compileall.py imports the wrong _sysconfigdata module. To fix this problem, this patch adds the -E option to PYTHON_FOR_BUILD when running compileall in the Makefile and 'cross_compiling' is set. The patch does not fix the fact that, when 'cross_compiling' is not set, PYTHONPATH is set to '$(DESTDIR)$(LIBDEST)' in the Makefile at the beginning of the statement that runs compileall.py while PYTHON_FOR_BUILD is set to './$(BUILDPYTHON) -E', something is obviously wrong here. So the patch would be simpler if '-E' was used in both cases, but I don't know what would be lost by removing this setting of PYTHONPATH at the beginning of those compileall statements, IOW what was their initial purpose. ---------- keywords: +patch nosy: +xdegaye stage: -> patch review versions: -Python 3.3, Python 3.4 Added file: http://bugs.python.org/file43559/python_for_build_flag.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 04:28:25 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 27 Jun 2016 08:28:25 +0000 Subject: [issue23968] rename the platform directory from plat-$(MACHDEP) to plat-$(PLATFORM_TRIPLET) In-Reply-To: <1429124647.47.0.946423694262.issue23968@psf.upfronthosting.co.za> Message-ID: <1467016105.9.0.98890997999.issue23968@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Regeneration of the platdir files needs to be aware of the value of sysroot [1]. For example on Android cross-builds, sysroot must be set to the path of the headers and libraries for the targeted Android API level corresponding to a version of the Android libc and a version of Android. So, automatically regenerating those files in this case requires to look into the CC, CFLAGS and CPPFLAGS environment variables for sysroot. OTOH RTLD_* constants are exposed in the posix module (issue 13226) and the platdir files usefulness is limited now. Cross building from one linux architecture to another is possible with gnu make VPATH support by building outside the source tree. Android is also a linux architecture and building outside the source tree makes sense, not only to work around the problem described in the second item of msg241143, but also to build for different Android API levels and identify the results of those builds. It is not clear that the changes made in this issue fixes correctly issue 22724, see msg269359. I think the scope of this isssue should be restricted to multiarch build systems, i.e. when gcc has been configured with '--enable-multiarch' [2]. [1] Options for Directory Search: https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html [2] Installing GCC: Configuration: https://gcc.gnu.org/install/configure.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 05:07:38 2016 From: report at bugs.python.org (Eryk Sun) Date: Mon, 27 Jun 2016 09:07:38 +0000 Subject: [issue27393] Command to activate venv in Windows has wrong path In-Reply-To: <1466962113.91.0.904493080486.issue27393@psf.upfronthosting.co.za> Message-ID: <1467018458.29.0.560764373005.issue27393@psf.upfronthosting.co.za> Eryk Sun added the comment: You missed "C:\\>". ---------- nosy: +eryksun resolution: fixed -> stage: resolved -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 05:08:40 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 27 Jun 2016 09:08:40 +0000 Subject: [issue23395] _thread.interrupt_main() errors if SIGINT handler in SIG_DFL, SIG_IGN In-Reply-To: <1423093850.42.0.241477195496.issue23395@psf.upfronthosting.co.za> Message-ID: <1467018520.8.0.134558714981.issue23395@psf.upfronthosting.co.za> STINNER Victor added the comment: Attached interrupt_main.patch fixes for _thread.interrupt_main(): raise an exception if the SIGINT signal is ignored (SIG_IGN) or not handled by Python (SIG_DFL). My patch updates the documentation and addds unit tests. issue23395.2.patch looks wrong: it's not the right place to handle the error. ---------- Added file: http://bugs.python.org/file43560/interrupt_main.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 05:12:41 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 27 Jun 2016 09:12:41 +0000 Subject: [issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more In-Reply-To: <1464270042.87.0.0233765451432.issue27130@psf.upfronthosting.co.za> Message-ID: <1467018761.38.0.453054774926.issue27130@psf.upfronthosting.co.za> Xiang Zhang added the comment: This is the v8 patch. It does two things: [1] Apply Martin's comment about decompressobj.decompress so when user passes in PY_SSIZE_T_MAX and there is enough memory, no error will be raised. [2] Now decompressobj.flush can still work even if decompressobj.unconsumed_tail is larger than 4GiB. This needs two changes. First is we don't always use Z_FINISH. Second is we need to change save_unconsumed_input to support 64bit. Before we didn't realize this. Corresponding tests are added. ---------- Added file: http://bugs.python.org/file43561/64bit_support_for_zlib_v8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 05:25:19 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 27 Jun 2016 09:25:19 +0000 Subject: [issue27398] configure warning for Python 3.5.2 during compilation In-Reply-To: <1467011091.26.0.498872044054.issue27398@psf.upfronthosting.co.za> Message-ID: <1467019519.07.0.28399903642.issue27398@psf.upfronthosting.co.za> Martin Panter added the comment: FWIW adding a blank fourth argument in configure.ac silences this warning (and speeds up the configure run by 7%, or 4 s). But I don?t want to become an Autoconf nerd and I don?t know if this change could have negative consequences on other platforms (e.g. perhaps AC_INCLUDES_DEFAULT matters?). Practically, I think you can ignore the warning. The include file is needed to use a new getrandom() syscall on Linux (see Issue 26839), but Python should fall back to older code if it cannot use getrandom(). ---------- keywords: +patch nosy: +martin.panter Added file: http://bugs.python.org/file43562/no-preproc-test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 05:28:36 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 27 Jun 2016 09:28:36 +0000 Subject: [issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more In-Reply-To: <1464270042.87.0.0233765451432.issue27130@psf.upfronthosting.co.za> Message-ID: <1467019716.41.0.109194925679.issue27130@psf.upfronthosting.co.za> Changes by Xiang Zhang : Removed file: http://bugs.python.org/file43561/64bit_support_for_zlib_v8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 05:28:46 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 27 Jun 2016 09:28:46 +0000 Subject: [issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more In-Reply-To: <1464270042.87.0.0233765451432.issue27130@psf.upfronthosting.co.za> Message-ID: <1467019726.3.0.769144564202.issue27130@psf.upfronthosting.co.za> Changes by Xiang Zhang : Added file: http://bugs.python.org/file43563/64bit_support_for_zlib_v8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 06:09:42 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 27 Jun 2016 10:09:42 +0000 Subject: [issue27393] Command to activate venv in Windows has wrong path In-Reply-To: <1466962113.91.0.904493080486.issue27393@psf.upfronthosting.co.za> Message-ID: <20160627100939.52453.43539.21E23EC1@psf.io> Roundup Robot added the comment: New changeset b82149953a8c by Berker Peksag in branch '3.5': Issue #27393: Fix escaping of C:\ too https://hg.python.org/cpython/rev/b82149953a8c New changeset e1a0582896d6 by Berker Peksag in branch 'default': Issue #27393: Merge from 3.5 https://hg.python.org/cpython/rev/e1a0582896d6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 06:12:17 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 27 Jun 2016 10:12:17 +0000 Subject: [issue27393] Command to activate venv in Windows has wrong path In-Reply-To: <1466962113.91.0.904493080486.issue27393@psf.upfronthosting.co.za> Message-ID: <1467022337.04.0.967482597279.issue27393@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks, Eryk. By the way, there is no need to change the state of 'resolution' and 'stage' fields. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 06:17:12 2016 From: report at bugs.python.org (INADA Naoki) Date: Mon, 27 Jun 2016 10:17:12 +0000 Subject: [issue27350] Compact and ordered dict In-Reply-To: <1466307796.29.0.980579044792.issue27350@psf.upfronthosting.co.za> Message-ID: <1467022632.32.0.488575471505.issue27350@psf.upfronthosting.co.za> INADA Naoki added the comment: Last patch I've posted implements "strict ordering rule" on key sharing dict. * Insertion order should be strictly equal to order in shared key. If insertion position is not equal to ma_used, convert it to combined form. * Deleting from split table is prohibited. Convert the table to combined form. (to keep ma_used == next insertion position rule). I ran sphinx-build on this patch and master branch. ("intern" in the result is incomplete implementation of my new idea. Please ignore it in this issue.) https://gist.github.com/methane/df89221222cc2474af1fe61a960e100d Summary ------------- Speed: No regression from master branch. Memory usage: Reduced from 172452k to 160876k ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 07:00:51 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Jun 2016 11:00:51 +0000 Subject: [issue27364] Deprecate invalid unicode escape sequences In-Reply-To: <1466541260.02.0.320668077341.issue27364@psf.upfronthosting.co.za> Message-ID: <1467025251.83.0.565670504698.issue27364@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: DeprecationWarning is used when we want to remove a feature. It becomes an error in the future. FutureWarning is used when we want change the meaning of a feature instead of removing it. For example re.split(':*', 'a:bc') emits a FutureWarning and returns ['a', 'bc'] because there is a plan to make it returning ['', 'a', 'b', 'c', '']. I think "a silent warning" means that it should emit a DeprecationWarning or a PendingDeprecationWarning. Since there is no haste, we should use 2-releases deprecation period. After this a deprecation can be changed to a SynataxWarning in 3.8 and to a UnicodeDecodeError (for strings) and a ValueError (for bytes) in 4.0. The latter are converted to SyntaxError by parser. At the end we should get the same behavior as for truncated \x and \u escapes. >>> '\u' File "", line 1 SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in position 0-1: truncated \uXXXX escape >>> b'\x' File "", line 1 SyntaxError: (value error) invalid \x escape at position 0 Maybe change a parser to convert warnings to a SyntaxWarning? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 07:05:54 2016 From: report at bugs.python.org (INADA Naoki) Date: Mon, 27 Jun 2016 11:05:54 +0000 Subject: [issue27350] Compact and ordered dict In-Reply-To: <1466307796.29.0.980579044792.issue27350@psf.upfronthosting.co.za> Message-ID: <1467025554.14.0.305510522686.issue27350@psf.upfronthosting.co.za> INADA Naoki added the comment: And Python benchmark result is here. https://gist.github.com/methane/e7a2ae389ca13905508905f5fa4ad46c pickup ------- ### call_method_slots ### Min: 0.282221 -> 0.266215: 1.06x faster Avg: 0.282379 -> 0.266448: 1.06x faster Significant (t=780.35) Stddev: 0.00015 -> 0.00032: 2.0993x larger ### call_method_unknown ### Min: 0.280347 -> 0.273366: 1.03x faster Avg: 0.280579 -> 0.273538: 1.03x faster Significant (t=800.73) Stddev: 0.00011 -> 0.00011: 1.0061x smaller ### call_simple ### Min: 0.202884 -> 0.208746: 1.03x slower Avg: 0.203037 -> 0.208866: 1.03x slower Significant (t=-642.05) Stddev: 0.00013 -> 0.00009: 1.3236x smaller ### chameleon_v2 ### Min: 3.715995 -> 3.819750: 1.03x slower Avg: 3.738736 -> 3.851562: 1.03x slower Significant (t=-62.21) Stddev: 0.00851 -> 0.01602: 1.8817x larger ### chaos ### Min: 0.195156 -> 0.203020: 1.04x slower Avg: 0.195803 -> 0.203704: 1.04x slower Significant (t=-179.73) Stddev: 0.00026 -> 0.00035: 1.3371x larger ### django_v3 ### Min: 0.369087 -> 0.386535: 1.05x slower Avg: 0.370569 -> 0.388277: 1.05x slower Significant (t=-184.30) Stddev: 0.00064 -> 0.00072: 1.1206x larger ### formatted_logging ### [97/1823] Min: 0.226584 -> 0.233564: 1.03x slower Avg: 0.229062 -> 0.235876: 1.03x slower Significant (t=-35.32) Stddev: 0.00133 -> 0.00140: 1.0505x larger ### normal_startup ### Min: 0.277946 -> 0.269843: 1.03x faster Avg: 0.279173 -> 0.271878: 1.03x faster Significant (t=17.65) Stddev: 0.00175 -> 0.00374: 2.1348x larger ### raytrace ### Min: 0.961784 -> 0.991375: 1.03x slower Avg: 0.963318 -> 0.994727: 1.03x slower Significant (t=-159.11) Stddev: 0.00073 -> 0.00183: 2.5204x larger ### regex_compile ### Min: 0.256675 -> 0.267169: 1.04x slower Avg: 0.257559 -> 0.268213: 1.04x slower Significant (t=-136.14) Stddev: 0.00050 -> 0.00060: 1.1996x larger ### richards ### Min: 0.129063 -> 0.134478: 1.04x slower Avg: 0.130158 -> 0.135382: 1.04x slower Significant (t=-18.28) Stddev: 0.00284 -> 0.00036: 7.8299x smaller ### startup_nosite ### Min: 0.165788 -> 0.159139: 1.04x faster Avg: 0.166089 -> 0.159848: 1.04x faster Significant (t=219.05) Stddev: 0.00021 -> 0.00035: 1.6594x larger ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 07:07:45 2016 From: report at bugs.python.org (Zahari Dim) Date: Mon, 27 Jun 2016 11:07:45 +0000 Subject: [issue27399] ChainMap.keys() is broken Message-ID: <1467025665.28.0.0299580646489.issue27399@psf.upfronthosting.co.za> New submission from Zahari Dim: When trying to see if the keys() of a collections.ChainMap object are empty, it tries to compute the hash of the dicts that compose the ChainMap, giving rise to an error: In [1]: from collections import ChainMap In [2]: m = ChainMap([{'a':1}, {'b':2}]) In [3]: bool(m.keys()) --------------------------------------------------------------------------- TypeError Traceback (most recent call last) in () ----> 1 bool(m.keys()) /home/zah/anaconda3/lib/python3.5/_collections_abc.py in __len__(self) 633 634 def __len__(self): --> 635 return len(self._mapping) 636 637 def __repr__(self): /home/zah/anaconda3/lib/python3.5/collections/__init__.py in __len__(self) 865 866 def __len__(self): --> 867 return len(set().union(*self.maps)) # reuses stored hash values if possible 868 869 def __iter__(self): TypeError: unhashable type: 'dict' Also, I can't ask if 'a' is in keys: In [6]: m.keys() Out[6]: KeysView(ChainMap([{'a': 1}, {'b': 2}])) In [9]: ks = m.keys() In [17]: 'a' in ks Out[17]: False ---------- components: Library (Lib) messages: 269370 nosy: Zahari.Dim priority: normal severity: normal status: open title: ChainMap.keys() is broken versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 07:10:01 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 27 Jun 2016 11:10:01 +0000 Subject: [issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more In-Reply-To: <1464270042.87.0.0233765451432.issue27130@psf.upfronthosting.co.za> Message-ID: <1467025801.65.0.386212606125.issue27130@psf.upfronthosting.co.za> Changes by Xiang Zhang : Removed file: http://bugs.python.org/file43563/64bit_support_for_zlib_v8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 07:10:29 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 27 Jun 2016 11:10:29 +0000 Subject: [issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more In-Reply-To: <1464270042.87.0.0233765451432.issue27130@psf.upfronthosting.co.za> Message-ID: <1467025829.63.0.532975473405.issue27130@psf.upfronthosting.co.za> Xiang Zhang added the comment: Make v8 patch consistent with the latest changeset. ---------- Added file: http://bugs.python.org/file43564/64bit_support_for_zlib_v8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 07:12:40 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 27 Jun 2016 11:12:40 +0000 Subject: [issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more In-Reply-To: <1464270042.87.0.0233765451432.issue27130@psf.upfronthosting.co.za> Message-ID: <1467025960.56.0.702319679206.issue27130@psf.upfronthosting.co.za> Changes by Xiang Zhang : Removed file: http://bugs.python.org/file43564/64bit_support_for_zlib_v8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 07:12:49 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 27 Jun 2016 11:12:49 +0000 Subject: [issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more In-Reply-To: <1464270042.87.0.0233765451432.issue27130@psf.upfronthosting.co.za> Message-ID: <1467025969.0.0.323567992672.issue27130@psf.upfronthosting.co.za> Changes by Xiang Zhang : Added file: http://bugs.python.org/file43565/64bit_support_for_zlib_v8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 07:13:00 2016 From: report at bugs.python.org (Zahari Dim) Date: Mon, 27 Jun 2016 11:13:00 +0000 Subject: [issue27399] ChainMap.keys() is broken In-Reply-To: <1467025665.28.0.0299580646489.issue27399@psf.upfronthosting.co.za> Message-ID: <1467025980.26.0.213917255129.issue27399@psf.upfronthosting.co.za> Changes by Zahari Dim : ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 07:30:10 2016 From: report at bugs.python.org (Emanuel Barry) Date: Mon, 27 Jun 2016 11:30:10 +0000 Subject: [issue27364] Deprecate invalid unicode escape sequences In-Reply-To: <1466541260.02.0.320668077341.issue27364@psf.upfronthosting.co.za> Message-ID: <1467027010.6.0.830111884742.issue27364@psf.upfronthosting.co.za> Emanuel Barry added the comment: I think ultimately a SyntaxError should be fine. I don't know *when* it becomes appropriate to change a warning into an error; I was thinking 3.7 but, as Serhiy said, there's no rush. I think waiting five release cycles is overkill though, that means the error won't be until 8 years from now (assuming release cycle periods don't change)! I think at most 3.8 should be fine for making this a full-on syntax error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 08:45:51 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 27 Jun 2016 12:45:51 +0000 Subject: [issue27364] Deprecate invalid unicode escape sequences In-Reply-To: <1466541260.02.0.320668077341.issue27364@psf.upfronthosting.co.za> Message-ID: <1467031551.57.0.0216261975904.issue27364@psf.upfronthosting.co.za> STINNER Victor added the comment: @ebarry: To move faster, you should also worker with linters (pylint, pychecker, pyflakes, pycodestyle, flake8, ...) to log a warning to help projects to be prepared this change. linters are used on Python 2-only projects, so it will help them to be prepared to the final Python 3. which will raise an exception. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 09:02:00 2016 From: report at bugs.python.org (Denny Weinberg) Date: Mon, 27 Jun 2016 13:02:00 +0000 Subject: [issue17408] second python execution fails when embedding In-Reply-To: <1363183794.27.0.643296851621.issue17408@psf.upfronthosting.co.za> Message-ID: <1467032520.72.0.561060812152.issue17408@psf.upfronthosting.co.za> Denny Weinberg added the comment: Can we please reopen this issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 09:20:06 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 27 Jun 2016 13:20:06 +0000 Subject: [issue27397] email.message.Message.get_payload(decode=True) raises AssertionError that "should never happen" In-Reply-To: <1467003168.77.0.181135273122.issue27397@psf.upfronthosting.co.za> Message-ID: <1467033606.13.0.0315129173085.issue27397@psf.upfronthosting.co.za> R. David Murray added the comment: This appears to be a bug in b64decode. It should not be raising that error if validate=False, as it is in the code being executed during the test case. It's not that b64decode is ignoring the validate argument; the error appears to be data-dependent. I don't have time to investigate this further at the moment, perhaps someone else can pick it up. ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 09:28:36 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 27 Jun 2016 13:28:36 +0000 Subject: [issue27364] Deprecate invalid unicode escape sequences In-Reply-To: <1466541260.02.0.320668077341.issue27364@psf.upfronthosting.co.za> Message-ID: <1467034116.35.0.41360797797.issue27364@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, this change is likely to break a lot of code, so an extended deprecation period (certainly longer than 3.7, which Guido has already mandated) is the minimum). Guido hasn't agreed to making it an error yet, as far as I can see ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 09:30:35 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 27 Jun 2016 13:30:35 +0000 Subject: [issue27399] ChainMap.keys() is broken In-Reply-To: <1467025665.28.0.0299580646489.issue27399@psf.upfronthosting.co.za> Message-ID: <1467034235.47.0.8087675.issue27399@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 09:37:22 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 27 Jun 2016 13:37:22 +0000 Subject: [issue17408] second python execution fails when embedding In-Reply-To: <1363183794.27.0.643296851621.issue17408@psf.upfronthosting.co.za> Message-ID: <1467034642.14.0.674761270125.issue17408@psf.upfronthosting.co.za> Berker Peksag added the comment: We don't re-open old issues (this was closed more than 3 years ago). Please open a new issue and provide a minimal reproducer. Thanks! ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 09:41:20 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 27 Jun 2016 13:41:20 +0000 Subject: [issue17408] second python execution fails when embedding In-Reply-To: <1363183794.27.0.643296851621.issue17408@psf.upfronthosting.co.za> Message-ID: <1467034880.44.0.290627836357.issue17408@psf.upfronthosting.co.za> R. David Murray added the comment: The interpreter is not crashing in your case, so this is a mostly-unrelated problem. (The part that is related is that it is triggered by module finalization.) As Berker said, please open a new issue, but be warned that it may get closed as a being addressed by the issue for rewriting the python startup sequence (pep 432 I think, which I think Nick has resurrected), since this is a systemic problem. On the other hand there might be a way to fix it in the datetime module if someone decides it is worth doing. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 09:49:18 2016 From: report at bugs.python.org (Denny Weinberg) Date: Mon, 27 Jun 2016 13:49:18 +0000 Subject: [issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize Message-ID: <1467035358.55.0.678180807375.issue27400@psf.upfronthosting.co.za> New submission from Denny Weinberg: After calling Py_Finalize and Py_Initialize I get the message "attribute of type 'NoneType' is not callable" on the datetime.strptime method. Example: from datetime import datetime s = '20160505 160000' refdatim = datetime.strptime(s, '%Y%m%d %H%M%S') The first call works fine but it crashes after the re initialization. Workaround: from datetime import datetime s = '20160505 160000' try: refdatim = datetime.strptime(s, '%Y%m%d %H%M%S') except TypeError: import time refdatim = datetime.fromtimestamp(time.mktime(time.strptime(s, '%Y%m%d %H%M%S'))) Related Issue: Issue17408 ("second python execution fails when embedding") ---------- components: Interpreter Core messages: 269379 nosy: Denny Weinberg, palm.kevin priority: normal severity: normal status: open title: Datetime NoneType after calling Py_Finalize and Py_Initialize type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 09:50:43 2016 From: report at bugs.python.org (Denny Weinberg) Date: Mon, 27 Jun 2016 13:50:43 +0000 Subject: [issue17408] second python execution fails when embedding In-Reply-To: <1363183794.27.0.643296851621.issue17408@psf.upfronthosting.co.za> Message-ID: <1467035443.84.0.114964493716.issue17408@psf.upfronthosting.co.za> Denny Weinberg added the comment: Ok, thank you very much for your comments. See Issue27400 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 10:10:52 2016 From: report at bugs.python.org (Denny Weinberg) Date: Mon, 27 Jun 2016 14:10:52 +0000 Subject: [issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize In-Reply-To: <1467035358.55.0.678180807375.issue27400@psf.upfronthosting.co.za> Message-ID: <1467036652.53.0.0777038123006.issue27400@psf.upfronthosting.co.za> Denny Weinberg added the comment: Just to be clear: The error happens after these steps: 1. Call strptime 2. Call cpython function "Py_Finalize" and "Py_Initialize" 3. Call strptime again Now we get the error "attribute of type 'NoneType' is not callable" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 11:00:28 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 27 Jun 2016 15:00:28 +0000 Subject: [issue27364] Deprecate invalid unicode escape sequences In-Reply-To: <1467034116.35.0.41360797797.issue27364@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I think ultimately it has to become an error (otherwise I wouldn't have agreed to the warning, silent or not). But because there's so much 3rd party code that depends on it we indeed need to take "several" releases before we go there. Contacting the PyCQA folks would also be a great idea -- can anyone volunteer to do so? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 11:57:10 2016 From: report at bugs.python.org (Jarod Brennfleck) Date: Mon, 27 Jun 2016 15:57:10 +0000 Subject: [issue27401] Wrong FTP links in 5.3.2 installer Message-ID: <1467043030.62.0.960428099704.issue27401@psf.upfronthosting.co.za> New submission from Jarod Brennfleck: So far, the only installers tested is the Python 5.3.2 x86 and x86_64 installers. When selecting customise install, the installer is unable to gather the files required, because the installer is looking for them in: https://www.python.org/ftp/python/3.5.2/amd64/ Following the link will result in a 404, as the folder does not exist. This reason has been found thanks to the log file of the installation that is given upon error during the installation. (Cheers for that! :D) The correct link is: https://www.python.org/ftp/python/3.5.2/amd64rc1/ ---------- components: Installation messages: 269383 nosy: Jarod Brennfleck priority: normal severity: normal status: open title: Wrong FTP links in 5.3.2 installer type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 11:59:16 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 27 Jun 2016 15:59:16 +0000 Subject: [issue27401] Wrong FTP links in 5.3.2 installer In-Reply-To: <1467043030.62.0.960428099704.issue27401@psf.upfronthosting.co.za> Message-ID: <1467043156.89.0.33769381444.issue27401@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 11:59:22 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 27 Jun 2016 15:59:22 +0000 Subject: [issue27255] More opcode predictions In-Reply-To: <1465324904.47.0.783952984943.issue27255@psf.upfronthosting.co.za> Message-ID: <20160627155916.15856.45136.F1FED82A@psf.io> Roundup Robot added the comment: New changeset f19c2b28710e by Serhiy Storchaka in branch 'default': Issue #27255: Added more predictions in ceval.c. https://hg.python.org/cpython/rev/f19c2b28710e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 12:33:17 2016 From: report at bugs.python.org (Brett Cannon) Date: Mon, 27 Jun 2016 16:33:17 +0000 Subject: [issue27352] Bug in IMPORT_NAME In-Reply-To: <1466337192.83.0.569731150376.issue27352@psf.upfronthosting.co.za> Message-ID: <1467045197.82.0.107590585786.issue27352@psf.upfronthosting.co.za> Brett Cannon added the comment: LGTM ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 12:33:41 2016 From: report at bugs.python.org (Brett Cannon) Date: Mon, 27 Jun 2016 16:33:41 +0000 Subject: [issue27387] Thread hangs on str.encode() when locale is not set In-Reply-To: <1466892219.46.0.416121805197.issue27387@psf.upfronthosting.co.za> Message-ID: <1467045221.68.0.297559326706.issue27387@psf.upfronthosting.co.za> Brett Cannon added the comment: Adding a note to the docs sounds reasonable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 12:41:45 2016 From: report at bugs.python.org (Zachary Ware) Date: Mon, 27 Jun 2016 16:41:45 +0000 Subject: [issue27401] Wrong FTP links in 3.5.2 installer In-Reply-To: <1467043030.62.0.960428099704.issue27401@psf.upfronthosting.co.za> Message-ID: <1467045705.01.0.13829318934.issue27401@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- assignee: -> steve.dower components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware priority: normal -> high title: Wrong FTP links in 5.3.2 installer -> Wrong FTP links in 3.5.2 installer type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 12:50:39 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 27 Jun 2016 16:50:39 +0000 Subject: [issue27387] Thread hangs on str.encode() when locale is not set In-Reply-To: <1467045221.68.0.297559326706.issue27387@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > Maybe it is worth adding a warning to that section of the 2.7 docs about implicit imports in general and encode/decode in particular? Ok to add a note to str.encode and str.decode methods to explain that an import is needed the first time that an encoding is used. I'm not ok for a warning, we should not discourage developers to use these methods! They are not dangerous by themself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 13:02:24 2016 From: report at bugs.python.org (Emanuel Barry) Date: Mon, 27 Jun 2016 17:02:24 +0000 Subject: [issue27364] Deprecate invalid unicode escape sequences In-Reply-To: <1466541260.02.0.320668077341.issue27364@psf.upfronthosting.co.za> Message-ID: <1467046944.47.0.503188455193.issue27364@psf.upfronthosting.co.za> Emanuel Barry added the comment: Easing transition is always a good idea. I'll contact the PyCQA people later today when I'm back home. On afterthought, it makes sense to wait more than two release cycles before making this an error. I don't really have a strong opinion when exactly that should happen. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 13:09:40 2016 From: report at bugs.python.org (Michael Lee) Date: Mon, 27 Jun 2016 17:09:40 +0000 Subject: [issue27402] Sequence example in typing module documentation does not typecheck Message-ID: <1467047380.43.0.562730585486.issue27402@psf.upfronthosting.co.za> New submission from Michael Lee: In the documentation for the `typing` module, the [entry for the `List` type][0] uses the following example to help demonstrate when to use `Sequence` vs `List`: T = TypeVar('T', int, float) def vec2(x: T, y: T) -> List[T]: return [x, y] def slice__to_4(vector: Sequence[T]) -> List[T]: return vector[0:4] However, the `slice__to_4` function does not actually typecheck since there's no guarantee that a slice of a sequence will return a `List`. For example the vector could be a numpy array or a custom subclass of `collections.abc.Sequence` with an unusual `__getitem__`. (Mypy correctly catches this error and complains about an "Incompatible return value type"). The documentation should probably be updated to use an example that _does_ typecheck, though I'm not sure what exactly that example might look like? Maybe replace `slice__to_4` with something like this? def keep_positives(vector: Sequence[T]) -> List[T]: return [item for item in vector if item > 0] ---------- assignee: docs at python components: Documentation messages: 269389 nosy: docs at python, michael0x2a priority: normal severity: normal status: open title: Sequence example in typing module documentation does not typecheck versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 13:12:11 2016 From: report at bugs.python.org (Michael Lee) Date: Mon, 27 Jun 2016 17:12:11 +0000 Subject: [issue27402] Sequence example in typing module documentation does not typecheck In-Reply-To: <1467047380.43.0.562730585486.issue27402@psf.upfronthosting.co.za> Message-ID: <1467047531.67.0.579606064746.issue27402@psf.upfronthosting.co.za> Michael Lee added the comment: Whoops, forgot the link to the error in the docs: https://docs.python.org/3/library/typing.html#typing.List ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 14:14:51 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Jun 2016 18:14:51 +0000 Subject: [issue27255] More opcode predictions In-Reply-To: <1465324904.47.0.783952984943.issue27255@psf.upfronthosting.co.za> Message-ID: <1467051291.26.0.720651957908.issue27255@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Raymond. Committed without the prediction from DUP_TOP_TWO to BINARY_SUBSCR. What are you think about following highly predictive pairs? 1. From UNPACK_SEQUENCE to STORE_FAST with 96.5% probability. This is the 15th of most common pairs. It is more common than any other predicted pairs except the COMPARE_OP/POP_JUMP_IF_FALSE pair. I suppose it is mostly used in for loops over dict.items(), enumerate(), etc. I suppose the remaining 3.5% are unpacking to object attributes (like "self.x, self.y = ..."). 2. From BUILD_SLICE to BINARY_SUBSCR with 99.3% probability. This is the 37th of most common pairs. It is more common than any other predicted pairs except the three most common pairs. The remaining 0.7% are slice assignment (0.42%), slice deleting (0.29%), slice inplace operations and extended slices. FYI here is a list of most common pairs (predicted pairs are starred). 1. 5.84% LOAD_FAST LOAD_FAST 22.6% 2. 5.16% LOAD_FAST LOAD_ATTR 20.0% 3. 4.18% COMPARE_OP POP_JUMP_IF_FALSE 82.9% * 4. 3.97% POP_JUMP_IF_FALSE LOAD_FAST 66.3% 5. 3.90% STORE_FAST LOAD_FAST 47.2% 6. 3.70% LOAD_FAST CALL_FUNCTION 14.3% 7. 3.36% LOAD_FAST LOAD_CONST 13.0% 8. 2.64% LOAD_ATTR LOAD_FAST 35.2% 9. 2.28% LOAD_CONST COMPARE_OP 26.7% 10. 2.12% STORE_FAST STORE_FAST 25.6% 11. 2.09% LOAD_GLOBAL LOAD_FAST 37.5% 12. 1.49% CALL_FUNCTION STORE_FAST 20.5% 13. 1.44% <0> LOAD_FAST 39.1% 14. 1.37% JUMP_ABSOLUTE FOR_ITER 77.6% 15. 1.29% UNPACK_SEQUENCE STORE_FAST 96.5% 16. 1.28% CALL_FUNCTION POP_TOP 17.7% 17. 1.28% LOAD_FAST LOAD_GLOBAL 4.9% 18. 1.26% FOR_ITER STORE_FAST 50.3% * 19. 1.25% LOAD_CONST RETURN_VALUE 14.6% 20. 1.19% LOAD_ATTR LOAD_CONST 15.9% ... 36. 0.65% COMPARE_OP POP_JUMP_IF_TRUE 13.0% * 37. 0.65% BUILD_SLICE BINARY_SUBSCR 99.3% ... 45. 0.55% SETUP_LOOP LOAD_FAST 80.7% 46. 0.55% GET_ITER FOR_ITER 71.9% * 47. 0.53% FOR_ITER UNPACK_SEQUENCE 21.2% * ... 50. 0.50% FOR_ITER POP_BLOCK 20.0% * ... 66. 0.33% ROT_TWO STORE_FAST 85.8% ... 71. 0.31% INPLACE_ADD STORE_FAST 92.1% ... 73. 0.30% LIST_APPEND JUMP_ABSOLUTE 100.0% * ... 90. 0.22% BUILD_MAP STORE_FAST 85.3% ... 93. 0.21% GET_ITER CALL_FUNCTION 28.1% * ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 14:21:39 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 27 Jun 2016 18:21:39 +0000 Subject: [issue27387] Thread hangs on str.encode() when locale is not set In-Reply-To: <1466892219.46.0.416121805197.issue27387@psf.upfronthosting.co.za> Message-ID: <1467051699.31.0.490070238931.issue27387@psf.upfronthosting.co.za> R. David Murray added the comment: No, I'm talking about the threading docs, not the encoding docs. I think that's the only place it matters. Specifically, in the section that I linked to, in the bullet point that warns against launching threads on import, it can note that even if you try to make your own code avoid the import lock, implicit imports such as the one done by encode/decode can trip you up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 14:31:17 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 27 Jun 2016 18:31:17 +0000 Subject: [issue27401] Wrong FTP links in 3.5.2 installer In-Reply-To: <1467043030.62.0.960428099704.issue27401@psf.upfronthosting.co.za> Message-ID: <1467052277.74.0.770670370385.issue27401@psf.upfronthosting.co.za> Steve Dower added the comment: Actually, the correct link is amd64/, but it didn't upload on my second try, apparently. Or somehow disappeared... Fixing that now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 14:39:38 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 27 Jun 2016 18:39:38 +0000 Subject: [issue27352] Bug in IMPORT_NAME In-Reply-To: <1466337192.83.0.569731150376.issue27352@psf.upfronthosting.co.za> Message-ID: <20160627183935.3717.78395.1AF00102@psf.io> Roundup Robot added the comment: New changeset e3164c9edb0b by Serhiy Storchaka in branch 'default': Issue #27352: Correct the validation of the ImportFrom AST node and simplify https://hg.python.org/cpython/rev/e3164c9edb0b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 14:40:51 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Jun 2016 18:40:51 +0000 Subject: [issue27352] Bug in IMPORT_NAME In-Reply-To: <1466337192.83.0.569731150376.issue27352@psf.upfronthosting.co.za> Message-ID: <1467052851.33.0.932738017076.issue27352@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Brett. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 14:47:46 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 27 Jun 2016 18:47:46 +0000 Subject: [issue27401] Wrong FTP links in 3.5.2 installer In-Reply-To: <1467043030.62.0.960428099704.issue27401@psf.upfronthosting.co.za> Message-ID: <1467053266.68.0.551733752772.issue27401@psf.upfronthosting.co.za> Steve Dower added the comment: Should be good now. Thanks for the heads-up! ---------- resolution: -> fixed stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 14:53:09 2016 From: report at bugs.python.org (Zachary Ware) Date: Mon, 27 Jun 2016 18:53:09 +0000 Subject: [issue27401] Wrong FTP links in 3.5.2 installer In-Reply-To: <1467043030.62.0.960428099704.issue27401@psf.upfronthosting.co.za> Message-ID: <1467053589.62.0.555824316434.issue27401@psf.upfronthosting.co.za> Zachary Ware added the comment: I'm still getting 404s; I'm not sure if there's cache to be purged or something, but I can't see that the ...amd64/ dir exists yet, at least from a browser. I haven't tried an actual installation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 15:36:41 2016 From: report at bugs.python.org (Larry Hastings) Date: Mon, 27 Jun 2016 19:36:41 +0000 Subject: [issue27401] Wrong FTP links in 3.5.2 installer In-Reply-To: <1467043030.62.0.960428099704.issue27401@psf.upfronthosting.co.za> Message-ID: <1467056201.5.0.422693203082.issue27401@psf.upfronthosting.co.za> Larry Hastings added the comment: I can independently confirm that the "amd64" directory is in the proper place, and all relevant files & directories look like they have the correct permissions. I did that by logging in to the appropriate server and nosing around. Also, the web link works fine too, for me: https://www.python.org/ftp/python/3.5.2/amd64/ If I click on that I see all the various msi and msu files. LGTM ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 15:38:32 2016 From: report at bugs.python.org (Zachary Ware) Date: Mon, 27 Jun 2016 19:38:32 +0000 Subject: [issue27401] Wrong FTP links in 3.5.2 installer In-Reply-To: <1467043030.62.0.960428099704.issue27401@psf.upfronthosting.co.za> Message-ID: <1467056312.12.0.353157320827.issue27401@psf.upfronthosting.co.za> Zachary Ware added the comment: Yep, looks fine now. I suspect from a couple of commits that Steve just did he did in fact have to purge cache :) Thanks, Steve! ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 16:13:27 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Jun 2016 20:13:27 +0000 Subject: [issue22557] Local import is too slow In-Reply-To: <1412512141.77.0.0512115045124.issue22557@psf.upfronthosting.co.za> Message-ID: <1467058407.02.0.546993545467.issue22557@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file43566/faster_import_5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 16:18:57 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Jun 2016 20:18:57 +0000 Subject: [issue22557] Local import is too slow In-Reply-To: <1412512141.77.0.0512115045124.issue22557@psf.upfronthosting.co.za> Message-ID: <1467058737.93.0.292269459227.issue22557@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: faster_import_pkg.patch optimizes also an import of names with dots. $ ./python -m timeit 'import os.path' Unpatched: 100000 loops, best of 3: 2.08 usec per loop faster_import_5.patch: 1000000 loops, best of 3: 1.79 usec per loop faster_import_pkg.patch: 1000000 loops, best of 3: 0.474 usec per loop ---------- Added file: http://bugs.python.org/file43567/faster_import_pkg.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 16:33:04 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 27 Jun 2016 20:33:04 +0000 Subject: [issue27352] Bug in IMPORT_NAME In-Reply-To: <1466337192.83.0.569731150376.issue27352@psf.upfronthosting.co.za> Message-ID: <1467059584.94.0.90299611086.issue27352@psf.upfronthosting.co.za> STINNER Victor added the comment: You broke Python! Example: http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/4853/steps/test/logs/stdio ====================================================================== FAIL: test_importfrom (test.test_ast.ASTValidatorTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_ast.py", line 757, in test_importfrom self.stmt(imp, "level less than -1") File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_ast.py", line 579, in stmt self.mod(mod, msg) File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_ast.py", line 571, in mod self.assertIn(msg, str(cm.exception)) AssertionError: 'level less than -1' not found in 'Negative ImportFrom level' ---------- nosy: +haypo resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 16:41:03 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 27 Jun 2016 20:41:03 +0000 Subject: [issue27352] Bug in IMPORT_NAME In-Reply-To: <1466337192.83.0.569731150376.issue27352@psf.upfronthosting.co.za> Message-ID: <20160627204059.15809.79074.BEF7C020@psf.io> Roundup Robot added the comment: New changeset e5063a82f490 by Serhiy Storchaka in branch 'default': Issue #27352: Fixed an error message in a test. https://hg.python.org/cpython/rev/e5063a82f490 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 16:54:17 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Jun 2016 20:54:17 +0000 Subject: [issue27352] Bug in IMPORT_NAME In-Reply-To: <1466337192.83.0.569731150376.issue27352@psf.upfronthosting.co.za> Message-ID: <1467060857.55.0.772468757127.issue27352@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Victor! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 17:03:41 2016 From: report at bugs.python.org (Dustin Oprea) Date: Mon, 27 Jun 2016 21:03:41 +0000 Subject: [issue27403] os.path.dirname doesn't handle Windows' URNs correctly Message-ID: <1467061421.97.0.269034608873.issue27403@psf.upfronthosting.co.za> New submission from Dustin Oprea: Notice that os.path.dirname() returns whatever it is given if it is given a URN, regardless of slash-type. Oddly, you have to double-up the forward-slashes (like you're escaping them) in order to get the correct result (if you're using forward-slashes). Back-slashes appear to be broken no matter what. C:\Python35-32>python Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:01:18) [MSC v.1900 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os.path >>> os.path.dirname("\\\\a\\b") '\\\\a\\b' >>> os.path.dirname("//a/b") '//a/b' >>> os.path.dirname("////a//b") '////a' Any ideas? ---------- components: Windows messages: 269404 nosy: Dustin.Oprea, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: os.path.dirname doesn't handle Windows' URNs correctly type: behavior versions: Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 17:14:37 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 27 Jun 2016 21:14:37 +0000 Subject: [issue27404] Misc/NEWS: add [Security] prefix to Python 3.5.2 changelog Message-ID: <1467062077.67.0.144801873004.issue27404@psf.upfronthosting.co.za> New submission from STINNER Victor: As discussed on the Security-SIG mailing list, changes related to security should be prefixed by [Security]: https://mail.python.org/pipermail/security-sig/2016-June/000003.html Here is a first patch for Python 3.5.2 (and the future 3.5.3) changelog. ---------- files: NEWS.patch keywords: patch messages: 269405 nosy: haypo priority: normal severity: normal status: open title: Misc/NEWS: add [Security] prefix to Python 3.5.2 changelog type: security versions: Python 3.5 Added file: http://bugs.python.org/file43568/NEWS.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 18:08:52 2016 From: report at bugs.python.org (Eryk Sun) Date: Mon, 27 Jun 2016 22:08:52 +0000 Subject: [issue27403] os.path.dirname doesn't handle Windows' URNs correctly In-Reply-To: <1467061421.97.0.269034608873.issue27403@psf.upfronthosting.co.za> Message-ID: <1467065332.7.0.970117579402.issue27403@psf.upfronthosting.co.za> Eryk Sun added the comment: dirname() is implemented via split(), which begins by calling splitdrive(). The 'drive' for a UNC path is the r"\\server\share" component. For example: >>> path = r'\\server\share\folder\file' >>> os.path.splitdrive(path) ('\\\\server\\share', '\\folder\\file') >>> os.path.split(path) ('\\\\server\\share\\folder', 'file') >>> os.path.dirname(path) '\\\\server\\share\\folder' If you double the initial slashes, it's no longer a valid UNC path: >>> path = r'\\\\server\\share\\folder\\file' >>> os.path.splitdrive(path) ('', '\\\\\\\\server\\\\share\\\\folder\\\\file') >>> os.path.split(path) ('\\\\\\\\server\\\\share\\\\folder', 'file') >>> os.path.dirname(path) '\\\\\\\\server\\\\share\\\\folder' Windows itself will attempt to handle it as a UNC path, but the path is invalid. Specifically, before passing the path to the kernel, Windows collapses all of the extra slashes, except an initial slash count greater than two always leaves an extra slash in the path. For example: >>> open(r'\\\\server\\share\\folder\\file') Breakpoint 0 hit ntdll!NtCreateFile: 00007ffb`a1f25b70 4c8bd1 mov r10,rcx 0:000> !obja @r8 Obja +00000049781ef160 at 00000049781ef160: Name is \??\UNC\\server\share\folder\file OBJ_CASE_INSENSITIVE Notice the extra backlash in "UNC\\server". Thus a valid UNC path must start with exactly two slashes. Using forward slash is generally fine. The Windows API substitutes backslash for slash before passing a path to the kernel. For example: >>> open(r'//server/share/folder/file') Breakpoint 0 hit ntdll!NtCreateFile: 00007ffb`a1f25b70 4c8bd1 mov r10,rcx 0:000> !obja @r8 Obja +00000049781ef160 at 00000049781ef160: Name is \??\UNC\server\share\folder\file OBJ_CASE_INSENSITIVE Except you can't use forward slash with a "\\?\" path, which bypasses normal path processing. For example: >>> open(r'\\?\UNC/server/share/folder/file') Breakpoint 0 hit ntdll!NtCreateFile: 00007ffb`a1f25b70 4c8bd1 mov r10,rcx 0:000> !obja @r8 Obja +00000049781ef160 at 00000049781ef160: Name is \??\UNC/server/share/folder/file OBJ_CASE_INSENSITIVE In the kernel '/' isn't a path separator. It's just another name character, so this (potentially) looks for a server named "/server/share/folder/file". Microsoft file systems forbid using slash in names (for POSIX compatibility and to avoid needless confusion), but you can use slash in the name of kernel objects such as Event objects, or even in the name of DOS devices defined via DefineDosDevice. ---------- nosy: +eryksun resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 18:14:23 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 27 Jun 2016 22:14:23 +0000 Subject: [issue27173] Modern Unix key bindings for IDLE In-Reply-To: <1464766185.36.0.150155479026.issue27173@psf.upfronthosting.co.za> Message-ID: <1467065663.31.0.638801679905.issue27173@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I rebooted and reran build in case this was another funny heisenbug. It isn't. Before patch, start 3.6 repository IDLE. Click Options, Configure IDLE, and Keys tab. Look at 'Use a Custom Key Set'. It says 'Terry', which is correct. After patch: repeat. It says 'IDLE Modern Unix'. Custom Key Binding box reflects change. Repeat with 3.5 repository IDLE: it still says Terry. Ditto for installed 3.6.0a2. My custom [Keys] section: [Keys] default = False name2 = IDLE Modern Unix name = Terry The problem is that name2 should be treated only as default, never as custom, and should be used only if default=True. This is true in CurrentTheme. However, your revised CurrentKeys uses it first and unconditionally. Hence the observed behavior. CurrentKeys should use the same logic as CurrentTheme. In fact, the common logic should factored out into a separate function with two or three parameters and used by both. If, as you claim, CurrentTheme is buggy, it should be fixed before using it as the template for both. To test and claim that it was future proof, I did something like the following last fall. First set config-main.cfg [Keys] name2 to something non-existent, that might be added in the future. [Theme] default = True name2 = IDLE Future name = Custom Dark Then start, for instance, 3.5.2. The non-existent IDLE Future is ignored and replaced with the default default IDLE Classic, as intended in the code. No warnings. What exactly did you do to claim otherwise? --- Also wrong, even with your patch removed: '()Use a Built-in Key Set' says IDLE Classic Mac (slightly grayed) on all versions. If I select built-in, change built-in selection to IDLE Classic Windows, select custom again, click [OK] to close, and reopen, the unselected built-in has switched back to Mac. This must be a pre-existing bug that makes Classic Mac the default builtin when custom is selected, This is in spite of config-main.def having [Keys] default= 1 name= IDLE Classic Windows This, of course, is also wrong on non-Windows, which is why you changed it. But it is also being ignored when custom is selected. The problem must be in how configdialog gets the default key set when the current keyset is custom. The widget is a DynOptionMenu, created in CreatePageKeys, line 335, with no content. The options are set in LoadKeyCfg, lines 1055 and 1069. The latter is used when the current key is custom. It sets the grayed out default option to the alphabetically first among default key sets. itemList = idleConf.GetSectionList('default', 'keys') itemList.sort() self.optMenuKeysBuiltin.SetMenu(itemList, itemList[0]) itemList[0] should be replaced by your new system-sensitive idleConf.DefaultKeys(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 18:14:31 2016 From: report at bugs.python.org (Eryk Sun) Date: Mon, 27 Jun 2016 22:14:31 +0000 Subject: [issue27403] os.path.dirname doesn't handle Windows' URNs correctly In-Reply-To: <1467061421.97.0.269034608873.issue27403@psf.upfronthosting.co.za> Message-ID: <1467065671.57.0.191060328014.issue27403@psf.upfronthosting.co.za> Changes by Eryk Sun : ---------- Removed message: http://bugs.python.org/msg269406 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 18:15:33 2016 From: report at bugs.python.org (Eryk Sun) Date: Mon, 27 Jun 2016 22:15:33 +0000 Subject: [issue27403] os.path.dirname doesn't handle Windows' URNs correctly In-Reply-To: <1467061421.97.0.269034608873.issue27403@psf.upfronthosting.co.za> Message-ID: <1467065733.26.0.287020806129.issue27403@psf.upfronthosting.co.za> Eryk Sun added the comment: dirname() is implemented via split(), which begins by calling splitdrive(). The 'drive' for a UNC path is the r"\\server\share" component. For example: >>> path = r'\\server\share\folder\file' >>> os.path.splitdrive(path) ('\\\\server\\share', '\\folder\\file') >>> os.path.split(path) ('\\\\server\\share\\folder', 'file') >>> os.path.dirname(path) '\\\\server\\share\\folder' If you double the initial slashes, it's no longer a valid UNC path: >>> path = r'\\\\server\\share\\folder\\file' >>> os.path.splitdrive(path) ('', '\\\\\\\\server\\\\share\\\\folder\\\\file') >>> os.path.split(path) ('\\\\\\\\server\\\\share\\\\folder', 'file') >>> os.path.dirname(path) '\\\\\\\\server\\\\share\\\\folder' Windows itself will attempt to handle it as a UNC path, but the path is invalid. Specifically, before passing the path to the kernel, Windows collapses all of the extra slashes, except an initial slash count greater than two always leaves an extra slash in the path. For example: >>> open(r'\\\\server\\share\\folder\\file') Breakpoint 0 hit ntdll!NtCreateFile: 00007ffb`a1f25b70 4c8bd1 mov r10,rcx 0:000> !obja @r8 Obja +00000049781ef160 at 00000049781ef160: Name is \??\UNC\\server\share\folder\file OBJ_CASE_INSENSITIVE Notice the extra backlash in "UNC\\server". Thus a valid UNC path must start with exactly two slashes. Using forward slash is generally fine. The Windows API substitutes backslash for slash before passing a path to the kernel. For example: >>> open(r'//server/share/folder/file') Breakpoint 0 hit ntdll!NtCreateFile: 00007ffb`a1f25b70 4c8bd1 mov r10,rcx 0:000> !obja @r8 Obja +00000049781ef160 at 00000049781ef160: Name is \??\UNC\server\share\folder\file OBJ_CASE_INSENSITIVE Except you can't use forward slash with a "\\?\" path, which bypasses normal path processing. For example: >>> open(r'\\?\UNC/server/share/folder/file') Breakpoint 0 hit ntdll!NtCreateFile: 00007ffb`a1f25b70 4c8bd1 mov r10,rcx 0:000> !obja @r8 Obja +00000049781ef160 at 00000049781ef160: Name is \??\UNC/server/share/folder/file OBJ_CASE_INSENSITIVE In the kernel '/' isn't a path separator. It's just another name character, so this looks for a DOS device named "UNC/server/share/folder/file". Microsoft file systems forbid using slash in names (for POSIX compatibility and to avoid needless confusion), but you can use slash in the name of kernel objects such as Event objects, or even in the name of DOS devices defined via DefineDosDevice. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 18:17:29 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 27 Jun 2016 22:17:29 +0000 Subject: [issue27255] More opcode predictions In-Reply-To: <1465324904.47.0.783952984943.issue27255@psf.upfronthosting.co.za> Message-ID: <1467065849.97.0.958292285224.issue27255@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The BUILD_SLICE pairing with BINARY_SUBSCR has a tight conceptual linkage with the lookup case dominating use patterns over slice deletion and slice assignment. IIRC, I passed on that pairing long ago because even though the predictive power was good, it didn't come up much (a very, very low percentage of executed op-codes in any real programs). That would mean the user wouldn't be likely to see any benefit and I worried about the cost (global prediction tables have a finite size and are subject to aliased false positives, so when in doubt, it is better to not do it at all.) The UNPACK_SEQUENCE pairing with STORE_FAST had the opposite issue. The two arise in real code often enough to be interesting, but I wasn't as confident that it wasn't competing with alternative successors like STORE_NAME or attribute storage. Here, the statistics are heavily influenced by whatever is being profiled. Given that I wasn't confident in the pairing, I passed on it. That said, there's nothing terribly wrong with either, so it is hard to veto them. Now as well as back when the opcode predictions were first studied, I remain -0 on both pairings. In general, we should have a bias towards there being relatively few predictions (each one adds size to the generated code, adds load to the branch prediction tables, and adds to the cognitive load of anyone modifying the compiler, the peephole optimizer, or adding new opcodes) and there should be a preference to leave out cases where there is doubt. I'll leave it to you to decide whether either one of these should go in (I just wanted you to know why they weren't included in the first place). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 18:21:52 2016 From: report at bugs.python.org (Dustin Oprea) Date: Mon, 27 Jun 2016 22:21:52 +0000 Subject: [issue27403] os.path.dirname doesn't handle Windows' URNs correctly In-Reply-To: <1467061421.97.0.269034608873.issue27403@psf.upfronthosting.co.za> Message-ID: <1467066112.84.0.984964757544.issue27403@psf.upfronthosting.co.za> Dustin Oprea added the comment: Thank you for your elaborate response. I appreciate knowing that "\\server\share" could be considered as the "drive" portion of the path. I'm having trouble determining if "\\?\" is literally some type of valid UNC prefix or you're just using it to represent some format/idea. Just curious. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 20:19:36 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 28 Jun 2016 00:19:36 +0000 Subject: [issue27380] IDLE: add base Query dialog with ttk widgets In-Reply-To: <1466741717.27.0.533147933113.issue27380@psf.upfronthosting.co.za> Message-ID: <1467073176.05.0.962025454908.issue27380@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Thanks, I will switch to True and False. I am aware of the possibility of separately importing the constants, but like some others, I prefer the strings. Compile-time checking is a good point, especially with no run tests. In this case, test_query has 100% coverage of query.py. Minor question: While trying to use the new widget (instead of tkSimpledialog) in (editor.EditorWindow).open_module I had problems which I am trying to pin down by taking smaller steps. As part of this, I tried this minimal code that uses Query. from idlelib import query from tkinter import Tk root = Tk() name = query.Query(root, "Open Module", "Enter the name of a Python module\n" "to search on sys.path and open:",).result print(name) It works fine except that entry.focus_set() is not working for me with this call (or else it is not staying set) even though it works fine when configdialog calls the SectionName subclass. I know Windows is more troublesome than *nix about focus, but do you have any idea why calling Query this way, instead of as in the committed patch, would make a difference? ---------- stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 20:36:05 2016 From: report at bugs.python.org (Eryk Sun) Date: Tue, 28 Jun 2016 00:36:05 +0000 Subject: [issue27403] os.path.dirname doesn't handle Windows' URNs correctly In-Reply-To: <1467061421.97.0.269034608873.issue27403@psf.upfronthosting.co.za> Message-ID: <1467074165.96.0.663656756524.issue27403@psf.upfronthosting.co.za> Eryk Sun added the comment: Paths starting with "\\.\" (or "//./") and "\\?\" are not UNC paths. I've provided some explanations and examples below, and I also encourage you to read "Naming Files, Paths, and Namespaces": https://msdn.microsoft.com/en-us/library/aa365247 "\\.\" is the general way to access DOS devices, but with some path processing still enabled. For example: >>> files = os.listdir(r'//./C:/Windows/System32/..') >>> [x for x in files if x[:2] == 'py'] ['py.exe', 'pyw.exe'] Notice that using slash and ".." is allowed. This form doesn't allow relative paths that depend on per-drive current directories. It's actually not recommended to use "\\.\" to access files on drive letters. Normally it's used with drive letters only when directly opening a volume. For example: >>> fd = os.open(r'\\.\C:', os.O_RDONLY | os.O_BINARY) >>> os.read(fd, 512)[:7] b'\xebR\x90NTFS' The "\\?\" prefix allows the most access to the NT kernel namespace from within the Windows API (e.g. file paths can be up to 32K characters instead of the DOS limit of 260 characters). It does so by disabling all path processing, which means the onus is on the programmer to provide a fully-qualified, Unicode path that only uses backslash as the path separator. So why does "\\.\" exist? Some DOS devices are made implicitly available in the Windows API, such as DOS drive letters and "CON". However, the Windows API greatly extends the number of 'DOS' devices (e.g. the "PhysicalDrive0" device for low-level access to the first disk). Accessing these devices unambiguously requires the "\\.\" prefix. A common example is using "\\.\pipe\[pipe name]" to open a NamedPipe. You can even list the NamedPipe filesystem in Python. For example: >>> p1, p2 = multiprocessing.Pipe() >>> [x for x in os.listdir(r'\\.\pipe') if x[:2] == 'py'] ['pyc-719-1-hoirbkzb'] Global DOS device names are defined in the kernel's "\Global??" directory. Some DOS devices, such as mapped network drives, are usually defined local to a logon session in the kernel's "\Sessions\0\DosDevices\[Logon Session ID]" directory. In the examples I gave, you may have noticed that each native kernel path starts with "\??\". This is a virtual directory in the kernel (and only the kernel). It instructs the object manager to first search the local session DOS devices and then the global DOS devices. A DOS device is almost always implemented as an object symbolic link to the real NT device name in the kernel's "\Device" directory. For example, "\Global??\PIPE" links to "\Device\NamedPipe" and the "C:" drive may be a link to "\Device\HarddiskVolume2". This device is what the kernel actually opened in the previous example that read from "\\.\C:". Note that this accesses the volume itself, not the root directory of the filesystem that resides on the volume. The latter is "\\.C:\". The trailing backslash makes all the difference. (Opening a directory such as the latter requires backup semantics, as described in the CreateFile docs.) If a DOS drive letter is assigned to a volume, the assignment is stored in the registry by the volume's ID. (Dynamic volumes that span multiple disks also contain a drive letter hint.) For volume devices, the kernel also creates a GUID name that's always available and allows mounting a volume in a directory using an NTFS reparse point (e.g. see the output of mountvol.exe). You can also use GUID volume names in the Windows API. For example: >>> path = r'\\?\Volume{1693b540-0000-0000-0000-612e00000000}\Windows' >>> files = os.listdir(path) >>> [x for x in files if x[:2] == 'py'] ['py.exe', 'pyw.exe'] But normally you'd just mount the volume, which can even be recursively mounted within itself. For example: >>> os.mkdir('C:\\SystemVolume') >>> subprocess.call(r'mountvol C:\SystemVolume \\?\Volume{1693b540-0000-0000-0000-612e00000000}') 0 >>> files = os.listdir(r'C:\SystemVolume\Windows') >>> [x for x in files if x[:2] == 'py'] ['py.exe', 'pyw.exe'] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 21:15:04 2016 From: report at bugs.python.org (Emanuel Barry) Date: Tue, 28 Jun 2016 01:15:04 +0000 Subject: [issue27364] Deprecate invalid unicode escape sequences In-Reply-To: <1466541260.02.0.320668077341.issue27364@psf.upfronthosting.co.za> Message-ID: <1467076504.1.0.169777142838.issue27364@psf.upfronthosting.co.za> Emanuel Barry added the comment: Just brought this to the attention of the code-quality mailing list, so linter maintainers should (hopefully!) catch up soon. Also new patch, I forgot to add '\c' in the tests. ---------- Added file: http://bugs.python.org/file43569/deprecate_invalid_escapes_only_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 21:15:40 2016 From: report at bugs.python.org (Andre Merzky) Date: Tue, 28 Jun 2016 01:15:40 +0000 Subject: [issue23395] _thread.interrupt_main() errors if SIGINT handler in SIG_DFL, SIG_IGN In-Reply-To: <1423093850.42.0.241477195496.issue23395@psf.upfronthosting.co.za> Message-ID: <1467076540.1.0.970889998242.issue23395@psf.upfronthosting.co.za> Andre Merzky added the comment: I can confirm that the patch provided by Victor addresses the problem. It seems to be against the current HEAD -- is there a chance that this will be backported to 2.7 (which is what I need to use)? Thanks! Andre. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 22:33:18 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 28 Jun 2016 02:33:18 +0000 Subject: [issue27380] IDLE: add base Query dialog with ttk widgets In-Reply-To: <1466741717.27.0.533147933113.issue27380@psf.upfronthosting.co.za> Message-ID: <1467081198.97.0.204092282849.issue27380@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Revised load_module and new query.ModuleName work, including when invoked by open_class_browser. Tests are need for both. One problem was that using withdrawn root rather than a text as parent caused query.Query to not appear, so wait_window could not be terminated. ---------- stage: needs patch -> test needed Added file: http://bugs.python.org/file43570/query3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 27 22:39:32 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 28 Jun 2016 02:39:32 +0000 Subject: [issue27364] Deprecate invalid unicode escape sequences In-Reply-To: <1466541260.02.0.320668077341.issue27364@psf.upfronthosting.co.za> Message-ID: <1467081572.0.0.0849354330771.issue27364@psf.upfronthosting.co.za> Martin Panter added the comment: Forgot to say I reviewed invalid_stdlib_escapes_1.patch the other day and can?t see any problems. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 01:41:23 2016 From: report at bugs.python.org (=?utf-8?b?67CV7IS47JuQ?=) Date: Tue, 28 Jun 2016 05:41:23 +0000 Subject: [issue23749] asyncio missing wrap_socket (starttls) In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za> Message-ID: <1467092483.08.0.699022141192.issue23749@psf.upfronthosting.co.za> ??? added the comment: https://bugs.python.org/review/23749/#msg1 yuri, did you saw guido added review on your patch? ---------- nosy: +??? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 03:03:21 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Jun 2016 07:03:21 +0000 Subject: [issue23395] _thread.interrupt_main() errors if SIGINT handler in SIG_DFL, SIG_IGN In-Reply-To: <1423093850.42.0.241477195496.issue23395@psf.upfronthosting.co.za> Message-ID: <1467097401.25.0.251891770266.issue23395@psf.upfronthosting.co.za> STINNER Victor added the comment: > It seems to be against the current HEAD -- is there a chance that this will be backported to 2.7 (which is what I need to use)? Yes, I will fix Python 2.7 and 3.5, I will just make PyErr_SetInterruptWithErr() private (rename to _PyErr_SetInterruptWithErr()). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 03:09:50 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 Jun 2016 07:09:50 +0000 Subject: [issue27255] More opcode predictions In-Reply-To: <1465324904.47.0.783952984943.issue27255@psf.upfronthosting.co.za> Message-ID: <1467097790.96.0.963193805214.issue27255@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: OK, I'm only +0 on adding these predictions and fine with status quo. The ratio 28:1 looks compelling to me, but all this is not enough important. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 03:13:13 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 Jun 2016 07:13:13 +0000 Subject: [issue27085] Make it possible to select return type for os.listdir In-Reply-To: <1463940504.88.0.721320439319.issue27085@psf.upfronthosting.co.za> Message-ID: <1467097993.04.0.295219789078.issue27085@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 03:29:38 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 28 Jun 2016 07:29:38 +0000 Subject: [issue26226] Various test suite failures on Windows In-Reply-To: <1453940751.65.0.882732529995.issue26226@psf.upfronthosting.co.za> Message-ID: <1467098978.58.0.554045892026.issue26226@psf.upfronthosting.co.za> Martin Panter added the comment: Regarding the files getting messed up in Lib/test/cjkencodings, IMO the solution is to not configure Git to mess with newlines in files. ;) But perhaps a reasonable workaround might be to rename the relevant files to something like *.txt.bin. Perhaps that will bypass whatever logic Git uses. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 03:29:54 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 Jun 2016 07:29:54 +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: <1467098994.72.0.460873367516.issue21134@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: An empty string is the result of str() on an instance created with __new__ for all standard exceptions except SyntaxError (str() returnns 'None' for the latter, and this looks as a bug). Since there was no complains on this issue, I think it can be closed. ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 03:33:04 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 Jun 2016 07:33:04 +0000 Subject: [issue27025] More human readable generated widget names In-Reply-To: <1463299445.94.0.887025569149.issue27025@psf.upfronthosting.co.za> Message-ID: <1467099184.64.0.659869084466.issue27025@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'm working on a patch that allows to trace all Tcl commands passed from Tkinter, and a number of ".`" in widget names looks not nice. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 03:56:45 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Jun 2016 07:56:45 +0000 Subject: [issue26226] Various test suite failures on Windows In-Reply-To: <1453940751.65.0.882732529995.issue26226@psf.upfronthosting.co.za> Message-ID: <1467100605.18.0.449250994672.issue26226@psf.upfronthosting.co.za> STINNER Victor added the comment: It looks like all issues are now fixed in the default branch, no? Can we close this issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 03:59:24 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Jun 2016 07:59:24 +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: <1467100764.87.0.98993932089.issue21134@psf.upfronthosting.co.za> STINNER Victor added the comment: > Since there was no complains on this issue, I think it can be closed. I have a complain: we should not ignore bugs. IMO an exception must be raised. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 04:06:01 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 Jun 2016 08:06:01 +0000 Subject: [issue27405] Ability to trace Tcl commands executed by Tkinter Message-ID: <1467101160.96.0.000959009774067.issue27405@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: For debugging purpose it would be helpful to have an ability to show all Tcl commands executed by Tkinter. In particular it would be helpful for testing wherever some issue is Tkinter issue or Tcl/Tk issue. I'm working on a patch, but there is a design question about an interface. In simplest case you set the debug property of Tk instance to True and all Tcl commands are printed to stdout or stderr in the form ready for executing with Tcl/Tk interpreter. You also can set the module global tkinter.debug to True, and this will affect all new Tk instances (as with tkinter.wantobjects). But maybe there is a need in larger customization? For example specifying the command that accepts every Tcl command as a string or a tuple? ---------- components: Tkinter messages: 269425 nosy: serhiy.storchaka, terry.reedy priority: normal severity: normal status: open title: Ability to trace Tcl commands executed by Tkinter type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 04:32:30 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 Jun 2016 08:32:30 +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: <1467102750.89.0.844762925606.issue21134@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What is the bug here (except fixed segfault)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 05:14:24 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 28 Jun 2016 09:14:24 +0000 Subject: [issue26971] python v3.5.1: sys.paths not respecting DESTDIRS and DESTSHARED In-Reply-To: <1462628482.0.0.926875224828.issue26971@psf.upfronthosting.co.za> Message-ID: <1467105264.0.0.802944511143.issue26971@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Johannes, what are the values of CONFIG_ARGS and libdir in the config.log of your Linux SuSE. ---------- nosy: +xdegaye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 05:39:07 2016 From: report at bugs.python.org (Bar Harel) Date: Tue, 28 Jun 2016 09:39:07 +0000 Subject: [issue27141] Fix collections.UserList shallow copy In-Reply-To: <1464384542.41.0.303372176211.issue27141@psf.upfronthosting.co.za> Message-ID: <1467106747.38.0.654628055225.issue27141@psf.upfronthosting.co.za> Bar Harel added the comment: Are the patch and tests good? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 07:01:19 2016 From: report at bugs.python.org (INADA Naoki) Date: Tue, 28 Jun 2016 11:01:19 +0000 Subject: [issue27350] Compact and ordered dict In-Reply-To: <1466307796.29.0.980579044792.issue27350@psf.upfronthosting.co.za> Message-ID: <1467111679.52.0.883472729897.issue27350@psf.upfronthosting.co.za> INADA Naoki added the comment: Anyone can review this by Python 3.6a3 ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 10:05:49 2016 From: report at bugs.python.org (Rolf Krahl) Date: Tue, 28 Jun 2016 14:05:49 +0000 Subject: [issue12319] [http.client] HTTPConnection.request not support "chunked" Transfer-Encoding to send data In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za> Message-ID: <1467122749.62.0.656794710487.issue12319@psf.upfronthosting.co.za> Rolf Krahl added the comment: Martin, I'm almost through with your comments. There is however one item that I need some feedback on: You asked for more documentation on the new EncodingError exception. This was introduced by Demian. It is raised when the Transfer-encoding header set by the caller is invalid. I'm not sure about this. What is the purpose of the HTTPException tree of exceptions in http.client? Is this ought to be a collection of all kinds of exceptions raised in http.client or should a (child of) HTTPException indicate that an exception occurred while talking to the HTTP server? In the latter case, the EncodingError class as introduced now would be just wrong. Maybe we should raise a ValueError instead? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 10:08:10 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 28 Jun 2016 14:08:10 +0000 Subject: [issue26226] Various test suite failures on Windows In-Reply-To: <1453940751.65.0.882732529995.issue26226@psf.upfronthosting.co.za> Message-ID: <1467122890.01.0.948210572298.issue26226@psf.upfronthosting.co.za> R. David Murray added the comment: It looks like this issue can be closed, but a new one should be opened for dealing with the newline issue under git on windows. However, I'm surprised there weren't failures in the email tests. Although I've been moving the email tests away from depending on data on the disk being in DOS format, I think there are some compat32 tests that still do so. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 10:09:06 2016 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 28 Jun 2016 14:09:06 +0000 Subject: [issue27406] subprocess.Popen() hangs in multi-threaded code Message-ID: <1467122946.13.0.890453921822.issue27406@psf.upfronthosting.co.za> New submission from Kristj?n Valur J?nsson: On a quad-core raspberrypi, i have experienced that subprocess.Popen() sometimes does not return immediatelly, but only much later, when an unrelated process has exited. Debugging the issue, I find the parent process hanging in # Wait for exec to fail or succeed; possibly raising exception # Exception limited to 1M data = _eintr_retry_call(os.read, errpipe_read, 1048576) This behaviour is consistent with the problem described in pipe_cloexec(): def pipe_cloexec(self): """Create a pipe with FDs set CLOEXEC.""" # Pipes' FDs are set CLOEXEC by default because we don't want them # to be inherited by other subprocesses: the CLOEXEC flag is removed # from the child's FDs by _dup2(), between fork() and exec(). # This is not atomic: we would need the pipe2() syscall for that. r, w = os.pipe() self._set_cloexec_flag(r) self._set_cloexec_flag(w) return r, w In short: It appears that occasionally the pipe FD is leaked to a different subprocess (started on a separate thread) before the cloexec flags can be set. This causes the parent process to wait until that other instance of the file descriptor is closed, i.e. when that other unrelated process exits. I currently have a workaround which involves using a threading.Lock() around the call. This is not very nice, however. Also, there is #Issue12196 which could be backported to 2.7 to address this problem. ---------- components: Interpreter Core messages: 269432 nosy: kristjan.jonsson priority: normal severity: normal status: open title: subprocess.Popen() hangs in multi-threaded code type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 10:12:07 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 28 Jun 2016 14:12:07 +0000 Subject: [issue27406] subprocess.Popen() hangs in multi-threaded code In-Reply-To: <1467122946.13.0.890453921822.issue27406@psf.upfronthosting.co.za> Message-ID: <1467123127.85.0.378311842181.issue27406@psf.upfronthosting.co.za> R. David Murray added the comment: This is a duplicate of issue 20318. The advice is to use subprocess32. ---------- nosy: +r.david.murray resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> subprocess.Popen can hang in threaded applications in Python 2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 10:42:50 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 28 Jun 2016 14:42:50 +0000 Subject: [issue27385] itertools.groupby has misleading doc string In-Reply-To: <1466801880.76.0.293579802764.issue27385@psf.upfronthosting.co.za> Message-ID: <1467124970.63.0.136197748511.issue27385@psf.upfronthosting.co.za> Josh Rosenberg added the comment: While you're fixing, the docstring should say "groupby(iterable, key=None)", not "groupby(iterable[, keyfunc])"; the functions accepts the key function by name, and the name is key, not keyfunc. And it can be passed explicitly as None (equivalent to not passing it at all), so the [, keyfunc] approach that indicates it's positional only and can't be explicitly passed as a default is wrong. Gets a little confusing because it also returns a "key", but the argument is definitely named "key", so we can't go calling it "keyfunc". Mind you, seems like this could also be fixed by just Clinic-ifying it. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 10:50:23 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 28 Jun 2016 14:50:23 +0000 Subject: [issue27385] itertools.groupby has misleading doc string In-Reply-To: <1466801880.76.0.293579802764.issue27385@psf.upfronthosting.co.za> Message-ID: <1467125423.02.0.45279463343.issue27385@psf.upfronthosting.co.za> R. David Murray added the comment: Please open a separate issue for that problem. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 11:01:22 2016 From: report at bugs.python.org (Emanuel Barry) Date: Tue, 28 Jun 2016 15:01:22 +0000 Subject: [issue26226] Various test suite failures on Windows In-Reply-To: <1453940751.65.0.882732529995.issue26226@psf.upfronthosting.co.za> Message-ID: <1467126082.02.0.770105465739.issue26226@psf.upfronthosting.co.za> Emanuel Barry added the comment: Some of the tests that used to fail are now passing, however some are still failing (and new ones are also failing now). Tests that are still failing: test_code_module (TestInteractiveConsole; test_ps1 and test_ps2 failed) test_codecencodings_iso2022 (blame git for changing line endings; will open a new issue about this) New failures: test_capi (_testcapi doesn't have test_buildvalue_N) test_codecencodings_jp (passes when I run it by itself... ?) test_ctypes (AssertionError: "phi" does not match "duplicate values for field '???'") test_decimal (will open a new issue for that one, there are over 300 lines of failures/errors) test_distutils (env changed, also no tests run when I try to run it by itself) test_getargs2 (fails on import with 'from _testcapi import getargs_positional_only_and_keywords as getargs'; ImportError: cannot import name 'getargs_positional_only_and_keywords') Tests previously hung up after that point. The tests continue now, so here are more failures: test_logging (socket timeout) test_os (many failed C++ assertions! [Visual C++ Runtime library] Will open a new issue about that) test_random (line endings mismatch) test_sax (again line endings mismatch) test_sqlite (sqlite3.test.dbapi.CursorTests.CheckLastRowIDOnReplace fails with self.cu.lastrowid =! 1 [it's None]) test_strptime (that's a DST issue: AssertionError: False is not true : timezone est (heure d??t?) not found in (frozenset({'gmt', 'est', 'utc'}), frozenset({'est (heure d\x92?t?)'}))) test_uuid (sounds like it's related to my hostname having non-ASCII characters) test_warnings ('__main__' != '' [I'm running tests via the interactive prompt, this might be why]) test_xml_etree_c ('Windows fatal error: stack overflow' in the test that makes sure recursive repr doesn't overflow [but it doesn't fail when I run it individually, apparently]) I'll spawn new issues for the more serious/specific ones, but unless you'd rather have one issue per failure, I'd like to keep this one open (for now at least). @R. David: 4 skips, but no failures in the email tests, so at least there's that! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 11:15:36 2016 From: report at bugs.python.org (Emanuel Barry) Date: Tue, 28 Jun 2016 15:15:36 +0000 Subject: [issue26226] Various test suite failures on Windows In-Reply-To: <1453940751.65.0.882732529995.issue26226@psf.upfronthosting.co.za> Message-ID: <1467126936.64.0.61435914651.issue26226@psf.upfronthosting.co.za> Emanuel Barry added the comment: About the strptime failure - it seems time.strftime returns "Est (heure d??t?)" while _strptime.LocaleTime().timezone has "est (heure d\x92?t?)". I don't know why it's like that, but neither are correct - the character that goes there is a single quote ('). I'm also puzzled by the fact that '?' appears properly despite not being ASCII. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 11:16:34 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 28 Jun 2016 15:16:34 +0000 Subject: [issue27385] itertools.groupby has misleading doc string In-Reply-To: <1466801880.76.0.293579802764.issue27385@psf.upfronthosting.co.za> Message-ID: <1467126994.31.0.294090093043.issue27385@psf.upfronthosting.co.za> Raymond Hettinger added the comment: That's okay. I'm taking care of both in this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 11:22:26 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 28 Jun 2016 15:22:26 +0000 Subject: [issue27385] itertools.groupby has misleading doc string In-Reply-To: <1466801880.76.0.293579802764.issue27385@psf.upfronthosting.co.za> Message-ID: <1467127346.16.0.292760427645.issue27385@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Added file: http://bugs.python.org/file43571/groupbydoc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 11:49:24 2016 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 28 Jun 2016 15:49:24 +0000 Subject: [issue23749] asyncio missing wrap_socket (starttls) In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za> Message-ID: <1467128964.44.0.381340771641.issue23749@psf.upfronthosting.co.za> Yury Selivanov added the comment: > yuri, did you saw guido added review on your patch? Yes. There are few more issues with the patch that I want to resolve before re-submitting it for another review. Will do it soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 11:51:41 2016 From: report at bugs.python.org (George Ge) Date: Tue, 28 Jun 2016 15:51:41 +0000 Subject: [issue27407] prepare_ssl.py missing in PCBuild folder Message-ID: <1467129101.75.0.190967311264.issue27407@psf.upfronthosting.co.za> New submission from George Ge: The readme.txt file in the PCBuild folder in Python 2.7.11 and 2.7.12 sources both contain instructions on how to configure to build a different OpenSSL version using PCbuild\prepare_ssl.py, but this file is missing on both versions. ---------- components: Installation, Windows messages: 269440 nosy: George Ge, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: prepare_ssl.py missing in PCBuild folder type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 11:58:06 2016 From: report at bugs.python.org (Ulrich Petri) Date: Tue, 28 Jun 2016 15:58:06 +0000 Subject: [issue27337] 3.6.0a2 tarball has weird paths In-Reply-To: <1466100270.24.0.259127068452.issue27337@psf.upfronthosting.co.za> Message-ID: <1467129486.1.0.584083984139.issue27337@psf.upfronthosting.co.za> Ulrich Petri added the comment: Just as another datapoint: This also breaks installing a2 with pythonz. ---------- nosy: +ulope _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 12:16:23 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 28 Jun 2016 16:16:23 +0000 Subject: [issue27407] prepare_ssl.py missing in PCBuild folder In-Reply-To: <1467129101.75.0.190967311264.issue27407@psf.upfronthosting.co.za> Message-ID: <1467130583.27.0.160361115685.issue27407@psf.upfronthosting.co.za> Steve Dower added the comment: It can be found at PCbuild/prepare_ssl.py in the default branch. Copying it into the 2.7 branch wouldn't hurt I guess, and I'm okay with having build scripts in there that depend on Python 3 ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 12:22:44 2016 From: report at bugs.python.org (George Ge) Date: Tue, 28 Jun 2016 16:22:44 +0000 Subject: [issue27407] prepare_ssl.py missing in PCBuild folder In-Reply-To: <1467129101.75.0.190967311264.issue27407@psf.upfronthosting.co.za> Message-ID: <1467130964.16.0.373147499763.issue27407@psf.upfronthosting.co.za> George Ge added the comment: I see. Would it be possible to have a version of prepare_ssl.py written in 2.7 for the official source releases? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 12:29:05 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 28 Jun 2016 16:29:05 +0000 Subject: [issue27407] prepare_ssl.py missing in PCBuild folder In-Reply-To: <1467129101.75.0.190967311264.issue27407@psf.upfronthosting.co.za> Message-ID: <1467131345.31.0.172448167961.issue27407@psf.upfronthosting.co.za> Steve Dower added the comment: It would need someone to volunteer to port and maintain it. I don't believe any of the current team want to maintain two different versions of the script, considering we all use Python 3 and have it available when updating the version of OpenSSL used. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 13:13:24 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 28 Jun 2016 17:13:24 +0000 Subject: [issue27402] Sequence example in typing module documentation does not typecheck In-Reply-To: <1467047380.43.0.562730585486.issue27402@psf.upfronthosting.co.za> Message-ID: <20160628171309.28782.74096.A3C07A06@psf.io> Roundup Robot added the comment: New changeset 0aec17c8f434 by Guido van Rossum in branch '3.5': Fix issue #27402: example for typing did not type-check. https://hg.python.org/cpython/rev/0aec17c8f434 New changeset 57f3514564f6 by Guido van Rossum in branch 'default': Fix issue #27402: example for typing did not type-check. (Merge 3.5->3.6) https://hg.python.org/cpython/rev/57f3514564f6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 13:32:44 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 28 Jun 2016 17:32:44 +0000 Subject: [issue27402] Sequence example in typing module documentation does not typecheck In-Reply-To: <1467047380.43.0.562730585486.issue27402@psf.upfronthosting.co.za> Message-ID: <1467135164.33.0.386384463667.issue27402@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks! ---------- nosy: +gvanrossum resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 13:49:51 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 28 Jun 2016 17:49:51 +0000 Subject: [issue27405] Ability to trace Tcl commands executed by Tkinter In-Reply-To: <1467101160.96.0.000959009774067.issue27405@psf.upfronthosting.co.za> Message-ID: <1467136191.83.0.0945740589709.issue27405@psf.upfronthosting.co.za> Terry J. Reedy added the comment: +1 for at least a simple interface: tkinter/root.debug = True. Let's do at least that much. I don't understand what you propose in the last sentence, do you mean 'add a new function that accepts any tcl command, as string or tuple'? Or add better access to the existing call function? Or does the existing call function have limitations I do not not know about? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 14:37:25 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 28 Jun 2016 18:37:25 +0000 Subject: [issue27383] executuable in distutils triggering microsoft anti virus In-Reply-To: <1466780621.95.0.0684107940642.issue27383@psf.upfronthosting.co.za> Message-ID: <1467139045.5.0.246330114641.issue27383@psf.upfronthosting.co.za> Steve Dower added the comment: FYI the definitions have been updated and I'm no longer seeing the false positive. Definition version: 1.223.2858.0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 14:52:08 2016 From: report at bugs.python.org (Rob Bairos) Date: Tue, 28 Jun 2016 18:52:08 +0000 Subject: [issue27383] executuable in distutils triggering microsoft anti virus In-Reply-To: <1467139045.5.0.246330114641.issue27383@psf.upfronthosting.co.za> Message-ID: Rob Bairos added the comment: Great. Thanks for the update On Tue, Jun 28, 2016 at 2:37 PM, Steve Dower wrote: > > Steve Dower added the comment: > > FYI the definitions have been updated and I'm no longer seeing the false > positive. > > Definition version: 1.223.2858.0 > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 15:20:51 2016 From: report at bugs.python.org (Zachary Ware) Date: Tue, 28 Jun 2016 19:20:51 +0000 Subject: [issue27407] prepare_ssl.py missing in PCBuild folder In-Reply-To: <1467129101.75.0.190967311264.issue27407@psf.upfronthosting.co.za> Message-ID: <1467141651.83.0.928704224389.issue27407@psf.upfronthosting.co.za> Zachary Ware added the comment: You can also use PC/VS9.0/build_ssl.py which was the progenitor of prepare_ssl.py. The project files in PC/VS9.0 will use build_ssl.py by default. FTR, I'm good with copying prepare_ssl.py to 2.7, and even with ensuring that it's 2.7 compatible (it probably already is), but I want it to match between branches and it must be Python 3 compatible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 17:02:24 2016 From: report at bugs.python.org (Neil Schemenauer) Date: Tue, 28 Jun 2016 21:02:24 +0000 Subject: [issue27377] Add smarter socket.fromfd() In-Reply-To: <1466706816.6.0.72770597716.issue27377@psf.upfronthosting.co.za> Message-ID: <1467147744.68.0.684380104449.issue27377@psf.upfronthosting.co.za> Neil Schemenauer added the comment: I've revised the patch based on the second round of comments from Martin. I've removed the ifdef test for CO_TYPE and assumed it is always available. That means fdtype() should be available on all platforms. I did not change the test as suggested to call s.detach(), I think my test code should work okay. The compare of 'protocol' has been removed from the test. The duplicate definition of SO_PASSCRED has been removed. I didn't add the constants to the documentation as other constants are only documented on a wildcard basis (e.g. SO_*). ---------- Added file: http://bugs.python.org/file43572/fromfd2_v3.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 17:44:35 2016 From: report at bugs.python.org (Brett Cannon) Date: Tue, 28 Jun 2016 21:44:35 +0000 Subject: [issue26844] Wrong error message during import In-Reply-To: <1461564546.15.0.190869698481.issue26844@psf.upfronthosting.co.za> Message-ID: <1467150275.52.0.415806364835.issue26844@psf.upfronthosting.co.za> Brett Cannon added the comment: Should we use __qualname__ instead of __name__? And I haven't forgotten about your patch, Lev. I'm just occupied trying to get feature changes into Python 3.6 as that has a sooner deadline than bug fixes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 18:05:01 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 28 Jun 2016 22:05:01 +0000 Subject: [issue4945] json checks True/False by identity, not boolean value In-Reply-To: <1231911098.49.0.621266929609.issue4945@psf.upfronthosting.co.za> Message-ID: <1467151501.19.0.681901620293.issue4945@psf.upfronthosting.co.za> Raymond Hettinger added the comment: These latest two patches look fine. Go ahead with them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 19:20:13 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 28 Jun 2016 23:20:13 +0000 Subject: [issue27384] itertools islice consumes items when given negative range In-Reply-To: <1466795612.87.0.341578291618.issue27384@psf.upfronthosting.co.za> Message-ID: <1467156013.02.0.861070397823.issue27384@psf.upfronthosting.co.za> Raymond Hettinger added the comment: "Surprising" is in the eye of the beholder. Having islice() always consume at least "start" number of values seems reasonable enough and it is the documented behavior: "If start is non-zero, then elements from the iterable are skipped until start is reached. ... If stop is None, then iteration continues until the iterator is exhausted, if at all; otherwise, it stops at the specified position." That covers a lot of cases including the existing consume() recipe and what happens to the iterator if it supplies fewer than start elements: it=iter('abc'); list(islice(it, 4, 4)); print(list(it)). Also, to my eyes, the current behavior seems like a natural and smooth transition as the arguments transition towards cross-over: >>> from itertools import islice >>> it = iter('ABCDEFG'); print(list(islice(it, 2, 4)), list(it)) ['C', 'D'] ['E', 'F', 'G'] >>> it = iter('ABCDEFG'); print(list(islice(it, 2, 3)), list(it)) ['C'] ['D', 'E', 'F', 'G'] >>> it = iter('ABCDEFG'); print(list(islice(it, 2, 2)), list(it)) [] ['C', 'D', 'E', 'F', 'G'] >>> it = iter('ABCDEFG'); print(list(islice(it, 2, 1)), list(it)) [] ['C', 'D', 'E', 'F', 'G'] >>> it = iter('ABCDEFG'); print(list(islice(it, 2, 0)), list(it)) [] ['C', 'D', 'E', 'F', 'G'] >>> it = iter('ABCDEFG'); print(list(islice(it, 0, 2)), list(it)) ['A', 'B'] ['C', 'D', 'E', 'F', 'G'] >>> it = iter('ABCDEFG'); print(list(islice(it, 1, 2)), list(it)) ['B'] ['C', 'D', 'E', 'F', 'G'] >>> it = iter('ABCDEFG'); print(list(islice(it, 2, 2)), list(it)) [] ['C', 'D', 'E', 'F', 'G'] >>> it = iter('ABCDEFG'); print(list(islice(it, 3, 2)), list(it)) [] ['D', 'E', 'F', 'G'] >>> it = iter('ABCDEFG'); print(list(islice(it, 4, 2)), list(it)) [] ['E', 'F', 'G'] Putting in your suggested optimization to treat start > stop as being fully consumed from the outset would have some big disadvantages. It would break existing code relying on the current reasonable and documented behavior of always eating at least "start" elements. And it would incentivize a new and weird idiom for "consume" as islice(it, n, 0). As far as I can tell, the current behavior hasn't been problematic for anyone in the almost 15 year history of the itertools module, so it is hard to get excited enough about this to want to incur those disadvantages. ---------- priority: normal -> resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 19:35:29 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 28 Jun 2016 23:35:29 +0000 Subject: [issue26226] Various test suite failures on Windows In-Reply-To: <1453940751.65.0.882732529995.issue26226@psf.upfronthosting.co.za> Message-ID: <1467156929.86.0.591900020458.issue26226@psf.upfronthosting.co.za> Martin Panter added the comment: test_distutils: Is the failure the same as before, or changed? Are you testing with new code that includes the Issue 27048 fix? It looks like test_distutils doesn?t support running directly via ?unittest?. Perhaps try ?python -m test -W test_distutils? or similar if you were previously only trying unittest. Some of your new failures look like symptoms of running the test suite on out-of-date compiled modules. For test_ctypes, see Issue 27343; test_getargs2: Issue 26282; test_capi: Issue 26168. strptime: Maybe the test suite is trying to report a string that contains both U+0092 and ???, but cannot encode U+0092, and uses backslashreplace error handler. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 20:25:07 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 29 Jun 2016 00:25:07 +0000 Subject: [issue27377] Add smarter socket.fromfd() In-Reply-To: <1466706816.6.0.72770597716.issue27377@psf.upfronthosting.co.za> Message-ID: <1467159907.29.0.687246432841.issue27377@psf.upfronthosting.co.za> Martin Panter added the comment: The s.detach() thing isn?t a big deal, but I thought it would simplify the code (eliminate the need for the ?finally? clause). I will try to propose a minor documentation update for SO_PASSCRED as a starting point for adding the others. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 21:03:34 2016 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 29 Jun 2016 01:03:34 +0000 Subject: [issue22970] asyncio: Cancelling wait() after notification leaves Condition in an inconsistent state In-Reply-To: <1417404582.01.0.276361050449.issue22970@psf.upfronthosting.co.za> Message-ID: <1467162214.22.0.784887652057.issue22970@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 21:28:12 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 29 Jun 2016 01:28:12 +0000 Subject: [issue19802] socket.SO_PRIORITY is missing In-Reply-To: <1385485579.99.0.471708921072.issue19802@psf.upfronthosting.co.za> Message-ID: <1467163692.64.0.48640646529.issue19802@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- versions: +Python 3.4 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 21:30:53 2016 From: report at bugs.python.org (Larry Hastings) Date: Wed, 29 Jun 2016 01:30:53 +0000 Subject: [issue19802] socket.SO_PRIORITY is missing In-Reply-To: <1385485579.99.0.471708921072.issue19802@psf.upfronthosting.co.za> Message-ID: <1467163853.79.0.531064603075.issue19802@psf.upfronthosting.co.za> Larry Hastings added the comment: Sorry, this is now too late for 3.4. 3.4 is now in "security fixes only" mode. This is not a security fix, therefore 3.4 is now ineligible. Since this change was committed to 3.5, it's better to let the historical record reflect that. So I'm changing the version back to 3.5 (and not 3.4). ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 22:22:03 2016 From: report at bugs.python.org (Brett Cannon) Date: Wed, 29 Jun 2016 02:22:03 +0000 Subject: [issue27408] Document importlib.abc.ExecutionLoader implements get_data() Message-ID: <1467166923.22.0.634971996974.issue27408@psf.upfronthosting.co.za> New submission from Brett Cannon: The fact that importlib.abc.ExectionLoader.get_data() is implemented is missing (or put another way, it isn't documented that get_source() still needs to be implemented). ---------- assignee: docs at python components: Documentation messages: 269458 nosy: brett.cannon, docs at python priority: normal severity: normal stage: needs patch status: open title: Document importlib.abc.ExecutionLoader implements get_data() versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 22:45:42 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 29 Jun 2016 02:45:42 +0000 Subject: [issue1732367] Document the constants in the socket module Message-ID: <1467168342.13.0.235183929797.issue1732367@psf.upfronthosting.co.za> Martin Panter added the comment: Reopening because the consensus seems to be to update and apply this sort of change. ---------- nosy: +martin.panter stage: -> needs patch status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 22:54:56 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 29 Jun 2016 02:54:56 +0000 Subject: [issue27409] List socket.SO_*, SCM_*, MSG_*, IPPROTO_* symbols Message-ID: <1467168896.94.0.840314714269.issue27409@psf.upfronthosting.co.za> New submission from Martin Panter: The documentation just says that SO_* etc constants are defined. However when people add new ones, they add them as new features to a specific version (not backported as bug fixes), but do not alter the documentation at all. IMO it is silly adding undocumented features. E.g. Issue 26907 was opened to add (among others) SO_PASSCRED, which was already added, undocumented, as part of Issue 6560. This patch attempts to indicate which symbols are defined by Python (depending on OS availability), and therefore one can deduce if Python does not define a particular symbol. It could be adapted to the 2.7 documentation, but I am not really motivated for that on my own. I also remove a redundant definition in the module, and removed a conditional because SO_REUSEADDR is required to always be defined according to the test suite. These specific changes should only be applied to 3.6. I also found Issue 1732367, which has a patch documenting each AF_* symbol in a little more detail. That patch was never updated nor comitted, but it sounds like this kind of addition might be acceptable. ---------- assignee: docs at python components: Documentation files: socket-const.patch keywords: patch messages: 269460 nosy: docs at python, martin.panter priority: normal severity: normal stage: patch review status: open title: List socket.SO_*, SCM_*, MSG_*, IPPROTO_* symbols versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43573/socket-const.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 23:50:44 2016 From: report at bugs.python.org (anandbhat) Date: Wed, 29 Jun 2016 03:50:44 +0000 Subject: [issue27410] DLL hijacking vulnerability in Python 3.5.2 installer Message-ID: <1467172244.73.0.493856628502.issue27410@psf.upfronthosting.co.za> New submission from anandbhat: The Python 3.5.2 Windows x86-64 executable installer (MD5: 4da6dbc8e43e2249a0892d257e977291) downloaded from https://www.python.org/ftp/python/3.5.2/python-3.5.2-amd64.exe is vulnerable to DLL hijacking. The installer attempts to load DLLs from the current directory, which in most cases, is the Downloads directory. As explained in http://blog.opensecurityresearch.com/2014/01/unsafe-dll-loading-vulnerabilities.html and https://textslashplain.com/2015/12/18/dll-hijacking-just-wont-die/, installers that are vulnerable to DLL hijacking can be used to load untrusted and malicious DLLs. A maliciously crafted DLL when dropped into the user's Downloads directory will be executed by this installer. System used for testing: Windows 10 Steps to reproduce: 1. Download a dummy DLL file for this demo -- version.dll -- from https://www.dropbox.com/s/3l5qwz7ppevs9za/version.dll?dl=0 and place it in the default Downloads directory. Virustotal report for this file: https://www.virustotal.com/en/file/29b51fdb8e498ef5d3fe05e924e23fcaffa554d64fb024b042101236028242b0/analysis/1467171188/ 2. Download the Python 3.5.2 Windows x86-64 executable installer (MD5: 4da6dbc8e43e2249a0892d257e977291) from https://www.python.org/ftp/python/3.5.2/python-3.5.2-amd64.exe and save it to the default Downloads directory (e.g., C:\Users\xxx\Downloads) 3. Attempt to run the downloaded installer. 4. Windows loads version.dll placed in step [1]. This is just one of several DLLs that can be exploited. Attached are screen captures from Process Monitor (https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx) in a Windows 10 environment with filters (listed below) that show the DLLs looked for by the installer in the Downloads directory. Process Monitor filters: Inclusion: Process Name beginswith python, Path beginswith Operation is Load Image Operation is CreateImage Exclusion: Path endswith .ini Path contains .exe ---------- components: Installation files: Python_3.5.2_64_exe_DLL_Hijack.PNG messages: 269461 nosy: anandbhat priority: normal severity: normal status: open title: DLL hijacking vulnerability in Python 3.5.2 installer type: security versions: Python 3.5 Added file: http://bugs.python.org/file43574/Python_3.5.2_64_exe_DLL_Hijack.PNG _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 23:51:17 2016 From: report at bugs.python.org (anandbhat) Date: Wed, 29 Jun 2016 03:51:17 +0000 Subject: [issue27410] DLL hijacking vulnerability in Python 3.5.2 installer In-Reply-To: <1467172244.73.0.493856628502.issue27410@psf.upfronthosting.co.za> Message-ID: <1467172277.7.0.00398449157981.issue27410@psf.upfronthosting.co.za> Changes by anandbhat : Added file: http://bugs.python.org/file43575/Python_3.5.2_64_exe_version_DLL_Hijack.PNG _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 23:52:15 2016 From: report at bugs.python.org (anandbhat) Date: Wed, 29 Jun 2016 03:52:15 +0000 Subject: [issue27410] DLL hijacking vulnerability in Python 3.5.2 installer In-Reply-To: <1467172244.73.0.493856628502.issue27410@psf.upfronthosting.co.za> Message-ID: <1467172335.58.0.224317888929.issue27410@psf.upfronthosting.co.za> Changes by anandbhat : Removed file: http://bugs.python.org/file43574/Python_3.5.2_64_exe_DLL_Hijack.PNG _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 28 23:53:56 2016 From: report at bugs.python.org (anandbhat) Date: Wed, 29 Jun 2016 03:53:56 +0000 Subject: [issue27410] DLL hijacking vulnerability in Python 3.5.2 installer In-Reply-To: <1467172244.73.0.493856628502.issue27410@psf.upfronthosting.co.za> Message-ID: <1467172436.07.0.33547855269.issue27410@psf.upfronthosting.co.za> Changes by anandbhat : Added file: http://bugs.python.org/file43576/Python_3.5.2_64_exe_DLL_Hijack.PNG _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 00:00:10 2016 From: report at bugs.python.org (Eryk Sun) Date: Wed, 29 Jun 2016 04:00:10 +0000 Subject: [issue26226] Various test suite failures on Windows In-Reply-To: <1453940751.65.0.882732529995.issue26226@psf.upfronthosting.co.za> Message-ID: <1467172810.39.0.948866181211.issue26226@psf.upfronthosting.co.za> Eryk Sun added the comment: time.strftime calls the CRT's strftime function, which the Windows universal CRT implements by calling wcsftime and encoding the result. The timezone name is actually stored as a char string (tzname), so wcsftime has to decode it via mbstowcs. The problem is that in the C locale tzname is an ANSI (1252) string while mbstowcs simply casts to wchar_t, which is the same as decoding as Latin-1. This works fine for "?" (U+00E9). But the right single quote character (U+2019) is "\x92" in 1252, and a simple cast maps it to the non-character U+0092. When the CRT's strftime encodes this back as an ANSI string, it maps U+0092 to the replacement character for 1252, a question mark. Similarly, time.tzname decodes the tzname ANSI strings using mbstowcs, with the same mismatch between LC_CTYPE and LC_TIME, resulting in the string "Est (heure d\x92?t?)" In summary, the problem is that LC_TIME uses ANSI in the C locale, while LC_CTYPE uses Latin-1. A workaround (in most cases) is to delay importing the time module until after setting LC_CTYPE (also setting LC_TIME should cover all cases). For example: >>> import sys, locale >>> 'time' in sys.modules False >>> locale.setlocale(locale.LC_CTYPE, '') 'French_France.1252' >>> import time >>> time.tzname ('Est', 'Est (heure d??t?)') >>> time.strftime('%Z') 'Est (heure d??t?)' Note that Unix Python 3 sets LC_CTYPE at startup, so doing the same on Windows would actually improve cross-platform consistency. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 00:10:18 2016 From: report at bugs.python.org (Emanuel Barry) Date: Wed, 29 Jun 2016 04:10:18 +0000 Subject: [issue26226] Various test suite failures on Windows In-Reply-To: <1453940751.65.0.882732529995.issue26226@psf.upfronthosting.co.za> Message-ID: <1467173418.94.0.835599630886.issue26226@psf.upfronthosting.co.za> Emanuel Barry added the comment: That is good to know, thanks Eryk for the explanation! I also think making Python set LC_CTYPE on startup on Windows would be good. Martin's comment got me wondering, so I'm going to try to see if all modules properly got re-compiled, and re-run tests. I'll also run test_distutils through the command line to see if it passes. Following that, I'll branch off the relevant issues; and hopefully close this one too (I realize that it started going in all directions, it's hard to keep track even for me now). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 01:00:26 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 29 Jun 2016 05:00:26 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1467176426.31.0.624790193146.issue17911@psf.upfronthosting.co.za> Martin Panter added the comment: Robert: in issue17911-2.patch (and the eventual commit) you added a check for value == 'None' in _format_final_exc_line(). Why was this necessary? I think it is the cause of my Issue 27348 regression: >>> traceback.format_exception(Exception, Exception("One"), None) ['Exception: One\n'] >>> traceback.format_exception(Exception, Exception("None"), None) ['Exception\n'] ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 01:00:41 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 29 Jun 2016 05:00:41 +0000 Subject: [issue27348] traceback (and threading) drops exception message In-Reply-To: <1466261856.58.0.470780414166.issue27348@psf.upfronthosting.co.za> Message-ID: <1467176441.63.0.607018973807.issue27348@psf.upfronthosting.co.za> Martin Panter added the comment: I traced this back to revision 73afda5a4e4c (Issue 17911), which includes this change to traceback._format_final_exc_line(): -if value is None or not valuestr: +if value == 'None' or value is None or not valuestr: ---------- components: +Library (Lib) keywords: +3.5regression title: Non-main thread exception handler drops exception message -> traceback (and threading) drops exception message type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 01:01:27 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 29 Jun 2016 05:01:27 +0000 Subject: [issue27410] DLL hijacking vulnerability in Python 3.5.2 installer In-Reply-To: <1467172244.73.0.493856628502.issue27410@psf.upfronthosting.co.za> Message-ID: <1467176487.94.0.158530800875.issue27410@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 02:37:57 2016 From: report at bugs.python.org (Steve Piercy) Date: Wed, 29 Jun 2016 06:37:57 +0000 Subject: [issue27285] Document the deprecation of pyvenv in favor of `python3 -m venv` In-Reply-To: <1465544944.16.0.549761687921.issue27285@psf.upfronthosting.co.za> Message-ID: <1467182277.85.0.905832650991.issue27285@psf.upfronthosting.co.za> Steve Piercy added the comment: After looking into this issue, I need guidance to better define scope and intent, and how to go about submitting the changes. I found 81 occurrences of the term `pyvenv` in the documentation, either in reST files or docstrings, across about a dozen files. 1. Should I obliterate any mention of `pyvenv` (excluding HISTORY and whatsnew) or preserve a mention or two of it? For example, "`pyvenv` was the recommended tool for creating virtual environments for Python 3.3 and 3.4, and is deprecated in Python 3.6. Beginning in Python 3.5, the use of `venv` is recommended." 2. Is it preferred to submit one patch for all edited files, or one patch per edited file? TIA for any guidance. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 02:43:02 2016 From: report at bugs.python.org (Christian Ullrich) Date: Wed, 29 Jun 2016 06:43:02 +0000 Subject: [issue27410] DLL hijacking vulnerability in Python 3.5.2 installer In-Reply-To: <1467172244.73.0.493856628502.issue27410@psf.upfronthosting.co.za> Message-ID: <1467182582.31.0.418410148842.issue27410@psf.upfronthosting.co.za> Changes by Christian Ullrich : ---------- nosy: +Christian.Ullrich _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 04:36:16 2016 From: report at bugs.python.org (Lev Maximov) Date: Wed, 29 Jun 2016 08:36:16 +0000 Subject: [issue26844] Wrong error message during import In-Reply-To: <1461564546.15.0.190869698481.issue26844@psf.upfronthosting.co.za> Message-ID: <1467189376.65.0.841871781437.issue26844@psf.upfronthosting.co.za> Lev Maximov added the comment: Nevermind. It's not urgent but should definitely be fixed some day. Yes, __qualname__ might be a good idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 04:51:47 2016 From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=) Date: Wed, 29 Jun 2016 08:51:47 +0000 Subject: [issue27363] Complex with negative zero imaginary part In-Reply-To: <1466535728.31.0.514028528898.issue27363@psf.upfronthosting.co.za> Message-ID: <1467190307.51.0.922058906707.issue27363@psf.upfronthosting.co.za> Vedran ?a?i? added the comment: And of course, the most important argument that preserving type(x)(repr(x))==x is futile: try it with x=False. (Yes, bools are numbers too.:) On the other hand, of course, literal_eval treats 'False' completely fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 05:56:27 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 29 Jun 2016 09:56:27 +0000 Subject: [issue27348] traceback (and threading) drops exception message In-Reply-To: <1466261856.58.0.470780414166.issue27348@psf.upfronthosting.co.za> Message-ID: <1467194187.65.0.791481870861.issue27348@psf.upfronthosting.co.za> Martin Panter added the comment: If I remove the value == 'None' check, there are two failures in the test suite: 1. test_decimal fails, but only because the test was changed in revision 5f3dd0a2b1ab to accommodate the very bug I am complaining about. IMO this was a case of ?fixing? the test instead of fixing the bug, so it is okay to restore the test. 2. The following test, added in revision ecaafc32c500: def test_without_exception(self): err = traceback.format_exception_only(None, None) self.assertEqual(err, ['None\n']) It was apparently added so that print_exc() would output ?None? when called with no exception set. This is the case for Python 2. However in the Python 3 versions I have tried, print_exc() either raises AttributeError or prints ?NoneType?. In any case, the test does not seem to be testing anything valid according to the documentation, so I propose to remove it. ---------- keywords: +patch nosy: +rbcollins stage: -> patch review Added file: http://bugs.python.org/file43577/none-message.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 05:57:04 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 29 Jun 2016 09:57:04 +0000 Subject: [issue27411] Possible different behaviour of explicit and implicit __dict__ accessing when involving builtin types' __dict__ descriptors Message-ID: <1467194224.29.0.874639254683.issue27411@psf.upfronthosting.co.za> New submission from Xiang Zhang: Usually when we access an object's __dict__, it will finally reach subtype_dict[0]. When involving builtin base, it may delegates to the base's __dict__ descriptor. In such a case, it is possible for the __dict__ descriptor to initialize the dict object if it's NULL. This is what PyObject_GenericGetDict does. But if the __dict__ descriptor initialize dict to other mapping objects instead of dict object, accessing __dict__ explicitly first or implicitly by attribute setting will result in different behaviours. If we first access obj.__dict__, obj.__dict__ will set to the mapping object, otherwise it will be set to a dict. Let's make a example. For convenience I alter BaseException's __dict__ descriptor, changing PyObject_GenericGetDict to custom_getdict: PyObject * custom_getdict(PyObject *obj, void *context) { PyObject *dict, **dictptr = _PyObject_GetDictPtr(obj); dict = *dictptr; if (dict == NULL) { *dictptr = dict = PyDict_New(); PyDict_SetItemString(dict, "test", PyDict_New()); } Py_XINCREF(dict); return dict; } And then the use case: >>> BaseException().__dict__ {'test': {}} >>> class A: ... pass ... >>> class B(A, BaseException): ... def __init__(self): ... self.__dict__['a'] = 1 ... self.b = 2 ... >>> class C(A, BaseException): ... def __init__(self): ... self.a = 1 ... self.__dict__['b'] = 2 ... >>> B().__dict__ {'b': 2, 'test': {}, 'a': 1} >>> C().__dict__ {'a': 1, 'b': 2} Since a and b are not descriptors, I think B().__dict__ and C().__dict__ should lead to same result but they are not. I think it's because PyObject_GenericSetAttr doesn't go the same way as subtype_dict so when it finds __dict__ is not initialized it always assign it a new dict. I am not sure this is a bug or a case worth fixing or is designed deliberately. BTW, subtype_dict was introduced in [1]. [0] https://hg.python.org/cpython/file/tip/Objects/typeobject.c#l2069 [1] http://bugs.python.org/issue1303614 ---------- components: Interpreter Core messages: 269470 nosy: rhettinger, serhiy.storchaka, xiang.zhang priority: normal severity: normal status: open title: Possible different behaviour of explicit and implicit __dict__ accessing when involving builtin types' __dict__ descriptors type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 06:08:58 2016 From: report at bugs.python.org (Robert Collins) Date: Wed, 29 Jun 2016 10:08:58 +0000 Subject: [issue27348] traceback (and threading) drops exception message In-Reply-To: <1466261856.58.0.470780414166.issue27348@psf.upfronthosting.co.za> Message-ID: <1467194938.34.0.220848893136.issue27348@psf.upfronthosting.co.za> Robert Collins added the comment: hmm, can you give me a change to page this in? I'm pretty sure I saw breakage in external libraries prompting me to add the test and fix. I'd rather not recause that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 06:09:09 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 29 Jun 2016 10:09:09 +0000 Subject: [issue27348] traceback (and threading) drops exception message In-Reply-To: <1466261856.58.0.470780414166.issue27348@psf.upfronthosting.co.za> Message-ID: <1467194949.55.0.0171591136823.issue27348@psf.upfronthosting.co.za> STINNER Victor added the comment: I agree that ignoring the exception message if str(exc) == 'None' is wrong. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 06:18:51 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 29 Jun 2016 10:18:51 +0000 Subject: [issue27348] traceback (and threading) drops exception message In-Reply-To: <1466261856.58.0.470780414166.issue27348@psf.upfronthosting.co.za> Message-ID: <1467195531.06.0.249516086982.issue27348@psf.upfronthosting.co.za> Martin Panter added the comment: Yeah sure I can give you a chance to consider this (I assume you meant ?chance? :). But neither of the tests I mentioned were added by you as far as I know. Maybe you are thinking of some other test. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 06:36:51 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 29 Jun 2016 10:36:51 +0000 Subject: [issue26721] Avoid socketserver.StreamRequestHandler.wfile doing partial writes In-Reply-To: <1460204395.72.0.250418211057.issue26721@psf.upfronthosting.co.za> Message-ID: <20160629103648.23391.64581.9C9D079F@psf.io> Roundup Robot added the comment: New changeset 4ea79767ff75 by Martin Panter in branch 'default': Issue #26721: Change StreamRequestHandler.wfile to BufferedIOBase https://hg.python.org/cpython/rev/4ea79767ff75 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 07:26:37 2016 From: report at bugs.python.org (David Howlett) Date: Wed, 29 Jun 2016 11:26:37 +0000 Subject: =?utf-8?b?W2lzc3VlMjc0MTJdIGZsb2F0KCfiiJ4nKSByZXR1cm5zIDguMA==?= Message-ID: <1467199597.93.0.168166235932.issue27412@psf.upfronthosting.co.za> New submission from David Howlett: float('inf') returns a float with a value of inf float('?') returns a float with a value of 8.0 I can't think of any justification for returning 8.0 other then ? looks like an 8 turned sideways. I believe float('?') should return inf. ---------- components: Unicode messages: 269475 nosy: David Howlett, ezio.melotti, haypo priority: normal severity: normal status: open title: float('?') returns 8.0 type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 07:33:17 2016 From: report at bugs.python.org (John Hagen) Date: Wed, 29 Jun 2016 11:33:17 +0000 Subject: [issue26988] Add AutoNumberedEnum to stdlib In-Reply-To: <1462844071.91.0.106881823757.issue26988@psf.upfronthosting.co.za> Message-ID: <1467199997.63.0.795848073908.issue26988@psf.upfronthosting.co.za> John Hagen added the comment: @Ethan/Barry what needs to be done now to accept or reject this for Python 3.6? Should I propose it onto python-dev? If accepted, would be nice to get it in before alpha 3 (~2 weeks). What's nice about this proposal is Ethan has already written the code, so it's just a matter of getting consensus to add it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 07:43:54 2016 From: report at bugs.python.org (Ashwini Chaudhary) Date: Wed, 29 Jun 2016 11:43:54 +0000 Subject: =?utf-8?b?W2lzc3VlMjc0MTJdIGZsb2F0KCfiiJ4nKSByZXR1cm5zIDguMA==?= In-Reply-To: <1467199597.93.0.168166235932.issue27412@psf.upfronthosting.co.za> Message-ID: <1467200634.84.0.442138431674.issue27412@psf.upfronthosting.co.za> Ashwini Chaudhary added the comment: float('?') raised ValueError as expected: ValueError: could not convert string to float: '?' I am not sure how you ended up with 8.0. ---------- nosy: +ashwch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 07:47:28 2016 From: report at bugs.python.org (Eryk Sun) Date: Wed, 29 Jun 2016 11:47:28 +0000 Subject: =?utf-8?b?W2lzc3VlMjc0MTJdIGZsb2F0KCfiiJ4nKSByZXR1cm5zIDguMA==?= In-Reply-To: <1467199597.93.0.168166235932.issue27412@psf.upfronthosting.co.za> Message-ID: <1467200848.55.0.29013574414.issue27412@psf.upfronthosting.co.za> Eryk Sun added the comment: There's something wrong with however you're testing this. >>> s = '\N{infinity}' >>> s == '?' == '\u221e' True '?' isn't numeric. It's a math symbol (Sm): >>> unicodedata.category(s) 'Sm' >>> s.isdecimal() False >>> s.isdigit() False So float('?') should raise a ValueError: >>> float(s) Traceback (most recent call last): File "", line 1, in ValueError: could not convert string to float: '?' ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 07:49:29 2016 From: report at bugs.python.org (Wei-Cheng Pan) Date: Wed, 29 Jun 2016 11:49:29 +0000 Subject: [issue27413] Add an option to json.tool to bypass non-ASCII characters. Message-ID: <1467200969.47.0.983958211319.issue27413@psf.upfronthosting.co.za> New submission from Wei-Cheng Pan: This patch adds a command line option "--no-escape" that allows json.tool to display non-ASCII characters. e.g.: $ echo '"??"' | python -m json.tool "\u6e2c\u8a66" $ echo '"??"' | python -m json.tool --no-escape "??" ---------- components: Library (Lib) files: json-add-an-option-to-bypass-non-ascii-characters.patch keywords: patch messages: 269479 nosy: Wei-Cheng.Pan priority: normal severity: normal status: open title: Add an option to json.tool to bypass non-ASCII characters. type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43578/json-add-an-option-to-bypass-non-ascii-characters.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 08:06:10 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 29 Jun 2016 12:06:10 +0000 Subject: =?utf-8?b?W2lzc3VlMjc0MTJdIGZsb2F0KCfiiJ4nKSByZXR1cm5zIDguMA==?= In-Reply-To: <1467199597.93.0.168166235932.issue27412@psf.upfronthosting.co.za> Message-ID: <1467201970.55.0.41392661113.issue27412@psf.upfronthosting.co.za> STINNER Victor added the comment: On Windows, the ? character (U+221E) is replaced with the letter 8 (U+0038) by the WideCharToMultiByte() function for most code pages: http://unicodebook.readthedocs.io/operating_systems.html#encode-and-decode-functions Can you please describe how and where you typed the ? character? Are you testing on Windows? What is your Python version? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 08:06:14 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 29 Jun 2016 12:06:14 +0000 Subject: [issue26721] Avoid socketserver.StreamRequestHandler.wfile doing partial writes In-Reply-To: <1460204395.72.0.250418211057.issue26721@psf.upfronthosting.co.za> Message-ID: <1467201974.35.0.205507550008.issue26721@psf.upfronthosting.co.za> Martin Panter added the comment: Committed for 3.6. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 08:19:28 2016 From: report at bugs.python.org (Eryk Sun) Date: Wed, 29 Jun 2016 12:19:28 +0000 Subject: [issue27410] DLL hijacking vulnerability in Python 3.5.2 installer In-Reply-To: <1467172244.73.0.493856628502.issue27410@psf.upfronthosting.co.za> Message-ID: <1467202768.33.0.36137603097.issue27410@psf.upfronthosting.co.za> Eryk Sun added the comment: > installer attempts to load DLLs from the current directory It's actually the application directory that's the culprit, not the current directory. All supported versions of Windows default to SafeDllSearchMode, which moves the current directory after system directories. However, the loader (and also the CreateProcess family) default to searching the application directory before system directories. Known DLLs [1] aren't vulnerable, and AFAIK neither are DLLs loaded from system API Sets, which is typically how ucrtbase.dll gets loaded. The problem could be worked around by calling SetDefaultDllDirectories (requires KB2533623 prior to Windows 8) to disable searching the application directory. For static imports, I suppose one could delay loading them until after SetDefaultDllDirectories is called. There should really be a way to control this behavior in the application manifest. Giving the application directory priority when looking for DLLs and EXEs is fine for securely installed applications, but not for installers and the like. [1] HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs ---------- components: +Windows nosy: +eryksun, paul.moore, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 09:18:49 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jun 2016 13:18:49 +0000 Subject: [issue26844] Wrong error message during import In-Reply-To: <1461564546.15.0.190869698481.issue26844@psf.upfronthosting.co.za> Message-ID: <1467206329.2.0.554629092717.issue26844@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: __qualname__ itself is not much more informative than __name__. You should use it together with __module__ to get the full qualified name. But 1) it is never used in error messages, 2) the code becomes more verbose, 3) the output becomes more verbose, and excessive verbose for builtin types. __name__ LGTM. It is enough to identify the error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 09:19:50 2016 From: report at bugs.python.org (David Howlett) Date: Wed, 29 Jun 2016 13:19:50 +0000 Subject: =?utf-8?b?W2lzc3VlMjc0MTJdIGZsb2F0KCfiiJ4nKSByZXR1cm5zIDguMA==?= In-Reply-To: <1467199597.93.0.168166235932.issue27412@psf.upfronthosting.co.za> Message-ID: <1467206390.78.0.640427353879.issue27412@psf.upfronthosting.co.za> David Howlett added the comment: I am using python 3.5 in a REPL in an IDE called Komodo running on Windows. After reading your comments I wrote the following python file: try: x = float('?') except ValueError: print('Value error was correctly thrown') This throws a ValueError as you describe. I get the following behaviour in powershell and cmd.exe: >>> float('\u221e') Traceback (most recent call last): File "", line 1, in ValueError: could not convert string to float: '\u221e' In the Komodo REPL I see the following behaviour: >>> '?' '8' >>> '\u221e' '\u221e' I now believe the issue is with how Komodo reads in characters from its REPL. In the course of testing I also found out that the REPL in Komodo suffers and internal fault whenever it tries to print '?' in a debug message. Unless someone objects I will close this issue in the Python bug tracker and open a new issue in the Komodo bug tracker. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 09:23:03 2016 From: report at bugs.python.org (Eryk Sun) Date: Wed, 29 Jun 2016 13:23:03 +0000 Subject: =?utf-8?b?W2lzc3VlMjc0MTJdIGZsb2F0KCfiiJ4nKSByZXR1cm5zIDguMA==?= In-Reply-To: <1467199597.93.0.168166235932.issue27412@psf.upfronthosting.co.za> Message-ID: <1467206583.89.0.706873605954.issue27412@psf.upfronthosting.co.za> Changes by Eryk Sun : ---------- resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 09:28:05 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 29 Jun 2016 13:28:05 +0000 Subject: =?utf-8?b?W2lzc3VlMjc0MTJdIGZsb2F0KCfiiJ4nKSByZXR1cm5zIDguMA==?= In-Reply-To: <1467199597.93.0.168166235932.issue27412@psf.upfronthosting.co.za> Message-ID: <1467206885.02.0.272777124327.issue27412@psf.upfronthosting.co.za> STINNER Victor added the comment: """ In the Komodo REPL I see the following behaviour: >>> '?' '8' """ Ok, it's now obvious that the issue comes from Komodo REPL, not from Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 09:30:35 2016 From: report at bugs.python.org (Jim Fulton) Date: Wed, 29 Jun 2016 13:30:35 +0000 Subject: [issue27386] Asyncio server hang when clients connect and immediately disconnect In-Reply-To: <1466888194.59.0.640833210662.issue27386@psf.upfronthosting.co.za> Message-ID: <1467207035.28.0.21463268623.issue27386@psf.upfronthosting.co.za> Jim Fulton added the comment: This is already pretty minimal. There are no external dependencies. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 09:34:19 2016 From: report at bugs.python.org (Jim Fulton) Date: Wed, 29 Jun 2016 13:34:19 +0000 Subject: [issue27391] server_hostname should only be required when checking host names In-Reply-To: <1466955837.8.0.0746303655033.issue27391@psf.upfronthosting.co.za> Message-ID: <1467207259.73.0.15265470919.issue27391@psf.upfronthosting.co.za> Jim Fulton added the comment: It's not bug, it's a misfeature, IMO. If you pass an SSL context and either don't pass a hostname or pass an empty string, then server_hostname is required, even if check_hostname is false for the context. The fix is trivial. I'd be happy to provide a PR. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 09:34:36 2016 From: report at bugs.python.org (Mathieu Xhonneux) Date: Wed, 29 Jun 2016 13:34:36 +0000 Subject: [issue27414] http.server.BaseHTTPRequestHandler inconsistence with Content-Length value Message-ID: <1467207276.94.0.887561217469.issue27414@psf.upfronthosting.co.za> New submission from Mathieu Xhonneux: With Python 3.5, when I subclass SimpleHTTPRequestHandler, which itself subclasses BaseHTTPRequestHandler, and I try to access a non-existing file, the server responds with a 404 code, but send_error (see Lib/http/server.py, line 473) adds the Content-Length header with an int value, whereas all others functions convert this value to str (see lines 699, 761). For consistency, all header values should be str. ---------- components: Library (Lib) messages: 269488 nosy: m.xhonneux priority: normal severity: normal status: open title: http.server.BaseHTTPRequestHandler inconsistence with Content-Length value type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 09:35:21 2016 From: report at bugs.python.org (Steve Dower) Date: Wed, 29 Jun 2016 13:35:21 +0000 Subject: [issue27410] DLL hijacking vulnerability in Python 3.5.2 installer In-Reply-To: <1467172244.73.0.493856628502.issue27410@psf.upfronthosting.co.za> Message-ID: <1467207321.11.0.414510319834.issue27410@psf.upfronthosting.co.za> Steve Dower added the comment: Unless you can show that it's loaded after the installer elevates, I'm not concerned. "User can run arbitrary code as themselves" is not a security vulnerability. (Hint: when the bundle elevates, it copies the exe to a new directory and runs it from there to avoid this issue.) I'll leave this open for a few days in case of more comments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 09:36:38 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Wed, 29 Jun 2016 13:36:38 +0000 Subject: [issue27386] Asyncio server hang when clients connect and immediately disconnect In-Reply-To: <1466888194.59.0.640833210662.issue27386@psf.upfronthosting.co.za> Message-ID: <1467207398.11.0.55039266289.issue27386@psf.upfronthosting.co.za> ???? ????????? added the comment: Plese reduce even more. I mean remove debugging, specifi commands, and all extra code, that is not related to original problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 09:36:38 2016 From: report at bugs.python.org (Mathieu Xhonneux) Date: Wed, 29 Jun 2016 13:36:38 +0000 Subject: [issue27414] http.server.BaseHTTPRequestHandler inconsistence with Content-Length value In-Reply-To: <1467207276.94.0.887561217469.issue27414@psf.upfronthosting.co.za> Message-ID: <1467207398.52.0.174489365621.issue27414@psf.upfronthosting.co.za> Mathieu Xhonneux added the comment: It's line 469 in the latest Lib/http/server.py (and not 473). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 09:40:10 2016 From: report at bugs.python.org (Jim Fulton) Date: Wed, 29 Jun 2016 13:40:10 +0000 Subject: [issue27392] Add a server_side keyword parameter to create_connection In-Reply-To: <1466957117.0.0.423625085233.issue27392@psf.upfronthosting.co.za> Message-ID: <1467207610.84.0.0371376607699.issue27392@psf.upfronthosting.co.za> Jim Fulton added the comment: Tests are also unstable with uvloop. (Although uvloop doesn't have http://bugs.python.org/issue27386 at least.) I was eventually able to wrestle the test into submission using asyncio.Server. I suspect that some of this had to do with issues closing connections at the end of tests. I made my close logic more paranoid and that *seemed* to help. Some of the instability was due to test bugs that were activated by the different timing characteristics of using asyncio.Server. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 09:56:57 2016 From: report at bugs.python.org (Jim Fulton) Date: Wed, 29 Jun 2016 13:56:57 +0000 Subject: [issue27392] Add a server_side keyword parameter to create_connection In-Reply-To: <1466957117.0.0.423625085233.issue27392@psf.upfronthosting.co.za> Message-ID: <1467208617.65.0.407826469958.issue27392@psf.upfronthosting.co.za> Jim Fulton added the comment: Guido, IMO, there's value in having the ability to accept connections independently of handling them. It wasn't clear to me from reading the documentation that create_connection is only meant for making client connections, especially given that it can take an already connected socket. It works well for non-SSL server sockets and would work for SSL with a trivial change. This issue was discussed on the tulip list or issue tracker a couple of years ago. (Sorry, I can't find the link ATM.) I think it was dismissed because no one felt like looking into it and because you asserted that it makes no sense to use an async library when handling each connection in a separate thread. IMO, async loop is useful even for a single connection when reading and writing are not purely synchronous. In ZEO it's very useful that that the server can send data to a client independent of requests the client is making. (Technically, under the hood this often means that there are really 2 I/O channels, the client's TCP connection and whatever mechanism the loop uses to allow itself to be woken asynchronously as in call_soon_threadsafe.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 10:01:28 2016 From: report at bugs.python.org (Jim Fulton) Date: Wed, 29 Jun 2016 14:01:28 +0000 Subject: [issue27392] Add a server_side keyword parameter to create_connection In-Reply-To: <1466957117.0.0.423625085233.issue27392@psf.upfronthosting.co.za> Message-ID: <1467208888.59.0.901889980287.issue27392@psf.upfronthosting.co.za> Jim Fulton added the comment: I agree that if create_server (or asyncio.Server) is buggy, it should be fixed! However, IMO, it's useful to be able to accept a connection outside of an asyncio event loop and then hand the loop the connected socket. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 10:04:26 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 29 Jun 2016 14:04:26 +0000 Subject: [issue27285] Document the deprecation of pyvenv in favor of `python3 -m venv` In-Reply-To: <1465544944.16.0.549761687921.issue27285@psf.upfronthosting.co.za> Message-ID: <1467209066.56.0.919736270365.issue27285@psf.upfronthosting.co.za> R. David Murray added the comment: In this case I think one patch is good. The deprecation should mention pyvenv in the main venv docs (and maybe installing), but probably nowhere else. See the deprecated-removed sphinx tag. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 10:09:01 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 29 Jun 2016 14:09:01 +0000 Subject: [issue27363] Complex with negative zero imaginary part In-Reply-To: <1466535728.31.0.514028528898.issue27363@psf.upfronthosting.co.za> Message-ID: <1467209341.37.0.757588764459.issue27363@psf.upfronthosting.co.za> R. David Murray added the comment: Right, that isn't the invariant. Eval is the normal invariant, but not all classes *can* meet it, in which case if they can provide a repr that *can* be turned back into the value losslessly somehow, that's better than not doing so at all. Still, changing the repr would be the best way to meet the desired invariant, if we're willing to do that. This could be the first stdlib case of a non-string having a useful __str__ if we make the __str__ still return what the current __repr__ does. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 10:14:31 2016 From: report at bugs.python.org (Rolf Krahl) Date: Wed, 29 Jun 2016 14:14:31 +0000 Subject: [issue12319] [http.client] HTTPConnection.request not support "chunked" Transfer-Encoding to send data In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za> Message-ID: <1467209671.55.0.791039647909.issue12319@psf.upfronthosting.co.za> Rolf Krahl added the comment: Here comes a new version of the patch. I believe, I addressed all review comments made on issue12319_7.patch, with the exception of the EncodingError mentioned in the last post. Most relevant changes compared to last patch: * Do not try to dertermine the content length for text files. * Change priority of object types for the body: try file like before byte like. * Convert byte like to bytes before feeding the body into the socket. This fixes Issue 27340, at least as far as http.client is concerned. * Split test_http() in one separate test for each body type in test_urllib2.py. * Review documentation. Another question is: what is the best method to test whether a file like is text or binary? For the moment, I kept the original code that essentially does: try: isText = "b" not in readable.mode except AttributeError: isText = False This logic fails for StringIO and possibly others. Alternatives could be: isText = isinstance(readable, io.TextIOBase) isText = hasattr(readable, 'encoding') or isText = isinstance(readable.read(0), str) What do you guys suggest? ---------- Added file: http://bugs.python.org/file43579/issue12319_8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 10:15:50 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 29 Jun 2016 14:15:50 +0000 Subject: [issue27413] Add an option to json.tool to bypass non-ASCII characters. In-Reply-To: <1467200969.47.0.983958211319.issue27413@psf.upfronthosting.co.za> Message-ID: <1467209750.63.0.250459535351.issue27413@psf.upfronthosting.co.za> R. David Murray added the comment: Maybe name it --no-insure-ascii? Or --insure-ascii=no/yes. (or true/false). ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 10:17:21 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 29 Jun 2016 14:17:21 +0000 Subject: [issue27414] http.server.BaseHTTPRequestHandler inconsistence with Content-Length value In-Reply-To: <1467207276.94.0.887561217469.issue27414@psf.upfronthosting.co.za> Message-ID: <1467209841.45.0.660028883736.issue27414@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- nosy: +ezio.melotti, pitrou, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 10:21:00 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 29 Jun 2016 14:21:00 +0000 Subject: [issue27391] server_hostname should only be required when checking host names In-Reply-To: <1466955837.8.0.0746303655033.issue27391@psf.upfronthosting.co.za> Message-ID: <1467210060.63.0.301549068152.issue27391@psf.upfronthosting.co.za> R. David Murray added the comment: You still haven't told me what you are passing the context to that objects to not having server_hostname. I suppose the asyncio experts would know immediately, so I should probably just leave it to them...or wait for your PR. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 10:21:39 2016 From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=) Date: Wed, 29 Jun 2016 14:21:39 +0000 Subject: [issue27363] Complex with negative zero imaginary part In-Reply-To: <1466535728.31.0.514028528898.issue27363@psf.upfronthosting.co.za> Message-ID: <1467210099.55.0.50239453039.issue27363@psf.upfronthosting.co.za> Vedran ?a?i? added the comment: ...but hopefully not the last. People are playing (with BDFL's blessing) with the idea of types having just (qual)name as str. By "first stdlib case" you mean "first builtin case", right? fractions.Fraction and decimal.Decimal are in stdlib. :-) Yes, not all classes can (nor should) support the strong "literal_eval being left-inverse of repr" invariant, but IMO builtin value-like (having a meaningful ==/hash infrastructure separate from identity) classes should. Numbers are surely in that camp. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 10:30:29 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 29 Jun 2016 14:30:29 +0000 Subject: [issue27414] http.server.BaseHTTPRequestHandler inconsistence with Content-Length value In-Reply-To: <1467207276.94.0.887561217469.issue27414@psf.upfronthosting.co.za> Message-ID: <1467210629.6.0.0969162545265.issue27414@psf.upfronthosting.co.za> R. David Murray added the comment: For reference, the changeset that introduced that was ee34cb049a10. An interesting feature of that changset is the trace command in the test...I guess the wrong patch was comitted and no one noticed. The trace was obvious fixed but no one appears to have noticed the int problem, presumably because it gets converted to string before being emitted. Would you be interested in trying to write a test that will detect this, to go along with the trivial fix? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 10:33:14 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 29 Jun 2016 14:33:14 +0000 Subject: [issue27414] http.server.BaseHTTPRequestHandler inconsistence with Content-Length value In-Reply-To: <1467207276.94.0.887561217469.issue27414@psf.upfronthosting.co.za> Message-ID: <1467210794.65.0.991419322013.issue27414@psf.upfronthosting.co.za> R. David Murray added the comment: Sorry once again for the infelicitous phrasing. I meant to say "sorry, what I was unclearly asking for was what you were calling that..." Too bad I don't drink coffee or I could blame it on not having had any yet today... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 10:36:01 2016 From: report at bugs.python.org (Jim Fulton) Date: Wed, 29 Jun 2016 14:36:01 +0000 Subject: [issue27391] server_hostname should only be required when checking host names In-Reply-To: <1466955837.8.0.0746303655033.issue27391@psf.upfronthosting.co.za> Message-ID: <1467210961.11.0.691767991117.issue27391@psf.upfronthosting.co.za> Jim Fulton added the comment: I'm not sure I understand your question. The documentation for create_connection, https://docs.python.org/3/library/asyncio-eventloop.html#creating-connections states that server_hostname is required if the host is empty. (I'm generalizing "empty" to include None.) SSL contexts, https://docs.python.org/3/library/ssl.html#ssl-contexts, have an attribute, check_hostname, which controls whether hostname checking is required. If set to false in a context passed to create_connection, then it makes no sense to require server_hostname under any circumstances. Note that this is easy to work around by passing an empty string, it just seems pointless to make people do that if you're already controlling this via the SSL context. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 10:37:13 2016 From: report at bugs.python.org (David Howlett) Date: Wed, 29 Jun 2016 14:37:13 +0000 Subject: =?utf-8?b?W2lzc3VlMjc0MTJdIGZsb2F0KCfiiJ4nKSByZXR1cm5zIDguMA==?= In-Reply-To: <1467199597.93.0.168166235932.issue27412@psf.upfronthosting.co.za> Message-ID: <1467211033.84.0.652605073436.issue27412@psf.upfronthosting.co.za> David Howlett added the comment: I am sorry about misattributing this bug and wasting your time. I have opened two new bugs against Komodo: https://github.com/Komodo/KomodoEdit/issues/1760 https://github.com/Komodo/KomodoEdit/issues/1759 They are looking into it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 10:37:58 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 29 Jun 2016 14:37:58 +0000 Subject: [issue27363] Complex with negative zero imaginary part In-Reply-To: <1466535728.31.0.514028528898.issue27363@psf.upfronthosting.co.za> Message-ID: <1467211078.97.0.85062101066.issue27363@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, I haven't used Fractions and Decimal much, so I hadn't noticed. Those postdate complex, I think, but do follow the model Mark is suggesting. Seems like it would be reasonble to make complex do the same...the concern of course is backward compatibilty. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 10:38:45 2016 From: report at bugs.python.org (Jim Fulton) Date: Wed, 29 Jun 2016 14:38:45 +0000 Subject: [issue27391] server_hostname should only be required when checking host names In-Reply-To: <1466955837.8.0.0746303655033.issue27391@psf.upfronthosting.co.za> Message-ID: <1467211125.95.0.241205922494.issue27391@psf.upfronthosting.co.za> Jim Fulton added the comment: Consider this a suggestion. Do with it what you will. I'm closing this as I don't want to spend more time on it other than creating a PR if requested. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 10:44:23 2016 From: report at bugs.python.org (ppperry) Date: Wed, 29 Jun 2016 14:44:23 +0000 Subject: [issue26686] email.parser stops parsing headers too soon when given a defective message. In-Reply-To: <1459532790.12.0.415003614976.issue26686@psf.upfronthosting.co.za> Message-ID: <1467211463.4.0.856741392093.issue26686@psf.upfronthosting.co.za> Changes by ppperry : ---------- title: email.parser stops parsing headers too soon. -> email.parser stops parsing headers too soon when given a defective message. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 10:46:01 2016 From: report at bugs.python.org (Marcus Cobden) Date: Wed, 29 Jun 2016 14:46:01 +0000 Subject: [issue27415] BaseEventLoop.create_server does not accept port=None Message-ID: <1467211561.08.0.329801464417.issue27415@psf.upfronthosting.co.za> New submission from Marcus Cobden: With the most recent 3.4 bugfix, calling create_server with port=None stopped working. This also affects 3.5, and I would imagine also 3.6, but haven't checked that. Test case: import asyncio; l = asyncio.get_event_loop(); l.run_until_complete(l.create_server(lambda: None, host='0.0.0.0', port=None)) Expected result: a socket object Broken result: "TypeError: an integer is required (got type NoneType)" ---------- components: asyncio messages: 269507 nosy: gvanrossum, haypo, mcobden, yselivanov priority: normal severity: normal status: open title: BaseEventLoop.create_server does not accept port=None versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 10:46:32 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 29 Jun 2016 14:46:32 +0000 Subject: [issue27391] server_hostname should only be required when checking host names In-Reply-To: <1466955837.8.0.0746303655033.issue27391@psf.upfronthosting.co.za> Message-ID: <1467211592.54.0.625341832227.issue27391@psf.upfronthosting.co.za> R. David Murray added the comment: Sorry, I've been having trouble communicating on this ticket. I thought I'd posetd an apology but I don't see it...I wonder where I did post it? Bad morning :(. Anyway, create_connection was what I was asking for. Reading the docs, I, at least, agree with you, and if it weren't for backward compatibility I'd suggest making the only way to disable host checking be by passing a context with it disabled. But failing that I don't see any reason to force you to specify a hostname if you've already said you don't want to check hostnames. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 10:57:52 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 29 Jun 2016 14:57:52 +0000 Subject: [issue27391] server_hostname should only be required when checking host names In-Reply-To: <1466955837.8.0.0746303655033.issue27391@psf.upfronthosting.co.za> Message-ID: <1467212272.3.0.28643637322.issue27391@psf.upfronthosting.co.za> Yury Selivanov added the comment: > SSL contexts, https://docs.python.org/3/library/ssl.html#ssl-contexts, have an attribute, check_hostname, which controls whether hostname checking is required. If set to false in a context passed to create_connection, then it makes no sense to require server_hostname under any circumstances. This makes sense. I'm reopening this issue. Jim, would you be able to submit a PR to github/python/asyncio? ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 10:59:28 2016 From: report at bugs.python.org (Jim Fulton) Date: Wed, 29 Jun 2016 14:59:28 +0000 Subject: [issue27391] server_hostname should only be required when checking host names In-Reply-To: <1466955837.8.0.0746303655033.issue27391@psf.upfronthosting.co.za> Message-ID: <1467212368.04.0.428969229553.issue27391@psf.upfronthosting.co.za> Jim Fulton added the comment: No need to apologize! My capitulation was just due to the fact that this isn't a big deal. (My tone probably came across as cranky; sorry) WRT backward compatibility, I suspect that there's a bit of wiggle here between loop implementations and I doubt this would be noticed. For example, uvloop errors if you pass None for both server_hostname and ssl. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 11:00:20 2016 From: report at bugs.python.org (Jim Fulton) Date: Wed, 29 Jun 2016 15:00:20 +0000 Subject: [issue27391] server_hostname should only be required when checking host names In-Reply-To: <1466955837.8.0.0746303655033.issue27391@psf.upfronthosting.co.za> Message-ID: <1467212420.42.0.841863601599.issue27391@psf.upfronthosting.co.za> Jim Fulton added the comment: OK, sure, I'll make a PR. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 11:04:30 2016 From: report at bugs.python.org (Paul Killey) Date: Wed, 29 Jun 2016 15:04:30 +0000 Subject: [issue27416] typo / missing word in docs.python.org/2/library/copy.html Message-ID: <1467212670.04.0.257355516163.issue27416@psf.upfronthosting.co.za> New submission from Paul Killey: I wonder if the word 'not' is missing between 'that' and 'should' in this sentence in https://docs.python.org/2/library/copy.html? Because deep copy copies everything it may copy too much, e.g., administrative data structures that should be shared even between copies. ---------- assignee: docs at python components: Documentation messages: 269512 nosy: docs at python, paulkilley priority: normal severity: normal status: open title: typo / missing word in docs.python.org/2/library/copy.html versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 11:05:10 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 29 Jun 2016 15:05:10 +0000 Subject: [issue27392] Add a server_side keyword parameter to create_connection In-Reply-To: <1466957117.0.0.423625085233.issue27392@psf.upfronthosting.co.za> Message-ID: <1467212710.14.0.733442317541.issue27392@psf.upfronthosting.co.za> Yury Selivanov added the comment: > However, IMO, it's useful to be able to accept a connection outside of an asyncio event loop and then hand the loop the connected socket. Looks like what you're asking for is a way to wrap existing socket object into a (transport, protocol) pair. I'm -1 to add this new semantics to loop.create_connection, as I think it will complicate it too much. However, we can consider adding something like loop.wrap_socket(protocol_factory, sock) -> Transport ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 11:06:12 2016 From: report at bugs.python.org (Paul Killey) Date: Wed, 29 Jun 2016 15:06:12 +0000 Subject: [issue27416] typo / missing word in docs.python.org/2/library/copy.html In-Reply-To: <1467212670.04.0.257355516163.issue27416@psf.upfronthosting.co.za> Message-ID: <1467212772.09.0.369592644005.issue27416@psf.upfronthosting.co.za> Paul Killey added the comment: I'm sorry, 'not' could be missing between 'should' and 'be' --- 'should not be shared' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 11:10:02 2016 From: report at bugs.python.org (Jim Fulton) Date: Wed, 29 Jun 2016 15:10:02 +0000 Subject: [issue27392] Add a server_side keyword parameter to create_connection In-Reply-To: <1466957117.0.0.423625085233.issue27392@psf.upfronthosting.co.za> Message-ID: <1467213002.78.0.731490750991.issue27392@psf.upfronthosting.co.za> Jim Fulton added the comment: Yury, I'm curious what you think the socket argument to create_connection is about. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 11:12:10 2016 From: report at bugs.python.org (Jim Fulton) Date: Wed, 29 Jun 2016 15:12:10 +0000 Subject: [issue27392] Add a server_side keyword parameter to create_connection In-Reply-To: <1466957117.0.0.423625085233.issue27392@psf.upfronthosting.co.za> Message-ID: <1467213130.17.0.317981429489.issue27392@psf.upfronthosting.co.za> Jim Fulton added the comment: BTW, a problem with this proposal that I realized after submitting it is that it changes an API that has multiple implementations, including implementations outside of the Python codebase. Arguably, this would require a PEP, at which point the change is no-longer trivial. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 11:17:40 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Wed, 29 Jun 2016 15:17:40 +0000 Subject: [issue27386] Asyncio server hang when clients connect and immediately disconnect In-Reply-To: <1466888194.59.0.640833210662.issue27386@psf.upfronthosting.co.za> Message-ID: <1467213460.75.0.5616956938.issue27386@psf.upfronthosting.co.za> ???? ????????? added the comment: Also I recommend you to use asyncio streams, instead of reinventing wheels. So, reading your command will look like: data = await stream.read_exactly(4) (len,) = unpack(">I", data) command = await stream.read_exactly(len) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 11:20:08 2016 From: report at bugs.python.org (Jim Fulton) Date: Wed, 29 Jun 2016 15:20:08 +0000 Subject: [issue27386] Asyncio server hang when clients connect and immediately disconnect In-Reply-To: <1466888194.59.0.640833210662.issue27386@psf.upfronthosting.co.za> Message-ID: <1467213608.22.0.554045009494.issue27386@psf.upfronthosting.co.za> Jim Fulton added the comment: OK, I *was* able to simplify it a fair bit. I'm uploading a new version. I left prints in because I think you'd find them helpful, but I'll upload another version without prints. ---------- Added file: http://bugs.python.org/file43580/echo.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 11:20:23 2016 From: report at bugs.python.org (Jim Fulton) Date: Wed, 29 Jun 2016 15:20:23 +0000 Subject: [issue27386] Asyncio server hang when clients connect and immediately disconnect In-Reply-To: <1466888194.59.0.640833210662.issue27386@psf.upfronthosting.co.za> Message-ID: <1467213623.32.0.219913804967.issue27386@psf.upfronthosting.co.za> Changes by Jim Fulton : Removed file: http://bugs.python.org/file43540/echo.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 11:20:32 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 29 Jun 2016 15:20:32 +0000 Subject: [issue27392] Add a server_side keyword parameter to create_connection In-Reply-To: <1466957117.0.0.423625085233.issue27392@psf.upfronthosting.co.za> Message-ID: <1467213632.05.0.677615336646.issue27392@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Yury, I'm curious what you think the socket argument to create_connection is about. :) The current intended purpose of create_connection is to create a client connection. You're proposing to add a new argument -- server_side -- which I think will confuse the users of create_connection. What I'm saying is that we may consider creating a low-level loop.wrap_socket, which would be generic and suitable to be used for both client and server connections. We could even refactor create_connection to use wrap_socket when 'sock' argument is passed to it. We already have something similar, although it's a private API -- _make_socket_transport. > BTW, a problem with this proposal that I realized after submitting it is that it changes an API that has multiple implementations, including implementations outside of the Python codebase. Arguably, this would require a PEP, at which point the change is no-longer trivial. :) No need for a PEP; Guido's approval is enough usually. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 11:21:09 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Wed, 29 Jun 2016 15:21:09 +0000 Subject: [issue27386] Asyncio server hang when clients connect and immediately disconnect In-Reply-To: <1466888194.59.0.640833210662.issue27386@psf.upfronthosting.co.za> Message-ID: <1467213669.65.0.186190600278.issue27386@psf.upfronthosting.co.za> ???? ????????? added the comment: One more thing. Why you set socket.SO_LINGER ? and why lingering timeout is 0 seconds ? Removing that eliminate problem completely. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 11:22:04 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 29 Jun 2016 15:22:04 +0000 Subject: [issue26988] Add AutoNumberedEnum to stdlib In-Reply-To: <1462844071.91.0.106881823757.issue26988@psf.upfronthosting.co.za> Message-ID: <1467213724.9.0.907359391296.issue26988@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: I don't really think much more needs to be done other than agree on this tracker issue that it's something we want, and that Ethan's implementation is good enough. It's been a while since I looked that the code but it seemed good to me before, so if Ethan is happy with it going into the stdlib, so am I. As for the feature, it *is* a little magical, but not so much that it would be confusing or ambiguous, so I'm +1 on it. I'll defer to Ethan for the final decision, but if we have tests and documentation, I'd be very happy to see this in 3.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 11:23:59 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 29 Jun 2016 15:23:59 +0000 Subject: [issue27416] typo / missing word in docs.python.org/2/library/copy.html In-Reply-To: <1467212670.04.0.257355516163.issue27416@psf.upfronthosting.co.za> Message-ID: <1467213839.67.0.122008207973.issue27416@psf.upfronthosting.co.za> R. David Murray added the comment: No, the text is correct. Perhaps it would be clearer if the 'even' were moved to the front of the phrase? "...it may copy too much, even data structures that should be shared between copies." ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 11:25:29 2016 From: report at bugs.python.org (Jim Fulton) Date: Wed, 29 Jun 2016 15:25:29 +0000 Subject: [issue27386] Asyncio server hang when clients connect and immediately disconnect In-Reply-To: <1466888194.59.0.640833210662.issue27386@psf.upfronthosting.co.za> Message-ID: <1467213929.33.0.692743203938.issue27386@psf.upfronthosting.co.za> Jim Fulton added the comment: Here's a version sans prints ---------- Added file: http://bugs.python.org/file43581/echo-no-print.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 11:31:18 2016 From: report at bugs.python.org (Jim Fulton) Date: Wed, 29 Jun 2016 15:31:18 +0000 Subject: [issue27392] Add a server_side keyword parameter to create_connection In-Reply-To: <1466957117.0.0.423625085233.issue27392@psf.upfronthosting.co.za> Message-ID: <1467214278.61.0.953742833578.issue27392@psf.upfronthosting.co.za> Jim Fulton added the comment: >> Yury, I'm curious what you think the socket argument to create_connection is about. > > :) The current intended purpose of create_connection is to create a client connection. You're proposing to add a new argument -- server_side -- which I think will confuse the users of create_connection. Perhaps. I'll note that the word "client" appears nowhere in the documentation of create_connection. I needed a way to wrap a socket and create_connection took one. Wrapping a server socket seemed to be to be the most likely use case for it. > > What I'm saying is that we may consider creating a low-level loop.wrap_socket, which would be generic and suitable to be used for both client and server connections. We could even refactor create_connection to use wrap_socket when 'sock' argument is passed to it. > > We already have something similar, although it's a private API -- _make_socket_transport. Right. That's what I'm monkey-patching now to work around this, mostly as an experiment. > >> BTW, a problem with this proposal that I realized after submitting it is that it changes an API that has multiple implementations, including implementations outside of the Python codebase. Arguably, this would require a PEP, at which point the change is no-longer trivial. :) > > No need for a PEP; Guido's approval is enough usually. /me holds breath ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 11:40:10 2016 From: report at bugs.python.org (Jim Fulton) Date: Wed, 29 Jun 2016 15:40:10 +0000 Subject: [issue27392] Add a server_side keyword parameter to create_connection In-Reply-To: <1466957117.0.0.423625085233.issue27392@psf.upfronthosting.co.za> Message-ID: <1467214810.84.0.667113049485.issue27392@psf.upfronthosting.co.za> Jim Fulton added the comment: See: https://bugs.launchpad.net/zodb/+bug/135108/comments/9 Sorry, I should have sent that link sooner. In my flailing to come up with a simple case, I forgot the importance of that setting. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 11:47:29 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 29 Jun 2016 15:47:29 +0000 Subject: [issue27386] Asyncio server hang when clients connect and immediately disconnect In-Reply-To: <1466888194.59.0.640833210662.issue27386@psf.upfronthosting.co.za> Message-ID: <1467215249.2.0.214181176483.issue27386@psf.upfronthosting.co.za> Guido van Rossum added the comment: I can't personally run that code and get the results you are getting; could you please walk us through what happens (as far as you can tell)? Reading the code I find myself quite confused about which parts of the code might be active or not. E.g. is self.messages used? Does its actual contents matter? Where does it end up? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 12:10:03 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 29 Jun 2016 16:10:03 +0000 Subject: [issue27386] Asyncio server hang when clients connect and immediately disconnect In-Reply-To: <1466888194.59.0.640833210662.issue27386@psf.upfronthosting.co.za> Message-ID: <1467216603.69.0.424554495972.issue27386@psf.upfronthosting.co.za> Yury Selivanov added the comment: Jim, I think you wanted to post this link in this issue: https://bugs.launchpad.net/zodb/+bug/135108/comments/9 instead of in #27392. I can reproduce this on my mac, but so far I've no idea what's going on. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 12:11:16 2016 From: report at bugs.python.org (Jeremy Kloth) Date: Wed, 29 Jun 2016 16:11:16 +0000 Subject: [issue27410] DLL hijacking vulnerability in Python 3.5.2 installer In-Reply-To: <1467172244.73.0.493856628502.issue27410@psf.upfronthosting.co.za> Message-ID: <1467216676.53.0.478826802482.issue27410@psf.upfronthosting.co.za> Changes by Jeremy Kloth : ---------- nosy: +jkloth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 12:16:46 2016 From: report at bugs.python.org (ppperry) Date: Wed, 29 Jun 2016 16:16:46 +0000 Subject: [issue27363] Complex numbers with negative zero imaginary parts do not roundtrip properly In-Reply-To: <1466535728.31.0.514028528898.issue27363@psf.upfronthosting.co.za> Message-ID: <1467217006.91.0.463411239989.issue27363@psf.upfronthosting.co.za> Changes by ppperry : ---------- title: Complex with negative zero imaginary part -> Complex numbers with negative zero imaginary parts do not roundtrip properly _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 12:21:29 2016 From: report at bugs.python.org (Jim Fulton) Date: Wed, 29 Jun 2016 16:21:29 +0000 Subject: [issue27386] Asyncio server hang when clients connect and immediately disconnect In-Reply-To: <1466888194.59.0.640833210662.issue27386@psf.upfronthosting.co.za> Message-ID: <1467217289.27.0.354708308663.issue27386@psf.upfronthosting.co.za> Jim Fulton added the comment: Guido, are you saying that the script runs without hanging for you? (If you get a boatload of tracebacks, that's due to another asyncio bug in error handling.) Are you running the version with prints? This is an adaptation of the echo server and client from the docs. The server runs in a thread. It just echos it's input. The client just waits for a message from the server, and then send messages (one in attached echo2.py) and waits for replies. When I run this on Mac and ubuntu 14.04, the server never sees the messages sent by the client. I'm uploading a newer version that simplifies the messages data structure and adds some prints to, I think, make the sequence easier to see. Fixing the bug that causes all the tracebacks to be printed would also make this easier to interpret. Commenting out the code that makes and closes the socket connections with SO_LINGER and running echo2.py should also make it easy to see the trivial expected client/server interaction. I don't think the details of the interaction between the server and the client are very important, other than the fact that the client gets the first message from the server and the server doesn't get the subsequent message from the client. ---------- Added file: http://bugs.python.org/file43582/echo2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 12:22:51 2016 From: report at bugs.python.org (Jim Fulton) Date: Wed, 29 Jun 2016 16:22:51 +0000 Subject: [issue27392] Add a server_side keyword parameter to create_connection In-Reply-To: <1466957117.0.0.423625085233.issue27392@psf.upfronthosting.co.za> Message-ID: <1467217371.27.0.439864033925.issue27392@psf.upfronthosting.co.za> Jim Fulton added the comment: Sorry, ignore my last message ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 12:23:52 2016 From: report at bugs.python.org (Jim Fulton) Date: Wed, 29 Jun 2016 16:23:52 +0000 Subject: [issue27386] Asyncio server hang when clients connect and immediately disconnect In-Reply-To: <1466888194.59.0.640833210662.issue27386@psf.upfronthosting.co.za> Message-ID: <1467217432.32.0.0724457171229.issue27386@psf.upfronthosting.co.za> Jim Fulton added the comment: Yuri, right you are. Thanks. ????, see https://bugs.launchpad.net/zodb/+bug/135108/comments/9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 12:40:37 2016 From: report at bugs.python.org (Paul Killey) Date: Wed, 29 Jun 2016 16:40:37 +0000 Subject: [issue27416] typo / missing word in docs.python.org/2/library/copy.html In-Reply-To: <1467212670.04.0.257355516163.issue27416@psf.upfronthosting.co.za> Message-ID: <1467218437.04.0.294274509257.issue27416@psf.upfronthosting.co.za> Paul Killey added the comment: Ah, I see now -- your comment clarified it for me. Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 13:04:47 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 29 Jun 2016 17:04:47 +0000 Subject: [issue27386] Asyncio server hang when clients connect and immediately disconnect In-Reply-To: <1466888194.59.0.640833210662.issue27386@psf.upfronthosting.co.za> Message-ID: <1467219887.22.0.627599872969.issue27386@psf.upfronthosting.co.za> Yury Selivanov added the comment: Running out of time to debug this today. I think this is a bug in CPython, in either socket or select module. When I inject some debug code in selectors.py and replace KQueue with select(), I can see that the server thread's selector stops working at some point due to a EBADF error. I think something similar is happening with the KQueue selector -- at some point it just stops to return events correctly. Again, I might be wrong about this all, but this is what I think after 2.5 hours of debugging. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 13:16:31 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 29 Jun 2016 17:16:31 +0000 Subject: [issue27386] Asyncio server hang when clients connect and immediately disconnect In-Reply-To: <1467217432.32.0.0724457171229.issue27386@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: No, I just don't have a computer right now, only a phone. --Guido (mobile) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 13:25:47 2016 From: report at bugs.python.org (Jim Fulton) Date: Wed, 29 Jun 2016 17:25:47 +0000 Subject: [issue27386] Asyncio server hang when clients connect and immediately disconnect In-Reply-To: <1466888194.59.0.640833210662.issue27386@psf.upfronthosting.co.za> Message-ID: <1467221147.34.0.726944823705.issue27386@psf.upfronthosting.co.za> Jim Fulton added the comment: WRT CPython/sockets this problem doesn't happen if I use asyncore to accept connections and hand them off to create_connection. :) It also doesn't occur with uvloop, which I assume still uses sockets. Also, FWIW, the relevant ZEO test passes if I use SSL, which is how I'm working around this now for the tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 13:49:43 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 29 Jun 2016 17:49:43 +0000 Subject: [issue27392] Add a server_side keyword parameter to create_connection In-Reply-To: <1466957117.0.0.423625085233.issue27392@psf.upfronthosting.co.za> Message-ID: <1467222583.0.0.650043503673.issue27392@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- Removed message: http://bugs.python.org/msg269525 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 13:49:56 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 29 Jun 2016 17:49:56 +0000 Subject: [issue27392] Add a server_side keyword parameter to create_connection In-Reply-To: <1466957117.0.0.423625085233.issue27392@psf.upfronthosting.co.za> Message-ID: <1467222596.71.0.518470432116.issue27392@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- Removed message: http://bugs.python.org/msg269529 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 14:09:07 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 29 Jun 2016 18:09:07 +0000 Subject: [issue27386] Asyncio server hang when clients connect and immediately disconnect In-Reply-To: <1466888194.59.0.640833210662.issue27386@psf.upfronthosting.co.za> Message-ID: <1467223747.3.0.712624627747.issue27386@psf.upfronthosting.co.za> Yury Selivanov added the comment: > It also doesn't occur with uvloop, which I assume still uses sockets. No, uvloop doesn't use python sockets or select for IO at all. All IO is done in libuv. > WRT CPython/sockets this problem doesn't happen if I use asyncore to accept connections and hand them off to create_connection. :) Interesting. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 14:15:43 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 29 Jun 2016 18:15:43 +0000 Subject: [issue27392] Add a server_side keyword parameter to create_connection In-Reply-To: <1466957117.0.0.423625085233.issue27392@psf.upfronthosting.co.za> Message-ID: <1467224143.6.0.316503597765.issue27392@psf.upfronthosting.co.za> Guido van Rossum added the comment: Hm. The docs in PEP 3156 do mention that create_connection() is for clients (though it weakens this with "typically"): https://www.python.org/dev/peps/pep-3156/#internet-connections I always think of TCP connections (which is what create_connection() is about) as essentially asymmetrical -- the server uses bind() and listen() and then sits in an accept() loop accepting connections, while the client reaches out to the server using connect(). And create_connection() is a wrapper around that connect() call; for servers we have create_server(). (The asymmetry in naming reflects the asymmetry in functionality and API.) You can pass a pre-connected socket in to create_connection() for edge cases where you need control over how the socket is created and initialized or when there's a 3rd party library that can give you a connected socket that you want/need to use. Similarly, you can pass a pre-bound socket to create_server(). I guess at the lower, TCP level, there isn't much of a difference between a client-side socket and the kind of server-side socket that's returned by accept(). And maybe that's also the case for SSL (I've never actually understood most of the details of using SSL). Maybe it's just culture shock? Or maybe we just need a public API that roughly represents the pair of calls to _make_ssl_transport() and _make_socket_transport() that are currently appearing both in _create_connection_transport() and in _accept_connection2(), plus some of the code around it that's a little tricky? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 14:19:38 2016 From: report at bugs.python.org (Steve Dower) Date: Wed, 29 Jun 2016 18:19:38 +0000 Subject: [issue27417] Call CoInitializeEx on startup Message-ID: <1467224377.99.0.571630822652.issue27417@psf.upfronthosting.co.za> New submission from Steve Dower: I'd like to enable calling CoInitializeEx on Python startup for 3.6 (and into the future). See https://msdn.microsoft.com/en-us/library/windows/desktop/ms695279.aspx This would enable us to use more advanced Windows features within Python that require COM, such as better integration with the shell or features such as AMSI (issue26137, https://msdn.microsoft.com/en-us/library/windows/desktop/dn889587.aspx). The fact that AMSI is a security feature makes it important that it be enabled by default and not be able to be disabled. Calling CoInitializeEx has no impact on code that isn't already calling it, however, since it can only be called once per thread and you can't change the apartment type, it could break existing code that calls it directly (but only if it tries to use a different apartment type). My proposal is to call CoInitializeEx(NULL, COINIT_MULTITHREADED) by default, with "-X:STA" to call CoInitializeEx(NULL, COINIT_APARTMENTTHREADED) instead. (Single Threaded Apartment is the commonly used acronym for COINIT_APARTMENTTHREADED.) This forces the decision onto the user rather than letting libraries do it, but since libraries may have conflicting requirements, this hardly makes things worse. It also means we can rely on COM being enabled for any features we may want to enable within Python. I've nosied people who I expect/hope to have an opinion, so let me know what you think. ---------- assignee: steve.dower components: Windows messages: 269537 nosy: eryksun, mhammond, paul.moore, steve.dower, tim.golden, zach.ware priority: low severity: normal status: open title: Call CoInitializeEx on startup type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 14:23:37 2016 From: report at bugs.python.org (Steve Dower) Date: Wed, 29 Jun 2016 18:23:37 +0000 Subject: [issue26137] [idea] use the Microsoft Antimalware Scan Interface In-Reply-To: <1453023852.0.0.39090079449.issue26137@psf.upfronthosting.co.za> Message-ID: <1467224617.36.0.706624477917.issue26137@psf.upfronthosting.co.za> Steve Dower added the comment: This now depends on issue27417, since we can't enable AMSI without enabling COM, and doing that has a number of back-compat implications. ---------- dependencies: +Call CoInitializeEx on startup _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 14:27:40 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jun 2016 18:27:40 +0000 Subject: [issue27418] Tools/importbench/importbench.py is broken Message-ID: <1467224860.71.0.322462895886.issue27418@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: $ ./python Tools/importbench/importbench.py Traceback (most recent call last): File "Tools/importbench/importbench.py", line 8, in from test.test_importlib.source import util as source_util ImportError: cannot import name 'util' ---------- components: Demos and Tools messages: 269539 nosy: brett.cannon, serhiy.storchaka priority: normal severity: normal status: open title: Tools/importbench/importbench.py is broken type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 14:28:07 2016 From: report at bugs.python.org (Jim Fulton) Date: Wed, 29 Jun 2016 18:28:07 +0000 Subject: [issue27392] Add a server_side keyword parameter to create_connection In-Reply-To: <1466957117.0.0.423625085233.issue27392@psf.upfronthosting.co.za> Message-ID: <1467224887.26.0.0387344661363.issue27392@psf.upfronthosting.co.za> Jim Fulton added the comment: With SSL, the protocol is a little different clients and servers, although that may just be in the handshake. I'm no SSL expert by any means. When you call wrap_socket on an SSLContext, you can pass server_side, which defaults to False. If you get this wrong, you end up with an SSL protocol error. FWIW, here's my awful monkey patch to work around this experimentally in ZEO: https://github.com/zopefoundation/ZEO/pull/32/commits/daca97cb4292ad9a316a1924960a5fbf54d3622b#diff-248404a51b1503a38c3319c85e6c1c5aR174 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 14:38:34 2016 From: report at bugs.python.org (Brett Cannon) Date: Wed, 29 Jun 2016 18:38:34 +0000 Subject: [issue27418] Tools/importbench/importbench.py is broken In-Reply-To: <1467224860.71.0.322462895886.issue27418@psf.upfronthosting.co.za> Message-ID: <1467225514.16.0.145972375715.issue27418@psf.upfronthosting.co.za> Brett Cannon added the comment: If you don't have any use for it I say just delete the benchmark. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 14:40:56 2016 From: report at bugs.python.org (Brett Cannon) Date: Wed, 29 Jun 2016 18:40:56 +0000 Subject: [issue27417] Call CoInitializeEx on startup In-Reply-To: <1467224377.99.0.571630822652.issue27417@psf.upfronthosting.co.za> Message-ID: <1467225656.06.0.754675156383.issue27417@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 14:43:15 2016 From: report at bugs.python.org (Brett Cannon) Date: Wed, 29 Jun 2016 18:43:15 +0000 Subject: [issue27417] Call CoInitializeEx on startup In-Reply-To: <1467224377.99.0.571630822652.issue27417@psf.upfronthosting.co.za> Message-ID: <1467225795.49.0.0719245163371.issue27417@psf.upfronthosting.co.za> Brett Cannon added the comment: Steve has also told me this would enable querying the OS for what the default web browser is. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 14:45:48 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jun 2016 18:45:48 +0000 Subject: [issue27418] Tools/importbench/importbench.py is broken In-Reply-To: <1467224860.71.0.322462895886.issue27418@psf.upfronthosting.co.za> Message-ID: <1467225948.52.0.881280273126.issue27418@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Just now I'm writing a patch for optimizing __import__. Maybe importbench would be helpful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 14:46:55 2016 From: report at bugs.python.org (Steve Dower) Date: Wed, 29 Jun 2016 18:46:55 +0000 Subject: [issue27417] Call CoInitializeEx on startup In-Reply-To: <1467224377.99.0.571630822652.issue27417@psf.upfronthosting.co.za> Message-ID: <1467226015.68.0.950944295423.issue27417@psf.upfronthosting.co.za> Steve Dower added the comment: It would enable wrapping up anything from this list too, and more: https://msdn.microsoft.com/en-us/library/windows/desktop/bb774328(v=vs.85).aspx Plenty of cool potential features in there :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 15:09:11 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 29 Jun 2016 19:09:11 +0000 Subject: [issue27392] Add a server_side keyword parameter to create_connection In-Reply-To: <1467224887.26.0.0387344661363.issue27392@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Rather tham monkey-patching, in general I recommend just copying some code from the asyncio library and calling that. In this case you'd be copying a tiny bit of code from create_connection(). You'd still be calling an internal API, _make_ssl_transport(), but your code would still be less likely to change when some part of the asyncio library changes than with monkey-patching. (Of course, since you pretty much invented monkey-patching, you may feel differently. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 15:14:24 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 29 Jun 2016 19:14:24 +0000 Subject: [issue27392] Add a server_side keyword parameter to create_connection In-Reply-To: <1466957117.0.0.423625085233.issue27392@psf.upfronthosting.co.za> Message-ID: <1467227664.69.0.946548945283.issue27392@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Rather tham monkey-patching, in general I recommend just copying some code from the asyncio library and calling that. In this case you'd be copying a tiny bit of code from create_connection(). You'd still be calling an internal API, _make_ssl_transport(), but your code would still be less likely to change when some part of the asyncio library changes than with monkey-patching. But this kind of defeats the purpose of pluggable event loop etc. I can't implement all asyncio private APIs for uvloop. Once you start using that, your code can't run on uvloop or any other asyncio implementation. > Maybe it's just culture shock? Or maybe we just need a public API that roughly represents the pair of calls to _make_ssl_transport() and _make_socket_transport() that are currently appearing both in _create_connection_transport() and in _accept_connection2(), plus some of the code around it that's a little tricky? That's essentially what I wanted `loop.wrap_socket` to do (see msg269519) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 15:16:59 2016 From: report at bugs.python.org (Jim Fulton) Date: Wed, 29 Jun 2016 19:16:59 +0000 Subject: [issue27392] Add a server_side keyword parameter to create_connection In-Reply-To: <1466957117.0.0.423625085233.issue27392@psf.upfronthosting.co.za> Message-ID: <1467227819.73.0.129583354767.issue27392@psf.upfronthosting.co.za> Jim Fulton added the comment: :) I'm not a fan of monkey patching code in production, unless the code I'm monkey patching is code I control. (And since releasing code now is a lot easier than it used to be, I have much less occasion to monkey-patch code I control.) (I'm a big fan of and am also terrified by gevent and I generally avoid it's use of monkey patching.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 15:22:57 2016 From: report at bugs.python.org (Paul Moore) Date: Wed, 29 Jun 2016 19:22:57 +0000 Subject: [issue27417] Call CoInitializeEx on startup In-Reply-To: <1467224377.99.0.571630822652.issue27417@psf.upfronthosting.co.za> Message-ID: <1467228177.8.0.485978322908.issue27417@psf.upfronthosting.co.za> Paul Moore added the comment: Things I know that call CoInitialize - pywin32/pythoncom and comtypes. I assume the proposal is to call CoInitializeEx in a way that won't break those? I'm not sure I see how this would affect the user (i.e. Python code). Brett mentions detecting the user's browser and Steve points to the shell interfaces. But would accessing those require C support (or Python interface code complex enough that using pywin32 or comtypes would be a better option)? In practice, I don't see this change having much impact on the end user. I'm +0 on this change, regardless - it's harmless enough and offers at least some level of benefit. If it allowed user code to access COM without needing a 3rd party dependency, I'd be +1, but I don't think that's being proposed here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 15:26:16 2016 From: report at bugs.python.org (Steve Dower) Date: Wed, 29 Jun 2016 19:26:16 +0000 Subject: [issue27417] Call CoInitializeEx on startup In-Reply-To: <1467224377.99.0.571630822652.issue27417@psf.upfronthosting.co.za> Message-ID: <1467228376.53.0.632257576177.issue27417@psf.upfronthosting.co.za> Steve Dower added the comment: > If it allowed user code to access COM without needing a 3rd party dependency, I'd be +1, but I don't think that's being proposed here. It's a prerequisite to adding features to the stdlib that access COM (whether or not COM is directly exposed to the user). But no, there's no new (useful) functionality being proposed in this particular issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 15:33:19 2016 From: report at bugs.python.org (Tim Golden) Date: Wed, 29 Jun 2016 19:33:19 +0000 Subject: [issue27417] Call CoInitializeEx on startup In-Reply-To: <1467228376.53.0.632257576177.issue27417@psf.upfronthosting.co.za> Message-ID: <85b0a49e-8d33-7cb5-fe49-566f3f91c7a1@timgolden.me.uk> Tim Golden added the comment: As it happens, all the code I use which calls CoInitialise[Ex] does so with STA. But do I understand correctly that, if you implement this, there's no way for me to select MTA? If so I would consider that a major drawback. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 15:45:26 2016 From: report at bugs.python.org (Eryk Sun) Date: Wed, 29 Jun 2016 19:45:26 +0000 Subject: [issue27417] Call CoInitializeEx on startup In-Reply-To: <1467224377.99.0.571630822652.issue27417@psf.upfronthosting.co.za> Message-ID: <1467229526.77.0.897760404052.issue27417@psf.upfronthosting.co.za> Eryk Sun added the comment: pythoncom and comtypes use the value of sys.coinit_flags when imported, and otherwise default to calling CoInitializeEx(NULL, COINIT_APARTMENTTHREADED). Setting this value should ease problems, but something like -X:STA is still necessary. Note that the launcher allows passing arguments in a shebang. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 15:50:59 2016 From: report at bugs.python.org (Brett Cannon) Date: Wed, 29 Jun 2016 19:50:59 +0000 Subject: [issue27418] Tools/importbench/importbench.py is broken In-Reply-To: <1467224860.71.0.322462895886.issue27418@psf.upfronthosting.co.za> Message-ID: <1467229859.61.0.693393039944.issue27418@psf.upfronthosting.co.za> Brett Cannon added the comment: Feel free to do whatever you need/want to with the benchmark. I originally created it when switching __import__ to importlib to prove that it didn't impact performance. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 16:49:48 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jun 2016 20:49:48 +0000 Subject: [issue27418] Tools/importbench/importbench.py is broken In-Reply-To: <1467224860.71.0.322462895886.issue27418@psf.upfronthosting.co.za> Message-ID: <1467233388.16.0.474655301407.issue27418@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Following patch seems fixes importbench. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file43583/importbench.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 17:18:54 2016 From: report at bugs.python.org (Steve Dower) Date: Wed, 29 Jun 2016 21:18:54 +0000 Subject: [issue27417] Call CoInitializeEx on startup In-Reply-To: <1467224377.99.0.571630822652.issue27417@psf.upfronthosting.co.za> Message-ID: <1467235134.59.0.224779299253.issue27417@psf.upfronthosting.co.za> Steve Dower added the comment: > But do I understand correctly that, if you implement this, there's no way for me to select MTA? MTA would be the default, with no -X argument. But we could support a no-op "-X:MTA" as well. Because of the potential for use in security features, I don't want a state where COM is not enabled at all. That's status quo and no change/discussion would be necessary :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 17:19:31 2016 From: report at bugs.python.org (Steve Dower) Date: Wed, 29 Jun 2016 21:19:31 +0000 Subject: [issue27417] Call CoInitializeEx on startup In-Reply-To: <1467224377.99.0.571630822652.issue27417@psf.upfronthosting.co.za> Message-ID: <1467235171.73.0.431636638724.issue27417@psf.upfronthosting.co.za> Steve Dower added the comment: I'm also okay to discuss whether MTA or STA should be the default, but I'll also be seeking advice from work colleagues on this who know COM really well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 17:22:47 2016 From: report at bugs.python.org (Steve Dower) Date: Wed, 29 Jun 2016 21:22:47 +0000 Subject: [issue27417] Call CoInitializeEx on startup In-Reply-To: <1467224377.99.0.571630822652.issue27417@psf.upfronthosting.co.za> Message-ID: <1467235367.93.0.722918879864.issue27417@psf.upfronthosting.co.za> Steve Dower added the comment: > pythoncom and comtypes use the value of sys.coinit_flags when imported Good to know. Assume we'll add that as well. Also, with respect to threading, we'd want to initialize on all new threads too. That will require a way to specify that a new thread should be STA/MTA. I'll think about this before proposing a solution (though since it's inherently an OS-specific specialization, having a separate function for this is a fairly safe way to do it). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 18:02:05 2016 From: report at bugs.python.org (Brett Cannon) Date: Wed, 29 Jun 2016 22:02:05 +0000 Subject: [issue27418] Tools/importbench/importbench.py is broken In-Reply-To: <1467224860.71.0.322462895886.issue27418@psf.upfronthosting.co.za> Message-ID: <1467237725.83.0.776006210771.issue27418@psf.upfronthosting.co.za> Brett Cannon added the comment: I don't see anything obviously wrong with it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 21:00:14 2016 From: report at bugs.python.org (Mark Hammond) Date: Thu, 30 Jun 2016 01:00:14 +0000 Subject: [issue27417] Call CoInitializeEx on startup In-Reply-To: <1467224377.99.0.571630822652.issue27417@psf.upfronthosting.co.za> Message-ID: <1467248414.82.0.789772821801.issue27417@psf.upfronthosting.co.za> Mark Hammond added the comment: I've a few reservations here: * CoInitialize will load a number of COM DLLs into the process, which isn't free and will have some memory and performance costs for programs that don't use COM. I see around 10 such DLLs loaded. * pythoncom uses sys.coinit_flags because some COM objects simply don't work with the wrong apartment model. IOW, it is the objects you want to use on a particular thread that dictates the model you should use for that thread. Thus scripts written to interact with a particular COM object could set this flag before importing pythoncom so the correct threading model is setup. If this is done at Python startup, the script has lost the chance to influence this - insisting that Python be run with a particular set of flags for the script to work sounds painful. * pythoncom defaults to COINIT_APARTMENTTHREADED as the apartment threading model is a special snowflake - if you need to use apartment model objects, the main thread *must* be apartment threading (even though other threads can use free threading.) COM objects with a UI (eg, MSOffice, IE) typically required apartment threading. Most new objects probably allow free threading, but I think we want to be careful about defaulting to a model that might avoid common objects from being used without an obscure command-line param. * This may well break things like pythonwin until they also grow support for the new param - but new params for GUI applications somewhat suck as people tend to start them from an icon instead of the command-line. * Each thread that wants to use COM must also make this call. If *any* object you want to use uses apartment model threading, then you really have no choice other than to init the main thread with this model - but you are then free to spin up other threads using free-threading, and life is good. So to make this sane, you really want to expose CoInitialize to Python code so new threads can do the right thing. So in this case, I wonder why we don't just expose it and let it be called manually? IOW, it seems the potential risks of this outweighs the cost of requiring it to be called manually in a controlled way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 29 23:30:32 2016 From: report at bugs.python.org (Wei-Cheng Pan) Date: Thu, 30 Jun 2016 03:30:32 +0000 Subject: [issue27413] Add an option to json.tool to bypass non-ASCII characters. In-Reply-To: <1467200969.47.0.983958211319.issue27413@psf.upfronthosting.co.za> Message-ID: <1467257432.47.0.953351360813.issue27413@psf.upfronthosting.co.za> Wei-Cheng Pan added the comment: If the arguments should be aligned with those in dump/load, then maybe "--no-ensure-ascii" is an option? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 00:13:23 2016 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 30 Jun 2016 04:13:23 +0000 Subject: [issue1732367] Document the constants in the socket module Message-ID: <1467260003.13.0.141109066339.issue1732367@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 01:04:17 2016 From: report at bugs.python.org (Lisa Roach) Date: Thu, 30 Jun 2016 05:04:17 +0000 Subject: [issue23951] Update devguide style to use a similar theme as Docs In-Reply-To: <1429030125.69.0.476464501234.issue23951@psf.upfronthosting.co.za> Message-ID: <1467263057.14.0.808291648866.issue23951@psf.upfronthosting.co.za> Lisa Roach added the comment: I have updated the conf.py and added a "tools" folder that contains the themes, templates, etc. to make the devguide match more closely with the pydoctheme. I altered the theme a little bit to keep the colors more consistent with the original devguide, hopefully this will retain the obvious difference between the two documents while merging some of the more beneficial items (collapsible sidebar, code highlighting, etc.). This is my first patch submitted to Python, so I appreciate any feedback :) ---------- keywords: +patch nosy: +lisroach Added file: http://bugs.python.org/file43584/devguide_theme.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 03:35:12 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 30 Jun 2016 07:35:12 +0000 Subject: [issue27418] Tools/importbench/importbench.py is broken In-Reply-To: <1467224860.71.0.322462895886.issue27418@psf.upfronthosting.co.za> Message-ID: <20160630073508.124039.77706.6B4B2A8D@psf.io> Roundup Robot added the comment: New changeset ba4548916f05 by Serhiy Storchaka in branch '3.5': Issue #27418: Fixed Tools/importbench/importbench.py. https://hg.python.org/cpython/rev/ba4548916f05 New changeset c2e898813409 by Serhiy Storchaka in branch 'default': Issue #27418: Fixed Tools/importbench/importbench.py. https://hg.python.org/cpython/rev/c2e898813409 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 03:36:02 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 30 Jun 2016 07:36:02 +0000 Subject: [issue27418] Tools/importbench/importbench.py is broken In-Reply-To: <1467224860.71.0.322462895886.issue27418@psf.upfronthosting.co.za> Message-ID: <1467272162.57.0.7256797515.issue27418@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 04:08:44 2016 From: report at bugs.python.org (Akira Li) Date: Thu, 30 Jun 2016 08:08:44 +0000 Subject: [issue27079] Bugs in curses.ascii predicates In-Reply-To: <1463861399.98.0.689088484472.issue27079@psf.upfronthosting.co.za> Message-ID: <1467274124.07.0.887072843033.issue27079@psf.upfronthosting.co.za> Akira Li added the comment: There is an overlapping issue from 2010: "curses.ascii.isblank() function is broken. It confuses backspace (BS 0x08) with tab (0x09)" http://bugs.python.org/issue9770 Your patch fixes it too (it should be closed). Note: the patch does not pass tests from Lib/test/test_curses_ascii.py attached to issue9770 (even if the code: `if char_class_name in ('cntrl', 'punct') test = unittest.expectedFailure(test)` is removed) e.g., iscntrl(-1) should be False but it returns True: $ ./python >>> import curses.ascii >>> curses.ascii.iscntrl(-1) #XXX expected False True If we ignore negative ints then isblank, ispunct, iscntrl provided in the curses_ascii.patch are ok. ---------- nosy: +akira _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 04:22:18 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 30 Jun 2016 08:22:18 +0000 Subject: [issue23951] Update devguide style to use a similar theme as Docs In-Reply-To: <1429030125.69.0.476464501234.issue23951@psf.upfronthosting.co.za> Message-ID: <1467274938.75.0.00662542123749.issue23951@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This has a nice look and feel. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 04:28:21 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 30 Jun 2016 08:28:21 +0000 Subject: [issue27419] Bugs in PyImport_ImportModuleLevelObject Message-ID: <1467275301.6.0.860119433525.issue27419@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: 1. If __package__ is None, and __spec__ is None or not set, and emitting ImportWarning raises an error, package is a borrowed reference to None, and it is decrefed. As result, the reference count of None is decremented. 2. __import__ is looked in globals or builtins and passed to _find_and_load(), _handle_fromlist() or called with highest package name. This doesn't match Python implementation. Python implementation uses _gcd_import which implements the original __import__, and isn't affected by overriding __import__ in globals or builtins. ---------- components: Interpreter Core files: fix-__import__.patch keywords: patch messages: 269564 nosy: brett.cannon, eric.snow, ncoghlan, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Bugs in PyImport_ImportModuleLevelObject type: behavior versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43585/fix-__import__.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 04:43:24 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 30 Jun 2016 08:43:24 +0000 Subject: [issue27419] Bugs in PyImport_ImportModuleLevelObject In-Reply-To: <1467275301.6.0.860119433525.issue27419@psf.upfronthosting.co.za> Message-ID: <1467276204.15.0.833115394606.issue27419@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a reproducer for the first bug. In Python 3.6: $ ./python import_bug_1.py 1738 738 Fatal Python error: deallocating None Current thread 0xb7552700 (most recent call first): Aborted (core dumped) In Python 3.5: $ ./python import_bug_1.py 1709 Traceback (most recent call last): File "import_bug_1.py", line 10, in from .foo import bar SystemError: Parent module '' not loaded, cannot perform relative import ---------- type: behavior -> crash Added file: http://bugs.python.org/file43586/import_bug_1.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 05:11:29 2016 From: report at bugs.python.org (=?utf-8?q?Boris_Du=C5=A1ek?=) Date: Thu, 30 Jun 2016 09:11:29 +0000 Subject: [issue23794] http package should support HTTP/2 In-Reply-To: <1427479110.25.0.801999785412.issue23794@psf.upfronthosting.co.za> Message-ID: <1467277889.45.0.478363704866.issue23794@psf.upfronthosting.co.za> Changes by Boris Du?ek : ---------- nosy: +dusek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 05:15:59 2016 From: report at bugs.python.org (Nikita Nemkin) Date: Thu, 30 Jun 2016 09:15:59 +0000 Subject: [issue27417] Call CoInitializeEx on startup In-Reply-To: <1467224377.99.0.571630822652.issue27417@psf.upfronthosting.co.za> Message-ID: <1467278159.37.0.913488681195.issue27417@psf.upfronthosting.co.za> Nikita Nemkin added the comment: COM should be initialized on demand by C modules that need it. They might need STA or MTA, it's their choice to make. Python core (ceval and builtins) doesn't need COM and shouldn't impose COM threading models on any threads it creates. Things like -X:STA are not Python's concern at all. Python code (interpreted) can't access COM objects directly, it always goes through C modules, which know better. Also, COM using apps are very likely to be GUI apps and need STA main thread. MTA by default makes no sense. PS. AMSI is insane. In what world would Pyhton interpteter send my code for analysis to who knows where and without even an option to disable it (because "security")? ---------- nosy: +nnemkin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 05:45:42 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 30 Jun 2016 09:45:42 +0000 Subject: [issue23951] Update devguide style to use a similar theme as Docs In-Reply-To: <1429030125.69.0.476464501234.issue23951@psf.upfronthosting.co.za> Message-ID: <1467279942.08.0.670064143611.issue23951@psf.upfronthosting.co.za> STINNER Victor added the comment: I like the new style. I don't think that it's a big issue if people come to the /devguide/ by mistake. They should understand quickly their mistake and search for the right documentation. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 05:51:09 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 30 Jun 2016 09:51:09 +0000 Subject: [issue27416] typo / missing word in docs.python.org/2/library/copy.html In-Reply-To: <1467212670.04.0.257355516163.issue27416@psf.upfronthosting.co.za> Message-ID: <20160630095105.124085.77110.11276AC2@psf.io> Roundup Robot added the comment: New changeset 9efe0e718914 by Victor Stinner in branch '2.7': Issue #27416: clarify copy doc https://hg.python.org/cpython/rev/9efe0e718914 New changeset 54e9ca0a1639 by Victor Stinner in branch '3.5': Issue #27416: clarify copy doc https://hg.python.org/cpython/rev/54e9ca0a1639 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 05:52:01 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 30 Jun 2016 09:52:01 +0000 Subject: [issue27416] typo / missing word in docs.python.org/2/library/copy.html In-Reply-To: <1467212670.04.0.257355516163.issue27416@psf.upfronthosting.co.za> Message-ID: <1467280321.2.0.0493814967031.issue27416@psf.upfronthosting.co.za> STINNER Victor added the comment: > Because deep copy copies everything it may copy too much, e.g., administrative data structures that should be shared even between copies. I agree that the sentence sounds wrong. I applied David's patch, it also helped me to understand. Thanks :-) ---------- nosy: +haypo resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 06:04:07 2016 From: report at bugs.python.org (Paul Moore) Date: Thu, 30 Jun 2016 10:04:07 +0000 Subject: [issue26137] [idea] use the Microsoft Antimalware Scan Interface In-Reply-To: <1453023852.0.0.39090079449.issue26137@psf.upfronthosting.co.za> Message-ID: <1467281047.21.0.0378869034436.issue26137@psf.upfronthosting.co.za> Paul Moore added the comment: Strong -1 on anything that scans my locally-written scripts by default. There's no reason or justification for that. Maybe there's a point in having a way to submit an untrusted Python code snippet for scanning, but why would that need to be a core service, as opposed to a 3rd party module? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 06:04:13 2016 From: report at bugs.python.org (Paul Moore) Date: Thu, 30 Jun 2016 10:04:13 +0000 Subject: [issue27417] Call CoInitializeEx on startup In-Reply-To: <1467224377.99.0.571630822652.issue27417@psf.upfronthosting.co.za> Message-ID: <1467281052.99.0.788298344339.issue27417@psf.upfronthosting.co.za> Paul Moore added the comment: Hmm, this'll teach me to rely on my memory rather than checking :-) It seems to me that core code that needs COM can use it by wrapping the code in CoInitializeEx(sys.coinit_flags)...CoUninitialize(). That will either work fine (I don't know where you got the idea that CoInitializeEx can only be called once per thread - AFAICT the the documentation you linked to clearly states that's not the case) or it will fail because someone else has initialised the thread with an incompatible model. Either try the other model (if you don't actually care) or report the issue and stop - it's the user's code that is relying on conflicting functions, so let the user decide how to deal with it. Do you have a use case in mind where something like the above wouldn't work? BTW, I agree that AMSI sounds like a very weird thing to want to add to the Python interpreter - maybe it might make sense to have a special build "checking" interpreter that could be used in appropriate circumstances, but I'd be very uncomfortable adding something like that to the core binary or making it "enabled by default and not be able to be disabled". So that's not a good motivating use case for me... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 06:33:36 2016 From: report at bugs.python.org (Niall Mansfield) Date: Thu, 30 Jun 2016 10:33:36 +0000 Subject: [issue27420] Docs for os.link - say what happens if link already exists Message-ID: <1467282816.95.0.317527848578.issue27420@psf.upfronthosting.co.za> New submission from Niall Mansfield: In os.link(source, link_name) Change Create a hard link pointing to source named link_name. to Create a hard link pointing to source named link_name. If link_name already exists, OSError is raised. ---------- assignee: docs at python components: Documentation messages: 269572 nosy: docs at python, python-bugs-uit priority: normal severity: normal status: open title: Docs for os.link - say what happens if link already exists type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 06:50:56 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 30 Jun 2016 10:50:56 +0000 Subject: [issue27079] Bugs in curses.ascii predicates In-Reply-To: <1463861399.98.0.689088484472.issue27079@psf.upfronthosting.co.za> Message-ID: <1467283856.08.0.0823083013474.issue27079@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Since screen.getch() can return -1, it looks reasonable to make curses.ascii predicates to work with negative integers. Do you want to open a new issue and write a patch Akira? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 07:03:44 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 30 Jun 2016 11:03:44 +0000 Subject: [issue4945] json checks True/False by identity, not boolean value In-Reply-To: <1231911098.49.0.621266929609.issue4945@psf.upfronthosting.co.za> Message-ID: <20160630110341.7434.88125.9F9FDC26@psf.io> Roundup Robot added the comment: New changeset 8f1d3ebdbc56 by Serhiy Storchaka in branch '2.7': Issue #4945: Improved the documenting of boolean arguments in the json module. https://hg.python.org/cpython/rev/8f1d3ebdbc56 New changeset 324b061ce220 by Serhiy Storchaka in branch '3.5': Issue #4945: Improved the documenting of boolean arguments in the json module. https://hg.python.org/cpython/rev/324b061ce220 New changeset f2d1dba10a0e by Serhiy Storchaka in branch 'default': Issue #4945: Improved the documenting of boolean arguments in the json module. https://hg.python.org/cpython/rev/f2d1dba10a0e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 07:04:25 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 30 Jun 2016 11:04:25 +0000 Subject: [issue4945] json checks True/False by identity, not boolean value In-Reply-To: <1231911098.49.0.621266929609.issue4945@psf.upfronthosting.co.za> Message-ID: <1467284665.81.0.188816524559.issue4945@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Raymond. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 07:59:05 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 30 Jun 2016 11:59:05 +0000 Subject: [issue27421] PPC64LE Fedora 2.7: certificate for hg.python.org has unexpected fingerprint Message-ID: <1467287945.31.0.973782054097.issue27421@psf.upfronthosting.co.za> New submission from STINNER Victor: http://buildbot.python.org/all/builders/PPC64LE%20Fedora%202.7/builds/429/steps/hg/logs/stdio abort: certificate for hg.python.org has unexpected fingerprint 31:d8:79:0f:ca:b5:c4:76:85:ba:61:84:e7:5b:52:4f:78:7d:38:3e (check hostfingerprint configuration) ---------- components: Build keywords: buildbot messages: 269576 nosy: haypo priority: normal severity: normal status: open title: PPC64LE Fedora 2.7: certificate for hg.python.org has unexpected fingerprint versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 08:11:52 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 30 Jun 2016 12:11:52 +0000 Subject: [issue27173] Modern Unix key bindings for IDLE In-Reply-To: <1464766185.36.0.150155479026.issue27173@psf.upfronthosting.co.za> Message-ID: <1467288712.93.0.465260634245.issue27173@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated patch addresses your comments Terry. Since CurrentTheme checks that the corresponding section exists, I no longer think it is buggy. ---------- Added file: http://bugs.python.org/file43587/idle_modern_unix_key_set5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 08:23:30 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Thu, 30 Jun 2016 12:23:30 +0000 Subject: [issue23794] http package should support HTTP/2 In-Reply-To: <1427479110.25.0.801999785412.issue23794@psf.upfronthosting.co.za> Message-ID: <1467289410.06.0.63102029048.issue23794@psf.upfronthosting.co.za> ???? ????????? added the comment: Why not to use HTTP parser from Nginx ? I mean write binding using Cython. AFAIK, Nodejs already done that. It is fast, and fully spec-compliant http-parser. ---------- nosy: +mmarkk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 08:25:30 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 30 Jun 2016 12:25:30 +0000 Subject: [issue16137] Using time.asctime() with an array with negative tm_hour causes Python Crash. In-Reply-To: <1349390143.92.0.685174043431.issue16137@psf.upfronthosting.co.za> Message-ID: <1467289530.91.0.206277844653.issue16137@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Eryk. Sad, a simple solution doesn't help. We have returned to the old decision -- won't fix. ---------- stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 08:37:23 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 30 Jun 2016 12:37:23 +0000 Subject: [issue23794] http package should support HTTP/2 In-Reply-To: <1427479110.25.0.801999785412.issue23794@psf.upfronthosting.co.za> Message-ID: <1467290243.53.0.706603941382.issue23794@psf.upfronthosting.co.za> STINNER Victor added the comment: Even if HTTP2 is a standard, it looks a little bit more complex than HTTP 1.1. It would be nice to start with a package on PyPI to keep fast evolution, and then wait until the API is stabilized before we put anything in the stdlib. Or maybe we should start with a "subset" of HTTP2. By the way, the issue title is "http package should support HTTP/2". Are you talking about the http client or client+server? I suggest to start with the client. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 08:49:00 2016 From: report at bugs.python.org (Cory Benfield) Date: Thu, 30 Jun 2016 12:49:00 +0000 Subject: [issue23794] http package should support HTTP/2 In-Reply-To: <1427479110.25.0.801999785412.issue23794@psf.upfronthosting.co.za> Message-ID: <1467290940.5.0.760630531371.issue23794@psf.upfronthosting.co.za> Cory Benfield added the comment: It occurs to me that I should update this issue to mention that the HTTP/2 parser I spoke about above now exists, and has existed for some time, as hyper-h2. It's available on PyPI: https://pypi.python.org/pypi/h2 It's fully spec-compliant, and already used as the basis for HTTP/2 implementations in mitmproxy, Twisted, and hyper itself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 09:02:36 2016 From: report at bugs.python.org (Steve Dower) Date: Thu, 30 Jun 2016 13:02:36 +0000 Subject: [issue26137] [idea] use the Microsoft Antimalware Scan Interface In-Reply-To: <1453023852.0.0.39090079449.issue26137@psf.upfronthosting.co.za> Message-ID: <1467291756.71.0.957982486109.issue26137@psf.upfronthosting.co.za> Steve Dower added the comment: AMSI is intended for local scanners that are entirely on your own machine, so code never goes anywhere, and everything that passes through the file system is already scanned because of hooks whether you wrote it or not (maybe you're thinking of SmartScreen?). What this would add is scanning at the exec point in: python -c exec(decrypt(open('file.bin', 'rb'))) Currently, malware scanners don't get to see the decrypted code, and I'm assured this is a common pattern for getting malware onto machines (yes, in Python). That said, I fully expect the official releases to require a registry key to enable it (can't be env or CLI option or an attacker would just leave it out :) ). Wouldn't be on for normal use, but would be available for paranoid people. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 11:17:10 2016 From: report at bugs.python.org (Paul Moore) Date: Thu, 30 Jun 2016 15:17:10 +0000 Subject: [issue26137] [idea] use the Microsoft Antimalware Scan Interface In-Reply-To: <1453023852.0.0.39090079449.issue26137@psf.upfronthosting.co.za> Message-ID: <1467299830.43.0.645477781103.issue26137@psf.upfronthosting.co.za> Paul Moore added the comment: OK, so a 3rd party module providing a "safe_exec" function would make a good proof of concept, I assume. You could probably do that using comtypes or pywin32. I'm not going to try to say what is or isn't a security threat, that's not my expertise. But I am puzzled as to why "use safe_exec rather than exec" isn't an option, but "use python with the malware scanning option enabled" is. Maybe it's like the Powershell execution policy model, though. I still don't want it to scan my trusted scripts, though. More interpreter startup overhead? No thanks. Anyway, thanks for the clarification. It's early days yet to be debating this level of detail, so I'll leave it there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 11:25:08 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 30 Jun 2016 15:25:08 +0000 Subject: [issue27413] Add an option to json.tool to bypass non-ASCII characters. In-Reply-To: <1467200969.47.0.983958211319.issue27413@psf.upfronthosting.co.za> Message-ID: <1467300308.08.0.702546637134.issue27413@psf.upfronthosting.co.za> R. David Murray added the comment: Sorry, yes, that's what I meant. I think it will make it easier to understand and remember if the option uses the same terminology as the function. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 11:35:37 2016 From: report at bugs.python.org (Zachary Ware) Date: Thu, 30 Jun 2016 15:35:37 +0000 Subject: [issue26137] [idea] use the Microsoft Antimalware Scan Interface In-Reply-To: <1453023852.0.0.39090079449.issue26137@psf.upfronthosting.co.za> Message-ID: <1467300937.49.0.857309985936.issue26137@psf.upfronthosting.co.za> Zachary Ware added the comment: > I am puzzled as to why "use safe_exec rather than exec" isn't an option Because you're going to have a hard time convincing malware authors to use it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 11:47:57 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 30 Jun 2016 15:47:57 +0000 Subject: [issue27421] PPC64LE Fedora 2.7: certificate for hg.python.org has unexpected fingerprint In-Reply-To: <1467287945.31.0.973782054097.issue27421@psf.upfronthosting.co.za> Message-ID: <1467301677.13.0.0300103244131.issue27421@psf.upfronthosting.co.za> R. David Murray added the comment: The EV certificate was updated, according to Donald. I don't understand the source of the abort, though. It looks like it is coming from hg itself? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 11:51:13 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 30 Jun 2016 15:51:13 +0000 Subject: [issue27421] PPC64LE Fedora 2.7: certificate for hg.python.org has unexpected fingerprint In-Reply-To: <1467287945.31.0.973782054097.issue27421@psf.upfronthosting.co.za> Message-ID: <1467301873.03.0.0168091746913.issue27421@psf.upfronthosting.co.za> STINNER Victor added the comment: > The EV certificate was updated, according to Donald. I don't understand the source of the abort, though. It looks like it is coming from hg itself? I got the error sometimes with Bitbucket when they change their certificate. I store Bitbucket certificate fingerprint in my ~/.hgrc configuration file: [hostfingerprints] # https://blog.bitbucket.org/2016/05/04/2847/ bitbucket.org = 3f:d3:c5:17:23:3c:cd:f5:2d:17:76:06:93:7e:ee:97:42:21:14:aa ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 11:53:53 2016 From: report at bugs.python.org (Zachary Ware) Date: Thu, 30 Jun 2016 15:53:53 +0000 Subject: [issue27421] PPC64LE Fedora 2.7: certificate for hg.python.org has unexpected fingerprint In-Reply-To: <1467287945.31.0.973782054097.issue27421@psf.upfronthosting.co.za> Message-ID: <1467302033.34.0.740274528194.issue27421@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +David.Edelsohn, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 11:55:03 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 30 Jun 2016 15:55:03 +0000 Subject: [issue27421] PPC64LE Fedora 2.7: certificate for hg.python.org has unexpected fingerprint In-Reply-To: <1467287945.31.0.973782054097.issue27421@psf.upfronthosting.co.za> Message-ID: <1467302103.47.0.0378976143933.issue27421@psf.upfronthosting.co.za> R. David Murray added the comment: Yeah, looks like the hg server config needs to be updated. I don't think I can do that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 11:55:57 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 30 Jun 2016 15:55:57 +0000 Subject: [issue27421] PPC64LE Fedora 2.7: certificate for hg.python.org has unexpected fingerprint In-Reply-To: <1467287945.31.0.973782054097.issue27421@psf.upfronthosting.co.za> Message-ID: <1467302157.04.0.141521808881.issue27421@psf.upfronthosting.co.za> R. David Murray added the comment: Oh, wait, this is buildbot client side...so the buildbot slave itself needs to be updated? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 11:57:06 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 30 Jun 2016 15:57:06 +0000 Subject: [issue27421] PPC64LE Fedora 2.7: certificate for hg.python.org has unexpected fingerprint In-Reply-To: <1467287945.31.0.973782054097.issue27421@psf.upfronthosting.co.za> Message-ID: <1467302226.1.0.786749899671.issue27421@psf.upfronthosting.co.za> R. David Murray added the comment: I'll post a message to the buildbots list. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 11:58:14 2016 From: report at bugs.python.org (Steve Dower) Date: Thu, 30 Jun 2016 15:58:14 +0000 Subject: [issue27417] Call CoInitializeEx on startup In-Reply-To: <1467224377.99.0.571630822652.issue27417@psf.upfronthosting.co.za> Message-ID: <1467302294.43.0.958653586736.issue27417@psf.upfronthosting.co.za> Steve Dower added the comment: Mark: > CoInitialize will load a number of COM DLLs into the process, which isn't free and will have some memory and performance costs for programs that don't use COM. I see around 10 such DLLs loaded. Very good point. Most of those should already be loaded in the OS, which reduces the cost, but it's still not free. Given some other work I've been trying to do to reduce footprint, this is definitely a step backwards :( > This may well break things like pythonwin until they also grow support for the new param I expect that, which is why I'm only proposing it for 3.6 onwards. While adding support for a new major version of Python should be fairly cheap, it isn't entirely free and so it's the right time to add new complications. > I wonder why we don't just expose it and let it be called manually? Because that prevents us adding features to the core interpreter that require COM before a user could choose to initialize it. Also, that's the current state of the world, and this is a proposal to change it - hence I don't want to start with that as an assumption since it makes this whole discussion moot :) Nikita: > COM should be initialized on demand by C modules that need it. They might need STA or MTA, it's their choice to make. And if the C module is the core interpreter (see issue26137 for an example of where this would be necessary)? If we require user code to initialize COM, this whole proposal is moot as that is the current state of the world and it does not require any changes to achieve. > COM using apps are very likely to be GUI apps and need STA main thread. MTA by default makes no sense. Fair point. CoInitializeEx defaults to MTA, and pythonwin follows this, while IronPython defaults to STA (since COM initialization is unavoidable in their context), so the default we should use is not obvious. But I will mention that there are plenty of ways that COM is useful without writing a GUI app, so I don't think we should assume that only GUI apps are going to use it. > PS. AMSI ... Your PS is basically answered in issue26137 - I want to keep the discussion of the merits of AMSI separate from this issue :) Paul: > It seems to me that core code that needs COM can use it by wrapping the code in CoInitializeEx(sys.coinit_flags)...CoUninitialize(). This doesn't work when COM objects have to be kept around. In the AMSI case, the threading model is irrelevant, but you need to keep reusing the same context for each call, which means you can't keep initializing COM (I tried it - it crashes, I believe because you get a new memory allocator and/or arena each time, but I didn't diagnose the crash thoroughly). There may be a workaround for cases where we can't keep reinitializing COM (add a background non-Python thread and do all the calls from there), but the complexity is fairly high and the performance impact is greater. Worth investigating further, since the general feeling seems to be against change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 12:14:49 2016 From: report at bugs.python.org (ppperry) Date: Thu, 30 Jun 2016 16:14:49 +0000 Subject: [issue26226] Various test suite failures on Windows when computer name contains a non-ascii character In-Reply-To: <1453940751.65.0.882732529995.issue26226@psf.upfronthosting.co.za> Message-ID: <1467303289.66.0.403436187039.issue26226@psf.upfronthosting.co.za> Changes by ppperry : ---------- title: Various test suite failures on Windows -> Various test suite failures on Windows when computer name contains a non-ascii character _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 12:20:43 2016 From: report at bugs.python.org (Paul Moore) Date: Thu, 30 Jun 2016 16:20:43 +0000 Subject: [issue26137] [idea] use the Microsoft Antimalware Scan Interface In-Reply-To: <1453023852.0.0.39090079449.issue26137@psf.upfronthosting.co.za> Message-ID: <1467303643.06.0.12168461001.issue26137@psf.upfronthosting.co.za> Paul Moore added the comment: >> I am puzzled as to why "use safe_exec rather than exec" isn't an option > Because you're going to have a hard time convincing malware authors to use it. :-) So the malicious payload is the whole python command, not just file.bin. OK, fair enough. But in that case, why hook into exec? The malware author can execute arbitrary Python so doesn't *need* exec. As I say, though, I'm not an expert in security threats, so I'm OK with accepting that there's a hole here and the proposal plugs it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 12:23:23 2016 From: report at bugs.python.org (Martin Ritter) Date: Thu, 30 Jun 2016 16:23:23 +0000 Subject: [issue27422] Deadlock when mixing threading and multiprocessing Message-ID: <1467303803.25.0.914359339926.issue27422@psf.upfronthosting.co.za> New submission from Martin Ritter: When creating a multiprocessing.Process in a threaded environment I get deadlocks waiting, I guess waiting for the lock to flush the output. I attached a minimal example of the problem which hangs for me starting with 4 threads. ---------- files: test_threadfork.py messages: 269593 nosy: Martin Ritter priority: normal severity: normal status: open title: Deadlock when mixing threading and multiprocessing type: crash versions: Python 3.5 Added file: http://bugs.python.org/file43588/test_threadfork.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 12:25:04 2016 From: report at bugs.python.org (Martin Ritter) Date: Thu, 30 Jun 2016 16:25:04 +0000 Subject: [issue27422] Deadlock when mixing threading and multiprocessing In-Reply-To: <1467303803.25.0.914359339926.issue27422@psf.upfronthosting.co.za> Message-ID: <1467303904.88.0.95219327865.issue27422@psf.upfronthosting.co.za> Martin Ritter added the comment: I attached a gdb backtrace of one of the child processes ---------- Added file: http://bugs.python.org/file43589/test_threadfork_backtrace.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 12:25:05 2016 From: report at bugs.python.org (Zachary Ware) Date: Thu, 30 Jun 2016 16:25:05 +0000 Subject: [issue27417] Call CoInitializeEx on startup In-Reply-To: <1467224377.99.0.571630822652.issue27417@psf.upfronthosting.co.za> Message-ID: <1467303905.16.0.165354937365.issue27417@psf.upfronthosting.co.za> Zachary Ware added the comment: What about instead of unconditionally calling CoInitializeEx in all cases, add a Py_EnsureCOM(flags) C API function? The flags param would be any flags that the caller must have, would default to 0, and would be combined with sys.coinit_flags before calling CoInitializeEx. If CoInitializeEx had already been called, the flags are compared with what were used in the call and an error is raised in case of conflict. Otherwise, CoInitializeEx is called and the flags are returned. It could also be exposed to Python code as sys.ensure_com, though in the case of something like AMSI being enabled, sys.ensure_com would always either be a no-op or raise an error. Disclaimer: I know exactly nothing about COM, except what I've read in this issue and the AMSI issue. If this suggestion is unworkable, please ignore it entirely! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 12:27:24 2016 From: report at bugs.python.org (Paul Moore) Date: Thu, 30 Jun 2016 16:27:24 +0000 Subject: [issue27417] Call CoInitializeEx on startup In-Reply-To: <1467224377.99.0.571630822652.issue27417@psf.upfronthosting.co.za> Message-ID: <1467304044.17.0.773510185629.issue27417@psf.upfronthosting.co.za> Paul Moore added the comment: > This doesn't work when COM objects have to be kept around. In the AMSI case... OK, so that's a limitation. Is there any *other* use case for keeping COM objects (that are created by the core) around? If not, then like it or not, this is a problem for AMSI, not for a general "initialise COM" proposal. Basically, I'm saying that it's only worth splitting this proposal out from the AMSI one if there's a benefit (to offset the costs) for code other than AMSI. And there seems to be no such use case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 12:43:38 2016 From: report at bugs.python.org (Steve Dower) Date: Thu, 30 Jun 2016 16:43:38 +0000 Subject: [issue27417] Call CoInitializeEx on startup In-Reply-To: <1467224377.99.0.571630822652.issue27417@psf.upfronthosting.co.za> Message-ID: <1467305018.22.0.145595872124.issue27417@psf.upfronthosting.co.za> Steve Dower added the comment: > What about instead of unconditionally calling CoInitializeEx in all cases, add a Py_EnsureCOM(flags) C API function? This is essentially what CoInitializeEx does anyway - if the flags don't match the existing ones, it returns an error. So all we gain is a core function that directly calls CoInitializeEx. (I'm not saying that wouldn't be valuable, but it's also entirely suitable for a 3rd-party package since it requires 3rd-party code to call it.) > Is there any *other* use case for keeping COM objects (that are created by the core) around? Haven't found one yet :) IIRC, there's a decent chunk of certificate store APIs that are only available via COM, so if we wanted to enable something like signed scripts (or possibly even migrate ssl to verify using the right APIs on Windows) then we'd probably need it for that. Maybe - though doubtful - it would be feasible to only initialize COM around each connection. Basically all of the new "cool" APIs added since Windows 8 are COM-based too, so if we wanted to support launching/interacting with modern-style apps (or being embedded in one), or some of the credential support. It's a big hypothetical right now, but given the current state is "we can't use COM because we don't initialize it", we're definitely missing potential opportunities. If there was an easy way to say "we now initialize COM all the time" then the potential would open up, but since it doesn't look like there's an easy way to do that we'll have to keen on avoiding the new APIs unless there's sufficient value to add the complexity of background threads. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 12:43:44 2016 From: report at bugs.python.org (Steve Dower) Date: Thu, 30 Jun 2016 16:43:44 +0000 Subject: [issue26137] [idea] use the Microsoft Antimalware Scan Interface In-Reply-To: <1453023852.0.0.39090079449.issue26137@psf.upfronthosting.co.za> Message-ID: <1467305024.21.0.864027570429.issue26137@psf.upfronthosting.co.za> Steve Dower added the comment: > So the malicious payload is the whole python command, not just file.bin Yeah, sorry that wasn't clear. Many vulnerabilities allow attackers to schedule process launches (e.g. via cron/Task Scheduler/etc.) without actually being able to add any files to the machine - Stuxnet took advantage of this, for example. So if Python is already there, you can schedule "python -c "import urllib, base64; exec(...)"" to download->decode->exec arbitrary code without touching the file system or network with obvious sources. (Right now, I understand base64 is sufficient encryption, at least until the antimalware companies add signatures for base64-encoded scripts. Even then, the slightest customization of the original code is going to break base64 enough to avoid detection, whereas the signatures are flexible enough to handle variations to source code.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 12:47:18 2016 From: report at bugs.python.org (Emanuel Barry) Date: Thu, 30 Jun 2016 16:47:18 +0000 Subject: [issue27423] Failed assertions when running test.test_os on Windows Message-ID: <1467305238.88.0.613411427666.issue27423@psf.upfronthosting.co.za> New submission from Emanuel Barry: Running test_os yields a ton (something like 20) failed assertion warnings. The attached screenshot is one of them (comes up a few times), but there are others. Choosing to Ignore the error makes Python think that the test was merely skipped without any error. I'm not sure where exactly this kind of bug report goes (doesn't seem to be Python's fault), but I'm hoping some of the Windows experts can pick this up. ---------- components: Tests, Windows files: test_os failed assertion.png messages: 269599 nosy: ebarry, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: needs patch status: open title: Failed assertions when running test.test_os on Windows type: crash versions: Python 3.6 Added file: http://bugs.python.org/file43590/test_os failed assertion.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 12:47:22 2016 From: report at bugs.python.org (Zachary Ware) Date: Thu, 30 Jun 2016 16:47:22 +0000 Subject: [issue26137] [idea] use the Microsoft Antimalware Scan Interface In-Reply-To: <1453023852.0.0.39090079449.issue26137@psf.upfronthosting.co.za> Message-ID: <1467305242.74.0.119596655712.issue26137@psf.upfronthosting.co.za> Zachary Ware added the comment: > But in that case, why hook into exec? The malware author can execute > arbitrary Python so doesn't *need* exec. As I understand it, the malware is distributed in encrypted form (probably encrypted differently each time it propagates) so as to be given a green-light by anti-malware software, then decrypted and run via exec so that the bad code is never actually on disk, and thus never scanned. Yes, the attacker can run arbitrary Python code, but if he just distributed the code in plain text, it could be detected and blocked. The unpacking code is simple and generic enough that it can't be blocked. As far as actually enabling AMSI, I'm +0. I don't understand it well enough to be +1, and I share Paul's concerns about startup overhead. I'm also unsure that AMSI actually affords any protection: what's to stop the attacker from distributing their own interpreter that just doesn't use AMSI? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 12:51:44 2016 From: report at bugs.python.org (David Edelsohn) Date: Thu, 30 Jun 2016 16:51:44 +0000 Subject: [issue27421] PPC64LE Fedora 2.7: certificate for hg.python.org has unexpected fingerprint In-Reply-To: <1467287945.31.0.973782054097.issue27421@psf.upfronthosting.co.za> Message-ID: <1467305504.31.0.170389840583.issue27421@psf.upfronthosting.co.za> David Edelsohn added the comment: I have updated the fingerprint in .hgrc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 13:00:01 2016 From: report at bugs.python.org (Emanuel Barry) Date: Thu, 30 Jun 2016 17:00:01 +0000 Subject: [issue27424] Failures in test.test_logging Message-ID: <1467306001.82.0.0686720653934.issue27424@psf.upfronthosting.co.za> New submission from Emanuel Barry: Ran the test as 'python -W error -m test.test_logging' on latest 3.6 version. No idea what causes this; full traceback attached. Not sure if it's relevant, but I'm running Windows 7. ---------- components: Library (Lib), Tests files: test_logging failures.txt messages: 269602 nosy: ebarry, vinay.sajip priority: normal severity: normal stage: needs patch status: open title: Failures in test.test_logging type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file43591/test_logging failures.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 13:11:16 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 30 Jun 2016 17:11:16 +0000 Subject: [issue27422] Deadlock when mixing threading and multiprocessing In-Reply-To: <1467303803.25.0.914359339926.issue27422@psf.upfronthosting.co.za> Message-ID: <1467306676.4.0.0042035423507.issue27422@psf.upfronthosting.co.za> R. David Murray added the comment: Mixing multiprocessing and threading is problem prone in general. Hopefully one of the multiprocessing experts can say if this is a known problem or not... ---------- nosy: +devin, r.david.murray, sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 13:16:29 2016 From: report at bugs.python.org (Emanuel Barry) Date: Thu, 30 Jun 2016 17:16:29 +0000 Subject: [issue27425] Tests fail because of git's newline preferences on Windows Message-ID: <1467306989.4.0.803551571995.issue27425@psf.upfronthosting.co.za> New submission from Emanuel Barry: Specifically, test_random and test_sax both fail because of git's newline preferences. Mine is set to convert \r\n to \n on push and the other way around on pull. Relevant output: test_random: ....EException ignored in: <_io.FileIO name='E:\\GitHub\\cpython\\lib\\test\\randv2_32.pck' mode='rb' closefd=True> ResourceWarning: unclosed file <_io.BufferedReader name='E:\\GitHub\\cpython\\lib\\test\\randv2_32.pck'> ...........................EException ignored in: <_io.FileIO name='E:\\GitHub\\cpython\\lib\\test\\randv2_32.pck' mode='rb' closefd=True> ResourceWarning: unclosed file <_io.BufferedReader name='E:\\GitHub\\cpython\\lib\\test\\randv2_32.pck'> ............................ ====================================================================== ERROR: test_bug_1727780 (__main__.MersenneTwister_TestBasicOps) ---------------------------------------------------------------------- Traceback (most recent call last): File "E:\GitHub\cpython\lib\test\test_random.py", line 178, in test_bug_1727780 r = pickle.load(f) ImportError: No module named 'random\r' ====================================================================== ERROR: test_bug_1727780 (__main__.SystemRandom_TestBasicOps) ---------------------------------------------------------------------- Traceback (most recent call last): File "E:\GitHub\cpython\lib\test\test_random.py", line 178, in test_bug_1727780 r = pickle.load(f) ImportError: No module named 'random\r' ---------------------------------------------------------------------- Ran 61 tests in 1.480s FAILED (errors=2) test_sax: (Passing tests omitted) ====================================================================== FAIL: test_expat_binary_file (__main__.ExpatReaderTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "E:\GitHub\cpython\lib\test\test_sax.py", line 836, in test_expat_binary_file self.assertEqual(result.getvalue(), xml_test_out) AssertionError: b'\n\r\n\n\r\n\n\r\n\n\r\n\n\r\n\n\r\n\n\r\n\n\r\n\n\r\n\n\r\n test_main() File "E:\GitHub\cpython\lib\test\test_sax.py", line 1258, in test_main XmlReaderTest) File "E:\GitHub\cpython\lib\test\support\__init__.py", line 1837, in run_unittest _run_suite(suite) File "E:\GitHub\cpython\lib\test\support\__init__.py", line 1812, in _run_suite raise TestFailed(err) test.support.TestFailed: multiple errors occurred ---------- components: Tests messages: 269604 nosy: ebarry priority: normal severity: normal status: open title: Tests fail because of git's newline preferences on Windows type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 13:19:57 2016 From: report at bugs.python.org (Memeplex) Date: Thu, 30 Jun 2016 17:19:57 +0000 Subject: [issue26894] Readline not aborting line edition on sigint In-Reply-To: <1462027506.98.0.545203031593.issue26894@psf.upfronthosting.co.za> Message-ID: <1467307197.41.0.377564692156.issue26894@psf.upfronthosting.co.za> Memeplex added the comment: Martin: I can't reproduce the issue by just importing matplotlib with the TkAgg backend into a vanilla python repl. I will try to isolate the problem when I have some free time. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 13:20:04 2016 From: report at bugs.python.org (Steve Dower) Date: Thu, 30 Jun 2016 17:20:04 +0000 Subject: [issue26137] [idea] use the Microsoft Antimalware Scan Interface In-Reply-To: <1453023852.0.0.39090079449.issue26137@psf.upfronthosting.co.za> Message-ID: <1467307204.03.0.557405231824.issue26137@psf.upfronthosting.co.za> Steve Dower added the comment: > what's to stop the attacker from distributing their own interpreter that just doesn't use AMSI? AppLocker https://technet.microsoft.com/en-us/library/ee619725.aspx (In short, restrict which executables can be run on a particular system by path/certificate/etc.) Also a combination of ACLs and the fact that they may not be able to copy files onto the system directly anyway - see my post just before yours. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 13:25:43 2016 From: report at bugs.python.org (Steve Dower) Date: Thu, 30 Jun 2016 17:25:43 +0000 Subject: [issue26137] [idea] use the Microsoft Antimalware Scan Interface In-Reply-To: <1453023852.0.0.39090079449.issue26137@psf.upfronthosting.co.za> Message-ID: <1467307543.13.0.550122385869.issue26137@psf.upfronthosting.co.za> Steve Dower added the comment: And in case it's not clear, I *totally* recognize that AMSI is not for everyone. If you're running in a developer environment, your security is almost certainly so lax that it's irrelevant. However, once you start getting serious about what's deployed on your production machines, Python gets ruled out very quickly because it lacks features like AMSI. Sysadmins don't want to enable a potential attack tool unless it's value drastically outweighs the risks (and on Windows, this is generally/currently not true), or there is sufficient insight into the behavior and use of the tool. If we want Python to be seen as a production tool and not just a developer tool (which I do), we need to address these concerns. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 13:26:35 2016 From: report at bugs.python.org (Emanuel Barry) Date: Thu, 30 Jun 2016 17:26:35 +0000 Subject: [issue27426] Encoding mismatch causes some tests to fail on Windows Message-ID: <1467307595.9.0.252955875696.issue27426@psf.upfronthosting.co.za> New submission from Emanuel Barry: Specifically, test_strptime fails: ss.............F.....................E........... ====================================================================== ERROR: test_timezone (__main__.StrptimeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "E:\GitHub\cpython\lib\test\test_strptime.py", line 330, in test_timezone strp_output = _strptime._strptime_time(strf_output, "%Z") File "E:\GitHub\cpython\lib\_strptime.py", line 559, in _strptime_time tt = _strptime(data_string, format)[0] File "E:\GitHub\cpython\lib\_strptime.py", line 365, in _strptime data_string[found.end():]) ValueError: unconverted data remains: (heure d??t?) ====================================================================== FAIL: test_timezone (__main__.LocaleTime_Tests) ---------------------------------------------------------------------- Traceback (most recent call last): File "E:\GitHub\cpython\lib\test\test_strptime.py", line 78, in test_timezone (timezone, self.LT_ins.timezone)) AssertionError: False is not true : timezone est (heure d??t?) not found in (frozenset({'utc', 'est', 'gmt'}), frozenset({'est (heure d\x92?t?)'})) ---------------------------------------------------------------------- Ran 49 tests in 0.128s FAILED (failures=1, errors=1, skipped=2) Eryk Sun explains the cause in http://bugs.python.org/issue26226#msg269462 ---------- components: Tests, Windows messages: 269608 nosy: ebarry, eryksun, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: needs patch status: open title: Encoding mismatch causes some tests to fail on Windows type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 13:32:12 2016 From: report at bugs.python.org (Emanuel Barry) Date: Thu, 30 Jun 2016 17:32:12 +0000 Subject: [issue26226] Test failures with non-ascii character in hostname on Windows In-Reply-To: <1453940751.65.0.882732529995.issue26226@psf.upfronthosting.co.za> Message-ID: <1467307932.45.0.543535493302.issue26226@psf.upfronthosting.co.za> Emanuel Barry added the comment: So I checked to make sure everything re-compiled properly and re-ran tests. Now, only a very few fail, and I've opened separate issues for each of them. test_os: #27423 test_logging: #27424 test_random: #27425 test_sax: #27425 test_strptime: #27426 I'm keeping this one open specifically for the test_uuid failure, which seems to be caused by my hostname having non-ascii characters (and this was more or less the focus of this issue for a while). ---------- title: Various test suite failures on Windows when computer name contains a non-ascii character -> Test failures with non-ascii character in hostname on Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 13:46:40 2016 From: report at bugs.python.org (erdban fed) Date: Thu, 30 Jun 2016 17:46:40 +0000 Subject: [issue26664] find a bug in activate.fish of venv of cpython3.6 In-Reply-To: <1459255585.37.0.253753371111.issue26664@psf.upfronthosting.co.za> Message-ID: <1467308800.86.0.763701816466.issue26664@psf.upfronthosting.co.za> erdban fed added the comment: This bug shipped in 3.5.2. It should've been a blocker. ---------- nosy: +erdban fed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 13:49:56 2016 From: report at bugs.python.org (Martin Ritter) Date: Thu, 30 Jun 2016 17:49:56 +0000 Subject: =?utf-8?q?=5Bissue23644=5D_g++_module_compile_fails_with_=E2=80=98=5FAtom?= =?utf-8?q?ic=E2=80=99_does_not_name_a_type?= In-Reply-To: <1426172340.82.0.788562357439.issue23644@psf.upfronthosting.co.za> Message-ID: <1467308996.12.0.0254333787087.issue23644@psf.upfronthosting.co.za> Martin Ritter added the comment: For me compiling 3.5.2 on GCC 5.2.0 fails when I supply --with-cxx-main=g++ with the same "error: ?_Atomic? does not name a type" messages. I'm guessing that --with-cxx-main is probably outdated(?) but at least it worked with 3.5.0 ---------- nosy: +Martin Ritter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 13:52:58 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 30 Jun 2016 17:52:58 +0000 Subject: [issue26664] find a bug in activate.fish of venv of cpython3.6 In-Reply-To: <1459255585.37.0.253753371111.issue26664@psf.upfronthosting.co.za> Message-ID: <1467309178.3.0.0743590547132.issue26664@psf.upfronthosting.co.za> Xiang Zhang added the comment: I get the same feeling. Add Larry. ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 14:25:20 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 30 Jun 2016 18:25:20 +0000 Subject: [issue27422] Deadlock when mixing threading and multiprocessing In-Reply-To: <1467303803.25.0.914359339926.issue27422@psf.upfronthosting.co.za> Message-ID: <1467311120.13.0.313313923115.issue27422@psf.upfronthosting.co.za> Raymond Hettinger added the comment: It is in-fact problem prone (and not just in Python). The rule is "thread after you fork, not before". Otherwise, the locks used by the thread executor will get duplicated across processes. If one of those processes dies while it has the lock, all of the other processes using that lock will deadlock. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 14:33:29 2016 From: report at bugs.python.org (Brett Cannon) Date: Thu, 30 Jun 2016 18:33:29 +0000 Subject: [issue26664] Misuse of $ in activate.fish of venv In-Reply-To: <1459255585.37.0.253753371111.issue26664@psf.upfronthosting.co.za> Message-ID: <1467311609.62.0.393307607583.issue26664@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- title: find a bug in activate.fish of venv of cpython3.6 -> Misuse of $ in activate.fish of venv _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 14:43:33 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 30 Jun 2016 18:43:33 +0000 Subject: [issue26665] pip is not bootstrapped by default on 2.7 In-Reply-To: <1459261486.77.0.745706792357.issue26665@psf.upfronthosting.co.za> Message-ID: <20160630184330.122165.94869.57F1E28A@psf.io> Roundup Robot added the comment: New changeset 4fc0154ec84a by Brett Cannon in branch '3.5': Issue #26665: Remove mis-use of ``$`` in activate.fish. https://hg.python.org/cpython/rev/4fc0154ec84a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 14:43:33 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 30 Jun 2016 18:43:33 +0000 Subject: [issue26664] Misuse of $ in activate.fish of venv In-Reply-To: <1459255585.37.0.253753371111.issue26664@psf.upfronthosting.co.za> Message-ID: <20160630184330.122165.39385.CF81FF01@psf.io> Roundup Robot added the comment: New changeset 8d7bde14d7a4 by Brett Cannon in branch 'default': Merge from 3.5 for issue #26664 https://hg.python.org/cpython/rev/8d7bde14d7a4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 14:46:36 2016 From: report at bugs.python.org (Brett Cannon) Date: Thu, 30 Jun 2016 18:46:36 +0000 Subject: [issue26664] Misuse of $ in activate.fish of venv In-Reply-To: <1459255585.37.0.253753371111.issue26664@psf.upfronthosting.co.za> Message-ID: <1467312396.43.0.888244156301.issue26664@psf.upfronthosting.co.za> Brett Cannon added the comment: Two things. One, sorry for not getting to this before 3.5.1 got out. It simply slipped off my radar thanks to various other issues that I've been dealing with. It's obviously now fixed. Two, this is not a release blocker. Python itself continues to function properly with this bug and it doesn't prevent you from working with a venv under fish (but I recognize it's an annoyance). ---------- nosy: -larry resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 14:47:38 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 30 Jun 2016 18:47:38 +0000 Subject: [issue22724] byte-compile fails for cross-builds In-Reply-To: <1414194759.57.0.515625475535.issue22724@psf.upfronthosting.co.za> Message-ID: <1467312458.8.0.812564179603.issue22724@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > On Android cross-builds, it should be possible to reproduce the failure when the build system and the host system have the same PLATFORM_TRIPLET I confirm that this is the case. The following backtrace is produced when cross-building and installing Android x86_64 on a linux x86_64: PYTHONPATH=/sdcard/org.bitbucket.pyona/lib/python3.6 \ _PYTHON_PROJECT_BASE=/home/xavier/src/android/pyona/build/python3.6-android-21-x86_64 _PYTHON_HOST_PLATFORM=linux-x86_64 PYTHONPATH=/home/xavier/src/android/pyona/build/python3.6-android-21-x86_64/build/lib.linux-x86_64-3.6:/home/xavier/src/packages/android/cpython/Lib:/home/xavier/src/packages/android/cpython/Lib/plat-x86_64-linux-gnu python3.6 -Wi /sdcard/org.bitbucket.pyona/lib/python3.6/compileall.py \ -d /sdcard/org.bitbucket.pyona/lib/python3.6 -f \ -x 'bad_coding|badsyntax|site-packages|lib2to3/tests/data' \ /sdcard/org.bitbucket.pyona/lib/python3.6 Traceback (most recent call last): File "/sdcard/org.bitbucket.pyona/lib/python3.6/compileall.py", line 17, in import struct File "/sdcard/org.bitbucket.pyona/lib/python3.6/struct.py", line 13, in from _struct import * ImportError: libpython3.6m.so.1.0: cannot open shared object file: No such file or directory make[3]: [Makefile:1270: libinstall] Error 1 (ignored) 'python3.6' is the native interpreter built from the same source tree as the source tree used for the cross-build. PATH has been set so that this native interpreter is run. Running this same command interactively with the native interpreter gives the same result: [xavier at bilboquet python-native]$ PYTHONPATH=/home/xavier/src/android/pyona/build/python3.6-android-21-x86_64/build/lib.linux-x86_64-3.6:/home/xavier/src/packages/android/cpython/Lib:/home/xavier/src/packages/android/cpython/Lib/plat-x86_64-linux-gnu ./python3.6 Python 3.6.0a2+ (default:64ed56fbc5e7+, Jun 27 2016, 10:36:45) [GCC 6.1.1 20160602] on linux Type "help", "copyright", "credits" or "license" for more information. Traceback (most recent call last): File "/home/xavier/config/.pystartup", line 14, in import readline ImportError: libpython3.6m.so.1.0: cannot open shared object file: No such file or directory >>> Cross-building and installing Android i686 on a linux x86_64 with the same Makefile does not cause the problem. Adding -E to PYTHON_FOR_BUILD fixes the x86_64 install. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 14:50:07 2016 From: report at bugs.python.org (Omar Sandoval) Date: Thu, 30 Jun 2016 18:50:07 +0000 Subject: [issue16142] ArgumentParser inconsistent with parse_known_args In-Reply-To: <1349448801.58.0.783623579173.issue16142@psf.upfronthosting.co.za> Message-ID: <1467312607.72.0.405782401202.issue16142@psf.upfronthosting.co.za> Changes by Omar Sandoval : ---------- nosy: +Omar Sandoval _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 14:56:16 2016 From: report at bugs.python.org (erdban fed) Date: Thu, 30 Jun 2016 18:56:16 +0000 Subject: [issue26664] Misuse of $ in activate.fish of venv In-Reply-To: <1459255585.37.0.253753371111.issue26664@psf.upfronthosting.co.za> Message-ID: <1467312976.02.0.0305923758647.issue26664@psf.upfronthosting.co.za> erdban fed added the comment: > Two, this is not a release blocker. Python itself continues to function properly with this bug and it doesn't prevent you from working with a venv under fish (but I recognize it's an annoyance). If you can't load the venv, I think that pretty definitely prevents you from working with one. I'll now have to edit the activation script file manually every time I create a new venv until 3.6 is released. Or revert to 3.5.1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 15:12:25 2016 From: report at bugs.python.org (Marcus Cobden) Date: Thu, 30 Jun 2016 19:12:25 +0000 Subject: [issue27415] BaseEventLoop.create_server does not accept port=None In-Reply-To: <1467211561.08.0.329801464417.issue27415@psf.upfronthosting.co.za> Message-ID: <1467313945.47.0.553468528458.issue27415@psf.upfronthosting.co.za> Marcus Cobden added the comment: I should add that port=0 is an acceptable workaround ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 15:24:50 2016 From: report at bugs.python.org (Brett Cannon) Date: Thu, 30 Jun 2016 19:24:50 +0000 Subject: [issue26664] Misuse of $ in activate.fish of venv In-Reply-To: <1459255585.37.0.253753371111.issue26664@psf.upfronthosting.co.za> Message-ID: <1467314690.14.0.631979134557.issue26664@psf.upfronthosting.co.za> Brett Cannon added the comment: Activation doesn't "load" the Python interpreter in the venv; all it does is tweak shell variables to put the interpreter in venv early on PATH. I personally never use the activate.* scripts and simply directly execute the Python interpreter, e.g. venv/bin/python. The only other thing the activation script does that potentially changes semantics is the setting of $PYTHONHOME which can do manually if you need that specific bit of functionality. You have to realize that there are over 5,000 issues open on bugs.python.org. We are all volunteers working on Python and we do our best to get through issues, but we just don't get to everything on the timeframe people prefer. I realize this issue is important to you, but basically every reported issue is important to someone so every time we prioritize anything over something else we are upsetting someone somewhere. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 15:34:18 2016 From: report at bugs.python.org (Paul Moore) Date: Thu, 30 Jun 2016 19:34:18 +0000 Subject: [issue27417] Call CoInitializeEx on startup In-Reply-To: <1467224377.99.0.571630822652.issue27417@psf.upfronthosting.co.za> Message-ID: <1467315258.29.0.654474047981.issue27417@psf.upfronthosting.co.za> Paul Moore added the comment: I presume by "we" you mean "the core"? There's nothing to stop 3rd party code using COM APIs. The only downside to using COM in (user) Python code at the moment is the need for a dependency on pywin32 (robust, mature, but a big dependency) or comtypes (relatively lightweight, but less mature/well used). Hardly a huge burden. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 15:38:14 2016 From: report at bugs.python.org (Zachary Ware) Date: Thu, 30 Jun 2016 19:38:14 +0000 Subject: [issue26665] pip is not bootstrapped by default on 2.7 In-Reply-To: <1459261486.77.0.745706792357.issue26665@psf.upfronthosting.co.za> Message-ID: <1467315494.19.0.276512108951.issue26665@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- Removed message: http://bugs.python.org/msg269614 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 15:44:35 2016 From: report at bugs.python.org (Paul Moore) Date: Thu, 30 Jun 2016 19:44:35 +0000 Subject: [issue26137] [idea] use the Microsoft Antimalware Scan Interface In-Reply-To: <1453023852.0.0.39090079449.issue26137@psf.upfronthosting.co.za> Message-ID: <1467315875.59.0.553068892793.issue26137@psf.upfronthosting.co.za> Paul Moore added the comment: Thanks for the explanation. Based on what's been said, I'd have no objections to this, on a "you don't pay for what you don't use" basis - i.e., users who don't enable AMSI should not pay any cost for its existence. I'd be extremely happy if Python was viewed as a high-quality option in the server management space, so if this helps in that goal, then that's good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 15:47:31 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 30 Jun 2016 19:47:31 +0000 Subject: [issue27213] Rework CALL_FUNCTION* opcodes In-Reply-To: <1465026334.02.0.369802561902.issue27213@psf.upfronthosting.co.za> Message-ID: <1467316051.56.0.152862816074.issue27213@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Added comments on Rietveld. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 15:51:23 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 30 Jun 2016 19:51:23 +0000 Subject: [issue27421] PPC64LE Fedora 2.7: certificate for hg.python.org has unexpected fingerprint In-Reply-To: <1467287945.31.0.973782054097.issue27421@psf.upfronthosting.co.za> Message-ID: <1467316283.69.0.843215418309.issue27421@psf.upfronthosting.co.za> STINNER Victor added the comment: David Edelsohn: "I have updated the fingerprint in .hgrc." Thanks! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 15:52:42 2016 From: report at bugs.python.org (Zachary Ware) Date: Thu, 30 Jun 2016 19:52:42 +0000 Subject: [issue27421] PPC64LE Fedora 2.7: certificate for hg.python.org has unexpected fingerprint In-Reply-To: <1467287945.31.0.973782054097.issue27421@psf.upfronthosting.co.za> Message-ID: <1467316362.8.0.890902927841.issue27421@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 15:54:05 2016 From: report at bugs.python.org (=?utf-8?q?Tin_Tvrtkovi=C4=87?=) Date: Thu, 30 Jun 2016 19:54:05 +0000 Subject: [issue26664] Misuse of $ in activate.fish of venv In-Reply-To: <1467314690.14.0.631979134557.issue26664@psf.upfronthosting.co.za> Message-ID: Tin Tvrtkovi? added the comment: Thanks for dealing with this, Brett, your efforts are appreciated. :) On Thu, Jun 30, 2016 at 9:24 PM Brett Cannon wrote: > > Brett Cannon added the comment: > > Activation doesn't "load" the Python interpreter in the venv; all it does > is tweak shell variables to put the interpreter in venv early on PATH. I > personally never use the activate.* scripts and simply directly execute the > Python interpreter, e.g. venv/bin/python. The only other thing the > activation script does that potentially changes semantics is the setting of > $PYTHONHOME which can do manually if you need that specific bit of > functionality. > > You have to realize that there are over 5,000 issues open on > bugs.python.org. We are all volunteers working on Python and we do our > best to get through issues, but we just don't get to everything on the > timeframe people prefer. I realize this issue is important to you, but > basically every reported issue is important to someone so every time we > prioritize anything over something else we are upsetting someone somewhere. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 16:18:19 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 30 Jun 2016 20:18:19 +0000 Subject: [issue27405] Ability to trace Tcl commands executed by Tkinter In-Reply-To: <1467101160.96.0.000959009774067.issue27405@psf.upfronthosting.co.za> Message-ID: <1467317899.46.0.108213318921.issue27405@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I meant adding API similar to sys.settrace() for specifying a function that will be called before executing every Tcl command. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 16:20:35 2016 From: report at bugs.python.org (erdban fed) Date: Thu, 30 Jun 2016 20:20:35 +0000 Subject: [issue26664] Misuse of $ in activate.fish of venv In-Reply-To: <1459255585.37.0.253753371111.issue26664@psf.upfronthosting.co.za> Message-ID: <1467318035.09.0.867421870729.issue26664@psf.upfronthosting.co.za> erdban fed added the comment: > Activation doesn't "load" the Python interpreter in the venv; all it does is tweak shell variables to put the interpreter in venv early on PATH. I'm aware. > You have to realize that ... I know it's often a thankless task and that mistakes can and do happen. Not prioritising a two-click fix to a regression that was spotted several months in advance would - in my book - count as such a mistake. Okay, you were preoccupied with other things - that's fine. That's a valid excuse. And if you disagree with the importance of it, that's also fine; I'm not gonna argue my case further. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 16:37:13 2016 From: report at bugs.python.org (Brett Cannon) Date: Thu, 30 Jun 2016 20:37:13 +0000 Subject: [issue26664] Misuse of $ in activate.fish of venv In-Reply-To: <1459255585.37.0.253753371111.issue26664@psf.upfronthosting.co.za> Message-ID: <1467319033.84.0.442713864149.issue26664@psf.upfronthosting.co.za> Brett Cannon added the comment: I wish it was a two-click fix. It's actually a fix-in-3.5-then-test-then-update-Misc/NEWS-then-commit-then-merge-then-verify-again-then-commit-then-push-then-update-the-issue (IOW it's about 8 separate steps). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 17:29:47 2016 From: report at bugs.python.org (Zachary Ware) Date: Thu, 30 Jun 2016 21:29:47 +0000 Subject: [issue23951] Update devguide style to use a similar theme as Docs In-Reply-To: <1429030125.69.0.476464501234.issue23951@psf.upfronthosting.co.za> Message-ID: <1467322187.05.0.421626140106.issue23951@psf.upfronthosting.co.za> Zachary Ware added the comment: Another +1 here, looks good and has some nice improvements. The patch needs some cleanup, though: We don't need the extensions [1], the version switcher, or the susp-ignored file. The templates dir needs some cleanup; we don't need the download page at all, and the indexsidebar.html template needs to be properly updated for the devguide (or removed, but updated would probably be nicer), and indexcontent.html can go away. layout.html could stand some cleanup as well, removing the stuff that doesn't apply to the devguide. rstlint.py can probably stay, it has a few complaints that might be nice to fix. It would be nice to wire it into the Makefile (and make.bat) if it's staying. tools/static/py.png does need to be copied over, though (and currently isn't in the patch); it's used in the upper left corner of the page. With cleanup, though, I'm looking forward to this going in! [1] it might be interesting to look into what extensions from the regular docs could be useful, particularly the 'suspicious' checker ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 17:41:58 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 30 Jun 2016 21:41:58 +0000 Subject: [issue25958] Implicit ABCs have no means of "anti-registration" In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za> Message-ID: <1467322918.86.0.297861273024.issue25958@psf.upfronthosting.co.za> Changes by Ivan Levkivskyi : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 17:50:28 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 30 Jun 2016 21:50:28 +0000 Subject: [issue26141] typing module documentation incomplete In-Reply-To: <1453049740.68.0.762293537242.issue26141@psf.upfronthosting.co.za> Message-ID: <1467323428.58.0.541011427181.issue26141@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: I would like to do this (update the typing docs) at some point before 3.6 beta1. There probably will be some updates to the PEP (it is still provisional), and maybe to typing.py soon. ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 17:53:19 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 30 Jun 2016 21:53:19 +0000 Subject: [issue27405] Ability to trace Tcl commands executed by Tkinter In-Reply-To: <1467101160.96.0.000959009774067.issue27405@psf.upfronthosting.co.za> Message-ID: <1467323599.48.0.348257508306.issue27405@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is preliminary patch. It contains leaks, don't worry. ---------- keywords: +patch Added file: http://bugs.python.org/file43592/tkinter_trace_tcl.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 17:55:39 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 30 Jun 2016 21:55:39 +0000 Subject: [issue26696] Document collections.abc.ByteString In-Reply-To: <1459881544.79.0.834895685887.issue26696@psf.upfronthosting.co.za> Message-ID: <1467323739.03.0.669115403143.issue26696@psf.upfronthosting.co.za> Changes by Ivan Levkivskyi : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 18:04:19 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 30 Jun 2016 22:04:19 +0000 Subject: [issue26477] typing forward references and module attributes In-Reply-To: <1457028467.36.0.208660584048.issue26477@psf.upfronthosting.co.za> Message-ID: <1467324259.92.0.857895359319.issue26477@psf.upfronthosting.co.za> Changes by Ivan Levkivskyi : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 18:05:41 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 30 Jun 2016 22:05:41 +0000 Subject: [issue25830] _TypeAlias: Discrepancy between docstring and behavior In-Reply-To: <1449662252.92.0.779493267097.issue25830@psf.upfronthosting.co.za> Message-ID: <1467324341.27.0.958035116102.issue25830@psf.upfronthosting.co.za> Changes by Ivan Levkivskyi : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 18:07:35 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 30 Jun 2016 22:07:35 +0000 Subject: [issue26075] typing.Union unifies types too broadly In-Reply-To: <1452430654.78.0.244173734721.issue26075@psf.upfronthosting.co.za> Message-ID: <1467324455.19.0.775521948153.issue26075@psf.upfronthosting.co.za> Changes by Ivan Levkivskyi : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 18:12:04 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 30 Jun 2016 22:12:04 +0000 Subject: [issue24379] Add operator.subscript as a convenience for creating slices In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1467324724.12.0.508150809116.issue24379@psf.upfronthosting.co.za> Changes by Ivan Levkivskyi : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 18:31:27 2016 From: report at bugs.python.org (Francisco Couzo) Date: Thu, 30 Jun 2016 22:31:27 +0000 Subject: [issue27427] Math tests Message-ID: <1467325887.57.0.243525279322.issue27427@psf.upfronthosting.co.za> New submission from Francisco Couzo: I added some tests for the math module. ---------- components: Tests files: test_math.patch keywords: patch messages: 269632 nosy: franciscouzo priority: normal severity: normal status: open title: Math tests versions: Python 3.6 Added file: http://bugs.python.org/file43593/test_math.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 18:34:32 2016 From: report at bugs.python.org (Brett Cannon) Date: Thu, 30 Jun 2016 22:34:32 +0000 Subject: [issue27428] Document WindowsRegistryFinder inherits from MetaPathFinder Message-ID: <1467326072.76.0.431868228595.issue27428@psf.upfronthosting.co.za> New submission from Brett Cannon: Currently the docs claim it inherits from importlib.abc.Finder. ---------- assignee: docs at python components: Documentation messages: 269633 nosy: brett.cannon, docs at python priority: normal severity: normal status: open title: Document WindowsRegistryFinder inherits from MetaPathFinder versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 19:28:04 2016 From: report at bugs.python.org (tylerjohnhughes) Date: Thu, 30 Jun 2016 23:28:04 +0000 Subject: [issue27429] xml.sax.saxutils.escape doesn't escape multiple characters safely Message-ID: <1467329284.42.0.570425192888.issue27429@psf.upfronthosting.co.za> New submission from tylerjohnhughes: The escape function appears to go through the list in multiple passes, replacing characters as it encounters them on each pass, rather than traversing the source string and replacing matches in the entities dict. This results in invalid escape strings if a replacement value contains one of the replacement entities. I've attached a file to reproduce the behavior. ---------- components: XML files: escapetest.py messages: 269634 nosy: tylerjohnhughes priority: normal severity: normal status: open title: xml.sax.saxutils.escape doesn't escape multiple characters safely type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file43594/escapetest.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 20:37:12 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 01 Jul 2016 00:37:12 +0000 Subject: [issue26665] pip is not bootstrapped by default on 2.7 In-Reply-To: <1459261486.77.0.745706792357.issue26665@psf.upfronthosting.co.za> Message-ID: <1467333432.8.0.559422975025.issue26665@psf.upfronthosting.co.za> Martin Panter added the comment: Revision 4fc0154ec84a links here, but actually seems to be discussed in Issue 26348 and Issue 26664 instead. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 21:05:35 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 01 Jul 2016 01:05:35 +0000 Subject: [issue27425] Tests fail because of git's newline preferences on Windows In-Reply-To: <1467306989.4.0.803551571995.issue27425@psf.upfronthosting.co.za> Message-ID: <1467335135.16.0.768687036777.issue27425@psf.upfronthosting.co.za> Martin Panter added the comment: If it were me, I might try to use a version of Git that doesn?t mess with the files. But if this becomes a common problem (esp with the move from Mercurial to Git), maybe we can add a ?.gitattributes? file . We aleady seem to have ?.hgeol?. I presume this is going to affect earlier versions too. ---------- components: +Windows nosy: +martin.panter, paul.moore, steve.dower, tim.golden, zach.ware versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 21:11:03 2016 From: report at bugs.python.org (Mark Hammond) Date: Fri, 01 Jul 2016 01:11:03 +0000 Subject: [issue27417] Call CoInitializeEx on startup In-Reply-To: <1467224377.99.0.571630822652.issue27417@psf.upfronthosting.co.za> Message-ID: <1467335463.18.0.797035172678.issue27417@psf.upfronthosting.co.za> Mark Hammond added the comment: > > This may well break things like pythonwin until they also grow support > > for the new param > I expect that, which is why I'm only proposing it for 3.6 onwards. While > adding support for a new major version of Python should be fairly cheap, > it isn't entirely free and so it's the right time to add new complications. My point with that is that pythonwin is a GUI app rarely started by the command-line. It isn't that adding the cmdline support is difficult, more that it's difficult for users to specify it. This will be true for any GUI installed into the start menu (eg, idle) > Nikita: > > COM should be initialized on demand by C modules that need it. They might need STA or > > MTA, it's their choice to make. > And if the C module is the core interpreter (see issue26137 for an example of where > this would be necessary)? If we require user code to initialize COM, this whole > proposal is moot as that is the current state of the world and it does not require > any changes to achieve. I'd be surprised if issue26137 ended up unconditionally doing a malware scan on everything Python ever executes. Thus, I don't see why "I'd like to enable calling CoInitializeEx on Python startup for 3.6" is necessary - just attempting to initialize it immediately before that feature is invoked would be fine and may sidestep the entire issue. Instead of command-line flags to control COM initialization we should add new flags to disable these new features that require COM (and thus also implicitly control whether COM is initialized or not.) IOW, I think it makes sense for the core to initialize COM immediately before it needs to use COM, under the assumption that executing "python" or "python myscript.py" isn't going to need to do that by default. I think initializing COM by default at process startup on the off-chance that some COM-using feature will be invoked is more problematic. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 21:36:05 2016 From: report at bugs.python.org (Emanuel Barry) Date: Fri, 01 Jul 2016 01:36:05 +0000 Subject: [issue27425] Tests fail because of git's newline preferences on Windows In-Reply-To: <1467306989.4.0.803551571995.issue27425@psf.upfronthosting.co.za> Message-ID: <1467336965.94.0.930755409516.issue27425@psf.upfronthosting.co.za> Emanuel Barry added the comment: I agree, but I wouldn't expect my line ending preferences to make tests fail. I think that with the move to GitHub already underway, it's not unreasonable to (at least consider to) add a .gitattributes file. Added Brett to nosy since he's responsible for PEP 512. (I think this should be changed before the final announcement that the cpython repo is on GitHub, but there's no rush until then; although I'm certainly not going to complain if it's done before ;) ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 22:03:11 2016 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 01 Jul 2016 02:03:11 +0000 Subject: [issue26664] Misuse of $ in activate.fish of venv In-Reply-To: <1459255585.37.0.253753371111.issue26664@psf.upfronthosting.co.za> Message-ID: <1467338591.4.0.81696040535.issue26664@psf.upfronthosting.co.za> Xiang Zhang added the comment: Since the bug is fixed, we can also close issue26348. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 23:09:10 2016 From: report at bugs.python.org (Eryk Sun) Date: Fri, 01 Jul 2016 03:09:10 +0000 Subject: [issue27423] Failed assertions when running test.test_os on Windows In-Reply-To: <1467305238.88.0.613411427666.issue27423@psf.upfronthosting.co.za> Message-ID: <1467342550.93.0.56064768336.issue27423@psf.upfronthosting.co.za> Eryk Sun added the comment: The attached patch suppresses the failed-assertion message boxes when running test_os on a debug build. ---------- keywords: +patch nosy: +eryksun stage: needs patch -> patch review Added file: http://bugs.python.org/file43595/issue27423_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 23:51:22 2016 From: report at bugs.python.org (Wei-Cheng Pan) Date: Fri, 01 Jul 2016 03:51:22 +0000 Subject: [issue27413] Add an option to json.tool to bypass non-ASCII characters. In-Reply-To: <1467200969.47.0.983958211319.issue27413@psf.upfronthosting.co.za> Message-ID: <1467345082.61.0.910947528568.issue27413@psf.upfronthosting.co.za> Changes by Wei-Cheng Pan : Removed file: http://bugs.python.org/file43578/json-add-an-option-to-bypass-non-ascii-characters.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 23:52:49 2016 From: report at bugs.python.org (Wei-Cheng Pan) Date: Fri, 01 Jul 2016 03:52:49 +0000 Subject: [issue27413] Add an option to json.tool to bypass non-ASCII characters. In-Reply-To: <1467200969.47.0.983958211319.issue27413@psf.upfronthosting.co.za> Message-ID: <1467345169.46.0.375617538758.issue27413@psf.upfronthosting.co.za> Wei-Cheng Pan added the comment: Use "--no-ensure-ascii" instead. ---------- Added file: http://bugs.python.org/file43596/json-add-an-option-to-bypass-non-ascii-characters.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 30 23:59:12 2016 From: report at bugs.python.org (Paul Winkler) Date: Fri, 01 Jul 2016 03:59:12 +0000 Subject: [issue1349732] urllib.urlencode provides two features in one param Message-ID: <1467345552.16.0.42518391132.issue1349732@psf.upfronthosting.co.za> Paul Winkler added the comment: This was marked as a duplicate of http://bugs.python.org/issue8788 but the doc changes in that issue, and the current docs for 2.7, do not mention anything related to handling of unicode nor how `doseq` affects unicode-related behavior. If we can agree on wording, does 2.7 still get documentation fixes? ---------- nosy: +slinkp _______________________________________ Python tracker _______________________________________