From report at bugs.python.org Fri Jul 1 00:26:11 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Jul 2016 04:26:11 +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: <1467347171.34.0.752022070501.issue27423@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 00:33:59 2016 From: report at bugs.python.org (Emanuel Barry) Date: Fri, 01 Jul 2016 04:33:59 +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: <1467347639.4.0.632359871157.issue27423@psf.upfronthosting.co.za> Emanuel Barry added the comment: I'm not sure about the patch - sure, the messages might go away, but I find it concerning that the assertions are failing to begin with. Of course, it only happens when in debug (and this might be a non-issue in practice, I haven't checked), but shouldn't we fix this in the C code? As I understand it though, that part of code is out of Python's control, so there might not be much we can do... But I'm probably overthinking everything again ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 00:37:39 2016 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 01 Jul 2016 04:37:39 +0000 Subject: [issue26348] activate.fish sets VENV prompt incorrectly In-Reply-To: <1455282539.52.0.733684318611.issue26348@psf.upfronthosting.co.za> Message-ID: <1467347859.41.0.491974634251.issue26348@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 00:42:23 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 01 Jul 2016 04:42:23 +0000 Subject: [issue1349732] urllib.urlencode provides two features in one param Message-ID: <1467348143.04.0.459321846328.issue1349732@psf.upfronthosting.co.za> Terry J. Reedy added the comment: 2.7 can get doc changes if a core developer wants to push it. ---------- versions: -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 01:24:36 2016 From: report at bugs.python.org (Eryk Sun) Date: Fri, 01 Jul 2016 05:24:36 +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: <1467350676.76.0.948801134496.issue27423@psf.upfronthosting.co.za> Eryk Sun added the comment: test_os intentionally operates on invalid file descriptors. In the Windows CRT this leads to failed assertions, such as from its _VALIDATE_RETURN macro. This macro would also call the default invalid parameter handler, which would kill the process, but that's disabled in 3.5+ via _Py_BEGIN_SUPPRESS_IPH. That leaves the message box for failed assertions in debug builds [1]. On entry, support.SuppressCrashReport calls the CRT functions _CrtSetReportMode [2] and _CrtSetReportFile [3] to ensure that failed assertions are instead printed to stderr. These functions are available in a debug build of the msvcrt module. [1]: https://msdn.microsoft.com/en-us/library/9sb57dw4.aspx [2]: https://msdn.microsoft.com/en-us/library/1y71x448.aspx [3]: https://msdn.microsoft.com/en-us/library/a68f826y.aspx ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 01:27:58 2016 From: report at bugs.python.org (Steve Dower) Date: Fri, 01 Jul 2016 05:27:58 +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: <1467350878.78.0.319910914058.issue27423@psf.upfronthosting.co.za> Steve Dower added the comment: The warnings are expected - Python has to be able to handle arbitrarily bad parameters/use without crashing, while the CRT assumes that bugs belong to the direct caller who needs to fix them. As a result, it will assert and terminate for blatantly incorrect operations. A while back we discussed suppressing these warnings by default to stop people worrying, while leaving them enabled for the build bots where those analysing the results are more likely to be aware of the intricacies. Of course, if the assert dialog is actually showing, we have an issue. If it's only the printed warning then it's expected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 02:10:50 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Jul 2016 06:10:50 +0000 Subject: [issue18726] json functions have too many positional parameters In-Reply-To: <1376392694.75.0.457946059126.issue18726@psf.upfronthosting.co.za> Message-ID: <1467353450.82.0.991970692025.issue18726@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 Fri Jul 1 02:25:01 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Jul 2016 06:25:01 +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: <1467354301.14.0.755287104212.issue23908@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. Can anybody please test the patch on Windows? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 03:36:21 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 01 Jul 2016 07:36:21 +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: <1467358581.79.0.0218350041796.issue27413@psf.upfronthosting.co.za> Berker Peksag added the comment: The patch needs tests and documentation. > + parser.add_argument('--no-ensure-ascii', action='store_true', default=False, I'd go with ``action='store_false', default=True``. ---------- nosy: +berker.peksag stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 03:42:00 2016 From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=) Date: Fri, 01 Jul 2016 07:42:00 +0000 Subject: [issue27430] Spelling fixes Message-ID: <1467358920.61.0.353928601124.issue27430@psf.upfronthosting.co.za> Changes by Ville Skytt? : ---------- files: spelling.patch keywords: patch nosy: scop priority: normal severity: normal status: open title: Spelling fixes type: enhancement Added file: http://bugs.python.org/file43597/spelling.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 04:11:59 2016 From: report at bugs.python.org (SilentGhost) Date: Fri, 01 Jul 2016 08:11:59 +0000 Subject: [issue27430] Spelling fixes Message-ID: <1467360719.93.0.760461107439.issue27430@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python stage: -> patch review versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 04:29:55 2016 From: report at bugs.python.org (Steve Piercy) Date: Fri, 01 Jul 2016 08:29:55 +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: <1467361795.37.0.249533602778.issue27285@psf.upfronthosting.co.za> Steve Piercy added the comment: Patch attached for review. Notes: - I built the docs using Sphinx 1.4.1, whereas I think 1.3.3 is in use in production. If you upgrade, you will need to specify the language for syntax highlighting, else you will get hundreds of these error messages: /Users/stevepiercy/projects/cpython/Doc/distutils/examples.rst:250: WARNING: Could not lex literal_block as "python3". Highlighting skipped. I made my changes accordingly, as they are backward compatible to Sphinx 1.3.3 and will be one fewer thing to update in future releases. - I removed the file Doc/using/scripts.rst because it became obsolete. This caused warnings in Doc/whatsnew/3.3.rst and Doc/whatsnew/3.4.rst which reference the obsolete file. - I updated a lot of links to https://packaging.python.org/ and others to save a redirect and to get link checking to pass. - I replaced confusing colloquialisms of "env", "venv", and "virtualenv" with "virtual environment" as appropriate. This clarifies that a virtual environment is the thing created, whereas `venv`, `pyvenv`, and `virtualenv` are modules/scripts/commands that create a virtual environment, or that "env" is the name of a directory. - Minor grammar, punctuation, and reST fixes. ---------- hgrepos: +346 keywords: +patch Added file: http://bugs.python.org/file43598/pyvenv-to-venv.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 05:15:50 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 01 Jul 2016 09:15:50 +0000 Subject: [issue27430] Spelling fixes Message-ID: <20160701091547.11279.25003.F8AD8153@psf.io> New submission from Roundup Robot: New changeset ab6129af2a5c by Berker Peksag in branch '3.5': Issue #27430: Fix typos, patch by scop. https://hg.python.org/cpython/rev/ab6129af2a5c New changeset 97b22fe37af1 by Berker Peksag in branch 'default': Issue #27430: Merge from 3.5 https://hg.python.org/cpython/rev/97b22fe37af1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 05:16:15 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 01 Jul 2016 09:16:15 +0000 Subject: [issue27430] Spelling fixes In-Reply-To: <20160701091547.11279.25003.F8AD8153@psf.io> Message-ID: <1467364575.64.0.417972946672.issue27430@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks. ---------- nosy: +berker.peksag resolution: -> fixed stage: patch review -> resolved status: open -> closed type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 05:17:42 2016 From: report at bugs.python.org (Sander Steffann) Date: Fri, 01 Jul 2016 09:17:42 +0000 Subject: [issue27431] Shelve pickle version error Message-ID: <1467364662.95.0.314062070458.issue27431@psf.upfronthosting.co.za> New submission from Sander Steffann: The "class shelve.Shelf(dict, protocol=None, writeback=False, keyencoding='utf-8')" section still says "By default, version 0 pickles are used to serialize values.". This is incorrect. The default version has been 3 since this commit: https://hg.python.org/cpython/file/f351fb7ea179/Lib/shelve.py ---------- assignee: docs at python components: Documentation messages: 269652 nosy: Sander Steffann, docs at python priority: normal severity: normal status: open title: Shelve pickle version error type: enhancement versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 05:27:49 2016 From: report at bugs.python.org (Camilla Ke) Date: Fri, 01 Jul 2016 09:27:49 +0000 Subject: [issue27432] Unittest truncating of error message not works Message-ID: <1467365269.89.0.517880663648.issue27432@psf.upfronthosting.co.za> New submission from Camilla Ke: Builtin assert methods output messages no matter how length is the output messages. However, content with exceeding length should be truncated. I found an error in the function. The function is safe_repr() in util.py if len(result) > _MAX_LENGTH, it should return truncated content, but "short" is default to False. unittest/util.py def safe_repr(obj, short=False): try: result = repr(obj) except Exception: result = object.__repr__(obj) if not short or len(result) < _MAX_LENGTH: return result return result[:_MAX_LENGTH] + ' [truncated]...' ---------- components: Library (Lib) messages: 269653 nosy: Camilla Ke priority: normal severity: normal status: open title: Unittest truncating of error message not works type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 05:31:30 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 01 Jul 2016 09:31:30 +0000 Subject: [issue27431] Shelve pickle version error In-Reply-To: <1467364662.95.0.314062070458.issue27431@psf.upfronthosting.co.za> Message-ID: <20160701093127.72498.90253.4DF3C7B1@psf.io> Roundup Robot added the comment: New changeset b2c3837f7833 by Berker Peksag in branch '3.5': Issue #27431: Update default protocol version in shelve.Shelf() documentation https://hg.python.org/cpython/rev/b2c3837f7833 New changeset 908b801f8a62 by Berker Peksag in branch 'default': Issue #27431: Merge from 3.5 https://hg.python.org/cpython/rev/908b801f8a62 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 05:33:34 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 01 Jul 2016 09:33:34 +0000 Subject: [issue27431] Shelve pickle version error In-Reply-To: <1467364662.95.0.314062070458.issue27431@psf.upfronthosting.co.za> Message-ID: <1467365614.2.0.687937085434.issue27431@psf.upfronthosting.co.za> Berker Peksag added the comment: Good catch, thanks for the report! 3.2, 3.3 and 3.4 are now in security-fix-only so their docs won't be updated. ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed type: enhancement -> behavior versions: -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 06:14:24 2016 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 01 Jul 2016 10:14:24 +0000 Subject: [issue27429] xml.sax.saxutils.escape doesn't escape multiple characters safely In-Reply-To: <1467329284.42.0.570425192888.issue27429@psf.upfronthosting.co.za> Message-ID: <1467368064.04.0.148325583841.issue27429@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 06:25:52 2016 From: report at bugs.python.org (Tobias Burnus (PDF)) Date: Fri, 01 Jul 2016 10:25:52 +0000 Subject: [issue27433] Missing "as err" in Lib/socket.py Message-ID: <1467368752.52.0.502124517419.issue27433@psf.upfronthosting.co.za> New submission from Tobias Burnus (PDF): Cf. https://hg.python.org/cpython/file/tip/Lib/socket.py#l261 In _sendfile_use_sendfile, one has: try: fsize = os.fstat(fileno).st_size except OSError: raise _GiveupOnSendfile(err) # not a regular file I think the "err" in the last line will only work if there is an "as err" in the "except" line. ---------- components: Library (Lib) messages: 269656 nosy: Tobias Burnus (PDF) priority: normal severity: normal status: open title: Missing "as err" in Lib/socket.py versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 06:42:42 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 01 Jul 2016 10:42:42 +0000 Subject: [issue27433] Missing "as err" in Lib/socket.py In-Reply-To: <1467368752.52.0.502124517419.issue27433@psf.upfronthosting.co.za> Message-ID: <1467369762.9.0.408477208155.issue27433@psf.upfronthosting.co.za> Berker Peksag added the comment: This is a duplicate of issue 26384. ---------- nosy: +berker.peksag resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> UnboundLocalError in socket._sendfile_use_sendfile type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 07:37:40 2016 From: report at bugs.python.org (INADA Naoki) Date: Fri, 01 Jul 2016 11:37:40 +0000 Subject: [issue27424] Failures in test.test_logging In-Reply-To: <1467306001.82.0.0686720653934.issue27424@psf.upfronthosting.co.za> Message-ID: <1467373060.01.0.0939392189483.issue27424@psf.upfronthosting.co.za> INADA Naoki added the comment: Maybe, `socket.getfqdn()` returns non-ASCII string in your environment. smtpd.py has `-u` option which enables utf-8 support. smtpd.SMTPServer has enable_SMTPUTF8 option. test_logging.TestSMTPServer should enable this option. Could you test adding `enable_SMTPUTF8=True` kwarg here? https://github.com/python/cpython/blob/master/Lib/test/test_logging.py#L682-L683 ---------- nosy: +naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 07:41:27 2016 From: report at bugs.python.org (And Clover) Date: Fri, 01 Jul 2016 11:41:27 +0000 Subject: [issue20770] Inform caller of smtplib STARTTLS failures In-Reply-To: <1393352419.14.0.647705184863.issue20770@psf.upfronthosting.co.za> Message-ID: <1467373287.57.0.0956622876293.issue20770@psf.upfronthosting.co.za> And Clover added the comment: This is CVE-2016-0772 and appears to have been fixed properly with an exception here: https://hg.python.org/cpython/rev/d590114c2394 (py3) https://hg.python.org/cpython/rev/b3ce713fb9be (py2) ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 08:02:04 2016 From: report at bugs.python.org (koobs) Date: Fri, 01 Jul 2016 12:02:04 +0000 Subject: [issue22928] HTTP header injection in urrlib2/urllib/httplib/http.client (CVE-2016-5699) In-Reply-To: <1416797425.29.0.948172439575.issue22928@psf.upfronthosting.co.za> Message-ID: <1467374524.17.0.798043868255.issue22928@psf.upfronthosting.co.za> koobs added the comment: 3.3 is supported for security related fixes until September 2017 [1], but only 3.4, 3.5 and 2.7 have received the backport, reopen for outstanding merge [1] https://docs.python.org/devguide/#status-of-python-branches Update summary to reflect the RedHat CVE that was assigned to this issue. ---------- keywords: +security_issue nosy: +koobs resolution: fixed -> status: closed -> open title: HTTP header injection in urrlib2/urllib/httplib/http.client -> HTTP header injection in urrlib2/urllib/httplib/http.client (CVE-2016-5699) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 08:02:37 2016 From: report at bugs.python.org (koobs) Date: Fri, 01 Jul 2016 12:02:37 +0000 Subject: [issue22928] HTTP header injection in urrlib2/urllib/httplib/http.client (CVE-2016-5699) In-Reply-To: <1416797425.29.0.948172439575.issue22928@psf.upfronthosting.co.za> Message-ID: <1467374557.59.0.691409096261.issue22928@psf.upfronthosting.co.za> Changes by koobs : ---------- versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 08:08:23 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Jul 2016 12:08:23 +0000 Subject: [issue22928] HTTP header injection in urrlib2/urllib/httplib/http.client (CVE-2016-5699) In-Reply-To: <1416797425.29.0.948172439575.issue22928@psf.upfronthosting.co.za> Message-ID: <1467374903.86.0.846300513834.issue22928@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: serhiy.storchaka -> georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 08:14:45 2016 From: report at bugs.python.org (=?utf-8?b?TMOhc3psw7MgS8Ohcm9seWk=?=) Date: Fri, 01 Jul 2016 12:14:45 +0000 Subject: [issue26664] Misuse of $ in activate.fish of venv In-Reply-To: <1459255585.37.0.253753371111.issue26664@psf.upfronthosting.co.za> Message-ID: <1467375285.22.0.282280753001.issue26664@psf.upfronthosting.co.za> L?szl? K?rolyi added the comment: +1 here, broken on homebrew cpython > 3.5.1 (a.k.a. 3.5.2) ---------- nosy: +karolyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 08:18:40 2016 From: report at bugs.python.org (INADA Naoki) Date: Fri, 01 Jul 2016 12:18:40 +0000 Subject: [issue26110] Speedup method calls 1.2x In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za> Message-ID: <1467375520.47.0.955053192869.issue26110@psf.upfronthosting.co.za> INADA Naoki added the comment: Updated, based on 102241:908b801f8a62 ---------- nosy: +naoki Added file: http://bugs.python.org/file43599/call_method_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 08:23:12 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Jul 2016 12:23:12 +0000 Subject: [issue26984] int() can return not exact int instance In-Reply-To: <1462802551.63.0.282711121635.issue26984@psf.upfronthosting.co.za> Message-ID: <1467375792.52.0.335086308166.issue26984@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Proposed patch makes int() always returning exact int. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file43600/int_exact.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 08:38:57 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 01 Jul 2016 12:38:57 +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: <1467376737.3.0.568494297651.issue27425@psf.upfronthosting.co.za> R. David Murray added the comment: Yes .gitattributes looks like the correct solution. The problem is that most of the text files we *want* git to transform per platform, it's just a few that we don't. Mercurial actually added support for this for us when we switched to it. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 08:46:57 2016 From: report at bugs.python.org (INADA Naoki) Date: Fri, 01 Jul 2016 12:46:57 +0000 Subject: [issue26110] Speedup method calls 1.2x In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za> Message-ID: <1467377217.28.0.786740453286.issue26110@psf.upfronthosting.co.za> INADA Naoki added the comment: Oops, previous patch doesn't update magic number in PC/launcher.c Should I update it? Or don't touch it to avoid additional conflicts? ---------- Added file: http://bugs.python.org/file43601/call_method_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 08:54:17 2016 From: report at bugs.python.org (Thomas Heller) Date: Fri, 01 Jul 2016 12:54:17 +0000 Subject: [issue27417] Call CoInitializeEx on startup In-Reply-To: <1467224377.99.0.571630822652.issue27417@psf.upfronthosting.co.za> Message-ID: <1467377657.75.0.29061666224.issue27417@psf.upfronthosting.co.za> Changes by Thomas Heller : ---------- nosy: +theller _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 08:54:38 2016 From: report at bugs.python.org (Thomas Heller) Date: Fri, 01 Jul 2016 12:54:38 +0000 Subject: [issue26137] [idea] use the Microsoft Antimalware Scan Interface In-Reply-To: <1453023852.0.0.39090079449.issue26137@psf.upfronthosting.co.za> Message-ID: <1467377678.9.0.358160063397.issue26137@psf.upfronthosting.co.za> Changes by Thomas Heller : ---------- nosy: +theller _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 09:00:22 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 01 Jul 2016 13:00:22 +0000 Subject: [issue27434] cross-building python 3.6 with an older interpreter fails Message-ID: <1467378022.01.0.957641757812.issue27434@psf.upfronthosting.co.za> New submission from Xavier de Gaye: Cross-building the 3.6 source with PYTHON_FOR_BUILD using archlinux python 3.5.1 as found in PATH, fails with: _PYTHON_PROJECT_BASE=/home/xavier/src/android/pyona/build/python3.6-android-21-x86 _PYTHON_HOST_PLATFORM=linux-x86 PYTHONPATH=/home/xavier/src/packages/android/cpython/Lib:/home/xavier/src/packages/android/cpython/Lib/plat-i386-linux-gnu python3 -S -m sysconfig --generate-posix-vars ;\ if test $? -ne 0 ; then \ echo "generate-posix-vars failed" ; \ rm -f ./pybuilddir.txt ; \ exit 1 ; \ fi Could not import runpy module Traceback (most recent call last): File "/home/xavier/src/packages/android/cpython/Lib/runpy.py", line 15, in import importlib.util File "/home/xavier/src/packages/android/cpython/Lib/importlib/util.py", line 25 raise ValueError(f'no package specified for {repr(name)} ' ^ SyntaxError: invalid syntax generate-posix-vars failed The reason is that the syntax of formatted string literals is unknown to python 3.5. ---------- components: Cross-Build messages: 269666 nosy: Alex.Willmer, doko, xdegaye priority: normal severity: normal stage: needs patch status: open title: cross-building python 3.6 with an older interpreter fails type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 09:45:39 2016 From: report at bugs.python.org (Wei-Cheng Pan) Date: Fri, 01 Jul 2016 13:45:39 +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: <1467380739.8.0.855357380939.issue27413@psf.upfronthosting.co.za> Wei-Cheng Pan added the comment: > The patch needs tests and documentation. Ok, I'll update it later. >> + parser.add_argument('--no-ensure-ascii', action='store_true', default=False, >I'd go with ``action='store_false', default=True``. If I'm not misreading your comment, this will change the original behavior, right? (because options.no_ensure_ascii will be set to True by default) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 09:52:20 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 01 Jul 2016 13:52:20 +0000 Subject: [issue27432] Unittest truncating of error message not works In-Reply-To: <1467365269.89.0.517880663648.issue27432@psf.upfronthosting.co.za> Message-ID: <1467381140.74.0.300880556397.issue27432@psf.upfronthosting.co.za> R. David Murray added the comment: This is by design. The short option was introduced to use in specific asserts (assertDictEqual and assertMultilineEqual; see 8b8701551253). These were later enhanced to do an even better job of abbreviating the output usefully, but the short option on safe_repr was not removed even though it is no longer used, for backward compatibility reasons. If you would like for there to be a way to toggle safe_repr's default, that would be a new feature request, and seems like a reasononable feature to me. The new feature should incorporate a way to set _MAX_LENGTH as well. ---------- nosy: +r.david.murray type: behavior -> enhancement versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 10:10:52 2016 From: report at bugs.python.org (Demur Rumed) Date: Fri, 01 Jul 2016 14:10:52 +0000 Subject: [issue27213] Rework CALL_FUNCTION* opcodes In-Reply-To: <1465026334.02.0.369802561902.issue27213@psf.upfronthosting.co.za> Message-ID: <1467382252.96.0.604395587485.issue27213@psf.upfronthosting.co.za> Demur Rumed added the comment: callfunc3 addresses most feedback. Doesn't address _PyEval_EvalCodeWithName2 code bloat, & I disagree with mentioning BUILD_MAP_UNPACK_WITH_CALL change in magic number update as the ABI of BUILD_MAP_UNPACK_WITH_CALL is unchanged. ie if we were to implement #27358 after this there would be no need to bump the magic number One thing which looks odd to me is the INCREF/DECREF calls on function objects surrounding calls. Especially odd is CALL_FUNCTION_EX where we finish with two calls to Py_DECREF(func). It shows up in IMPORT_NAME too ---------- Added file: http://bugs.python.org/file43602/callfunc3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 10:15:46 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 01 Jul 2016 14:15:46 +0000 Subject: [issue27424] Failures in test.test_logging In-Reply-To: <1467306001.82.0.0686720653934.issue27424@psf.upfronthosting.co.za> Message-ID: <1467382546.71.0.991308438775.issue27424@psf.upfronthosting.co.za> R. David Murray added the comment: Domain names should never have non-ascii in them. They should be IDNA encoded. There is a known problem where Windows will return non-ascii domain names if the local hostname is configured naively (see issue 9377). SMTPUTF8 might be a workaround in smtpd's case, since I think it will allow handling of such domain names, but that could actually be considered an RFC violation in smtpd if it works :) That said, looking at the traceback I'm not convinced that's the problem. The test using support.HOST, and that is 127.0.0.1. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 10:18:14 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 01 Jul 2016 14:18:14 +0000 Subject: [issue20770] Inform caller of smtplib STARTTLS failures In-Reply-To: <1393352419.14.0.647705184863.issue20770@psf.upfronthosting.co.za> Message-ID: <1467382694.7.0.488047736271.issue20770@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 10:19:51 2016 From: report at bugs.python.org (Matthias Klose) Date: Fri, 01 Jul 2016 14:19:51 +0000 Subject: [issue27434] cross-building python 3.6 with an older interpreter fails In-Reply-To: <1467378022.01.0.957641757812.issue27434@psf.upfronthosting.co.za> Message-ID: <1467382791.88.0.788123106346.issue27434@psf.upfronthosting.co.za> Matthias Klose added the comment: yes, I think we have to limit the choice of the interpreter for the build to the same major version. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 10:22:16 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Jul 2016 14:22:16 +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: <1467382936.41.0.684168154617.issue27007@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 10:23:16 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 01 Jul 2016 14:23:16 +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: <20160701142306.9110.41989.7F542EAE@psf.io> Roundup Robot added the comment: New changeset 62375fd21de8 by Serhiy Storchaka in branch 'default': Issue #27007: The fromhex() class methods of bytes and bytearray subclasses https://hg.python.org/cpython/rev/62375fd21de8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 10:23:58 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Jul 2016 14:23:58 +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: <1467383038.91.0.129826128578.issue27007@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 Jul 1 10:35:00 2016 From: report at bugs.python.org (aixtools) Date: Fri, 01 Jul 2016 14:35:00 +0000 Subject: [issue27435] ctypes and AIX - also for 2.7.X (and later) Message-ID: <1467383699.63.0.495142233463.issue27435@psf.upfronthosting.co.za> New submission from aixtools: I am opening a new issue # - about the same problem described in 26439, but now calling it a bug rather than a behavior change. Then I did not know better - all was new, and as the "new" kid I felt uncomfortable calling it a bug - when maybe it was just behavior I did not understand However, with the feedback from code review I am beginning to understand what the ctypes functionality is: ctypes.find_library() and cdll.LoadLibrary (aka CDLL) in __init__.py it is clear that there is one entry point for LoadLibrary. For find_library(), I assume overtime, the development led to six (6) definitions - and I am proposing a 7th. The pseudo_code is roughly this (although import ctypes._$_platform._xxx may be incorrect syntax) def find_library(name) import os,sys _platform = sys.platform import ctypes._$_platform._find_library as _find_library return(_find_library(name)) Unclear is how a regular .so file should be treated by find_library() when the actual file is not prefixed by the string "lib", e.g., sudoers.so - should it only look for libsudoers.so even though Currently it is "defined" 7 times (including the definition I added at line 79) because - again - util.py defines find_library several times - only one of the definitions is called dependent on the os.name or os.name + platform. Within the os.name() and sys.platform code block there are sufficient "liberities" to call external programs used to determine where (i.e., find) the library is - and what it's correct prefix and suffix is. +6 # find_library(name) returns the pathname of a library, or None. +49 def find_library(name): in block if os.name == "nt" +71 def find_library(name): if os.name == "ce" return None +79 def find_library(name): if sys.platform.startswith("aix") return ctypes._aixutils.find_library(name) +84 def find_library(name): elif os.name == "posix" and sys.platform == "darwin": +95 elif os.name == "posix": +177 def find_library(name): inside: if (sys.platform.startswith("freebsd") or sys.platform.startswith("openbsd") or sys.platform.startswith("dragonfly")): +217 def find_library(name, is64 = False): inside: elif sys.platform == "sunos5": +220 else: +249 def find_library(name): +250 return _findSoname_ldconfig(name) or _get_soname(_findLib_gcc(name)) ++++++ Getting back to my patch development - initially I was adding code to both util.py and __init__.py and putting everything in " startswith("aix")" blocks. As I thought, in error, find_library() was to make visible what CDLL was finding on it's own I was also doing find_library() like behavior. Rather than have the same code in two files I moved the code into a new file - now named _aixutils.py. So, this looks like a design change, but it is not. All this code could be re-indented and inserted into util.py. IMHO, in a separate file the changes are easier to follow. If a seperate file means it cannot be accepted into python-2.7.X then the code needs to be moved back into util.py Note: the extra tests added to util.py are only for my enjoyment, i.e., verification of several cases I have experienced while porting other packages. Think of them as not being there (for now, if not for always). Once I knew what CDLL(None) was suppossed to That is why my first patch had CDLL() also calling ctypes._aixutils - to only edit once. Once I learned how wrong I was - that was removed - and it just remained this way as "eye-candy". +++ Closing +++ find_library() is defined multiple times, so adding one for aix is not a design change, i.e., behavior modification rather, find_library - as defined for aix in "default block" (elif os.name = "posix": ... else: ...) specifically calling _findSoname_ldconfig(name) or _get_soname(_findLib_gcc(name)) is a "bug of ommission" because the programs the two routines called depend on: ldconfig and gcc are not, normally present on AIX. My patch is a different way changing line 250 from return _findSoname_ldconfig(name) or _get_soname(_findLib_gcc(name)) to return _findSoname_ldconfig(name) or _get_soname(_findLib_gcc(name)) or _findAIXmember(name) or _find_Soname_dump(name) with, of course def _findAIXmember() and def _findSoname_dump() defined within the limits of util.py Instead, I have "hard-coded" an approach similar to the psuedo code example. +++ Disclaimer :P +++ As I am still relatively new, if I am still not understanding the official definition of ctypes.find_library() - I apologize. util.py is, due to is many defines of find_library() was difficult for me to grasp the difference between permissible and "not done". Going back to the earliest documentation I could find for ctypes https://docs.python.org/2.6/library/ctypes.html (new in 2.5) the key lines are: ctypes exports the cdll, and on Windows windll and oledll objects, for loading dynamic link libraries. You load libraries by accessing them as attributes of these objects. cdll loads libraries which export functions using the standard cdecl calling convention, while ... For find_library() - the documentation is quite clear - find_library is system dependent - mentioning that "linux", as one example, uses ldconfig to find libraries: 15.15.2.1. Finding shared libraries When programming in a compiled language, shared libraries are accessed when compiling/linking a program, and when the program is run. The purpose of the find_library() function is to locate a library in a way similar to what the compiler does (on platforms with several versions of a shared library the most recent should be loaded), while the ctypes library loaders act like when a program is run, and call the runtime loader directly. The ctypes.util module provides a function which can help to determine the library to load. ctypes.util.find_library(name) Try to find a library and return a pathname. name is the library name without any prefix like lib, suffix like .so, .dylib or version number (this is the form used for the posix linker option -l). If no library can be found, returns None. The exact functionality is system dependent. On Linux, find_library() tries to run external programs (/sbin/ldconfig, gcc, and objdump) to find the library file. It returns the filename of the library file. .... In short, I believe there is sufficient clarity in the initial documentation - that it is an "error of ommission" (so maybe "shame on IBM" that noone took this up years ago) and has every right as Linux, Solaris, openBSD, etc.. to have the system dependent glue that is needed to work "natively" on the platform. -- but I am biased -- so if I am wrong - please be kind. Note: goal is to have the new patch, still with _aixutil.py as a matter of textual clarity rather than as language/module syntax. If being in a different file is the primary/only objection then, when I am again able to devote time - I will move the code into an "aix" block within util.py ---------- components: ctypes messages: 269673 nosy: aixtools at gmail.com priority: normal severity: normal status: open title: ctypes and AIX - also for 2.7.X (and later) versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 10:57:50 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 01 Jul 2016 14:57:50 +0000 Subject: [issue26765] Factor out common bytes and bytearray implementation In-Reply-To: <1460707559.13.0.709090380773.issue26765@psf.upfronthosting.co.za> Message-ID: <20160701145746.32010.23724.94EEE03C@psf.io> Roundup Robot added the comment: New changeset b0087e17cd5e by Serhiy Storchaka in branch 'default': Issue #26765: Moved wrappers for bytes and bytearray methods to common header https://hg.python.org/cpython/rev/b0087e17cd5e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 11:15:21 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 01 Jul 2016 15:15:21 +0000 Subject: [issue22724] byte-compile fails for cross-builds In-Reply-To: <1414194759.57.0.515625475535.issue22724@psf.upfronthosting.co.za> Message-ID: <1467386121.25.0.984969238428.issue22724@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Adding -E to PYTHON_FOR_BUILD fixes the x86_64 install because in my Android cross-build setup, the native interpreter is built from the same source tree as the cross-build. However, currently the interpreter used for the cross-build may be any interpreter found in PATH and can import an incorrect importlib.util.MAGIC_NUMBER if PYTHONPATH is not set properly. So this new patch does not use -E and splits PYTHON_FOR_BUILD into two variables, PY_BUILD_ENVIRON that sets the environment variables and PYTHON_FOR_BUILD, the interpreter. PY_BUILD_ENVIRON is not used when running compileall. Tested by running the test suite on the Android i686 and x86_64 emulators (excluding test_ctypes that segfaults python on x86_64). The tests cannot be run with a cross-build where PYTHON_FOR_BUILD is python 3.5.1 because of issue 27434. ---------- Added file: http://bugs.python.org/file43603/py_build_environ.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 11:33:27 2016 From: report at bugs.python.org (David Beazley) Date: Fri, 01 Jul 2016 15:33:27 +0000 Subject: [issue27436] Strange code in selectors.KqueueSelector Message-ID: <1467387207.61.0.938158843585.issue27436@psf.upfronthosting.co.za> New submission from David Beazley: Not so much a bug, but an observation based on reviewing the implementation of the selectors.KqueueSelector class. In that class there is the select() method: def select(self, timeout=None): timeout = None if timeout is None else max(timeout, 0) max_ev = len(self._fd_to_key) ready = [] try: kev_list = self._kqueue.control(None, max_ev, timeout) except InterruptedError: return ready for kev in kev_list: fd = kev.ident flag = kev.filter events = 0 if flag == select.KQ_FILTER_READ: events |= EVENT_READ if flag == select.KQ_FILTER_WRITE: events |= EVENT_WRITE key = self._key_from_fd(fd) if key: ready.append((key, events & key.events)) return ready The for-loop looks like it might be checking flags against some kind of bit-mask in order to build events. However, if so, the code just looks wrong. Wouldn't it use the '&' operator (or some variant) instead of '==' like this? for kev in kev_list: fd = kev.ident flag = kev.filter events = 0 if flag & select.KQ_FILTER_READ: events |= EVENT_READ if flag & select.KQ_FILTER_WRITE: events |= EVENT_WRITE If it's not a bit-mask, then wouldn't the code be simplified by something like this? for kev in kev_list: fd = kev.ident flag = kev.filter if flag == select.KQ_FILTER_READ: events = EVENT_READ elif flag == select.KQ_FILTER_WRITE: events = EVENT_WRITE Again, not sure if this is a bug or not. It's just something that looks weirdly off. ---------- components: Library (Lib) messages: 269676 nosy: dabeaz priority: normal severity: normal status: open title: Strange code in selectors.KqueueSelector type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 12:17:45 2016 From: report at bugs.python.org (Zachary Ware) Date: Fri, 01 Jul 2016 16:17:45 +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: <1467389865.92.0.334171160027.issue23908@psf.upfronthosting.co.za> Zachary Ware added the comment: I get one test failure: ERROR: test_u (__main__.Unicode_TestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "P:\ath\to\cpython\lib\test\test_getargs2.py", line 782, in test_u self.assertEqual(getargs_u(u'nul:\0'), u'nul:') TypeError: argument 1 must be unicode without null characters, not unicode All other tests appear to pass. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 12:20:06 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 01 Jul 2016 16:20:06 +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: <1467390006.1.0.92679231901.issue27285@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks for the patch, Steve! Since this is a bug fix I may take until after 3.6b1 goes out to get reviewed and committed since I need to get any semantic changes in before then (b1 is due out in Sep). So if this patch lingers for a couple months, that will be why. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 12:59:23 2016 From: report at bugs.python.org (Akira Li) Date: Fri, 01 Jul 2016 16:59:23 +0000 Subject: [issue27079] Bugs in curses.ascii predicates In-Reply-To: <1463861399.98.0.689088484472.issue27079@psf.upfronthosting.co.za> Message-ID: <1467392363.21.0.445435849169.issue27079@psf.upfronthosting.co.za> Akira Li added the comment: I'm not sure anything should be done (e.g., it is "undefined behavior" to pass a negative value such as CHAR_MIN (if *char* type is signed) to a character classification function in C. Though EOF value (-1 traditionally) should be handled). If you want to explore it further; I've enumerated open questions in 2014 (inconsistent TypeError, ord(c) > 0x100, negative ints handling, etc) http://bugs.python.org/issue9770#msg221008 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 13:10:39 2016 From: report at bugs.python.org (Nick Timkovich) Date: Fri, 01 Jul 2016 17:10:39 +0000 Subject: [issue27337] 3.6.0a2 tarball has weird paths In-Reply-To: <1466100270.24.0.259127068452.issue27337@psf.upfronthosting.co.za> Message-ID: <1467393039.05.0.0887773733385.issue27337@psf.upfronthosting.co.za> Nick Timkovich added the comment: In pyenv this was "fixed" by pointing to the .tar.xz archive instead of the .tgz https://github.com/yyuu/pyenv/pull/652, maybe you could implement that for Pythonz? ---------- nosy: +nicktimko -ned.deily, petere _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 14:10:28 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 01 Jul 2016 18:10:28 +0000 Subject: [issue27434] cross-building python 3.6 with an older interpreter fails In-Reply-To: <1467378022.01.0.957641757812.issue27434@psf.upfronthosting.co.za> Message-ID: <1467396628.27.0.771992512081.issue27434@psf.upfronthosting.co.za> Xavier de Gaye added the comment: With this patch, cross-building the 3.6 source with only python 3.5.1 on the PATH, produces the following configure error: checking for python interpreter for cross build... configure: error: python3.6 interpreter not found ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file43604/restrict_interp.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 14:34:26 2016 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 01 Jul 2016 18:34:26 +0000 Subject: [issue27436] Strange code in selectors.KqueueSelector In-Reply-To: <1467387207.61.0.938158843585.issue27436@psf.upfronthosting.co.za> Message-ID: <1467398066.52.0.525882445104.issue27436@psf.upfronthosting.co.za> Xiang Zhang added the comment: EVENT_* and KQ_FILTER_* are two different sets of constants. EVENT_* represent event types of the abstract event and KQ_FILTER_* represent the kevent filter type. EVENT_* can be combined while kevent.filter can only get one type. ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 14:44:14 2016 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 01 Jul 2016 18:44:14 +0000 Subject: [issue27436] Strange code in selectors.KqueueSelector In-Reply-To: <1467387207.61.0.938158843585.issue27436@psf.upfronthosting.co.za> Message-ID: <1467398654.66.0.663799331901.issue27436@psf.upfronthosting.co.za> Xiang Zhang added the comment: What I am saying is that EVENT_* (1, 2) are bit_masks while KQ_FILTER_* not (-1, -2, -3, -4). So you should use |= with EVENT_* and == with KQ_FILTER_*. It seems not a bug. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 15:02:47 2016 From: report at bugs.python.org (Danek Duvall) Date: Fri, 01 Jul 2016 19:02:47 +0000 Subject: [issue20104] expose posix_spawn(p) In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za> Message-ID: <1467399767.61.0.170261734187.issue20104@psf.upfronthosting.co.za> Danek Duvall added the comment: Oh, for what it's worth, Solaris added setsid support to posix_spawn a few years ago, as a result of this conversation. I still think it would be worthwhile supporting this in the stdlib, since we keep running into processes which have a lot of memory reserved and can't fork some small program because they're running in a memory-limited environment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 15:19:32 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 01 Jul 2016 19:19:32 +0000 Subject: [issue27437] IDLE tests must be able to set user configuration values. Message-ID: <1467400772.1.0.605855673918.issue27437@psf.upfronthosting.co.za> New submission from Terry J. Reedy: An important feature of IDLE is that it has default configuration values in idlelib/config-xyz.def files that can be overriden by user values in $HOME/.idlerc/config-xyz.cfg files. IDLE should run and tests should pass both without and with user overrides. IDLE's config module currently hard-codes the file names. However, configparser can read from files it opens from a filename (.read), iterables of strings (.read_file), strings (.read_string), and dictionaries (.read_dict). This issue is about exposing this flexibility to IDLE tests and being able to clear and reset the user values for each test. ---------- assignee: terry.reedy messages: 269685 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: IDLE tests must be able to set user configuration values. type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 15:21:32 2016 From: report at bugs.python.org (David Beazley) Date: Fri, 01 Jul 2016 19:21:32 +0000 Subject: [issue27436] Strange code in selectors.KqueueSelector In-Reply-To: <1467387207.61.0.938158843585.issue27436@psf.upfronthosting.co.za> Message-ID: <1467400892.46.0.105057512933.issue27436@psf.upfronthosting.co.za> David Beazley added the comment: If the KQ_FILTER constants aren't bitmasks, it seems that the code could be simplified to the last version then. At the least, it would remove a few unnecessary calculations. Again, a very minor thing (I only stumbled onto it by accident really). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 15:23:31 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 01 Jul 2016 19:23:31 +0000 Subject: [issue27437] IDLE tests must be able to set user configuration values. In-Reply-To: <1467400772.1.0.605855673918.issue27437@psf.upfronthosting.co.za> Message-ID: <1467401011.48.0.0481557486283.issue27437@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Being able to force a rereading of user files from the menu could also be useful for manual testing or after a user fixes a problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 15:30:43 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 01 Jul 2016 19:30:43 +0000 Subject: [issue27437] IDLE tests must be able to set user configuration values. In-Reply-To: <1467400772.1.0.605855673918.issue27437@psf.upfronthosting.co.za> Message-ID: <1467401443.06.0.0319224799456.issue27437@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I don't believe that buildbots have an accessible $HOME that can be written to. In any case, tests of writing user config files should use StringIOs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 15:31:00 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 01 Jul 2016 19:31:00 +0000 Subject: [issue27436] Strange code in selectors.KqueueSelector In-Reply-To: <1467387207.61.0.938158843585.issue27436@psf.upfronthosting.co.za> Message-ID: <1467401460.98.0.0953367227156.issue27436@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 15:31:30 2016 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 01 Jul 2016 19:31:30 +0000 Subject: [issue27436] Strange code in selectors.KqueueSelector In-Reply-To: <1467387207.61.0.938158843585.issue27436@psf.upfronthosting.co.za> Message-ID: <1467401490.52.0.36083861193.issue27436@psf.upfronthosting.co.za> Xiang Zhang added the comment: But EVENT_* are. If you use =, events can only be either EVENT_READ or EVENT_WRITE, not EVENT_READ & EVENT_WRITE. EVENT_* != KQ_FILTER_*. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 15:38:52 2016 From: report at bugs.python.org (David Beazley) Date: Fri, 01 Jul 2016 19:38:52 +0000 Subject: [issue27436] Strange code in selectors.KqueueSelector In-Reply-To: <1467387207.61.0.938158843585.issue27436@psf.upfronthosting.co.za> Message-ID: <1467401932.94.0.683697261018.issue27436@psf.upfronthosting.co.za> David Beazley added the comment: I don't see any possible way that you would ever get events = EVENT_READ | EVENT_WRITE if the flag is a single value (e.g., KQ_FILTER_READ) and the flag itself is not a bitmask. Only one of those == tests will ever be True. There is no need to use |=. Unless I'm missing something. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 15:42:15 2016 From: report at bugs.python.org (Demur Rumed) Date: Fri, 01 Jul 2016 19:42:15 +0000 Subject: [issue27436] Strange code in selectors.KqueueSelector In-Reply-To: <1467387207.61.0.938158843585.issue27436@psf.upfronthosting.co.za> Message-ID: <1467402135.0.0.0642204704331.issue27436@psf.upfronthosting.co.za> Demur Rumed added the comment: Xiang: pause a moment to read the code being discussed. event before the |= is 0. You're saying flag must READ xor WRITE xor neither. Then only one if can be taken. Therefore events |= EVENT_* will always happen with events == 0, therefore it can be events = EVENT_* Further inspection of the code could move the flag/events calc into the 'if key' block ---------- nosy: +Demur Rumed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 15:43:09 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 01 Jul 2016 19:43:09 +0000 Subject: [issue27173] Modern Unix key bindings for IDLE In-Reply-To: <1464766185.36.0.150155479026.issue27173@psf.upfronthosting.co.za> Message-ID: <1467402189.77.0.971333021216.issue27173@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Seems to be working correctly now, so I will review the code in detail. I will look into extracting a common get_theme_keys function and editing the long docstring currently attached to CurrentTheme. I want to look at paired functions in configdialog, such as def VarChanged_builtinTheme/Keys to see if there are any unnecessary differences. The hardest thing is adding tests. Correct answers depend on the configuration vales, both default and user overrides. See #24737 for the latter. ---------- dependencies: +IDLE tests must be able to set user configuration values. stage: patch review -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 15:51:55 2016 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 01 Jul 2016 19:51:55 +0000 Subject: [issue27436] Strange code in selectors.KqueueSelector In-Reply-To: <1467387207.61.0.938158843585.issue27436@psf.upfronthosting.co.za> Message-ID: <1467402715.1.0.257254990905.issue27436@psf.upfronthosting.co.za> Xiang Zhang added the comment: Oh, sorry. My focus seem to be on the wrong place. I thought David is arguing something about the constants are bitmasks or not. It's my fault. But actually the current code looks very clearly and I can tell from it that EVENT_* are bitmasks and KQ_FILTER_* are not. Also changing it is also OK and can avoid a bit calculation. Then no opinion on changing it or not. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 16:35:17 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 01 Jul 2016 20:35:17 +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: <20160701203514.10925.24827.EB158BBD@psf.io> Roundup Robot added the comment: New changeset 30099abdb3a4 by Serhiy Storchaka in branch '2.7': Issue #23908: os functions, open() and the io.FileIO constructor now reject https://hg.python.org/cpython/rev/30099abdb3a4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 16:36:25 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Jul 2016 20:36:25 +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: <1467405385.88.0.677301802212.issue23908@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Zachary. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 17:11:46 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Jul 2016 21:11:46 +0000 Subject: [issue27213] Rework CALL_FUNCTION* opcodes In-Reply-To: <1465026334.02.0.369802561902.issue27213@psf.upfronthosting.co.za> Message-ID: <1467407506.89.0.000861799593255.issue27213@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The ABI of BUILD_MAP_UNPACK_WITH_CALL is changed. oparg=514 meant merging 2 dicts, but with the patch it will mean merging 514 dicts. The INCREF/DECREF calls on function objects surrounding calls are not needed, because the refcount was increased when the function pushed on the stack. They were needed if use PyMethod optimization, since PyMethod_GET_FUNCTION() returns borrowed link. Seems you have missed my comments on compile.c. Added more comments on Rietveld. What about CALL_FUNCTION_EX benchmarking? Did the optimization help? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 17:20:01 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 01 Jul 2016 21:20:01 +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: <1467408001.61.0.890613536483.issue27405@psf.upfronthosting.co.za> Terry J. Reedy added the comment: In "debug = False+1', I presume the '+1' is just temporary. The debug property and the clinic file refer to _tkinter.tkapp.get/settrace, which do not exist. Did you just forget to include that part? Or does 'preliminary' mean 'do not test yet'? >>> import tkinter >>> tkinter.debug 1 >>> import idlelib.idle Traceback (most recent call last): File "", line 1, in File "F:\Python\dev\36\lib\idlelib\idle.py", line 11, in idlelib.pyshell.main() File "F:\Python\dev\36\lib\idlelib\pyshell.py", line 1553, in main root = Tk(className="Idle") File "F:\Python\dev\36\lib\tkinter\__init__.py", line 2018, in __init__ self.debug = debug File "F:\Python\dev\36\lib\tkinter\__init__.py", line 2110, in debug self.tk.settrace(trace) AttributeError: '_tkinter.tkapp' object has no attribute 'settrace' At least the error shows that the code works as far as written ;-). I now understand 'larger customization ...' to mean supplying a trace function other than the default, to do something with 'cmd' other than just print it. For instance, one could record tcl commands in a file and later count the tcl function calls, much like python's trace does. To do that, I believe you could just replace 'def trace ... with if iscallable(value): trace = value else: def trace ... +1 on adding this. The default trace would be useful for simple interaction, but less so for what I tried to do above, which is to trace a complete IDLE session. ---------- assignee: -> serhiy.storchaka stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 17:21:19 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Jul 2016 21:21:19 +0000 Subject: [issue27173] Modern Unix key bindings for IDLE In-Reply-To: <1464766185.36.0.150155479026.issue27173@psf.upfronthosting.co.za> Message-ID: <1467408079.92.0.18847858529.issue27173@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: After committing the patch for this issue I'm going to refactor the code related to getting/setting theme/keys settings. For now it is too complicated, the logic is scattered between two files, some code is duplicated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 17:24:54 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Jul 2016 21:24:54 +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: <1467408294.45.0.798288594546.issue27405@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: You need to recompile the _tkinter module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 17:39:28 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 01 Jul 2016 21:39:28 +0000 Subject: [issue27427] Add new math module tests In-Reply-To: <1467325887.57.0.243525279322.issue27427@psf.upfronthosting.co.za> Message-ID: <1467409168.37.0.387745147808.issue27427@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +mark.dickinson, rhettinger, stutzbach title: Math tests -> Add new math module tests _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 18:00:50 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Jul 2016 22:00:50 +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: <1467410450.16.0.272580871316.issue26885@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your review Terry. You can pass an integer in range from -2147483648 to 2147483647, and it is marshalled using the tag. But when you receive tags , , etc, they are unmarshalled to integer values, and these values can be out of range from -2147483648 to 2147483647. How to document all these detail in short? The same is with other types. xmlrpclib is more conservative with data that it sends than with data that it receives. float is marshalled using the flag, but the tag is unmarshalled to float too. None and datetime can be marshalled only if corresponding option is enabled, but always can be unmarshalled. Decimal can't be marshalled, but can be unmarshalled. For now unmarshalling None is supported from the tag (this is unofficial extension). But Apache XML-RPC server produces tags with namespace: , which is not supported in xmplrpclib. The patch adds the support of tags with namespaces, and therefore adds the support of unmarshalling None in Apache XML-RPC server format. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 18:09:46 2016 From: report at bugs.python.org (Kevin Ollivier) Date: Fri, 01 Jul 2016 22:09:46 +0000 Subject: [issue17128] OS X system openssl deprecated - installer should build local libssl In-Reply-To: <1360002680.77.0.851671416179.issue17128@psf.upfronthosting.co.za> Message-ID: <1467410986.73.0.0790989647713.issue17128@psf.upfronthosting.co.za> Kevin Ollivier added the comment: The OpenSSL included with OS X, still at 0.9.8, has become very dated and a growing number of servers (including openssl.org) now fail the handshake because they no longer support any of the protocols and ciphers included with that build. It is reaching the point where for some projects the system OpenSSL on OS X is no longer viable to use. Here's a ticket for a Python project showing an example of this problem: https://github.com/kivy/kivy-ios/issues/198 I have run into this issue myself on this and a couple other projects I am working on. Would it be possible to have the fix for 10.5 builds get applied to all the Python OS X installers, perhaps for 3.6, and ideally also for 2.7 if there are plans to make a new release for that? ---------- nosy: +Kevin Ollivier _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 1 19:02:18 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 01 Jul 2016 23:02:18 +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: <1467414138.32.0.548969854772.issue27405@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I just noticed that the patch includes a patch to _tkinter.c, which however, does not show up on the Rietveld dashboad, where I first reviewed it. Sorry for the mistaken comment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 02:40:08 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Jul 2016 06:40:08 +0000 Subject: [issue27438] Refactot simple iterators implementation Message-ID: <1467441608.13.0.484194759608.issue27438@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: The implementation of iterators for str, bytes, bytearray, tuple and list is virtually the same. Proposed patch moves common code to the template file iterlib.h and parametrizes it with few macros. The patch decreases the number of source lines by 600. Makefile.pre.in | 2 Objects/bytearrayobject.c | 165 ------------ Objects/bytesobject.c | 167 ------------- Objects/iterlib.h | 168 +++++++++++++ Objects/listobject.c | 468 ++++++++++-------------------------- Objects/tupleobject.c | 156 ------------ Objects/unicodeobject.c | 171 ------------- PCbuild/pythoncore.vcxproj | 1 PCbuild/pythoncore.vcxproj.filters | 3 9 files changed, 349 insertions(+), 942 deletions(-), 10 modifications(!) ---------- components: Interpreter Core files: iterlib.patch keywords: patch messages: 269703 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Refactot simple iterators implementation type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43605/iterlib.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 02:41:11 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Jul 2016 06:41:11 +0000 Subject: [issue27438] Refactor simple iterators implementation In-Reply-To: <1467441608.13.0.484194759608.issue27438@psf.upfronthosting.co.za> Message-ID: <1467441671.29.0.35317186895.issue27438@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- title: Refactot simple iterators implementation -> Refactor simple iterators implementation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 05:58:09 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 02 Jul 2016 09:58:09 +0000 Subject: [issue27438] Refactor simple iterators implementation In-Reply-To: <1467441608.13.0.484194759608.issue27438@psf.upfronthosting.co.za> Message-ID: <1467453489.84.0.520645019051.issue27438@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Though this gives us a nicely reduced line count, I'm disinclined to do this for several reasons: The benefit is too small to warrant this kind of atypical macro/include magic (with "magic" being the pattern of making a series of #defines followed by an #inclusion of a .h file that uses those definition to generate code that would normally be in a .c file and then #undefining so that the pattern can be repeated elsewhere). Anyone trying to maintain this code will have to rediscover what you're doing and mentally unroll all the steps. I also think it will confuse static tools like CTAGs, making the source harder to trace. In general, the rule of refactoring is to express every idea only once in the source, so I do understand the motivation for this patch; however, this patch results in a net increase in maintenance burden and will make it more difficult for our newer core developers to understand the code. Currently listobject.c and tupleobject.c are separately digestible and intelligible -- one can read and make changes to each without learning new macros and without worrying about the effects of tight coupling ("don't tug on that, you never know what it might be attached to"). I don't think we're solving a real problem here. The code currently works fine and is easy to digest one object type at a time. For me, the patch interferes with the way I think about and work with these modules. I reason about the what the iterator is doing in conjuction with the surrounding code for the rest of the type. This patch has a conflicting notion which is that sequence iteration is a single concept that should be reasoned about independently of how the type is implemented. If someone later wants to do major surgery to one of the types (such as being contemplated now with compacts dicts being applied to dictobject.c), the maintainer would have to first undo this patch. FWIW, I looked at similar transformations many times and have always concluded that it would make us worse off even though the code size would be smaller. For example, the itertools module has internal redundancy; however, that is a net benefit because it allows each tool to be reasoned about separately and to be maintained without worrying about the effects on the other tools. So, please put me down for a -1. Factoring and less code are generally good, but tricky macro/define/include/undefine magic is bad. Tight coupling is also bad. I worry that in you efforts to "refactor" just about everything in the entire code base, you are invalidating the design decisions of every developer who came before you. In creating many new macros, we're increasing the learning curve for subsequent maintainers (they have to first learn what tricks the macros are doing and what is behind the abstraction before being able to do anything). Also, it creates was somewhat constipated coding style where everything has been squeezed tightly together and lost the simple fluidity and lucidity that it had before. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 05:58:17 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 02 Jul 2016 09:58:17 +0000 Subject: [issue27438] Refactor simple iterators implementation In-Reply-To: <1467441608.13.0.484194759608.issue27438@psf.upfronthosting.co.za> Message-ID: <1467453497.75.0.315093501795.issue27438@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 06:56:36 2016 From: report at bugs.python.org (Upendra Kumar) Date: Sat, 02 Jul 2016 10:56:36 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1467456996.01.0.484129288044.issue27051@psf.upfronthosting.co.za> Upendra Kumar added the comment: For using threading with Tkinter there are two options : either to use threading or asyncio ( coroutines ). Because asyncio is easier as compared to threading, therefore I would like to use it. But, coroutines are available only in Python >=3.5. Therefore should we target all Python 3 users or Python>=3.5 users? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 07:40:48 2016 From: report at bugs.python.org (Utkan Gezer) Date: Sat, 02 Jul 2016 11:40:48 +0000 Subject: [issue27439] product function patch Message-ID: <1467459648.57.0.0102935074886.issue27439@psf.upfronthosting.co.za> New submission from Utkan Gezer: An issue of enhancement by the introduction of a built-in product() function for the multiplication operation, functions similar to how sum does for the addition operation. This issue is a reincarnation of Issue 1093 for Python 2.6, now for 3.6. Ref: http://bugs.python.org/issue1093 ---------- messages: 269706 nosy: Utkan Gezer priority: normal severity: normal status: open title: product function patch type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 07:57:31 2016 From: report at bugs.python.org (Emanuel Barry) Date: Sat, 02 Jul 2016 11:57:31 +0000 Subject: [issue27439] product function patch In-Reply-To: <1467459648.57.0.0102935074886.issue27439@psf.upfronthosting.co.za> Message-ID: <1467460651.64.0.7567623652.issue27439@psf.upfronthosting.co.za> Emanuel Barry added the comment: What is the use case, and why is a regular for loop not enough? The bar for adding new builtin functions is high, and I don't think this meets it. ---------- nosy: +ebarry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 08:11:18 2016 From: report at bugs.python.org (Utkan Gezer) Date: Sat, 02 Jul 2016 12:11:18 +0000 Subject: [issue27439] product function patch In-Reply-To: <1467459648.57.0.0102935074886.issue27439@psf.upfronthosting.co.za> Message-ID: <1467461478.4.0.0764136532862.issue27439@psf.upfronthosting.co.za> Utkan Gezer added the comment: The use case is similar to the use case of sum() function, which is analogous to the sigma notation in mathematics, and is analogous to the use case of the pi notation in mathematics. Regular loop should be equally enough to achieve the function of sum(), yet the sum() exists. Only apparent (to me) difference between the sum() and product() is that sum() is already built-in while product() is yet to be. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 08:26:03 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Sat, 02 Jul 2016 12:26:03 +0000 Subject: [issue27439] product function patch In-Reply-To: <1467459648.57.0.0102935074886.issue27439@psf.upfronthosting.co.za> Message-ID: <20160702122556.GO27919@ando.pearwood.info> Steven D'Aprano added the comment: On Sat, Jul 02, 2016 at 11:40:48AM +0000, Utkan Gezer wrote: > > New submission from Utkan Gezer: > > An issue of enhancement by the introduction of a built-in product() > function for the multiplication operation, functions similar to how > sum does for the addition operation. I will likely be introducing an internal product() to the statistics module, for use in calculating the geometric mean. The problem with product() is similar to the problem with sum(). There are three different implementations of sum in the std lib: a general purpose one optimised for speed as the builtin, one optimized for floating point accuracy in the math module, and an internal-only private one optimized for exactness in the statistics module. I expect that product() will have the same tradeoffs, only even more so since it will overflow much more easily than sum() will. ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 08:36:35 2016 From: report at bugs.python.org (Emanuel Barry) Date: Sat, 02 Jul 2016 12:36:35 +0000 Subject: [issue27439] Add a product() function to the standard library In-Reply-To: <1467459648.57.0.0102935074886.issue27439@psf.upfronthosting.co.za> Message-ID: <1467462995.93.0.172958858132.issue27439@psf.upfronthosting.co.za> Emanuel Barry added the comment: With the existence of multiple sum() functions (and potentially multiple product() functions), would it be worth it to group these all into one module? It also doesn't help that there is an itertools.product function that has yet another purpose. I maintain my stance that this doesn't meet the bar for entry in the builtins, but adding this to the stdlib is much more reasonable (and likely). ---------- title: product function patch -> Add a product() function to the standard library _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 09:32:29 2016 From: report at bugs.python.org (Shubham Singh) Date: Sat, 02 Jul 2016 13:32:29 +0000 Subject: [issue27440] Trigonometric bug Message-ID: <1467466349.47.0.855783586648.issue27440@psf.upfronthosting.co.za> New submission from Shubham Singh: The value of sine and tangent, using math module is showing wrong.Screenshot is attached. ---------- components: Extension Modules, Windows files: Sin.jpg messages: 269711 nosy: ShubhamSingh.er, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Trigonometric bug type: resource usage versions: Python 3.5 Added file: http://bugs.python.org/file43606/Sin.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 09:59:57 2016 From: report at bugs.python.org (Alexander Riccio) Date: Sat, 02 Jul 2016 13:59:57 +0000 Subject: [issue26137] [idea] use the Microsoft Antimalware Scan Interface In-Reply-To: <1453023852.0.0.39090079449.issue26137@psf.upfronthosting.co.za> Message-ID: <1467467997.95.0.703208782698.issue26137@psf.upfronthosting.co.za> Alexander Riccio added the comment: It's not just Stuxnet, as at least one other Advanced Persistent Threat uses that tactic. An APT (likely Russian intelligence) recently used encoded PowerShell to break into the Democratic National Committe: https://www.crowdstrike.com/blog/bears-midst-intrusion-democratic-national-committee/ >From that article: > This one-line powershell command, stored only in WMI database, establishes an encrypted connection to C2 and downloads additional powershell modules from it, executing them in memory. (As a fun coincidence, they also used py2exe to distribute other modules, which is kinda like a separate interpreter using safe_exec) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 10:00:44 2016 From: report at bugs.python.org (Alexander Riccio) Date: Sat, 02 Jul 2016 14:00: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: <1467468044.43.0.397835582815.issue26137@psf.upfronthosting.co.za> Alexander Riccio added the comment: We might want to use some kind of Group Policy setting, for the same reason that many Windows security configuration options are there, and that DoD STIGs for Windows https://www.stigviewer.com/stig/windows_8_8.1/ are almost totally about configuring Group Policy settings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 10:28:38 2016 From: report at bugs.python.org (Mathieu Dupuy) Date: Sat, 02 Jul 2016 14:28:38 +0000 Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1467469718.95.0.0767618634479.issue15873@psf.upfronthosting.co.za> Mathieu Dupuy added the comment: Hi. I'm back, and willing to move forward on this issue. With the new code layout, the compiled regexes now lay in datetime classes as class attributes. Will it be possible to import date, time and datetime from datetime.py in _datetime.c without a problem ? By the way, I just discovered, that the way we treat microseconds differs from the strptime one : we are smarter read every digits and smartly round to six, strptime doesn't go that far and just *truncate* to this. Should go that way, for consistency with what strptime does, maybe ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 10:39:00 2016 From: report at bugs.python.org (Oren Milman) Date: Sat, 02 Jul 2016 14:39:00 +0000 Subject: [issue27441] redundant assignments to ob_size of new ints that _PyLong_New returned Message-ID: <1467470337.8.0.776341442151.issue27441@psf.upfronthosting.co.za> New submission from Oren Milman: ------------ current state ------------ In six different functions, the following happens: 1. Function x calls _PyLong_New, with var y as the size argument. * Among others, _PyLong_New sets the ob_size of the new int to y (the size argument it received). 2. Function x sets the ob_size of the new int to y, even though y is already the value of ob_size. The functions in which this happens are: 1. in Objects/longobject.c: - PyLong_FromUnsignedLong - PyLong_FromLongLong - PyLong_FromUnsignedLongLong - PyLong_FromSsize_t - PyLong_FromSize_t 2. in Python/marshal.c: - r_PyLong With regard to relevant changes made in the past, it seems that the redundant assignment was added (in each of these six functions) on the last major rewriting of the function, or when the function was first added, and remained there to this day. The revisions in which the redundant assignments were added: 1. changeset 18114 (https://hg.python.org/cpython/rev/31cd0db0f09f): - PyLong_FromUnsignedLong 2. changeset 38307 (https://hg.python.org/cpython/rev/5a63369056a7): - PyLong_FromLongLong - PyLong_FromUnsignedLongLong 3. changeset 46460 (https://hg.python.org/cpython/rev/b04f2052e812): - PyLong_FromSize_t - PyLong_FromSsize_t 4. changeset 52215 (https://hg.python.org/cpython/rev/bb5de24a343f): - r_PyLong ------------ proposed changes ------------ Remove these six redundant assignments. ------------ 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: CPythonTestOutput.txt messages: 269715 nosy: Oren Milman priority: normal severity: normal status: open title: redundant assignments to ob_size of new ints that _PyLong_New returned type: performance Added file: http://bugs.python.org/file43607/CPythonTestOutput.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 10:40:17 2016 From: report at bugs.python.org (Oren Milman) Date: Sat, 02 Jul 2016 14:40:17 +0000 Subject: [issue27441] redundant assignments to ob_size of new ints that _PyLong_New returned In-Reply-To: <1467470337.8.0.776341442151.issue27441@psf.upfronthosting.co.za> Message-ID: <1467470417.05.0.224620396562.issue27441@psf.upfronthosting.co.za> Changes by Oren Milman : ---------- keywords: +patch Added file: http://bugs.python.org/file43608/issue27441_ver1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 10:40:55 2016 From: report at bugs.python.org (Oren Milman) Date: Sat, 02 Jul 2016 14:40:55 +0000 Subject: [issue27441] redundant assignments to ob_size of new ints that _PyLong_New returned In-Reply-To: <1467470337.8.0.776341442151.issue27441@psf.upfronthosting.co.za> Message-ID: <1467470455.84.0.390931228071.issue27441@psf.upfronthosting.co.za> Changes by Oren Milman : Added file: http://bugs.python.org/file43609/patchedCPythonTestOutput_ver1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 10:52:55 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 02 Jul 2016 14:52:55 +0000 Subject: [issue27442] expose Android API level in sys.implementation Message-ID: <1467471175.35.0.000904857777026.issue27442@psf.upfronthosting.co.za> New submission from Xavier de Gaye: Expose the Android API level that python was built against, in sys.implementation as _android_api. Purposes: * Identify the platform as Android. * Allow detecting a mismatch with the runtime sdk version returned by platform.android_ver() (issue 26855), for example when the runtime sdk is lower than the built API level. ---------- assignee: xdegaye components: Interpreter Core messages: 269716 nosy: haypo, xdegaye priority: normal severity: normal status: open title: expose Android API level in sys.implementation type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 10:57:16 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 02 Jul 2016 14:57:16 +0000 Subject: [issue27442] expose Android API level in sys.implementation In-Reply-To: <1467471175.35.0.000904857777026.issue27442@psf.upfronthosting.co.za> Message-ID: <1467471436.23.0.874790766581.issue27442@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Patch added. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file43610/android_api.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 11:00:04 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 02 Jul 2016 15:00:04 +0000 Subject: [issue26865] Meta-issue: support of the android platform In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za> Message-ID: <1467471604.15.0.863395438464.issue26865@psf.upfronthosting.co.za> Xavier de Gaye added the comment: issue #27442: expose Android API level in sys.implementation ---------- dependencies: +expose Android API level in sys.implementation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 11:01:57 2016 From: report at bugs.python.org (Pascal Chambon) Date: Sat, 02 Jul 2016 15:01:57 +0000 Subject: [issue27141] Fix collections.UserList shallow copy In-Reply-To: <1464384542.41.0.303372176211.issue27141@psf.upfronthosting.co.za> Message-ID: <1467471717.93.0.325078588698.issue27141@psf.upfronthosting.co.za> Changes by Pascal Chambon : ---------- nosy: +pakal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 11:11:45 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sat, 02 Jul 2016 15:11:45 +0000 Subject: [issue27442] expose Android API level in sys.implementation In-Reply-To: <1467471175.35.0.000904857777026.issue27442@psf.upfronthosting.co.za> Message-ID: <1467472305.86.0.946506204775.issue27442@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: I don't think sys.implementation is a good place to contain the information of the underlying platform. By Doc/sys.rst: An object containing information about the implementation of the currently running Python interpreter. ---------- nosy: +Chi Hsuan Yen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 11:12:20 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sat, 02 Jul 2016 15:12:20 +0000 Subject: [issue27442] expose Android API level in sys.implementation In-Reply-To: <1467471175.35.0.000904857777026.issue27442@psf.upfronthosting.co.za> Message-ID: <1467472340.04.0.440499221944.issue27442@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Sorry, it's Doc/library/sys.rst ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 11:28:08 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 02 Jul 2016 15:28:08 +0000 Subject: [issue27442] expose Android API level in sys.implementation In-Reply-To: <1467471175.35.0.000904857777026.issue27442@psf.upfronthosting.co.za> Message-ID: <1467473288.15.0.119713190724.issue27442@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > I don't think sys.implementation is a good place to contain the information of the underlying platform. Quite the opposite, the ndk API level gives an information about the implementation of the currently running Python interpreter saying that this Python has been built against this version of Android libc identified by this API level. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 11:52:42 2016 From: report at bugs.python.org (=?utf-8?q?Anders_Hovm=C3=B6ller?=) Date: Sat, 02 Jul 2016 15:52:42 +0000 Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times In-Reply-To: <1467469718.95.0.0767618634479.issue15873@psf.upfronthosting.co.za> Message-ID: <226B1846-CF0F-46C2-B4EA-AE2843A2D19F@killingar.net> Anders Hovm?ller added the comment: > > By the way, I just discovered, that the way we treat microseconds differs from the strptime one : we are smarter read every digits and smartly round to six, strptime doesn't go that far and just *truncate* to this. Should go that way, for consistency with what strptime does, maybe ? I'm strongly against silently throwing away data and calling it even. If we want compatibility with strptime then it should be a separate flag like silent_truncate_milliseconds=True. On another matter: does the latest proposed code pass the tests in my ISO8601 implementation that I mentioned 2013 (! time flies)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 13:35:25 2016 From: report at bugs.python.org (Martin Teichmann) Date: Sat, 02 Jul 2016 17:35:25 +0000 Subject: [issue27366] PEP487: Simpler customization of class creation In-Reply-To: <1466579967.76.0.483118833643.issue27366@psf.upfronthosting.co.za> Message-ID: <1467480925.88.0.457005504993.issue27366@psf.upfronthosting.co.za> Martin Teichmann added the comment: This is a C implementation of PEP 487, directly in the Python core ---------- Added file: http://bugs.python.org/file43611/pep487a.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 13:39:57 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sat, 02 Jul 2016 17:39:57 +0000 Subject: [issue27442] expose Android API level in sys.implementation In-Reply-To: <1467471175.35.0.000904857777026.issue27442@psf.upfronthosting.co.za> Message-ID: <1467481197.41.0.560342184346.issue27442@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: OK I see the rationale. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 13:54:36 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Jul 2016 17:54:36 +0000 Subject: [issue27440] Trigonometric bug In-Reply-To: <1467466349.47.0.855783586648.issue27440@psf.upfronthosting.co.za> Message-ID: <1467482076.85.0.0805482529433.issue27440@psf.upfronthosting.co.za> R. David Murray added the comment: I would imagine that this is a consequence of platform-dependent floating point math. Not to mention working with an irrational number. See also issue 8309. ---------- nosy: +mark.dickinson, r.david.murray type: resource usage -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 14:21:08 2016 From: report at bugs.python.org (STINNER Victor) Date: Sat, 02 Jul 2016 18:21:08 +0000 Subject: [issue27442] expose Android API level in sys.implementation In-Reply-To: <1467471175.35.0.000904857777026.issue27442@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: I woupd prefer to have a public attribute. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 14:54:05 2016 From: report at bugs.python.org (Davin Potts) Date: Sat, 02 Jul 2016 18:54:05 +0000 Subject: [issue27422] Deadlock when mixing threading and multiprocessing In-Reply-To: <1467303803.25.0.914359339926.issue27422@psf.upfronthosting.co.za> Message-ID: <1467485645.58.0.359467147309.issue27422@psf.upfronthosting.co.za> Davin Potts added the comment: It would be nice to find an appropriate place to document the solid general guidance Raymond provided; though merely mentioning it somewhere in the docs will not translate into it being noticed. Not sure where to put it just yet... Martin: Is there a specific situation that prompted your discovering this behavior? Mixing the spinning up of threads with the forking of processes requires appropriate planning to avoid problems and achieve desired performance. If you have a thoughtful design to your code but are still triggering problems, can you share more of the motivation? As a side note, this is more appropriately labeled as a 'behavior' rather than a 'crash' -- the Python executable does not crash in any way but merely hangs in an apparent lock contention. ---------- nosy: +davin type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 15:09:57 2016 From: report at bugs.python.org (Tim Peters) Date: Sat, 02 Jul 2016 19:09:57 +0000 Subject: [issue27440] Trigonometric bug In-Reply-To: <1467466349.47.0.855783586648.issue27440@psf.upfronthosting.co.za> Message-ID: <1467486597.13.0.794462713152.issue27440@psf.upfronthosting.co.za> Tim Peters added the comment: Python's floats are emphatically not doing symbolic arithmetic - they use the platform's binary floating point facilities, which can only represent a subset of rationals exactly. All other values are approximated. In particular, this shows the exact value of the approximation used for pi: >>> import math >>> from decimal import Decimal >>> Decimal(math.pi) Decimal('3.141592653589793115997963468544185161590576171875') That isn't the mathematical pi, but is the closest approximation representable as a platform Python binary float (same as type "double" in the platform C). Here's the difference between math.pi and a better decimal approximation to pi: >>> Decimal(math.pi) - Decimal("3.141592653589793238462643383279502884") Decimal('-1.224646799147353177224094238E-16') So math.pi is a little bit smaller than the mathematical pi. Mathematically, using the subtraction formula for sine: sin(pi - e) = sin(pi)*cos(e) - sin(e)*cos(pi) = 0*cos(e) - sin(e)*-1 = 0 + sin(e) = sin(e) So mathematically sin(pi - e) = sin(e), and if |e| is close to 0 then sin(e) ~= e. For that reason, it's not a coincidence that the result you got for math.sin(math.pi) = 1.22464...e-16 is approximately equal to the difference (shown above) between the mathematical pi and math.pi. It's not due to gross inaccuracy in sine, it's due to that pi isn't exactly representable as a Python float. Note that this has nothing to do with Python specifically. You'll see the same kind of behaviors in any language exposing the platform floating point facilities. If you need to do symbolic computations, then you need much fancier facilities. ---------- nosy: +tim.peters resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 15:53:54 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Jul 2016 19:53:54 +0000 Subject: [issue27443] __length_hint__() of bytearray iterator can return negative integer Message-ID: <1467489234.07.0.837465555055.issue27443@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: >>> ba = bytearray(b'ab') >>> it = iter(ba) >>> next(it) 97 >>> ba.clear() >>> list(it) Traceback (most recent call last): File "", line 1, in ValueError: __length_hint__() should return >= 0 Proposed patch fixes this issue. ---------- components: Interpreter Core files: bytearray_iterator_length_hint.patch keywords: patch messages: 269729 nosy: rhettinger, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: __length_hint__() of bytearray iterator can return negative integer type: behavior versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43612/bytearray_iterator_length_hint.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 16:00:24 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Jul 2016 20:00:24 +0000 Subject: [issue27438] Refactor simple iterators implementation In-Reply-To: <1467441608.13.0.484194759608.issue27438@psf.upfronthosting.co.za> Message-ID: <1467489624.75.0.537069322.issue27438@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your detailed explanation Raymond. In any case, the work on this patch helped to find a bug in bytearray iterator (issue27443). ---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 16:03:12 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Jul 2016 20:03:12 +0000 Subject: [issue26765] Factor out common bytes and bytearray implementation In-Reply-To: <1460707559.13.0.709090380773.issue26765@psf.upfronthosting.co.za> Message-ID: <1467489792.5.0.562932747005.issue26765@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 Jul 2 16:06:24 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Jul 2016 20:06:24 +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: <1467489984.66.0.701633972497.issue26800@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 16:14:11 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 02 Jul 2016 20:14:11 +0000 Subject: [issue27439] Add a product() function to the standard library In-Reply-To: <1467459648.57.0.0102935074886.issue27439@psf.upfronthosting.co.za> Message-ID: <1467490451.65.0.327776869735.issue27439@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Actually, Guido already vetoed the idea: http://bugs.python.org/issue1093 ---------- nosy: +rhettinger resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 16:17:53 2016 From: report at bugs.python.org (Davin Potts) Date: Sat, 02 Jul 2016 20:17:53 +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: <1467490673.68.0.146419230894.issue27081@psf.upfronthosting.co.za> Davin Potts added the comment: I took the example snippet and cleaned things up a bit, adding some crude timestamping and commentary. (Attached) In the example, when the Process finally dies, a lot of information has been put onto the Queue but it hasn't necessarily had enough time to be synced to the parent process so it may be only a truncated subset of the data that remains available/visible/retrievable on the parent. How much data gets synced to the parent depends on many factors and should even vary from one run to another. That is to say that a multiprocessing.Queue is not going to hold up a dying process to finish communicating data to other processes. ---------- Added file: http://bugs.python.org/file43613/issue27081.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 16:18:43 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 02 Jul 2016 20:18:43 +0000 Subject: [issue27422] Deadlock when mixing threading and multiprocessing In-Reply-To: <1467303803.25.0.914359339926.issue27422@psf.upfronthosting.co.za> Message-ID: <1467490723.71.0.676712174058.issue27422@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, this isn't even a Python specific behavior. It is just how threads, locks, and processes work (or in this case don't work). The code is doing what it is told to do which happens to not be what you want (i.e. a user bug rather than a Python bug). I think a FAQ entry would be a reasonable place to mention this (it comes up more often than one would hope). ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python resolution: -> not a bug _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 16:22:58 2016 From: report at bugs.python.org (Davin Potts) Date: Sat, 02 Jul 2016 20:22:58 +0000 Subject: [issue26903] ProcessPoolExecutor(max_workers=64) crashes on Windows In-Reply-To: <1462135538.41.0.857077084248.issue26903@psf.upfronthosting.co.za> Message-ID: <1467490978.36.0.809891617623.issue26903@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 16:34:54 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 02 Jul 2016 20:34:54 +0000 Subject: [issue27443] __length_hint__() of bytearray iterator can return negative integer In-Reply-To: <1467489234.07.0.837465555055.issue27443@psf.upfronthosting.co.za> Message-ID: <1467491694.92.0.896588848311.issue27443@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This patch looks correct. Nice catch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 16:42:36 2016 From: report at bugs.python.org (ppperry) Date: Sat, 02 Jul 2016 20:42:36 +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: <1467492156.26.0.311170352151.issue27081@psf.upfronthosting.co.za> ppperry added the comment: I believe that regardless of the number of prints to sys.stderr that happen before the recursion error, all of them will get sent to the parent. The problem is that the queue is flushed before the uncaught error is sent to stderr, not after. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 17:02:45 2016 From: report at bugs.python.org (Emanuel Barry) Date: Sat, 02 Jul 2016 21:02:45 +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: <1467493365.55.0.689625709478.issue27081@psf.upfronthosting.co.za> Emanuel Barry added the comment: Worth of note: #26823 will actually change printing to stderr for recursion errors (if/when it gets merged that is; I don't know what's holding it up). It might be interesting to see if you can still witness this issue with the patch applied. ---------- nosy: +ebarry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 17:10:03 2016 From: report at bugs.python.org (ppperry) Date: Sat, 02 Jul 2016 21:10:03 +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: <1467493803.83.0.974349335622.issue27081@psf.upfronthosting.co.za> ppperry added the comment: This issue isn't specific to recursion errors. It only occurs when the error message is long enough, so #26823 would fix the RecursionError case, but it would still happen when someone calls a function with a billion-character-long name that raises an error, for example. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 17:10:51 2016 From: report at bugs.python.org (Greg Stark) Date: Sat, 02 Jul 2016 21:10:51 +0000 Subject: [issue27444] Python doesn't build due to test_float.py broken on non-IEEE machines Message-ID: <1467493851.35.0.417072100147.issue27444@psf.upfronthosting.co.za> New submission from Greg Stark: The file Test/test_float.py has a decorator for tests that must be skipped on non-IEEE machines. However just eyeballing it it seems there are a few tests that test behaviour around Inf and NaN that are lacking this decorator. Alternately it's possible this is actually a core interpreter bug where even code which is never called is now triggering floating point exceptions due to some constant propagation optimization or something like that. To reproduce, try to install on a non-IEE machine such as a VAX and your install will crash with: Compiling /usr/pkgsrc/lang/python27/work/.destdir/usr/pkg/lib/python2.7/test/test_filecmp.py ... Compiling /usr/pkgsrc/lang/python27/work/.destdir/usr/pkg/lib/python2.7/test/test_fileinput.py ... Compiling /usr/pkgsrc/lang/python27/work/.destdir/usr/pkg/lib/python2.7/test/test_fileio.py ... Compiling /usr/pkgsrc/lang/python27/work/.destdir/usr/pkg/lib/python2.7/test/test_float.py ... [1] Floating point exception (core dumped) PYTHONPATH=/usr/... *** Error code 136 Stop. make: stopped in /usr/pkgsrc/lang/python27/work/Python-2.7.10 *** Error code 1 I do happen to have been compiling with -O0 -g so I have a core file and a binary with symbols (if you have a VAX gdb...) but here's the backtrace: #0 0x7f687748 in float_mul (v=0x7ee82f54, w=0x7ee82f54, 2129145684, 2129145684) at Objects/floatobject.c:658 #1 0x7f65eb56 in binary_op1 (v=0x7ee82f54, w=0x7ee82f54, op_slot=8, 2129145684, 2129145684, 8) at Objects/abstract.c:945 #2 0x7f65f572 in PyNumber_Multiply (v=0x7ee82f54, w=0x7ee82f54, 2129145684, 2129145684) at Objects/abstract.c:1216 #3 0x7f72e573 in fold_binops_on_constants (codestr=0x7f28b169 "d\001", consts=0x7f0b5dcc, 2133373289, 2131451340) at Python/peephole.c:108 #4 0x7f72f56c in PyCode_Optimize (code=0x7f3316a8, consts=0x7f0b5dcc, names=0x7f0948ec, lineno_obj=0x7f0b5840, 2134054568, 2131451340, 2131314924, 2131449920) at Python/peephole.c:482 #5 0x7f71d3ad in makecode (c=0x7fffc810, a=0x7fffc5b0, 2147469328, 2147468720) at Python/compile.c:3883 #6 0x7f71d77d in assemble (c=0x7fffc810, addNone=1, 2147469328, 1) at Python/compile.c:3999 #7 0x7f717527 in compiler_function (c=0x7fffc810, s=0x7eb82bf0, 2147469328, 2125999088) at Python/compile.c:1422 #8 0x7f719552 in compiler_visit_stmt (c=0x7fffc810, s=0x7eb82bf0, 2147469328, 2125999088) at Python/compile.c:2122 #9 0x7f716d00 in compiler_body (c=0x7fffc810, stmts=0x7ebc88f8, 2147469328, 2126285048) at Python/compile.c:1209 #10 0x7f717882 in compiler_class (c=0x7fffc810, s=0x7ebd2608, 2147469328, 2126325256) at Python/compile.c:1477 #11 0x7f719564 in compiler_visit_stmt (c=0x7fffc810, s=0x7ebd2608, 2147469328, 2126325256) at Python/compile.c:2124 #12 0x7f716d00 in compiler_body (c=0x7fffc810, stmts=0x7eb53010, 2147469328, 2125803536) at Python/compile.c:1209 #13 0x7f716db6 in compiler_mod (c=0x7fffc810, mod=0x7ebe1438, 2147469328, 2126386232) at Python/compile.c:1229 #14 0x7f7151f3 in PyAST_Compile (mod=0x7ebe1438, filename=0x7f2c15b4 "/usr/pkg/lib/python2.7/test/test_float.py", flags=0x7fffc8c0, arena=0x7f3482f0, 2126386232, 2133595572, 2147469504, 2134147824) at Python/compile.c:292 #15 0x7f733849 in Py_CompileStringFlags ( str=0x7eb43014 "\nimport unittest, struct\nimport os\nfrom test import test_support\nimport math\nfrom math import isinf, isnan, copysign, ldexp\nimport operator\nimport random\nimport fractions\nimport sys\nimport time\n\nINF ="..., filename=0x7f2c15b4 "/usr/pkg/lib/python2.7/test/test_float.py", start=257, flags=0x7fffc8c0, 2125738004, 2133595572, 257, 2147469504) at Python/pythonrun.c:1428 #16 0x7f705dc6 in builtin_compile (self=0x0, args=0x7f08f914, kwds=0x0, 0, 2131294484, 0) at Python/bltinmodule.c:559 #17 0x7f6a5b8a in PyCFunction_Call (func=0x7f32a96c, arg=0x7f08f914, kw=0x0, 2134026604, 2131294484, 0) at Objects/methodobject.c:85 #18 0x7f713023 in call_function (pp_stack=0x7fffca44, oparg=3, 2147469892, 3) at Python/ceval.c:4035 #19 0x7f70fe32 in PyEval_EvalFrameEx (f=0x7f29568c, throwflag=0, 2133415564, 0) at Python/ceval.c:2681 #20 0x7f711523 in PyEval_EvalCodeEx (co=0x7f25cad0, globals=0x7f29a3e4, locals=0x0, args=0x7f3b7874, argcount=4, kws=0x7f3b7884, kwcount=0, defs=0x7f29d3a8, defcount=3, closure=0x0, 2133183184, 2133435364, 0, 2134603892, 4, 2134603908, 0, 2133447592, 3, 0) at Python/ceval.c:3267 #21 0x7f71337c in fast_function (func=0x7f29b924, pp_stack=0x7fffcd30, n=4, na=4, nk=0, 2133440804, 2147470640, 4, 4, 0) at Python/ceval.c:4131 #22 0x7f713106 in call_function (pp_stack=0x7fffcd30, oparg=4, 2147470640, 4) at Python/ceval.c:4056 #23 0x7f70fe32 in PyEval_EvalFrameEx (f=0x7f3b76ec, throwflag=0, 2134603500, 0) at Python/ceval.c:2681 #24 0x7f711523 in PyEval_EvalCodeEx (co=0x7f23ecc8, globals=0x7f33e714, locals=0x0, args=0x7f2d1198, argcount=5, kws=0x7f2d11ac, kwcount=0, defs=0x7f24bfd8, defcount=4, closure=0x0, 2133060808, 2134107924, 0, 2133660056, 5, 2133660076, 0, 2133114840, 4, 0) at Python/ceval.c:3267 #25 0x7f71337c in fast_function (func=0x7f29b844, pp_stack=0x7fffd01c, n=5, na=5, nk=0, 2133440580, 2147471388, 5, 5, 0) at Python/ceval.c:4131 #26 0x7f713106 in call_function (pp_stack=0x7fffd01c, oparg=5, 2147471388, 5) at Python/ceval.c:4056 #27 0x7f70fe32 in PyEval_EvalFrameEx (f=0x7f2d102c, throwflag=0, 2133659692, 0) at Python/ceval.c:2681 #28 0x7f711523 in PyEval_EvalCodeEx (co=0x7f258188, globals=0x7f33e714, locals=0x0, args=0x7f295660, argcount=6, kws=0x7f295678, kwcount=0, defs=0x7f24cc68, defcount=5, closure=0x0, 2133164424, 2134107924, 0, 2133415520, 6, 2133415544, 0, 2133118056, 5, 0) at Python/ceval.c:3267 #29 0x7f71337c in fast_function (func=0x7f29b7d4, pp_stack=0x7fffd308, n=6, na=6, nk=0, 2133440468, 2147472136, 6, 6, 0) at Python/ceval.c:4131 #30 0x7f713106 in call_function (pp_stack=0x7fffd308, oparg=6, 2147472136, 6) at Python/ceval.c:4056 #31 0x7f70fe32 in PyEval_EvalFrameEx (f=0x7f2954f4, throwflag=0, 2133415156, 0) at Python/ceval.c:2681 #32 0x7f711523 in PyEval_EvalCodeEx (co=0x7f258188, globals=0x7f33e714, locals=0x0, args=0x7f2a31a8, argcount=6, kws=0x7f2a31c0, kwcount=0, defs=0x7f24cc68, defcount=5, closure=0x0, 2133164424, 2134107924, 0, 2133471656, 6, 2133471680, 0, 2133118056, 5, 0) at Python/ceval.c:3267 #33 0x7f71337c in fast_function (func=0x7f29b7d4, pp_stack=0x7fffd5f4, n=6, na=6, nk=0, 2133440468, 2147472884, 6, 6, 0) at Python/ceval.c:4131 #34 0x7f713106 in call_function (pp_stack=0x7fffd5f4, oparg=6, 2147472884, 6) at Python/ceval.c:4056 #35 0x7f70fe32 in PyEval_EvalFrameEx (f=0x7f2a302c, throwflag=0, 2133471276, 0) at Python/ceval.c:2681 #36 0x7f7132c0 in fast_function (func=0x7f29ba04, pp_stack=0x7fffd7e0, n=0, na=0, nk=0, 2133441028, 2147473376, 0, 0, 0) at Python/ceval.c:4121 #37 0x7f713106 in call_function (pp_stack=0x7fffd7e0, oparg=0, 2147473376, 0) at Python/ceval.c:4056 #38 0x7f70fe32 in PyEval_EvalFrameEx (f=0x7f25370c, throwflag=0, 2133145356, 0) at Python/ceval.c:2681 #39 0x7f711523 in PyEval_EvalCodeEx (co=0x7f25c0b0, globals=0x7f33e714, locals=0x7f33e714, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0, 2133180592, 2134107924, 2134107924, 0, 0, 0, 0, 0, 0, 0) at Python/ceval.c:3267 #40 0x7f70af1b in PyEval_EvalCode (co=0x7f25c0b0, globals=0x7f33e714, locals=0x7f33e714, 2133180592, 2134107924, 2134107924) at Python/ceval.c:669 #41 0x7f73365a in run_mod (mod=0x7f2f6e60, filename=0x7fffef44 "/usr/pkgsrc/lang/python27/work/.destdir/usr/pkg/lib/python2.7/compileall.py", globals=0x7f33e714, locals=0x7f33e714, flags=0x7fffdbe4, arena=0x7f348250, 2133814880, 2147479364, 2134107924, 2134107924, 2147474404, 2134147664) at Python/pythonrun.c:1371 #42 0x7f73360b in PyRun_FileExFlags (fp=0x7f5aa0c0, filename=0x7fffef44 "/usr/pkgsrc/lang/python27/work/.destdir/usr/pkg/lib/python2.7/compileall.py", start=257, globals=0x7f33e714, locals=0x7f33e714, closeit=1, flags=0x7fffdbe4, 2136645824, 2147479364, 257, 2134107924, 2134107924, 1, 2147474404) at Python/pythonrun.c:1357 #43 0x7f732658 in PyRun_SimpleFileExFlags (fp=0x7f5aa0c0, filename=0x7fffef44 "/usr/pkgsrc/lang/python27/work/.destdir/usr/pkg/lib/python2.7/compileall.py", closeit=1, flags=0x7fffdbe4, 2136645824, 2147479364, 1, 2147474404) at Python/pythonrun.c:949 #44 0x7f73207a in PyRun_AnyFileExFlags (fp=0x7f5aa0c0, filename=0x7fffef44 "/usr/pkgsrc/lang/python27/work/.destdir/usr/pkg/lib/python2.7/compileall.py", closeit=1, flags=0x7fffdbe4, 2136645824, 2147479364, 1, 2147474404) at Python/pythonrun.c:753 #45 0x7f741fc2 in Py_Main (argc=11, argv=0x7fffdcdc, 11, 2147474652) at Modules/main.c:640 #46 0x00010742 in main (argc=11, argv=0x7fffdcdc, 11, 2147474652, 2147474700) at Modules/python.c:23 ---------- components: Installation messages: 269739 nosy: stark priority: normal severity: normal status: open title: Python doesn't build due to test_float.py broken on non-IEEE machines type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 17:13:07 2016 From: report at bugs.python.org (Claude Paroz) Date: Sat, 02 Jul 2016 21:13:07 +0000 Subject: [issue27445] Charset instance not passed to set_payload() Message-ID: <1467493987.65.0.715756200587.issue27445@psf.upfronthosting.co.za> New submission from Claude Paroz: In issue #16324, I contributed an improvement so as MIMEText __init__ accept Charset instances, not only encoding strings. The use case is from Django where we customize the Charset.body_encoding before passing it to the MIMEText initialization. Unfortunately, what I didn't notice when Berker adapted my patch is that the Charset is casted to its string representation for the whole method, while I initially intended to let the unchanged Charset passed to self.set_payload. And the test I suggested was not smart enough to detect that. ---------- components: email messages: 269740 nosy: barry, claudep, r.david.murray priority: normal severity: normal status: open title: Charset instance not passed to set_payload() versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 17:25:05 2016 From: report at bugs.python.org (Claude Paroz) Date: Sat, 02 Jul 2016 21:25:05 +0000 Subject: [issue27445] Charset instance not passed to set_payload() In-Reply-To: <1467493987.65.0.715756200587.issue27445@psf.upfronthosting.co.za> Message-ID: <1467494705.28.0.291777387218.issue27445@psf.upfronthosting.co.za> Changes by Claude Paroz : ---------- keywords: +patch Added file: http://bugs.python.org/file43614/issue27445.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 17:50:56 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 02 Jul 2016 21:50:56 +0000 Subject: [issue27444] Python doesn't build due to test_float.py broken on non-IEEE machines In-Reply-To: <1467493851.35.0.417072100147.issue27444@psf.upfronthosting.co.za> Message-ID: <1467496256.06.0.737760028495.issue27444@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +mark.dickinson, tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 18:06:53 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 02 Jul 2016 22:06:53 +0000 Subject: [issue26624] Windows hangs in call to CRT setlocale() In-Reply-To: <1458747871.12.0.710719467032.issue26624@psf.upfronthosting.co.za> Message-ID: <1467497213.92.0.374556657605.issue26624@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I have recent gotten WARN: ucrtbased contains known issues. Please update Visual Studio or the Windows SDK. See: http://bugs.python.org/issue26624 F:\Python\dev\36\PCbuild\python.vcxproj(91,5): warning MSB3073: The command ""F:\Python\dev\36\PCBuild\win32\python_d.exe" "F:\Python\dev\36\PC\validate_ucrtbase.py" ucrtbased" exited with code 1. but Python still ran for me. Today, I recompiled, and python stopped running when I try to either run IDLE or patchcheck. To eliminate the old .dll as a cause, I tried to 'update'. How to do so? I started VS by double clicking pcbuild/python.vcxproj. The first barrier was that Community 2015 is only good for 30 days (the compiler invoked by build.bat still ran) and I could not access the menu. Once I got the license renewed, so VS ran, there is no Update entry on Help or anywhere else on the menu that I could find. (I seem to remember that VC Express updated automatically.) When I started VS2015 from the start menu instead, there was a splash screen with News and a link to a brand new Update 3. https://blogs.msdn.microsoft.com/visualstudio/2016/06/27/visual-studio-2015-update-3-and-net-core-1-0-available-now/ I clicked the first link and downloaded vs2015.3.exe. ran it, and left the minimal selection of components alone. After 3 GB downloaded and installed, there are error messages that *cannot* be copied and pasted. Here is a summary: 1. VS update prereq: Installer failed. bad hash 0x80091007 (did this mess up everything?) 2. Team J. Serv CTP! SToryboarding Pack file not found 0x80070002 (This does not seem like something I requested.) 3. VC++IDE base resource package ditto as to error. (Perhaps not needed for build.bat) Log file attached. I will restart and see what happens. ---------- nosy: +terry.reedy Added file: http://bugs.python.org/file43615/dd_vs_community_20160702172149.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 18:25:53 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 02 Jul 2016 22:25:53 +0000 Subject: [issue26624] Windows hangs in call to CRT setlocale() In-Reply-To: <1458747871.12.0.710719467032.issue26624@psf.upfronthosting.co.za> Message-ID: <1467498353.31.0.74281188092.issue26624@psf.upfronthosting.co.za> Terry J. Reedy added the comment: After the 'update', the compiler ran and re-linked all the targets. The warning about the old .dll remains. Perhaps I should remove and re-install? The crash also remain. I'll backdate the repository to mid-June when I successfully compiled and ran and see if I can find a particular commit causing the problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 19:19:15 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 02 Jul 2016 23:19:15 +0000 Subject: [issue26624] Windows hangs in call to CRT setlocale() In-Reply-To: <1458747871.12.0.710719467032.issue26624@psf.upfronthosting.co.za> Message-ID: <1467501555.4.0.242278049197.issue26624@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The problem was the last patch, for #26765. In spite of the faulty .dll, the test suite ran OK. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 19:19:24 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 02 Jul 2016 23:19:24 +0000 Subject: [issue26765] Factor out common bytes and bytearray implementation In-Reply-To: <1460707559.13.0.709090380773.issue26765@psf.upfronthosting.co.za> Message-ID: <1467501564.32.0.714805012558.issue26765@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Serhiy, compiling 3.6 on Windows after this patch lets it start, but causes it to crash both importing tkinter and running patchcheck. Compiling 3.6 after your previous patch for #27007 and the test suite runs without error. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 19:22:28 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 02 Jul 2016 23:22:28 +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: <1467501748.17.0.149765097635.issue27405@psf.upfronthosting.co.za> Terry J. Reedy added the comment: After re-compiling, import tkinter crashed 3.6. Reversion did not help. After trying to update VS2015 (not successfully), and doing a binary search, it was your patch for #26765. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 20:01:27 2016 From: report at bugs.python.org (R. David Murray) Date: Sun, 03 Jul 2016 00:01:27 +0000 Subject: [issue27444] Python doesn't build due to test_float.py broken on non-IEEE machines In-Reply-To: <1467493851.35.0.417072100147.issue27444@psf.upfronthosting.co.za> Message-ID: <1467504087.9.0.35796840804.issue27444@psf.upfronthosting.co.za> R. David Murray added the comment: It looks like you are in the compiling step, so the decorators have nothing to do with it. This does appear to be a platform issue in the interpreter core, and you'll have to track it down since we don't have access to your platform (at least, I don't think any of the core devs are set up to test on VAX). ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 20:07:39 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 03 Jul 2016 00:07:39 +0000 Subject: [issue26765] Factor out common bytes and bytearray implementation In-Reply-To: <1460707559.13.0.709090380773.issue26765@psf.upfronthosting.co.za> Message-ID: <1467504459.83.0.0536813597891.issue26765@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Checking, I see that 3 of 4 Windows buildbots ran with this patch, so there must be something significantly different about my VS install with respect to this particular patch. #26624 might or might not have something to do with it (see my posts today). I can't tell from the logs which update the buildbots are running. The fourth, x86windows7 crashed before running anything (http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/11283/steps/test/logs/stdio), after having previously run part way through the tests. It *might* have a similar problem, or might not. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 20:09:52 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 03 Jul 2016 00:09:52 +0000 Subject: [issue27442] expose Android API level in sys.implementation In-Reply-To: <1467471175.35.0.000904857777026.issue27442@psf.upfronthosting.co.za> Message-ID: <1467504592.19.0.611802688685.issue27442@psf.upfronthosting.co.za> Ned Deily added the comment: Typically, for other sorts of build configuration data, we have relied on extracting that from the ./configure-produced Makefile and making it available via sysconfig.get_config_var(). I think we should be cautious about bloating sys.implementation with platform-specific data unless there is an overriding need for it, for example, if it is needed during interpreter initialization before sysconfig can be initialized. If not, I'd look at adding the needed values as configuration variables in configure.ac. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 21:16:11 2016 From: report at bugs.python.org (ppperry) Date: Sun, 03 Jul 2016 01:16:11 +0000 Subject: [issue27363] Complex numbers with negative zero parts do not roundtrip properly In-Reply-To: <1466535728.31.0.514028528898.issue27363@psf.upfronthosting.co.za> Message-ID: <1467508571.85.0.261225606335.issue27363@psf.upfronthosting.co.za> Changes by ppperry : ---------- title: Complex numbers with negative zero imaginary parts do not roundtrip properly -> Complex numbers with negative zero parts do not roundtrip properly _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 2 22:08:05 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Sun, 03 Jul 2016 02:08:05 +0000 Subject: [issue27440] Trigonometric bug In-Reply-To: <1467466349.47.0.855783586648.issue27440@psf.upfronthosting.co.za> Message-ID: <1467511685.61.0.167297112285.issue27440@psf.upfronthosting.co.za> Steven D'Aprano added the comment: I know this issue is closed, but for future reference, ShubhamSingh.er, if you submit any further bug reports, please don't submit screen shots unless necessary. Just copy and paste the text from your terminal into the issue tracker. A screen shot is more work for you, less useful to us, and impossible for the blind and visually-impaired to work with using a screen reader. ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 3 00:25:21 2016 From: report at bugs.python.org (Davin Potts) Date: Sun, 03 Jul 2016 04:25:21 +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: <1467519920.9.0.6054631948.issue27081@psf.upfronthosting.co.za> Davin Potts added the comment: The spawned process (you appear to have run on Windows, so I'm assuming spawn but that's not so significant) has triggered an unhandled exception. If the triggering and subsequent sending of the traceback to stderr is synchronous and completes before Python actually kills the process, then the original "one would expect" statement would make sense. Removing the use of the Queue entirely and substituting the use of a socket to communicate from the child (spawned) process to some distinct listener process results in only a portion of the traceback text being received by the listener (or sometimes little to none of the traceback text). This suggests that the original premise is false and the expectation inaccurate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 3 00:31:30 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 03 Jul 2016 04:31:30 +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: <1467520290.4.0.174746043093.issue27400@psf.upfronthosting.co.za> Nick Coghlan added the comment: Thanks for the report Denny. Looking at https://hg.python.org/cpython/file/30099abdb3a4/Modules/datetimemodule.c#l3929, there's a problematic caching of the "_strptime" module that is almost certainly the cause of the problem - it will attempt to call _strptime._strptime from the already finalized interpreter rather than the new one. It should be possible to adjust that logic to permit a check for _strptime._strptime being set to None, and reimporting _strptime in that case. ---------- nosy: +belopolsky, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 3 01:09:26 2016 From: report at bugs.python.org (koobs) Date: Sun, 03 Jul 2016 05:09:26 +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: <1467522566.81.0.990999299155.issue23908@psf.upfronthosting.co.za> koobs added the comment: koobs-freebsd{9,10,current) failing after 30099abdb3a46d0e306a4cf995b95fa8cfb8b78a merge to 2.7 ---------- nosy: +koobs resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 3 01:10:18 2016 From: report at bugs.python.org (koobs) Date: Sun, 03 Jul 2016 05:10:18 +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: <1467522618.61.0.952851322813.issue23908@psf.upfronthosting.co.za> koobs added the comment: ====================================================================== ERROR: test_path_with_null_unicode (test.test_posix.PosixTester) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/buildbot/python/2.7.koobs-freebsd9/build/Lib/test/test_posix.py", line 585, in test_path_with_null_unicode test_support.unlink(fn) File "/usr/home/buildbot/python/2.7.koobs-freebsd9/build/Lib/test/test_support.py", line 243, in unlink _unlink(filename) UnicodeEncodeError: 'ascii' codec can't encode characters in position 6-7: ordinal not in range(128) ====================================================================== ERROR: test_path_with_null_unicode (test.test_posix.PosixTester) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/buildbot/python/2.7.koobs-freebsd9/build/Lib/test/test_support.py", line 243, in unlink _unlink(filename) UnicodeEncodeError: 'ascii' codec can't encode characters in position 6-7: ordinal not in range(128) ---------------------------------------------------------------------- Ran 43 tests in 0.105s ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 3 03:55:41 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 Jul 2016 07:55:41 +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: <20160703075538.882.1358.7BA716B9@psf.io> Roundup Robot added the comment: New changeset b0e8a2e7c361 by Serhiy Storchaka in branch '2.7': Fixed a test for issue23908 with C locale. https://hg.python.org/cpython/rev/b0e8a2e7c361 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 3 03:57:14 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 Jul 2016 07:57:14 +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: <1467532634.9.0.0493669001211.issue23908@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for noticing this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 3 04:40:42 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 03 Jul 2016 08:40:42 +0000 Subject: [issue27442] expose Android API level in sys.implementation In-Reply-To: <1467471175.35.0.000904857777026.issue27442@psf.upfronthosting.co.za> Message-ID: <1467535242.11.0.028803319889.issue27442@psf.upfronthosting.co.za> Xavier de Gaye added the comment: @Ned The information that the interpreter is an Android built, is needed in issue 16353 [1][2]. In msg266135, the corresponding patch adds the 'is_android' attribute to the already bloated sys module. I had thought then about using sysconfig.get_config_var() as you are suggesting, but this means that the os module would need now to import sysconfig on all linux platforms and build this big dictionary (about 650 entries on linux). So it seems that the choice is between: (1) adding an attribute (is_android or android_api) to the bloated sys module (2) bloating sys.implementation with platform-specific data I think that (2) would be better since _android_api is an information about the implementation, it tells that in these binaries, such and such features are available or not (issue 26857 for example). The drawback is that it would not be documented except in Misc/NEWS [2]. @Victor Do you mean a public attribute of sys.implementation ? Adding a new sys.implementation required attribute is described in pep 421. In that case the attribute name could be 'libc_version' or 'libc'. [1] msg175006 suggested another approach though, but this seems to be abandoned. [2] For completeness, Stefan has submitted a feature request to google in msg266089. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 3 05:37:01 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 03 Jul 2016 09:37:01 +0000 Subject: [issue27442] expose Android API level in sys.implementation In-Reply-To: <1467471175.35.0.000904857777026.issue27442@psf.upfronthosting.co.za> Message-ID: <1467538621.54.0.87581356059.issue27442@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Well, issue 16353 has been entered upon attempting to fix issue 16255 (see msg173477). So an alternative exists. Issue 16353 could be closed as 'wont't fix'. The list of locations where '/bin/sh' is hard coded in the standard library in msg266084 shows that only the subprocess module and the test suite need to know the location of the system shell. So the subprocess module and issue 27027 could deduct the location of this shell via sysconfig.get_config_var('android_api'). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 3 06:27:50 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 Jul 2016 10:27:50 +0000 Subject: [issue26765] Factor out common bytes and bytearray implementation In-Reply-To: <1460707559.13.0.709090380773.issue26765@psf.upfronthosting.co.za> Message-ID: <20160703102747.26057.60792.7D83AD99@psf.io> Roundup Robot added the comment: New changeset 0638047c0c36 by Serhiy Storchaka in branch 'default': Issue #26765: Fixed parsing Py_ssize_t arguments on 32-bit Windows. https://hg.python.org/cpython/rev/0638047c0c36 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 3 06:58:11 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 Jul 2016 10:58:11 +0000 Subject: [issue26765] Factor out common bytes and bytearray implementation In-Reply-To: <1460707559.13.0.709090380773.issue26765@psf.upfronthosting.co.za> Message-ID: <20160703105809.10758.30474.471FE1BC@psf.io> Roundup Robot added the comment: New changeset 6c4c0a23fabb by Serhiy Storchaka in branch 'default': Backed out changeset b0087e17cd5e (issue #26765) https://hg.python.org/cpython/rev/6c4c0a23fabb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 3 06:59:33 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 Jul 2016 10:59:33 +0000 Subject: [issue26765] Factor out common bytes and bytearray implementation In-Reply-To: <1460707559.13.0.709090380773.issue26765@psf.upfronthosting.co.za> Message-ID: <1467543573.43.0.010331219868.issue26765@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I don't know what is wrong with this patch. Backed out just for the case. ---------- resolution: fixed -> stage: resolved -> patch review status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 3 07:42:43 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 Jul 2016 11:42:43 +0000 Subject: [issue27443] __length_hint__() of bytearray iterator can return negative integer In-Reply-To: <1467489234.07.0.837465555055.issue27443@psf.upfronthosting.co.za> Message-ID: <20160703114240.31154.94147.E033FCEC@psf.io> Roundup Robot added the comment: New changeset 6b084bb6c38b by Serhiy Storchaka in branch '3.5': Issue #27443: __length_hint__() of bytearray itearator no longer return https://hg.python.org/cpython/rev/6b084bb6c38b New changeset 03192909160d by Serhiy Storchaka in branch 'default': Issue #27443: __length_hint__() of bytearray itearator no longer return https://hg.python.org/cpython/rev/03192909160d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 3 07:43:54 2016 From: report at bugs.python.org (Greg Stark) Date: Sun, 03 Jul 2016 11:43:54 +0000 Subject: [issue27444] Python doesn't build due to test_float.py broken on non-IEEE machines In-Reply-To: <1467493851.35.0.417072100147.issue27444@psf.upfronthosting.co.za> Message-ID: <1467546234.24.0.745827140864.issue27444@psf.upfronthosting.co.za> Greg Stark added the comment: I can easily grant you access to mine. It's a bit slow but you can quickly poke around with the state in the backtrace which honestly looks to me like it should be enough to spot the problem. There are other options. There's a good emulator at http://simh.trailing-edge.com/ and there are other non-ieee platforms out there. But installing an OS is a bit of a hassle. If you're interested send me your email address and preferably a public key or something and I'll send you a login. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 3 08:17:43 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 03 Jul 2016 12:17:43 +0000 Subject: [issue27429] xml.sax.saxutils.escape doesn't escape multiple characters safely In-Reply-To: <1467329284.42.0.570425192888.issue27429@psf.upfronthosting.co.za> Message-ID: <1467548263.95.0.432752652049.issue27429@psf.upfronthosting.co.za> Xiang Zhang added the comment: I think this a bug. There should be no override when escape or unescape. Upload a patch to fix this. ---------- keywords: +patch nosy: +martin.panter, serhiy.storchaka Added file: http://bugs.python.org/file43616/issue27429.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 3 08:18:19 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 Jul 2016 12:18:19 +0000 Subject: [issue27443] __length_hint__() of bytearray iterator can return negative integer In-Reply-To: <1467489234.07.0.837465555055.issue27443@psf.upfronthosting.co.za> Message-ID: <1467548299.12.0.194198337446.issue27443@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 Sun Jul 3 08:28:32 2016 From: report at bugs.python.org (fourplusone) Date: Sun, 03 Jul 2016 12:28:32 +0000 Subject: [issue24960] Can't use pip or easy_install with embeddable zip file. In-Reply-To: <1440869782.83.0.207113001402.issue24960@psf.upfronthosting.co.za> Message-ID: <1467548912.5.0.107062231546.issue24960@psf.upfronthosting.co.za> fourplusone added the comment: The problem is indeed that lib2to3 fails to load the Grammar.txt file if it is located inside a .zip archive. I think one way to fix it is using of the "get_data" function of the loader https://docs.python.org/3/library/importlib.html#importlib.abc.ResourceLoader.get_data However, this would make caching the Grammar more difficult, as one cannot write back the pickled dict to a zip file Alternatively one could generate an importable *.pyc file from the grammar during the build process ---------- nosy: +fourplusone _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 3 08:29:28 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 Jul 2016 12:29:28 +0000 Subject: [issue27429] xml.sax.saxutils.escape doesn't escape multiple characters safely In-Reply-To: <1467329284.42.0.570425192888.issue27429@psf.upfronthosting.co.za> Message-ID: <1467548968.16.0.36961231818.issue27429@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The purpose of xml.sax.saxutils.escape() is escaping characters, that can't be used directly in XML: "&", "<", etc. Quotes are escaped in attributes. It shouldn't be used for replacing ";", because this character itself is used in escapes. There is no a bug. If use this function correctly it works as expected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 3 08:38:36 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 03 Jul 2016 12:38:36 +0000 Subject: [issue27429] xml.sax.saxutils.escape doesn't escape multiple characters safely In-Reply-To: <1467329284.42.0.570425192888.issue27429@psf.upfronthosting.co.za> Message-ID: <1467549516.35.0.480500735187.issue27429@psf.upfronthosting.co.za> Xiang Zhang added the comment: I thought of that too. But the doc doesn't tell you that you can not put any characters in the entities, so I think we should make the implementation right when some unexpected characters are passed in. If you don't like the implementation to be changed, I think at least we should declare that in the documentation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 3 08:43:18 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 Jul 2016 12:43:18 +0000 Subject: [issue27429] xml.sax.saxutils.escape doesn't escape multiple characters safely In-Reply-To: <1467329284.42.0.570425192888.issue27429@psf.upfronthosting.co.za> Message-ID: <1467549798.85.0.292555317884.issue27429@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 3 10:17:00 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 03 Jul 2016 14:17:00 +0000 Subject: [issue27429] xml.sax.saxutils.escape doesn't escape multiple characters safely In-Reply-To: <1467329284.42.0.570425192888.issue27429@psf.upfronthosting.co.za> Message-ID: <1467555420.79.0.310648403386.issue27429@psf.upfronthosting.co.za> Xiang Zhang added the comment: Put a not in escape's doc. ---------- Added file: http://bugs.python.org/file43617/sax_escape_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 3 10:37:56 2016 From: report at bugs.python.org (R. David Murray) Date: Sun, 03 Jul 2016 14:37:56 +0000 Subject: [issue27444] Python doesn't build due to test_float.py broken on non-IEEE machines In-Reply-To: <1467493851.35.0.417072100147.issue27444@psf.upfronthosting.co.za> Message-ID: <1467556676.25.0.471203143601.issue27444@psf.upfronthosting.co.za> R. David Murray added the comment: I don't have time to tackle it myself; maybe Mark will be interested, but he probably doesn't have time either. Also, he's been known to say he'd like to drop support for non-IEEE architectures ;) I suspect it will be up to someone with an investment in the platform, this being a volunteer project. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 3 12:20:09 2016 From: report at bugs.python.org (Zack Weinberg) Date: Sun, 03 Jul 2016 16:20:09 +0000 Subject: [issue27446] struct: allow per-item byte order Message-ID: <1467562809.45.0.522502679617.issue27446@psf.upfronthosting.co.za> New submission from Zack Weinberg: Occasionally one encounters binary formats which do not stick to one byte order throughout. For example, I have a C program that reads and writes arrays of this struct: ``` struct conn_data { uint32_t ipv4_addr; /* read - network byte order - target IPv4 address */ uint16_t tcp_port; /* read - network byte order - target TCP port */ uint16_t errnm; /* write - native byte order - errno code */ uint64_t elapsed; /* write - native byte order - elapsed time in ns */ }; ``` On little-endian systems, the first and second fields of this struct will be in the opposite byte order from the third and fourth. If the struct module allowed specification of byte order on a per-item basis, it would make working with structures of this type simpler. Hypothetical notation: ``` addr, port, errnm, elapsed = struct.unpack("=4s!H=H=Q") addr = socket.inet_ntoa(addr) ``` instead of what one must do now, ``` addr, port, errnm, elapsed = struct.unpack("=4sHHQ") addr = socket.inet_ntoa(addr) port = socket.ntohs(port) ``` To avoid ambiguities and confusion, I would suggest that, if more than one item has its own byte-order specifier, _all_ items must have byte-order specifiers (with the possible exception of the 1-byte item types?), and that this is not allowed in an '@'-mode format. ---------- components: Library (Lib) messages: 269770 nosy: zwol priority: normal severity: normal status: open title: struct: allow per-item byte order type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 3 14:04:22 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 Jul 2016 18:04:22 +0000 Subject: [issue23034] Dynamically control debugging output In-Reply-To: <1418332173.89.0.386427809737.issue23034@psf.upfronthosting.co.za> Message-ID: <20160703180419.31583.17029.4A5C8AE1@psf.io> Roundup Robot added the comment: New changeset cd911e06bf6c by Serhiy Storchaka in branch 'default': Issue #23034: The output of a special Python build with defined COUNT_ALLOCS, https://hg.python.org/cpython/rev/cd911e06bf6c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 3 15:31:16 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 Jul 2016 19:31:16 +0000 Subject: [issue19527] Test failures with COUNT_ALLOCS In-Reply-To: <1383913813.74.0.198352256395.issue19527@psf.upfronthosting.co.za> Message-ID: <20160703193113.83102.98728.9288A6FD@psf.io> Roundup Robot added the comment: New changeset 5abf6cdcac4d by Serhiy Storchaka in branch '3.5': Issue #19527: Fixed tests with defined COUNT_ALLOCS. https://hg.python.org/cpython/rev/5abf6cdcac4d New changeset e7d84ecdd37d by Serhiy Storchaka in branch 'default': Issue #19527: Fixed tests with defined COUNT_ALLOCS. https://hg.python.org/cpython/rev/e7d84ecdd37d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 3 15:43:45 2016 From: report at bugs.python.org (Giampaolo Rodola') Date: Sun, 03 Jul 2016 19:43:45 +0000 Subject: [issue26081] Implement asyncio Future in C to improve performance In-Reply-To: <1452533022.97.0.443242974791.issue26081@psf.upfronthosting.co.za> Message-ID: <1467575025.49.0.941546492931.issue26081@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 3 16:18:20 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 03 Jul 2016 20:18:20 +0000 Subject: [issue26081] Implement asyncio Future in C to improve performance In-Reply-To: <1467575025.52.0.482303914342.issue26081@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: We should really try to get this into 3.6. --Guido (mobile) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 3 18:21:35 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 03 Jul 2016 22:21:35 +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: <1467584495.06.0.0594463304784.issue27380@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Added tests for ModuleName. Will recheck and push. ---------- Added file: http://bugs.python.org/file43618/query4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 3 19:11:33 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 Jul 2016 23:11:33 +0000 Subject: [issue27437] IDLE tests must be able to set user configuration values. In-Reply-To: <1467400772.1.0.605855673918.issue27437@psf.upfronthosting.co.za> Message-ID: <20160703231130.2201.37664.10365584@psf.io> Roundup Robot added the comment: New changeset 78a3d3700233 by Terry Jan Reedy in branch 'default': Issue 27437: Add query.ModuleName and use it for file => Load Module. https://hg.python.org/cpython/rev/78a3d3700233 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 3 23:31:20 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 04 Jul 2016 03:31:20 +0000 Subject: [issue27437] IDLE tests must be able to set user configuration values. In-Reply-To: <1467400772.1.0.605855673918.issue27437@psf.upfronthosting.co.za> Message-ID: <1467603080.0.0.179487738342.issue27437@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- Removed message: http://bugs.python.org/msg269775 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 3 23:32:42 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 04 Jul 2016 03:32:42 +0000 Subject: [issue27437] IDLE tests must be able to set user configuration values. In-Reply-To: <1467400772.1.0.605855673918.issue27437@psf.upfronthosting.co.za> Message-ID: <1467603162.8.0.0898705848321.issue27437@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Message for #27380 deleted and copied there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 3 23:32:51 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 04 Jul 2016 03:32:51 +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: <1467603171.11.0.66210342522.issue27380@psf.upfronthosting.co.za> Terry J. Reedy added the comment: (Misdirected notice copied here) New changeset 78a3d3700233 by Terry Jan Reedy in branch 'default': Issue 27437: Add query.ModuleName and use it for file => Load Module. https://hg.python.org/cpython/rev/78a3d3700233 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 00:17:30 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 04 Jul 2016 04:17:30 +0000 Subject: [issue27437] IDLE tests must be able to set user configuration values. In-Reply-To: <1467400772.1.0.605855673918.issue27437@psf.upfronthosting.co.za> Message-ID: <1467605850.92.0.72011151608.issue27437@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I believe this is enough to test the new Unix keys patch #27173. Will backport the test file and StringIO import and the additions to IdleUserConfParser in config to support backporting tests for 27173. ---------- keywords: +patch stage: needs patch -> commit review versions: +Python 2.7, Python 3.5 Added file: http://bugs.python.org/file43619/set_user_cfg.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 00:54:10 2016 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 04 Jul 2016 04:54:10 +0000 Subject: [issue24960] Can't use lib2to3 with embeddable zip file. In-Reply-To: <1440869782.83.0.207113001402.issue24960@psf.upfronthosting.co.za> Message-ID: <1467608050.81.0.224888389006.issue24960@psf.upfronthosting.co.za> Nick Coghlan added the comment: (issue title updated to indicate this appears to be lib2to3 related and added Benjamin Peterson to the nosy list) The build process already generates a _sysconfigdata.py file in order to pass along build time details to the sysconfig module in a way that isn't dependent on having otherwise build-time only files accessible at runtime. Doing something similar with a _lib2to3grammar.py file seems like it could be a reasonable approach to making lib2to3 zip archive friendly, but I'm not familiar enough with pgen2's internals to say how feasible that would be. ---------- nosy: +benjamin.peterson title: Can't use pip or easy_install with embeddable zip file. -> Can't use lib2to3 with embeddable zip file. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 04:26:45 2016 From: report at bugs.python.org (Mark Hammond) Date: Mon, 04 Jul 2016 08:26:45 +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: <1467620805.05.0.996316601963.issue27410@psf.upfronthosting.co.za> Mark Hammond added the comment: While I agree the risk is fairly low and it will require effort to actually do, it still sounds worth fixing at some point. A user might be tricked into downloading a DLL - eg, Firefox will happily save it without any scary UI - it's just a file. Later they run our "trusted" download from the same directory and we screw them - even if the attacker can't elevate they can do damage. ---------- nosy: +mhammond _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 05:54:32 2016 From: report at bugs.python.org (towb) Date: Mon, 04 Jul 2016 09:54:32 +0000 Subject: [issue27447] python -m doctest file_with_no_py_extension # silently fails Message-ID: <1467626072.62.0.919470824468.issue27447@psf.upfronthosting.co.za> New submission from towb: Command line tools usually use the shebang and don't have a .py extension. This breaks the `python -m doctest` shortcut for testmod(). Getting it to work is probably ugly, but there should be a useful message. Currently it's just a NameError for every function, which is very confusing. ---------- components: Library (Lib) messages: 269781 nosy: towb priority: normal severity: normal status: open title: python -m doctest file_with_no_py_extension # silently fails type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 07:29:32 2016 From: report at bugs.python.org (Aaron Sokoloski) Date: Mon, 04 Jul 2016 11:29:32 +0000 Subject: [issue24959] unittest swallows part of stack trace when raising AssertionError in a TestCase In-Reply-To: <1440864914.24.0.799928607113.issue24959@psf.upfronthosting.co.za> Message-ID: <1467631772.7.0.523375519832.issue24959@psf.upfronthosting.co.za> Aaron Sokoloski added the comment: I've run into this bug too. Took a while to track down the cause :) ---------- nosy: +Aaron Sokoloski _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 08:52:32 2016 From: report at bugs.python.org (Andrew) Date: Mon, 04 Jul 2016 12:52:32 +0000 Subject: [issue27448] Race condition in subprocess.Popen which causes a huge memory leak Message-ID: <1467636752.08.0.502936379731.issue27448@psf.upfronthosting.co.za> New submission from Andrew: We had problem where at some point python start consuming RAM. Until it ends. The reason was race condition in subprocess.Popen. Which triggered gc.disable() and never gc.enable(). The workaround we use is: subprocess.gc.isenabled = lambda: True The scenario for race condition is pretty obvious looking into the code below: gc_was_enabled = gc.isenabled() <- T1 gets false here gc.disable() try: self.pid = os.fork() <- while T2 is here except: if gc_was_enabled: gc.enable() raise ... CODE FRAGMENT 1 ... if gc_was_enabled: gc.enable() Also I wonder if exception fails in "... CODE FRAGMENT 1 ..." why don't we re-enable gc (finally block) ---------- messages: 269783 nosy: aonishuk priority: normal severity: normal status: open title: Race condition in subprocess.Popen which causes a huge memory leak versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 09:08:25 2016 From: report at bugs.python.org (frank-e) Date: Mon, 04 Jul 2016 13:08:25 +0000 Subject: [issue27449] pip install --upgrade pip (Windows) Message-ID: <1467637705.46.0.30850712587.issue27449@psf.upfronthosting.co.za> New submission from frank-e: `python -m pip install --upgrade pip` on Windows 7 with Python 3.5.2 installed for all users, PermissionError: [WinError 5] Access denied: 'c:\\program files\\python35\\lib\\site-packages\\p ip-8.1.1.dist-info\\description.rst' ---------- components: Windows files: pip.8.1.1.txt messages: 269784 nosy: frank-e, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: pip install --upgrade pip (Windows) versions: Python 3.5 Added file: http://bugs.python.org/file43620/pip.8.1.1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 09:18:08 2016 From: report at bugs.python.org (Martin Ritter) Date: Mon, 04 Jul 2016 13:18:08 +0000 Subject: [issue27422] Deadlock when mixing threading and multiprocessing In-Reply-To: <1467303803.25.0.914359339926.issue27422@psf.upfronthosting.co.za> Message-ID: <1467638288.54.0.424124907663.issue27422@psf.upfronthosting.co.za> Martin Ritter added the comment: I agree that this is error prone and can not be fixed reliably on the python side. However, python makes it very easy to mix these two, a user might not even notice it if a function he calls uses fork and thus just use a ThreadPoolExecutor() because it's the simplest thing to do. What could be an nice solution in my opinion if the multiprocessing module could check if there are already multiple threads active on process creation and issue a warning if so. This warning could of course be optional but would make this issue more obvious. In my case we have a large C++ code base which still includes a lot of Fortran 77 code with common blocks all over the place (yay science). Everything is interfaced in python so to make sure that I do not have any side effects I run the some of the functions in a fork using multiprocessing.Process(). And in this case I just wanted to run some testing in parallel. I now switched to a ProcessPoolExecutor which works fine but for me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 09:49:03 2016 From: report at bugs.python.org (Zachary Ware) Date: Mon, 04 Jul 2016 13:49:03 +0000 Subject: [issue27449] pip install --upgrade pip (Windows) In-Reply-To: <1467637705.46.0.30850712587.issue27449@psf.upfronthosting.co.za> Message-ID: <1467640143.9.0.571950934476.issue27449@psf.upfronthosting.co.za> Zachary Ware added the comment: As the traceback suggests, you don't have permission to write there. You'll need to run that as an administrator, but note that you'll run into a different issue using the 'pip' command to upgrade itself; use 'py -3.5 -m pip install -U pip' instead. Also, pip is not actually part of the standard library, it's just bundled with CPython. For any change you'd like to see in pip's behavior, you'll need to raise an issue on pip's issue tracker (https://github.com/pypa/pip/issues). ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 10:03:28 2016 From: report at bugs.python.org (Jakub Wilk) Date: Mon, 04 Jul 2016 14:03:28 +0000 Subject: [issue12806] argparse: Hybrid help text formatter In-Reply-To: <1313973978.37.0.422477813424.issue12806@psf.upfronthosting.co.za> Message-ID: <1467641008.39.0.229161608326.issue12806@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 10:15:28 2016 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 04 Jul 2016 14:15:28 +0000 Subject: [issue27439] Add a product() function to the standard library In-Reply-To: <1467459648.57.0.0102935074886.issue27439@psf.upfronthosting.co.za> Message-ID: <1467641728.35.0.268629002782.issue27439@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 11:19:42 2016 From: report at bugs.python.org (Davin Potts) Date: Mon, 04 Jul 2016 15:19:42 +0000 Subject: [issue27422] Deadlock when mixing threading and multiprocessing In-Reply-To: <1467303803.25.0.914359339926.issue27422@psf.upfronthosting.co.za> Message-ID: <1467645582.9.0.573280293629.issue27422@psf.upfronthosting.co.za> Davin Potts added the comment: While I believe I understand the motivation behind the suggestion to detect when the code is doing something potentially dangerous, I'll point out a few things: * any time you ask for a layer of convenience, you must choose something to sacrifice to get it (usually performance is sacrificed) and this sacrifice will affect all code (including non-problematic code) * behind the scenes multiprocessing itself is employing multiple threads in the creation and coordination between processes -- "checking to see if there are multiple threads active on process creation" is therefore a more complicated request than it maybe first appears * Regarding "python makes it very easy to mix these two", I'd say it's nearly as easy to mix the two in C code -- the common pattern across different languages is to learn the pros+cons+gotchyas of working with processes and threads I too come from the world of scientific software and the mixing of Fortran, C/C++, and Python (yay science and yay Fortran) so I'll make another point (apologies if you already knew this): There's a lot of computationally intensive code in scientific code/applications and being able to perform those computations in parallel is a wonderful thing. I am unsure if the tests you're trying to speed up exercise compute-intensive functions but let's assume they do. For reasons not described here, using the CPython implementation, there is a constraint on the use of threads that restricts them to all run on a single core of your multi-core cpu (and on only one cpu if you have an SMP system). Hence spinning up threads to perform compute intensive tasks will likely result in no better throughput (no speedup) because they're all fighting over the same maxed-out core. To spread out onto and take advantage of multiple cores (and multiple cpus on an SMP system) you will want switch to creating processes (as you say you now have). I'd make the distinction that you are likely much more interested in 'parallel computing' than 'concurrent execution'. Since you're already using multiprocessing you might also simply use `multiprocessing.Pool`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 11:33:55 2016 From: report at bugs.python.org (Greg Stark) Date: Mon, 04 Jul 2016 15:33:55 +0000 Subject: [issue27444] Python doesn't build due to test_float.py broken on non-IEEE machines In-Reply-To: <1467493851.35.0.417072100147.issue27444@psf.upfronthosting.co.za> Message-ID: <1467646435.87.0.66320681929.issue27444@psf.upfronthosting.co.za> Greg Stark added the comment: I certainly understand the limitations of volunteer projects. I know you have limited resources and can't test on every platform. That's actually exactly why I'm testing on this platform and why I reported the bug. If there's any additional information I can provide to help you I can try to get it. I found this while trying to build a Postgres build-farm member to help us identify portability issues quickly on platforms that aren't widely used by developers. If Python has similar infrastructure I could deploy it to the same hardware to help you spot these problems sooner. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 11:46:41 2016 From: report at bugs.python.org (Stefan Krah) Date: Mon, 04 Jul 2016 15:46:41 +0000 Subject: [issue27444] Python doesn't build due to test_float.py broken on non-IEEE machines In-Reply-To: <1467493851.35.0.417072100147.issue27444@psf.upfronthosting.co.za> Message-ID: <1467647201.06.0.897372316811.issue27444@psf.upfronthosting.co.za> Stefan Krah added the comment: It looks like the peephole optimizer chokes on some constant folding. Probably: INF = float("inf") NAN = float("nan") -INF -NAN You could try some combinations in the REPL. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 12:29:27 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 Jul 2016 16:29:27 +0000 Subject: [issue23034] Dynamically control debugging output In-Reply-To: <1418332173.89.0.386427809737.issue23034@psf.upfronthosting.co.za> Message-ID: <1467649767.75.0.694651689605.issue23034@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 12:32:24 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 04 Jul 2016 16:32:24 +0000 Subject: [issue27447] python -m doctest script_file_with_no_py_extension produces confusing NameErrors In-Reply-To: <1467626072.62.0.919470824468.issue27447@psf.upfronthosting.co.za> Message-ID: <1467649944.78.0.239369626113.issue27447@psf.upfronthosting.co.za> R. David Murray added the comment: This is not a bug, it is a feature. python -m doctest can be used to run tests from files that are *not* python files. I wouldn't call tracebacks with name errors as a silent failure :) As you say, there is no easy way to use doctest to run doctests in a script file that is not a .py file, since it can't be imported, so I'm not sure there is anything that can be done here. Even trying to guess that it is a python file and issuing an error message or even a warning is problematic from a backward compatibility standpoint, since there may be people with files that look like python files that are *meant* to be run as doctests. I'm guessing script-with-testable-docstrings isn't *common*, though I can easily imagine myself writing one (using subprocess to re-exec the script). What I actually did, though, was have a command line switch that runs the doctests by calling testmod from within the script, which is how doctest is designed to work. So, we can see what other people think about the idea of looking for a shebang line and issuing an error message. Or maybe a warning...or an error plus a command line switch to force it to process the script anyway? ---------- nosy: +r.david.murray title: python -m doctest file_with_no_py_extension # silently fails -> python -m doctest script_file_with_no_py_extension produces confusing NameErrors versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 12:33:17 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 Jul 2016 16:33:17 +0000 Subject: [issue19527] Test failures with COUNT_ALLOCS In-Reply-To: <1383913813.74.0.198352256395.issue19527@psf.upfronthosting.co.za> Message-ID: <1467649997.9.0.226688955728.issue19527@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: All tests now are passed in 3.6 on Linux. Making them passing in 3.5 requires too much changes that are not needed in 3.6. I don't think we need to pollute tests with these temporary workarounds. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 12:34:36 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 Jul 2016 16:34:36 +0000 Subject: [issue23591] Add IntFlags In-Reply-To: <1425569483.33.0.144069723147.issue23591@psf.upfronthosting.co.za> Message-ID: <1467650076.33.0.00478456071094.issue23591@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping again. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 12:35:10 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 Jul 2016 16:35:10 +0000 Subject: [issue26974] Crash in Decimal.from_float In-Reply-To: <1462684427.76.0.86950702335.issue26974@psf.upfronthosting.co.za> Message-ID: <1467650110.84.0.284475690382.issue26974@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 12:37:13 2016 From: report at bugs.python.org (Martin Ritter) Date: Mon, 04 Jul 2016 16:37:13 +0000 Subject: [issue27422] Deadlock when mixing threading and multiprocessing In-Reply-To: <1467303803.25.0.914359339926.issue27422@psf.upfronthosting.co.za> Message-ID: <1467650233.15.0.591093318116.issue27422@psf.upfronthosting.co.za> Martin Ritter added the comment: Dear Davin, Thanks for the input, I was perfectly aware that the "solution" I proposed is not realistic. But the feedback that multiprocessing is using threads internally is useful as I can quickly abandon the idea to do something like the check I proposed in our code base without spending time on it. I was aware of the Gil, I just did not anticipate that big a problem when mixing threads and processes with rather simple python code. My bad, sorry for the noise. Cheers, Martin ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 12:41:02 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 Jul 2016 16:41:02 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1467650462.88.0.258819670884.issue27186@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Maybe merge Include/osmodule.h and Modules/posixmodule.h? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 12:43:21 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 04 Jul 2016 16:43:21 +0000 Subject: [issue27448] Race condition in subprocess.Popen which causes a huge memory leak In-Reply-To: <1467636752.08.0.502936379731.issue27448@psf.upfronthosting.co.za> Message-ID: <1467650601.93.0.247665729412.issue27448@psf.upfronthosting.co.za> R. David Murray added the comment: I presume we don't re-enable gc in the child because if there's an exception it is exiting anyway. FYI subprocess32, which fixes some other race conditions, shouldn't have this problem, since it is a backport of subprocess from python3, which no longer manipulates the GC. Unlike the other race that subprocess32 fixes, this one could be fixed in python2, though, if you want to propose a patch. ---------- nosy: +gps, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 12:48:49 2016 From: report at bugs.python.org (Jakub Wilk) Date: Mon, 04 Jul 2016 16:48:49 +0000 Subject: [issue18920] argparse version action should print to stdout, not stderr In-Reply-To: <1378297847.46.0.268237187871.issue18920@psf.upfronthosting.co.za> Message-ID: <1467650929.8.0.719172974683.issue18920@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk title: argparse module version action -> argparse version action should print to stdout, not stderr _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 12:50:47 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 Jul 2016 16:50:47 +0000 Subject: [issue26027] Support Path objects in the posix module In-Reply-To: <1452114329.99.0.617690911804.issue26027@psf.upfronthosting.co.za> Message-ID: <1467651047.25.0.999291514876.issue26027@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: At first glance issue27186-os_path_t.patch looks good. But with the patch applied the error message in case of incorrect argument type is always "expected str, bytes or os.PathLike object, not ...". Currently it is more detailed and specific: contains the function and the argument names, and is aware that some functions accept an integer or None. I think the best way is to inline the code of PyOS_FSPath in path_converter. Also we first resolve issue26800. ---------- dependencies: +Don't accept bytearray as filenames part 2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 12:55:21 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 04 Jul 2016 16:55:21 +0000 Subject: [issue27422] Deadlock when mixing threading and multiprocessing In-Reply-To: <1467303803.25.0.914359339926.issue27422@psf.upfronthosting.co.za> Message-ID: <1467651321.06.0.717868727807.issue27422@psf.upfronthosting.co.za> R. David Murray added the comment: To clarify the GIL issue (for davin, I guess? :): if the library you are using to interface with the FORTRAN code drops the GIL before calling the FORTRAN, then you *can* take advantage of multiple cores. It is only the python code (and some of the code interacting with the python objects) that is limited to executing on one core at a time. (As far as I know it isn't restricted to be the *same* core unless you set CPU affinity somehow, and I have no idea if it improves performance to use CPU affinity or not). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 13:12:00 2016 From: report at bugs.python.org (towb) Date: Mon, 04 Jul 2016 17:12:00 +0000 Subject: [issue27447] python -m doctest script_file_with_no_py_extension produces confusing NameErrors In-Reply-To: <1467626072.62.0.919470824468.issue27447@psf.upfronthosting.co.za> Message-ID: <1467652320.99.0.903467572117.issue27447@psf.upfronthosting.co.za> towb added the comment: Improving the documentation would also be nice, and easier. -m is mentioned in two places, first only as a shortcut for testmod, later with an explanation on name extensions and testfile. At least I didn't get that far. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 13:27:39 2016 From: report at bugs.python.org (Brett Cannon) Date: Mon, 04 Jul 2016 17:27:39 +0000 Subject: [issue27186] add os.fspath() In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io> Message-ID: <1467653259.46.0.437684726648.issue27186@psf.upfronthosting.co.za> Brett Cannon added the comment: I'm fine with merging the two files if you want to do it. Build rules will also need updating if they do get merged. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 13:28:30 2016 From: report at bugs.python.org (Brett Cannon) Date: Mon, 04 Jul 2016 17:28:30 +0000 Subject: [issue26027] Support Path objects in the posix module In-Reply-To: <1452114329.99.0.617690911804.issue26027@psf.upfronthosting.co.za> Message-ID: <1467653309.99.0.767310306486.issue26027@psf.upfronthosting.co.za> Brett Cannon added the comment: I have no issues inlining -- with a comment about the inlining -- if it buys us better error messages in this critical case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 13:44:22 2016 From: report at bugs.python.org (ppperry) Date: Mon, 04 Jul 2016 17:44:22 +0000 Subject: [issue27448] Race condition in subprocess.Popen which causes a huge memory leak In-Reply-To: <1467636752.08.0.502936379731.issue27448@psf.upfronthosting.co.za> Message-ID: <1467654262.64.0.823342405904.issue27448@psf.upfronthosting.co.za> ppperry added the comment: What are you doing that creates so many circular references that the not collecting them causes a massive memory leak? Or are you using an alternative implementation of Python? In addition, your monkeypatching is incorrect. `subprocess.gc` is the same object as the module you get by typing `import gc`, sou you are completely breaking the `gc.isenabled` functionality. ---------- nosy: +ppperry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 15:29:36 2016 From: report at bugs.python.org (Davin Potts) Date: Mon, 04 Jul 2016 19:29:36 +0000 Subject: [issue27422] Deadlock when mixing threading and multiprocessing In-Reply-To: <1467303803.25.0.914359339926.issue27422@psf.upfronthosting.co.za> Message-ID: <1467660576.43.0.391581659485.issue27422@psf.upfronthosting.co.za> Davin Potts added the comment: @r.david.murray: Oh man, I was not going to go as far as advocate dropping the GIL. :) At least not in situations like this where the exploitable parallelism is meant to be at the Python level and not inside the Fortran code (or that was my understanding of the setup). Martin had already mentioned the motivation to fork to avoid side effects possibly arising somewhere in that code. In practice, after dropping the GIL the threads will likely use multiple of the cores -- though that's up to the OS kernel scheduler, that's what I've observed happening after temporarily dropping the GIL on both Windows and Linux systems. As to the benefit of CPU affinity, it depends -- it depends upon what my code was and what the OS and other system processes were busily doing at the time my code ran -- but I've never seen it hurt performance (even if the help was diminishingly small at times). For certain situations, it has been worth doing. Correction: I have seen cpu affinity hurt performance when I make a bone-headed mistake and constrain too many things onto too few cores. But that's a PEBCAK root cause. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 15:32:46 2016 From: report at bugs.python.org (Davin Potts) Date: Mon, 04 Jul 2016 19:32:46 +0000 Subject: [issue27422] Deadlock when mixing threading and multiprocessing In-Reply-To: <1467303803.25.0.914359339926.issue27422@psf.upfronthosting.co.za> Message-ID: <1467660766.91.0.337375264913.issue27422@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 15:43:23 2016 From: report at bugs.python.org (Andrew) Date: Mon, 04 Jul 2016 19:43:23 +0000 Subject: [issue27448] Race condition in subprocess.Popen which causes a huge memory leak In-Reply-To: <1467636752.08.0.502936379731.issue27448@psf.upfronthosting.co.za> Message-ID: <1467661403.98.0.593452005362.issue27448@psf.upfronthosting.co.za> Andrew added the comment: pppery, I don't think I am breaking gc functionality with my code. The code line I gave just meant to give the basic idea of what was helping to workaround this. If you are actually interested in the code I use, it is below: def fix_subprocess_racecondition(): """ !!! PLEASE NOTE THIS SHOULD BE CALLED BEFORE ANY OTHER INITIALIZATION was done to avoid already created links to subprocess or subprocess.gc or gc """ # monkey patching subprocess import subprocess subprocess.gc.isenabled = lambda: True # re-importing gc to have correct isenabled for non-subprocess contexts import sys del sys.modules['gc'] import gc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 15:50:22 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 Jul 2016 19:50:22 +0000 Subject: [issue27419] Bugs in PyImport_ImportModuleLevelObject In-Reply-To: <1467275301.6.0.860119433525.issue27419@psf.upfronthosting.co.za> Message-ID: <1467661822.59.0.433447161146.issue27419@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a reproducer for the second bug. In Python 2.7 and Python 3.2 all works. In Python 3.3+: $ ./python import_bug_2.py Traceback (most recent call last): File "import_bug_2.py", line 6, in import os.path File "import_bug_2.py", line 4, in __import__ raise AssertionError AssertionError ---------- Added file: http://bugs.python.org/file43621/import_bug_2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 16:01:33 2016 From: report at bugs.python.org (Josh Triplett) Date: Mon, 04 Jul 2016 20:01:33 +0000 Subject: [issue27450] bz2: BZ2File should expose compression level as an attribute Message-ID: <1467662493.73.0.0646490356421.issue27450@psf.upfronthosting.co.za> New submission from Josh Triplett: (This exists in both Python 3 and Python 2.) When opening an existing .bz2 file with BZ2File, I'd like to have access to the compression level, so that I don't have to manually parse the file's header to get it. BZ2File could provide the compression level as an attribute on itself. ---------- components: Library (Lib) messages: 269806 nosy: joshtriplett priority: normal severity: normal status: open title: bz2: BZ2File should expose compression level as an attribute type: enhancement versions: Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 16:02:10 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 04 Jul 2016 20:02:10 +0000 Subject: [issue27442] expose the Android API level in sysconfig.get_config_vars() In-Reply-To: <1467471175.35.0.000904857777026.issue27442@psf.upfronthosting.co.za> Message-ID: <1467662530.7.0.248799336716.issue27442@psf.upfronthosting.co.za> Xavier de Gaye added the comment: A patch to expose the Android API level in sysconfig.get_config_vars(). ---------- components: +Library (Lib) -Interpreter Core title: expose Android API level in sys.implementation -> expose the Android API level in sysconfig.get_config_vars() Added file: http://bugs.python.org/file43622/android_api_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 16:04:18 2016 From: report at bugs.python.org (Josh Triplett) Date: Mon, 04 Jul 2016 20:04:18 +0000 Subject: [issue27451] gzip.py: Please save more of the gzip header for later examination Message-ID: <1467662658.73.0.679022780479.issue27451@psf.upfronthosting.co.za> New submission from Josh Triplett: GzipFile currently reads and discards various fields from the gzip header, such as the original filename and timestamp. Please consider reading all the fields of the gzip header into fields of the GzipFile instance, so that users of GzipFile can access these fields. ---------- components: Library (Lib) messages: 269808 nosy: joshtriplett priority: normal severity: normal status: open title: gzip.py: Please save more of the gzip header for later examination type: enhancement versions: Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 16:09:51 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 04 Jul 2016 20:09:51 +0000 Subject: [issue27452] IDLE: Cleanup config code Message-ID: <1467662991.07.0.187758431637.issue27452@psf.upfronthosting.co.za> New submission from Terry J. Reedy: The config module code can be improved even without changing behavior. While working on #27380, I noticed these two: IdleUserConfParser.RemoveFile is a simple one-liner called once. Put it inline. IdleConf.CreateConfigHandlers: A) As near as I can tell, __file__ is now always the absolute path of the file regardless if executed directly or imported. B) Creating two dicts of file names that are immediately used and deleted is useless and to me makes the code less readable. I intend these changes only for 3.6 and will not apply until after the new unix keys patch. Serhiy, have you noticed any similar cleanups that would be appropriate to add? ---------- assignee: terry.reedy files: config-clean.diff keywords: patch messages: 269809 nosy: serhiy.storchaka, terry.reedy priority: normal severity: normal stage: test needed status: open title: IDLE: Cleanup config code type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43623/config-clean.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 16:48:32 2016 From: report at bugs.python.org (Marcos Dione) Date: Mon, 04 Jul 2016 20:48:32 +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: <1467665312.39.0.535044575116.issue26826@psf.upfronthosting.co.za> Marcos Dione added the comment: * Updated the patch to latest version. * PEP-8'ed the tests. * Dropped flags from the API but not the internal function. ---------- Added file: http://bugs.python.org/file43624/copy_file_range.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 17:50:28 2016 From: report at bugs.python.org (ppperry) Date: Mon, 04 Jul 2016 21:50:28 +0000 Subject: [issue27451] gzip.py: Please save more of the gzip header for later examination In-Reply-To: <1467662658.73.0.679022780479.issue27451@psf.upfronthosting.co.za> Message-ID: <1467669028.67.0.0336703693386.issue27451@psf.upfronthosting.co.za> Changes by ppperry : ---------- versions: -Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 18:06:13 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 04 Jul 2016 22:06:13 +0000 Subject: [issue27437] IDLE tests must be able to set user configuration values. In-Reply-To: <1467400772.1.0.605855673918.issue27437@psf.upfronthosting.co.za> Message-ID: <1467669973.31.0.249891539335.issue27437@psf.upfronthosting.co.za> Terry J. Reedy added the comment: After moving the config cleanup part of the patch to #27452 and doing further experiments with methods inherited from configparser.ConfigParser, in all 3 versions, I decided that nothing new needs to be added to config.py. I will instead use the prototype test_config.py files developed for this issue for #27173. ---------- resolution: -> rejected stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 18:13:58 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 04 Jul 2016 22:13:58 +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: <1467670438.59.0.923609565703.issue27410@psf.upfronthosting.co.za> Steve Dower added the comment: It's not even that the risk is low, it's that we can't actually fix it. There are zero explicit DLL loads in the installer (either the part we own or the third-party core) that are insecure, and the four DLLs referenced by the third-party core executable that are not listed as KnownDLLs are Windows system DLLs that could be used by any downloaded executable - in particular installers, which are most likely to show up in a downloads folder. If a user is not knowledgeable enough to avoid "accidentally" downloading a file from a website, is not perceptive enough to notice an unexpected download, and/or is not paranoid enough to run installers from their own directory, they are going to be affected by this design decision in the operating system through some other installer. We are already more secure than most, since we don't elevate by default. The 7-zip installer (which just happened to be first in my downloads folder) is more vulnerable to this, in that it will load version.dll from the downloads folder and execute code as Administrator. We will only run it as the current user, which is certainly a vector to start executing code, but it's not one that we can possibly close off. If someone wants to report this flaw to the Microsoft security team, they can consider changing Windows to add these DLLs to the KnownDLLs list and ensure that the system's version is always loaded. The most we can do is publish an article for paranoid people to protect themselves (which I am not volunteering to write). ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 18:24:20 2016 From: report at bugs.python.org (Brett Cannon) Date: Mon, 04 Jul 2016 22:24:20 +0000 Subject: [issue27419] Bugs in PyImport_ImportModuleLevelObject In-Reply-To: <1467275301.6.0.860119433525.issue27419@psf.upfronthosting.co.za> Message-ID: <1467671060.01.0.156320606052.issue27419@psf.upfronthosting.co.za> Brett Cannon added the comment: The semantics for looking up __import__ is to only grab it from builtins and to ignore globals() and locals() (see issue #25500), so any fix/change should follow those semantics. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 4 19:32:45 2016 From: report at bugs.python.org (Greg Stark) Date: Mon, 04 Jul 2016 23:32:45 +0000 Subject: [issue27444] Python doesn't build due to test_float.py broken on non-IEEE machines In-Reply-To: <1467493851.35.0.417072100147.issue27444@psf.upfronthosting.co.za> Message-ID: <1467675165.27.0.13088255106.issue27444@psf.upfronthosting.co.za> Greg Stark added the comment: Well I was able to minimize the actual cause: $ /usr/pkg/bin/python -c 1e300*1e300 [1] Floating point exception /usr/pkg/bin/python -c 1e300*1e300 I noticed that the constant folding arithmetic is protected by "PyFPE_START_PROTECT" macros so I wonder... should I be configuring with --with-fpectl? (Or should it be on unconditionally if it's required to function properly on a given architecture?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 00:04:18 2016 From: report at bugs.python.org (raylu) Date: Tue, 05 Jul 2016 04:04:18 +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: <1467691458.9.0.353520998009.issue26292@psf.upfronthosting.co.za> Changes by raylu : ---------- nosy: +raylu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 02:09:30 2016 From: report at bugs.python.org (Emin Ghuliev) Date: Tue, 05 Jul 2016 06:09:30 +0000 Subject: [issue27254] UAF in Tkinter module In-Reply-To: <1465324141.01.0.361051063774.issue27254@psf.upfronthosting.co.za> Message-ID: <1467698970.28.0.923056895599.issue27254@psf.upfronthosting.co.za> Changes by Emin Ghuliev : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 02:09:47 2016 From: report at bugs.python.org (Emin Ghuliev) Date: Tue, 05 Jul 2016 06:09:47 +0000 Subject: [issue27254] UAF in Tkinter module In-Reply-To: <1465324141.01.0.361051063774.issue27254@psf.upfronthosting.co.za> Message-ID: <1467698987.3.0.141099862048.issue27254@psf.upfronthosting.co.za> Changes by Emin Ghuliev : ---------- resolution: -> third party _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 04:01:28 2016 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 05 Jul 2016 08:01:28 +0000 Subject: [issue27444] Python doesn't build due to test_float.py broken on non-IEEE machines In-Reply-To: <1467493851.35.0.417072100147.issue27444@psf.upfronthosting.co.za> Message-ID: <1467705688.17.0.598486830658.issue27444@psf.upfronthosting.co.za> Mark Dickinson added the comment: [David] > maybe Mark will be interested, but he probably doesn't have time either. Also, he's been known to say he'd like to drop support for non-IEEE architectures ;) Exactly correct on all counts. :-) I'm *very* interested: I've been looking for a non-IEEE machine to play with Python on for years. But time is (as ever) in short supply. Realistically, maintaining support for non-IEEE 754 platforms looks like something with an enormously high cost/benefit ratio; maintaining just on machines with (some approximation of) IEEE 754 is already enough work. Greg: you say "there are other non-ieee platforms out there". Can you point me to any current hardware using non-IEEE 754 floating-point formats that one might want to run Python on? I know there are examples where not all of the IEEE 754 standard is supported, but the interchange format used is still IEEE 754 binary64 / binary32 / whatever, but that's not what I'm looking for; I'm looking for cases where the underlying format is different. The only example I'm aware of is the IBM System z, with its hexadecimal floating-point format, but those machines support IEEE 754 too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 07:18:43 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Tue, 05 Jul 2016 11:18:43 +0000 Subject: [issue27453] Fix cross-compilation with Android NDK and Clang Message-ID: <1467717523.35.0.850577639812.issue27453@psf.upfronthosting.co.za> New submission from Chi Hsuan Yen: Motivation: Android NDK is deprecating GCC and moving ot Clang/LLVM. From [1]: We strongly recommend switching to Clang. GCC in the NDK is now deprecated in favor of Clang. This patch fixes the only one problem when migrating GCC to Clang. In my build script, $CPP is set to "${ANDROID_NDK}/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -E" and $CPPFLAGS is set to "-target armv7-none-linux-androideabi -gcc-toolchain ${ANDROID_NDK}/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64 --sysroot ${ANDROID_NDK}/platforms/android-21/arch-arm/usr -I${PREFIX}/include -DANDROID". I'm not sure whether it's the correct usage of clang, but at least it works. With such a configuration, most Python parts builds well. Just something wrong - extensions as built as xyz.cpython-36m-x86_64-linux-gnu.so. My patch just fixes $(PLATFORM_TRIPLET) detection. [1] https://developer.android.com/ndk/downloads/revision_history.html ---------- components: Cross-Build files: ndk-clang-preprocessor.patch keywords: patch messages: 269816 nosy: Alex.Willmer, Chi Hsuan Yen, xdegaye priority: normal severity: normal status: open title: Fix cross-compilation with Android NDK and Clang type: compile error versions: Python 3.6 Added file: http://bugs.python.org/file43625/ndk-clang-preprocessor.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 07:25:28 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 05 Jul 2016 11:25:28 +0000 Subject: [issue27422] Deadlock when mixing threading and multiprocessing In-Reply-To: <1467303803.25.0.914359339926.issue27422@psf.upfronthosting.co.za> Message-ID: <1467717928.95.0.906296650536.issue27422@psf.upfronthosting.co.za> R. David Murray added the comment: Heh, yeah. What I was really trying to do by that comment was clarify for any *other* readers that stumble on this issue later it is just the python code that *has* to be constrained by the GIL. I have no idea how much of the scipy stack drops the gil at strategic spots. I do seem to remember that the the Jupyter uses multiple processes for its parallelism, though. Anyway, this is pretty off topic now :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 07:38:43 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 05 Jul 2016 11:38:43 +0000 Subject: [issue27450] bz2: BZ2File should expose compression level as an attribute In-Reply-To: <1467662493.73.0.0646490356421.issue27450@psf.upfronthosting.co.za> Message-ID: <1467718723.56.0.183484037723.issue27450@psf.upfronthosting.co.za> R. David Murray added the comment: New features can only be added in a new feature release, which means 3.6 at the moment (the window for that is shrinking fast, though, we hit beta in September). ---------- nosy: +r.david.murray stage: -> needs patch versions: -Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 09:01:36 2016 From: report at bugs.python.org (INADA Naoki) Date: Tue, 05 Jul 2016 13:01:36 +0000 Subject: [issue27454] PyUnicode_InternInPlace can use PyDict_SetDefault Message-ID: <1467723696.2.0.276855964684.issue27454@psf.upfronthosting.co.za> New submission from INADA Naoki: PyDict_SetDefault() was added Python 3.4 Currently, PyUnicode_InternInPlace() uses PyDict_GetItem, and PyDict_SetItem if no item found. It can be replaced PyDict_SetDefault() easily. ---------- components: Interpreter Core files: intern-setdefault.patch keywords: patch messages: 269819 nosy: naoki priority: normal severity: normal status: open title: PyUnicode_InternInPlace can use PyDict_SetDefault type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43626/intern-setdefault.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 09:20:52 2016 From: report at bugs.python.org (John Hagen) Date: Tue, 05 Jul 2016 13:20:52 +0000 Subject: [issue27455] Fix tkinter examples to be PEP8 compliant Message-ID: <1467724852.16.0.852334218439.issue27455@psf.upfronthosting.co.za> New submission from John Hagen: Patch fixes tkinter examples to be PEP8 compliant. ---------- assignee: docs at python components: Documentation files: 0001-Fix-tkinter-docs-PEP8.patch keywords: patch messages: 269820 nosy: John Hagen, docs at python priority: normal severity: normal status: open title: Fix tkinter examples to be PEP8 compliant versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43627/0001-Fix-tkinter-docs-PEP8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 09:24:41 2016 From: report at bugs.python.org (SilentGhost) Date: Tue, 05 Jul 2016 13:24:41 +0000 Subject: [issue27455] Fix tkinter examples to be PEP8 compliant In-Reply-To: <1467724852.16.0.852334218439.issue27455@psf.upfronthosting.co.za> Message-ID: <1467725081.71.0.0148294985055.issue27455@psf.upfronthosting.co.za> SilentGhost added the comment: This patch is going to be rejected, camelCase is standard convention in tkinter and logging modules and that's why it is used in documentation as well. ---------- nosy: +SilentGhost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 09:30:40 2016 From: report at bugs.python.org (SilentGhost) Date: Tue, 05 Jul 2016 13:30:40 +0000 Subject: [issue27441] redundant assignments to ob_size of new ints that _PyLong_New returned In-Reply-To: <1467470337.8.0.776341442151.issue27441@psf.upfronthosting.co.za> Message-ID: <1467725440.9.0.811773175798.issue27441@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +haypo, serhiy.storchaka stage: -> commit review versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 09:41:21 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 05 Jul 2016 13:41:21 +0000 Subject: [issue27455] Fix tkinter examples to be PEP8 compliant In-Reply-To: <1467724852.16.0.852334218439.issue27455@psf.upfronthosting.co.za> Message-ID: <1467726081.76.0.931648239111.issue27455@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch. If you want to improve the examples in tkinter documentation, I'd suggest to update Class.__init__(self, ...) to super().__init__(...). There is no old-style classes in Python 3 anymore so those examples could be updated safely. Also, please read https://docs.python.org/devguide/patch.html. Sending a patch from a Git checkout will only make the review process harder (and I will personally ignore them in the future). ---------- nosy: +berker.peksag, terry.reedy stage: -> patch review type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 10:01:30 2016 From: report at bugs.python.org (Brian Curtin) Date: Tue, 05 Jul 2016 14:01:30 +0000 Subject: [issue17128] OS X system openssl deprecated - installer should build local libssl In-Reply-To: <1360002680.77.0.851671416179.issue17128@psf.upfronthosting.co.za> Message-ID: <1467727290.84.0.740579634065.issue17128@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- nosy: -brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 10:04:42 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 05 Jul 2016 14:04:42 +0000 Subject: [issue27454] PyUnicode_InternInPlace can use PyDict_SetDefault In-Reply-To: <1467723696.2.0.276855964684.issue27454@psf.upfronthosting.co.za> Message-ID: <1467727482.55.0.178192225672.issue27454@psf.upfronthosting.co.za> Berker Peksag added the comment: I think you also need to update the comment below: /* It might be that the GetItem call fails even though the key is present in the dictionary, namely when this happens during a stack overflow. */ ---------- nosy: +berker.peksag, haypo, serhiy.storchaka stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 11:00:49 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 05 Jul 2016 15:00:49 +0000 Subject: [issue27453] Fix cross-compilation with Android NDK and Clang In-Reply-To: <1467717523.35.0.850577639812.issue27453@psf.upfronthosting.co.za> Message-ID: <1467730849.29.0.78429659254.issue27453@psf.upfronthosting.co.za> Xavier de Gaye added the comment: With configure run as './configure CC="$(CC)" ...' and when CC is set to: CC = clang --sysroot=$(SYSROOT) -target $(TARGET) -gcc-toolchain $(GCC_TOOLCHAIN) and building for armv7 on android-21, then configure runs $CPP as: checking for CPP... clang --sysroot=/opt/android-ndk/platforms/android-21/arch-arm -target armv7-none-linux-androideabi -gcc-toolchain /opt/android-ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64 -E as can be seen by inserting in configure.ac: AC_MSG_CHECKING([for CPP]) AC_MSG_RESULT([$CPP]) and the shared libraries are named 'module_name.cpython-36m-arm-linux-gnueabi.so'. OTOH, the 'configure' script runs its own preprocessings with the following idiom: if (eval "$ac_cpp conftest.$ac_ext") 2>&5 | $EGREP "memchr" >/dev/null 2>&1; then : where 'ac_cpp' is set to ac_cpp='$CPP $CPPFLAGS'. So the proposed patch LGTM. PLATFORM_TRIPLETs are specific to multiarch systems such as debian and should not be relied upon on Android, but they should not be entirely wrong of course. ---------- nosy: +doko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 11:13:30 2016 From: report at bugs.python.org (Facundo Batista) Date: Tue, 05 Jul 2016 15:13:30 +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: <1467731610.24.0.817793655374.issue26826@psf.upfronthosting.co.za> Facundo Batista added the comment: It looked ok to me (I couldn't try it, as I still have 4.4 kernel). One thing to the be done is to improve the test coverage (trying the usage of all the parameters, at least). ---------- nosy: +facundobatista _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 11:27:48 2016 From: report at bugs.python.org (Jim Fulton) Date: Tue, 05 Jul 2016 15:27:48 +0000 Subject: [issue27456] TCP_NODELAY Message-ID: <1467732468.65.0.201519937735.issue27456@psf.upfronthosting.co.za> New submission from Jim Fulton: tl;dr TCP_NODELAY should be set by default and/or there should be a proper way to set it. I've ported ZEO, ZODB's client-server networking layer to asyncio. Things were going pretty well. I've been developing on a Mac. Yesterday, I ran some performance measurements on Linux and found some tests ran 30x slower. After some digging, I came across this: https://github.com/python/asyncio/issues/311 Then led me to try setting TCP_NODELAY, which provided Linux performance comparable to Mac OS performance. Issue 311 suggested that this was a kernal-version issue. I think this is a failure to set, or at least provide a way to set a "don't be stupid" option. I originally tried this on Ubuntu 14.04, with kernal 3.13.0-74-generic. I then tried Ubuntu 16.04, in a docker image, with kernal 4.4.12-boot2docker. For both of these, performance for the write tests were 30x slower unless I set TCP_NODELAY. Finally, I tried an Amazon standard AMI, which runs some version of RedHat, with kernal 4.4.11-23.53.amzn1.x86_64. On that system, performance of the tests was similar to Mac OS X without setting TCP_NODELAY. Note that the non-slow kernal version was lower than the slow (Ubuntu) one. I don't think this is mearly a kernal version issue, nor do I think this should have been dismissed as one. I couldn't find a way to set TCP_NODELAY cleanly. Did I miss something? https://github.com/python/asyncio/issues/286 suggests there isn't one. I ended up having to set the option on _sock transport attributes, which is dirty and, I assume, won't work with uvloop. (BTW, uvloop was only ~15x slower on linux systems with this problem.) I think TCP_NODELAY should be set by default. Perhaps it shouldn't be set on mobile, by everywhere else, I think it's a "don't be stupid" option. I also think there should be a way to set it cleanly. IMO, this is extremely important. Linux is a wildly important platform for networking applications and Python, and, for better or worse, Ubuntu is a very commonly used distribution. Having asyncio, perform so poorly on these platforms is a big deal. ---------- messages: 269826 nosy: j1m priority: normal severity: normal status: open title: TCP_NODELAY _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 11:31:50 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Tue, 05 Jul 2016 15:31:50 +0000 Subject: [issue27453] Fix cross-compilation with Android NDK and Clang In-Reply-To: <1467717523.35.0.850577639812.issue27453@psf.upfronthosting.co.za> Message-ID: <1467732710.28.0.0579672251564.issue27453@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Several days ago I have once tried to set CC="clang -target $(TARGET) -gcc-toolchain $(GCC_TOOLCHAIN)", and it failed to build some dependency of Python (I can't remember). Just tried and everything is OK. Dunno what's changed. Anyway both approaches (-target in $CC/$CXX/$CPP and -target in $CFLAGS/$CXXFLAGS/$CPPFLAGS) should be supported. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 11:34:04 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 05 Jul 2016 15:34:04 +0000 Subject: [issue27442] expose the Android API level in sysconfig.get_config_vars() In-Reply-To: <1467471175.35.0.000904857777026.issue27442@psf.upfronthosting.co.za> Message-ID: <1467732844.45.0.501087372955.issue27442@psf.upfronthosting.co.za> Xavier de Gaye added the comment: According to issue 27453, do this minor change in the patch: s/$CC -E/$CPP $CPPFLAGS. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 11:49:47 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Tue, 05 Jul 2016 15:49:47 +0000 Subject: [issue27442] expose the Android API level in sysconfig.get_config_vars() In-Reply-To: <1467471175.35.0.000904857777026.issue27442@psf.upfronthosting.co.za> Message-ID: <1467733787.25.0.447040309013.issue27442@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Here's an issue - there's already a macro called ANDROID_API defined in libcutils [1] If someone is going to integrate Python into AOSP, redefining macros may cause a problem. [1] https://android.googlesource.com/platform/system/core/+/master/include/cutils/compiler.h#42 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 11:50:26 2016 From: report at bugs.python.org (klo uo) Date: Tue, 05 Jul 2016 15:50:26 +0000 Subject: [issue27457] shlex.quote incorrectly quotes ampersants, pipes Message-ID: <1467733826.6.0.356479348318.issue27457@psf.upfronthosting.co.za> New submission from klo uo: Example code: ======================================== Python 3.4.3 (default, Oct 14 2015, 20:28:29) [GCC 4.8.4] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import shlex >>> cmd = ["pwd", "&&", "ls"] >>> ' '.join(shlex.quote(arg) for arg in cmd) "pwd '&&' ls" >>> ======================================== Double ampersants is quoted, and if this command string is passed to Popen or pasted in shell it would fail. OTOH, Windows so-so compatible list2cmdline: ======================================== Python 3.5.1 (v3.5.1:37a07cee5969, Dec 6 2015, 01:54:25) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import subprocess >>> cmd = ["cd", "&&", "dir"] >>> subprocess.list2cmdline(cmd) 'cd && dir' >>> ======================================== behaves correctly. ---------- messages: 269830 nosy: klo.uo priority: normal severity: normal status: open title: shlex.quote incorrectly quotes ampersants, pipes type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 12:00:20 2016 From: report at bugs.python.org (Jim Fulton) Date: Tue, 05 Jul 2016 16:00:20 +0000 Subject: [issue27456] TCP_NODELAY In-Reply-To: <1467732468.65.0.201519937735.issue27456@psf.upfronthosting.co.za> Message-ID: <1467734420.92.0.823203254062.issue27456@psf.upfronthosting.co.za> Jim Fulton added the comment: Gaaa, forgot to set meta data. ---------- components: +asyncio nosy: +gvanrossum, haypo, yselivanov type: -> performance versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 12:03:05 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 05 Jul 2016 16:03:05 +0000 Subject: [issue27442] expose the Android API level in sysconfig.get_config_vars() In-Reply-To: <1467471175.35.0.000904857777026.issue27442@psf.upfronthosting.co.za> Message-ID: <1467734585.84.0.334170203087.issue27442@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Integrating Python into AOSP does not make sense. The patch can be changed with s/ANDROID_API/ANDROID_API_LEVEL. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 12:08:19 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 05 Jul 2016 16:08:19 +0000 Subject: [issue27457] shlex.quote incorrectly quotes ampersants, pipes In-Reply-To: <1467733826.6.0.356479348318.issue27457@psf.upfronthosting.co.za> Message-ID: <1467734899.71.0.333016303296.issue27457@psf.upfronthosting.co.za> Xiang Zhang added the comment: Doesn't this the expected behaviour of shlex.quote, return a shell-escaped version of the string s? If && is not quoted, how about "pwd && rm -rf ~"? I think in your case there is no need to use shlex.quote. ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 12:11:38 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Tue, 05 Jul 2016 16:11:38 +0000 Subject: [issue27442] expose the Android API level in sysconfig.get_config_vars() In-Reply-To: <1467471175.35.0.000904857777026.issue27442@psf.upfronthosting.co.za> Message-ID: <1467735098.84.0.153640386317.issue27442@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Yep adding Python to Android's build system is a rare case. Just to mention there's already an macro and avoiding possible redefined macros is always good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 12:14:27 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 05 Jul 2016 16:14:27 +0000 Subject: [issue27457] shlex.quote incorrectly quotes ampersants, pipes In-Reply-To: <1467733826.6.0.356479348318.issue27457@psf.upfronthosting.co.za> Message-ID: <1467735267.36.0.0785412141128.issue27457@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, the point of shlex.quote is to get something that is *not* special to the shell, and therefore safe to pass to the shell. If you *want* an & in your command, just pass it, don't quote it. quote is for *untrusted* data, like filenames received from a user. Or better, don't use shell=True all. (list2cmdline has a different purpose, unique to windows) ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 12:15:00 2016 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 05 Jul 2016 16:15:00 +0000 Subject: [issue27456] TCP_NODELAY In-Reply-To: <1467732468.65.0.201519937735.issue27456@psf.upfronthosting.co.za> Message-ID: <1467735300.8.0.167848789617.issue27456@psf.upfronthosting.co.za> Yury Selivanov added the comment: See also https://github.com/python/asyncio/issues/286 I also wanted to raise this question. I think transports should set NODELAY by default (as Golang, for instance). I've been hit by this thing a few times already -- performance of protocols over TCP is terrible because somebody forgot to set this flag. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 12:24:59 2016 From: report at bugs.python.org (Jim Fulton) Date: Tue, 05 Jul 2016 16:24:59 +0000 Subject: [issue27456] TCP_NODELAY In-Reply-To: <1467732468.65.0.201519937735.issue27456@psf.upfronthosting.co.za> Message-ID: <1467735899.59.0.889312349615.issue27456@psf.upfronthosting.co.za> Jim Fulton added the comment: I forgot to switch to the asyncio branch of ZEO when testing on the Amazon/RedHat linux. When I do, the tests run slow there too. Asyncio is dog slow on every linux I've tried. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 12:27:12 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 05 Jul 2016 16:27:12 +0000 Subject: [issue27456] TCP_NODELAY In-Reply-To: <1467735300.8.0.167848789617.issue27456@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Fine with me -- I have no idea what this flag does (nor the desire to learn :-). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 12:28:13 2016 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 05 Jul 2016 16:28:13 +0000 Subject: [issue27456] TCP_NODELAY In-Reply-To: <1467732468.65.0.201519937735.issue27456@psf.upfronthosting.co.za> Message-ID: <1467736093.66.0.508328114886.issue27456@psf.upfronthosting.co.za> Yury Selivanov added the comment: Jim, I can make a PR, unless you want to do that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 12:30:19 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 05 Jul 2016 16:30:19 +0000 Subject: [issue27456] TCP_NODELAY In-Reply-To: <1467732468.65.0.201519937735.issue27456@psf.upfronthosting.co.za> Message-ID: <1467736219.08.0.0382793128442.issue27456@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- nosy: -gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 12:30:43 2016 From: report at bugs.python.org (Jim Fulton) Date: Tue, 05 Jul 2016 16:30:43 +0000 Subject: [issue27456] TCP_NODELAY In-Reply-To: <1467732468.65.0.201519937735.issue27456@psf.upfronthosting.co.za> Message-ID: <1467736243.68.0.398220062734.issue27456@psf.upfronthosting.co.za> Jim Fulton added the comment: Yury, I'd be fine with you making a PR. :) Is there a similar update that can be made to uvloop? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 12:37:10 2016 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 05 Jul 2016 16:37:10 +0000 Subject: [issue27456] TCP_NODELAY In-Reply-To: <1467732468.65.0.201519937735.issue27456@psf.upfronthosting.co.za> Message-ID: <1467736630.21.0.470998279627.issue27456@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Is there a similar update that can be made to uvloop? Yes. Once it's committed to asyncio, I'll add it to uvloop immediately. That's one benefit of using uvloop -- it gets updates faster ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 12:38:37 2016 From: report at bugs.python.org (klo uo) Date: Tue, 05 Jul 2016 16:38:37 +0000 Subject: [issue27457] shlex.quote incorrectly quotes ampersants, pipes In-Reply-To: <1467733826.6.0.356479348318.issue27457@psf.upfronthosting.co.za> Message-ID: <1467736717.78.0.482064054183.issue27457@psf.upfronthosting.co.za> klo uo added the comment: So there is no reliable way for converting chained command line sequence to string on *nix, when I have to to use string as shell=True? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 12:59:14 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 05 Jul 2016 16:59:14 +0000 Subject: [issue27457] shlex.quote incorrectly quotes ampersants, pipes In-Reply-To: <1467733826.6.0.356479348318.issue27457@psf.upfronthosting.co.za> Message-ID: <1467737954.31.0.23071142835.issue27457@psf.upfronthosting.co.za> R. David Murray added the comment: If you use shell=True you can do almost anything you can do in the shell, but making it safe is up to you. We provide shlex.quote to help you with that, but only you can know what parts of the expression need quoting and what don't. It sounds like you might find the stdlib 'pipes' module interesting. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 13:41:39 2016 From: report at bugs.python.org (John Hagen) Date: Tue, 05 Jul 2016 17:41:39 +0000 Subject: [issue27455] Fix tkinter examples to be PEP8 compliant In-Reply-To: <1467724852.16.0.852334218439.issue27455@psf.upfronthosting.co.za> Message-ID: <1467740499.24.0.504347315517.issue27455@psf.upfronthosting.co.za> Changes by John Hagen : Removed file: http://bugs.python.org/file43627/0001-Fix-tkinter-docs-PEP8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 13:49:26 2016 From: report at bugs.python.org (John Hagen) Date: Tue, 05 Jul 2016 17:49:26 +0000 Subject: [issue27455] Fix tkinter examples to be PEP8 compliant In-Reply-To: <1467724852.16.0.852334218439.issue27455@psf.upfronthosting.co.za> Message-ID: <1467740966.31.0.0349409300104.issue27455@psf.upfronthosting.co.za> John Hagen added the comment: @Berker, sorry for the incorrect diff format, still new to CPython (and Mercurial) workflow. I've attached the diff in a new format. @SilentGhost I see what you mean that camelCase is used often in tkinter (though many of the examples use lower_camel_case, so it seems like at least it's not consistent currently). The minor issue I was trying to fix with this patch is that I was showing a programmer completely new to Python the tkinter example and when he pasted it into PyCharm it had some PEP8 warnings, so I was hoping to improve that experience slightly for others in the future. Some of the changes were newlines for PEP8, would those be accepted? I'm not strongly inclined either way, so if the core team thinks it should not be changed, I'm happy with that. ---------- Added file: http://bugs.python.org/file43628/0001-Fix-tkinter-docs-PEP8.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 15:46:19 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 05 Jul 2016 19:46:19 +0000 Subject: [issue27455] Fix tkinter examples to be PEP8 compliant In-Reply-To: <1467724852.16.0.852334218439.issue27455@psf.upfronthosting.co.za> Message-ID: <1467747979.28.0.491524531721.issue27455@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Except for replacing '' with ""*, I am strongly for this patch. To me, caMelcaSe is ugLy, and should not be encouraged. I disagree that camelCase is standard convention, at least not currently. Tkinter itself does not use it. It does not even use TitleCase much. As near as I could find, neither http://effbot.org/tkinterbook/tkinter-index.htm nor http://www.tkdocs.com/tutorial/index.html introduce camelCase identifiers. For instance, http://effbot.org/tkinterbook/tkinter-hello-again.htm, instead of hiThere and sayHi, has self.hi_there = Button(frame, text="Hello", command=self.say_hi) def say_hi(self): * PEP 8 says "In Python, single-quoted strings and double-quoted strings are the same. This PEP does not make a recommendation for this." My personal convention is 'word', which occurs a lot in tkinter code, and 'multi-word phrase or sentence", which is much rarer. Why the change in the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 15:46:37 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 05 Jul 2016 19:46:37 +0000 Subject: [issue27455] Fix tkinter examples to be PEP8 compliant In-Reply-To: <1467724852.16.0.852334218439.issue27455@psf.upfronthosting.co.za> Message-ID: <1467747997.68.0.889819900291.issue27455@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- components: +Tkinter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 15:56:20 2016 From: report at bugs.python.org (Eric Snow) Date: Tue, 05 Jul 2016 19:56:20 +0000 Subject: [issue24254] Make class definition namespace ordered by default In-Reply-To: <1432186488.39.0.20621749373.issue24254@psf.upfronthosting.co.za> Message-ID: <1467748580.63.0.308791213966.issue24254@psf.upfronthosting.co.za> Eric Snow added the comment: Here's an updated patch that matches the accepted PEP. Most notably I've added a tp_deforder slot. This was necessary because subclasses should not inherit their parent's __definition_order__ and the ability to delete cls.__definition_order__ makes this problematic. I didn't see a way to do that without adding a new type slot. ---------- Added file: http://bugs.python.org/file43629/deforder-with-tp-slot.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 16:02:38 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 05 Jul 2016 20:02:38 +0000 Subject: [issue27448] Race condition in subprocess.Popen which causes a huge memory leak In-Reply-To: <1467636752.08.0.502936379731.issue27448@psf.upfronthosting.co.za> Message-ID: <1467748958.59.0.793517370952.issue27448@psf.upfronthosting.co.za> Gregory P. Smith added the comment: FWIW at this point i'm not willing to "fix" issues in Python 2.7's subprocess module for POSIX platforms as subprocess32 is a superior drop in alternative without the issues. inspecting the 2.7 code, if you are seeing a memory leak and the statements that fail before the gc.enable call are more than "self._child_created = True" and "if self.pid == 0:", it must be the child process. there DOES appear to be a unlikely but potential bug in the 2.7 child process code: its "os._exit(255)" call should really be within a finally: so that any exception raised during the bare "except:" phase somehow still exits. that should be rare. the result if missing that would be a runaway forked child process that does indeed have gc disabled but is in the process of propagating an exception upwards (and is likely to hit others along the way in the other finally: clauses) so it is would die anyways unless the calling code catches and dismisses that (possible). so what I _imagine_ you _might_ be seeing somehow is the pre-exec forked child exception handling+reporting code failing and leading to a runaway child who's exception you caught and let keep running. if you have this situation, something else odd is going on (is the os.write() failing?). i've attached a _possible_ patch. but i'd rather not commit this without a test that reproduces the situation (that sounds difficult). I strongly recommend you just use subprocess32. ---------- keywords: +patch nosy: +gregory.p.smith Added file: http://bugs.python.org/file43630/issue27448-gps01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 16:08:07 2016 From: report at bugs.python.org (Bernard Spil) Date: Tue, 05 Jul 2016 20:08:07 +0000 Subject: [issue24557] Refactor LibreSSL / EGD detection In-Reply-To: <1435926751.49.0.18395819216.issue24557@psf.upfronthosting.co.za> Message-ID: <1467749287.54.0.755709535389.issue24557@psf.upfronthosting.co.za> Bernard Spil added the comment: It's been a year since this was created. Can we move this forward? For the OpenSSL 1.1 changes, see https://github.com/openssl/openssl/blob/master/Configure#L363 (egd is disabled in the default configuration) and https://github.com/openssl/openssl/blob/master/include/openssl/rand.h#L61 When OPENSSL_NO_EGD is defined, the EGD related methods are rempved. This is still causing build problems on some isntallations, seems there can be diffences in detection between configure and build phase. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205960# ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 16:10:11 2016 From: report at bugs.python.org (Ammar Askar) Date: Tue, 05 Jul 2016 20:10:11 +0000 Subject: [issue27458] Allow subtypes of unicode/str to hit the optimized unicode_concatenate block Message-ID: <1467749411.27.0.801295605617.issue27458@psf.upfronthosting.co.za> New submission from Ammar Askar: So currently as far as string concatenation goes. ceval has this nice little branch it can take if both operators are unicode types. However, since this check is an Exact check, it means that subtypes of unicode end up going through the slow code path through: PyNumber_Add -> PyUnicode_Concat. This patch aims to allow subtypes to take that optimized branch without breaking any existing behavior and without any more memory copy calls than necessary. The motivation for this change is that some templating engines (Mako/Jinja2/Cheetah) use stuff like MarkupSafe which is implemented with a unicode subtype called `Markup`. Concatenating these custom objects (pretty common for templating engines) is fairly slow. This change modifies and uses the existing cpython code to make it a fair bit faster. I think the only real "dangerous" change in here is in the cast_unicode_subtype_to_base function which uses a trick at the end to prevent deallocation of memory. I've made sure to keep it well commented but I'd appreciate any feedback on it. >From what I can tell from running the test suite, all tests pass and there don't seem to be any new reference leaks. ---------- components: Interpreter Core files: python.diff keywords: patch messages: 269849 nosy: ammar2, benjamin.peterson, ezio.melotti, haypo, lemburg, pitrou priority: normal severity: normal status: open title: Allow subtypes of unicode/str to hit the optimized unicode_concatenate block type: performance Added file: http://bugs.python.org/file43631/python.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 16:13:25 2016 From: report at bugs.python.org (John Hagen) Date: Tue, 05 Jul 2016 20:13:25 +0000 Subject: [issue27455] Fix tkinter examples to be PEP8 compliant In-Reply-To: <1467724852.16.0.852334218439.issue27455@psf.upfronthosting.co.za> Message-ID: <1467749605.67.0.517057241796.issue27455@psf.upfronthosting.co.za> John Hagen added the comment: @Terry The reason for changing the quotes was for consistency, since everywhere else on that page used double quotes. That being said, I don't have a strong preference and will happily revert it if that is the consensus. I'm +0 on the change. I personally use single quotes everywhere and use flake8-quotes to help with this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 16:25:57 2016 From: report at bugs.python.org (Bernard Spil) Date: Tue, 05 Jul 2016 20:25:57 +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: <1467750357.02.0.812405688864.issue26470@psf.upfronthosting.co.za> Bernard Spil added the comment: Can you please replace the HAVE_RAND_EGD bits with OPENSSL_NO_EGD as defined by both OpenSSL 1.1 and LibreSSL? EGD default disabled https://github.com/openssl/openssl/blob/master/Configure#L363 EGD methods not available https://github.com/openssl/openssl/blob/master/include/openssl/rand.h#L61 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 16:55:28 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 05 Jul 2016 20:55:28 +0000 Subject: [issue27452] IDLE: Cleanup config code In-Reply-To: <1467662991.07.0.187758431637.issue27452@psf.upfronthosting.co.za> Message-ID: <1467752128.84.0.130787593728.issue27452@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If config.py is just executed, __file__ can be a relative path. RemoveFile() looks as a part of public API. If you are sure that nobody needs to remove a config file, you can remove this method. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 17:05:31 2016 From: report at bugs.python.org (Brett Cannon) Date: Tue, 05 Jul 2016 21:05:31 +0000 Subject: [issue24557] Refactor LibreSSL / EGD detection In-Reply-To: <1435926751.49.0.18395819216.issue24557@psf.upfronthosting.co.za> Message-ID: <1467752731.08.0.303094670979.issue24557@psf.upfronthosting.co.za> Brett Cannon added the comment: You could try bringing this up on the security-sig to see if there is enough interest: https://mail.python.org/mailman/listinfo/security-sig ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 17:05:43 2016 From: report at bugs.python.org (Brett Cannon) Date: Tue, 05 Jul 2016 21:05:43 +0000 Subject: [issue24557] Refactor LibreSSL / EGD detection In-Reply-To: <1435926751.49.0.18395819216.issue24557@psf.upfronthosting.co.za> Message-ID: <1467752743.6.0.698152202202.issue24557@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: -brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 17:10:43 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 05 Jul 2016 21:10:43 +0000 Subject: [issue24557] Refactor LibreSSL / EGD detection In-Reply-To: <1435926751.49.0.18395819216.issue24557@psf.upfronthosting.co.za> Message-ID: <1467753043.72.0.458695319395.issue24557@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: -pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 17:16:40 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 05 Jul 2016 21:16:40 +0000 Subject: [issue27019] Reduce marshal stack depth for 2.7 on Windows debug build In-Reply-To: <1463244101.49.0.212240462675.issue27019@psf.upfronthosting.co.za> Message-ID: <1467753400.37.0.159144852906.issue27019@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 17:17:56 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 05 Jul 2016 21:17:56 +0000 Subject: [issue27019] Reduce marshal stack depth for 2.7 on Windows debug build In-Reply-To: <1463244101.49.0.212240462675.issue27019@psf.upfronthosting.co.za> Message-ID: <1467753476.35.0.43600255736.issue27019@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: -pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 17:44:31 2016 From: report at bugs.python.org (Ammar Askar) Date: Tue, 05 Jul 2016 21:44:31 +0000 Subject: [issue27458] Allow subtypes of unicode/str to hit the optimized unicode_concatenate block In-Reply-To: <1467749411.27.0.801295605617.issue27458@psf.upfronthosting.co.za> Message-ID: <1467755071.05.0.132196597925.issue27458@psf.upfronthosting.co.za> Ammar Askar added the comment: Side note, I was using this script which uses gdb to trace the execution path when it concatenates strings. ---------- Added file: http://bugs.python.org/file43632/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 18:07:47 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 05 Jul 2016 22:07:47 +0000 Subject: [issue27452] IDLE: Cleanup config code In-Reply-To: <1467662991.07.0.187758431637.issue27452@psf.upfronthosting.co.za> Message-ID: <1467756467.34.0.806864708733.issue27452@psf.upfronthosting.co.za> Terry J. Reedy added the comment: How can you get a relative path in 3.6 (or other current Python)? To test, I wrote file.py containing "print(__file__)". Executing from IDLE, with "python path/to/file.py", "path/to/file.py", "file.py" in the path/to directory, and "python -m to.file" (where path is on sys.path) all resulted in the absolute path. After adding "input()" to suspend execution, double clicking in Explorer gives the same result. Have I forgotten something? Do any of these result is something different on Linux? (or Mac?, for that matter) The only reason to execute rather than import config.py is to run the test at the end of the file after editing the file. In the absence of a thorough automated test, I occasionally do so. The approximately 500 lines of output is too much to read in detail (although one might check one specific part), but that it runs and produces the same number of lines before and after a change is reassuring. I should add a line counter and checksum to the dump function. As for removing RemoveFile: idlelib in 3.6 is, with a few exceptions, a private API. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 18:24:08 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 05 Jul 2016 22:24:08 +0000 Subject: [issue27452] IDLE: Cleanup config code In-Reply-To: <1467662991.07.0.187758431637.issue27452@psf.upfronthosting.co.za> Message-ID: <1467757448.99.0.90251718387.issue27452@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: $ ./python -m file /home/serhiy/py/cpython/file.py $ ./python file.py file.py ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 19:30:23 2016 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 05 Jul 2016 23:30:23 +0000 Subject: [issue27456] TCP_NODELAY In-Reply-To: <1467732468.65.0.201519937735.issue27456@psf.upfronthosting.co.za> Message-ID: <1467761423.4.0.0881370845813.issue27456@psf.upfronthosting.co.za> Yury Selivanov added the comment: PR: https://github.com/python/asyncio/pull/373 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 20:07:52 2016 From: report at bugs.python.org (Zhihan Chen) Date: Wed, 06 Jul 2016 00:07:52 +0000 Subject: [issue27459] unintended changes occurs when dealing with list of list Message-ID: <1467763672.45.0.0368079728325.issue27459@psf.upfronthosting.co.za> New submission from Zhihan Chen: When creating list of list with multiplication, changing one element of a list will result in changing all lists. ---------- components: Demos and Tools files: Screenshot from 2016-07-05 16-44-14.png messages: 269858 nosy: Zhihan Chen priority: normal severity: normal status: open title: unintended changes occurs when dealing with list of list type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file43633/Screenshot from 2016-07-05 16-44-14.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 20:08:18 2016 From: report at bugs.python.org (Zhihan Chen) Date: Wed, 06 Jul 2016 00:08:18 +0000 Subject: [issue27459] unintended changes occur when dealing with list of list In-Reply-To: <1467763672.45.0.0368079728325.issue27459@psf.upfronthosting.co.za> Message-ID: <1467763698.58.0.0177863832546.issue27459@psf.upfronthosting.co.za> Changes by Zhihan Chen : ---------- title: unintended changes occurs when dealing with list of list -> unintended changes occur when dealing with list of list _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 20:12:03 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 06 Jul 2016 00:12:03 +0000 Subject: [issue27452] IDLE: Cleanup config code In-Reply-To: <1467662991.07.0.187758431637.issue27452@psf.upfronthosting.co.za> Message-ID: <20160706001159.31109.67012.3C5329AC@psf.io> Roundup Robot added the comment: New changeset da83e115afea by Terry Jan Reedy in branch '2.7': Issue #27452: add line counter and crc to IDLE configHandler test dump. https://hg.python.org/cpython/rev/da83e115afea New changeset 127569004538 by Terry Jan Reedy in branch '3.5': Issue #27452: add line counter and crc to IDLE configHandler test dump. https://hg.python.org/cpython/rev/127569004538 New changeset c2e21bc83066 by Terry Jan Reedy in branch 'default': Issue #27452: add line counter and crc to IDLE config test dump. https://hg.python.org/cpython/rev/c2e21bc83066 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 20:14:53 2016 From: report at bugs.python.org (Eryk Sun) Date: Wed, 06 Jul 2016 00:14:53 +0000 Subject: [issue27459] unintended changes occur when dealing with list of list In-Reply-To: <1467763672.45.0.0368079728325.issue27459@psf.upfronthosting.co.za> Message-ID: <1467764093.39.0.358319090137.issue27459@psf.upfronthosting.co.za> Eryk Sun added the comment: This is by design. Please read the answer for the frequently asked question "How do I create a multidimensional list?": https://docs.python.org/3/faq/programming.html#how-do-i-create-a-multidimensional-list ---------- nosy: +eryksun resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 21:09:41 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Wed, 06 Jul 2016 01:09:41 +0000 Subject: [issue27459] unintended changes occur when dealing with list of list In-Reply-To: <1467763672.45.0.0368079728325.issue27459@psf.upfronthosting.co.za> Message-ID: <1467767381.34.0.178612780116.issue27459@psf.upfronthosting.co.za> Steven D'Aprano added the comment: Hi Zhihan Chen, I see this issue is closed, but for future reference please don't post screenshots to report issues unless they are really needed. For text output, just copy the text from your terminal and paste it into your bug report. Making a screen shot is more work for you, less useful for us, and makes it impossible for the blind and visually impaired to read it using a screen-reader. ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 21:34:53 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Wed, 06 Jul 2016 01:34:53 +0000 Subject: [issue27458] Allow subtypes of unicode/str to hit the optimized unicode_concatenate block In-Reply-To: <1467749411.27.0.801295605617.issue27458@psf.upfronthosting.co.za> Message-ID: <1467768893.88.0.743546082022.issue27458@psf.upfronthosting.co.za> Steven D'Aprano added the comment: I haven't studied your code in detail (I won't be qualified to judge it) but I notice this comment: /* Hit the faster unicode_concatenate method if and only if all the following conditions are true: 1. The left operand is a unicode type 2. The right operand is a unicode type 3. The left operand's __add__ method isn't overriden */ I don't think that's sufficient. You also need to check the right operand's __radd__ method if it is a subclass of the left: class A(str): pass class B(str): def __radd__(self, other): return B(other.uppper() + str(self)) a = A("hello ") b = B("world") assert a + b == "HELLO world" Also you have some tests, but I don't think they're sufficient. You have a comment about "Longer strings to prevent interning" but I'm not sure that a mere 21 characters is guaranteed now and forever to do that. I'd be much happier to see a long string which is not an identifier: s = S("# ! ~"*50) # hopefully will not be interned plus an assertion to check that it is not interned. That way, if the rules for interning ever change, the test will fail loudly and clearly rather than silently do the wrong thing. (Better still would be an actual language API for un-interning strings, if one exists.) Also, I see that you have tests to check that the optimized path is taken for subclasses, but do you have tests to check that it is NOT taken when it shouldn't be? ---------- nosy: +steven.daprano versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 21:40:05 2016 From: report at bugs.python.org (INADA Naoki) Date: Wed, 06 Jul 2016 01:40:05 +0000 Subject: [issue27454] PyUnicode_InternInPlace can use PyDict_SetDefault In-Reply-To: <1467723696.2.0.276855964684.issue27454@psf.upfronthosting.co.za> Message-ID: <1467769205.19.0.698143950374.issue27454@psf.upfronthosting.co.za> INADA Naoki added the comment: Thank you for pointing it out. That comment seems useless when removing PyDict_GetItem(). So I removed it. ---------- Added file: http://bugs.python.org/file43634/intern-setdefault2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 21:52:17 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 06 Jul 2016 01:52:17 +0000 Subject: [issue27452] IDLE: Cleanup config code In-Reply-To: <1467662991.07.0.187758431637.issue27452@psf.upfronthosting.co.za> Message-ID: <20160706015213.41505.21670.D3067E1D@psf.io> Roundup Robot added the comment: New changeset adbeef96ae95 by Terry Jan Reedy in branch 'default': Issue #27452: make command line idle-test> python test_help.py work. https://hg.python.org/cpython/rev/adbeef96ae95 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 21:55:37 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 06 Jul 2016 01:55:37 +0000 Subject: [issue27452] IDLE: Cleanup config code In-Reply-To: <1467662991.07.0.187758431637.issue27452@psf.upfronthosting.co.za> Message-ID: <1467770137.1.0.775883290054.issue27452@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Ah, the invocation I did not test ;-). It does not matter in this case because "os.path.dirname('config.py')" is '' and the join leaves relative names for the config files that work fine for opening them. F:\Python\dev\36\Lib\idlelib>..\..\pcbuild\win32\python_d.exe config.py {'keys': <__main__.IdleConfParser object at 0x000002633B200080>, ... At one time, I thought, sys.path[0] was '', representing the current directory, and not the absolute path of the starting directory. I am not sure if there are any cross platform, cross implementation, guarantees. There are 12 other idlelib files using __file__. I ran each in either idlelib or idle_test as appropriate. 11 run. test_help.py fails at this line (which I wrote) helpfile = join(abspath(dirname(dirname(__file__))), 'help.html') as the double dirname does not have the expected effect. A version of the conditional from config, with dirname(sys.path[0]), would work. However, taking the abspath first is easier. helpfile = join(dirname(dirname(abspath(__file__))), 'help.html') The comment in config appears to refer to the exec command/function. I don't know what either does with __name__, __file__, or sys.path. --- With the two IdleConf dict keys sorted, the first patch results in consistent output. configparser.ConfigParser uses OrderedDicts by default, so re-running on unchanged files results in unchanged iteration order. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 21:57:12 2016 From: report at bugs.python.org (Zhihan Chen) Date: Wed, 06 Jul 2016 01:57:12 +0000 Subject: [issue27459] unintended changes occur when dealing with list of list In-Reply-To: <1467763672.45.0.0368079728325.issue27459@psf.upfronthosting.co.za> Message-ID: <1467770232.08.0.508330179425.issue27459@psf.upfronthosting.co.za> Zhihan Chen added the comment: Oh I am really sorry for my carelessness. Please accept my apology. and thank you Steven, I will pay special attention to that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 23:10:58 2016 From: report at bugs.python.org (Larry Hastings) Date: Wed, 06 Jul 2016 03:10:58 +0000 Subject: [issue24557] Refactor LibreSSL / EGD detection In-Reply-To: <1435926751.49.0.18395819216.issue24557@psf.upfronthosting.co.za> Message-ID: <1467774658.93.0.201345396002.issue24557@psf.upfronthosting.co.za> Larry Hastings added the comment: At this point you're not adding this to 3.5. ---------- versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 23:11:39 2016 From: report at bugs.python.org (Larry Hastings) Date: Wed, 06 Jul 2016 03:11:39 +0000 Subject: [issue24557] Refactor LibreSSL / EGD detection In-Reply-To: <1435926751.49.0.18395819216.issue24557@psf.upfronthosting.co.za> Message-ID: <1467774699.08.0.418198794676.issue24557@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- nosy: -larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 23:17:07 2016 From: report at bugs.python.org (Ammar Askar) Date: Wed, 06 Jul 2016 03:17:07 +0000 Subject: [issue27458] Allow subtypes of unicode/str to hit the optimized unicode_concatenate block In-Reply-To: <1467749411.27.0.801295605617.issue27458@psf.upfronthosting.co.za> Message-ID: <1467775027.92.0.951621469643.issue27458@psf.upfronthosting.co.za> Ammar Askar added the comment: Thank you very much for the prompt feedback. I didn't even realize there was a __radd__ method, great catch. I've fixed this and added an appropriate test. Very good point about the interning. Seeing as its an implementation detail, I've changed the interned tests to cpython only and added the assertion to ensure they are not interned. I don't think there's any language level features to ensure strings are not interned. As far as testing the execution path goes. I was updating the source code in my test.py script between concatenating with subtypes vs just plain old unicode objects since doing multiple traces was starting to get a lot more complicated with gdb scripting :) ---------- Added file: http://bugs.python.org/file43635/python.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 5 23:17:33 2016 From: report at bugs.python.org (Ammar Askar) Date: Wed, 06 Jul 2016 03:17:33 +0000 Subject: [issue27458] Allow subtypes of unicode/str to hit the optimized unicode_concatenate block In-Reply-To: <1467749411.27.0.801295605617.issue27458@psf.upfronthosting.co.za> Message-ID: <1467775053.8.0.295585954915.issue27458@psf.upfronthosting.co.za> Changes by Ammar Askar : Removed file: http://bugs.python.org/file43631/python.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 03:25:50 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 06 Jul 2016 07:25:50 +0000 Subject: [issue27458] Allow subtypes of unicode/str to hit the optimized unicode_concatenate block In-Reply-To: <1467749411.27.0.801295605617.issue27458@psf.upfronthosting.co.za> Message-ID: <1467789950.39.0.144809460346.issue27458@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: -pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 03:55:54 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 Jul 2016 07:55:54 +0000 Subject: [issue27458] Allow subtypes of unicode/str to hit the optimized unicode_concatenate block In-Reply-To: <1467749411.27.0.801295605617.issue27458@psf.upfronthosting.co.za> Message-ID: <1467791754.35.0.441843650436.issue27458@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: 1. It would be interesting to see an example showing the benefit of this change. How large is the benefit, and how common is this case? 2. The optimization of string concatenation is CPython specific, and AFAIK it was decided not to extend it to other cases (e.g. to bytes). The recommended way for efficient string concatenation is using str.join or io.StringIO. Or classic string formatting -- this is yet one CPython specific optimization. 3. Non-compact string representation is legacy. It is kept for compatibility with existing code, but will be removed in future. The work with non-compact strings is not always efficient. ---------- nosy: +gvanrossum, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 03:59:07 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 Jul 2016 07:59:07 +0000 Subject: [issue27452] IDLE: Cleanup config code In-Reply-To: <1467662991.07.0.187758431637.issue27452@psf.upfronthosting.co.za> Message-ID: <1467791947.22.0.142952851884.issue27452@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In this case it works, because os.join('', filename) returns filename. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 04:39:15 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 Jul 2016 08:39:15 +0000 Subject: [issue27441] redundant assignments to ob_size of new ints that _PyLong_New returned In-Reply-To: <1467470337.8.0.776341442151.issue27441@psf.upfronthosting.co.za> Message-ID: <1467794355.03.0.451851557584.issue27441@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Changes to PyLong_FromUnsignedLong() and PyLong_FromUnsignedLongLong() LGTM. I don't know whether other changes have a positive effect. Are there any microbenchmarks? There are other places in which Py_SIZE() is set to the same value. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 05:00:41 2016 From: report at bugs.python.org (Upendra Kumar) Date: Wed, 06 Jul 2016 09:00:41 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1467795641.23.0.445385765353.issue27051@psf.upfronthosting.co.za> Upendra Kumar added the comment: @Terry, I am switching between different frames using frame.tkraise() method in order to switch the user attention. Now, if I want to test which frame is at top what should I check for or which parameter I should check. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 05:22:17 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 06 Jul 2016 09:22:17 +0000 Subject: [issue21708] Deprecate nonstandard behavior of a dumbdbm database In-Reply-To: <1402425082.25.0.679069092867.issue21708@psf.upfronthosting.co.za> Message-ID: <20160706092214.13598.91391.5840BAA3@psf.io> Roundup Robot added the comment: New changeset 62da75b29b29 by Serhiy Storchaka in branch 'default': Issue #21708: Deprecated dbm.dumb behavior that differs from common dbm https://hg.python.org/cpython/rev/62da75b29b29 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 05:31:09 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 Jul 2016 09:31:09 +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: <1467797469.97.0.0744939550945.issue17711@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping again. ---------- versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 06:11:39 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 06 Jul 2016 10:11:39 +0000 Subject: [issue7769] SimpleXMLRPCServer.SimpleXMLRPCServer.register_function as decorator In-Reply-To: <1264337326.51.0.913533963705.issue7769@psf.upfronthosting.co.za> Message-ID: <1467799899.64.0.944185715867.issue7769@psf.upfronthosting.co.za> Xiang Zhang added the comment: ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 06:12:03 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 06 Jul 2016 10:12:03 +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: <1467799923.83.0.830038956106.issue27248@psf.upfronthosting.co.za> Xiang Zhang added the comment: ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 06:12:32 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 06 Jul 2016 10:12: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: <1467799952.04.0.84080802865.issue26915@psf.upfronthosting.co.za> Xiang Zhang added the comment: ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 06:18:24 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 06 Jul 2016 10:18:24 +0000 Subject: [issue27442] expose the Android API level in sysconfig.get_config_vars() In-Reply-To: <1467471175.35.0.000904857777026.issue27442@psf.upfronthosting.co.za> Message-ID: <1467800304.26.0.271140152448.issue27442@psf.upfronthosting.co.za> Xavier de Gaye added the comment: New patch incorporating the substitutions to '$CPP $CPPFLAGS' and ANDROID_API_LEVEL. ---------- stage: patch review -> commit review Added file: http://bugs.python.org/file43636/android_api_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 06:23:16 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 06 Jul 2016 10:23:16 +0000 Subject: [issue27453] $CPP invocation in configure must use $CPPFLAGS In-Reply-To: <1467717523.35.0.850577639812.issue27453@psf.upfronthosting.co.za> Message-ID: <1467800596.74.0.908470538941.issue27453@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- title: Fix cross-compilation with Android NDK and Clang -> $CPP invocation in configure must use $CPPFLAGS versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 06:38:48 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 06 Jul 2016 10:38:48 +0000 Subject: [issue27460] Change bytes exception when overflow Message-ID: <1467801528.33.0.514121242609.issue27460@psf.upfronthosting.co.za> New submission from Xiang Zhang: I suggest change `bytes` exception message when an iterable containing overflow integers. Right now, bytes([sys.maxsize+1]) emits ValueError: cannot fit 'int' into an index-sized integer "ValueError: cannot fit 'int' into an index-sized integer". I think actually when use bytes in such a situation we don't care the integer overflows or not, we only care if the integer is in range(0, 256) or not, just like what bytearray([sys.maxsize+1]) does. ---------- files: bytes_exception_msg.patch keywords: patch messages: 269879 nosy: xiang.zhang priority: normal severity: normal status: open title: Change bytes exception when overflow Added file: http://bugs.python.org/file43637/bytes_exception_msg.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 06:39:07 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 06 Jul 2016 10:39:07 +0000 Subject: [issue27434] cross-building python 3.6 with an older interpreter fails In-Reply-To: <1467378022.01.0.957641757812.issue27434@psf.upfronthosting.co.za> Message-ID: <1467801547.98.0.697819731789.issue27434@psf.upfronthosting.co.za> Xavier de Gaye added the comment: New patch that gets rid of the changes in configure made by my version of autoconf. This version is 2.69 though, i.e. the same as the generated configure file that is under control of mercurial in the default branch. ---------- assignee: -> xdegaye stage: patch review -> commit review Added file: http://bugs.python.org/file43638/restrict_interp_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 06:39:27 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 06 Jul 2016 10:39:27 +0000 Subject: [issue27460] Change bytes exception when overflow In-Reply-To: <1467801528.33.0.514121242609.issue27460@psf.upfronthosting.co.za> Message-ID: <1467801567.73.0.487554146484.issue27460@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- type: -> enhancement versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 07:18:03 2016 From: report at bugs.python.org (Marcos Dione) Date: Wed, 06 Jul 2016 11:18:03 +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: <1467803882.98.0.713776889476.issue26826@psf.upfronthosting.co.za> Marcos Dione added the comment: New version: * Adds a new test for offset parameters. ---------- Added file: http://bugs.python.org/file43639/copy_file_range.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 08:38:42 2016 From: report at bugs.python.org (Marcos Dione) Date: Wed, 06 Jul 2016 12:38:42 +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: <1467808722.13.0.1102942528.issue26826@psf.upfronthosting.co.za> Marcos Dione added the comment: Another version: * Changed availability to kernel type, version and date. ---------- Added file: http://bugs.python.org/file43640/copy_file_range.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 08:38:57 2016 From: report at bugs.python.org (John Hagen) Date: Wed, 06 Jul 2016 12:38:57 +0000 Subject: [issue27455] Fix tkinter examples to be PEP8 compliant In-Reply-To: <1467724852.16.0.852334218439.issue27455@psf.upfronthosting.co.za> Message-ID: <1467808737.95.0.232748416271.issue27455@psf.upfronthosting.co.za> Changes by John Hagen : Removed file: http://bugs.python.org/file43628/0001-Fix-tkinter-docs-PEP8.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 08:41:46 2016 From: report at bugs.python.org (John Hagen) Date: Wed, 06 Jul 2016 12:41:46 +0000 Subject: [issue27455] Fix tkinter examples to be PEP8 compliant In-Reply-To: <1467724852.16.0.852334218439.issue27455@psf.upfronthosting.co.za> Message-ID: <1467808906.95.0.448539576218.issue27455@psf.upfronthosting.co.za> John Hagen added the comment: @Terry I've removed the two string quotes changes in the latest patch. @Berker I spent a small amount of time trying out your proposed super() changes, but could not get them to work on 3.5.1. "C:\Users\John Hagen\AppData\Local\Programs\Python\Python35\python.exe" "C:/Users/John Hagen/PycharmProjects/test/test.py" Traceback (most recent call last): File "C:/Users/John Hagen/PycharmProjects/test/test.py", line 25, in app = Application(master=root) File "C:/Users/John Hagen/PycharmProjects/test/test.py", line 6, in __init__ super().__init__(self, master) File "C:\Users\John Hagen\AppData\Local\Programs\Python\Python35\lib\tkinter\__init__.py", line 2583, in __init__ Widget.__init__(self, master, 'frame', cnf, {}, extra) File "C:\Users\John Hagen\AppData\Local\Programs\Python\Python35\lib\tkinter\__init__.py", line 2131, in __init__ BaseWidget._setup(self, master, cnf) File "C:\Users\John Hagen\AppData\Local\Programs\Python\Python35\lib\tkinter\__init__.py", line 2109, in _setup self.tk = master.tk AttributeError: 'Application' object has no attribute 'tk' -------------------- import tkinter as tk class Application(tk.Frame): def __init__(self, master=None): super().__init__(self, master) self.pack() self.create_widgets() def create_widgets(self): self.hi_there = tk.Button(self) self.hi_there["text"] = "Hello World\n(click me)" self.hi_there["command"] = self.say_hi self.hi_there.pack(side="top") self.quit = tk.Button(self, text="QUIT", fg="red", command=root.destroy) self.quit.pack(side="bottom") def say_hi(self): print("hi there, everyone!") root = tk.Tk() app = Application(master=root) app.mainloop() ---------- Added file: http://bugs.python.org/file43641/0001-Fix-tkinter-docs-PEP8.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 09:04:56 2016 From: report at bugs.python.org (Brian Curtin) Date: Wed, 06 Jul 2016 13:04:56 +0000 Subject: [issue7769] SimpleXMLRPCServer.SimpleXMLRPCServer.register_function as decorator In-Reply-To: <1264337326.51.0.913533963705.issue7769@psf.upfronthosting.co.za> Message-ID: <1467810296.9.0.917695468658.issue7769@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- nosy: -brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 09:16:22 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 06 Jul 2016 13:16:22 +0000 Subject: [issue27455] Fix tkinter examples to be PEP8 compliant In-Reply-To: <1467724852.16.0.852334218439.issue27455@psf.upfronthosting.co.za> Message-ID: <1467810982.75.0.689091284161.issue27455@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the updated patch. I noticed a typo in your test script. It works for me if I update the super() line from super().__init__(self, master) to super().__init__(master) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 09:56:19 2016 From: report at bugs.python.org (Andrew) Date: Wed, 06 Jul 2016 13:56:19 +0000 Subject: [issue27448] Race condition in subprocess.Popen which causes a huge memory leak In-Reply-To: <1467636752.08.0.502936379731.issue27448@psf.upfronthosting.co.za> Message-ID: <1467813379.06.0.927536624623.issue27448@psf.upfronthosting.co.za> Andrew added the comment: Gregory P. Smith, "if you are seeing a memory leak and the statements that fail before the gc.enable call are more than" The problem in my case was different. It was race condition between gc.isenabled and gc.disable. Isenabled was called when gc was disabled by another subprocess. This caused that later on gc.enable was not triggered. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 11:22:38 2016 From: report at bugs.python.org (Roman Bolshakov) Date: Wed, 06 Jul 2016 15:22:38 +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: <1467818558.07.0.610471438497.issue27151@psf.upfronthosting.co.za> Roman Bolshakov added the comment: multiprocessing.Queue._writer is affected by similar issue. _writer FD is left open after .close() is invoked on a Queue. ---------- Added file: http://bugs.python.org/file43642/leak.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 11:22:59 2016 From: report at bugs.python.org (Roman Bolshakov) Date: Wed, 06 Jul 2016 15:22:59 +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: <1467818579.07.0.34586696064.issue27151@psf.upfronthosting.co.za> Changes by Roman Bolshakov : Removed file: http://bugs.python.org/file43046/leak.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 11:29:31 2016 From: report at bugs.python.org (Jim Fulton) Date: Wed, 06 Jul 2016 15:29:31 +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: <1467818971.59.0.257625511738.issue27386@psf.upfronthosting.co.za> Changes by Jim Fulton : ---------- type: behavior -> security _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 12:00:47 2016 From: report at bugs.python.org (Allan Haldane) Date: Wed, 06 Jul 2016 16:00:47 +0000 Subject: [issue26746] struct.pack(): trailing padding bytes on x64 In-Reply-To: <1460536729.2.0.723853097724.issue26746@psf.upfronthosting.co.za> Message-ID: <1467820847.41.0.505347723351.issue26746@psf.upfronthosting.co.za> Allan Haldane added the comment: Hello, Over at numpy I have a proposed fix for the bug you discovered, that numpy drops trailing padding in the 3118 format string. My strategy is going to make numpy interpret format strings exactly the same way as the struct module, let me know if you disagree. See https://github.com/numpy/numpy/pull/7798 ---------- nosy: +Allan Haldane _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 12:46:58 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 Jul 2016 16:46:58 +0000 Subject: [issue27458] Allow subtypes of unicode/str to hit the optimized unicode_concatenate block In-Reply-To: <1467749411.27.0.801295605617.issue27458@psf.upfronthosting.co.za> Message-ID: <1467823618.98.0.861588429423.issue27458@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'm not interested, sorry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 12:47:22 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 Jul 2016 16:47:22 +0000 Subject: [issue27458] Allow subtypes of unicode/str to hit the optimized unicode_concatenate block In-Reply-To: <1467749411.27.0.801295605617.issue27458@psf.upfronthosting.co.za> Message-ID: <1467823642.69.0.700566422891.issue27458@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- nosy: -gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 12:51:16 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 06 Jul 2016 16:51:16 +0000 Subject: [issue27460] Change bytes exception when overflow In-Reply-To: <1467801528.33.0.514121242609.issue27460@psf.upfronthosting.co.za> Message-ID: <1467823876.81.0.0041079915481.issue27460@psf.upfronthosting.co.za> Changes by Xiang Zhang : Removed file: http://bugs.python.org/file43637/bytes_exception_msg.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 12:51:24 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 06 Jul 2016 16:51:24 +0000 Subject: [issue27460] Change bytes exception when overflow In-Reply-To: <1467801528.33.0.514121242609.issue27460@psf.upfronthosting.co.za> Message-ID: <1467823884.28.0.24113418622.issue27460@psf.upfronthosting.co.za> Changes by Xiang Zhang : Added file: http://bugs.python.org/file43643/bytes_exception_msg.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 13:21:50 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 Jul 2016 17:21:50 +0000 Subject: [issue27460] Change bytes exception when overflow In-Reply-To: <1467801528.33.0.514121242609.issue27460@psf.upfronthosting.co.za> Message-ID: <1467825710.91.0.354291633687.issue27460@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. Are there any tests for these cases? ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 13:30:23 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 06 Jul 2016 17:30:23 +0000 Subject: [issue27458] Allow subtypes of unicode/str to hit the optimized unicode_concatenate block In-Reply-To: <1467749411.27.0.801295605617.issue27458@psf.upfronthosting.co.za> Message-ID: <1467826223.79.0.253440150922.issue27458@psf.upfronthosting.co.za> Raymond Hettinger added the comment: We really don't want to encourage any reliance on this optimization. It was put there only to help mitigate the performance impact of a common mistake. I don't think subclasses warrant extended coverage. This was already a hack at the outer limits of how far we were willing to go. It doesn't make sense to propagate it further. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 13:31:25 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 06 Jul 2016 17:31:25 +0000 Subject: [issue27460] Change bytes exception when overflow In-Reply-To: <1467801528.33.0.514121242609.issue27460@psf.upfronthosting.co.za> Message-ID: <1467826285.31.0.846840833861.issue27460@psf.upfronthosting.co.za> Xiang Zhang added the comment: The constructor has been well tested in https://hg.python.org/cpython/file/tip/Lib/test/test_bytes.py#l111. It looks like that the original author only wants to guarantee the exception type but not message. So I didn't add a assertRaisesRegex test. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 13:39:07 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 06 Jul 2016 17:39:07 +0000 Subject: [issue26974] Crash in Decimal.from_float In-Reply-To: <1462684427.76.0.86950702335.issue26974@psf.upfronthosting.co.za> Message-ID: <1467826747.11.0.554977503428.issue26974@psf.upfronthosting.co.za> Raymond Hettinger added the comment: My preference is to leave the Python implementation of from_float() as-is. Pure Python code is not obligated to defend itself against bizarre code. The C code however is obliged to not segfault. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 14:24:19 2016 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 06 Jul 2016 18:24:19 +0000 Subject: [issue23085] update internal libffi copy to 3.2.1 In-Reply-To: <1418922803.63.0.55729998299.issue23085@psf.upfronthosting.co.za> Message-ID: <1467829459.8.0.582478412246.issue23085@psf.upfronthosting.co.za> Chris Jerdonek added the comment: > Are there any issue *we* have with libffi which an update to 3.2.1 would solve ? There are these Ubuntu-specific compiler warnings: https://bugs.python.org/issue25077 which Berker says have been fixed in upstream libffi: https://bugs.python.org/issue25077#msg266068 ---------- nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 14:32:17 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 Jul 2016 18:32:17 +0000 Subject: [issue27460] Change bytes exception when overflow In-Reply-To: <1467801528.33.0.514121242609.issue27460@psf.upfronthosting.co.za> Message-ID: <1467829937.56.0.451828844852.issue27460@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is enough. ---------- stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 14:40:18 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 06 Jul 2016 18:40:18 +0000 Subject: [issue27460] Change bytes exception when overflow In-Reply-To: <1467801528.33.0.514121242609.issue27460@psf.upfronthosting.co.za> Message-ID: <20160706184014.22296.52344.11F5FE86@psf.io> Roundup Robot added the comment: New changeset f9481e5f1792 by Serhiy Storchaka in branch 'default': Issue #27460: Unified error messages in bytes constructor for integers https://hg.python.org/cpython/rev/f9481e5f1792 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 14:41:36 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 Jul 2016 18:41:36 +0000 Subject: [issue27460] Change bytes exception when overflow In-Reply-To: <1467801528.33.0.514121242609.issue27460@psf.upfronthosting.co.za> Message-ID: <1467830496.42.0.655751719853.issue27460@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your contribution Xiang Zhang. ---------- components: +Interpreter Core resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 14:58:18 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 06 Jul 2016 18:58:18 +0000 Subject: [issue23085] update internal libffi copy to 3.2.1 In-Reply-To: <1418922803.63.0.55729998299.issue23085@psf.upfronthosting.co.za> Message-ID: <1467831498.75.0.873643170426.issue23085@psf.upfronthosting.co.za> Berker Peksag added the comment: > which Berker says have been fixed in upstream libffi: https://bugs.python.org/issue25077#msg266068 Correct, here is the actual commit: https://github.com/libffi/libffi/commit/4a677a425c18eda4bc5357b2485da57f133f908d I have also sent a patch to upstream libffi for https://github.com/python/cpython/blob/master/Modules/_ctypes/libffi.diff#L161: https://github.com/libffi/libffi/commit/1e82e1cda43dacd8b6ab2d9ac4db33523d86f5dc But both of them will be released in libffi 4.0. Note that the current master branch of libffi doesn't seem to be compiled with a C89 compiler (see https://github.com/libffi/libffi/issues/218 for details). See also https://mail.python.org/pipermail/python-dev/2016-June/144816.html for discussion about C99 support in CPython. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 15:01:48 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Jul 2016 19:01:48 +0000 Subject: [issue27458] Allow subtypes of unicode/str to hit the optimized unicode_concatenate block In-Reply-To: <1467826223.79.0.253440150922.issue27458@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: I agree with Raymond. Use ''.join(list of str) or a similar pattern. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 15:08:33 2016 From: report at bugs.python.org (Emanuel Barry) Date: Wed, 06 Jul 2016 19:08:33 +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: <1467832113.21.0.988877576708.issue27137@psf.upfronthosting.co.za> Emanuel Barry added the comment: Is there anything still preventing this from being merged? I think the ability to consistently get the same behaviour, with or without _functools available, outweighs the performance and simplicity loss (and as far as performance loss goes, it appears that _functools is always available as far as CPython is concerned, which makes it a non-issue). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 15:12:22 2016 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 06 Jul 2016 19:12:22 +0000 Subject: [issue25077] Compiler warnings: initialization from incompatible pointer type In-Reply-To: <1442042610.13.0.957335882034.issue25077@psf.upfronthosting.co.za> Message-ID: <1467832342.99.0.357190711296.issue25077@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 15:15:02 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Jul 2016 19:15:02 +0000 Subject: [issue27434] cross-building python 3.6 with an older interpreter fails In-Reply-To: <1467378022.01.0.957641757812.issue27434@psf.upfronthosting.co.za> Message-ID: <1467832502.91.0.0859180196255.issue27434@psf.upfronthosting.co.za> STINNER Victor added the comment: restrict_interp_2.patch: LGTM. not ... == '...' can be written ... != '...', no? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 15:19:07 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 06 Jul 2016 19:19:07 +0000 Subject: [issue27051] Create PIP gui In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za> Message-ID: <1467832747.85.0.799947238756.issue27051@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Window stacking order can be queried with tcl calls: https://stackoverflow.com/questions/10343759/determining-what-tkinter-window-is-currently-on-top/10391659#10391659. I do not if there is the equivalent for frames. Note that uses can change window stack order, hence the need for a query, but not frame stack order. https://stackoverflow.com/questions/35690249/tkinter-is-it-possible-to-change-the-stacking-order-of-placed-frames claims that frames are initially stacked in order created. Verify if you want. After that, keep track of how you change the order. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 15:19:37 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Jul 2016 19:19:37 +0000 Subject: [issue27442] expose the Android API level in sysconfig.get_config_vars() In-Reply-To: <1467471175.35.0.000904857777026.issue27442@psf.upfronthosting.co.za> Message-ID: <1467832777.58.0.0292526504464.issue27442@psf.upfronthosting.co.za> STINNER Victor added the comment: + @unittest.skipIf(sysconfig.get_config_var('ANDROID_API_LEVEL') == 0, + "not an android platform") Hum, sysconfig.get_config_var() returns None for unknown variable. Why checking ==0? @Xavier: Are you generating the patch using "hg diff"? I don't see the base revision in your patch, and so there is no [Review] link on your patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 15:20:35 2016 From: report at bugs.python.org (Ammar Askar) Date: Wed, 06 Jul 2016 19:20:35 +0000 Subject: [issue27458] Allow subtypes of unicode/str to hit the optimized unicode_concatenate block In-Reply-To: <1467749411.27.0.801295605617.issue27458@psf.upfronthosting.co.za> Message-ID: <1467832835.28.0.765608400982.issue27458@psf.upfronthosting.co.za> Ammar Askar added the comment: > We really don't want to encourage any reliance on this optimization. It was put there only to help mitigate the performance impact of a common mistake. Aah, I didn't realize the extra context behind why the unicode_concatenate path actually exists in ceval. Makes sense though since it was the only exceptional case that popped out in ceval. > It would be interesting to see an example showing the benefit of this change I'm no expert at benchmarking but I threw together a quick script to compare the different ways of string concatenation and it seems like an INPLACE_ADD is the fastest. (which makes sense because it avoids the overhead of having a list object that ''.join brings in, not sure why StringIO is slower than both though, maybe that would be a better place to improve?) Either way if you guys think this adds too much complexity on top of an existing hack, this is fine to close. Benchmarking results: INPLACE_ADD short ascii 0.4307783489348367 ''.join short ascii 0.6934443039353937 StringIO short ascii 0.9447220619767904 INPLACE_ADD short unicode 0.4411839219974354 ''.join short unicode 0.666951927007176 StringIO short unicode 0.9783720930572599 INPLACE_ADD long ascii 3.6157665309729055 ''.join long ascii 6.938268916099332 StringIO long ascii 5.279585674987175 INPLACE_ADD long unicode 3.7768358619650826 ''.join long unicode 4.641092017991468 StringIO long unicode 7.6051657549105585 ---------- Added file: http://bugs.python.org/file43644/bench.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 15:21:20 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Jul 2016 19:21:20 +0000 Subject: [issue27458] Allow subtypes of unicode/str to hit the optimized unicode_concatenate block In-Reply-To: <1467749411.27.0.801295605617.issue27458@psf.upfronthosting.co.za> Message-ID: <1467832880.82.0.393623028795.issue27458@psf.upfronthosting.co.za> STINNER Victor added the comment: I close the issue. ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 15:33:57 2016 From: report at bugs.python.org (Emanuel Barry) Date: Wed, 06 Jul 2016 19:33:57 +0000 Subject: [issue27220] Add a pure Python version of 'collections.defaultdict' In-Reply-To: <1465060064.38.0.412706275461.issue27220@psf.upfronthosting.co.za> Message-ID: <1467833637.8.0.220569837804.issue27220@psf.upfronthosting.co.za> Emanuel Barry added the comment: Raymond, do you have any interest/time to review this? I can ask someone else, if you prefer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 15:56:10 2016 From: report at bugs.python.org (John Hagen) Date: Wed, 06 Jul 2016 19:56:10 +0000 Subject: [issue27455] Fix tkinter examples to be PEP8 compliant In-Reply-To: <1467724852.16.0.852334218439.issue27455@psf.upfronthosting.co.za> Message-ID: <1467834970.59.0.999217143402.issue27455@psf.upfronthosting.co.za> Changes by John Hagen : Removed file: http://bugs.python.org/file43641/0001-Fix-tkinter-docs-PEP8.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 15:57:46 2016 From: report at bugs.python.org (John Hagen) Date: Wed, 06 Jul 2016 19:57:46 +0000 Subject: [issue27455] Fix tkinter examples to be PEP8 compliant In-Reply-To: <1467724852.16.0.852334218439.issue27455@psf.upfronthosting.co.za> Message-ID: <1467835066.29.0.535174308106.issue27455@psf.upfronthosting.co.za> John Hagen added the comment: @Berker, thanks for the tip! I've fixed it up. I think this latest patch covers everything Berker and Terry have commented about. ---------- Added file: http://bugs.python.org/file43645/Fix-tkinter-docs-PEP8.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 16:06:04 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Wed, 06 Jul 2016 20:06:04 +0000 Subject: [issue23085] update internal libffi copy to 3.2.1 In-Reply-To: <1418922803.63.0.55729998299.issue23085@psf.upfronthosting.co.za> Message-ID: <1467835564.46.0.732712993502.issue23085@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: +1 for this. Cross-compile CPython for ARM with clang fails in _ctypes due to https://llvm.org/bugs/show_bug.cgi?id=20595. This bug is already fixed in libffi. By the way, I can't apply libffi.patch to the default branch. Some hunks are rejcted. Is there something wrong? issue26942 may also be relevant. I did't test it as I'm not sure how to update CPython's internal libffi. ---------- nosy: +Chi Hsuan Yen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 16:18:08 2016 From: report at bugs.python.org (Zachary Ware) Date: Wed, 06 Jul 2016 20:18:08 +0000 Subject: [issue23085] update internal libffi copy to 3.2.1 In-Reply-To: <1418922803.63.0.55729998299.issue23085@psf.upfronthosting.co.za> Message-ID: <1467836288.38.0.302170996193.issue23085@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 16:21:05 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Wed, 06 Jul 2016 20:21:05 +0000 Subject: [issue23085] update internal libffi copy to 3.2.1 In-Reply-To: <1418922803.63.0.55729998299.issue23085@psf.upfronthosting.co.za> Message-ID: <1467836465.98.0.614446887344.issue23085@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Oops the proglem of clang on ARM is not completely fixed in libffi 3.2.1. This commit [1] fixes only one `stmeqia` but not another. [1] https://github.com/libffi/libffi/commit/6eff9ff9e72463b9783be2514f944b6f05692054#diff-c6400d42bf23866ded49558ca9a54205R220 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 17:31:14 2016 From: report at bugs.python.org (Emanuel Barry) Date: Wed, 06 Jul 2016 21:31:14 +0000 Subject: [issue26823] Shrink recursive tracebacks In-Reply-To: <1461292585.22.0.159887337407.issue26823@psf.upfronthosting.co.za> Message-ID: <1467840674.82.0.732495568005.issue26823@psf.upfronthosting.co.za> Emanuel Barry added the comment: Sorry for the delay, but here's a patch with updated tests after Nick's suggestions. It should be ready to merge now. (I'm having some failures in test_traceback, but they fail even without my patch) ---------- Added file: http://bugs.python.org/file43646/short_tracebacks_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 17:48:56 2016 From: report at bugs.python.org (Ammar Askar) Date: Wed, 06 Jul 2016 21:48:56 +0000 Subject: [issue26267] UUID docs should say how to get "standard form" In-Reply-To: <1454438589.41.0.991764109365.issue26267@psf.upfronthosting.co.za> Message-ID: <1467841736.37.0.971534848805.issue26267@psf.upfronthosting.co.za> Ammar Askar added the comment: This patch adds documentation for the str(uuid) operator along with documenting the fact that UUID instances support comparisons with `>` and `<`. It also indents the attributes and descriptions to emphasize that they are part of the UUID instance, not the uuid module. I followed https://docs.python.org/3/library/stdtypes.html#set for documenting the operators, hope it's fine. ---------- keywords: +patch nosy: +ammar2 Added file: http://bugs.python.org/file43647/uuiddocs.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 17:51:19 2016 From: report at bugs.python.org (Emanuel Barry) Date: Wed, 06 Jul 2016 21:51:19 +0000 Subject: [issue27242] Make the docs for NotImplemented & NotImplementedError unambiguous In-Reply-To: <1465239567.69.0.773832868585.issue27242@psf.upfronthosting.co.za> Message-ID: <1467841879.73.0.478123345013.issue27242@psf.upfronthosting.co.za> Emanuel Barry added the comment: New patch with proper indenting, should be good as far as formatting is concerned :) ---------- Added file: http://bugs.python.org/file43648/NotImplemented_exceptions_wording_5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 18:39:45 2016 From: report at bugs.python.org (Ammar Askar) Date: Wed, 06 Jul 2016 22:39:45 +0000 Subject: [issue23710] C API doc for PyObject_HEAD is outdated In-Reply-To: <1426776099.01.0.644113037586.issue23710@psf.upfronthosting.co.za> Message-ID: <1467844785.19.0.593378354153.issue23710@psf.upfronthosting.co.za> Ammar Askar added the comment: This diff amends the documentation to point out that PyObject_HEAD includes the ob_base field, gives a brief overview of it and points to the PyObject/structures page for more information. It also changes the semicolon part to a warning for clarity. ---------- keywords: +patch nosy: +ammar2 Added file: http://bugs.python.org/file43649/capidocs.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 19:28:10 2016 From: report at bugs.python.org (Ammar Askar) Date: Wed, 06 Jul 2016 23:28:10 +0000 Subject: [issue19489] move quick search box above TOC In-Reply-To: <1383546510.68.0.587653327623.issue19489@psf.upfronthosting.co.za> Message-ID: <1467847690.24.0.824414248182.issue19489@psf.upfronthosting.co.za> Ammar Askar added the comment: It looks like this can be fixed by us. Since sphinx 1.0 there is this handy config parameter: http://www.sphinx-doc.org/en/stable/config.html#confval-html_sidebars I've attached a patch which pins the searchbox as the first thing on every page. ---------- keywords: +patch nosy: +ammar2 Added file: http://bugs.python.org/file43650/searchbar.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 20:18:32 2016 From: report at bugs.python.org (Ammar Askar) Date: Thu, 07 Jul 2016 00:18:32 +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: <1467850712.24.0.875273712148.issue27400@psf.upfronthosting.co.za> Ammar Askar added the comment: Is there any particular reason that datetime.strptime caches the imported module like that? >From a quick search, these two other examples don't bother with any caching: https://github.com/python/cpython/blob/2d264235f6e066611b412f7c2e1603866e0f7f1b/Modules/timemodule.c#L709 https://github.com/python/cpython/blob/64fe35c9fee088f7fec4dd2d760cb0026ac54ec8/Python/traceback.c#L277 ---------- nosy: +ammar2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 20:33:24 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 07 Jul 2016 00:33:24 +0000 Subject: [issue27448] Race condition in subprocess.Popen which causes a huge memory leak In-Reply-To: <1467636752.08.0.502936379731.issue27448@psf.upfronthosting.co.za> Message-ID: <1467851604.12.0.0548119027188.issue27448@psf.upfronthosting.co.za> Gregory P. Smith added the comment: ah, okay, that makes much more sense and is indeed a bug. Recommendation given that most people won't be using a python 2.7 version that has this and tons of other subprocess from a threaded process bugs fixed: Use subprocess32 where this isn't a problem. ---------- assignee: -> gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 22:27:52 2016 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 07 Jul 2016 02:27: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: <1467858472.27.0.724991385459.issue27400@psf.upfronthosting.co.za> Nick Coghlan added the comment: Aye, skipping the caching entirely would be an even simpler solution - the only thing it is saving in the typical case is a dictionary lookup in the modules cache. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 22:29:46 2016 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 07 Jul 2016 02:29:46 +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: <1467858586.42.0.739582222246.issue27137@psf.upfronthosting.co.za> Nick Coghlan added the comment: I should be able to take a look at the updated patch this coming weekend. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 22:31:31 2016 From: report at bugs.python.org (Joshua Jay Herman) Date: Thu, 07 Jul 2016 02:31:31 +0000 Subject: [issue24459] Mention PYTHONFAULTHANDLER in the man page In-Reply-To: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za> Message-ID: <1467858691.52.0.740869540697.issue24459@psf.upfronthosting.co.za> Joshua Jay Herman added the comment: ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 23:04:30 2016 From: report at bugs.python.org (Ethan Furman) Date: Thu, 07 Jul 2016 03:04:30 +0000 Subject: [issue23591] Add IntFlags In-Reply-To: <1425569483.33.0.144069723147.issue23591@psf.upfronthosting.co.za> Message-ID: <1467860670.1.0.444614390531.issue23591@psf.upfronthosting.co.za> Ethan Furman added the comment: Reviewing... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 6 23:44:27 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 07 Jul 2016 03:44:27 +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: <1467863067.76.0.171797021361.issue27380@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Next patch should finish issue except for a couple of minor questions. ---------- stage: test needed -> commit review Added file: http://bugs.python.org/file43651/query-helpsource.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 00:28:29 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 07 Jul 2016 04:28:29 +0000 Subject: [issue27220] Add a pure Python version of 'collections.defaultdict' In-Reply-To: <1465060064.38.0.412706275461.issue27220@psf.upfronthosting.co.za> Message-ID: <1467865709.5.0.955515899849.issue27220@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 02:28:36 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 07 Jul 2016 06:28:36 +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: <20160707062833.2583.15722.8A9E0122@psf.io> Roundup Robot added the comment: New changeset f1fcf60863f8 by Benjamin Peterson in branch '3.5': fix refleaks in PyDict_SetItem error cases (closes #27248) https://hg.python.org/cpython/rev/f1fcf60863f8 New changeset 370b2985d462 by Benjamin Peterson in branch '2.7': fix refleaks in PyDict_SetItem error cases (closes #27248) https://hg.python.org/cpython/rev/370b2985d462 New changeset f7c180dbc070 by Benjamin Peterson in branch 'default': merge 3.5 (#27248) https://hg.python.org/cpython/rev/f7c180dbc070 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 02:37:15 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 07 Jul 2016 06:37:15 +0000 Subject: [issue27019] Reduce marshal stack depth for 2.7 on Windows debug build In-Reply-To: <1463244101.49.0.212240462675.issue27019@psf.upfronthosting.co.za> Message-ID: <20160707063708.15237.54121.28AA4F98@psf.io> Roundup Robot added the comment: New changeset 6230ead06f65 by Benjamin Peterson in branch '2.7': reduce marshal stack size in debug mode on windows (closes #27019) https://hg.python.org/cpython/rev/6230ead06f65 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 03:03:02 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 07 Jul 2016 07:03:02 +0000 Subject: [issue24557] Refactor LibreSSL / EGD detection In-Reply-To: <1435926751.49.0.18395819216.issue24557@psf.upfronthosting.co.za> Message-ID: <20160707070256.106859.56148.4EA522F0@psf.io> Roundup Robot added the comment: New changeset 7c0432cf1f2e by Benjamin Peterson in branch '3.5': assume egd unless OPENSSL_NO_EGD is defined?remove configure check (closes #24557) https://hg.python.org/cpython/rev/7c0432cf1f2e New changeset fe168c2b5e95 by Benjamin Peterson in branch 'default': merge 3.5 (#24557) https://hg.python.org/cpython/rev/fe168c2b5e95 New changeset 676486e1a94f by Benjamin Peterson in branch '2.7': assume egd unless OPENSSL_NO_EGD is defined?remove configure check (closes #24557) https://hg.python.org/cpython/rev/676486e1a94f ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 03:06:44 2016 From: report at bugs.python.org (koobs) Date: Thu, 07 Jul 2016 07:06:44 +0000 Subject: [issue24557] Refactor LibreSSL / EGD detection In-Reply-To: <1435926751.49.0.18395819216.issue24557@psf.upfronthosting.co.za> Message-ID: <1467875204.53.0.00190049633798.issue24557@psf.upfronthosting.co.za> koobs added the comment: Thank you Benjamin :) ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 03:17:58 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 07 Jul 2016 07:17:58 +0000 Subject: [issue27434] cross-building python 3.6 with an older interpreter fails In-Reply-To: <1467378022.01.0.957641757812.issue27434@psf.upfronthosting.co.za> Message-ID: <1467875878.42.0.252517908362.issue27434@psf.upfronthosting.co.za> Xavier de Gaye added the comment: I think the way the condition was written previously is more expressive, so the patch does not change that. The 'not' here expresses the fact that in the shell syntax, the condition is true when the test returns 0 [1], but we still want to express the fact that the 'break' is taken when the interpreter version matches $PACKAGE_VERSION. [1] https://www.gnu.org/software/bash/manual/html_node/Conditional-Constructs.html#Conditional-Constructs ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 04:43:55 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Thu, 07 Jul 2016 08:43:55 +0000 Subject: [issue26662] configure/Makefile doesn't check if "python" command works, needed to build Objects/typeslots.inc In-Reply-To: <1459247902.98.0.893274525942.issue26662@psf.upfronthosting.co.za> Message-ID: <1467881035.96.0.726500721196.issue26662@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Hit by missing `python` command from Python/makeopcodetargets.py, too. Is `make touch` the correct way? ---------- nosy: +Chi Hsuan Yen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 05:06:23 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Thu, 07 Jul 2016 09:06:23 +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: <1467882383.91.0.266075828386.issue27369@psf.upfronthosting.co.za> Changes by Chi Hsuan Yen : Added file: http://bugs.python.org/file43652/issue27369.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 05:06:43 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Thu, 07 Jul 2016 09:06:43 +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: <1467882403.67.0.384124457002.issue27369@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Added a patch. ---------- nosy: +Chi Hsuan Yen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 06:07:59 2016 From: report at bugs.python.org (Attila-Mihaly Balazs) Date: Thu, 07 Jul 2016 10:07:59 +0000 Subject: [issue21496] pyvenv activate_this.py In-Reply-To: <1399989170.01.0.911856918297.issue21496@psf.upfronthosting.co.za> Message-ID: <1467886079.3.0.274026683836.issue21496@psf.upfronthosting.co.za> Attila-Mihaly Balazs added the comment: Hello, A scenario where this would be needed (and where you can't just "execute the script with the python from inside the pyvenv" to get it automatically activate) is when running under mod_wsgi. There sometimes it is needed to activate the virtualenv "on the fly" from inside the application.wsgi. Just taking activate_this.py from virtualenv and dropping it into env/bin seems to work nicely, so perhaps that could become the official solution? ---------- nosy: +Attila-Mihaly Balazs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 06:46:23 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 07 Jul 2016 10:46:23 +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: <1467888383.24.0.549918258781.issue17711@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: -pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 08:29:43 2016 From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=) Date: Thu, 07 Jul 2016 12:29:43 +0000 Subject: [issue27461] Optimize PNGs Message-ID: <1467894574.39.0.144098385194.issue27461@psf.upfronthosting.co.za> New submission from Ville Skytt?: Running PNGs through zopflipng makes them smaller, with no drawbacks. This patch was done with zopflipng version 1.0.1 with the -m option, and decreases the in-tree total size size of all *.png by almost 100KiB. $ find -name "*.png" | xargs du -bc | tail -n 1 # before 291101 total $ find -name "*.png" | xargs du -bc | tail -n 1 # after 194639 total ---------- assignee: docs at python components: Documentation files: pngs.patch keywords: patch messages: 269929 nosy: docs at python, scop priority: normal severity: normal status: open title: Optimize PNGs type: enhancement Added file: http://bugs.python.org/file43653/pngs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 08:31:58 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 07 Jul 2016 12:31:58 +0000 Subject: [issue27461] Optimize PNGs In-Reply-To: <1467894574.39.0.144098385194.issue27461@psf.upfronthosting.co.za> Message-ID: <1467894718.46.0.389725054736.issue27461@psf.upfronthosting.co.za> STINNER Victor added the comment: Hi, The idea is interesting, but IMO it would be more efficient to contribute to Sphinx, so all documentations will benefit of smallest pictures. There is a similar tool for JPEG. Victor ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 08:36:17 2016 From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=) Date: Thu, 07 Jul 2016 12:36:17 +0000 Subject: [issue27461] Optimize PNGs In-Reply-To: <1467894574.39.0.144098385194.issue27461@psf.upfronthosting.co.za> Message-ID: <1467894977.08.0.529081636581.issue27461@psf.upfronthosting.co.za> Ville Skytt? added the comment: Sure, I plan to suggest this to sphinx as well. One corresponding tool for JPEGs is jpegoptim and its --strip-all option, but there is only ./Mac/BuildScript/resources/background.jpg in the cpython source tree (which despite of the .jpg extension appears to be a PNG file so I don't want to touch that stuff), plus ./Lib/test/imghdrdata/python.jpg which isn't worth a patch alone :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 08:38:03 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 07 Jul 2016 12:38:03 +0000 Subject: [issue27461] Optimize PNGs In-Reply-To: <1467894574.39.0.144098385194.issue27461@psf.upfronthosting.co.za> Message-ID: <1467895083.67.0.387549014689.issue27461@psf.upfronthosting.co.za> STINNER Victor added the comment: > there is only ./Mac/BuildScript/resources/background.jpg in the cpython source tree (which despite of the .jpg extension appears to be a PNG file so I don't want to touch that stuff) Oh funny, you're right: it's a PNG file :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 09:14:44 2016 From: report at bugs.python.org (Jim Fulton) Date: Thu, 07 Jul 2016 13:14:44 +0000 Subject: [issue27456] TCP_NODELAY In-Reply-To: <1467732468.65.0.201519937735.issue27456@psf.upfronthosting.co.za> Message-ID: <1467897284.77.0.582366383764.issue27456@psf.upfronthosting.co.za> Jim Fulton added the comment: I missed the point that you can get a transport's socket using get_extra_info. IMO, this provides an adequate escape from the default and qualifies as a "proper way to set it". I still think the default should be to enable TCP_NODELAY. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 09:32:11 2016 From: report at bugs.python.org (Petr Viktorin) Date: Thu, 07 Jul 2016 13:32:11 +0000 Subject: [issue27332] Clinic: first parameter for module-level functions should be PyObject*, not PyModuleDef* In-Reply-To: <1466094813.1.0.702835277792.issue27332@psf.upfronthosting.co.za> Message-ID: <1467898331.11.0.531066295408.issue27332@psf.upfronthosting.co.za> Petr Viktorin added the comment: Hello, Is there anything I can do to help get this issue resolved? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 10:23:04 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 07 Jul 2016 14:23:04 +0000 Subject: [issue27332] Clinic: first parameter for module-level functions should be PyObject*, not PyModuleDef* In-Reply-To: <1466094813.1.0.702835277792.issue27332@psf.upfronthosting.co.za> Message-ID: <1467901384.48.0.120093562884.issue27332@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. Thank you for your contribution Petr. ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka stage: -> commit review type: -> behavior versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 10:32:42 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 07 Jul 2016 14:32:42 +0000 Subject: [issue23710] C API doc for PyObject_HEAD is outdated In-Reply-To: <1426776099.01.0.644113037586.issue23710@psf.upfronthosting.co.za> Message-ID: <1467901962.43.0.5065342703.issue23710@psf.upfronthosting.co.za> R. David Murray added the comment: Warnings are big red boxes, and we try to only use those for really critical info. The current text is what we want as far as that goes. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 10:43:39 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 07 Jul 2016 14:43:39 +0000 Subject: [issue27442] expose the Android API level in sysconfig.get_config_vars() In-Reply-To: <1467471175.35.0.000904857777026.issue27442@psf.upfronthosting.co.za> Message-ID: <1467902619.15.0.535346315511.issue27442@psf.upfronthosting.co.za> Xavier de Gaye added the comment: In sysconfig.parse_config_h(), the variables in pyconfig.h that have a commented-out '#undef' line are set to 0. Fortunately, there is no Android API level 0. Checking '== 0' ensures that autoreconf has been run to add '#undef ANDROID_API_LEVEL' to pyconfig.h.in. If this autoreconf step were to be missed, the test would (correctly) fail on the buildbots that are not Android as get_config_var() would return None then and the test would not be skipped and fail. Most of the tests in the Python test suite do check 'not sysconfig.get_config_var()' instead, except: Lib/test/test_cmath.py|543 col 22| @unittest.skipIf(sysconfig.get_config_var('TANH_PRESERVES_ZERO_SIGN') == 0, "system tanh() function doesn't copy the sign") Lib/test/test_math.py|978 col 22| @unittest.skipIf(sysconfig.get_config_var('TANH_PRESERVES_ZERO_SIGN') == 0, "system tanh() function doesn't copy the sign") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 10:48:47 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 07 Jul 2016 14:48:47 +0000 Subject: [issue27442] expose the Android API level in sysconfig.get_config_vars() In-Reply-To: <1467471175.35.0.000904857777026.issue27442@psf.upfronthosting.co.za> Message-ID: <1467902927.04.0.0753642380979.issue27442@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > Are you generating the patch using "hg diff"? I don't see the base revision in your patch, and so there is no [Review] link on your patch. I am using 'hg diff' with ~/.hgrc set to 'git = on' and this time, naively removed the '--git' from the output of 'hg diff' instead of commenting out 'git = on' in the config file :( (not finding any reference explaining why this setting is wrong for Rietveld). I will change that to have 'git = on' always commented out. The Python Developer?s Guide in section '16.1. Minimal Configuration' recommends setting 'git = on'. Since we are switching to git shortly, it is probably not very useful to enter a new issue to update the Guide explaining that this setting must not be used when producing patches to be reviewed by Rietveld because the base revision is missing in this case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 11:20:44 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 07 Jul 2016 15:20:44 +0000 Subject: [issue27332] Clinic: first parameter for module-level functions should be PyObject*, not PyModuleDef* In-Reply-To: <1466094813.1.0.702835277792.issue27332@psf.upfronthosting.co.za> Message-ID: <20160707152040.16045.75962.EAA2F6E9@psf.io> Roundup Robot added the comment: New changeset 870e02f86e08 by Serhiy Storchaka in branch '3.5': Issue #27332: Fixed the type of the first argument of module-level functions https://hg.python.org/cpython/rev/870e02f86e08 New changeset c80054ccbbd8 by Serhiy Storchaka in branch 'default': - Issue #27332: Fixed the type of the first argument of module-level functions https://hg.python.org/cpython/rev/c80054ccbbd8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 11:21:19 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 07 Jul 2016 15:21:19 +0000 Subject: [issue27332] Clinic: first parameter for module-level functions should be PyObject*, not PyModuleDef* In-Reply-To: <1466094813.1.0.702835277792.issue27332@psf.upfronthosting.co.za> Message-ID: <1467904879.24.0.45250616558.issue27332@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 Thu Jul 7 11:31:52 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 07 Jul 2016 15:31:52 +0000 Subject: [issue22198] Odd floor-division corner case In-Reply-To: <1408034861.79.0.503776123394.issue22198@psf.upfronthosting.co.za> Message-ID: <1467905512.84.0.990630398386.issue22198@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 11:48:13 2016 From: report at bugs.python.org (Emin Ghuliev) Date: Thu, 07 Jul 2016 15:48:13 +0000 Subject: [issue27462] NULL Pointer deref in binary_iop1 function Message-ID: <1467906493.58.0.790114894121.issue27462@psf.upfronthosting.co.za> New submission from Emin Ghuliev: Python VM parses "0x3b" opcode (INPLACE_MODULO) in the bytecode file. Subsequently VM parses left and right arguments of the opcode (0x3b). If left and right arguments doesn't exists in the bytecode file that causes a segmentation fault. Which triggered by the binary_iop1 function. PyEval_EvalFrameEx() at Python/ceval.c:1749 TARGET(INPLACE_MODULO) { PyObject *right = POP(); PyObject *left = TOP(); PyObject *mod = PyNumber_InPlaceRemainder(left, right); < left = 0, right = 0; Then INPLACE_MODULO opcode is passed two arguments into PyNumber_InPlaceRemainder. However, in order to call the binary_iop: PyNumber_InPlaceRemainder at Objects/abstract.c:1102 PyNumber_InPlaceRemainder(PyObject *v, PyObject *w) { return binary_iop(v, w, NB_SLOT(nb_inplace_remainder), NB_SLOT(nb_remainder), "%="); } Subsequently the binary_iop function is passed "v" argument into the binary_iop1: binary_iop at Objects/abstract.c:1005 static PyObject * binary_iop(PyObject *v, PyObject *w, const int iop_slot, const int op_slot, const char *op_name) { PyObject *result = binary_iop1(v, w, iop_slot, op_slot); # v = 0 and call the binary_iop1 function if (result == Py_NotImplemented) { Py_DECREF(result); return binop_type_error(v, w, op_name); } return result; } binary_iop1 at Objects/abstract.c:988 static PyObject * binary_iop1(PyObject *v, PyObject *w, const int iop_slot, const int op_slot) { PyNumberMethods *mv = v->ob_type->tp_as_number; // dereference object < -- > v = 0x0 if (mv != NULL) { binaryfunc slot = NB_BINOP(mv, iop_slot); if (slot) { PyObject *x = (slot)(v, w); if (x != Py_NotImplemented) { return x; } Py_DECREF(x); } } return binary_op1(v, w, op_slot); } The binary_iop1 function doesn't check "v" field and dereference it. mov rsi,QWORD PTR [rdi+0x8] = 0x8 byte -> ob_type $rdi register = 0x0 Program received signal SIGSEGV, Segmentation fault. ---------- components: Interpreter Core files: repro messages: 269940 nosy: Emin Ghuliev priority: normal severity: normal status: open title: NULL Pointer deref in binary_iop1 function versions: Python 3.6 Added file: http://bugs.python.org/file43654/repro _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 11:51:19 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 07 Jul 2016 15:51:19 +0000 Subject: [issue7769] SimpleXMLRPCServer.SimpleXMLRPCServer.register_function as decorator In-Reply-To: <1264337326.51.0.913533963705.issue7769@psf.upfronthosting.co.za> Message-ID: <1467906679.26.0.571209771889.issue7769@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I don't have an opinion about needing this feature. But for accepting it needs more documenting. The signature should be updated, the new feature should be documented in the main text, not only in the versionchanged note. Needed examples of using egister_function as decorator. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 11:51:44 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 07 Jul 2016 15:51:44 +0000 Subject: [issue27462] NULL Pointer deref in binary_iop1 function In-Reply-To: <1467906493.58.0.790114894121.issue27462@psf.upfronthosting.co.za> Message-ID: <1467906704.93.0.468110055809.issue27462@psf.upfronthosting.co.za> R. David Murray added the comment: Are you saying python generated an invalid bytecode file? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 12:01:24 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 07 Jul 2016 16:01:24 +0000 Subject: [issue27434] cross-building python 3.6 with an older interpreter fails In-Reply-To: <1467378022.01.0.957641757812.issue27434@psf.upfronthosting.co.za> Message-ID: <20160707160116.14434.43287.1439F0B4@psf.io> Roundup Robot added the comment: New changeset 62802d373e9f by Xavier de Gaye in branch 'default': Issue #27434: Version of interpreter running a cross-build and source version must be the same. https://hg.python.org/cpython/rev/62802d373e9f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 12:03:38 2016 From: report at bugs.python.org (Emin Ghuliev) Date: Thu, 07 Jul 2016 16:03:38 +0000 Subject: [issue27462] NULL Pointer deref in binary_iop1 function In-Reply-To: <1467906493.58.0.790114894121.issue27462@psf.upfronthosting.co.za> Message-ID: <1467907418.61.0.333912583645.issue27462@psf.upfronthosting.co.za> Emin Ghuliev added the comment: Nope, invalid bytecode file generated by fuzzer for the purpose of bug researching. Just python doesn't determine whether a variable is empty or valid. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 12:04:17 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 07 Jul 2016 16:04:17 +0000 Subject: [issue27434] cross-building python 3.6 with an older interpreter fails In-Reply-To: <1467378022.01.0.957641757812.issue27434@psf.upfronthosting.co.za> Message-ID: <1467907457.26.0.858917693948.issue27434@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 Thu Jul 7 12:07:27 2016 From: report at bugs.python.org (Izaak Weiss) Date: Thu, 07 Jul 2016 16:07:27 +0000 Subject: [issue27463] Floor division is not the same as the floor of division Message-ID: <1467907647.78.0.993210644564.issue27463@psf.upfronthosting.co.za> New submission from Izaak Weiss: The floor division operator in Python 3 `x//y` acts differently than the floor of the division operator `math.floor(x/y)` in some edge cases due to floating point errors. Consider `44//4.4` and `math.floor(44/4.4)`. These two expressions should, with infinite precision, evaluate to the same number. However, in practice `44//4.4` evaluates to `9.0`, but `math.floor(44/4.4)` evaluates to `10.0`. This should either be changed, or made clear in the documentation that the two may not be equal due to floating point errors. ---------- messages: 269945 nosy: izaakweiss priority: normal severity: normal status: open title: Floor division is not the same as the floor of division type: behavior versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 12:11:53 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 07 Jul 2016 16:11:53 +0000 Subject: [issue27462] NULL Pointer deref in binary_iop1 function In-Reply-To: <1467906493.58.0.790114894121.issue27462@psf.upfronthosting.co.za> Message-ID: <1467907913.03.0.616088882416.issue27462@psf.upfronthosting.co.za> R. David Murray added the comment: Well, unless you can find a way to reproduce it with python code, it isn't interesting to us. ---------- resolution: -> not a bug status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 12:20:13 2016 From: report at bugs.python.org (Emin Ghuliev) Date: Thu, 07 Jul 2016 16:20:13 +0000 Subject: [issue27462] NULL Pointer deref in binary_iop1 function In-Reply-To: <1467906493.58.0.790114894121.issue27462@psf.upfronthosting.co.za> Message-ID: <1467908413.73.0.956939358914.issue27462@psf.upfronthosting.co.za> Changes by Emin Ghuliev : ---------- resolution: not a bug -> wont fix status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 12:23:04 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Thu, 07 Jul 2016 16:23:04 +0000 Subject: [issue27463] Floor division is not the same as the floor of division In-Reply-To: <1467907647.78.0.993210644564.issue27463@psf.upfronthosting.co.za> Message-ID: <1467908584.22.0.167032147367.issue27463@psf.upfronthosting.co.za> Steven D'Aprano added the comment: The behaviour of both are correct: the binary float nearest to 4.4 is just a smidgen *bigger* than the exact decimal 4.4, so 44//4.4 truncates to 9.0. But floor(44/4.4) evaluates 44/4.4 first, and that rounds rather than truncating, giving 10.0, which then floors to 10. If you want to propose a documentation patch, that will be considered, but keep in mind that the Python docs cannot and should not be the place to document all the hairy corners of floating point arithmetic. ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 12:27:54 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 07 Jul 2016 16:27:54 +0000 Subject: [issue27463] Floor division is not the same as the floor of division In-Reply-To: <1467907647.78.0.993210644564.issue27463@psf.upfronthosting.co.za> Message-ID: <1467908874.56.0.0840849270295.issue27463@psf.upfronthosting.co.za> R. David Murray added the comment: I see Steven beat me to posting, but I'll post this anyway since it addresses the existing documentation. Those are already documented as being two different operations. // is "floor" in the sense (as documented in https://docs.python.org/3/reference/expressions.html#binary-arithmetic-operations): x == (x//y) + (x%y) or, more clearly, divmod(x, y) = (x//y, x%y) math.floor(x/y), on the other hand, is doing the floating point division first, and then taking the floor. Different operations, and thus, given floating point realities, different results are not surprising (at least to me...maybe I'm naive? :) Is this worth an additional documentation note of some sort? I'm not sure, I'll defer to Mark. ---------- nosy: +mark.dickinson, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 12:29:11 2016 From: report at bugs.python.org (Tim Peters) Date: Thu, 07 Jul 2016 16:29:11 +0000 Subject: [issue27463] Floor division is not the same as the floor of division In-Reply-To: <1467907647.78.0.993210644564.issue27463@psf.upfronthosting.co.za> Message-ID: <1467908951.93.0.0258554081905.issue27463@psf.upfronthosting.co.za> Tim Peters added the comment: Note that the same is true in Python 2. I don't want to document it, though. In `math.floor(44/4.4)`, the subexpression `44/4.4` by itself wholly rules out that "[as if] with infinite precision [throughout the larger expression]" may be in play. `44/4.4` rounds to 10.0 regardless of the context it appears in. It's just a universal fact about how float arithmetic works, and no more surprising than that, e.g., float addition isn't always associative. Which may mean "very surprising" to many brand new to float arithmetic, but it's not the job of the Python docs to give basic tutorials. ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 12:31:57 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 07 Jul 2016 16:31:57 +0000 Subject: [issue27463] Floor division is not the same as the floor of division In-Reply-To: <1467907647.78.0.993210644564.issue27463@psf.upfronthosting.co.za> Message-ID: <1467909117.76.0.791661397906.issue27463@psf.upfronthosting.co.za> R. David Murray added the comment: That's good enough for me. Closing. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 12:52:32 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 07 Jul 2016 16:52:32 +0000 Subject: [issue27139] Increased test coverage for statistics.median_grouped In-Reply-To: <1464446645.63.0.403096467331.issue27139@psf.upfronthosting.co.za> Message-ID: <20160707165229.4891.66002.9DE2E45B@psf.io> Roundup Robot added the comment: New changeset 4c4f8b0c5b30 by Steven D'Aprano in branch 'default': Issue27139 patch by Julio C Cardoza. https://hg.python.org/cpython/rev/4c4f8b0c5b30 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 13:24:45 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 07 Jul 2016 17:24:45 +0000 Subject: [issue7769] SimpleXMLRPCServer.SimpleXMLRPCServer.register_function as decorator In-Reply-To: <1264337326.51.0.913533963705.issue7769@psf.upfronthosting.co.za> Message-ID: <1467912285.43.0.414671935274.issue7769@psf.upfronthosting.co.za> Xiang Zhang added the comment: >From the old comments from Brian it seems he's willing to accept such a feature. But unfortunately Brian seems not interested in this now. IMHO, this is good feature especially to people familiar with Bottle and Flask. Writing in a decorator way seems more elegant to me. Nevertheless, add more doc. ---------- Added file: http://bugs.python.org/file43655/issue7769_with_more_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 13:27:16 2016 From: report at bugs.python.org (Neil Schemenauer) Date: Thu, 07 Jul 2016 17:27:16 +0000 Subject: [issue27377] Add smarter socket.fromfd() In-Reply-To: <1466706816.6.0.72770597716.issue27377@psf.upfronthosting.co.za> Message-ID: <1467912436.65.0.494184919222.issue27377@psf.upfronthosting.co.za> Neil Schemenauer added the comment: Adding yet another revised patch. I think this is ready to commit, if someone would like to do it. The documentation for constants can be added as a separate commit, if Martin wants. I think the generic SO_* style documentation is okay. Changes in this version: - fix documentation wording - add tests for different protocol types It would be really good(TM) if someone could test this on other platforms. I only tested on vanilla Debian Linux 3.16.0. ---------- Added file: http://bugs.python.org/file43656/fromfd2_v4.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 13:38:11 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 07 Jul 2016 17:38:11 +0000 Subject: [issue27442] expose the Android API level in sysconfig.get_config_vars() In-Reply-To: <1467471175.35.0.000904857777026.issue27442@psf.upfronthosting.co.za> Message-ID: <1467913091.53.0.0328739841246.issue27442@psf.upfronthosting.co.za> Berker Peksag added the comment: > I am using 'hg diff' with ~/.hgrc set to 'git = on' and this time, naively removed the '--git' from the output of 'hg diff' instead of commenting out 'git = on' in the config file :( You don't need to do that. I've been using the same setting [1] for 5 years without having a single problem. If you have a fresh clone of https://hg.python.org/cpython/ and using the 'default' branch, you're good. [1] [diff] git = True showfunc = True unified = 8 ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 14:16:34 2016 From: report at bugs.python.org (Ammar Askar) Date: Thu, 07 Jul 2016 18:16:34 +0000 Subject: [issue23710] C API doc for PyObject_HEAD is outdated In-Reply-To: <1426776099.01.0.644113037586.issue23710@psf.upfronthosting.co.za> Message-ID: <1467915394.8.0.597478163634.issue23710@psf.upfronthosting.co.za> Ammar Askar added the comment: >The current text is what we want as far as that goes. Roger that, I've reverted the change to make that a warning in the newest diff. ---------- Added file: http://bugs.python.org/file43657/capidocs.diff-2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 14:46:49 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 07 Jul 2016 18:46:49 +0000 Subject: [issue23710] C API doc for PyObject_HEAD is outdated In-Reply-To: <1426776099.01.0.644113037586.issue23710@psf.upfronthosting.co.za> Message-ID: <1467917209.91.0.720562976442.issue23710@psf.upfronthosting.co.za> R. David Murray added the comment: Looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 15:15:58 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 07 Jul 2016 19:15:58 +0000 Subject: [issue25507] IDLE: user code 'import tkinter; tkinter.font' should fail In-Reply-To: <1446113442.78.0.389498275803.issue25507@psf.upfronthosting.co.za> Message-ID: <1467918958.32.0.254469530384.issue25507@psf.upfronthosting.co.za> Terry J. Reedy added the comment: According to https://stackoverflow.com/questions/38249755/tkinter-not-working-in-cmd-working-in-idle, this code from tkinter import filedialog root = Tk() ran in 3.4.3. After the patch for 3.5.1 (and 3.4.4, 2.7.11) it raises NameError in 3.5.2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 16:24:03 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 07 Jul 2016 20:24:03 +0000 Subject: [issue27442] expose the Android API level in sysconfig.get_config_vars() In-Reply-To: <1467471175.35.0.000904857777026.issue27442@psf.upfronthosting.co.za> Message-ID: <1467923043.03.0.748968767253.issue27442@psf.upfronthosting.co.za> STINNER Victor added the comment: + @unittest.skipIf(sysconfig.get_config_var('ANDROID_API_LEVEL') == 0, + "not an android platform") + def test_is_android(self): + # Use an heuristic, the shell on Android is at /system/bin/sh. + proc = subprocess.run(['/system/bin/sh', '-c', 'echo OK'], + stdout=subprocess.PIPE) + self.assertIn(b'OK', proc.stdout) I dislike such functional test, it might fail and might need maintaince. I suggest to push the change without the unit test. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 17:52:50 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 07 Jul 2016 21:52:50 +0000 Subject: [issue27220] Add a pure Python version of 'collections.defaultdict' In-Reply-To: <1465060064.38.0.412706275461.issue27220@psf.upfronthosting.co.za> Message-ID: <1467928370.65.0.00464078355939.issue27220@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I don't think there is any advantage to adding a pure python version of defaultdict (or we would have done it a long time ago). Each time we do this, it creates a host of downstream issues where people notice minor implementation differences between the two. ---------- priority: normal -> low resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 18:03:57 2016 From: report at bugs.python.org (Emanuel Barry) Date: Thu, 07 Jul 2016 22:03:57 +0000 Subject: [issue27220] Add a pure Python version of 'collections.defaultdict' In-Reply-To: <1465060064.38.0.412706275461.issue27220@psf.upfronthosting.co.za> Message-ID: <1467929037.85.0.861058694846.issue27220@psf.upfronthosting.co.za> Emanuel Barry added the comment: I agree that CPython itself gains nothing from having this, as this is so that alternate implementations have it as well. I get what you mean about the minor differences, however I think it's a good thing, as it helps to make sure the tests are precise enough so that there can't be any differences (but that's probably just me). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 18:13:05 2016 From: report at bugs.python.org (Emanuel Barry) Date: Thu, 07 Jul 2016 22:13:05 +0000 Subject: [issue27220] Add a pure Python version of 'collections.defaultdict' In-Reply-To: <1465060064.38.0.412706275461.issue27220@psf.upfronthosting.co.za> Message-ID: <1467929585.19.0.354110985462.issue27220@psf.upfronthosting.co.za> Emanuel Barry added the comment: (Also, if this is going to be rejected still, I think that fixing __all__ to only conditionally add 'deque' and 'defaultdict' should be considered) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 18:24:31 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 07 Jul 2016 22:24:31 +0000 Subject: [issue27442] expose the Android API level in sysconfig.get_config_vars() In-Reply-To: <1467471175.35.0.000904857777026.issue27442@psf.upfronthosting.co.za> Message-ID: <1467930271.85.0.618891313963.issue27442@psf.upfronthosting.co.za> Xavier de Gaye added the comment: @Berker This does not work for me. I found an old discussion [1] on the git format problem with Rietveld. The thread diverges rapidly toward another subject, "submitting a branch instead of a patch to the issue tracker" but comes back to the original subject at the end. It seems that "not including the base changeset id in the --git diff is an oversight" of mercurial that has never been fixed. [1] http://grokbase.com/t/python/python-dev/1135q4xxa8/hg-diff ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 18:26:47 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 07 Jul 2016 22:26:47 +0000 Subject: [issue27442] expose the Android API level in sysconfig.get_config_vars() In-Reply-To: <1467471175.35.0.000904857777026.issue27442@psf.upfronthosting.co.za> Message-ID: <1467930407.31.0.348101451393.issue27442@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > I suggest to push the change without the unit test. Agreed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 19:42:36 2016 From: report at bugs.python.org (Mikhail Korobov) Date: Thu, 07 Jul 2016 23:42:36 +0000 Subject: [issue27464] Document that SplitResult & friends are namedtuples Message-ID: <1467934956.52.0.328129985005.issue27464@psf.upfronthosting.co.za> New submission from Mikhail Korobov: Docs currently say that urllib.parse.SplitResult is a subclass of tuple, without saying that it is namedtuple. What do you think about documenting it as a namedtuple? It has an useful _replace method which allows to change some part of URL before passing it to urlunsplit. It may also require updating typeshed - I noticed this issue because mypy shows an error when SplitResult._replace is used. ---------- messages: 269964 nosy: kmike priority: normal severity: normal status: open title: Document that SplitResult & friends are namedtuples _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 21:58:46 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 08 Jul 2016 01:58:46 +0000 Subject: [issue27465] IDLE:Make help source menu entries unique and sorted. Message-ID: <1467943126.13.0.718896019337.issue27465@psf.upfronthosting.co.za> New submission from Terry J. Reedy: The 'General' tab of the IDLE configuration menu allows a user to add entries to the Help menu that display a text when clicked. A user might want more than one text available for a given 'topic', such as a doc and how-to for a package. However, there is no need to have duplicate entries, as up to 30 chars are allowed. "Package - doc" and "Package - how" would be clearer than "Package" and "Package". Issue 27380 makes checking for unique entries easy as that is already done for user configuration file section names and the same base class is now used for help source names. Currently, names are displayed in the order added. I believe sorting would be better, especially when one adds more than 2 entries. That should also be easy. Existing duplicates would not be a problem for IDLE as the check would only apply when adding or editing an item. Python's stable list.sort would keep existing duplicates in the same relative order. I will *not* use the doc path to break ties. ---------- assignee: terry.reedy messages: 269965 nosy: terry.reedy priority: normal severity: normal stage: test needed status: open title: IDLE:Make help source menu entries unique and sorted. type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 22:10:03 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 08 Jul 2016 02:10:03 +0000 Subject: [issue27465] IDLE:Make help source menu entries unique and sorted. In-Reply-To: <1467943126.13.0.718896019337.issue27465@psf.upfronthosting.co.za> Message-ID: <1467943803.14.0.872739080125.issue27465@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The IDLE doc currently says "Additional help sources may be added here with the Configure IDLE dialog under the General tab." Revise to something like Additional help sources Menu items for display here are added on the General tap of Options => Configure IDLE. Menu entries should be unique (new in 3.6) and will be sorted. Documents can be located either on the current machine or on the internet. The allowed file types may depend on the system. Local file paths are checked when submitted; internet addresses are not. ---------- dependencies: +IDLE: add base Query dialog with ttk widgets _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 22:37:12 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 08 Jul 2016 02:37:12 +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: <1467945432.79.0.711257437624.issue27380@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Serhiy, thank you for the review. I intend to follow PEP 8 as best as possible in the code I touch. I also fixed some of the comments. I did a bit of refactoring that make it trivial to check for reuse of help source names. See new issue #27465. All that is needed is for configdialog to pass a used_names argument. I already changed the HelpSource htest to do so. I have tested the configdialog changes by running it with live IDLE. I intend to push after a final check. ---------- Added file: http://bugs.python.org/file43658/query-helpsource2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 7 23:24:20 2016 From: report at bugs.python.org (Robby Daigle) Date: Fri, 08 Jul 2016 03:24:20 +0000 Subject: [issue27466] [Copy from github user macartur] time2netscape missing comma Message-ID: <1467948260.35.0.112204143726.issue27466@psf.upfronthosting.co.za> New submission from Robby Daigle: For the time2netscape function. expected: Wed, DD-Mon-YYYY HH:MM:SS GMT got: Wed DD-Mon-YYYY HH:MM:SS GMT In Lib/http/cookiejar.py, line 116 suggests that the format should include a comma while line 123 does not include the comma in the formatted string. Wondering if 116 or 123 is wrong. ---------- components: Library (Lib) hgrepos: 347 messages: 269968 nosy: Robby Daigle priority: normal severity: normal status: open title: [Copy from github user macartur] time2netscape missing comma 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 Jul 8 00:05:12 2016 From: report at bugs.python.org (Evelyn Mitchell) Date: Fri, 08 Jul 2016 04:05:12 +0000 Subject: [issue27466] [Copy from github user macartur] time2netscape missing comma In-Reply-To: <1467948260.35.0.112204143726.issue27466@psf.upfronthosting.co.za> Message-ID: <1467950712.15.0.707770224891.issue27466@psf.upfronthosting.co.za> Evelyn Mitchell added the comment: http://web.archive.org/web/19990128171928/http://www51.netscape.com/newsref/std/cookie_spec.html says: The date string is formatted as: Wdy, DD-Mon-YYYY HH:MM:SS GMT so the comma should be there. ---------- nosy: +efm _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 00:16:32 2016 From: report at bugs.python.org (Joe) Date: Fri, 08 Jul 2016 04:16:32 +0000 Subject: [issue27467] distutils.config API different between <=3.5.1 and 3.5.2 Message-ID: <1467951392.72.0.939570638824.issue27467@psf.upfronthosting.co.za> New submission from Joe: In Python 3k releases leading up to 3.5.2, distutils.config imported "ConfigParser", but now imports "RawConfigParser" in the latest release. The documentation indicates "RawConfigParser" is considered legacy and "ConfigParser" should be used in its place. Was this change intentional, and if not, will it be reverted to the previous behavior for the next patch release? Thanks, Joe ---------- components: Distutils messages: 269970 nosy: dstufft, eric.araujo, jhunkeler priority: normal severity: normal status: open title: distutils.config API different between <=3.5.1 and 3.5.2 type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 00:25:26 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 08 Jul 2016 04:25:26 +0000 Subject: [issue27466] [Copy from github user macartur] time2netscape missing comma In-Reply-To: <1467948260.35.0.112204143726.issue27466@psf.upfronthosting.co.za> Message-ID: <1467951926.01.0.483268364812.issue27466@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Evelyn, Thanks for digging in. The code for time2netscape has been in the current form since it was originally introduced in 2004. If this is a bug, then it has been present since the introduction of the module. If anyone is using this module, they are probably relying the existing behavior. The spec you pointed out says that this is a bug. The bug fix can go in 2.7, 3.5 and 3.6 releases. ---------- nosy: +orsenthil versions: -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 00:26:35 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 08 Jul 2016 04:26:35 +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: <20160708042632.14672.34738.861B6AA0@psf.io> Roundup Robot added the comment: New changeset 66fe8d9eae6c by Terry Jan Reedy in branch 'default': Issue #27380: IDLE: add query.HelpSource class and tests. https://hg.python.org/cpython/rev/66fe8d9eae6c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 00:32:00 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 08 Jul 2016 04:32:00 +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: <1467952320.41.0.316000744092.issue27380@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Patch posted had code that belongs to #27465 and was deleted before pushing. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 01:16:09 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 08 Jul 2016 05:16:09 +0000 Subject: [issue27466] [Copy from github user macartur] time2netscape missing comma In-Reply-To: <1467948260.35.0.112204143726.issue27466@psf.upfronthosting.co.za> Message-ID: <1467954969.63.0.0659004570754.issue27466@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Here is the patch that fixes this issue. Patch includes unittests and NEWS entry. ---------- assignee: -> orsenthil keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file43659/issue27466.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 03:07:07 2016 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 08 Jul 2016 07:07:07 +0000 Subject: [issue27467] distutils.config API different between <=3.5.1 and 3.5.2 In-Reply-To: <1467951392.72.0.939570638824.issue27467@psf.upfronthosting.co.za> Message-ID: <1467961627.71.0.662065998889.issue27467@psf.upfronthosting.co.za> Xiang Zhang added the comment: I think it's intentional. You can see issue20120. ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 03:08:34 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 08 Jul 2016 07:08:34 +0000 Subject: [issue27467] distutils.config API different between <=3.5.1 and 3.5.2 In-Reply-To: <1467951392.72.0.939570638824.issue27467@psf.upfronthosting.co.za> Message-ID: <1467961713.99.0.124258586852.issue27467@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report. Yes, the RawConfigParser change was intentional and it was discussed in issue 20120. I'm marking this as a documentation issue. ---------- assignee: -> docs at python components: +Documentation nosy: +berker.peksag, docs at python stage: -> needs patch versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 03:12:57 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 08 Jul 2016 07:12:57 +0000 Subject: [issue11027] Implement sectionxform in configparser In-Reply-To: <1296139025.05.0.619488294513.issue11027@psf.upfronthosting.co.za> Message-ID: <1467961977.19.0.817604759168.issue11027@psf.upfronthosting.co.za> Berker Peksag added the comment: Issue 26537 is a duplicate of this one but it has an up-to-date and more complete patch so I'm going to close this one. ---------- nosy: +berker.peksag resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> ConfigParser has optionxform, but not sectionxform _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 03:22:38 2016 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 08 Jul 2016 07:22:38 +0000 Subject: [issue27467] distutils.config API different between <=3.5.1 and 3.5.2 In-Reply-To: <1467951392.72.0.939570638824.issue27467@psf.upfronthosting.co.za> Message-ID: <1467962558.98.0.958442717793.issue27467@psf.upfronthosting.co.za> Xiang Zhang added the comment: Berker, what doc needs to be changed? Although RawConfigParser is legacy but that does not mean it's deprecated, right? We can still use it although the doc suggests us use ConfigParser. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 03:37:59 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 08 Jul 2016 07:37:59 +0000 Subject: [issue27467] distutils.config API different between <=3.5.1 and 3.5.2 In-Reply-To: <1467951392.72.0.939570638824.issue27467@psf.upfronthosting.co.za> Message-ID: <1467963479.84.0.812742564345.issue27467@psf.upfronthosting.co.za> Berker Peksag added the comment: I was thinking to document issue 20120 in Misc/NEWS. It turns out I was looking at the wrong commit and it was already documented in eae59b6bf133. ---------- resolution: -> not a bug stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 04:19:25 2016 From: report at bugs.python.org (Stefan Krah) Date: Fri, 08 Jul 2016 08:19:25 +0000 Subject: [issue27442] expose the Android API level in sysconfig.get_config_vars() In-Reply-To: <1467471175.35.0.000904857777026.issue27442@psf.upfronthosting.co.za> Message-ID: <1467965965.54.0.373025737392.issue27442@psf.upfronthosting.co.za> Changes by Stefan Krah : Added file: http://bugs.python.org/file43660/issue27442-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 04:23:14 2016 From: report at bugs.python.org (Stefan Krah) Date: Fri, 08 Jul 2016 08:23:14 +0000 Subject: [issue27442] expose the Android API level in sysconfig.get_config_vars() In-Reply-To: <1467471175.35.0.000904857777026.issue27442@psf.upfronthosting.co.za> Message-ID: <1467966194.9.0.292370173625.issue27442@psf.upfronthosting.co.za> Stefan Krah added the comment: I did "hg pull -u" before re-generating the diff. Other than that, sometimes newer mercurial versions behave better (I have 2.8.2). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 04:32:39 2016 From: report at bugs.python.org (SilentGhost) Date: Fri, 08 Jul 2016 08:32:39 +0000 Subject: [issue27464] Document that SplitResult & friends are namedtuples In-Reply-To: <1467934956.52.0.328129985005.issue27464@psf.upfronthosting.co.za> Message-ID: <1467966759.89.0.61657693585.issue27464@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python stage: -> needs patch versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 05:39:49 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 08 Jul 2016 09:39:49 +0000 Subject: [issue27442] expose the Android API level in sysconfig.get_config_vars() In-Reply-To: <1467471175.35.0.000904857777026.issue27442@psf.upfronthosting.co.za> Message-ID: <1467970789.47.0.0385081563723.issue27442@psf.upfronthosting.co.za> STINNER Victor added the comment: issue27442-3.patch: be careful, the new item in Misc/NEWS is not at the top of its section. Moreover, I still consider that the unit test is risky and not really needed (just remove it). Good job, there is now a [review] button :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 06:01:17 2016 From: report at bugs.python.org (Stefan Krah) Date: Fri, 08 Jul 2016 10:01:17 +0000 Subject: [issue27442] expose the Android API level in sysconfig.get_config_vars() In-Reply-To: <1467471175.35.0.000904857777026.issue27442@psf.upfronthosting.co.za> Message-ID: <1467972077.13.0.932236179939.issue27442@psf.upfronthosting.co.za> Stefan Krah added the comment: Good point about Misc/NEWS: I just regenerated the patch mindlessly to check the "diff --git" situation :) Actually, Xavier, it's often better to leave out the NEWS section in the bug tracker patches and just add it before pushing. Perhaps Rietveld choked on the NEWS file before because it's constantly changing? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 07:03:23 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Fri, 08 Jul 2016 11:03:23 +0000 Subject: [issue20446] ipaddress: hash similarities for ipv4 and ipv6 In-Reply-To: <1391086928.1.0.694997709579.issue20446@psf.upfronthosting.co.za> Message-ID: <1467975803.53.0.356492448144.issue20446@psf.upfronthosting.co.za> ???? ????????? added the comment: See also issue20446 ---------- nosy: +mmarkk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 07:03:43 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Fri, 08 Jul 2016 11:03:43 +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: <1467975823.46.0.0259653835675.issue27269@psf.upfronthosting.co.za> ???? ????????? added the comment: see also issue20446 ---------- nosy: +mmarkk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 07:03:53 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Fri, 08 Jul 2016 11:03:53 +0000 Subject: [issue20446] ipaddress: hash similarities for ipv4 and ipv6 In-Reply-To: <1391086928.1.0.694997709579.issue20446@psf.upfronthosting.co.za> Message-ID: <1467975833.56.0.458331361424.issue20446@psf.upfronthosting.co.za> ???? ????????? added the comment: Sorry. See also issue27269 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 07:09:38 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Fri, 08 Jul 2016 11:09:38 +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: <1467976178.71.0.482056820263.issue27269@psf.upfronthosting.co.za> ???? ????????? added the comment: Also, it should be marked explicitly, if cross-type lookup is safe. I mean code like that: some_net = ipaddress.ip_network(some_input1) some_addr = ipaddress.ip_address(some_input2) return some_addr in some_net Is it safe to write such code? Docs say: 21.28.2.3. Operators Address objects support some operators. Unless stated otherwise, operators can only be applied between compatible objects (i.e. IPv4 with IPv4, IPv6 with IPv6). 1. It is not said if exception will be raised if incompatible objects are used, and not said if result is defined. 2. "Unless stated otherwise" - Seem it is stated nowhere. ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 10:43:16 2016 From: report at bugs.python.org (Oren Milman) Date: Fri, 08 Jul 2016 14:43:16 +0000 Subject: [issue27441] redundant assignments to ob_size of new ints that _PyLong_New returned In-Reply-To: <1467470337.8.0.776341442151.issue27441@psf.upfronthosting.co.za> Message-ID: <1467988996.21.0.860681274549.issue27441@psf.upfronthosting.co.za> Oren Milman added the comment: I am sorry, but I can't see why micro-benchmarking is needed here, as my patches only remove code that does nothing, while they don't add any new code. The assembly the compiler generates (on my PC) for 'Py_SIZE(v) = negative ? -ndigits : ndigits;' in PyLong_FromLongLong is: ('[edx+8]' is 'Py_SIZE(v)', '[esp+10h+var_4]' is 'negative', The 'lea ecx, [edx+0Ch]' and 'mov eax, edi' instructions set ecx and eax for later (I haven't removed them in order to be as precise as possible.)) ... cmp [esp+10h+var_4], 0 lea ecx, [edx+0Ch] jz short loc_1E0D48EC neg ebx loc_1E0D48EC: mov eax, edi mov [edx+8], ebx ... In contrast, the assembly the compiler generates for 'if (negative) Py_SIZE(v) = -ndigits;' is: ... cmp [esp+10h+var_4], 0 lea ecx, [edx+0Ch] jz short loc_1E0D482F neg ebx mov [edx+8], ebx loc_1E0D482F: mov eax, edi ... Comparing the assembly generated for the other original '?:' expressions with my corresponding patches looks quite the same. Each patch moves the assignment from code which is executed in both of the flows, to code which is executed in only one of the flows. Am I missing anything that might cause my patches to introduce a performance penalty? I searched (all of the cpython repo) for other places in which Py_SIZE() is set to the same value, and indeed found one in Objects/longobject.c in _PyLong_Init: The loop that initializes the small_ints array goes over every element in the array, and checks whether it was already initialized. For some reason, even when it realizes the current element was already initialized, it still sets 'Py_SIZE(v)' and 'v->ob_digit[0]' (to the values they are already set to). These redundant assignments were first added in changeset 45072 (https://hg.python.org/cpython/rev/f183f1189824), and remained there to this day. So I added a patch to move these assignments so they would be executed only in case the current element of small_ints wasn't already initialized. The updated patches diff file is attached. I also ran the tests again, and got quite the same output (the output is attached). Have you spotted any other places in which Py_SIZE() is set to the same value? ---------- Added file: http://bugs.python.org/file43661/issue27441_ver2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 10:43:36 2016 From: report at bugs.python.org (Oren Milman) Date: Fri, 08 Jul 2016 14:43:36 +0000 Subject: [issue27441] redundant assignments to ob_size of new ints that _PyLong_New returned In-Reply-To: <1467470337.8.0.776341442151.issue27441@psf.upfronthosting.co.za> Message-ID: <1467989016.46.0.735205262493.issue27441@psf.upfronthosting.co.za> Changes by Oren Milman : Added file: http://bugs.python.org/file43662/patchedCPythonTestOutput_ver2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 10:54:31 2016 From: report at bugs.python.org (Adria Garriga) Date: Fri, 08 Jul 2016 14:54:31 +0000 Subject: [issue27468] Erroneous memory behaviour for objects created in another thread Message-ID: <1467989671.36.0.557850749029.issue27468@psf.upfronthosting.co.za> New submission from Adria Garriga: I create several objects in the main thread, and then spawn several threads that "take ownership" of one object each. Within that thread, the objects' attributes' values are not consistent. The bug only happens sometimes. from threading import Thread import pdb n_threads = 8 def f(self): self.obj[0] = 0 t = 0 while True: if t != self.obj[0]: pdb.set_trace() # should not happen t += 1 self.obj[0] += 1 for _ in range(n_threads): t = Thread(target=lambda: f(t)) t.obj = [0] t.start() Tested in Python 2.7.11 under Ubuntu 16.04 LTS and OS X. The bug does not happen in Python 3.5 or Python 3.6 . Attached is a very similar program that exhibits the same issue, but which may be clearer and can sometimes be killed with Ctrl-C. ---------- components: Library (Lib) files: test.py messages: 269988 nosy: Adria Garriga priority: normal severity: normal status: open title: Erroneous memory behaviour for objects created in another thread type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file43663/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 10:54:59 2016 From: report at bugs.python.org (Robby Daigle) Date: Fri, 08 Jul 2016 14:54:59 +0000 Subject: [issue27466] [Copy from github user macartur] time2netscape missing comma In-Reply-To: <1467948260.35.0.112204143726.issue27466@psf.upfronthosting.co.za> Message-ID: <1467989699.37.0.571470792418.issue27466@psf.upfronthosting.co.za> Robby Daigle added the comment: Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 10:55:17 2016 From: report at bugs.python.org (Adria Garriga) Date: Fri, 08 Jul 2016 14:55:17 +0000 Subject: [issue27468] Erroneous memory behaviour for objects created in another thread In-Reply-To: <1467989671.36.0.557850749029.issue27468@psf.upfronthosting.co.za> Message-ID: <1467989717.79.0.45363508208.issue27468@psf.upfronthosting.co.za> Changes by Adria Garriga : Removed file: http://bugs.python.org/file43663/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 11:23:05 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 08 Jul 2016 15:23:05 +0000 Subject: [issue22624] Bogus usage of floatclock in timemodule In-Reply-To: <1413225295.8.0.611582673071.issue22624@psf.upfronthosting.co.za> Message-ID: <1467991385.97.0.726395889276.issue22624@psf.upfronthosting.co.za> STINNER Victor added the comment: Sorry but the Wii console is not supported. You have to maintain your fork/patch. Python 3 don't support platforms without clock(). ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 11:38:52 2016 From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=) Date: Fri, 08 Jul 2016 15:38:52 +0000 Subject: [issue27469] Unicode filename gets crippled on Windows when drag and drop Message-ID: <1467992332.72.0.0240653508758.issue27469@psf.upfronthosting.co.za> New submission from Adam Barto?: When a Python script is run by drag-and-dropping another file on it in Windows explorer, the other file's path becomes sys.argv[1]. However, when the path contains a Unicode characters (e.g. ?), it gets crippled ? it is replaced by ordinary question mark. Maybe this is not Python's fault. Calling directly GetCommandLineW already contains that question mark. I'm just curious whether the original path even can be reconstructed. ---------- components: Unicode, Windows messages: 269991 nosy: Drekin, ezio.melotti, haypo, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Unicode filename gets crippled on Windows when drag and drop type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 11:40:59 2016 From: report at bugs.python.org (Emanuel Barry) Date: Fri, 08 Jul 2016 15:40:59 +0000 Subject: [issue27469] Unicode filename gets crippled on Windows when drag and drop In-Reply-To: <1467992332.72.0.0240653508758.issue27469@psf.upfronthosting.co.za> Message-ID: <1467992459.34.0.232514588434.issue27469@psf.upfronthosting.co.za> Changes by Emanuel Barry : ---------- nosy: +ebarry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 11:52:10 2016 From: report at bugs.python.org (Keno Fischer) Date: Fri, 08 Jul 2016 15:52:10 +0000 Subject: [issue17213] ctypes loads wrong version of C runtime, leading to error message box from system In-Reply-To: <1360992800.86.0.617349310494.issue17213@psf.upfronthosting.co.za> Message-ID: <1467993130.12.0.832791214868.issue17213@psf.upfronthosting.co.za> Keno Fischer added the comment: pyzmq has a similar issue. I believe one solution would be to call `_Py_ActivateActCtx` in ctypes' load_library, i.e. do ``` #if HAVE_SXS ULONG_PTR cookie = _Py_ActivateActCtx(); #endif hMod = LoadLibraryW(name); #if HAVE_SXS _Py_DeactivateActCtx(cookie); #endif ``` in that function. I don't know enough about python or ctypes to say whether this patch works as is (_Py_ActivateActCtx seems to be an internal function, not sure if ctypes has access to that). ---------- nosy: +Keno Fischer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 11:55:55 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 08 Jul 2016 15:55:55 +0000 Subject: [issue22624] Bogus usage of floatclock in timemodule In-Reply-To: <1413225295.8.0.611582673071.issue22624@psf.upfronthosting.co.za> Message-ID: <20160708155550.14470.24555.5173D086@psf.io> Roundup Robot added the comment: New changeset 1452520dfe7b by Victor Stinner in branch 'default': Issue #22624: Python 3 requires clock() to build https://hg.python.org/cpython/rev/1452520dfe7b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 12:23:05 2016 From: report at bugs.python.org (Matthew Gilson) Date: Fri, 08 Jul 2016 16:23:05 +0000 Subject: [issue27470] -3 commandline option documented differently via man Message-ID: <1467994985.16.0.513883147731.issue27470@psf.upfronthosting.co.za> New submission from Matthew Gilson: The man page for python says: > Warn about Python 3.x incompatibilities that 2to3 cannot trivially fix. The official documentation (https://docs.python.org/2/using/cmdline.html#cmdoption-3) does not mention 2to3 at all: > Warn about Python 3.x possible incompatibilities by emitting a DeprecationWarning for features that are removed or significantly changed in Python 3. This seems like a pretty big oversight when the following code issues no warnings (presumably because 2to3 can trivially handle this change): ``` from __future__ import print_function class test(object): def __nonzero__(self): return False t = test() if t: print('Hello') ``` ---------- assignee: docs at python components: Documentation messages: 269994 nosy: docs at python, mgilson priority: normal severity: normal status: open title: -3 commandline option documented differently via man versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 12:24:28 2016 From: report at bugs.python.org (Peter Otten) Date: Fri, 08 Jul 2016 16:24:28 +0000 Subject: [issue27468] Erroneous memory behaviour for objects created in another thread In-Reply-To: <1467989671.36.0.557850749029.issue27468@psf.upfronthosting.co.za> Message-ID: <1467995068.91.0.214107071346.issue27468@psf.upfronthosting.co.za> Peter Otten added the comment: Your code relies on the assumption that when the lambda is invoked the global t is still bound to the Thread instance you are starting. It seems that this is not always the case, and I don't see why it should be guaranteed either. I don't know whether it's a good idea to store per-thread data in the Thread instance (have a look at threading.local()), but def start_thread(): t = Thread(target=lambda: f(t)) t.obj = [0] t.start() for _ in range(n_threads): start_thread() will at least avoid the global. ---------- nosy: +peter.otten _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 12:31:32 2016 From: report at bugs.python.org (Adria Garriga) Date: Fri, 08 Jul 2016 16:31:32 +0000 Subject: [issue27468] Erroneous memory behaviour for objects created in another thread In-Reply-To: <1467989671.36.0.557850749029.issue27468@psf.upfronthosting.co.za> Message-ID: <1467995492.06.0.0259701021492.issue27468@psf.upfronthosting.co.za> Adria Garriga added the comment: Yes, that seems to be it. Storing info in the Thread object is just for the sake of keeping the example short, but the error is the same you pointed out. Thank you very much and I hope I didn't waste too much of your time! ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 12:41:42 2016 From: report at bugs.python.org (Emanuel Barry) Date: Fri, 08 Jul 2016 16:41:42 +0000 Subject: [issue27468] Erroneous memory behaviour for objects created in another thread In-Reply-To: <1467989671.36.0.557850749029.issue27468@psf.upfronthosting.co.za> Message-ID: <1467996102.57.0.149027333307.issue27468@psf.upfronthosting.co.za> Changes by Emanuel Barry : ---------- resolution: -> not a bug stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 13:46:33 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 08 Jul 2016 17:46:33 +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: <20160708174626.15465.64135.85DA4CE9@psf.io> Roundup Robot added the comment: New changeset 414f67e000a7 by Brett Cannon in branch 'default': Issue #27285: Document the deprecation of the pyvenv script. https://hg.python.org/cpython/rev/414f67e000a7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 13:47:30 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 08 Jul 2016 17:47:30 +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: <1468000050.05.0.223468009131.issue27285@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks for the patch, Steve! I went ahead and got this done now when I realized your patch touched so many files, thus waiting could lead to skew and the need to update the patch needlessly. ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 14:00:08 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 08 Jul 2016 18:00:08 +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: <20160708180005.5017.2998.C2650920@psf.io> Roundup Robot added the comment: New changeset c65f34dafcc1 by Brett Cannon in branch 'default': Issue #26896: Disambiguate uses of "importer" with "finder". https://hg.python.org/cpython/rev/c65f34dafcc1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 14:00:40 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 08 Jul 2016 18:00: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: <1468000840.49.0.926108178965.issue26896@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks for the patch, Oren! Only change I made was deleting the lines you commented out in the tests. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 14:09:42 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 08 Jul 2016 18:09:42 +0000 Subject: [issue26972] mistakes in docstrings in the import machinery In-Reply-To: <1462637766.06.0.0379757360626.issue26972@psf.upfronthosting.co.za> Message-ID: <20160708180939.16214.46490.50A0668D@psf.io> Roundup Robot added the comment: New changeset d32517de5d8c by Brett Cannon in branch 'default': Issue #26972: Fix some mistakes in importlib-related docstrings. https://hg.python.org/cpython/rev/d32517de5d8c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 14:10:52 2016 From: report at bugs.python.org (A. Skrobov) Date: Fri, 08 Jul 2016 18:10:52 +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: <1468001452.29.0.804223061578.issue26415@psf.upfronthosting.co.za> A. Skrobov added the comment: Fixing whitespace in the patch, and including an update for the docs ---------- Added file: http://bugs.python.org/file43664/patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 14:11:10 2016 From: report at bugs.python.org (A. Skrobov) Date: Fri, 08 Jul 2016 18:11:10 +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: <1468001470.04.0.965308032383.issue26415@psf.upfronthosting.co.za> Changes by A. Skrobov : Added file: http://bugs.python.org/file43665/devguide_patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 14:11:18 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 08 Jul 2016 18:11:18 +0000 Subject: [issue26972] mistakes in docstrings in the import machinery In-Reply-To: <1462637766.06.0.0379757360626.issue26972@psf.upfronthosting.co.za> Message-ID: <1468001478.68.0.470426777133.issue26972@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks for the patch, Oren! The only real change I made was to make sure the the one-sentence summary at the start of the docstring fit on a single line (when it spans line it can muck up editors and tools). ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 14:15:05 2016 From: report at bugs.python.org (Steve Piercy) Date: Fri, 08 Jul 2016 18:15:05 +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: <1468001705.63.0.929879750868.issue27285@psf.upfronthosting.co.za> Steve Piercy added the comment: Thank you! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 15:18:04 2016 From: report at bugs.python.org (Oren Milman) Date: Fri, 08 Jul 2016 19:18:04 +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: <1468005484.39.0.748335368242.issue20842@psf.upfronthosting.co.za> Oren Milman added the comment: Note that http://bugs.python.org/issue26896 is now closed (the patches proposed in it (with some minor changes) were committed). ---------- nosy: +Oren Milman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 15:20:44 2016 From: report at bugs.python.org (Oren Milman) Date: Fri, 08 Jul 2016 19:20:44 +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: <1468005644.46.0.931439779484.issue26896@psf.upfronthosting.co.za> Oren Milman added the comment: That's awesome! Thanks :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 15:38:07 2016 From: report at bugs.python.org (Daniel Holth) Date: Fri, 08 Jul 2016 19:38:07 +0000 Subject: [issue25435] Wrong function calls and referring to not removed concepts in descriptor HowTo (documentation) In-Reply-To: <1445194189.09.0.0973348556564.issue25435@psf.upfronthosting.co.za> Message-ID: <1468006687.12.0.926056715879.issue25435@psf.upfronthosting.co.za> Daniel Holth added the comment: This bit me also. Is there other documentation for how many arguments MethodType() should take? ---------- nosy: +dholth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 16:00:55 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 08 Jul 2016 20:00:55 +0000 Subject: [issue27442] expose the Android API level in sysconfig.get_config_vars() In-Reply-To: <1467471175.35.0.000904857777026.issue27442@psf.upfronthosting.co.za> Message-ID: <1468008055.64.0.418163046566.issue27442@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Thanks Berker and Stefan for your help on 'hg diff --git'. Yes Stefan, maybe your patch has a [review] button because Rietveld found that your patch applied cleanly against the head of the default branch at the time you have submitted it, so it could guess the base revision while mines were submitted late, or rather without a 'hg pull -u' right before the submission ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 17:27:23 2016 From: report at bugs.python.org (Eryk Sun) Date: Fri, 08 Jul 2016 21:27:23 +0000 Subject: [issue27469] Unicode filename gets crippled on Windows when drag and drop In-Reply-To: <1467992332.72.0.0240653508758.issue27469@psf.upfronthosting.co.za> Message-ID: <1468013243.98.0.619398990825.issue27469@psf.upfronthosting.co.za> Eryk Sun added the comment: Nothing can be done about this from Python. It's a bug in how Explorer handles the dropped filename. Note that it's not simply replacing Unicode characters with question marks. It's using a best-fit ANSI encoding. For example, codepage 1252 maps "?" to "A". If there's no defined best-fit mapping, most codepages default to using "?" as the replacement character when encoding via WideCharToMultiByte. When decoding via MultiByteToWideChar, some codepages (e.g. 932), use katakana middle dot (U+30FB) as the default instead of a question mark. For example, here's the commandline of py.exe when I drop a file named "?.txt" on a script. Note that "?" becomes "A": 0:000> ?? @$peb->ProcessParameters->CommandLine struct _UNICODE_STRING ""C:\Windows\py.exe" "C:\Temp\test.py" C:\Temp\A.txt " +0x000 Length : 0x68 +0x002 MaximumLength : 0x6a +0x004 Buffer : 0x00771d50 ""C:\Windows\py.exe" "C:\Temp\test.py" C:\Temp\A.txt " It's bizarre that it encodes the filename as ANSI just to decode it later when it calls CreateProcess. But Explorer probably still has a lot old code from back when it had to run on both Windows NT and DOS-based Windows 9x. This is probably a vestige of some workaround. It isn't a problem if you ShellExecuteEx the Python script. For example, I ran "C:\Temp\test.py C:\Temp\?.txt" in the command prompt, and here's the resulting command line: 0:000> ?? @$peb->ProcessParameters->CommandLine struct _UNICODE_STRING ""C:\Windows\py.exe" "C:\Temp\test.py" C:\Temp\?.txt" +0x000 Length : 0x68 +0x002 MaximumLength : 0x6a +0x004 Buffer : 0x00981cf8 ""C:\Windows\py.exe" "C:\Temp\test.py" C:\Temp\?.txt" Explorer actually handles drag and drop correctly when dropping the file on another window. So as a (clunky) workaround, you can drag the script icon into a command prompt or Win+R run dialog, and then drag the target file. The shell should add quotes where required. ---------- nosy: +eryksun resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 17:57:07 2016 From: report at bugs.python.org (Noah Petherbridge) Date: Fri, 08 Jul 2016 21:57:07 +0000 Subject: [issue27471] sre_constants.error: bad escape \d Message-ID: <1468015027.73.0.234433787808.issue27471@psf.upfronthosting.co.za> New submission from Noah Petherbridge: I found a bug in Python 3.6.0a2 that wasn't present on previous versions of Python concerning the "\d" escape sequence as used in the following regular expression: import re s = "hello" s = re.sub(re.escape(r'(\d+?)'), '(?:\d+?)', s) (The purpose of this regular expression was to translate the literal regexp string "(\d+?)" to be a non-capturing literal regexp string, to eventually be used as a re pattern). When running this code in 3.6.0a2 I receive the following stack traces: - - - - - - - - - - Traceback (most recent call last): File "/home/kirsle/.pyenv/versions/3.6.0a2/lib/python3.6/sre_parse.py", line 877, in parse_template this = chr(ESCAPES[this][1]) KeyError: '\\d' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "test.py", line 4, in s = re.sub(re.escape(r'(\d+?)'), '(?:\d+?)', s) File "/home/kirsle/.pyenv/versions/3.6.0a2/lib/python3.6/re.py", line 181, in sub return _compile(pattern, flags).sub(repl, string, count) File "/home/kirsle/.pyenv/versions/3.6.0a2/lib/python3.6/re.py", line 324, in _subx template = _compile_repl(template, pattern) File "/home/kirsle/.pyenv/versions/3.6.0a2/lib/python3.6/re.py", line 311, in _compile_repl p = sre_parse.parse_template(repl, pattern) File "/home/kirsle/.pyenv/versions/3.6.0a2/lib/python3.6/sre_parse.py", line 880, in parse_template raise s.error('bad escape %s' % this, len(this)) sre_constants.error: bad escape \d at position 3 - - - - - - - - - - However, the script runs without crashing on Python 3.5.1 and 2.7.11 % python --version Python 3.6.0a2 ---------- components: Regular Expressions messages: 270010 nosy: Noah Petherbridge, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: sre_constants.error: bad escape \d type: crash versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 18:30:12 2016 From: report at bugs.python.org (Matthew Barnett) Date: Fri, 08 Jul 2016 22:30:12 +0000 Subject: [issue27471] sre_constants.error: bad escape \d In-Reply-To: <1468015027.73.0.234433787808.issue27471@psf.upfronthosting.co.za> Message-ID: <1468017012.13.0.270073746649.issue27471@psf.upfronthosting.co.za> Matthew Barnett added the comment: There's a move to treat invalid escape sequences as an error (see issue 27364). The previous behaviour was to treat them as literals. The replacement template string contains \d, which is not a valid escape sequence (it's valid for the pattern, but not the template). ---------- type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 18:33:57 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 08 Jul 2016 22:33:57 +0000 Subject: [issue27471] sre_constants.error: bad escape \d In-Reply-To: <1468015027.73.0.234433787808.issue27471@psf.upfronthosting.co.za> Message-ID: <1468017237.26.0.898119460824.issue27471@psf.upfronthosting.co.za> R. David Murray added the comment: It's just supposed to be a warning at this point, though, so this looks like a bug. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 18:51:12 2016 From: report at bugs.python.org (Stefan Krah) Date: Fri, 08 Jul 2016 22:51:12 +0000 Subject: [issue27442] expose the Android API level in sysconfig.get_config_vars() In-Reply-To: <1467471175.35.0.000904857777026.issue27442@psf.upfronthosting.co.za> Message-ID: <1468018272.23.0.530658635133.issue27442@psf.upfronthosting.co.za> Stefan Krah added the comment: I guess so. Our Rietveld setup apparently has some heuristics that work best when you're on the default branch and completely synced with the main repo. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 19:01:12 2016 From: report at bugs.python.org (Eryk Sun) Date: Fri, 08 Jul 2016 23:01:12 +0000 Subject: [issue25435] Wrong function calls and referring to not removed concepts in descriptor HowTo (documentation) In-Reply-To: <1445194189.09.0.0973348556564.issue25435@psf.upfronthosting.co.za> Message-ID: <1468018872.59.0.649514514082.issue25435@psf.upfronthosting.co.za> Eryk Sun added the comment: I'm surprised it's not documented for the types module: https://docs.python.org/3.5/library/types.html#types.MethodType At least the docstring has the parameters: >>> print(types.MethodType.__doc__) method(function, instance) Create a bound instance method object. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 21:57:37 2016 From: report at bugs.python.org (Connor Wolf) Date: Sat, 09 Jul 2016 01:57:37 +0000 Subject: [issue6721] Locks in the standard library should be sanitized on fork In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za> Message-ID: <1468029457.94.0.329598739589.issue6721@psf.upfronthosting.co.za> Connor Wolf added the comment: Is anything happening with these fixes? This is still an issue (I'm running into it now)? ---------- nosy: +Connor.Wolf _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 23:13:11 2016 From: report at bugs.python.org (Eryk Sun) Date: Sat, 09 Jul 2016 03:13:11 +0000 Subject: [issue27469] Unicode filename gets crippled on Windows when drag and drop In-Reply-To: <1467992332.72.0.0240653508758.issue27469@psf.upfronthosting.co.za> Message-ID: <1468033991.91.0.605743876938.issue27469@psf.upfronthosting.co.za> Eryk Sun added the comment: On second thought, it occurred to me that the problem isn't in Explorer or shell32, but in the drop handler. It turns out the problem is that the drop handler calls the ANSI API DragQueryFileA instead of DragQueryFileW. To see this I attached a debugger to Explorer and set a breakpoint on shell32!DragQueryFileA: Breakpoint 0 hit SHELL32!DragQueryFileA: 00007ffd`bed1a5b0 4883ec38 sub rsp,38h 0:056> k 3 Child-SP RetAddr Call Site 00000000`0ee3e0f8 00007ffd`b2c95b7a SHELL32!DragQueryFileA 00000000`0ee3e100 00007ffd`bedade2e wshext!CWSHExtension::Drop+0x7a 00000000`0ee3e300 00007ffd`bed9d547 SHELL32!CDVDropTarget::_PerformDrop+0x14a Note that the shell is deferring to the drop handler for the file type, which in our case is implemented by wshext.dll. The first DragQueryFileA call is to query the number of files (i.e. iFile == 0xFFFFFFFF): 0:056> r rdx rdx=00000000ffffffff 0:056> g The 2nd call gets the ANSI encoded filename: Breakpoint 0 hit SHELL32!DragQueryFileA: 00007ffd`bed1a5b0 4883ec38 sub rsp,38h 0:056> r r8 r8=000000000ee3e1a0 0:056> pt; da ee3e1a0 00000000`0ee3e1a0 "C:\Temp\A.txt" The drop handler is set in the Python.File ProgId, which is defined in the installer in Tools/msi/launcher/launcher_reg.wxs, which configures the following registry entry: C:\>reg query HKLM\Software\Classes\Python.File\shellex\DropHandler HKEY_LOCAL_MACHINE\Software\Classes\Python.File\shellex\DropHandler (Default) REG_SZ {60254CA5-953B-11CF-8C96-00AA00B8708C} As we previously saw in the stack trace, it's implemented by wshext.dll: C:\>reg query HKLM\Software\Classes\CLSID\{60254CA5-953B-11CF-8C96-00AA00B8708C} /s HKEY_LOCAL_MACHINE\Software\Classes\CLSID\{60254CA5-953B-11CF-8C96-00AA00B8708C} (Default) REG_SZ Shell Extension For Windows Script Host HKEY_LOCAL_MACHINE\Software\Classes\CLSID\{60254CA5-953B-11CF-8C96-00AA00B8708C}\InProcServer32 (Default) REG_SZ C:\Windows\System32\wshext.dll ThreadingModel REG_SZ Apartment I thought I could fix this easily by switching to the drop handler that batfile and exefile use: C:\>reg add HKLM\Software\Classes\Python.File\shellex\DropHandler /ve /d ^ More? {86C86720-42A0-1069-A2E8-08002B30309D} Value exists, overwrite(Yes/No)? y The operation completed successfully. This gets the Unicode filename right, but when I move "?.txt" to a directory under "Program Files", I see that it uses short filenames in the path. ['C:\\PROGRA~1\\Python35\\?.txt'] Is that acceptable? ---------- resolution: third party -> stage: resolved -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 23:19:21 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 09 Jul 2016 03:19:21 +0000 Subject: [issue6721] Locks in the standard library should be sanitized on fork In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za> Message-ID: <1468034361.28.0.579791346323.issue6721@psf.upfronthosting.co.za> Gregory P. Smith added the comment: For me the momentum on fixing these things has stalled because I no longer work on any code that runs into this. There is a fundamental problem: You cannot safely use threading and os.fork() in the same application per POSIX rules. So even if the standard library and interpreter to tried to force its locks into some sort of consistent state post os.fork(), the much more fundamental POSIX problem remains. IMNSHO, working on "fixes" for this issue while ignoring the larger application design flaw elephant in the room doesn't make a lot of sense. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 23:46:16 2016 From: report at bugs.python.org (Connor Wolf) Date: Sat, 09 Jul 2016 03:46:16 +0000 Subject: [issue6721] Locks in the standard library should be sanitized on fork In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za> Message-ID: <1468035976.16.0.386906032249.issue6721@psf.upfronthosting.co.za> Connor Wolf added the comment: > IMNSHO, working on "fixes" for this issue while ignoring the larger application design flaw elephant in the room doesn't make a lot of sense. I understand the desire for a canonically "correct" fix, but it seems the issue with fixing it "correctly" has lead to the /actual/ implementation being broken for at least 6 years now. As it is, my options are: A. Rewrite the many, many libraries I use that internally spawn threads. B. Not use multiprocessing. (A) is prohibitive from a time perspective (I don't even know how many libraries I'd have to rewrite!), and (B) means I'd get 1/24-th of my VMs performance, so it's somewhat prohibitive. At the moment, I've thrown together a horrible, horrible fix where I reach into the logging library (which is where I'm seeing deadlocks), and manually iterate over all attached log managers, resetting the locks in each immediately when each process spawns. This is, I think it can be agreed, a horrible, horrible hack, but in my particular case it works (the worst case result is garbled console output for a line or two). --- If a canonical fix is not possible, at least add a facility to the threading fork() call that lets the user decide what to do. In my case, my program is wedging in the logging system, and I am entirely OK with having transiently garbled logs, if it means I don't wind up deadlocking and having to force kill the interpreter (which is, I think, far /more/ destructive an action). If I could basically do `multiprocessing.Process(*args, *kwargs, _clear_locks=True)`, that would be entirely sufficient, and not change existing behaviour at all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 8 23:47:53 2016 From: report at bugs.python.org (Connor Wolf) Date: Sat, 09 Jul 2016 03:47:53 +0000 Subject: [issue6721] Locks in the standard library should be sanitized on fork In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za> Message-ID: <1468036073.59.0.143502959307.issue6721@psf.upfronthosting.co.za> Connor Wolf added the comment: Arrrgh, s/threading/multiprocessing/g in my last message. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 00:03:23 2016 From: report at bugs.python.org (lesha) Date: Sat, 09 Jul 2016 04:03:23 +0000 Subject: [issue6721] Locks in the standard library should be sanitized on fork In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za> Message-ID: <1468037003.19.0.0105235949925.issue6721@psf.upfronthosting.co.za> lesha added the comment: I work on a multi-million-line C++ codebase that uses fork() from multithreaded programs all over the place. We use `glog` ubiquitously. This bug here that spans 6 years and has affected dozens of people (conservatively) simply does not exist for us. That is because glog takes the pragmatic approach of sanitizing its mutex on fork: https://github.com/google/glog/blob/4d391fe692ae6b9e0105f473945c415a3ce5a401/src/base/mutex.h#L249 In my opinion, "thou shalt never fork() in a threaded program" is impractical purism. It is good to be aware of the dangers that lie therein, but it is completely possible to safely spawn **subprocesses** from multithreaded programs on modern OSes like Linux. Python's subprocess **ought** to be safe to use in threaded programs. Any issues with this (aside from `pre_exec_fn`, obviously) are bugs in `subprocess`. Here is a C++ implementation of the concept that can be safely used in threaded programs: https://github.com/facebook/folly/blob/master/folly/Subprocess.cpp Note that unlike Python's subprocess `pre_exec_fn`, the C++ analog is very loud in warning you about the scary world in which your closure will execute: https://github.com/facebook/folly/blob/master/folly/Subprocess.h#L252 The point to my message is simple: there is a pragmatic way to save hundreds of debugging hours for users of Python. People are going to find it necessary to do such things from time to time, so instead of telling them to redesign their programs, it is better to give them a safer tool. Taking the glog approach in `logging` has no cost to the standard library, but it does have real world benefits. Please don't block shipping such a fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 00:19:06 2016 From: report at bugs.python.org (lesha) Date: Sat, 09 Jul 2016 04:19:06 +0000 Subject: [issue6721] Locks in the standard library should be sanitized on fork In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za> Message-ID: <1468037946.07.0.200031592454.issue6721@psf.upfronthosting.co.za> lesha added the comment: On a moment's reflection, a lot of my prior comment is wrong. Sorry about that. - glog does not, that I know of, sanitize locks on fork. You just shouldn't log after fork but before exec. - Using `pthread_atfork` to clean up the `logging` lock might be enough to make it safe from the "just forked" context, but without adding fairly exhaustive tests around this logic, it would be fragile with respect to further improvements to `logging`. So even just making this one library safe is a considerable amount of work. So I retract most of my previous opinion. Sorry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 00:21:51 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 09 Jul 2016 04:21:51 +0000 Subject: [issue6721] Locks in the standard library should be sanitized on fork In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za> Message-ID: <1468038111.63.0.36464952447.issue6721@psf.upfronthosting.co.za> Gregory P. Smith added the comment: My intent is not to block anything. I'm Just explaining why I'm not motivated to spend much time on this issue myself. Others are welcome to. subprocess is not related to this issue, it has been fixed for use with threads (in 3.2 and higher) with an extremely widely used drop in replacement back-port for 2.7 https://pypi.python.org/pypi/subprocess32. But even 2.7's poor subprocess implementation never triggered this specific issue in the first place (unless someone logged from a pre_exec_fn which would be a laughable thing to do anyways). multiprocessing: It has spawn (as of 3.4) and forkserver methods both of which can help avoid this issue. Caveats: spawn understandably has negative performance implications and forkserver requires the forkserver to be forked before threads potentially holding locks have been started. As for the gross hacky monkey patching workaround: That was the approach I took in https://github.com/google/python-atfork/blob/master/atfork/stdlib_fixer.py#L51 Definitely a hack, but one that does work on existing interpreters. Conner & lesha: Which Python version(s) are you using? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 00:44:44 2016 From: report at bugs.python.org (Connor Wolf) Date: Sat, 09 Jul 2016 04:44:44 +0000 Subject: [issue6721] Locks in the standard library should be sanitized on fork In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za> Message-ID: <1468039484.83.0.243817345714.issue6721@psf.upfronthosting.co.za> Connor Wolf added the comment: > Python 3.5.1+ (default, Mar 30 2016, 22:46:26) Whatever the stock 3.5 on ubuntu 16.04 x64 is. I've actually been running into a whole horde of really bizarre issues related to what I /think/ is locking in stdout. Basically, I have a context where I have thousands and thousands of (relatively short lived) `multiprocessing.Process()` processes, and over time they all get wedged (basically, I have ~4-32 processes alive at any time, but they all get recycled every few minutes). After doing some horrible (https://github.com/fake-name/ReadableWebProxy/blob/master/logSetup.py#L21-L78) hackery in the logging module, I'm not seeing processes get wedged there, but I do still encounter issues with what I can only assume is a lock in the print statement. I'm hooking into a wedged process using [pystuck](https://github.com/alonho/pystuck) durr at rwpscrape:/media/Storage/Scripts/ReadableWebProxy? pystuck --port 6675 Welcome to the pystuck interactive shell. Use the 'modules' dictionary to access remote modules (like 'os', or '__main__') Use the `%show threads` magic to display all thread stack traces. In [1]: show threads <_MainThread(MainThread, started 140574012434176)> File "runScrape.py", line 74, in go() File "runScrape.py", line 57, in go runner.run() File "/media/Storage/Scripts/ReadableWebProxy/WebMirror/Runner.py", line 453, in run living = sum([manager.check_run_jobs() for manager in managers]) File "/media/Storage/Scripts/ReadableWebProxy/WebMirror/Runner.py", line 453, in living = sum([manager.check_run_jobs() for manager in managers]) File "/media/Storage/Scripts/ReadableWebProxy/WebMirror/Runner.py", line 364, in check_run_jobs proc.start() File "/usr/lib/python3.5/multiprocessing/process.py", line 105, in start self._popen = self._Popen(self) File "/usr/lib/python3.5/multiprocessing/context.py", line 212, in _Popen return _default_context.get_context().Process._Popen(process_obj) File "/usr/lib/python3.5/multiprocessing/context.py", line 267, in _Popen return Popen(process_obj) File "/usr/lib/python3.5/multiprocessing/popen_fork.py", line 20, in __init__ self._launch(process_obj) File "/usr/lib/python3.5/multiprocessing/popen_fork.py", line 74, in _launch code = process_obj._bootstrap() File "/usr/lib/python3.5/multiprocessing/process.py", line 249, in _bootstrap self.run() File "/usr/lib/python3.5/multiprocessing/process.py", line 93, in run self._target(*self._args, **self._kwargs) File "/media/Storage/Scripts/ReadableWebProxy/WebMirror/Runner.py", line 145, in run run.go() File "/media/Storage/Scripts/ReadableWebProxy/WebMirror/Runner.py", line 101, in go self.log.info("RunInstance starting!") File "/usr/lib/python3.5/logging/__init__.py", line 1279, in info self._log(INFO, msg, args, **kwargs) File "/usr/lib/python3.5/logging/__init__.py", line 1415, in _log self.handle(record) File "/usr/lib/python3.5/logging/__init__.py", line 1425, in handle self.callHandlers(record) File "/usr/lib/python3.5/logging/__init__.py", line 1487, in callHandlers hdlr.handle(record) File "/usr/lib/python3.5/logging/__init__.py", line 855, in handle self.emit(record) File "/media/Storage/Scripts/ReadableWebProxy/logSetup.py", line 134, in emit print(outstr) File "/usr/lib/python3.5/threading.py", line 882, in _bootstrap self._bootstrap_inner() File "/usr/lib/python3.5/threading.py", line 914, in _bootstrap_inner self.run() File "/usr/lib/python3.5/threading.py", line 862, in run self._target(*self._args, **self._kwargs) File "/usr/local/lib/python3.5/dist-packages/rpyc/utils/server.py", line 241, in start self.accept() File "/usr/local/lib/python3.5/dist-packages/rpyc/utils/server.py", line 128, in accept sock, addrinfo = self.listener.accept() File "/usr/lib/python3.5/socket.py", line 195, in accept fd, addr = self._accept() File "/usr/local/lib/python3.5/dist-packages/pystuck/thread_probe.py", line 15, in thread_frame_generator yield (thread_, frame) So, somehow the print() statement is blocking, which I have /no/ idea how to go about debugging. I assume there's a lock /in/ the print statement function call, and I'm probably going to look into wrapping both the print() call and the multiprocessing.Process() call execution in a single, shared multiprocessing lock, but that seems like a very patchwork solution to something that should just work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 01:23:04 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 09 Jul 2016 05:23:04 +0000 Subject: [issue27471] sre_constants.error: bad escape \d In-Reply-To: <1468015027.73.0.234433787808.issue27471@psf.upfronthosting.co.za> Message-ID: <1468041784.31.0.685006325986.issue27471@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It is a deprection warning in 3.5. $ python3.5 -Wd >>> import re >>> re.sub(re.escape(r'(\d+?)'), '(?:\d+?)', r'(\d+?)') /usr/lib/python3.5/re.py:182: DeprecationWarning: bad escape \d return _compile(pattern, flags).sub(repl, string, count) '(?:\\d+?)' The warning was added in issue23622, and turned into exception in issue27030. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 01:49:17 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Sat, 09 Jul 2016 05:49:17 +0000 Subject: [issue27181] Add geometric mean to `statistics` module In-Reply-To: <1464901494.08.0.0111988914026.issue27181@psf.upfronthosting.co.za> Message-ID: <1468043357.62.0.487484489652.issue27181@psf.upfronthosting.co.za> Steven D'Aprano added the comment: Does anyone have any strong feeling about the name for these functions? gmean and hmean; geometric_mean and harmonic_mean And "subcontrary_mean" is not an option :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 01:57:46 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 09 Jul 2016 05:57:46 +0000 Subject: [issue27181] Add geometric mean to `statistics` module In-Reply-To: <1464901494.08.0.0111988914026.issue27181@psf.upfronthosting.co.za> Message-ID: <1468043866.63.0.158378786888.issue27181@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I would like to see them spelled-out: geometric_mean and harmonic_mean ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 04:01:35 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Sat, 09 Jul 2016 08:01:35 +0000 Subject: [issue27466] [Copy from github user macartur] time2netscape missing comma In-Reply-To: <1467948260.35.0.112204143726.issue27466@psf.upfronthosting.co.za> Message-ID: <1468051295.97.0.59726148669.issue27466@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Fixed the redundant import as pointed by Evelyn on IRC. ---------- Added file: http://bugs.python.org/file43666/issue27466-v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 04:02:15 2016 From: report at bugs.python.org (STINNER Victor) Date: Sat, 09 Jul 2016 08:02:15 +0000 Subject: [issue6721] Locks in the standard library should be sanitized on fork In-Reply-To: <1468039484.83.0.243817345714.issue6721@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: I suggest to close the issue as WONT FIX. Python code base is huge and Python depends on a lot of external code. We cannot warranty anything. It might be possible to track all kinds of locks with an infinite time. But I'm not sure that it's worth it. It is possible to use fork() with threads. The problem is more to execute non trivial code after the fork. In short, the POSIX advices to only call exec() syscall after fork and nothing else. The list of functions which are safe after fork() is very short. You can still use the multiprocessing module using the fork server for example. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 04:50:07 2016 From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=) Date: Sat, 09 Jul 2016 08:50:07 +0000 Subject: [issue27469] Unicode filename gets crippled on Windows when drag and drop In-Reply-To: <1467992332.72.0.0240653508758.issue27469@psf.upfronthosting.co.za> Message-ID: <1468054207.15.0.419505272974.issue27469@psf.upfronthosting.co.za> Adam Barto? added the comment: Thank you very much for the analysis. So Python Windows installers may be changed to set the other drop handler. If the short paths are problem, they may be converted to long ones when initializing `sys.argv`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 04:51:18 2016 From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=) Date: Sat, 09 Jul 2016 08:51:18 +0000 Subject: [issue27469] Unicode filename gets crippled on Windows when drag and drop In-Reply-To: <1467992332.72.0.0240653508758.issue27469@psf.upfronthosting.co.za> Message-ID: <1468054278.61.0.796838854605.issue27469@psf.upfronthosting.co.za> Adam Barto? added the comment: Also, what versions of Windows does this affect? I have 64bit Vista, so maybe this is fixed in say Windows 10. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 05:06:43 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 09 Jul 2016 09:06:43 +0000 Subject: [issue27442] expose the Android API level in sysconfig.get_config_vars() In-Reply-To: <1467471175.35.0.000904857777026.issue27442@psf.upfronthosting.co.za> Message-ID: <20160709090636.59190.82184.A6F21F0B@psf.io> Roundup Robot added the comment: New changeset 46567fda0b29 by Xavier de Gaye in branch 'default': Issue #27442: Expose the Android API level in sysconfig.get_config_vars() https://hg.python.org/cpython/rev/46567fda0b29 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 05:08:13 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sat, 09 Jul 2016 09:08:13 +0000 Subject: [issue26942] android: test_ctypes crashes on armv7 In-Reply-To: <1462290789.53.0.483745295219.issue26942@psf.upfronthosting.co.za> Message-ID: <1468055293.23.0.971199103492.issue26942@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Maybe a libffi issue. The crash is still with libffi git-master and CPython hg-tip + `--with-system-libffi`. Reported to https://github.com/libffi/libffi/issues/262 ---------- nosy: +Chi Hsuan Yen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 05:09:29 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 09 Jul 2016 09:09:29 +0000 Subject: [issue27442] expose the Android API level in sysconfig.get_config_vars() In-Reply-To: <1467471175.35.0.000904857777026.issue27442@psf.upfronthosting.co.za> Message-ID: <1468055369.48.0.69667822322.issue27442@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 Sat Jul 9 05:15:15 2016 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 09 Jul 2016 09:15:15 +0000 Subject: [issue27181] Add geometric mean to `statistics` module In-Reply-To: <1464901494.08.0.0111988914026.issue27181@psf.upfronthosting.co.za> Message-ID: <1468055715.0.0.867474969101.issue27181@psf.upfronthosting.co.za> Mark Dickinson added the comment: > I would like to see them spelled-out: geometric_mean and harmonic_mean +1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 06:50:21 2016 From: report at bugs.python.org (Eryk Sun) Date: Sat, 09 Jul 2016 10:50:21 +0000 Subject: [issue27469] Unicode filename gets crippled on Windows when drag and drop In-Reply-To: <1467992332.72.0.0240653508758.issue27469@psf.upfronthosting.co.za> Message-ID: <1468061421.34.0.882164163416.issue27469@psf.upfronthosting.co.za> Eryk Sun added the comment: Yes, a different drop handler solves the problem. It doesn't have to be the exefile handler that's built into shell32.dll. Another handler could be used that preserves Unicode filenames and long paths. I tested in Windows 10.0.10586. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 07:49:58 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 09 Jul 2016 11:49:58 +0000 Subject: [issue27027] add the 'is_android' attribute to test.support In-Reply-To: <1463307075.8.0.646834682003.issue27027@psf.upfronthosting.co.za> Message-ID: <1468064998.42.0.67343218669.issue27027@psf.upfronthosting.co.za> Xavier de Gaye added the comment: New patch using the changes made in issue 27442. ---------- dependencies: -android: add platform.android_ver() keywords: +needs review -patch stage: -> patch review title: add is_android in test.support to detect Android platform -> add the 'is_android' attribute to test.support Added file: http://bugs.python.org/file43667/is_android_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 07:53:11 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 09 Jul 2016 11:53:11 +0000 Subject: [issue27027] add the 'is_android' attribute to test.support In-Reply-To: <1463307075.8.0.646834682003.issue27027@psf.upfronthosting.co.za> Message-ID: <1468065191.43.0.31510647327.issue27027@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- assignee: -> xdegaye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 08:08:21 2016 From: report at bugs.python.org (Eryk Sun) Date: Sat, 09 Jul 2016 12:08:21 +0000 Subject: [issue17213] ctypes loads wrong version of C runtime, leading to error message box from system In-Reply-To: <1360992800.86.0.617349310494.issue17213@psf.upfronthosting.co.za> Message-ID: <1468066101.7.0.915562484885.issue17213@psf.upfronthosting.co.za> Eryk Sun added the comment: This is only a problem for ctypes when python27.dll is used in an application that isn't manifested to load the "Microsoft.VC90.CRT" assembly. ctypes doesn't have this problem for a regular script run via the 2.7 version of python.exe, since the loader uses the python.exe activation context. Daniel claimed otherwise, but his claim is demonstrably false. Maybe he was embedding Python. Keno, I don't think it's a good idea to arbitrarily set the Python DLL's activation context every time ctypes calls LoadLibrary. I proposed a more generic solution in issue 24429, msg246754. An alternative solution would be to implement a pure-Python activation context class that works as a Python context manager. For example, it could create and activate a context using the hModule and lpResourceName fields: with ctypes.ACTCTX(module_handle=sys.dllhandle, resource_name=2): libc = ctypes.CDLL('msvcr90') I have a Stack Overflow answer that demonstrates using activation contexts with ctypes: http://stackoverflow.com/a/27392347/205580 ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 08:27:41 2016 From: report at bugs.python.org (INADA Naoki) Date: Sat, 09 Jul 2016 12:27:41 +0000 Subject: [issue26081] Implement asyncio Future in C to improve performance In-Reply-To: <1452533022.97.0.443242974791.issue26081@psf.upfronthosting.co.za> Message-ID: <1468067261.69.0.81228404659.issue26081@psf.upfronthosting.co.za> INADA Naoki added the comment: I'm working on this. Some bugs are fixed, but doesn't pass tests for now. https://github.com/methane/cpython/pull/5 ---------- nosy: +methane _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 08:59:51 2016 From: report at bugs.python.org (Steve Dower) Date: Sat, 09 Jul 2016 12:59:51 +0000 Subject: [issue27469] Unicode filename gets crippled on Windows when drag and drop In-Reply-To: <1467992332.72.0.0240653508758.issue27469@psf.upfronthosting.co.za> Message-ID: <1468069191.42.0.17212543714.issue27469@psf.upfronthosting.co.za> Steve Dower added the comment: Try removing the handler completely and see what the default behavior is. Otherwise, I'll do some research and figure out the right one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 09:04:55 2016 From: report at bugs.python.org (John Hagen) Date: Sat, 09 Jul 2016 13:04:55 +0000 Subject: [issue26988] Add AutoNumberedEnum to stdlib In-Reply-To: <1462844071.91.0.106881823757.issue26988@psf.upfronthosting.co.za> Message-ID: <1468069495.64.0.976231532606.issue26988@psf.upfronthosting.co.za> John Hagen added the comment: Is this something we want to get in before the next alpha in two days? Just wanted to bring up the deadline since this may be a feature people want to play around with during the alpha phase. Ethan, I'm happy to help with documentation or anything else. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 09:04:59 2016 From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=) Date: Sat, 09 Jul 2016 13:04:59 +0000 Subject: [issue27469] Unicode filename gets crippled on Windows when drag and drop In-Reply-To: <1467992332.72.0.0240653508758.issue27469@psf.upfronthosting.co.za> Message-ID: <1468069499.52.0.254924637801.issue27469@psf.upfronthosting.co.za> Adam Barto? added the comment: Without a handler the drop feature is disabled. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 09:47:04 2016 From: report at bugs.python.org (Keno Fischer) Date: Sat, 09 Jul 2016 13:47:04 +0000 Subject: [issue17213] ctypes loads wrong version of C runtime, leading to error message box from system In-Reply-To: <1360992800.86.0.617349310494.issue17213@psf.upfronthosting.co.za> Message-ID: <1468072024.28.0.973403572013.issue17213@psf.upfronthosting.co.za> Keno Fischer added the comment: Yes, you are correct about it being only an issue in the embedding context. I agree that it might not be a good idea to do do this for every library, but I wanted to revive the discussion since this kind of thing seems like something that comes up frequently when people embed python. Thanks for the reference to the other thread. A solution that allows the activation context to be specified would be great. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 09:50:52 2016 From: report at bugs.python.org (Steve Dower) Date: Sat, 09 Jul 2016 13:50:52 +0000 Subject: [issue27469] Unicode filename gets crippled on Windows when drag and drop In-Reply-To: <1467992332.72.0.0240653508758.issue27469@psf.upfronthosting.co.za> Message-ID: <1468072252.36.0.565673424775.issue27469@psf.upfronthosting.co.za> Steve Dower added the comment: Okay thanks. I'll see if I can track down the right one on Monday. ---------- assignee: -> steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 09:59:52 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 09 Jul 2016 13:59:52 +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: <1468072792.19.0.757480842678.issue27137@psf.upfronthosting.co.za> Nick Coghlan added the comment: Emanuel's latest patch looks good to me, but after seeing yet another behaviour discrepancy between the two versions(static method vs instance method behaviour), I've proposed disallowing function/class mismatches as an explicit policy clarification in PEP 399: https://mail.python.org/pipermail/python-dev/2016-July/145556.html Since this change can land any time before the first 3.6 beta in September, I'm going to wait and see want kind of responses we get to that thread before merging it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 10:26:24 2016 From: report at bugs.python.org (Christian H) Date: Sat, 09 Jul 2016 14:26:24 +0000 Subject: [issue1222585] C++ compilation support for distutils Message-ID: <1468074384.5.0.623431167497.issue1222585@psf.upfronthosting.co.za> Changes by Christian H : ---------- nosy: +Christian H _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 11:12:35 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 09 Jul 2016 15:12:35 +0000 Subject: [issue27472] add the 'unix_shell' attribute to test.support Message-ID: <1468077155.86.0.151085889776.issue27472@psf.upfronthosting.co.za> New submission from Xavier de Gaye: '/bin/sh' is hard-coded in few places in the test suite, but the Android shell is at '/system/bin/sh', see msg266084. ---------- assignee: xdegaye components: Tests messages: 270044 nosy: xdegaye priority: normal severity: normal stage: needs patch status: open title: add the 'unix_shell' attribute to test.support type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 11:13:45 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 09 Jul 2016 15:13:45 +0000 Subject: [issue27472] add the 'unix_shell' attribute to test.support In-Reply-To: <1468077155.86.0.151085889776.issue27472@psf.upfronthosting.co.za> Message-ID: <1468077225.03.0.436072078139.issue27472@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- dependencies: +add the 'is_android' attribute to test.support _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 11:15:57 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 09 Jul 2016 15:15:57 +0000 Subject: [issue26865] Meta-issue: support of the android platform In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za> Message-ID: <1468077357.49.0.960686048218.issue26865@psf.upfronthosting.co.za> Xavier de Gaye added the comment: issue #27472: add the 'unix_shell' attribute to test.support ---------- dependencies: +add the 'unix_shell' attribute to test.support _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 11:17:47 2016 From: report at bugs.python.org (Jim Fulton) Date: Sat, 09 Jul 2016 15:17:47 +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: <1468077467.29.0.0263589744793.issue27392@psf.upfronthosting.co.za> Jim Fulton added the comment: I'd still like to find a way to handle already accepted server sockets. Can we decide on either: - a server_side flag to create_connection or - A new interface for handling an already accepted socket? I would call this handle_connection, but I'll take any name. :) I'm fine with and willing to implement either alternative. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 11:18:28 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 09 Jul 2016 15:18:28 +0000 Subject: [issue16255] subrocess.Popen needs /bin/sh but Android only has /system/bin/sh In-Reply-To: <1350421202.49.0.905467284446.issue16255@psf.upfronthosting.co.za> Message-ID: <1468077508.73.0.428692193008.issue16255@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > The list of locations where '/bin/sh' is hard coded in the standard library: I have entered issue 27472. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 11:20:16 2016 From: report at bugs.python.org (Ethan Furman) Date: Sat, 09 Jul 2016 15:20:16 +0000 Subject: [issue26988] Add AutoNumberedEnum to stdlib In-Reply-To: <1462844071.91.0.106881823757.issue26988@psf.upfronthosting.co.za> Message-ID: <1468077616.66.0.686812215441.issue26988@psf.upfronthosting.co.za> Ethan Furman added the comment: There is one wrinkle with auto-numbering. Consider the following code: class Color(AutoNumberEnum): red green blue @property def cap_name(self): return self.name.upper() What happens with `property`? - `property` is looked up in the class namespace - it's not found, so is given the number 4 - it's then called to handle `cap_name` - an exception is raised As far as I can tell there is only one "good" way around this: - store any names you don't want auto-numbered into an `_ignore_` attribute (this only needs to be global and built-in names that are used before the first method is defined) another option is to build a proxy around any found global/built-in objects and decide what to do based on whether those objects are immediately called, but that fails when the object is simply assigned for later use. So, barring any other ideas to handle this problem, the above example should look like this: class Color(AutoNumberEnum): _ignore_ = 'property' red green blue @property def cap_name(self): return self.name.upper() Another advantage of using ignore is the ability to have temporary variables automatically discarded: class Period(timedelta, Enum): ''' different lengths of time ''' _ignore_ = 'Period i' Period = vars() for i in range(31): Period['day_%d' % i] = i, 'day' for i in range(15): Period['week_%d' % i] = i*7, 'week' for i in range(12): Period['month_%d' % i] = i*30, 'month' OneDay = day_1 OneWeek = week_1 def __new__(self, value, period): ... and the final enumeration does not have the temp variables `Period` nor `i`. Thoughts? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 12:04:43 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Sat, 09 Jul 2016 16:04:43 +0000 Subject: [issue26988] Add AutoNumberedEnum to stdlib In-Reply-To: <1468077616.66.0.686812215441.issue26988@psf.upfronthosting.co.za> Message-ID: <20160709120439.6ec2b653@subdivisions.wooz.org> Barry A. Warsaw added the comment: On Jul 09, 2016, at 03:20 PM, Ethan Furman wrote: >As far as I can tell there is only one "good" way around this: > >- store any names you don't want auto-numbered into an `_ignore_` > attribute (this only needs to be global and built-in names that > are used before the first method is defined) Seems reasonable, though why not a dunder, e.g. __ignore__? > _ignore_ = 'Period i' Why space separated names inside a string instead of a sequence of strings? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 12:09:55 2016 From: report at bugs.python.org (Steve Dower) Date: Sat, 09 Jul 2016 16:09:55 +0000 Subject: [issue27469] Unicode filename gets crippled on Windows when drag and drop In-Reply-To: <1467992332.72.0.0240653508758.issue27469@psf.upfronthosting.co.za> Message-ID: <1468080595.62.0.032611733458.issue27469@psf.upfronthosting.co.za> Steve Dower added the comment: Got some digging done today and it looks like we're probably best to write our own drop handler. It can probably be embedded into the py.exe launcher, which will keep all the registration in the one file. At worst, we should switch to {86C86720-42A0-1069-A2E8-08002B30309D} (same as EXE files - converts long/Unicode paths to short filenames). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 12:19:28 2016 From: report at bugs.python.org (Ethan Furman) Date: Sat, 09 Jul 2016 16:19:28 +0000 Subject: [issue26988] Add AutoNumberedEnum to stdlib In-Reply-To: <1462844071.91.0.106881823757.issue26988@psf.upfronthosting.co.za> Message-ID: <1468081168.55.0.0613228365199.issue26988@psf.upfronthosting.co.za> Ethan Furman added the comment: A standard feature of Enum is that either space separated strings or a list of strings is accepted any where either is. _sunder_ names are the ones reserved for Enum use (such as _value_, _name_, and soon _order_ (for py2/py3 compatible code). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 12:19:34 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 09 Jul 2016 16:19:34 +0000 Subject: [issue27392] Add a server_side keyword parameter to create_connection In-Reply-To: <1468077467.29.0.0263589744793.issue27392@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I like the new method better. Submit away! --Guido (mobile) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 12:46:44 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 09 Jul 2016 16:46:44 +0000 Subject: [issue27473] bytes_concat seems to check overflow using undefined behaviour Message-ID: <1468082804.63.0.768933034734.issue27473@psf.upfronthosting.co.za> New submission from Xiang Zhang: bytes_concat uses following code to check overflow: size = va.len + vb.len; if (size < 0): { PyErr_NoMemory(); goto done; } This is wrong since signed ints overflow is undefined bahaviour. But one point is that Python's Makefile defines -fwrapv with gcc and clang. So I am not sure this needs to be changed or not. But in other parts of Python code I don't see any overflow check like this. I only see pre-calculated overflow checks. ---------- messages: 270053 nosy: serhiy.storchaka, xiang.zhang priority: normal severity: normal status: open title: bytes_concat seems to check overflow using undefined behaviour _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 12:47:00 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 09 Jul 2016 16:47:00 +0000 Subject: [issue27473] bytes_concat seems to check overflow using undefined behaviour In-Reply-To: <1468082804.63.0.768933034734.issue27473@psf.upfronthosting.co.za> Message-ID: <1468082820.41.0.58017324823.issue27473@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- type: -> behavior versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 13:02:14 2016 From: report at bugs.python.org (John Hagen) Date: Sat, 09 Jul 2016 17:02:14 +0000 Subject: [issue26988] Add AutoNumberedEnum to stdlib In-Reply-To: <1462844071.91.0.106881823757.issue26988@psf.upfronthosting.co.za> Message-ID: <1468083734.76.0.858170855553.issue26988@psf.upfronthosting.co.za> John Hagen added the comment: > What happens with `property`? > > - `property` is looked up in the class namespace Perhaps you've already considered this, I'm not intimately familiar with how classes are parsed and constructed but is it possible to determine if the object is a decorator? It already determines to stop auto-numbering when it hits the first method, could it stop when it hits the first decorator or method? Being able to use temporaries is an interesting side effect, but I feel like that would be used less often than a @staticmethod, @property, or @classmethod over a method, in which case it becomes a little more complex. That being said, I think either solution is valid. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 13:05:42 2016 From: report at bugs.python.org (INADA Naoki) Date: Sat, 09 Jul 2016 17:05:42 +0000 Subject: [issue26081] Implement asyncio Future in C to improve performance In-Reply-To: <1452533022.97.0.443242974791.issue26081@psf.upfronthosting.co.za> Message-ID: <1468083942.69.0.851965636675.issue26081@psf.upfronthosting.co.za> INADA Naoki added the comment: Passing all tests now. Yury, could you explain what the comment "This isn't a Future class; it's a BaseFuture" means? Should it be "_futures.Future" or "_futures.BaseFuture"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 13:11:57 2016 From: report at bugs.python.org (Ethan Furman) Date: Sat, 09 Jul 2016 17:11:57 +0000 Subject: [issue26988] Add AutoNumberedEnum to stdlib In-Reply-To: <1462844071.91.0.106881823757.issue26988@psf.upfronthosting.co.za> Message-ID: <1468084317.77.0.951331055676.issue26988@psf.upfronthosting.co.za> Ethan Furman added the comment: The problem with testing the type of object a name refers to outside the class is it then becomes more difficult to make that an Enum member: class AddressType(Enum): pobox mailbox # third-party po box property Having to assign a value to `property` pretty much negates the value of the magic. I'll go with `_ignore_`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 13:36:48 2016 From: report at bugs.python.org (Memeplex) Date: Sat, 09 Jul 2016 17:36:48 +0000 Subject: [issue27274] [ctypes] Allow from_pointer creation In-Reply-To: <1465442258.95.0.0850234987407.issue27274@psf.upfronthosting.co.za> Message-ID: <1468085808.33.0.781393471217.issue27274@psf.upfronthosting.co.za> Memeplex added the comment: I have been happily using this helper function: def c_array(*args): if type(args[1]) is int: ptr, size = args return (ptr._type_ * size).from_address(ct.addressof(ptr.contents)) else: c_type, buf = args return (c_type * (len(buf) // ct.sizeof(c_type))).from_buffer_copy(buf) For example: c_array(ptr_obj, 10) c_array(c_int, bytes_obj) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 13:42:39 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 09 Jul 2016 17:42:39 +0000 Subject: [issue27474] Unify exception in _Py_bytes_contains for integers Message-ID: <1468086159.4.0.976753811511.issue27474@psf.upfronthosting.co.za> New submission from Xiang Zhang: Now, `sys.maxsize+1 in b'foo'` raises "TypeError: 'int' does not support the buffer interface" which seems weird. In such case, I don't think there is any difference between sys.maxsize+1 and 256. So I suggest make it emits the same exceptions as `256 in b'foo'`, "ValueError: byte must be in range(0, 256)". ---------- files: _Py_bytes_contains.patch keywords: patch messages: 270058 nosy: serhiy.storchaka, xiang.zhang priority: normal severity: normal status: open title: Unify exception in _Py_bytes_contains for integers type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43668/_Py_bytes_contains.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 14:40:28 2016 From: report at bugs.python.org (Jim Fulton) Date: Sat, 09 Jul 2016 18:40: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: <1468089628.78.0.345703144875.issue27392@psf.upfronthosting.co.za> Jim Fulton added the comment: We need an executive (Guido) decision on the name of the new API. Yury wants wrap_socket. I don't like wrap_socket because: - It implies that it's for wrapping client and server sockets. (It shouldn't be for wrapping client sockets because TOOWTDI and create_connection.) - I prefer names that are about goal rather than mechanism. But I can live with anything. I'll defer to Yury unless Guido voices an opinion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 14:40:43 2016 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 09 Jul 2016 18:40: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: <1468089643.44.0.657418078077.issue27392@psf.upfronthosting.co.za> Yury Selivanov added the comment: > wrap_socket implies that it's for wrapping client or server sockets, but it's not. It's only for handling server sockets. Also, I prefer a name that reflects goal, not mechanism. > I think the name should be discussed over here: https://bugs.python.org/issue27392. Why can't `wrap_socket` be used for wrapping client sockets? I think we can refactor asyncio to use it in 'create_connection', and maybe to accept new connections. To my ear, 'asyncio.handle_connection' implies that asyncio will "handle" the connection, i.e. that asyncio itself would do more than just wrapping the socket and attaching a protocol instance. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 14:45:40 2016 From: report at bugs.python.org (Jim Fulton) Date: Sat, 09 Jul 2016 18:45:40 +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: <1468089940.31.0.880175484916.issue27392@psf.upfronthosting.co.za> Jim Fulton added the comment: > Why can't `wrap_socket` be used for wrapping client sockets? TOOWTDI and create_connection. I suppose we could remove (unadvertise) this functionality from create_connection. Then we'd have code bloat because backward compatibility. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 15:00:52 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 09 Jul 2016 19:00:52 +0000 Subject: [issue27392] Add a server_side keyword parameter to create_connection In-Reply-To: <1468089940.31.0.880175484916.issue27392@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Hold on. It's weekend. I will review this when I am near a laptop again. --Guido (mobile) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 15:40:58 2016 From: report at bugs.python.org (Eryk Sun) Date: Sat, 09 Jul 2016 19:40:58 +0000 Subject: [issue27274] [ctypes] Allow from_pointer creation In-Reply-To: <1465442258.95.0.0850234987407.issue27274@psf.upfronthosting.co.za> Message-ID: <1468093258.64.0.0904668746504.issue27274@psf.upfronthosting.co.za> Eryk Sun added the comment: If your goal is to get a bytes object, I don't see the point of creating an array. string_at is simpler and more efficient. If you really must create an array, note that simple pointers (c_void_p, c_char_p, c_wchar_p) need special handling. They don't have a `contents` attribute, and their _type_ is a string. Also, I think combining from_address and addressof is a bit convoluted. I think it's cleaner to implement this using an array pointer: >>> ptr = POINTER(c_int)((c_int * 3)(1,2,3)) >>> arr = POINTER(ptr._type_ * 3)(ptr.contents)[0] >>> arr[:] [1, 2, 3] This also keeps the underlying ctypes object(s) properly referenced: >>> arr._b_base_ <__main__.LP_c_int_Array_3 object at 0x7fb28471cd90> >>> arr._b_base_._objects['0']['1'] <__main__.c_int_Array_3 object at 0x7fb28477da60> whereas using from_address creates an array that dangerously doesn't own its own data and doesn't keep a reference to the owner: >>> arr2 = (ptr._type_ * 3).from_address(addressof(ptr.contents)) >>> arr2._b_needsfree_ 0 >>> arr2._b_base_ is None True >>> arr2._objects is None True Let's create a larger array to ensure it's using an mmap region instead of the heap. This ensures a segfault when trying to access the memory block after it's deallocated: >>> ptr = POINTER(c_int)((c_int * 100000)(*range(100000))) >>> arr = (ptr._type_ * 100000).from_address(addressof(ptr.contents)) >>> del ptr >>> x = arr[:] Segmentation fault (core dumped) whereas using a dereferenced array pointer keeps the source data alive: >>> ptr = POINTER(c_int)((c_int * 100000)(*range(100000))) >>> arr = POINTER(ptr._type_ * 100000)(ptr.contents)[0] >>> del ptr >>> x = arr[:] >>> x[-5:] [99995, 99996, 99997, 99998, 99999] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 16:02:22 2016 From: report at bugs.python.org (Demur Rumed) Date: Sat, 09 Jul 2016 20:02:22 +0000 Subject: [issue27213] Rework CALL_FUNCTION* opcodes In-Reply-To: <1465026334.02.0.369802561902.issue27213@psf.upfronthosting.co.za> Message-ID: <1468094542.34.0.0350515376087.issue27213@psf.upfronthosting.co.za> Demur Rumed added the comment: Pybench is now only ~200ms slower instead of 1200ms slower. But the whole point of this patch is that CALL_FUNCTION_EX shouldn't be optimized for, so I'd much prefer real benchmarking results ---------- Added file: http://bugs.python.org/file43669/callfunc4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 16:09:33 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 09 Jul 2016 20:09:33 +0000 Subject: [issue27474] Unify exception in _Py_bytes_contains for integers In-Reply-To: <1468086159.4.0.976753811511.issue27474@psf.upfronthosting.co.za> Message-ID: <1468094973.62.0.947146927035.issue27474@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- assignee: -> serhiy.storchaka stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 16:11:12 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 09 Jul 2016 20:11:12 +0000 Subject: [issue27473] bytes_concat seems to check overflow using undefined behaviour In-Reply-To: <1468082804.63.0.768933034734.issue27473@psf.upfronthosting.co.za> Message-ID: <1468095072.58.0.79414035581.issue27473@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This should be fixed. ---------- components: +Interpreter Core stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 16:50:53 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 09 Jul 2016 20:50:53 +0000 Subject: [issue25507] IDLE: user code 'import tkinter; tkinter.font' should fail In-Reply-To: <1446113442.78.0.389498275803.issue25507@psf.upfronthosting.co.za> Message-ID: <1468097453.23.0.7464092644.issue25507@psf.upfronthosting.co.za> Terry J. Reedy added the comment: https://stackoverflow.com/questions/38276691/tkinter-nameerror-only-when-running-script-from-shell same problem with filedialog. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 23:27:06 2016 From: report at bugs.python.org (INADA Naoki) Date: Sun, 10 Jul 2016 03:27:06 +0000 Subject: [issue26081] Implement asyncio Future in C to improve performance In-Reply-To: <1452533022.97.0.443242974791.issue26081@psf.upfronthosting.co.za> Message-ID: <1468121226.59.0.131631818409.issue26081@psf.upfronthosting.co.za> INADA Naoki added the comment: Should I send pull request to github.com/python/asyncio? Or should I post patch here? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 9 23:31:49 2016 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 10 Jul 2016 03:31:49 +0000 Subject: [issue26081] Implement asyncio Future in C to improve performance In-Reply-To: <1452533022.97.0.443242974791.issue26081@psf.upfronthosting.co.za> Message-ID: <1468121509.14.0.715395913432.issue26081@psf.upfronthosting.co.za> Yury Selivanov added the comment: > I'm working on this. Some bugs are fixed, but doesn't pass tests for now. Thanks a lot! I couldn't find time to finish this myself. I can definitely help you and review the patch once it's ready. > Yury, could you explain what the comment "This isn't a Future class; it's a BaseFuture" means? Unfortunately I don't remember :( > Should I send pull request to github.com/python/asyncio? Or should I post patch here? Please post it here. AFAIK we haven't yet transitioned to the GitHub. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 00:28:30 2016 From: report at bugs.python.org (INADA Naoki) Date: Sun, 10 Jul 2016 04:28:30 +0000 Subject: [issue26081] Implement asyncio Future in C to improve performance In-Reply-To: <1452533022.97.0.443242974791.issue26081@psf.upfronthosting.co.za> Message-ID: <1468124910.09.0.0843223619915.issue26081@psf.upfronthosting.co.za> INADA Naoki added the comment: OK. Here is current version. ---------- Added file: http://bugs.python.org/file43670/futures.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 01:26:56 2016 From: report at bugs.python.org (mostafa shahdadi) Date: Sun, 10 Jul 2016 05:26:56 +0000 Subject: [issue20767] Some python extensions can't be compiled with clang 3.4 In-Reply-To: <1393335198.15.0.97052317234.issue20767@psf.upfronthosting.co.za> Message-ID: <1468128416.64.0.661742740241.issue20767@psf.upfronthosting.co.za> Changes by mostafa shahdadi : ---------- components: +Installation, Interpreter Core, Library (Lib), Tests type: compile error -> performance versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 01:41:37 2016 From: report at bugs.python.org (Ethan Furman) Date: Sun, 10 Jul 2016 05:41:37 +0000 Subject: [issue26988] Add AutoNumberedEnum to stdlib In-Reply-To: <1462844071.91.0.106881823757.issue26988@psf.upfronthosting.co.za> Message-ID: <1468129297.48.0.205700194871.issue26988@psf.upfronthosting.co.za> Ethan Furman added the comment: I need names. `aenum` already has an `AutoNumberEnum` (the one from the docs, no magic) so I hate to use the same name for the stdlib version with different behavior. So I either need a different name for the stdlib version, or a different name for the aenum version. Any ideas? Hmmm... maybe SequentialEnum for the aenum version... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 01:49:08 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 10 Jul 2016 05:49:08 +0000 Subject: [issue27473] bytes_concat seems to check overflow using undefined behaviour In-Reply-To: <1468082804.63.0.768933034734.issue27473@psf.upfronthosting.co.za> Message-ID: <1468129748.84.0.795969254871.issue27473@psf.upfronthosting.co.za> Xiang Zhang added the comment: Attach a patch to fix this. ---------- keywords: +patch Added file: http://bugs.python.org/file43671/bytes_concat_overflow_check.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 02:00:48 2016 From: report at bugs.python.org (Nathaniel Smith) Date: Sun, 10 Jul 2016 06:00:48 +0000 Subject: [issue26544] platform.libc_ver() returns incorrect version number In-Reply-To: <1457742963.17.0.0403505576154.issue26544@psf.upfronthosting.co.za> Message-ID: <1468130448.89.0.0981390533288.issue26544@psf.upfronthosting.co.za> Nathaniel Smith added the comment: We just ran into this in pip -- https://github.com/pypa/pip/pull/3836 I'd really recommend dropping the current "grovel through the binary doing a regex search" strategy -- it's incredibly error prone, and AFAICT doesn't really give any value. This code OTOH reliably lets you detect glibc and gives the exact version number with no fuss: https://github.com/pypa/pip/blob/master/pip/utils/glibc.py#L9 What about non-glibc systems? Unfortunately the current libc_ver() turns out not to work well for those either. Attached is a CSV file showing the return value of ~1.2 billion calls to platform.libc_ver() by the last 6 months of pip users. You can see that the current code basically never returns anything useful for non-glibc platforms. (The one exception is that it seems to be able to detect uclibc 0.9.32 and label it as "libc 0.9.32".) Don't get me wrong: it'd be really really useful if there were some way to detect and distinguish between the common non-glibc libcs like musl/bionic/uclibc/..., but I'm not sure how to do that -- and unfortunately the current code definitely doesn't do the job :-(. ---------- nosy: +njs Added file: http://bugs.python.org/file43672/results-20160709-224820.csv _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 02:03:46 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 10 Jul 2016 06:03:46 +0000 Subject: [issue27173] Modern Unix key bindings for IDLE In-Reply-To: <1464766185.36.0.150155479026.issue27173@psf.upfronthosting.co.za> Message-ID: <1468130626.93.0.491337033606.issue27173@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The attached patch has a new function current_colors_and_keys that combines ideas and code from both CurrentTheme and CurrentKeys. The latter are now trivial wrappers. It has a new test_config that tests both this function and _warn. The changes to configdialog were tested 'by hand' by loading config-main.cfg into an editor, applying every theme and keyset combination I could think of, and each time re-loading the user file to see what was written. The patterns produces were used in testing current_colors_and_keys. These tests and similar configdialog tests could be automated once I revise the user confighandler so it can write to a StringIO. Barring a reason not to, I plan to apply tomorrow to 3.6 so this gets into alpha 3. Backports can be done later, maybe after the configdialog tests can be automated. ---------- stage: test needed -> commit review Added file: http://bugs.python.org/file43673/modern-unix6.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 02:16:19 2016 From: report at bugs.python.org (mostafa shahdadi) Date: Sun, 10 Jul 2016 06:16:19 +0000 Subject: [issue23285] PEP 475 - EINTR handling In-Reply-To: <1421795073.82.0.355583642769.issue23285@psf.upfronthosting.co.za> Message-ID: <1468131379.49.0.453060800932.issue23285@psf.upfronthosting.co.za> Changes by mostafa shahdadi : Added file: http://bugs.python.org/file43674/b3b439d7dd40.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 03:43:14 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 10 Jul 2016 07:43:14 +0000 Subject: [issue27473] bytes_concat seems to check overflow using undefined behaviour In-Reply-To: <1468082804.63.0.768933034734.issue27473@psf.upfronthosting.co.za> Message-ID: <1468136594.48.0.73556680713.issue27473@psf.upfronthosting.co.za> Martin Panter added the comment: The patch looks correct to me. Issue 1621 is open about the general problem of overflows. ---------- nosy: +martin.panter stage: needs patch -> commit review versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 03:43:23 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 10 Jul 2016 07:43:23 +0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1468136603.15.0.428564160755.issue1621@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- dependencies: +bytes_concat seems to check overflow using undefined behaviour _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 04:18:44 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 10 Jul 2016 08:18:44 +0000 Subject: [issue27473] bytes_concat seems to check overflow using undefined behaviour In-Reply-To: <1468082804.63.0.768933034734.issue27473@psf.upfronthosting.co.za> Message-ID: <1468138724.14.0.809629088685.issue27473@psf.upfronthosting.co.za> Martin Panter added the comment: I changed the versions without checking first. Long story short: Objects/stringobject.c (Python 2 equivalent of Objects/bytesobject.c) is already fixed, but in all versions, Objects/bytearrayobject.c is apparently unfixed. Python 2 was fixed as part of r65335. Python 3 was supposed to be fixed in r66009 (Issue 3627), but it looks like some of the fixes were missed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 04:50:52 2016 From: report at bugs.python.org (Stefan Krah) Date: Sun, 10 Jul 2016 08:50:52 +0000 Subject: [issue20767] Some python extensions can't be compiled with clang 3.4 In-Reply-To: <1393335198.15.0.97052317234.issue20767@psf.upfronthosting.co.za> Message-ID: <1468140652.14.0.724537899917.issue20767@psf.upfronthosting.co.za> Stefan Krah added the comment: Strange, why can anyone edit the classification? It happens a lot lately. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 05:23:45 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 10 Jul 2016 09:23:45 +0000 Subject: [issue23285] PEP 475 - EINTR handling In-Reply-To: <1421795073.82.0.355583642769.issue23285@psf.upfronthosting.co.za> Message-ID: <1468142625.06.0.311920878176.issue23285@psf.upfronthosting.co.za> Changes by Berker Peksag : Removed file: http://bugs.python.org/file43674/b3b439d7dd40.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 05:25:45 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 10 Jul 2016 09:25:45 +0000 Subject: [issue20767] Some python extensions can't be compiled with clang 3.4 In-Reply-To: <1393335198.15.0.97052317234.issue20767@psf.upfronthosting.co.za> Message-ID: <1468142745.62.0.784645838045.issue20767@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- components: -Installation, Interpreter Core, Library (Lib), Tests type: performance -> compile error versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 05:38:30 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 10 Jul 2016 09:38:30 +0000 Subject: [issue27474] Unify exception in _Py_bytes_contains for integers In-Reply-To: <1468086159.4.0.976753811511.issue27474@psf.upfronthosting.co.za> Message-ID: <20160710093827.59273.21849.5688A3D4@psf.io> Roundup Robot added the comment: New changeset 93ab72de7431 by Serhiy Storchaka in branch 'default': Issue #27474: Unified error messages in the __contains__ method of bytes and https://hg.python.org/cpython/rev/93ab72de7431 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 05:39:25 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 10 Jul 2016 09:39:25 +0000 Subject: [issue27474] Unify exception in _Py_bytes_contains for integers In-Reply-To: <1468086159.4.0.976753811511.issue27474@psf.upfronthosting.co.za> Message-ID: <1468143564.99.0.760422120905.issue27474@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Interpreter Core resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 05:43:25 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 10 Jul 2016 09:43: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: <1468143805.55.0.214685204933.issue27235@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> test needed status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 05:49:48 2016 From: report at bugs.python.org (Antti Haapala) Date: Sun, 10 Jul 2016 09:49:48 +0000 Subject: [issue27473] bytes_concat seems to check overflow using undefined behaviour In-Reply-To: <1468082804.63.0.768933034734.issue27473@psf.upfronthosting.co.za> Message-ID: <1468144188.53.0.306793344604.issue27473@psf.upfronthosting.co.za> Antti Haapala added the comment: The previous code was perfectly fine with `-fwrapv` since it makes signed overflow behaviour defined. And afaik BDFLs stance is that signed integer overflow should be defined to wrap anyhow. ---- In my opinion the `-fwrapv` itself makes one proliferate all these insane wrap-checks; indeed I'd rather have them defined in a macro, something like if (PYSSIZE_OVERFLOWS_ON_ADD(va.len, vb.len)) { PyErr_NoMemory(); goto done; } size = va.len + vb.len; even though `-fwrapv` is defined; that way it'd be obvious what is supposed to happen there. ---------- nosy: +ztane _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 06:37:00 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sun, 10 Jul 2016 10:37:00 +0000 Subject: [issue26544] platform.libc_ver() returns incorrect version number In-Reply-To: <1457742963.17.0.0403505576154.issue26544@psf.upfronthosting.co.za> Message-ID: <1468147020.74.0.552249196084.issue26544@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: At the time the code was written, libc and glibc were in wide spread use, so it's not surprising that it doesn't work well for other C libs. Note that the routine returns the highest libc version number used and required by the executable (usually the Python interpreter). This does not necessarily correspond to the version installed on the system. The purpose of the function was to determine the minimum libc compatibility requirements of the executable. The routine you quote uses ctypes and only works for glibc, so parsing needs to be kept around as fallback solution. It also returns the libc version that is currently used on the system; not necessarily the minimum version required, so semantics are different. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 06:59:28 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 10 Jul 2016 10:59:28 +0000 Subject: [issue27473] bytes_concat seems to check overflow using undefined behaviour In-Reply-To: <1468082804.63.0.768933034734.issue27473@psf.upfronthosting.co.za> Message-ID: <1468148368.83.0.521284063917.issue27473@psf.upfronthosting.co.za> Xiang Zhang added the comment: Yes, the current code is valid with -fwrapv. But I am not sure if every compiler supports this feature. So maybe we can't totally rely on it. And in issue1621, some efforts seem to have worked to factor these out. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 07:11:24 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 10 Jul 2016 11:11:24 +0000 Subject: [issue27473] bytes_concat seems to check overflow using undefined behaviour In-Reply-To: <1468082804.63.0.768933034734.issue27473@psf.upfronthosting.co.za> Message-ID: <1468149084.73.0.139061653975.issue27473@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Xiang Zhang, could you please write a patch for bytearray too? ---------- stage: commit review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 08:52:17 2016 From: report at bugs.python.org (Antti Haapala) Date: Sun, 10 Jul 2016 12:52:17 +0000 Subject: [issue27078] Make f'' strings faster than .format: BUILD_STRING opcode? In-Reply-To: <1463858316.54.0.292581402272.issue27078@psf.upfronthosting.co.za> Message-ID: <1468155137.96.0.954535706362.issue27078@psf.upfronthosting.co.za> Antti Haapala added the comment: I am not an expert on writing new opcodes to CPython (having never done it, don't know where to change the disassembler and such, how to make compiler generate them properly and such), but I'd be glad to help with testing, timing and writing the possible joiner algorithm for it, to help it make into Python 3.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 09:05:56 2016 From: report at bugs.python.org (Antti Haapala) Date: Sun, 10 Jul 2016 13:05:56 +0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1468155956.8.0.0898850628094.issue1621@psf.upfronthosting.co.za> Antti Haapala added the comment: One common case where signed integer overflow has been assumed has been the wraparound/overflow checks like in http://bugs.python.org/issue27473 I propose that such commonly erroneous tasks such as overflow checks be implemented as common macros in CPython as getting them right is not quite easy (http://c-faq.com/misc/sd26.html); it would also make the C code more self-documenting. Thus instead of writing if (va.len > PY_SSIZE_T_MAX - vb.len) { one would write something like if (PY_SSIZE_T_SUM_OVERFLOWS(va.len, vb.len)) { and the mere fact that such a macro *wasn't* used there would signal about possible problems with the comparison. ---------- nosy: +ztane _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 09:40:35 2016 From: report at bugs.python.org (STINNER Victor) Date: Sun, 10 Jul 2016 13:40:35 +0000 Subject: [issue27027] add the 'is_android' attribute to test.support In-Reply-To: <1463307075.8.0.646834682003.issue27027@psf.upfronthosting.co.za> Message-ID: <1468158035.35.0.159639019339.issue27027@psf.upfronthosting.co.za> STINNER Victor added the comment: LGTM. Go ahead. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 09:49:59 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 10 Jul 2016 13:49:59 +0000 Subject: [issue27466] [Copy from github user macartur] time2netscape missing comma In-Reply-To: <1467948260.35.0.112204143726.issue27466@psf.upfronthosting.co.za> Message-ID: <20160710134956.7888.38213.D1820A47@psf.io> Roundup Robot added the comment: New changeset 3356d7c57750 by Senthil Kumaran in branch '3.5': Issue #27466: Change time format returned by http.cookie.time2netscape, https://hg.python.org/cpython/rev/3356d7c57750 New changeset 324ade62c0f0 by Senthil Kumaran in branch 'default': [merge from 3.5] - Issue #27466: Change time format returned by https://hg.python.org/cpython/rev/324ade62c0f0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 09:59:59 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 10 Jul 2016 13:59:59 +0000 Subject: [issue27473] bytes_concat seems to check overflow using undefined behaviour In-Reply-To: <1468082804.63.0.768933034734.issue27473@psf.upfronthosting.co.za> Message-ID: <1468159199.21.0.286039789885.issue27473@psf.upfronthosting.co.za> Xiang Zhang added the comment: Of course. I forgot to check bytearray. :( The new patch now also includes bytearray. ---------- Added file: http://bugs.python.org/file43675/bytes_concat_overflow_check_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 10:35:34 2016 From: report at bugs.python.org (John Hagen) Date: Sun, 10 Jul 2016 14:35:34 +0000 Subject: [issue26988] Add AutoNumberedEnum to stdlib In-Reply-To: <1462844071.91.0.106881823757.issue26988@psf.upfronthosting.co.za> Message-ID: <1468161334.57.0.761425912071.issue26988@psf.upfronthosting.co.za> John Hagen added the comment: Some ideas for the new stdlib class: BasicEnum - This helps emphasize that it is a simpler version of Enum that doesn't support all of the Enum features (like assigning values). It also helps communicate that if you don't need values this is a better fit. AutoEnum - This new version (compared with AutoNumberEnum in the docs) does more than just auto number, since it does even the value assignment. Auto helps communicate that this is automatically creating much of the class internals for you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 11:14:08 2016 From: report at bugs.python.org (Nathaniel Smith) Date: Sun, 10 Jul 2016 15:14:08 +0000 Subject: [issue26544] platform.libc_ver() returns incorrect version number In-Reply-To: <1457742963.17.0.0403505576154.issue26544@psf.upfronthosting.co.za> Message-ID: <1468163648.98.0.340719588523.issue26544@psf.upfronthosting.co.za> Nathaniel Smith added the comment: > The purpose of the function was to determine the minimum libc compatibility requirements of the executable. For what it's worth, I didn't know this, the pip authors obviously didn't know this, and after rereading the docs just now I still can't quite tell that this was intended. I'm not sure why one would want these semantics either, but at a minimum it would help to document the intended semantics much more clearly. > parsing needs to be kept around as fallback solution The point of the data I attached was that AFAICT there don't exist any currently-in-use, non-glibc systems where "parsing" returns a meaningful result. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 11:34:29 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 10 Jul 2016 15:34:29 +0000 Subject: [issue27466] [Copy from github user macartur] time2netscape missing comma In-Reply-To: <1467948260.35.0.112204143726.issue27466@psf.upfronthosting.co.za> Message-ID: <20160710153426.7102.18862.8FA8356D@psf.io> Roundup Robot added the comment: New changeset c613d8885054 by Senthil Kumaran in branch '2.7': [port to 2.7] - Issue #27466: Change time format returned by https://hg.python.org/cpython/rev/c613d8885054 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 11:35:25 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 10 Jul 2016 15:35:25 +0000 Subject: [issue27466] [Copy from github user macartur] time2netscape missing comma In-Reply-To: <1467948260.35.0.112204143726.issue27466@psf.upfronthosting.co.za> Message-ID: <1468164925.88.0.662995734718.issue27466@psf.upfronthosting.co.za> Senthil Kumaran added the comment: This is fixed in all versions of python. Thanks for the review. ---------- resolution: -> fixed status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 11:42:06 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 10 Jul 2016 15:42:06 +0000 Subject: [issue27473] bytes_concat seems to check overflow using undefined behaviour In-Reply-To: <1468082804.63.0.768933034734.issue27473@psf.upfronthosting.co.za> Message-ID: <1468165326.63.0.488048420568.issue27473@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And bytearray_iconcat() please. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 11:49:29 2016 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 Jul 2016 15:49:29 +0000 Subject: [issue27472] add the 'unix_shell' attribute to test.support In-Reply-To: <1468077155.86.0.151085889776.issue27472@psf.upfronthosting.co.za> Message-ID: <1468165769.94.0.725111701364.issue27472@psf.upfronthosting.co.za> R. David Murray added the comment: I think a cross reference to issue 16353 is worth making here :) I presume your intent with this issue is to avoid having to wait for that issue to get resolved. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 12:00:22 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 10 Jul 2016 16:00:22 +0000 Subject: [issue27473] bytes_concat seems to check overflow using undefined behaviour In-Reply-To: <1468082804.63.0.768933034734.issue27473@psf.upfronthosting.co.za> Message-ID: <1468166422.22.0.222592177358.issue27473@psf.upfronthosting.co.za> Xiang Zhang added the comment: Sorry. v3 now includes iconcat. ---------- Added file: http://bugs.python.org/file43676/bytes_concat_overflow_check_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 12:08:43 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 10 Jul 2016 16:08:43 +0000 Subject: [issue27078] Make f'' strings faster than .format: BUILD_STRING opcode? In-Reply-To: <1463858316.54.0.292581402272.issue27078@psf.upfronthosting.co.za> Message-ID: <1468166923.98.0.0562751375955.issue27078@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: For comparison: $ ./python -m timeit -s "x = 2" -- "f'X is {x}'" 1000000 loops, best of 3: 1.04 usec per loop $ ./python -m timeit -s "x = 2; j = ''.join" -- "j(['X is ', f'{x}'])" 1000000 loops, best of 3: 0.93 usec per loop $ ./python -m timeit -s "x = 2" -- "'X is {}'.format(x)" 1000000 loops, best of 3: 0.808 usec per loop $ ./python -m timeit -s "x = 2; f = 'X is {}'.format" -- "f(x)" 1000000 loops, best of 3: 0.748 usec per loop $ ./python -m timeit -s "x = 2" -- "'X is %s' % (x,)" 1000000 loops, best of 3: 0.467 usec per loop ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 12:10:10 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 10 Jul 2016 16:10:10 +0000 Subject: [issue27078] Make f'' strings faster than .format: BUILD_STRING opcode? In-Reply-To: <1463858316.54.0.292581402272.issue27078@psf.upfronthosting.co.za> Message-ID: <1468167010.64.0.0492846596616.issue27078@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +Demur Rumed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 12:12:49 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 10 Jul 2016 16:12:49 +0000 Subject: [issue27473] bytes_concat seems to check overflow using undefined behaviour In-Reply-To: <1468082804.63.0.768933034734.issue27473@psf.upfronthosting.co.za> Message-ID: <1468167169.92.0.943538577161.issue27473@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- assignee: -> serhiy.storchaka stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 12:18:25 2016 From: report at bugs.python.org (Jeff Allen) Date: Sun, 10 Jul 2016 16:18:25 +0000 Subject: [issue27427] Add new math module tests In-Reply-To: <1467325887.57.0.243525279322.issue27427@psf.upfronthosting.co.za> Message-ID: <1468167505.01.0.408214612408.issue27427@psf.upfronthosting.co.za> Jeff Allen added the comment: It would be nice to see this considered alongside #26040. ---------- nosy: +jeff.allen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 12:21:31 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 10 Jul 2016 16:21:31 +0000 Subject: [issue27027] add the 'is_android' attribute to test.support In-Reply-To: <1463307075.8.0.646834682003.issue27027@psf.upfronthosting.co.za> Message-ID: <20160710162128.31879.32736.109307E5@psf.io> Roundup Robot added the comment: New changeset 41dfd92f48f0 by Xavier de Gaye in branch 'default': Issue #27027: Added test.support.is_android that is True when this is an https://hg.python.org/cpython/rev/41dfd92f48f0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 12:24:18 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 10 Jul 2016 16:24:18 +0000 Subject: [issue27027] add the 'is_android' attribute to test.support In-Reply-To: <1463307075.8.0.646834682003.issue27027@psf.upfronthosting.co.za> Message-ID: <1468167858.17.0.510174966874.issue27027@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 Sun Jul 10 12:30:34 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 10 Jul 2016 16:30:34 +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: <1468168234.87.0.0750689713482.issue16353@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Issue 27472 adds test.support.unix_shell as the path to the default shell. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 12:33:22 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 10 Jul 2016 16:33:22 +0000 Subject: [issue27472] add the 'unix_shell' attribute to test.support In-Reply-To: <1468077155.86.0.151085889776.issue27472@psf.upfronthosting.co.za> Message-ID: <1468168402.46.0.65089354549.issue27472@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Yes, issue 27027 adds test.support.is_android and there is no need now to wait for issue 16353. Thanks David for reminding me, I have just added a cross-reference to issue 16353. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 12:48:10 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 10 Jul 2016 16:48:10 +0000 Subject: [issue20647] 3.4 cherry-pick: d50a95fab002 add tracemalloc.Traceback.format() method In-Reply-To: <1392593758.89.0.463975396834.issue20647@psf.upfronthosting.co.za> Message-ID: <20160710164807.1109.35595.09A73D94@psf.io> Roundup Robot added the comment: New changeset 74109d87283f by R David Murray in branch '3.5': #20647: Update dictobject.c comments to account for randomized string hashes. https://hg.python.org/cpython/rev/74109d87283f New changeset 31cdf23da19d by R David Murray in branch 'default': Merge: #20647: Update dictobject.c comments to account for randomized string hashes. https://hg.python.org/cpython/rev/31cdf23da19d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 12:49:07 2016 From: report at bugs.python.org (Szabolcs Dombi) Date: Sun, 10 Jul 2016 16:49:07 +0000 Subject: [issue27475] define_macros uses incorrect parameter for msvc compilers Message-ID: <1468169347.46.0.375922519741.issue27475@psf.upfronthosting.co.za> New submission from Szabolcs Dombi: define_macros will generate parameters like -D msvc compilers expect /D and ignore -D link: https://msdn.microsoft.com/en-us/library/hhzbb5c8.aspx ---------- components: Windows messages: 270102 nosy: Szabolcs Dombi, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: define_macros uses incorrect parameter for msvc compilers versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 12:50:08 2016 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 Jul 2016 16:50:08 +0000 Subject: [issue20674] Update comments in dictobject.c In-Reply-To: <1392744795.57.0.649500024154.issue20674@psf.upfronthosting.co.za> Message-ID: <1468169408.57.0.828298149042.issue20674@psf.upfronthosting.co.za> R. David Murray added the comment: Oops, wrong number in the commit message. Thanks for the patch, Jaysinh. New changeset 74109d87283f by R David Murray in branch '3.5': #20647: Update dictobject.c comments to account for randomized string hashes. https://hg.python.org/cpython/rev/74109d87283f New changeset 31cdf23da19d by R David Murray in branch 'default': Merge: #20647: Update dictobject.c comments to account for randomized string hashes. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 12:51:04 2016 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 Jul 2016 16:51:04 +0000 Subject: [issue20647] 3.4 cherry-pick: d50a95fab002 add tracemalloc.Traceback.format() method In-Reply-To: <1392593758.89.0.463975396834.issue20647@psf.upfronthosting.co.za> Message-ID: <1468169464.32.0.973004128503.issue20647@psf.upfronthosting.co.za> R. David Murray added the comment: Drat. Typoed the message number, this commit is for #20674. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 12:52:07 2016 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 Jul 2016 16:52:07 +0000 Subject: [issue20674] Update comments in dictobject.c In-Reply-To: <1392744795.57.0.649500024154.issue20674@psf.upfronthosting.co.za> Message-ID: <1468169527.94.0.579890437555.issue20674@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 13:09:07 2016 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 Jul 2016 17:09:07 +0000 Subject: [issue18858] dummy_threading lacks threading.get_ident() equivalent In-Reply-To: <1377638843.21.0.0472654933915.issue18858@psf.upfronthosting.co.za> Message-ID: <1468170546.99.0.673711059977.issue18858@psf.upfronthosting.co.za> R. David Murray added the comment: A forgotten issue marked commit review. I guess we aren't checking the commit review queue very carefully; I certainly haven't been :(. This patch adds a test but does not fix the bug. The assert should have a message parameter like the existing use of it in the test suite. Lines should be wrapped at 80...the lack of wrapping in the original import has already been corrected. Finally, the test seems more appropriate in test_dummythreading than test_threading. ---------- nosy: +r.david.murray stage: commit review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 13:24:01 2016 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 Jul 2016 17:24:01 +0000 Subject: [issue25652] collections.UserString.__rmod__() raises NameError In-Reply-To: <1447823769.89.0.495006915909.issue25652@psf.upfronthosting.co.za> Message-ID: <1468171441.7.0.814387847197.issue25652@psf.upfronthosting.co.za> R. David Murray added the comment: This was set to commit review when Raymond was ready to commit it, but subsequent discussion indicates the patch isn't yet ready for commit. In particular, there ought to be some tests, even if the decision is to remove __rmod__. The fact that UserString passes its tests with this buggy method indicates that there is a lack somewhere in the general string tests that test_userstring relies on. ---------- nosy: +r.david.murray stage: commit review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 13:42:18 2016 From: report at bugs.python.org (Ethan Furman) Date: Sun, 10 Jul 2016 17:42:18 +0000 Subject: [issue26988] Add AutoNumberedEnum to stdlib In-Reply-To: <1462844071.91.0.106881823757.issue26988@psf.upfronthosting.co.za> Message-ID: <1468172538.35.0.576778185899.issue26988@psf.upfronthosting.co.za> Ethan Furman added the comment: I like AutoEnum. Another auto-related thought: one of the more common Enum questions on StackOverflow is how to automatically have the value be the stringified version of the name: class Huh(Enum): this that those Huh.this.name == Huh.this.value # True So the question then becomes: is there a way to easily support both auto-number and auto-string values? While I don't have the auto-string feature yet in aenum, the system I am using to specify optional settings looks like this: ------ class Color(Enum, settings=AutoNumber): red ... ------ ------ class Color(IntEnum, settings=AutoNumber): red ... ------ ------ class Color(Enum, settings=AutoName): red ... ------ The other option, of course, is to just stick with the prebuilt method of doing things: class Color(AutoEnum): ... class Color(AutoEnum, IntEnum): ... class Color(AutoNameEnum): ... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 13:46:48 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 10 Jul 2016 17:46:48 +0000 Subject: [issue27173] Modern Unix key bindings for IDLE In-Reply-To: <1464766185.36.0.150155479026.issue27173@psf.upfronthosting.co.za> Message-ID: <20160710174645.7573.88907.689F2DFE@psf.io> Roundup Robot added the comment: New changeset e6e6c71776b0 by Terry Jan Reedy in branch 'default': Issue #27173: Add 'IDLE Modern Unix' to the built-in key sets. https://hg.python.org/cpython/rev/e6e6c71776b0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 13:48:24 2016 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 Jul 2016 17:48:24 +0000 Subject: [issue22758] Regression in Python 3.2 cookie parsing In-Reply-To: <1414577677.93.0.364604019199.issue22758@psf.upfronthosting.co.za> Message-ID: <1468172904.91.0.494715680931.issue22758@psf.upfronthosting.co.za> R. David Murray added the comment: My understanding is that there is a commit hook that prevents pushing to the 3.2 branch, so that Georg needs to do this. I've applied the patch and run the tests myself, and agree that it passes (as in, none of the test failures I see are related to cookies). This isn't set to release blocker...should it be (ie: since this is the last release do we want to make sure it gets in)? ---------- resolution: wont fix -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 13:52:41 2016 From: report at bugs.python.org (Ethan Furman) Date: Sun, 10 Jul 2016 17:52:41 +0000 Subject: [issue23591] Add IntFlags In-Reply-To: <1425569483.33.0.144069723147.issue23591@psf.upfronthosting.co.za> Message-ID: <1468173161.0.0.888066911521.issue23591@psf.upfronthosting.co.za> Ethan Furman added the comment: I don't think I'll have this in before the next alpha (today? tomorrow?) but I'll get it merged in the next couple weeks (need to do some integration work with the other Enum enhancements). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 13:55:29 2016 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 Jul 2016 17:55:29 +0000 Subject: [issue26020] set_display evaluation order doesn't match documented behaviour In-Reply-To: <1452048141.82.0.22346371212.issue26020@psf.upfronthosting.co.za> Message-ID: <1468173329.29.0.617771923343.issue26020@psf.upfronthosting.co.za> R. David Murray added the comment: Ping. (Raymond, if you are OK with someone else committing this, you could un-assign it.) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 14:01:11 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 10 Jul 2016 18:01:11 +0000 Subject: [issue16611] Cookie.py does not parse httponly or secure cookie flags In-Reply-To: <1354654224.49.0.677339520856.issue16611@psf.upfronthosting.co.za> Message-ID: <20160710180108.19895.24050.C194E9F5@psf.io> Roundup Robot added the comment: New changeset d22fadc18d01 by R David Murray in branch '3.2': #22758: fix regression in handling of secure cookies. https://hg.python.org/cpython/rev/d22fadc18d01 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 14:01:11 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 10 Jul 2016 18:01:11 +0000 Subject: [issue22758] Regression in Python 3.2 cookie parsing In-Reply-To: <1414577677.93.0.364604019199.issue22758@psf.upfronthosting.co.za> Message-ID: <20160710180108.19895.64501.726D77AC@psf.io> Roundup Robot added the comment: New changeset d22fadc18d01 by R David Murray in branch '3.2': #22758: fix regression in handling of secure cookies. https://hg.python.org/cpython/rev/d22fadc18d01 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 14:01:12 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 10 Jul 2016 18:01:12 +0000 Subject: [issue26176] EmailMessage example doesn't work In-Reply-To: <1453427916.73.0.91814079944.issue26176@psf.upfronthosting.co.za> Message-ID: <20160710180108.19895.19241.B97EF655@psf.io> Roundup Robot added the comment: New changeset 1530fd9a7089 by R David Murray in branch '3.5': #26176: fix usage of Address constructor in email examples. https://hg.python.org/cpython/rev/1530fd9a7089 New changeset a9c11fecd83b by R David Murray in branch 'default': Merge: #26176: fix usage of Address constructor in email examples. https://hg.python.org/cpython/rev/a9c11fecd83b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 14:02:35 2016 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 Jul 2016 18:02:35 +0000 Subject: [issue26176] EmailMessage example doesn't work In-Reply-To: <1453427916.73.0.91814079944.issue26176@psf.upfronthosting.co.za> Message-ID: <1468173755.85.0.418945552383.issue26176@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Nathan. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 14:03:25 2016 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 Jul 2016 18:03:25 +0000 Subject: [issue22758] Regression in Python 3.2 cookie parsing In-Reply-To: <1414577677.93.0.364604019199.issue22758@psf.upfronthosting.co.za> Message-ID: <1468173805.15.0.566371008623.issue22758@psf.upfronthosting.co.za> R. David Murray added the comment: Oops. I guess there's no commit hook after all. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 14:09:04 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Sun, 10 Jul 2016 18:09:04 +0000 Subject: [issue26988] Add AutoNumberedEnum to stdlib In-Reply-To: <1468172538.35.0.576778185899.issue26988@psf.upfronthosting.co.za> Message-ID: <20160710140900.706c8391@python.org> Barry A. Warsaw added the comment: On Jul 10, 2016, at 05:42 PM, Ethan Furman wrote: >class Color(Enum, settings=AutoNumber): [...] >class Color(Enum, settings=AutoName): I guess `settings` would take an AutoType enum. But that can't also be autonumbered or it would be autos all the way down. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 14:10:35 2016 From: report at bugs.python.org (Memeplex) Date: Sun, 10 Jul 2016 18:10:35 +0000 Subject: [issue27274] [ctypes] Allow from_pointer creation In-Reply-To: <1465442258.95.0.0850234987407.issue27274@psf.upfronthosting.co.za> Message-ID: <1468174235.1.0.245386467845.issue27274@psf.upfronthosting.co.za> Memeplex added the comment: As usual, thank you for the detailed and informative answer, Eryk. I think I understand your points but I decided to do it the way I did it because: 1. I sometimes need the array itself. For example, some of my clases contains or inherits from a ctypes structure with pointers (to an array of memory). Usually I name these pointers with a leading underscore and expose them as properties returning ctypes arrays. 2. For pickling/unpickling ctypes arrays provide a convenient middle-point between bytes objects and ctypes pointers. Getting a bytes object from an array is as easy as calling bytes() on it. OTOH, the array can be directly assigned to a compatible pointer structure field. 3. While the overloaded c_array(ptr, size)/c_array(type, bytes) is not the most efficient api to get bytes from a pointer and viceversa, it's very simple for the range of uses cases (1 and 2) it covers. Nevertheless, I have benchmarked the perfomance and it's not that terrible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 14:13:24 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 10 Jul 2016 18:13:24 +0000 Subject: [issue22758] Regression in Python 3.2 cookie parsing In-Reply-To: <1414577677.93.0.364604019199.issue22758@psf.upfronthosting.co.za> Message-ID: <20160710181321.59190.48376.516AE320@psf.io> Roundup Robot added the comment: New changeset 1c07bd735282 by R David Murray in branch '3.3': #22758 null merge https://hg.python.org/cpython/rev/1c07bd735282 New changeset 5b712993dce5 by R David Murray in branch '3.4': #22758 null merge https://hg.python.org/cpython/rev/5b712993dce5 New changeset 26342c9e8c1d by R David Murray in branch '3.5': #22758 null merge https://hg.python.org/cpython/rev/26342c9e8c1d New changeset ce140ed0a56c by R David Murray in branch 'default': #22758 null merge https://hg.python.org/cpython/rev/ce140ed0a56c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 14:14:36 2016 From: report at bugs.python.org (Eryk Sun) Date: Sun, 10 Jul 2016 18:14:36 +0000 Subject: [issue27475] define_macros uses incorrect parameter for msvc compilers In-Reply-To: <1468169347.46.0.375922519741.issue27475@psf.upfronthosting.co.za> Message-ID: <1468174476.49.0.581096765164.issue27475@psf.upfronthosting.co.za> Eryk Sun added the comment: Did you try it? Using -D works fine for me, as it should [1]: Options are specified by either a forward slash (/) or a dash (?). If an option takes an argument, the option's description documents whether a space is allowed between the option and the arguments. [1]: https://msdn.microsoft.com/en-us/library/610ecb4h.aspx ---------- nosy: +eryksun resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 14:29:24 2016 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 Jul 2016 18:29:24 +0000 Subject: [issue27172] Undeprecate inspect.getfullargspec() In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za> Message-ID: <1468175364.39.0.204341090761.issue27172@psf.upfronthosting.co.za> R. David Murray added the comment: The existing patch no longer addresses the revised decision about the API (or the new title of the issue). So, we need a new patch. ---------- nosy: +r.david.murray stage: commit review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 14:32:26 2016 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 Jul 2016 18:32:26 +0000 Subject: [issue27172] Undeprecate inspect.getfullargspec() In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za> Message-ID: <1468175546.23.0.046686206282.issue27172@psf.upfronthosting.co.za> R. David Murray added the comment: Also, this is now a documentation issue, though it does require a code change for the getargspec deprecation message. ---------- assignee: yselivanov -> components: +Documentation -Library (Lib) keywords: -patch type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 14:35:16 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 10 Jul 2016 18:35:16 +0000 Subject: [issue27473] bytes_concat seems to check overflow using undefined behaviour In-Reply-To: <1468082804.63.0.768933034734.issue27473@psf.upfronthosting.co.za> Message-ID: <20160710183513.115745.55322.36D7D1E3@psf.io> Roundup Robot added the comment: New changeset dac248056b20 by Serhiy Storchaka in branch '3.5': Issue #27473: Fixed possible integer overflow in bytes and bytearray https://hg.python.org/cpython/rev/dac248056b20 New changeset de8f0e9196d8 by Serhiy Storchaka in branch 'default': Issue #27473: Fixed possible integer overflow in bytes and bytearray https://hg.python.org/cpython/rev/de8f0e9196d8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 14:52:52 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 10 Jul 2016 18:52:52 +0000 Subject: [issue27476] Introduce a .github folder with PULL_REQUEST_TEMPLATE Message-ID: <1468176772.48.0.730450174113.issue27476@psf.upfronthosting.co.za> New submission from Senthil Kumaran: PULL_REQUEST_TEMPLATE will discourage pull requests in github repo and will instead point to python hg repo and dev guide. This will be removed after the hg to git migration is complete. ---------- assignee: orsenthil messages: 270124 nosy: orsenthil priority: normal severity: normal status: open title: Introduce a .github folder with PULL_REQUEST_TEMPLATE type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 14:54:23 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 10 Jul 2016 18:54:23 +0000 Subject: [issue27476] Introduce a .github folder with PULL_REQUEST_TEMPLATE In-Reply-To: <1468176772.48.0.730450174113.issue27476@psf.upfronthosting.co.za> Message-ID: <1468176863.34.0.0472003014838.issue27476@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Context: https://mail.python.org/pipermail/core-workflow/2016-July/000616.html https://github.com/python/cpython/pull/41 ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 15:00:04 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 10 Jul 2016 19:00:04 +0000 Subject: [issue27476] Introduce a .github folder with PULL_REQUEST_TEMPLATE In-Reply-To: <1468176772.48.0.730450174113.issue27476@psf.upfronthosting.co.za> Message-ID: <1468177204.64.0.403637474888.issue27476@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Here is the patch. ---------- keywords: +patch Added file: http://bugs.python.org/file43677/issue2476.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 15:04:39 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 10 Jul 2016 19:04:39 +0000 Subject: [issue27473] bytes_concat seems to check overflow using undefined behaviour In-Reply-To: <1468082804.63.0.768933034734.issue27473@psf.upfronthosting.co.za> Message-ID: <1468177479.7.0.154353897859.issue27473@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch for 2.7. It fixes also concatenation and repetition of str and unicode. ---------- stage: commit review -> patch review Added file: http://bugs.python.org/file43678/concat_and_repeat_overflow_check-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 15:07:55 2016 From: report at bugs.python.org (Brett Cannon) Date: Sun, 10 Jul 2016 19:07:55 +0000 Subject: [issue27476] Introduce a .github folder with PULL_REQUEST_TEMPLATE In-Reply-To: <1468176772.48.0.730450174113.issue27476@psf.upfronthosting.co.za> Message-ID: <1468177675.44.0.58095359936.issue27476@psf.upfronthosting.co.za> Brett Cannon added the comment: Review is done and only two comments for minor tweaks. ---------- nosy: +brett.cannon stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 15:22:27 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 10 Jul 2016 19:22:27 +0000 Subject: [issue27476] Introduce a .github folder with PULL_REQUEST_TEMPLATE In-Reply-To: <1468176772.48.0.730450174113.issue27476@psf.upfronthosting.co.za> Message-ID: <1468178547.39.0.0165161629497.issue27476@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Thanks. Addressed the review comments. Committing this. ---------- Added file: http://bugs.python.org/file43679/issue27476-v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 15:24:50 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 10 Jul 2016 19:24:50 +0000 Subject: [issue27476] Introduce a .github folder with PULL_REQUEST_TEMPLATE In-Reply-To: <1468176772.48.0.730450174113.issue27476@psf.upfronthosting.co.za> Message-ID: <20160710192447.19919.37342.8F33C1F7@psf.io> Roundup Robot added the comment: New changeset 40e2dd4f7612 by Senthil Kumaran in branch 'default': issue27476 - Introduce a .github template to discourage github pull requests https://hg.python.org/cpython/rev/40e2dd4f7612 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 16:19:37 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 10 Jul 2016 20:19:37 +0000 Subject: [issue27477] IDLE: Switch dialogs to ttk widgets. Message-ID: <1468181977.57.0.555586182066.issue27477@psf.upfronthosting.co.za> New submission from Terry J. Reedy: Scrollbars and the new query module now use ttk widgets. Time to convert the other dialogs. Changing imports is straightforward. Use of an option that can only be changed in the style may be harder. There was one instance of this among the scrollbars (converted in #24750) and I just skipped the minor tweak, and let the scrollbar in question look like all the rest. The most difficult issue is changes in allowed methods. For instance, the state of tk checkbuttons and radiobuttons can be controlled by either setting a control variable or by calling methods. For ttk, the methods are gone. First are the search dialog modules: searchbase, search, replace, and grep. The tk-only 'anchor' option is used but has no effect since the 'width' option is not used to allocate extra space for the buttons. The tk-only select method is used, but at least in searchbase, it has no effect, as it always sets the button to the state it already had. Its use in test files, however, has to be replaced, not deleted. IDLE does not control the common dialogs. But we could choose to replace them, I would not do that for the os file dialogs, but already replaced the 'ask' messagebox used for Open Module for behavioral reasons (#27380). ---------- messages: 270131 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: IDLE: Switch dialogs to ttk widgets. type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 16:39:17 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 10 Jul 2016 20:39:17 +0000 Subject: [issue26020] set_display evaluation order doesn't match documented behaviour In-Reply-To: <1452048141.82.0.22346371212.issue26020@psf.upfronthosting.co.za> Message-ID: <1468183157.68.0.00743522624935.issue26020@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I've got it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 16:40:41 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 10 Jul 2016 20:40:41 +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: <1468183241.0.0.272427979434.issue27392@psf.upfronthosting.co.za> Guido van Rossum added the comment: How about we use connect_socket() or a variant on that name? That feels similar to connect_{read,write}_pipe(), which also take a protocol_factory and an already-opened I/O object. If it's only for server-side sockets I'd call it connect_server_side_socket() -- I don't care that the name is long, the use case is not that common. Or we could have connect_socket() with a server_side flag and a server_hostname argument, and refactor some things so that it shares most of its implementation with _create_connection_transport(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 17:26:46 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 10 Jul 2016 21:26:46 +0000 Subject: [issue27173] Modern Unix key bindings for IDLE In-Reply-To: <1464766185.36.0.150155479026.issue27173@psf.upfronthosting.co.za> Message-ID: <20160710212643.59230.6250.36A6A8C3@psf.io> Roundup Robot added the comment: New changeset 792e3294b59e by Terry Jan Reedy in branch 'default': Issue #27173: Fix error in test_config that caused test_idle to fail. https://hg.python.org/cpython/rev/792e3294b59e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 17:35:56 2016 From: report at bugs.python.org (Antti Haapala) Date: Sun, 10 Jul 2016 21:35:56 +0000 Subject: [issue27078] Make f'' strings faster than .format: BUILD_STRING opcode? In-Reply-To: <1463858316.54.0.292581402272.issue27078@psf.upfronthosting.co.za> Message-ID: <1468186556.62.0.709508366596.issue27078@psf.upfronthosting.co.za> Antti Haapala added the comment: And the expected performance for optimal `f'X is {x}'` code would be *faster* than `"'X is %s' % (x,)"` which still needs to interpret the string at runtime, and build a proper tuple object on stack. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 18:18:43 2016 From: report at bugs.python.org (Eric V. Smith) Date: Sun, 10 Jul 2016 22:18:43 +0000 Subject: [issue27078] Make f'' strings faster than .format: BUILD_STRING opcode? In-Reply-To: <1463858316.54.0.292581402272.issue27078@psf.upfronthosting.co.za> Message-ID: <1468189123.48.0.294882083003.issue27078@psf.upfronthosting.co.za> Eric V. Smith added the comment: > And the expected performance for optimal `f'X is {x}'` code would > be *faster* than `"'X is %s' % (x,)"` which still needs to > interpret the string at runtime, and build a proper tuple object > on stack. That's not necessarily true. The f-string version still needs to invoke the .format() method on the object, instead of only working for a handful of hard-coded types. I'm not saying there aren't optimization opportunities, but it may be that %-formatting is always faster. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 18:26:04 2016 From: report at bugs.python.org (John Hagen) Date: Sun, 10 Jul 2016 22:26:04 +0000 Subject: [issue26988] Add AutoNumberedEnum to stdlib In-Reply-To: <1462844071.91.0.106881823757.issue26988@psf.upfronthosting.co.za> Message-ID: <1468189564.37.0.0525124012702.issue26988@psf.upfronthosting.co.za> John Hagen added the comment: To me, class Color(AutoEnum) and class Color(AutoEnum, IntEnum) is a little more straightforward. It makes usage of AutoEnum similar to IntEnum, and I would expect it to be at least as popular as it. A enum-related side question, since the plan is for this to go into the stdlib, would it also go into enum34 since that is the official back port of the stdlib Enum? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 18:38:31 2016 From: report at bugs.python.org (Eryk Sun) Date: Sun, 10 Jul 2016 22:38:31 +0000 Subject: [issue27469] Unicode filename gets crippled on Windows when drag and drop In-Reply-To: <1467992332.72.0.0240653508758.issue27469@psf.upfronthosting.co.za> Message-ID: <1468190311.62.0.540278816721.issue27469@psf.upfronthosting.co.za> Eryk Sun added the comment: The WSH drop handler was added to resolve issue 1656675. It was chosen because it supports long filenames. OTOH, the EXE drop handler probably uses short filenames because the command line is limited to 32,768 characters. (Actually, it only uses the short name for a path element if it's longer than 12 characters or contains whitespace, which was why my example still had non-ASCII "?" in the filename.) If Python.File switches to the EXE drop handler, then I think PySys_SetArgv should automatically expand short filenames. A command-line option could be added to disable automatic expansion. It would be nice to implement this change in 2.7 as well since the WSH drop handler has been used since 2.6. The alternative is to distribute a DLL with the launcher that implements the IPersistFile and IDropTarget interfaces [1], with support for both long filenames and Unicode. It has to be a shell extension, so AFAIK it can't be hosted in a local server process, if that's what Steve meant by embedding it in py.exe. [1]: https://msdn.microsoft.com/en-us/library/cc144165 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 19:23:34 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 10 Jul 2016 23:23:34 +0000 Subject: [issue25652] collections.UserString.__rmod__() raises NameError In-Reply-To: <1447823769.89.0.495006915909.issue25652@psf.upfronthosting.co.za> Message-ID: <1468193014.92.0.370454824453.issue25652@psf.upfronthosting.co.za> Martin Panter added the comment: Jonathon: Do you have a use case for __rmod__(), or did you find this bug by code analysis? UserString.__rmod__() was added as part of Issue 22189. The main reason seems to be so that UserString has all the methods listed by dir(str). The result was that UserString.__rmod__() is documented as existing since 3.5. Ideally I would agree with removing UserString.__rmod__(), but perhaps it would be safer to just have it return NotImplemented. As long as UserString properly supports all combinations of user_string_a % (user_string_b, user_string_c) etc, whether or how __rmod__() is implemented is an implementation detail. The existance of str.__rmod__() does not seem to be documented. It just seems to be a side-effect of how the C-level nb_remainder slot works. For Serhiy?s F class, which explicitly only works with a single str argument, I think it is reasonable that using UserString instead would raise TypeError. This is what Python 2?s UserString does. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 19:39:23 2016 From: report at bugs.python.org (Jonathan Goble) Date: Sun, 10 Jul 2016 23:39:23 +0000 Subject: [issue25652] collections.UserString.__rmod__() raises NameError In-Reply-To: <1447823769.89.0.495006915909.issue25652@psf.upfronthosting.co.za> Message-ID: <1468193963.67.0.0782949920202.issue25652@psf.upfronthosting.co.za> Jonathan Goble added the comment: Code analysis, if it can even be called that. I was simply looking through the source of the collections module one day out of curiosity (mainly to see how various things in it were implemented) and this bug jumped out at me as I was reading the code. I do not have a use case for the __rmod__() method. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 20:04:09 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 11 Jul 2016 00:04:09 +0000 Subject: [issue27477] IDLE: Switch dialogs to ttk widgets. In-Reply-To: <1468181977.57.0.555586182066.issue27477@psf.upfronthosting.co.za> Message-ID: <1468195449.3.0.501515926964.issue27477@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- keywords: +patch Added file: http://bugs.python.org/file43680/ttk-search.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 20:21:49 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 11 Jul 2016 00:21:49 +0000 Subject: [issue27477] IDLE: Switch dialogs to ttk widgets. In-Reply-To: <1468181977.57.0.555586182066.issue27477@psf.upfronthosting.co.za> Message-ID: <20160711002143.6965.45824.E0B43226@psf.io> Roundup Robot added the comment: New changeset 91fe65e3d7bb by Terry Jan Reedy in branch 'default': Issue #27477: Convert IDLE search dialogs to using ttk widgets. https://hg.python.org/cpython/rev/91fe65e3d7bb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 20:27:17 2016 From: report at bugs.python.org (Ethan Furman) Date: Mon, 11 Jul 2016 00:27:17 +0000 Subject: [issue26988] Add AutoNumberedEnum to stdlib In-Reply-To: <1462844071.91.0.106881823757.issue26988@psf.upfronthosting.co.za> Message-ID: <1468196837.16.0.131395096728.issue26988@psf.upfronthosting.co.za> Ethan Furman added the comment: Yeah, I think the public interface will just be the AutoEnum and AutoNameEnum style. --- > Will these features go into enum34? Not sure. At this point I have the stdlib enum, enum34 enum, and aenum enum. In terms of capability, aenum is the most advanced, followed by the stdlib enum, and finally enum34 (really the only difference between stdlib and enum34 is the automatic definition order). The only advantage of enum34 over aenum is if it works in enum34 it will definitely work in the stdlib, whilst aenum has features not in the stdlib (speaking from a user point of view). So I haven't decided, but at this moment I'm not excited about the prospect. :( What I'll probably do is put enum34 in bug-fix only mode. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 20:32:06 2016 From: report at bugs.python.org (Michael Lazar) Date: Mon, 11 Jul 2016 00:32:06 +0000 Subject: [issue14977] mailcap does not respect precedence in the presence of wildcards In-Reply-To: <1338542933.25.0.233529643572.issue14977@psf.upfronthosting.co.za> Message-ID: <1468197126.8.0.519786596639.issue14977@psf.upfronthosting.co.za> Michael Lazar added the comment: Hello. In my opinion this is a pretty major deficiency. I was trying to add definitions to my ~/.mailcap file (which should take priority over system mailcap files) but they weren't getting applied because of the wildcard bug. This was prohibiting me from using mailcap, so I wrote a patch and submitted it to PyPI. I've never contributed before; what would be the first step towards submitting this to python? https://github.com/michael-lazar/mailcap_fix https://pypi.python.org/pypi/mailcap-fix/0.1.0 ---------- nosy: +michael-lazar _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 20:33:49 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 11 Jul 2016 00:33:49 +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: <1468197229.05.0.575176922122.issue27285@psf.upfronthosting.co.za> Martin Panter added the comment: Buildbot has errors and warnings: http://buildbot.python.org/all/builders/Docs%203.x/builds/1729/steps/suspicious/logs/stdio make -C Doc/ suspicious . . . writing output... [ 83%] library/venv WARNING: [library/venv:353] ":param" found in " :param context: The information for the virtual environment" . . . /buildbot/buildarea/3.x.ware-docs/build/Doc/whatsnew/3.3.rst:110: WARNING: undefined label: scripts-pyvenv (if the link has no caption the label must precede a section header) /buildbot/buildarea/3.x.ware-docs/build/Doc/whatsnew/3.4.rst:200: WARNING: undefined label: scripts-pyvenv (if the link has no caption the label must precede a section header) /buildbot/buildarea/3.x.ware-docs/build/Doc/whatsnew/3.4.rst:1992: WARNING: undefined label: scripts-pyvenv (if the link has no caption the label must precede a section header) /buildbot/buildarea/3.x.ware-docs/build/Doc/whatsnew/3.4.rst:1996: WARNING: undefined label: scripts-pyvenv (if the link has no caption the label must precede a section header) /buildbot/buildarea/3.x.ware-docs/build/Doc/whatsnew/3.4.rst:2462: WARNING: undefined label: scripts-pyvenv (if the link has no caption the label must precede a section header) WARNING: Found 2/299 unused rules: library/venv,,:param,:param context: The information for the environment creation request tutorial/venv,,:c7b9645a6f35,Python 3.4.3+ (3.4:c7b9645a6f35+, May 22 2015, 09:31:25) . . . 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. Looks like Doc/tools/susp-ignored.csv and the whatsnew files need adjusting. ---------- nosy: +martin.panter status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 20:47:38 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 11 Jul 2016 00:47:38 +0000 Subject: [issue14977] mailcap does not respect precedence in the presence of wildcards In-Reply-To: <1338542933.25.0.233529643572.issue14977@psf.upfronthosting.co.za> Message-ID: <1468198058.15.0.00197672900795.issue14977@psf.upfronthosting.co.za> R. David Murray added the comment: Submit it as a proposed patch here for review, please. git or hg diff against the default branch, or a pointer to an hg clone with the patch applied. ---------- versions: +Python 3.5, Python 3.6 -Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 20:51:20 2016 From: report at bugs.python.org (Joshua) Date: Mon, 11 Jul 2016 00:51:20 +0000 Subject: [issue27478] Python Can't run Message-ID: <1468198280.51.0.00893594715031.issue27478@psf.upfronthosting.co.za> New submission from Joshua: I am using the book, Beginning Programming with Python For Dummies and I am stuck. On chapter 10 of the book, there is a dialog box that says"Changing the current python directory". Inside the dialog box there is an instruction on how to change directory, which I followed. I typed: "os.chdir(C:\the python root directory) and press enter and my problem started. The application can't run anything again. When I try to run, I get this message "IDLE's subprocess didn't make connection. Either IDLE cant start a subprocess or personal firewall software is blocking the connection". I have re-installed many times, tried google to see if i can find anything but none has helped. I am new in programming and I will really appreciate your assistant. ---------- components: IDLE messages: 270146 nosy: Keboku priority: normal severity: normal status: open title: Python Can't run type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 21:04:08 2016 From: report at bugs.python.org (Elizabeth Myers) Date: Mon, 11 Jul 2016 01:04:08 +0000 Subject: [issue27479] Slicing strings out of bounds does not raise IndexError Message-ID: <1468199048.87.0.686110972402.issue27479@psf.upfronthosting.co.za> New submission from Elizabeth Myers: When slicing strings, IndexError is not raised when the slices are out of bounds, even for negative indexes. Like so: >>> "test"[-1000:1000] 'test' >>> "test"[-1000:1] 't' >>> ""[-100:100] '' This seems more like a bug than useful behaviour to me. ---------- messages: 270147 nosy: Elizacat priority: normal severity: normal status: open title: Slicing strings out of bounds does not raise IndexError versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 21:04:20 2016 From: report at bugs.python.org (Elizabeth Myers) Date: Mon, 11 Jul 2016 01:04:20 +0000 Subject: [issue27479] Slicing strings out of bounds does not raise IndexError In-Reply-To: <1468199048.87.0.686110972402.issue27479@psf.upfronthosting.co.za> Message-ID: <1468199060.35.0.264381628102.issue27479@psf.upfronthosting.co.za> Changes by Elizabeth Myers : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 21:04:55 2016 From: report at bugs.python.org (Elizabeth Myers) Date: Mon, 11 Jul 2016 01:04:55 +0000 Subject: [issue27479] Slicing strings out of bounds does not raise IndexError In-Reply-To: <1468199048.87.0.686110972402.issue27479@psf.upfronthosting.co.za> Message-ID: <1468199095.56.0.929414247022.issue27479@psf.upfronthosting.co.za> Changes by Elizabeth Myers : ---------- components: +Interpreter Core _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 21:22:27 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 11 Jul 2016 01:22:27 +0000 Subject: [issue10697] host and port attributes not documented well in function urllib.parse.urlparse and urlsplit In-Reply-To: <1292271440.42.0.107945784803.issue10697@psf.upfronthosting.co.za> Message-ID: <1468200147.3.0.443842262927.issue10697@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 21:25:38 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 11 Jul 2016 01:25:38 +0000 Subject: [issue26988] Add AutoNumberedEnum to stdlib In-Reply-To: <1468196837.16.0.131395096728.issue26988@psf.upfronthosting.co.za> Message-ID: <20160710212532.166e4ae2@python.org> Barry A. Warsaw added the comment: On Jul 11, 2016, at 12:27 AM, Ethan Furman wrote: >Not sure. At this point I have the stdlib enum, enum34 enum, and aenum enum. > >In terms of capability, aenum is the most advanced, followed by the stdlib >enum, and finally enum34 (really the only difference between stdlib and >enum34 is the automatic definition order). > >The only advantage of enum34 over aenum is if it works in enum34 it will >definitely work in the stdlib, whilst aenum has features not in the stdlib >(speaking from a user point of view). > >So I haven't decided, but at this moment I'm not excited about the prospect. >:( > >What I'll probably do is put enum34 in bug-fix only mode. It's been useful to have a standalone version of the stdlib module, and in fact, I maintain the enum34 package in Debian. However, we only support that for Python 2 since we don't have to worry about any Python 3 versions before 3.4 (and even there, 3.5 is the default for Stretch and Ubuntu 16.04 LTS). We do have reverse dependencies for python-enum34, but given that we *really* want people to port to Python 3, I'm not sure I really care too much any more about enum34 in Debian. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 21:30:09 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 11 Jul 2016 01:30:09 +0000 Subject: [issue27478] Python Can't run In-Reply-To: <1468198280.51.0.00893594715031.issue27478@psf.upfronthosting.co.za> Message-ID: <1468200609.82.0.326189994431.issue27478@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Please use stackoverflow.com or python-tutor at python.org for assistance. This site is for developers of python. ---------- nosy: +orsenthil resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 21:30:47 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 11 Jul 2016 01:30:47 +0000 Subject: [issue27464] Document that SplitResult & friends are namedtuples In-Reply-To: <1467934956.52.0.328129985005.issue27464@psf.upfronthosting.co.za> Message-ID: <1468200647.36.0.583853727452.issue27464@psf.upfronthosting.co.za> Martin Panter added the comment: I agree, SplitResult._replace() would probably have been very useful to me in the past if it were available (and guaranteed by the documentation). The namedtuple implementation was added in revision 79579fa8d752 (in 2.6 and 3.0), with a comment mentioning speeding up and simplifying the code. So it may not have originally been intended to have the namedtuple functionality as part of the API. If the change is made in 3.5, it should equally be made in 2.7 (with a notice about only being supported since 2.6). ---------- nosy: +martin.panter, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 21:34:47 2016 From: report at bugs.python.org (Ethan Furman) Date: Mon, 11 Jul 2016 01:34:47 +0000 Subject: [issue26988] Add AutoNumberedEnum to stdlib In-Reply-To: <1462844071.91.0.106881823757.issue26988@psf.upfronthosting.co.za> Message-ID: <1468200887.15.0.654806462356.issue26988@psf.upfronthosting.co.za> Ethan Furman added the comment: That brings up a really good point -- this feature requires the __prepare__ method of the metaclass, so it won't work in Python 2 any way. So, yeah, bug-fix-mostly mode for enum34. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 21:38:10 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 11 Jul 2016 01:38:10 +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: <20160711013806.59372.93643.D26FB156@psf.io> Roundup Robot added the comment: New changeset 74856df7e55b by Martin Panter in branch '3.5': Issue #23804: Fix SSL zero-length recv() calls to not block and raise EOF https://hg.python.org/cpython/rev/74856df7e55b New changeset 43d7e5fb3bc2 by Martin Panter in branch '2.7': Issue #23804: Fix SSL zero-length recv() calls to not block and raise EOF https://hg.python.org/cpython/rev/43d7e5fb3bc2 New changeset 4ef2404d343e by Martin Panter in branch 'default': Issue #23804: Merge SSL recv() fix from 3.5 https://hg.python.org/cpython/rev/4ef2404d343e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 22:32:42 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 11 Jul 2016 02:32:42 +0000 Subject: [issue27476] Introduce a .github folder with PULL_REQUEST_TEMPLATE In-Reply-To: <1468176772.48.0.730450174113.issue27476@psf.upfronthosting.co.za> Message-ID: <1468204362.03.0.0341826010662.issue27476@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 22:35:24 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 11 Jul 2016 02:35:24 +0000 Subject: [issue27473] bytes_concat seems to check overflow using undefined behaviour In-Reply-To: <1468082804.63.0.768933034734.issue27473@psf.upfronthosting.co.za> Message-ID: <1468204524.88.0.506805115605.issue27473@psf.upfronthosting.co.za> Xiang Zhang added the comment: Left a comment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 22:47:00 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 11 Jul 2016 02:47:00 +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: <1468205220.8.0.636988843195.issue26867@psf.upfronthosting.co.za> Xiang Zhang added the comment: Does this need to be backport to py2.7? It suffers from the same problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 10 23:33:29 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 11 Jul 2016 03:33:29 +0000 Subject: [issue27377] Add smarter socket.fromfd() In-Reply-To: <1466706816.6.0.72770597716.issue27377@psf.upfronthosting.co.za> Message-ID: <1468208009.31.0.303616319347.issue27377@psf.upfronthosting.co.za> Martin Panter added the comment: Left some minor code review nitpicks. I opened Issue 27409 with an attempt at documenting exactly which SO_* etc symbols may be available. But so far I haven?t got any positive or negative feedback. If it were up to me, I would either commit everything except the new SO_* constants, or briefly list them in the documentation. One more thing that occurred to me is maybe we should check for EINVAL from SO_PROTOCOL. That option was apparently added in Linux 2.6.32, and Free BSD 8.4, 9.1, 10.0. Even if you think these version numbers are too old to worry about, what happens if a Python package is compiled with a new (e.g.) OS X or Windows version that supports SO_PROTOCOL, and then run on an old (existing) OS version? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 00:07:19 2016 From: report at bugs.python.org (Steve Piercy) Date: Mon, 11 Jul 2016 04:07:19 +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: <1468210039.71.0.34995007741.issue27285@psf.upfronthosting.co.za> Steve Piercy added the comment: I've attached a patch for the buildbot error at [library/venv:353]. However, as noted in my [second bullet point](http://bugs.python.org/issue27285#msg269649): - I removed the file Doc/using/scripts.rst because it became obsolete. This caused warnings in Doc/whatsnew/3.3.rst and Doc/whatsnew/3.4.rst which reference the obsolete file. I couldn't find a policy that addresses what to do in this situation, so I left it to the council of elders to provide me with their sage guidance. I'll submit a patch as soon as I know which path to follow. ---------- Added file: http://bugs.python.org/file43681/pyvenv-to-venv.update-susp-ignored.csv.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 00:24:42 2016 From: report at bugs.python.org (Eryk Sun) Date: Mon, 11 Jul 2016 04:24:42 +0000 Subject: [issue27479] Slicing strings out of bounds does not raise IndexError In-Reply-To: <1468199048.87.0.686110972402.issue27479@psf.upfronthosting.co.za> Message-ID: <1468211082.7.0.314580047061.issue27479@psf.upfronthosting.co.za> Eryk Sun added the comment: This is documented behavior for the built-in sequence types [1], and it's also mentioned in the tutorial [2]. The indices() method of a slice object shows the resolved bounds for given sequence length: >>> slice(-1000, 1000, 1).indices(4) (0, 4, 1) >>> slice(None, None, 1).indices(4) (0, 4, 1) >>> slice(1000, -1000, -1).indices(4) (3, -1, -1) >>> slice(None, None, -1).indices(4) (3, -1, -1) The rules apply the same to list, tuple, and range sequences: >>> [1, 2, 3, 4][-1000:1000] [1, 2, 3, 4] >>> (1, 2, 3, 4)[-1000:1] (1,) >>> range(0)[-100:100] range(0, 0) [1]: https://docs.python.org/3/library/stdtypes.html#common-sequence-operations [2]: https://docs.python.org/3/tutorial/introduction.html#strings ---------- nosy: +eryksun resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 00:28:03 2016 From: report at bugs.python.org (Michael Lazar) Date: Mon, 11 Jul 2016 04:28:03 +0000 Subject: [issue14977] mailcap does not respect precedence in the presence of wildcards In-Reply-To: <1338542933.25.0.233529643572.issue14977@psf.upfronthosting.co.za> Message-ID: <1468211283.01.0.163661764427.issue14977@psf.upfronthosting.co.za> Changes by Michael Lazar : ---------- keywords: +patch Added file: http://bugs.python.org/file43682/mailcap.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 00:29:01 2016 From: report at bugs.python.org (Michael Lazar) Date: Mon, 11 Jul 2016 04:29:01 +0000 Subject: [issue14977] mailcap does not respect precedence in the presence of wildcards In-Reply-To: <1338542933.25.0.233529643572.issue14977@psf.upfronthosting.co.za> Message-ID: <1468211341.82.0.668449048727.issue14977@psf.upfronthosting.co.za> Michael Lazar added the comment: Alright thanks, I've submitted a patch ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 00:34:55 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 11 Jul 2016 04:34:55 +0000 Subject: [issue26662] configure/Makefile doesn't check if "python" command works, needed to build Objects/typeslots.inc In-Reply-To: <1459247902.98.0.893274525942.issue26662@psf.upfronthosting.co.za> Message-ID: <1468211695.2.0.199572470115.issue26662@psf.upfronthosting.co.za> Martin Panter added the comment: Victor: Gnu Make has a special ?.DELETE_ON_ERROR? target that will cause Objects/typeslots.inc to be removed if the ?python? command fails, which is slightly better than truncating it. See delete-on-error.patch. It looks like you were not using Gnu Make, but maybe there is an equivalent for BSD?s Make. Chi: Yes I think ?make touch? may help you work around the problem. It should be safe to try anyway :) ---------- keywords: +patch Added file: http://bugs.python.org/file43683/delete-on-error.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 01:58:44 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Mon, 11 Jul 2016 05:58:44 +0000 Subject: [issue26662] configure/Makefile doesn't check if "python" command works, needed to build Objects/typeslots.inc In-Reply-To: <1459247902.98.0.893274525942.issue26662@psf.upfronthosting.co.za> Message-ID: <1468216724.01.0.372336516605.issue26662@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Thanks! It's now working find with `make touch` :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 02:54:06 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 11 Jul 2016 06:54:06 +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: <1468220046.72.0.379848814274.issue23804@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 03:40:09 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Jul 2016 07:40:09 +0000 Subject: [issue26662] configure/Makefile doesn't check if "python" command works, needed to build Objects/typeslots.inc In-Reply-To: <1468216724.01.0.372336516605.issue26662@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Right, I built Python on FreeBSD, it's likely that make was not GNU make. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 03:48:42 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 11 Jul 2016 07:48:42 +0000 Subject: [issue26662] configure/Makefile doesn't check if "python" command works, needed to build Objects/typeslots.inc In-Reply-To: <1459247902.98.0.893274525942.issue26662@psf.upfronthosting.co.za> Message-ID: <1468223322.1.0.928144523895.issue26662@psf.upfronthosting.co.za> Martin Panter added the comment: Survey of different mechanisms for running Python to generate files: Tools/scripts/generate_opcode_h.py and Parser/asdl_c.py: configure.ac tries python3.6, python3, python, etc commands. It either runs the scripts with what it finds, or substitutes an ?echo? command that emits an explanation but does not fail. One disadvantage of this was it needed a script to be made compatible with Python 2.5 . Python/makeopcodetargets.py: Always run as a Unix command with shebang ?#! /usr/bin/env python?. Objects/typeslots.py: Always run via $(PYTHON) command, which defaults to ?python$(EXE)?. No magic configure stuff, but could be manually adjusted by using ?make PYTHON=[. . .]?. This is the only remaining use of the $(PYTHON) makefile variable in 3.6, but it is shared with other stuff in 2.7. An idea I had a while ago was to only run these scripts with a special Make command, eliminating the need for ?make touch?. Going over a discussion earlier this year, Nick Coghlan said a disadvantage of this is that you have to remember the special Make command to use in the rare event that your work affects a generated. Maybe this could be overcome with documentation, warning messages, etc. Argument Clinic code and the configure script are not automatically regenerated. Another potential idea is a flag (either to configure, or to Make) to manually disable or enable all running of Python scripts. When disabled, it would use the existing generated files, and perhaps warn if they are out of date. Or by default perhaps the warning could be an error, with the resolution to either tell it to use a pre-installed Python, or explicitly run the build with the existing generated files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 04:54:39 2016 From: report at bugs.python.org (Martin Mokrejs) Date: Mon, 11 Jul 2016 08:54:39 +0000 Subject: [issue27480] Cannot link _crypt and _nis modules on a host with glibc-2.12 Message-ID: <1468227273.47.0.675242679806.issue27480@psf.upfronthosting.co.za> New submission from Martin Mokrejs: Hi, it seems at least python 3.4.3-r5 on a Gentoo Linux. Failed to build these modules: _crypt nis ---------- files: build.log messages: 270163 nosy: mmokrejs priority: normal severity: normal status: open title: Cannot link _crypt and _nis modules on a host with glibc-2.12 type: compile error versions: Python 3.4 Added file: http://bugs.python.org/file43684/build.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 04:55:36 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 11 Jul 2016 08:55:36 +0000 Subject: [issue27481] Replace TypeError with ValueError in doc regarding "embedded NUL character" Message-ID: <1468227336.42.0.208326485001.issue27481@psf.upfronthosting.co.za> New submission from Xiang Zhang: Errors regarding "embedded NUL character" were changed from TypeError to ValueError, in r92365, issue22215, but the doc doesn't get updated. Add a patch to apply the change in doc. ---------- assignee: docs at python components: Documentation files: null_characters_doc.patch keywords: patch messages: 270164 nosy: docs at python, serhiy.storchaka, xiang.zhang priority: normal severity: normal status: open title: Replace TypeError with ValueError in doc regarding "embedded NUL character" versions: Python 3.6 Added file: http://bugs.python.org/file43685/null_characters_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 05:01:11 2016 From: report at bugs.python.org (Martin Mokrejs) Date: Mon, 11 Jul 2016 09:01:11 +0000 Subject: [issue27480] Cannot link _crypt and _nis modules on a host with glibc-2.12 In-Reply-To: <1468227273.47.0.675242679806.issue27480@psf.upfronthosting.co.za> Message-ID: <1468227671.58.0.101599497125.issue27480@psf.upfronthosting.co.za> Martin Mokrejs added the comment: Also is an issue with 3.5.1-r3: x86_64-pc-linux-gnu-gcc -pthread -shared -Wl,-O1 -L. -L/scratch/mmokrejs/gentoo/lib -L/scratch/mmokrejs/gentoo/usr/lib -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -O2 -pipe -O2 -pipe -march=native -fwrapv build/temp.linux-x86_64-3.5/scratch/mmokrejs/gentoo/var/tmp/portage/dev-lang/python-3.5.1-r3/work/Python-3.5.1/Modules/_decimal/_decimal.o build/temp.linux-x86_64-3.5/scratch/mmokrejs/gentoo/var/tmp/portage/dev-lang/python-3.5.1-r3/work/Python-3.5.1/Modules/_decimal/libmpdec/basearith.o build/temp.linux-x86_64-3.5/scratch/mmokrejs/gentoo/var/tmp/portage/dev-lang/python-3.5.1-r3/work/Python-3.5.1/Modules/_decimal/libmpdec/constants.o build/temp.linux-x86_64-3.5/scratch/mmokrejs/gentoo/var/tmp/portage/dev-lang/python-3.5.1-r3/work/Python-3.5.1/Modules/_decimal/libmpdec/context.o build/temp.linux-x86_64-3.5/scratch/mmokrejs/gentoo/var/tmp/portage/dev-lang/python-3.5.1-r3/work/Python-3.5.1/Modules/_decimal/libmpdec/convolute.o build/temp.linux-x86_64-3.5/scratch/mmokrejs/gentoo/var/tmp/portage/dev-lang/python-3.5.1-r3/work/Python-3.5.1/Modules/_decimal/libmpdec/crt.o build/temp.linux-x86_64-3.5/scratch/mmokrejs/gentoo/var/tmp/portage/dev-lang/python-3.5.1-r3/work/Python-3.5.1/Modules/_decimal/libmpdec/difradix2.o build/temp.linux-x86_64-3.5/scratch/mmokrejs/gentoo/var/tmp/portage/dev-lang/python-3.5.1-r3/work/Python-3.5.1/Modules/_decimal/libmpdec/fnt.o build/temp.linux-x86_64-3.5/scratch/mmokrejs/gentoo/var/tmp/portage/dev-lang/python-3.5.1-r3/work/Python-3.5.1/Modules/_decimal/libmpdec/fourstep.o build/temp.linux-x86_64-3.5/scratch/mmokrejs/gentoo/var/tmp/portage/dev-lang/python-3.5.1-r3/work/Python-3.5.1/Modules/_decimal/libmpdec/io.o build/temp.linux-x86_64-3.5/scratch/mmokrejs/gentoo/var/tmp/portage/dev-lang/python-3.5.1-r3/work/Python-3.5.1/Modules/_decimal/libmpdec/memory.o build/temp.linux-x86_64-3.5/scratch/mmokrejs/gentoo/var/tmp/portage/dev-lang/python-3.5.1-r3/work/Python-3.5.1/Modules/_decimal/libmpdec/mpdecimal.o build/temp.linux-x86_64-3.5/scratch/mmokrejs/gentoo/var/tmp/portage/dev-lang/python-3.5.1-r3/work/Python-3.5.1/Modules/_decimal/libmpdec/numbertheory.o build/temp.linux-x86_64-3.5/scratch/mmokrejs/gentoo/var/tmp/portage/dev-lang/python-3.5.1-r3/work/Python-3.5.1/Modules/_decimal/libmpdec/sixstep.o build/temp.linux-x86_64-3.5/scratch/mmokrejs/gentoo/var/tmp/portage/dev-lang/python-3.5.1-r3/work/Python-3.5.1/Modules/_decimal/libmpdec/transpose.o -L. -L/scratch/mmokrejs/gentoo/lib -L/scratch/mmokrejs/gentoo/usr/lib -lpython3.5 -o build/lib.linux-x86_64-3.5/_decimal.cpython-35-x86_64-linux-gnu.so *** WARNING: renaming "_crypt" since importing it failed: build/lib.linux-x86_64-3.5/_crypt.cpython-35-x86_64-linux-gnu.so: undefined symbol: crypt *** WARNING: renaming "nis" since importing it failed: build/lib.linux-x86_64-3.5/nis.cpython-35-x86_64-linux-gnu.so: undefined symbol: yp_master Following modules built successfully but were removed because they could not be imported: _crypt nis ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 05:01:16 2016 From: report at bugs.python.org (Martin Mokrejs) Date: Mon, 11 Jul 2016 09:01:16 +0000 Subject: [issue27480] Cannot link _crypt and _nis modules on a host with glibc-2.12 In-Reply-To: <1468227273.47.0.675242679806.issue27480@psf.upfronthosting.co.za> Message-ID: <1468227676.79.0.11591037564.issue27480@psf.upfronthosting.co.za> Changes by Martin Mokrejs : ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 05:18:05 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 11 Jul 2016 09:18:05 +0000 Subject: [issue27481] Replace TypeError with ValueError in doc regarding "embedded NUL character" In-Reply-To: <1468227336.42.0.208326485001.issue27481@psf.upfronthosting.co.za> Message-ID: <1468228685.05.0.595734482856.issue27481@psf.upfronthosting.co.za> Xiang Zhang added the comment: Just for a note, there has already been an issue26401 fixing the function.rst. Upload a new patch adding versionchanged tag. ---------- Added file: http://bugs.python.org/file43686/null_characters_doc_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 05:25:06 2016 From: report at bugs.python.org (Antti Haapala) Date: Mon, 11 Jul 2016 09:25:06 +0000 Subject: [issue27078] Make f'' strings faster than .format: BUILD_STRING opcode? In-Reply-To: <1463858316.54.0.292581402272.issue27078@psf.upfronthosting.co.za> Message-ID: <1468229106.08.0.0317984525672.issue27078@psf.upfronthosting.co.za> Antti Haapala added the comment: Ah so it seems. Somehow I thought __format__ was slotted, but that is not the case and it needs to be looked up, and what is worse, of course a tuple needs to be built as well. Oh well, at least it should be quite minimal to make it be faster than `f(x)` there, which necessarily has one extra bound method call and interpretation of format string as the overhead, so there's minimally at least 30 % performance boost to achieve. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 05:40:47 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 11 Jul 2016 09:40:47 +0000 Subject: [issue27472] add the 'unix_shell' attribute to test.support In-Reply-To: <1468077155.86.0.151085889776.issue27472@psf.upfronthosting.co.za> Message-ID: <1468230047.96.0.34663264515.issue27472@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The attached patch ignores the following test modules listed in msg266084: Lib/distutils/tests/test_build_scripts.py|68 col 31| ("#!/bin/sh\n" Lib/distutils/tests/test_install_scripts.py|57 col 38| write_script("shell.sh", ("#!/bin/sh\n" reason: The scripts are not meant to be run. Lib/test/test__osx_support.py|46 col 24| f.write("#!/bin/sh\n/bin/echo OK\n") Lib/test/test__osx_support.py|58 col 24| f.write("#!/bin/sh\n/bin/echo ExpectedOutput\n") Lib/test/test__osx_support.py|149 col 28| f.write("#!/bin/sh\n/bin/echo " + c_output) Lib/test/test__osx_support.py|205 col 24| f.write("#!/bin/sh\nexit 255") reason: These tests run only on the darwin platform. Lib/test/test_subprocess.py|1645 col 15| sh = '/bin/sh' Lib/test/test_subprocess.py|1647 col 33| # Test will fail if /bin/sh is a symlink to csh. reason: This test is specific to bash or ksh. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file43687/unix_shell_27472.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 05:50:01 2016 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 11 Jul 2016 09:50:01 +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: <1468230601.75.0.781229316404.issue25572@psf.upfronthosting.co.za> St?phane Wirtel added the comment: The new paragraph about Homebrew for OSX is useful, we can close this issue. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 05:57:19 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Jul 2016 09:57:19 +0000 Subject: [issue27481] Replace TypeError with ValueError in doc regarding "embedded NUL character" In-Reply-To: <1468227336.42.0.208326485001.issue27481@psf.upfronthosting.co.za> Message-ID: <1468231039.44.0.809585553963.issue27481@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. But while we are here, it would be worth to change "NUL character" and "NUL byte" to "null character" or "null byte" as most used in the documentation and the code. ---------- assignee: docs at python -> serhiy.storchaka stage: -> commit review versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 06:06:54 2016 From: report at bugs.python.org (Marcos Dione) Date: Mon, 11 Jul 2016 10:06:54 +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: <1468231614.18.0.928755564496.issue26826@psf.upfronthosting.co.za> Marcos Dione added the comment: Fixed extra space and semicolon (?!?!). Also, I'm getting 500 errors from riedvelt when I try to reply to comments. ---------- Added file: http://bugs.python.org/file43688/copy_file_range.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 06:08:48 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 11 Jul 2016 10:08:48 +0000 Subject: [issue27481] Replace TypeError with ValueError in doc regarding "embedded NUL character" In-Reply-To: <1468227336.42.0.208326485001.issue27481@psf.upfronthosting.co.za> Message-ID: <1468231728.1.0.972970487604.issue27481@psf.upfronthosting.co.za> Xiang Zhang added the comment: Yes. I noticed the change but didn't change it. Now add it. ---------- Added file: http://bugs.python.org/file43689/null_characters_doc_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 06:12:41 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Jul 2016 10:12:41 +0000 Subject: [issue27481] Replace TypeError with ValueError in doc regarding "embedded NUL character" In-Reply-To: <1468227336.42.0.208326485001.issue27481@psf.upfronthosting.co.za> Message-ID: <1468231961.82.0.820317507295.issue27481@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Python strings contain characters, not bytes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 06:18:25 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 11 Jul 2016 10:18:25 +0000 Subject: [issue27481] Replace TypeError with ValueError in doc regarding "embedded NUL character" In-Reply-To: <1468227336.42.0.208326485001.issue27481@psf.upfronthosting.co.za> Message-ID: <1468232305.09.0.214353843374.issue27481@psf.upfronthosting.co.za> Xiang Zhang added the comment: Sorry, I didn't notice the difference. ---------- Added file: http://bugs.python.org/file43690/null_characters_doc_v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 06:24:04 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 11 Jul 2016 10:24:04 +0000 Subject: [issue25572] _ssl doesn't build on OSX 10.11 In-Reply-To: <1446845399.36.0.0648529481801.issue25572@psf.upfronthosting.co.za> Message-ID: <1468232644.75.0.824170860281.issue25572@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> out of date stage: needs patch -> resolved type: -> behavior versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 08:49:25 2016 From: report at bugs.python.org (INADA Naoki) Date: Mon, 11 Jul 2016 12:49:25 +0000 Subject: [issue26081] Implement asyncio Future in C to improve performance In-Reply-To: <1452533022.97.0.443242974791.issue26081@psf.upfronthosting.co.za> Message-ID: <1468241365.94.0.658413076546.issue26081@psf.upfronthosting.co.za> INADA Naoki added the comment: In my patch, test_asyncio runs against C version Future. I saw how test_json tests against C version and pure Python version. But test_asyncio is more larger than test_json. Before working on it, could someone give me idea to run whole test_asyncio with and without C version Future easily? And, which is master repository of asyncio? github? or hg.python.org? If github, can I send separated pull request changing test_asyncio after this patch is merged? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 09:11:00 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 11 Jul 2016 13:11:00 +0000 Subject: [issue27480] Cannot link _crypt and _nis modules on a host with glibc-2.12 In-Reply-To: <1468227273.47.0.675242679806.issue27480@psf.upfronthosting.co.za> Message-ID: <1468242660.78.0.128041154491.issue27480@psf.upfronthosting.co.za> R. David Murray added the comment: Since you are using the gentoo build system to build this, the bug report should go to the gentoo project, as indicated by the message at the end of your build log. If they find a bug in python itself, then it can be reported here (Arfrever at least can reopen the issue if needed). More likely it is a gentoo configuration issue. ---------- nosy: +Arfrever, r.david.murray resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 09:20:56 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 11 Jul 2016 13:20:56 +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: <20160711132050.17323.3041.1AA66A38@psf.io> Roundup Robot added the comment: New changeset df908a9d97a6 by Martin Panter in branch 'default': Issue #23804: Merge spelling and NEWS fixes from 3.5 https://hg.python.org/cpython/rev/df908a9d97a6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 09:20:56 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 11 Jul 2016 13:20:56 +0000 Subject: [issue25523] Correct "a" article to "an" article In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za> Message-ID: <20160711132049.17323.60416.F2407648@psf.io> Roundup Robot added the comment: New changeset 651f7addf4a8 by Martin Panter in branch '2.7': Issue #25523: Correct "a" article to "an" article https://hg.python.org/cpython/rev/651f7addf4a8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 09:23:51 2016 From: report at bugs.python.org (Martin Mokrejs) Date: Mon, 11 Jul 2016 13:23:51 +0000 Subject: [issue27480] Cannot link _crypt and _nis modules on a host with glibc-2.12 In-Reply-To: <1468227273.47.0.675242679806.issue27480@psf.upfronthosting.co.za> Message-ID: <1468243431.39.0.620531703645.issue27480@psf.upfronthosting.co.za> Martin Mokrejs added the comment: Ah, thank you for a quick answer. The problem is not with a Gentoo, the problem is with python which needs too new libc or libnss or libcrypt. I am re-opening, why cannot I compile newer python version on glibc-2.12 host? This is not a problme with python-2.7, at least. https://bugs.gentoo.org/show_bug.cgi?id=587664 ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 09:29:04 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 11 Jul 2016 13:29:04 +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: <1468243744.62.0.0231220975376.issue23804@psf.upfronthosting.co.za> Martin Panter added the comment: Oops, that last merge is not related to this ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 09:36:22 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 11 Jul 2016 13:36:22 +0000 Subject: [issue25523] Correct "a" article to "an" article In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za> Message-ID: <1468244182.52.0.473575460772.issue25523@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 10:21:45 2016 From: report at bugs.python.org (mtowalski) Date: Mon, 11 Jul 2016 14:21:45 +0000 Subject: [issue27482] heap-buffer-overflow on address 0x6250000078ff Message-ID: <1468246905.12.0.769586892118.issue27482@psf.upfronthosting.co.za> New submission from mtowalski: PoC is attached. Version: 2.7.12 ================================================================= ==4461==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6250000078ff at pc 0x000000508e70 bp 0x7ffe3e88db60 sp 0x7ffe3e88db58 READ of size 1 at 0x6250000078ff thread T0 #0 0x508e6f in tok_nextc /home/mtowalski/tmp/python/Python-2.7.12/Parser/tokenizer.c:954:28 #1 0x4ff581 in tok_get /home/mtowalski/tmp/python/Python-2.7.12/Parser/tokenizer.c:1232:17 #2 0x4ff581 in PyTokenizer_Get /home/mtowalski/tmp/python/Python-2.7.12/Parser/tokenizer.c:1681:0 #3 0x4fae5d in parsetok /home/mtowalski/tmp/python/Python-2.7.12/Parser/parsetok.c:159:16 #4 0x7c9a92 in PyParser_ASTFromFile /home/mtowalski/tmp/python/Python-2.7.12/Python/pythonrun.c:1499:15 #5 0x7c9e49 in PyRun_FileExFlags /home/mtowalski/tmp/python/Python-2.7.12/Python/pythonrun.c:1354:11 #6 0x7c8a7e in PyRun_SimpleFileExFlags /home/mtowalski/tmp/python/Python-2.7.12/Python/pythonrun.c:948:13 #7 0x4f80b9 in Py_Main /home/mtowalski/tmp/python/Python-2.7.12/Modules/main.c:640:23 #8 0x7feaeb493f44 in __libc_start_main /build/eglibc-oGUzwX/eglibc-2.19/csu/libc-start.c:287:0 #9 0x42adc5 in _start ??:? 0x6250000078ff is located 1 bytes to the left of 8192-byte region [0x625000007900,0x625000009900) allocated by thread T0 here: #0 0x4c8d3c in malloc ??:? #1 0x4fe75d in PyTokenizer_FromFile /home/mtowalski/tmp/python/Python-2.7.12/Parser/tokenizer.c:759:29 SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/mtowalski/tmp/python/Python-2.7.12/python+0x508e6f) Shadow bytes around the buggy address: 0x0c4a7fff8ec0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c4a7fff8ed0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c4a7fff8ee0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c4a7fff8ef0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c4a7fff8f00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c4a7fff8f10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa[fa] 0x0c4a7fff8f20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c4a7fff8f30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c4a7fff8f40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c4a7fff8f50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c4a7fff8f60: 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 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==4461==ABORTING ---------- components: Interpreter Core files: python-heap-buffer-overflow-e6f-581-e5d.py messages: 270181 nosy: mtowalski priority: normal severity: normal status: open title: heap-buffer-overflow on address 0x6250000078ff type: crash versions: Python 2.7 Added file: http://bugs.python.org/file43691/python-heap-buffer-overflow-e6f-581-e5d.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 10:29:22 2016 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 11 Jul 2016 14:29:22 +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: <1468247362.71.0.898120114785.issue27392@psf.upfronthosting.co.za> Yury Selivanov added the comment: > How about we use connect_socket() or a variant on that name? That feels similar to connect_{read,write}_pipe(), which also take a protocol_factory and an already-opened I/O object. I like the idea to use "connect_" prefix here. How about simple "connect_accepted_socket"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 10:32:51 2016 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 11 Jul 2016 14:32:51 +0000 Subject: [issue26081] Implement asyncio Future in C to improve performance In-Reply-To: <1452533022.97.0.443242974791.issue26081@psf.upfronthosting.co.za> Message-ID: <1468247571.22.0.172297049101.issue26081@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Before working on it, could someone give me idea to run whole test_asyncio with and without C version Future easily? asyncio uses loop.create_future() to create sockets. I'd suggest you to create two base test classes: one that monkeypatches loop.create_future to return pure python Future in its setUp method; an another, that makes create_future to return a C version of the Future. The derive some unittests from those base classes (which will effectively double the number of tests). > And, which is master repository of asyncio? github? or hg.python.org? If github, can I send separated pull request changing test_asyncio after this patch is merged? The master repo for asyncio is github, but since the C version won't be a part of asyncio (it will be checked in only in CPython source tree), I think it's fine to continue the work here, on bugs.python.org. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 10:43:39 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 11 Jul 2016 14:43:39 +0000 Subject: [issue27480] Cannot link _crypt and _nis modules on a host with glibc-2.12 In-Reply-To: <1468227273.47.0.675242679806.issue27480@psf.upfronthosting.co.za> Message-ID: <1468248219.85.0.937880349532.issue27480@psf.upfronthosting.co.za> R. David Murray added the comment: Can you demonstrate the problem without involving the gentoo build system, using a vanilla tarball downloaded from our site? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 11:03:36 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 11 Jul 2016 15:03:36 +0000 Subject: [issue27392] Add a server_side keyword parameter to create_connection In-Reply-To: <1468247362.71.0.898120114785.issue27392@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Sounds Good To Me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 12:08:25 2016 From: report at bugs.python.org (Martin Mokrejs) Date: Mon, 11 Jul 2016 16:08:25 +0000 Subject: [issue27480] Cannot link _crypt and _nis modules on a host with glibc-2.12 In-Reply-To: <1468227273.47.0.675242679806.issue27480@psf.upfronthosting.co.za> Message-ID: <1468253305.15.0.815674497907.issue27480@psf.upfronthosting.co.za> Martin Mokrejs added the comment: Interesting, using the system-wide RedHat stuff I can compile vanilla Python-3.4.5. See attached nohup.out. I tried to stick to the same configure arguments as Gentoo's package manager used. I also tried to compile the vanilla tarball under Gentoo::Prefix and wow, it also went through (as fat as _crypt is concerned). See nohup-gentoo-prefix.out ---------- Added file: http://bugs.python.org/file43692/nohup.out _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 12:09:26 2016 From: report at bugs.python.org (Martin Mokrejs) Date: Mon, 11 Jul 2016 16:09:26 +0000 Subject: [issue27480] Cannot link _crypt and _nis modules on a host with glibc-2.12 In-Reply-To: <1468227273.47.0.675242679806.issue27480@psf.upfronthosting.co.za> Message-ID: <1468253366.35.0.961418045578.issue27480@psf.upfronthosting.co.za> Changes by Martin Mokrejs : Added file: http://bugs.python.org/file43693/nohup-gentoo-prefix.out _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 12:20:32 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 11 Jul 2016 16:20:32 +0000 Subject: [issue27480] Cannot link _crypt and _nis modules on a host with glibc-2.12 In-Reply-To: <1468227273.47.0.675242679806.issue27480@psf.upfronthosting.co.za> Message-ID: <1468254032.68.0.605087326274.issue27480@psf.upfronthosting.co.za> R. David Murray added the comment: Now you see why I guessed that it was a Gentoo issue :) Or an issue in whatever it is you are using, since it doesn't sound like vanilla gentoo, either. So, I'm closing this again. If you find something you really think is a bug in *our* build process, you can open a new ticket for it. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 12:50:30 2016 From: report at bugs.python.org (Maciej Fijalkowski) Date: Mon, 11 Jul 2016 16:50:30 +0000 Subject: [issue27483] Expose HEAD_LOCK/HEAD_UNLOCK in pystate.c Message-ID: <1468255830.37.0.284681994761.issue27483@psf.upfronthosting.co.za> New submission from Maciej Fijalkowski: Hi The use case here is for C-based statistical profilers. When running vmprof on linux/os x, you can get the current thread state from PyThreadState_GetUnchecked or a similar solution. However, on windows you need to walk all the interpreter state, for which there is an API. However that API is only ever used with locks (HEAD_LOCK/HEAD_UNLOCK), which are not exposed, which turns API mostly useless. ---------- messages: 270188 nosy: fijall, haypo priority: normal severity: normal status: open title: Expose HEAD_LOCK/HEAD_UNLOCK in pystate.c type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 12:56:56 2016 From: report at bugs.python.org (Rufus V. Smith) Date: Mon, 11 Jul 2016 16:56:56 +0000 Subject: [issue27484] Some Examples in Format String Syntax are incorrect or poorly worded Message-ID: <1468256216.77.0.446527786917.issue27484@psf.upfronthosting.co.za> New submission from Rufus V. Smith: In section 6.1.3 Format String Syntax, some examples have incorrect or poorly worded comments: Original: "Harold's a clever {0!s}" # Calls str() on the argument first "Bring out the holy {name!r}" # Calls repr() on the argument first "More {!a}" # Calls ascii() on the argument first Suggested Changes: "Harold's a clever {0!s}" # Calls str() on first positional argument "Bring out the holy {name!r}" # Calls repr() on the named argument 'name' "More {!a}" # Calls ascii() on first positional argument (v. 3.1 and later) ---------- assignee: docs at python components: Documentation messages: 270189 nosy: RufusVS, docs at python priority: normal severity: normal status: open title: Some Examples in Format String Syntax are incorrect or poorly worded _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 13:20:57 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Jul 2016 17:20:57 +0000 Subject: [issue27483] Expose HEAD_LOCK/HEAD_UNLOCK in pystate.c In-Reply-To: <1468255830.37.0.284681994761.issue27483@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Is the profiler running in the same process than the profiled application? Vmprof uses a signal handler, right? HEAD_LOCK is a mutex, acquire a mutex is not async-signal safe :-( Is it an issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 13:26:11 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 11 Jul 2016 17:26:11 +0000 Subject: [issue27469] Unicode filename gets crippled on Windows when drag and drop In-Reply-To: <1467992332.72.0.0240653508758.issue27469@psf.upfronthosting.co.za> Message-ID: <1468257971.37.0.737626191155.issue27469@psf.upfronthosting.co.za> Steve Dower added the comment: I don't want Python to get into the business of changing the command line. I've started looking into building the shell extension so we can pass through arguments correctly. Once we have this, there are likely other features we can add to it (maybe extract __author__/__version__ and display it in tooltips? Certainly some of the requests for IDLE could be accommodated). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 13:52:09 2016 From: report at bugs.python.org (Maciej Fijalkowski) Date: Mon, 11 Jul 2016 17:52:09 +0000 Subject: [issue27483] Expose HEAD_LOCK/HEAD_UNLOCK in pystate.c In-Reply-To: <1468255830.37.0.284681994761.issue27483@psf.upfronthosting.co.za> Message-ID: <1468259529.33.0.541254677431.issue27483@psf.upfronthosting.co.za> Maciej Fijalkowski added the comment: On windows the profiler runs in a separate thread and pauses/restarts other threads (hence the requirements are slightly different). HEAD_LOCK etc. are def not async-signal safe, but it's not an issue on linux ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 14:02:03 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 11 Jul 2016 18:02:03 +0000 Subject: [issue27485] urllib.splitport -- is it official or not? Message-ID: <1468260123.51.0.000787877209911.issue27485@psf.upfronthosting.co.za> New submission from Guido van Rossum: I've seen and written some code that uses urllib.splitport() [1], but it's not in the export list, nor in the docs. However I see no easy other way to perform the same function. Should we make it official, or get rid of it? It's used internally in urllib/request.py [2]. There's a test for it in test_urlparse.py [3], but another test [4] also acknowledges that it's "undocumented" (which suggests that the author of that test didn't know what to do with it either). Same question for the others in that list [4]: 'splitattr', 'splithost', 'splitnport', 'splitpasswd', 'splitport', 'splitquery', 'splittag', 'splittype', 'splituser', 'splitvalue', 'Quoter', 'ResultBase', 'clear_cache', 'to_bytes', 'unwrap', References: [1] https://hg.python.org/cpython/file/tip/Lib/urllib/parse.py#l956 [2] https://hg.python.org/cpython/file/tip/Lib/urllib/request.py#l106 [3] https://hg.python.org/cpython/file/tip/Lib/test/test_urlparse.py#l1015 [4] https://hg.python.org/cpython/file/tip/Lib/test/test_urlparse.py#l946 ---------- messages: 270193 nosy: gvanrossum priority: normal severity: normal status: open title: urllib.splitport -- is it official or not? 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 Jul 11 14:07:32 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 11 Jul 2016 18:07:32 +0000 Subject: [issue27464] Document that SplitResult & friends are namedtuples In-Reply-To: <1467934956.52.0.328129985005.issue27464@psf.upfronthosting.co.za> Message-ID: <1468260452.51.0.0122736884204.issue27464@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: docs at python -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 14:10:42 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 11 Jul 2016 18:10:42 +0000 Subject: [issue27484] Some Examples in Format String Syntax are incorrect or poorly worded In-Reply-To: <1468256216.77.0.446527786917.issue27484@psf.upfronthosting.co.za> Message-ID: <1468260642.45.0.0477478332119.issue27484@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I think all of these read fine as-is though I would change "argument first" to "first argument" or just "argument". Adding the word "positional" is a distractor from what the comments are trying to communicate. The version numbering is normally done with a directive and outside of the examples. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 14:23:44 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 11 Jul 2016 18:23:44 +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: <20160711182339.29055.82345.DFCFCC92@psf.io> Roundup Robot added the comment: New changeset 2a34cef7681b by Ned Deily in branch 'default': Issue #27285: Cleanup "suspicious" warnings. https://hg.python.org/cpython/rev/2a34cef7681b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 14:28:04 2016 From: report at bugs.python.org (Brian Martin) Date: Mon, 11 Jul 2016 18:28:04 +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: <1468261684.3.0.727740372101.issue27235@psf.upfronthosting.co.za> Changes by Brian Martin : ---------- nosy: +osvdb status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 14:28:32 2016 From: report at bugs.python.org (Ned Deily) Date: Mon, 11 Jul 2016 18:28:32 +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: <1468261712.01.0.390502152525.issue27285@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the fix up, Steve. For 3.6.0a3, I chose to just change the 3.3 and 3.4 whatsnew references to just in-line code without any links. If anyone wants something fancier, please feel free to expand on it (after the release). (BTW, Steve, when you submit an updated patch, please do so against the current tip of the branch; most of your update patch had already been committed by Brett.) ---------- nosy: +ned.deily status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 14:29:31 2016 From: report at bugs.python.org (Zachary Ware) Date: Mon, 11 Jul 2016 18:29:31 +0000 Subject: [issue27484] Some Examples in Format String Syntax are incorrect or poorly worded In-Reply-To: <1468256216.77.0.446527786917.issue27484@psf.upfronthosting.co.za> Message-ID: <1468261771.24.0.977117792288.issue27484@psf.upfronthosting.co.za> Zachary Ware added the comment: I don't think "argument first" should be changed to "first argument": the point is that the converter is called on the argument before it's formatted into the string, the call is done "first". ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 14:41:34 2016 From: report at bugs.python.org (=?utf-8?b?7Iah67OR7Jqw?=) Date: Mon, 11 Jul 2016 18:41:34 +0000 Subject: [issue27486] FTPlib hangs on some pasv responses Message-ID: <1468262494.01.0.466520589745.issue27486@psf.upfronthosting.co.za> New submission from ???: FTPlib hangs on PASV responses when the connected server is within its local network. Here's my fix that checks the target address with ipaddress lib: https://github.com/python/cpython/pull/28/files ---------- components: Library (Lib) messages: 270198 nosy: ??? priority: normal severity: normal status: open title: FTPlib hangs on some pasv responses type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 14:49:00 2016 From: report at bugs.python.org (SilentGhost) Date: Mon, 11 Jul 2016 18:49:00 +0000 Subject: [issue27486] FTPlib hangs on some pasv responses In-Reply-To: <1468262494.01.0.466520589745.issue27486@psf.upfronthosting.co.za> Message-ID: <1468262940.05.0.952981503541.issue27486@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +giampaolo.rodola stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 15:05:27 2016 From: report at bugs.python.org (Ethan Furman) Date: Mon, 11 Jul 2016 19:05:27 +0000 Subject: [issue26988] Add AutoNumberedEnum to stdlib In-Reply-To: <1462844071.91.0.106881823757.issue26988@psf.upfronthosting.co.za> Message-ID: <1468263927.64.0.539313905661.issue26988@psf.upfronthosting.co.za> Ethan Furman added the comment: If you are constructing your own base Enum type, which would you rather do? class BaseZeroEnum(Enum): "initial integer is 0" _start_ = 0 ... or class BaseZeroEnum(Enum, start=0): "initial integer is 0" ... ? Oh, and yes if you specify a starting number you also activate the AutoNumber feature. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 15:08:01 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Jul 2016 19:08:01 +0000 Subject: [issue27485] urllib.splitport -- is it official or not? In-Reply-To: <1468260123.51.0.000787877209911.issue27485@psf.upfronthosting.co.za> Message-ID: <1468264081.45.0.333362775094.issue27485@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: splitport() doesn't work with IPv6 ("[::1]", see issue18191), nor with authority ("user:password at example.com"). Note that there is a almost duplicate function splitnport(). The existence of two similar functions that behave differently in corner cases looks confusing. And seems splitport() and splitnport() not always used correctly internally (see issue20271). ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 15:25:50 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 11 Jul 2016 19:25:50 +0000 Subject: [issue26988] Add AutoNumberedEnum to stdlib In-Reply-To: <1468263927.64.0.539313905661.issue26988@psf.upfronthosting.co.za> Message-ID: <20160711152520.1fd0564e@anarchist.wooz.org> Barry A. Warsaw added the comment: On Jul 11, 2016, at 07:05 PM, Ethan Furman wrote: >class BaseZeroEnum(Enum, start=0): > "initial integer is 0" > ... > >? Oh, and yes if you specify a starting number you also activate the >AutoNumber feature. I like the way this one looks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 16:18:11 2016 From: report at bugs.python.org (Wolfgang Maier) Date: Mon, 11 Jul 2016 20:18:11 +0000 Subject: [issue27487] -m switch regression in Python 3.5.2 (under rare circumstances) Message-ID: <1468268291.19.0.631980361837.issue27487@psf.upfronthosting.co.za> New submission from Wolfgang Maier: As a result of Issue14285 Python 3.5.2 now imports packages in runpy. _get_module_details before calling importlib.util.find_spec. Although I'm not sure how important this is, I wanted to report that this new behaviour can have a side-effect under pretty exotic circumstances. When __init__.py imports the same module that is supposed to be invoked via the -m switch and that module replaces its own entry in sys.modules with another object, this causes importlib.util.find_spec to fail with a *very* cryptic: Error while finding spec for 'package.module' (ValueError: package.module.__spec__ is not set) without an exception traceback. I have no idea whether any other package would be affected by this, but it took me quite some time today to trace the cause of this and it is not what you'd expect from a maintenance release. I think the changed behaviour in runpy should at least be documented (beyond just mentioning the issue in the changelog). ---------- components: Library (Lib) messages: 270202 nosy: martin.panter, ncoghlan, wolma priority: normal severity: normal status: open title: -m switch regression in Python 3.5.2 (under rare circumstances) type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 16:18:35 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 11 Jul 2016 20:18:35 +0000 Subject: [issue27484] Some Examples in Format String Syntax are incorrect or poorly worded In-Reply-To: <1468256216.77.0.446527786917.issue27484@psf.upfronthosting.co.za> Message-ID: <1468268315.33.0.459489620518.issue27484@psf.upfronthosting.co.za> R. David Murray added the comment: Agree with Zach. The example comments are correct as written, especially when considered in the context of the preceding example. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 16:24:18 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Mon, 11 Jul 2016 20:24:18 +0000 Subject: [issue16858] tarfile silently hides errors In-Reply-To: <1357286028.6.0.98597292825.issue16858@psf.upfronthosting.co.za> Message-ID: <1468268658.01.0.389942103552.issue16858@psf.upfronthosting.co.za> ???? ????????? added the comment: http://stackoverflow.com/questions/1964806/short-read-from-filesystem-when-can-it-happen Disk-based filesystems generally use uninterruptible reads, which means that the read operation generally cannot be interrupted by a signal. Network-based filesystems sometimes use interruptible reads, which can return partial data or no data. (In the case of NFS this is configurable using the intr mount option.) They sometimes also implement timeouts. > can return partial data Seems reading tar-file from NFS-filesystem may trigger that bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 16:26:10 2016 From: report at bugs.python.org (Monti Carlo) Date: Mon, 11 Jul 2016 20:26:10 +0000 Subject: [issue27488] Underscore not showing Mac El Capitan Message-ID: <1468268770.26.0.794680081595.issue27488@psf.upfronthosting.co.za> New submission from Monti Carlo: Trying to type in underscore and it just made a space... Downloaded 3.5.2 and it works fine. ---------- components: IDLE messages: 270205 nosy: Monti Carlo priority: normal severity: normal status: open title: Underscore not showing Mac El Capitan versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 16:27:23 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Mon, 11 Jul 2016 20:27:23 +0000 Subject: [issue16858] tarfile silently hides errors In-Reply-To: <1357286028.6.0.98597292825.issue16858@psf.upfronthosting.co.za> Message-ID: <1468268843.39.0.61982497863.issue16858@psf.upfronthosting.co.za> ???? ????????? added the comment: What the hell! sorry again :( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 16:27:54 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Mon, 11 Jul 2016 20:27:54 +0000 Subject: [issue26877] tarfile use wrong code when read from fileobj In-Reply-To: <1461879882.57.0.719679075431.issue26877@psf.upfronthosting.co.za> Message-ID: <1468268874.02.0.729102094178.issue26877@psf.upfronthosting.co.za> ???? ????????? added the comment: http://stackoverflow.com/questions/1964806/short-read-from-filesystem-when-can-it-happen Disk-based filesystems generally use uninterruptible reads, which means that the read operation generally cannot be interrupted by a signal. Network-based filesystems sometimes use interruptible reads, which can return partial data or no data. (In the case of NFS this is configurable using the intr mount option.) They sometimes also implement timeouts. > can return partial data Seems reading tar-file from NFS-filesystem may trigger that bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 16:51:30 2016 From: report at bugs.python.org (Zachary Ware) Date: Mon, 11 Jul 2016 20:51:30 +0000 Subject: [issue27488] Underscore not showing Mac El Capitan In-Reply-To: <1468268770.26.0.794680081595.issue27488@psf.upfronthosting.co.za> Message-ID: <1468270290.32.0.969066613216.issue27488@psf.upfronthosting.co.za> Zachary Ware added the comment: This is due to changes in the default font settings for IDLE. You can boost your font size and/or pick a different font, and your underscores will appear. 3.4 is no longer receiving bug fixes (or binary installers), so there's nothing we can do here. ---------- nosy: +zach.ware resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 16:55:40 2016 From: report at bugs.python.org (Joel Handwell) Date: Mon, 11 Jul 2016 20:55:40 +0000 Subject: [issue27489] Win 10, choco install python gets message: Access to the path 'C:\WINDOWS\system32\**\**.exe.ignore' is denied. Message-ID: <1468270540.45.0.165403304626.issue27489@psf.upfronthosting.co.za> New submission from Joel Handwell: While installing python 3.5.1 using chocolatey package manager on Windows 10, I got following message: python3 v3.5.1 WARNING: The names of some imported commands from the module 'chocolateyInstaller' include unapproved verbs that might make them less discoverable. To find the commands with unapproved verbs, run the Import-Module command again with the Verbose parameter. For a list of approved verbs, type Get-Verb. Downloading python3 64 bit from 'https://www.python.org/ftp/python/3.5.1/python-3.5.1-amd64.exe' Progress: 100% - Saving 28.25 MB of 28.25 MB (29627072/29627072) Download of python3Install.exe (28.25 MB) completed. Installing python3... python3 has been installed. Access to the path 'C:\WINDOWS\system32\Boot\winload.exe.ignore' is denied. Access to the path 'C:\WINDOWS\system32\Boot\winresume.exe.ignore' is denied. Access to the path 'C:\WINDOWS\system32\DriverStore\FileRepository\64dp4256.inf_amd64_9191bdaf5e95d43e\difx64.exe.ignore' is denied. Access to the path 'C:\WINDOWS\system32\DriverStore\FileRepository\64dp4256.inf_amd64_9191bdaf5e95d43e\DPTopologyApp.exe.ignore' is denied. Access to the path 'C:\WINDOWS\system32\DriverStore\FileRepository\64dp4256.inf_amd64_9191bdaf5e95d43e\DPTopologyAppv2_0.exe.ignore' is denied. Access to the path 'C:\WINDOWS\system32\DriverStore\FileRepository\64dp4256.inf_amd64_9191bdaf5e95d43e\GfxUIEx.exe.ignore' is denied. Access to the path 'C:\WINDOWS\system32\DriverStore\FileRepository\64dp4256.inf_amd64_9191bdaf5e95d43e\Gfxv2_0.exe.ignore' is denied. Access to the path 'C:\WINDOWS\system32\DriverStore\FileRepository\64dp4256.inf_amd64_9191bdaf5e95d43e\Gfxv4_0.exe.ignore' is denied. Access to the path 'C:\WINDOWS\system32\DriverStore\FileRepository\64dp4256.inf_amd64_9191bdaf5e95d43e\igfxCUIService.exe.ignore' is denied. Access to the path 'C:\WINDOWS\system32\DriverStore\FileRepository\64dp4256.inf_amd64_9191bdaf5e95d43e\igfxEM.exe.ignore' is denied. Access to the path 'C:\WINDOWS\system32\DriverStore\FileRepository\64dp4256.inf_amd64_9191bdaf5e95d43e\igfxext.exe.ignore' is denied. Access to the path 'C:\WINDOWS\system32\DriverStore\FileRepository\64dp4256.inf_amd64_9191bdaf5e95d43e\igfxHK.exe.ignore' is denied. ---------- components: Installation messages: 270209 nosy: joelhandwell priority: normal severity: normal status: open title: Win 10, choco install python gets message: Access to the path 'C:\WINDOWS\system32\**\**.exe.ignore' is denied. type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 17:03:29 2016 From: report at bugs.python.org (Joel Handwell) Date: Mon, 11 Jul 2016 21:03:29 +0000 Subject: [issue27489] Win 10, choco install python gets message: Access to the path 'C:\WINDOWS\system32\**\**.exe.ignore' is denied. In-Reply-To: <1468270540.45.0.165403304626.issue27489@psf.upfronthosting.co.za> Message-ID: <1468271009.3.0.823297478666.issue27489@psf.upfronthosting.co.za> Changes by Joel Handwell : ---------- resolution: -> third party _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 17:41:47 2016 From: report at bugs.python.org (=?utf-8?q?Mihai_Capot=C4=83?=) Date: Mon, 11 Jul 2016 21:41:47 +0000 Subject: [issue8027] distutils fail to determine c++ linker with unixcompiler if using ccache In-Reply-To: <1267284243.46.0.756608052144.issue8027@psf.upfronthosting.co.za> Message-ID: <1468273307.24.0.512160728444.issue8027@psf.upfronthosting.co.za> Changes by Mihai Capot? : ---------- nosy: +mihaic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 17:59:56 2016 From: report at bugs.python.org (Eryk Sun) Date: Mon, 11 Jul 2016 21:59:56 +0000 Subject: [issue27489] Win 10, choco install python gets message: Access to the path 'C:\WINDOWS\system32\**\**.exe.ignore' is denied. In-Reply-To: <1468270540.45.0.165403304626.issue27489@psf.upfronthosting.co.za> Message-ID: <1468274396.64.0.435606787729.issue27489@psf.upfronthosting.co.za> Changes by Eryk Sun : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 18:06:12 2016 From: report at bugs.python.org (Brad Larsen) Date: Mon, 11 Jul 2016 22:06:12 +0000 Subject: [issue13402] Document absoluteness of sys.executable In-Reply-To: <1321289437.84.0.982753479785.issue13402@psf.upfronthosting.co.za> Message-ID: <1468274772.28.0.198358413257.issue13402@psf.upfronthosting.co.za> Brad Larsen added the comment: It looks like sys.executable is *not* always an absolute path. In Python 2.7: $ which python2.7 /opt/local/bin/python2.7 $ cd /opt/local/bin $ ../bin/python2.7 -m 'import sys; print(sys.executable)' /opt/local/bin/../bin/python2.7 Also in Python 3.5: $ which python3.5 /opt/local/bin/python3.5 $ cd /opt/local/bin $ ../bin/python3.5 -m 'import sys; print(sys.executable)' /opt/local/bin/../bin/python3.5 ---------- nosy: +blarsen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 18:42:18 2016 From: report at bugs.python.org (Thomas Perl) Date: Mon, 11 Jul 2016 22:42:18 +0000 Subject: [issue27490] ARM cross-compile: pgen built without $(CFLAGS) as $(LIBRARY) dependency Message-ID: <1468276938.3.0.370267656827.issue27490@psf.upfronthosting.co.za> New submission from Thomas Perl: Problem description: Trying to cross-compile $(LIBRARY) (libpython2.7.a for example) causes "pgen" to be built, even when it's not used in the cross-compilation case (only a file copy is done to generate $(GRAMMAR_H) and $(GRAMMAR_C)). The current rule for $(PGEN) in Makefile.pre.in does not include $(CFLAGS): https://hg.python.org/cpython/file/tip/Makefile.pre.in#l810 This causes problems when $(CFLAGS) changes the ARM float ABI, e.g.: CFLAGS="-mfloat-abi=hard" This causes the following issues at link time: 1. The .o files that get linked into "pgen" are built with CFLAGS (which is good, because some of them are used for libpython as well) 2. When the "pgen" binary gets built, the $(CFLAGS) are not used 3. Compiler fails to build "pgen" with different float ABI settings ===== [...] arm-none-eabi-gcc -c -fno-strict-aliasing -march=armv6k -mtune=mpcore -mfloat-abi=hard -mtp=soft -fomit-frame-pointer -ffunction-sections -DARM11 -D_3DS -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -o Parser/pgenmain.o Parser/pgenmain.c arm-none-eabi-gcc -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/parsetok.o Parser/bitset.o Parser/metagrammar.o Parser/firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o Python/mysnprintf.o Python/pyctype.o Parser/tokenizer_pgen.o Parser/printgrammar.o Parser/pgenmain.o -o Parser/pgen /Users/thp/pkg/devkitPro/devkitARM/bin/../lib/gcc/arm-none-eabi/5.3.0/../../../../arm-none-eabi/bin/ld: error: Parser/acceler.o uses VFP register arguments, Parser/pgen does not /Users/thp/pkg/devkitPro/devkitARM/bin/../lib/gcc/arm-none-eabi/5.3.0/../../../../arm-none-eabi/bin/ld: failed to merge target specific data of file Parser/acceler.o [...] ===== Note that the error message is repeated for all .o files linked into pgen, I've only included one here for demonstration purposes. The following patch (against a Python 2.7.12 tarball, similar fix for Hg tip and Python 3) fixes the issue for me: ===== diff -u Python-2.7.12/Makefile.pre.in Python-2.7.12-fix/Makefile.pre.in --- Python-2.7.12/Makefile.pre.in 2016-06-25 23:49:31.000000000 +0200 +++ Python-2.7.12-fix/Makefile.pre.in 2016-07-12 00:17:02.000000000 +0200 @@ -698,7 +698,7 @@ fi $(PGEN): $(PGENOBJS) - $(CC) $(OPT) $(LDFLAGS) $(PGENOBJS) $(LIBS) -o $(PGEN) + $(CC) $(OPT) $(CFLAGS) $(LDFLAGS) $(PGENOBJS) $(LIBS) -o $(PGEN) Parser/grammar.o: $(srcdir)/Parser/grammar.c \ $(srcdir)/Include/token.h \ ===== Also note that the same $(CFLAGS) needs to be added to the rule for $(BUILDPYTHON) if one wants to build that as well, but in my case, I only did a "make libpython2.7.a", and that indirectly depends on pgen ($(LIBRARY) -> $(LIBRARY_OBJS) -> $(PYTHON_OBJS) -> Python/graminit.o -> $(GRAMMAR_C) -> $(GRAMMAR_H) -> $(PGEN), which results in that error message, so libpython2.7.a can't be built). Another fix could be to make it so that $(GRAMMAR_H) does not depend on $(PGEN) if $(cross_compiling) is "yes" (if you read the rule contents for $(GRAMMAR_H), you'll find that indeed $(PGEN) isn't used at all if $(cross_compiling) is "yes". At least for GNU make, it might be possible to avoid building "pgen" in that case as follows and removing $(PGEN) from the default dependencies of $(GRAMMAR_H): ifneq ($(cross_compiling),yes) $(GRAMMAR_H): $(PGEN) endif If this is a more acceptable solution, one could probably rewrite the "test "$(cross_compiling" != "yes"; then..." part of the make rules from $(GRAMMAR_H) and $(GRAMMAR_C) with Make's ifeq, here's a patch for that instead (this also makes the dependencies more clear, since $(GRAMMAR_H) does not depend on $(GRAMMAR_INPUT) for the cross-input case, as it is not used): ===== diff -u Python-2.7.12/Makefile.pre.in Python-2.7.12-fix/Makefile.pre.in --- Python-2.7.12/Makefile.pre.in 2016-06-25 23:49:31.000000000 +0200 +++ Python-2.7.12-fix/Makefile.pre.in 2016-07-12 00:37:43.000000000 +0200 @@ -680,22 +680,21 @@ Modules/pwdmodule.o: $(srcdir)/Modules/pwdmodule.c $(srcdir)/Modules/posixmodule.h +ifeq ($(cross_compiling),yes) +$(GRAMMAR_H): $(srcdir)/Include/graminit.h + @$(MKDIR_P) Include + cp $(srcdir)/Include/graminit.h $(GRAMMAR_H).tmp + mv $(GRAMMAR_H).tmp $(GRAMMAR_H) +$(GRAMMAR_C): $(srcdir)/Python/graminit.c + cp $(srcdir)/Python/graminit.c $(GRAMMAR_C).tmp + mv $(GRAMMAR_C).tmp $(GRAMMAR_C) +else $(GRAMMAR_H): $(GRAMMAR_INPUT) $(PGEN) @$(MKDIR_P) Include - # Avoid copying the file onto itself for an in-tree build - if test "$(cross_compiling)" != "yes"; then \ - $(PGEN) $(GRAMMAR_INPUT) $(GRAMMAR_H) $(GRAMMAR_C); \ - else \ - cp $(srcdir)/Include/graminit.h $(GRAMMAR_H).tmp; \ - mv $(GRAMMAR_H).tmp $(GRAMMAR_H); \ - fi + $(PGEN) $(GRAMMAR_INPUT) $(GRAMMAR_H) $(GRAMMAR_C) $(GRAMMAR_C): $(GRAMMAR_H) - if test "$(cross_compiling)" != "yes"; then \ - touch $(GRAMMAR_C); \ - else \ - cp $(srcdir)/Python/graminit.c $(GRAMMAR_C).tmp; \ - mv $(GRAMMAR_C).tmp $(GRAMMAR_C); \ - fi + touch $(GRAMMAR_C) +endif $(PGEN): $(PGENOBJS) $(CC) $(OPT) $(LDFLAGS) $(PGENOBJS) $(LIBS) -o $(PGEN) ===== See also (slightly related, the "avoid running" part is fixed, but the "avoid building" part is not fixed): https://bugs.python.org/issue22625 ---------- components: Cross-Build messages: 270211 nosy: Alex.Willmer, Thomas Perl priority: normal severity: normal status: open title: ARM cross-compile: pgen built without $(CFLAGS) as $(LIBRARY) dependency type: compile error versions: Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 18:47:23 2016 From: report at bugs.python.org (John Hagen) Date: Mon, 11 Jul 2016 22:47:23 +0000 Subject: [issue26988] Add AutoNumberedEnum to stdlib In-Reply-To: <1462844071.91.0.106881823757.issue26988@psf.upfronthosting.co.za> Message-ID: <1468277243.81.0.61874916056.issue26988@psf.upfronthosting.co.za> John Hagen added the comment: >class BaseZeroEnum(Enum, start=0): > "initial integer is 0" > ... I also think this looks better. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 18:48:33 2016 From: report at bugs.python.org (Jonathan Kross) Date: Mon, 11 Jul 2016 22:48:33 +0000 Subject: [issue27131] Unit test random shuffle In-Reply-To: <1464277146.71.0.570096870767.issue27131@psf.upfronthosting.co.za> Message-ID: <1468277313.5.0.441561061558.issue27131@psf.upfronthosting.co.za> Jonathan Kross added the comment: Just giving this one a bump to see if it can be applied soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 19:02:23 2016 From: report at bugs.python.org (Thomas Perl) Date: Mon, 11 Jul 2016 23:02:23 +0000 Subject: [issue27490] ARM cross-compile: pgen built without $(CFLAGS) as $(LIBRARY) dependency In-Reply-To: <1468276938.3.0.370267656827.issue27490@psf.upfronthosting.co.za> Message-ID: <1468278143.7.0.586657085728.issue27490@psf.upfronthosting.co.za> Thomas Perl added the comment: Also related: https://bugs.python.org/issue22359 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 19:33:39 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 11 Jul 2016 23:33:39 +0000 Subject: [issue27485] urllib.splitport -- is it official or not? In-Reply-To: <1468260123.51.0.000787877209911.issue27485@psf.upfronthosting.co.za> Message-ID: <1468280019.62.0.920205599857.issue27485@psf.upfronthosting.co.za> Martin Panter added the comment: Previous discussion: Issue 1722, Issue 11009. In Python 2, most of the split- functions _have_ been in urllib.__all__ since revision 5d68afc5227c (2.1). Also, since revision c3656dca65e7 (Issue 1722, 2.7.4), the RST documentation does mention that at least some of them are deprecated in favour of the ?urlparse? module. However there are no index entries, and splitport() is not mentioned by name. In Python 3, these functions wandered into urllib.parse. There is no RST documentation, and the functions are not in __all__ (which was added for Issue 13287 in 3.3). I think you can use the documented urllib.parse API instead of splitport(), but it is borderline unwieldy: >>> netloc = "[::1]:80" >>> urllib.parse.splitport(netloc) # [Brackets] kept! ('[::1]', '80') >>> split = urlsplit("//" + netloc); (split.hostname, split.port) ('::1', 80) >>> split = SplitResult("", netloc, path="", query="", fragment=""); (split.hostname, split.port) ('::1', 80) I opened Issue 23416 with a suggestion that would make SplitResult a bit simpler to use here. But maybe it makes the implementation too complicated. I don?t think the non-split-names (Quoter, etc) are in much doubt. They were never in __all__. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 20:31:53 2016 From: report at bugs.python.org (ahxxm) Date: Tue, 12 Jul 2016 00:31:53 +0000 Subject: [issue26608] RLock undocumented behavior in case of multiple acquire In-Reply-To: <1458629798.26.0.210968234517.issue26608@psf.upfronthosting.co.za> Message-ID: <1468283513.1.0.736732750909.issue26608@psf.upfronthosting.co.za> ahxxm added the comment: As seen from commit log, all return type are double back-quoted, this could be a rendering error. I think this commit somehow makes it clear that RLock is a thread-level reentrant lock, some code example of suggested usage might be helpful though. ---------- hgrepos: +348 nosy: +ahxxm _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 20:35:28 2016 From: report at bugs.python.org (Eryk Sun) Date: Tue, 12 Jul 2016 00:35:28 +0000 Subject: [issue13402] Document absoluteness of sys.executable In-Reply-To: <1321289437.84.0.982753479785.issue13402@psf.upfronthosting.co.za> Message-ID: <1468283728.32.0.260476402825.issue13402@psf.upfronthosting.co.za> Eryk Sun added the comment: "/opt/local/bin/../bin/python2.7" is an absolute path. >>> os.path.isabs('/opt/local/bin/../bin/python2.7') True It's not relative to the working directory. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 20:51:34 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 12 Jul 2016 00:51:34 +0000 Subject: [issue27485] urllib.splitport -- is it official or not? In-Reply-To: <1468260123.51.0.000787877209911.issue27485@psf.upfronthosting.co.za> Message-ID: <1468284694.69.0.644779729212.issue27485@psf.upfronthosting.co.za> Guido van Rossum added the comment: Aha. I see you are referring to this note in the 2.7 docs for urllib: urllib also exposes certain utility functions like splittype, splithost and others parsing URL into various components. But it is recommended to use :mod:`urlparse` for parsing URLs rather than using these functions directly. Python 3 does not expose these helper functions from :mod:`urllib.parse` module. This is somewhat ironic because those functions still exist in urllib.parse. I've rewritten my code using your suggestions of using urllib.parse.urlparse(). Shall we just close this issue or is there still an action item? (Maybe actually delete those functions whose deletion has been promised so long ago, or at least rename them to _splitport() etc.?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 21:45:10 2016 From: report at bugs.python.org (Ethan Furman) Date: Tue, 12 Jul 2016 01:45:10 +0000 Subject: [issue26988] Add AutoNumberedEnum to stdlib In-Reply-To: <1462844071.91.0.106881823757.issue26988@psf.upfronthosting.co.za> Message-ID: <1468287910.47.0.873138903177.issue26988@psf.upfronthosting.co.za> Ethan Furman added the comment: Here's the code. I'll do the doc changes next. ---------- keywords: +patch Added file: http://bugs.python.org/file43694/issue26988.stoneleaf.01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 21:59:34 2016 From: report at bugs.python.org (Memeplex) Date: Tue, 12 Jul 2016 01:59:34 +0000 Subject: [issue672115] Assignment to __bases__ of direct object subclasses Message-ID: <1468288774.44.0.671226097003.issue672115@psf.upfronthosting.co.za> Memeplex added the comment: I understand Michael's comment http://bugs.python.org/issue672115#msg14169 but I'm failing to see how it's directly related to this issue: as Michael himself said it's even relevant for the object-subclass-object hack or for any hierarchy whatsoever. Is the comment warning about the entire writable-bases idea? It feels to me like the behavior should be consistently extended or consistently banned, but currently some cases work, another cases don't, and there seems to be no clear rationale supporting this state of affairs. Am I wrong? ---------- nosy: +memeplex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 22:22:38 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 12 Jul 2016 02:22:38 +0000 Subject: [issue16858] tarfile silently hides errors In-Reply-To: <1357286028.6.0.98597292825.issue16858@psf.upfronthosting.co.za> Message-ID: <1468290158.35.0.446764469948.issue16858@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- Removed message: http://bugs.python.org/msg270204 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 22:22:43 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 12 Jul 2016 02:22:43 +0000 Subject: [issue16858] tarfile silently hides errors In-Reply-To: <1357286028.6.0.98597292825.issue16858@psf.upfronthosting.co.za> Message-ID: <1468290163.43.0.571162051154.issue16858@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- Removed message: http://bugs.python.org/msg270206 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 22:22:51 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 12 Jul 2016 02:22:51 +0000 Subject: [issue16858] tarfile silently hides errors In-Reply-To: <1357286028.6.0.98597292825.issue16858@psf.upfronthosting.co.za> Message-ID: <1468290171.46.0.900846157648.issue16858@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- Removed message: http://bugs.python.org/msg265967 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 22:27:39 2016 From: report at bugs.python.org (INADA Naoki) Date: Tue, 12 Jul 2016 02:27:39 +0000 Subject: [issue26081] Implement asyncio Future in C to improve performance In-Reply-To: <1452533022.97.0.443242974791.issue26081@psf.upfronthosting.co.za> Message-ID: <1468290459.19.0.614494683851.issue26081@psf.upfronthosting.co.za> INADA Naoki added the comment: Thanks. I'll working on test_asyncio in next few days. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 22:39:28 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 12 Jul 2016 02:39:28 +0000 Subject: [issue13402] Document absoluteness of sys.executable In-Reply-To: <1321289437.84.0.982753479785.issue13402@psf.upfronthosting.co.za> Message-ID: <1468291168.33.0.0513988842836.issue13402@psf.upfronthosting.co.za> Ned Deily added the comment: @blarsen, and there's something strange about your example. '-m' won't work with a real python executable, presumably you meant '-c'. And judging from the paths involved, I'm guessing you are using MacPorts on OS X. With either MacPorts or any other OS X framework build, you wouldn't see results like that with -c. ../bin/python3.5 -c 'import sys; print(sys.executable)' /opt/local/bin/python3.5 ../bin/python2.7 -c 'import sys; print(sys.executable)' /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python So I'm guessing what's in ../bin/python3.7 and ../bin/python3.5 is something other than the normal python bootstrap binaries. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 22:59:08 2016 From: report at bugs.python.org (Brad Larsen) Date: Tue, 12 Jul 2016 02:59:08 +0000 Subject: [issue13402] Document absoluteness of sys.executable In-Reply-To: <1321289437.84.0.982753479785.issue13402@psf.upfronthosting.co.za> Message-ID: <1468292348.31.0.449927782551.issue13402@psf.upfronthosting.co.za> Brad Larsen added the comment: @eryksun, you are right! The output *is* an absolute path as far as `os.path.isabs` is concerned. @ned.deily, you are right about my example --- I transcribed it wrong, and it should be `-c`. The system in question is not a Mac OS system, but a Linux system with newer Python versions than what come with the system installed to /opt/local. These are compiled from source, but without any modifications. I'm commenting here because I'm seeing the `test_sys` test from the regression suite fail in a slightly modified version of Python that ships with a product. In particular, in Lib/test/test_sys.py around line 640, we have this: @unittest.skipIf(sys.base_prefix != sys.prefix, 'Test is not venv-compatible') def test_executable(self): # sys.executable should be absolute self.assertEqual(os.path.abspath(sys.executable), sys.executable) Yes, /opt/local/bin/../bin/python3.5 is an absolute path as far as `os.path.isabs` is concerned, but `os.path.abspath('/opt/local/bin/../bin/python3.5')` gives '/opt/local/bin/python3.5', and the test fails. So maybe the documentation is fine but the test is wrong? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 11 23:05:43 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 12 Jul 2016 03:05:43 +0000 Subject: [issue13402] Document absoluteness of sys.executable In-Reply-To: <1321289437.84.0.982753479785.issue13402@psf.upfronthosting.co.za> Message-ID: <1468292743.84.0.398927952947.issue13402@psf.upfronthosting.co.za> Ned Deily added the comment: @blarsen, OK, but if you want to pursue this, please open a new issue against the current versions. This issue was closed years ago and against earlier versions so your comments will not get acted on. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 00:05:32 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 12 Jul 2016 04:05:32 +0000 Subject: [issue16858] tarfile silently hides errors In-Reply-To: <1357286028.6.0.98597292825.issue16858@psf.upfronthosting.co.za> Message-ID: <1468296332.43.0.444094294321.issue16858@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- Removed message: http://bugs.python.org/msg265966 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 00:06:34 2016 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 12 Jul 2016 04:06:34 +0000 Subject: [issue27487] -m switch regression in Python 3.5.2 (under rare circumstances) In-Reply-To: <1468268291.19.0.631980361837.issue27487@psf.upfronthosting.co.za> Message-ID: <1468296394.77.0.983351456836.issue27487@psf.upfronthosting.co.za> Nick Coghlan added the comment: Since this worked in 3.5.1, and fails in 3.5.2, I think it's reasonable to consider if it makes sense to find a way to make it work again in 3.5.3 (and then decide separately whether or not we want to preserve the capability in 3.6.0). Specifically, restoring the old behaviour would mean that: 1. *If* the -m target module already exists in sys.modules after importing the parent module; and 2. The already imported target module doesn't have a __spec__ attribute; then 3. Ignore that already imported artifact when figuring out what to run as __main__ However, the problem with doing that is that this *is* an instance of code that falls into the double-import trap: http://python-notes.curiousefficiency.org/en/latest/python_concepts/import_traps.html#executing-the-main-module-twice Even in 3.5.1, the affected module is getting executed twice - once from the package's __init__.py, and once via the "-m" switch. For cases that *don't* overwrite the module in sys.modules, a solution that resolves the issue in a backwards and forwards compatible way is to split the module being executed via -m as follows: * Move the pieces needed by mypkg.__init__ into a "mypkg._mymain_support" module * In that module, set "__name__ = 'mypkg.mymain'" to preserve pickle compatibility and docs introspection * Change both "mypkg.__init__" and "mypkg.mymain" to import the shared components from the "mypkg._mymain_support" module However, you still run into a problem with figuring out when the replacement module should be written into sys.modules - if that stays in "mypkg.mymain" it will no longer get done as a side effect of importing "mypkg", while if it moves into "mypkg._mymain_support", you'll still run into the problem reported here in 3.5.2 ---------- nosy: +brett.cannon, eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 00:35:55 2016 From: report at bugs.python.org (Michael Lazar) Date: Tue, 12 Jul 2016 04:35:55 +0000 Subject: [issue14977] mailcap does not respect precedence in the presence of wildcards In-Reply-To: <1338542933.25.0.233529643572.issue14977@psf.upfronthosting.co.za> Message-ID: <1468298155.6.0.703507932621.issue14977@psf.upfronthosting.co.za> Michael Lazar added the comment: Submitting an updated patch; simplified the implementation and updated test_mailcap.py ---------- Added file: http://bugs.python.org/file43695/mailcap_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 01:16:45 2016 From: report at bugs.python.org (Brian Herman) Date: Tue, 12 Jul 2016 05:16:45 +0000 Subject: [issue27083] PYTHONCASEOK is ignored on Windows In-Reply-To: <1463899532.05.0.0164205622545.issue27083@psf.upfronthosting.co.za> Message-ID: <1468300605.12.0.660018243063.issue27083@psf.upfronthosting.co.za> Brian Herman added the comment: In python 3.6 from hg it has been fixed. >>> glob.glob('*.py') ['setup.py', 'test.py'] >>> import test >>> test.__file__ 'C:\\Users\\brian\\Desktop\\cpython\\test.py' >>> ---------- nosy: +Brian.Herman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 01:27:00 2016 From: report at bugs.python.org (Minmin Gong) Date: Tue, 12 Jul 2016 05:27:00 +0000 Subject: [issue27491] Errors when building with UNICODE character set Message-ID: <1468301219.72.0.359104811522.issue27491@psf.upfronthosting.co.za> New submission from Minmin Gong: Switch the pythoncore's character set to UNICODE, some compile errors about Windows APIs show up. A patch is attached to fix this. ---------- components: Windows files: 0001-Fix-building-with-UNICODE-character-set.patch keywords: patch messages: 270228 nosy: Minmin.Gong, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Errors when building with UNICODE character set type: compile error versions: Python 3.5 Added file: http://bugs.python.org/file43696/0001-Fix-building-with-UNICODE-character-set.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 02:11:31 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 Jul 2016 06:11:31 +0000 Subject: [issue27481] Replace TypeError with ValueError in doc regarding "embedded NUL character" In-Reply-To: <1468227336.42.0.208326485001.issue27481@psf.upfronthosting.co.za> Message-ID: <1468303891.68.0.408732040324.issue27481@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. Thanks Xiang. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 02:15:33 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 12 Jul 2016 06:15:33 +0000 Subject: [issue27481] Replace TypeError with ValueError in doc regarding "embedded NUL character" In-Reply-To: <1468227336.42.0.208326485001.issue27481@psf.upfronthosting.co.za> Message-ID: <20160712061530.31564.92941.5973B540@psf.io> Roundup Robot added the comment: New changeset 420030a5e854 by Serhiy Storchaka in branch '3.5': Issue #27481: Docummented that ValueError is now raised instead of TypeError https://hg.python.org/cpython/rev/420030a5e854 New changeset 00b9c734af87 by Serhiy Storchaka in branch 'default': Issue #27481: Docummented that ValueError is now raised instead of TypeError https://hg.python.org/cpython/rev/00b9c734af87 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 02:16:14 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 Jul 2016 06:16:14 +0000 Subject: [issue27481] Replace TypeError with ValueError in doc regarding "embedded NUL character" In-Reply-To: <1468227336.42.0.208326485001.issue27481@psf.upfronthosting.co.za> Message-ID: <1468304174.06.0.804304768777.issue27481@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 Tue Jul 12 03:09:41 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 12 Jul 2016 07:09:41 +0000 Subject: [issue27492] Enhance bytearray_repr with bytes_repr's logic Message-ID: <1468307381.71.0.764408700488.issue27492@psf.upfronthosting.co.za> New submission from Xiang Zhang: Right now bytearray_repr's implementation mimics old string_repr, but it has a drawback: It arbitrarily checks overflow using four times the bytearray object's length, but the representation length of the value can range from 1 to 4. I think we can use bytes_repr's logic which calculates the actual output length. ---------- components: Interpreter Core files: bytearray_repr.patch keywords: patch messages: 270231 nosy: serhiy.storchaka, xiang.zhang priority: normal severity: normal status: open title: Enhance bytearray_repr with bytes_repr's logic type: enhancement versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43697/bytearray_repr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 04:50:03 2016 From: report at bugs.python.org (INADA Naoki) Date: Tue, 12 Jul 2016 08:50:03 +0000 Subject: [issue26081] Implement asyncio Future in C to improve performance In-Reply-To: <1452533022.97.0.443242974791.issue26081@psf.upfronthosting.co.za> Message-ID: <1468313403.61.0.601573175415.issue26081@psf.upfronthosting.co.za> INADA Naoki added the comment: > asyncio uses loop.create_future() to create sockets. I'd suggest you to create two base test classes: one that monkeypatches loop.create_future to return pure python Future in its setUp method; an another, that makes create_future to return a C version of the Future. windows_events.py has some classes extends futures.Future. Task extends Future. There are some `isinstance(future, futures.Future)`. So monkeypatching `baseevent.create_future` seems not enough. I want a way to completely reload asyncio and test_asyncio packages with and without C future. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 05:14:44 2016 From: report at bugs.python.org (Richard) Date: Tue, 12 Jul 2016 09:14:44 +0000 Subject: [issue27493] logging module fails with unclear error when supplied a (Posix)Path Message-ID: <1468314884.39.0.604549697605.issue27493@psf.upfronthosting.co.za> New submission from Richard: No idea if I should be reporting this here, but it came with the default installation, so here goes: On a mac, I supplied a basicConfig object to the logging class that contains a PosixPath instance for the "filename" attribute. consequently, it fails with the error message "'PosixPath' object has no attribute 'startswith'" without specifying where the issue lies. offending value: STATUSLOG_PATH = Path('~/logFiles/Reseller/').expanduser() Relevant part of the traceback (which didn't print by default): File "/Users/rhendrikse/Documents/PythonScripts/Reseller/Reseller/application/application.py", line 41, in __setup_logger logging.basicConfig(level=logging.DEBUG, format=DEFS.RUNLOG_FORMAT, filename=DEFS.RUNLOG_PATH) File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/logging/__init__.py", line 1744, in basicConfig h = FileHandler(filename, mode) File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/logging/__init__.py", line 998, in __init__ self.baseFilename = os.path.abspath(filename) File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/posixpath.py", line 357, in abspath if not isabs(path): File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/posixpath.py", line 64, in isabs return s.startswith(sep) AttributeError: 'PosixPath' object has no attribute 'startswith' ---------- components: Library (Lib) messages: 270233 nosy: rhendrikse priority: normal severity: normal status: open title: logging module fails with unclear error when supplied a (Posix)Path versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 05:24:11 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 12 Jul 2016 09:24:11 +0000 Subject: [issue27493] logging module fails with unclear error when supplied a (Posix)Path In-Reply-To: <1468314884.39.0.604549697605.issue27493@psf.upfronthosting.co.za> Message-ID: <1468315451.83.0.735449913223.issue27493@psf.upfronthosting.co.za> Berker Peksag added the comment: logging module doesn't support Path objects. You need to wrap STATUSLOG_PATH = Path('~/logFiles/Reseller/').expanduser() with str(). We could possibly add PEP 519 support to the logging module for Python 3.6. What do you think, Vinay? ---------- nosy: +berker.peksag, vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 05:46:16 2016 From: report at bugs.python.org (Richard) Date: Tue, 12 Jul 2016 09:46:16 +0000 Subject: [issue27493] logging module fails with unclear error when supplied a (Posix)Path In-Reply-To: <1468314884.39.0.604549697605.issue27493@psf.upfronthosting.co.za> Message-ID: <1468316776.5.0.684238346962.issue27493@psf.upfronthosting.co.za> Richard added the comment: Yeah, figured as much. But thanks:) I'm kind of new to Python and was having some problems determining whether this is as it should be, or if it should be improved. After all, I could not find any documentation that states what the permitted variable-types are (for pretty much any function, actually), yet print() does cast the Path()s to a string... Kind of used to the documentation format on php.net :P ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 06:29:13 2016 From: report at bugs.python.org (Jakub Stasiak) Date: Tue, 12 Jul 2016 10:29:13 +0000 Subject: [issue27494] 2to3 parser failure caused by a comma after a generator expression Message-ID: <1468319353.83.0.357995670089.issue27494@psf.upfronthosting.co.za> New submission from Jakub Stasiak: Test file (test.py): print(set(x for x in range(2),)) Python runs it nicely: % python2 test.py set([0, 1]) % python3 test.py {0, 1} 2to3 parser (on both Python 2.7.11 and 3.5.2) chokes on it though: % /usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/bin/2to3 test.py RefactoringTool: Skipping optional fixer: buffer RefactoringTool: Skipping optional fixer: idioms RefactoringTool: Skipping optional fixer: set_literal RefactoringTool: Skipping optional fixer: ws_comma RefactoringTool: Can't parse test.py: ParseError: bad input: type=8, value=u')', context=('', (1, 30)) RefactoringTool: No files need to be modified. RefactoringTool: There was 1 error: RefactoringTool: Can't parse test.py: ParseError: bad input: type=8, value=u')', context=('', (1, 30)) % /usr/local/Cellar/python3/3.5.2/Frameworks/Python.framework/Versions/3.5/bin/2to3 test.py RefactoringTool: Skipping optional fixer: buffer RefactoringTool: Skipping optional fixer: idioms RefactoringTool: Skipping optional fixer: set_literal RefactoringTool: Skipping optional fixer: ws_comma RefactoringTool: Can't parse test.py: ParseError: bad input: type=8, value=')', context=('', (1, 30)) RefactoringTool: No files need to be modified. RefactoringTool: There was 1 error: RefactoringTool: Can't parse test.py: ParseError: bad input: type=8, value=')', context=('', (1, 30)) For reference: https://github.com/smarkets/flake8-strict/issues/9 (project using lib2to3 parser) ---------- components: 2to3 (2.x to 3.x conversion tool) messages: 270236 nosy: jstasiak priority: normal severity: normal status: open title: 2to3 parser failure caused by a comma after a generator expression type: crash versions: Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 06:34:44 2016 From: report at bugs.python.org (John Mark Vandenberg) Date: Tue, 12 Jul 2016 10:34:44 +0000 Subject: [issue27494] 2to3 parser failure caused by a comma after a generator expression In-Reply-To: <1468319353.83.0.357995670089.issue27494@psf.upfronthosting.co.za> Message-ID: <1468319684.48.0.485241370297.issue27494@psf.upfronthosting.co.za> Changes by John Mark Vandenberg : ---------- nosy: +jayvdb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 07:30:29 2016 From: report at bugs.python.org (Danilo J. S. Bellini) Date: Tue, 12 Jul 2016 11:30:29 +0000 Subject: [issue27495] Pretty printing sorting for set and frozenset instances Message-ID: <1468323029.69.0.352634397545.issue27495@psf.upfronthosting.co.za> New submission from Danilo J. S. Bellini: The pprint pretty printer in Python 3 sorts sets/frozensets only if their length don't fit in one single line/row for the given width, else it was just leaving repr(my_set_instance) alone, like: >>> import string, pprint >>> pprint.pprint(set(string.digits)) {'7', '5', '2', '4', '1', '9', '6', '3', '0', '8'} That order is quite random in Python 3.2+. But on Python 2.6 and 2.7, the result is shown as: set(['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']) So for using pprint in doctests (or anything alike) with sets/frozensets, the pretty printer isn't as useful in Python 3 than it is in Python 2. The pprint tests for non-nested set/frozenset were only using some small ranges for testing. I've written a patch to solve that. ---------- components: Library (Lib) files: pprint_small_set_sorted.patch keywords: patch messages: 270237 nosy: danilo.bellini priority: normal severity: normal status: open title: Pretty printing sorting for set and frozenset instances type: behavior versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43698/pprint_small_set_sorted.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 07:52:31 2016 From: report at bugs.python.org (John Hagen) Date: Tue, 12 Jul 2016 11:52:31 +0000 Subject: [issue26988] Add AutoNumberedEnum to stdlib In-Reply-To: <1462844071.91.0.106881823757.issue26988@psf.upfronthosting.co.za> Message-ID: <1468324351.68.0.132181196062.issue26988@psf.upfronthosting.co.za> John Hagen added the comment: I like the addition of UniqueEnum. It's the default use case often. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 08:19:16 2016 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 12 Jul 2016 12:19:16 +0000 Subject: [issue27493] logging module fails with unclear error when supplied a (Posix)Path In-Reply-To: <1468314884.39.0.604549697605.issue27493@psf.upfronthosting.co.za> Message-ID: <1468325956.94.0.100036172722.issue27493@psf.upfronthosting.co.za> Vinay Sajip added the comment: > We could possibly add PEP 519 support to the logging module for Python 3.6 Seems like a reasonable enhancement for 3.6. ---------- stage: -> needs patch type: -> enhancement versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 08:25:32 2016 From: report at bugs.python.org (SilentGhost) Date: Tue, 12 Jul 2016 12:25:32 +0000 Subject: [issue27495] Pretty printing sorting for set and frozenset instances In-Reply-To: <1468323029.69.0.352634397545.issue27495@psf.upfronthosting.co.za> Message-ID: <1468326332.69.0.635233290422.issue27495@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +fdrake stage: -> patch review versions: -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 08:38:45 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 Jul 2016 12:38:45 +0000 Subject: [issue27495] Pretty printing sorting for set and frozenset instances In-Reply-To: <1468323029.69.0.352634397545.issue27495@psf.upfronthosting.co.za> Message-ID: <1468327125.8.0.348367556252.issue27495@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +rhettinger, serhiy.storchaka type: behavior -> enhancement versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 08:47:19 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 12 Jul 2016 12:47:19 +0000 Subject: [issue27473] bytes_concat seems to check overflow using undefined behaviour In-Reply-To: <1468082804.63.0.768933034734.issue27473@psf.upfronthosting.co.za> Message-ID: <20160712124716.31453.99461.220E66CF@psf.io> Roundup Robot added the comment: New changeset 130d97217e36 by Serhiy Storchaka in branch '2.7': Issue #27473: Fixed possible integer overflow in str, unicode and bytearray https://hg.python.org/cpython/rev/130d97217e36 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 08:47:47 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 Jul 2016 12:47:47 +0000 Subject: [issue27473] bytes_concat seems to check overflow using undefined behaviour In-Reply-To: <1468082804.63.0.768933034734.issue27473@psf.upfronthosting.co.za> Message-ID: <1468327667.62.0.272475192916.issue27473@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 08:47:56 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 Jul 2016 12:47:56 +0000 Subject: [issue27473] bytes_concat seems to check overflow using undefined behaviour In-Reply-To: <1468082804.63.0.768933034734.issue27473@psf.upfronthosting.co.za> Message-ID: <1468327676.18.0.18137433365.issue27473@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 08:59:00 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 Jul 2016 12:59:00 +0000 Subject: [issue27492] Enhance bytearray_repr with bytes_repr's logic In-Reply-To: <1468307381.71.0.764408700488.issue27492@psf.upfronthosting.co.za> Message-ID: <1468328340.42.0.0210222838014.issue27492@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Bytes and bytearray share a much of code. I think it is possible to share the implementation of reprs. Just add two functions in bytes_methods.c: one counts the size of the repr and determines the quote, and other writes the content of the repr in preallocated buffer. ---------- versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 09:10:49 2016 From: report at bugs.python.org (Zack Weinberg) Date: Tue, 12 Jul 2016 13:10:49 +0000 Subject: [issue27496] unicodedata.name() doesn't have names for control characters Message-ID: <1468329049.33.0.201400438769.issue27496@psf.upfronthosting.co.za> New submission from Zack Weinberg: unicodedata.name() doesn't have name information for the C0 and C1 control characters. To see this, run pprint.pprint(["U+{:04X} {}".format(n, unicodedata.name(chr(n), "")) for n in range(256)]) and you will observe printed for U+0000 through U+001F and U+007F through U+009F. These characters do have official Unicode names and they should be known to name(). I may see if I can come up with a patch for this one, in my copious free time. ---------- components: Library (Lib) messages: 270242 nosy: zwol priority: normal severity: normal status: open title: unicodedata.name() doesn't have names for control characters type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 09:20:02 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 12 Jul 2016 13:20:02 +0000 Subject: [issue14977] mailcap does not respect precedence in the presence of wildcards In-Reply-To: <1338542933.25.0.233529643572.issue14977@psf.upfronthosting.co.za> Message-ID: <1468329602.43.0.633008038672.issue14977@psf.upfronthosting.co.za> R. David Murray added the comment: I think we need to preserve backward compatibility in the readmailcapfile function even though it isn't technically a public API (make lineno a keyword argument and the behavior dependent on its presence). I haven't experimented with the patch yet, but it looks reasonable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 09:32:00 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 12 Jul 2016 13:32:00 +0000 Subject: [issue27493] logging module fails with unclear error when supplied a (Posix)Path In-Reply-To: <1468314884.39.0.604549697605.issue27493@psf.upfronthosting.co.za> Message-ID: <1468330320.64.0.787669321782.issue27493@psf.upfronthosting.co.za> R. David Murray added the comment: It will be interesting to see how much logging itself needs to be aware of PEP 519 once the support is added to posixpath. ideally, to meet the goals of PEP 519, the answer would be "not at all". @richard: python uses duck typing: if it quacks like a duck, pretend it is a duck. That means that the code (generally, there are exceptions) doesn't check for types, but just handles the object the way it normally would until it fails to quack, at which point you get an exception. Sometimes we add code to turn such exceptions into clearer error messages, when the existing error *hides* what is really going on. This would not be one of those cases though, even if supporting Path wasn't on the long term agenda: the existing error tells you that the module expects it to act like a string (support startswith, and other string methods). ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 09:35:01 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 12 Jul 2016 13:35:01 +0000 Subject: [issue27496] unicodedata.name() doesn't have names for control characters In-Reply-To: <1468329049.33.0.201400438769.issue27496@psf.upfronthosting.co.za> Message-ID: <1468330501.8.0.420319353248.issue27496@psf.upfronthosting.co.za> R. David Murray added the comment: That information is programatically generated from data files obtained from the unicode project, as far as I know. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 10:01:02 2016 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Tue, 12 Jul 2016 14:01:02 +0000 Subject: [issue27495] Pretty printing sorting for set and frozenset instances In-Reply-To: <1468323029.69.0.352634397545.issue27495@psf.upfronthosting.co.za> Message-ID: <1468332062.01.0.786824694665.issue27495@psf.upfronthosting.co.za> Fred L. Drake, Jr. added the comment: +1 It could reasonably be argued that not sorting is a bug for already-released 3.x versions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 11:08:29 2016 From: report at bugs.python.org (Eryk Sun) Date: Tue, 12 Jul 2016 15:08:29 +0000 Subject: [issue27496] unicodedata.name() doesn't have names for control characters In-Reply-To: <1468329049.33.0.201400438769.issue27496@psf.upfronthosting.co.za> Message-ID: <1468336109.3.0.336613219392.issue27496@psf.upfronthosting.co.za> Eryk Sun added the comment: Character names are in field 1 of UnicodeData.txt [1][2]. For controls the name is just "". In Tools/unicode/makunicodedata.py, the makeunicodename function skips names that start with "<". Instead of skipping the character, it could fall back on the Unicode 1.0 name (field 10), if it's defined. For controls, this is the ISO 6429 name: (10) Old name as published in Unicode 1.0 or ISO 6429 names for control functions. This field is empty unless it is significantly different from the current name for the character. No longer used in code chart production. See Name_Alias. The names of control characters are also in NameAliases.txt, which gets processed as the unicode.aliases list of (name, char) tuples. [1]: http://www.unicode.org/reports/tr44/#UnicodeData.txt [2]: http://www.unicode.org/Public/8.0.0/ucd ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 11:14:08 2016 From: report at bugs.python.org (Logan) Date: Tue, 12 Jul 2016 15:14:08 +0000 Subject: [issue27497] csv module: Add return value to DictWriter.writeheader Message-ID: <1468336448.04.0.83850338242.issue27497@psf.upfronthosting.co.za> New submission from Logan: Currently, DictWriter.writeheader() is defined like: def writeheader(self): header = dict(zip(self.fieldnames, self.fieldnames)) self.writerow(header) It would be useful to have it return the value of writerow(): def writeheader(self): header = dict(zip(self.fieldnames, self.fieldnames)) return self.writerow(header) This would useful because: 1) It would match the behavior of DictWriter.writerow 2) It would enable DictWriter.writeheader to be used in within a generator function (ala https://docs.djangoproject.com/en/1.9/howto/outputting-csv/#streaming-large-csv-files) ---------- messages: 270248 nosy: lsowen priority: normal severity: normal status: open title: csv module: Add return value to DictWriter.writeheader type: enhancement versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 11:25:57 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 12 Jul 2016 15:25:57 +0000 Subject: [issue27492] Enhance bytearray_repr with bytes_repr's logic In-Reply-To: <1468307381.71.0.764408700488.issue27492@psf.upfronthosting.co.za> Message-ID: <1468337157.11.0.976631223812.issue27492@psf.upfronthosting.co.za> Xiang Zhang added the comment: I considered that too. But I was not sure what code could go into bytes_methods.c then, Python level methods, all common parts or only tp->methods? I'll try to factor the common part out later. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 11:31:17 2016 From: report at bugs.python.org (Zachary Ware) Date: Tue, 12 Jul 2016 15:31:17 +0000 Subject: [issue27497] csv module: Add return value to DictWriter.writeheader In-Reply-To: <1468336448.04.0.83850338242.issue27497@psf.upfronthosting.co.za> Message-ID: <1468337477.34.0.0229194583904.issue27497@psf.upfronthosting.co.za> Zachary Ware added the comment: This seems like a reasonable request, but could only be done in 3.6 as it would be a new feature. ---------- keywords: +easy nosy: +zach.ware stage: -> needs patch versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 11:54:02 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 12 Jul 2016 15:54:02 +0000 Subject: [issue27498] Regression in repr() of class object Message-ID: <1468338842.06.0.843714859349.issue27498@psf.upfronthosting.co.za> New submission from Guido van Rossum: In Python 3.6, the repr() of a class includes its memory address. This is going to cause a lot of problems for tests in 3rd party code that expects the nice and clean instead of ??. I understand the desire to provide more clarity in case somehow two class objects created at different times have the same name -- but I'm not sure I like to rub the hex address in the user's face all the time. Can we please roll this back or think about a better way to reveal this that won't break so many 3rd party tests? ---------- messages: 270251 nosy: gvanrossum priority: normal severity: normal status: open title: Regression in repr() of class object versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 11:59:47 2016 From: report at bugs.python.org (Daniel Holth) Date: Tue, 12 Jul 2016 15:59:47 +0000 Subject: [issue27499] PY_SSIZE_T_CLEAN conflicts with Py_LIMITED_API Message-ID: <1468339187.51.0.412519931192.issue27499@psf.upfronthosting.co.za> New submission from Daniel Holth: When compiling my cryptacular extension https://bitbucket.org/dholth/cryptacular I noticed -DPy_LIMITED_API -DPY_SSIZE_T_CLEAN creates a binary that does not actually use the limited api. This causes segfaults on Linux but does not appear to cause problems on Windows. I found some emails suggestid PY_SSIZE_T_CLEAN was supposed to go away entirely? ---------- components: Extension Modules messages: 270252 nosy: dholth priority: normal severity: normal status: open title: PY_SSIZE_T_CLEAN conflicts with Py_LIMITED_API versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 12:03:48 2016 From: report at bugs.python.org (Brett Cannon) Date: Tue, 12 Jul 2016 16:03:48 +0000 Subject: [issue27485] urllib.splitport -- is it official or not? In-Reply-To: <1468260123.51.0.000787877209911.issue27485@psf.upfronthosting.co.za> Message-ID: <1468339428.65.0.930190909037.issue27485@psf.upfronthosting.co.za> Brett Cannon added the comment: Probably a rename is good. Question then becomes whether the old names should raise an DeprecationWarning for a release? ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 12:04:24 2016 From: report at bugs.python.org (Zack Weinberg) Date: Tue, 12 Jul 2016 16:04:24 +0000 Subject: [issue27496] unicodedata.name() doesn't have names for control characters In-Reply-To: <1468329049.33.0.201400438769.issue27496@psf.upfronthosting.co.za> Message-ID: <1468339464.22.0.161166282405.issue27496@psf.upfronthosting.co.za> Zack Weinberg added the comment: It looks to me as if NameAliases.txt is the better reference for the C0 and C1 controls. It matches the UnicodeData.txt field 10 names for most entries where the field 1 name is "", but it has names for U+0080, U+0081, U+0084, and U+0099, which have no field 10 name. The only catch is that NameAliases may have *several* names for the same character, with the same category tag, e.g. 0009;CHARACTER TABULATION;control 0009;HORIZONTAL TABULATION;control It probably makes sense to consistently use the first listed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 12:32:35 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 Jul 2016 16:32:35 +0000 Subject: [issue27499] PY_SSIZE_T_CLEAN conflicts with Py_LIMITED_API In-Reply-To: <1468339187.51.0.412519931192.issue27499@psf.upfronthosting.co.za> Message-ID: <1468341155.56.0.0822757990084.issue27499@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: First we should make PY_SSIZE_T_CLEAN mandatory for the term of at least two releases (or to the end of 2.7 support). ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 12:38:04 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 12 Jul 2016 16:38:04 +0000 Subject: [issue27498] Regression in repr() of class object In-Reply-To: <1468338842.06.0.843714859349.issue27498@psf.upfronthosting.co.za> Message-ID: <1468341484.45.0.364699525599.issue27498@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 13:16:50 2016 From: report at bugs.python.org (Daniel Holth) Date: Tue, 12 Jul 2016 17:16:50 +0000 Subject: [issue27499] PY_SSIZE_T_CLEAN conflicts with Py_LIMITED_API In-Reply-To: <1468339187.51.0.412519931192.issue27499@psf.upfronthosting.co.za> Message-ID: <1468343810.86.0.875164148314.issue27499@psf.upfronthosting.co.za> Daniel Holth added the comment: Here it is. https://mail.python.org/pipermail/python-3000/2008-November/015344.html On Sat, Nov 22, 2008 at 06:29, Barry Warsaw wrote: > > On Nov 22, 2008, at 4:05 AM, Martin v. L?wis wrote: > >> I just noticed that the Python 3 C API still contains PY_SSIZE_T_CLEAN. >> >> This macro was a transition mechanism, to allow extensions to use >> Py_ssize_t in PyArg_ParseTuple, while allowing other module continue >> to use int. >> >> In Python 3, I would like the mechanism, making Py_ssize_t the only >> valid data type for size in, say, s# parsers. >> >> Is it ok to still change that? > > Given that we just released the last planned candidate, I'd say it was too > late to change this for Python 3.0. > But we can at least document that the macro is a gone as soon as 3.0 final is out the door. -Brett ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 13:29:45 2016 From: report at bugs.python.org (Eryk Sun) Date: Tue, 12 Jul 2016 17:29:45 +0000 Subject: [issue27496] unicodedata.name() doesn't have names for control characters In-Reply-To: <1468329049.33.0.201400438769.issue27496@psf.upfronthosting.co.za> Message-ID: <1468344585.2.0.153063421034.issue27496@psf.upfronthosting.co.za> Changes by Eryk Sun : ---------- components: +Unicode nosy: +ezio.melotti, haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 13:30:10 2016 From: report at bugs.python.org (Eryk Sun) Date: Tue, 12 Jul 2016 17:30:10 +0000 Subject: [issue27496] unicodedata.name() doesn't have names for control characters In-Reply-To: <1468329049.33.0.201400438769.issue27496@psf.upfronthosting.co.za> Message-ID: <1468344610.18.0.590015260441.issue27496@psf.upfronthosting.co.za> Changes by Eryk Sun : ---------- versions: +Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 13:38:39 2016 From: report at bugs.python.org (Steve Piercy) Date: Tue, 12 Jul 2016 17:38:39 +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: <1468345119.17.0.419267194696.issue27285@psf.upfronthosting.co.za> Steve Piercy added the comment: Thanks, Ned. This was my first hg patch. I'm learning. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 13:55:35 2016 From: report at bugs.python.org (Sebastien Bourdeauducq) Date: Tue, 12 Jul 2016 17:55:35 +0000 Subject: [issue27500] ProactorEventLoop cannot open connection to ::1 Message-ID: <1468346135.06.0.410333112523.issue27500@psf.upfronthosting.co.za> New submission from Sebastien Bourdeauducq: The following code fails with "OSError: [WinError 10022] An invalid argument was supplied". import asyncio loop = asyncio.ProactorEventLoop() asyncio.set_event_loop(loop) loop.run_until_complete(asyncio.open_connection("::1", 4242)) This is a regression in 3.5.2. 3.5.1 does not have this bug. Connecting to 127.0.0.1 does not cause the problem. ---------- components: asyncio messages: 270258 nosy: gvanrossum, haypo, sebastien.bourdeauducq, yselivanov priority: normal severity: normal status: open title: ProactorEventLoop cannot open connection to ::1 versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 13:58:28 2016 From: report at bugs.python.org (Ethan Furman) Date: Tue, 12 Jul 2016 17:58:28 +0000 Subject: [issue27498] Regression in repr() of class object In-Reply-To: <1468338842.06.0.843714859349.issue27498@psf.upfronthosting.co.za> Message-ID: <1468346308.69.0.196485618386.issue27498@psf.upfronthosting.co.za> Ethan Furman added the comment: This change was done in issue25548. ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 14:00:43 2016 From: report at bugs.python.org (Daniel Holth) Date: Tue, 12 Jul 2016 18:00:43 +0000 Subject: [issue27499] PY_SSIZE_T_CLEAN conflicts with Py_LIMITED_API In-Reply-To: <1468339187.51.0.412519931192.issue27499@psf.upfronthosting.co.za> Message-ID: <1468346443.33.0.828045212284.issue27499@psf.upfronthosting.co.za> Daniel Holth added the comment: Oh, I can avoid this problem by setting Py_LIMITED_API to 0x30300000 or greater. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 14:07:23 2016 From: report at bugs.python.org (Daniel Moisset) Date: Tue, 12 Jul 2016 18:07:23 +0000 Subject: [issue27501] Create a collections.abc class that describes PEP 3118 buffer Message-ID: <1468346843.82.0.455431578723.issue27501@psf.upfronthosting.co.za> New submission from Daniel Moisset: The buffer protocol is a low level C protocol, but even if it doesn't expose a specific python API, it's currently not possible to say "this object implements the buffer protocol" in Python This might be useful for some applications, including PEP-484 typing hints. It would be useful to have a collections.abc.Buffer which already registers the types that already support the protocol (bytes, strings, array.array, struct, mmap, ctype arrays/pointers, etc) ---------- messages: 270261 nosy: Daniel Moisset priority: normal severity: normal status: open title: Create a collections.abc class that describes PEP 3118 buffer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 14:09:55 2016 From: report at bugs.python.org (Daniel Moisset) Date: Tue, 12 Jul 2016 18:09:55 +0000 Subject: [issue27501] Create a collections.abc class that describes PEP 3118 buffer In-Reply-To: <1468346843.82.0.455431578723.issue27501@psf.upfronthosting.co.za> Message-ID: <1468346995.28.0.255829110667.issue27501@psf.upfronthosting.co.za> Changes by Daniel Moisset : ---------- components: +Library (Lib) type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 14:45:27 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 12 Jul 2016 18:45:27 +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: <1468349127.19.0.0986207256671.issue25548@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'm also echoing this... It breaks too many tests. I filed issue27498. ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 14:46:27 2016 From: report at bugs.python.org (Sebastien Bourdeauducq) Date: Tue, 12 Jul 2016 18:46:27 +0000 Subject: [issue27500] ProactorEventLoop cannot open connection to ::1 In-Reply-To: <1468346135.06.0.410333112523.issue27500@psf.upfronthosting.co.za> Message-ID: <1468349187.3.0.334205542839.issue27500@psf.upfronthosting.co.za> Sebastien Bourdeauducq added the comment: The first offending commit is this one: https://github.com/python/cpython/commit/03df54d549173e17e1cf9a767199de32a363aa6b more specifically "return af, type, proto, '', (host, port)". For IPv6, it should be "(host, port, flow info, scope id)" instead of just "(host, port)". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 14:53:48 2016 From: report at bugs.python.org (Brett Cannon) Date: Tue, 12 Jul 2016 18:53:48 +0000 Subject: [issue27498] Regression in repr() of class object In-Reply-To: <1468338842.06.0.843714859349.issue27498@psf.upfronthosting.co.za> Message-ID: <1468349628.85.0.745159500852.issue27498@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +kushal.das _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 15:09:33 2016 From: report at bugs.python.org (Dhiraj) Date: Tue, 12 Jul 2016 19:09:33 +0000 Subject: [issue27502] Python -m Module Vulnerable to Buffer Over Flow. Message-ID: <1468350573.84.0.544949544506.issue27502@psf.upfronthosting.co.za> New submission from Dhiraj: Hello Sir , The Module of Python " -m SimpleHTTPServer " is vulnerable to Buffer Over Flow. Step : I have prepared a python script which is sending more than 5000+ Values to the Module in GET Method , and as soon as , I run that Script , the Python -m SimpleHTTPServer which is running on the Victim's system Generator?s a huge Line or Error where as Exception handling is not done Proper , as if the Server do not get crash , but if the fuzzing script is run again and again it gets Crashed , and Buffer Over Flow is been Taken place. In our Scenario Kali Linux machine is victims system running the server module and Linux Mint is sending the fuzzing script. Please have a look on the POC below. I ll be happy to hear from the team. Thank You ---------- files: POC-Python.zip messages: 270264 nosy: DhirajMishra priority: normal severity: normal status: open title: Python -m Module Vulnerable to Buffer Over Flow. type: security 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/file43699/POC-Python.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 15:34:27 2016 From: report at bugs.python.org (Marcus Cobden) Date: Tue, 12 Jul 2016 19:34:27 +0000 Subject: [issue27415] regression: BaseEventLoop.create_server does not accept port=None In-Reply-To: <1467211561.08.0.329801464417.issue27415@psf.upfronthosting.co.za> Message-ID: <1468352067.47.0.066618090696.issue27415@psf.upfronthosting.co.za> Changes by Marcus Cobden : ---------- title: BaseEventLoop.create_server does not accept port=None -> regression: BaseEventLoop.create_server does not accept port=None _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 15:47:42 2016 From: report at bugs.python.org (Steve Holden) Date: Tue, 12 Jul 2016 19:47:42 +0000 Subject: [issue15443] datetime module has no support for nanoseconds In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za> Message-ID: <1468352862.55.0.355025406707.issue15443@psf.upfronthosting.co.za> Steve Holden added the comment: Just wanted to add a couple of comments here in case there's any interest. In our missions to make the world's market data available we deal with financial exchanges, many of whom are already recording event data at nanosecond resolution. Further, I believe the decision to use a separate nanoseconds field to be essentially correct. While it may well introduce some arithmetical complexity its value in backwards compatibility should be regarded as paramount. If I understand it correctly, the new nanosecond resolution times would continue to be correctly handled (module loss of nanosecond resolution) when handled as current microsecond date-times. ---------- nosy: +holdenweb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 15:52:18 2016 From: report at bugs.python.org (Steve Holden) Date: Tue, 12 Jul 2016 19:52:18 +0000 Subject: [issue15443] datetime module has no support for nanoseconds In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za> Message-ID: <1468353138.0.0.562512329327.issue15443@psf.upfronthosting.co.za> Steve Holden added the comment: Just wanted to add a couple of comments here in case there's any interest. In our missions to make the world's market data available we deal with financial exchanges, many of whom are already recording event data at nanosecond resolution. Further, I believe the decision to use a separate nanoseconds field to be essentially correct. While it may well introduce some arithmetical complexity its value in backwards compatibility should be regarded as paramount. If I understand it correctly, the new nanosecond resolution times would continue to be correctly handled (module loss of nanosecond resolution) when handled as current microsecond date-times. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 15:55:26 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 12 Jul 2016 19:55:26 +0000 Subject: [issue27502] Python -m Module Vulnerable to Buffer Over Flow. In-Reply-To: <1468350573.84.0.544949544506.issue27502@psf.upfronthosting.co.za> Message-ID: <1468353326.83.0.356533097955.issue27502@psf.upfronthosting.co.za> R. David Murray added the comment: Your screenshots don't show any evidence of a crash. I don't see any buffer overflow here, just normal python error messages. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 16:35:00 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 Jul 2016 20:35:00 +0000 Subject: [issue15443] datetime module has no support for nanoseconds In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za> Message-ID: <1468355700.55.0.20955687795.issue15443@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- Removed message: http://bugs.python.org/msg270265 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 16:38:15 2016 From: report at bugs.python.org (Tim Graham) Date: Tue, 12 Jul 2016 20:38:15 +0000 Subject: [issue27498] Regression in repr() of class object In-Reply-To: <1468338842.06.0.843714859349.issue27498@psf.upfronthosting.co.za> Message-ID: <1468355895.91.0.999290402016.issue27498@psf.upfronthosting.co.za> Changes by Tim Graham : ---------- nosy: +Tim.Graham _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 18:04:55 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Jul 2016 22:04:55 +0000 Subject: [issue27497] csv module: Add return value to DictWriter.writeheader In-Reply-To: <1468336448.04.0.83850338242.issue27497@psf.upfronthosting.co.za> Message-ID: <1468361095.53.0.139091629468.issue27497@psf.upfronthosting.co.za> STINNER Victor added the comment: It doesn't seem right to me. The writer should be blocking: write *all* data, don't use partial write. Supporting partial write (non-blocking files) requires more changes, and it isn't worth it. Here the problem is that the function doesn't support partial write. Each time, it tries to write the full content. What is your use case? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 18:06:51 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Jul 2016 22:06:51 +0000 Subject: [issue8538] Add FlagAction to argparse In-Reply-To: <1272303487.22.0.380388489779.issue8538@psf.upfronthosting.co.za> Message-ID: <1468361211.43.0.958973645985.issue8538@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm sorry but there is no activity since 4 years, so I guess that the feature is not common enough to require a builtin support in argparse. ---------- nosy: +haypo resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 18:09:32 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Jul 2016 22:09:32 +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: <1468361372.14.0.168737589322.issue26446@psf.upfronthosting.co.za> STINNER Victor added the comment: Brett: "Thanks for the patch, Evelyn! The latest one LGTM and I will commit it when I have time." Ok, so are you going to push it? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 18:11:59 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Jul 2016 22:11:59 +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: <1468361519.83.0.659927776913.issue27180@psf.upfronthosting.co.za> STINNER Victor added the comment: patch27180. LGTM. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 18:24:33 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 12 Jul 2016 22:24:33 +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: <20160712222430.18887.15359.FFB59699@psf.io> Roundup Robot added the comment: New changeset 3e44c449433a by Yury Selivanov in branch '3.5': Issue #27392: Add loop.connect_accepted_socket(). https://hg.python.org/cpython/rev/3e44c449433a New changeset 2f0716009132 by Yury Selivanov in branch 'default': Merge 3.5 (issue #27392) https://hg.python.org/cpython/rev/2f0716009132 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 18:25:07 2016 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 12 Jul 2016 22:25: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: <1468362307.31.0.656697354878.issue27392@psf.upfronthosting.co.za> Yury Selivanov added the comment: Let's keep this issue open until we have the docs updated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 19:03:17 2016 From: report at bugs.python.org (Brett Cannon) Date: Tue, 12 Jul 2016 23:03:17 +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: <1468364597.16.0.528075860912.issue26446@psf.upfronthosting.co.za> Brett Cannon added the comment: I figured Berker was/had when he did the review, but I can take care of it when I get around to it (prioritizing 3.6 features ATM). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 19:32:11 2016 From: report at bugs.python.org (Maxim Sobolev) Date: Tue, 12 Jul 2016 23:32:11 +0000 Subject: [issue27503] support RUSAGE_THREAD as a constant in the resource module Message-ID: <1468366331.88.0.761138440335.issue27503@psf.upfronthosting.co.za> New submission from Maxim Sobolev: This is duplicate of the #10440, which has been added in 2010 into 3.x but never merged. ---------- files: patch-Modules_resource.c messages: 270275 nosy: Maxim Sobolev priority: normal severity: normal status: open title: support RUSAGE_THREAD as a constant in the resource module type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file43700/patch-Modules_resource.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 19:38:25 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 12 Jul 2016 23:38:25 +0000 Subject: [issue27498] Regression in repr() of class object In-Reply-To: <1468338842.06.0.843714859349.issue27498@psf.upfronthosting.co.za> Message-ID: <1468366705.15.0.099801153725.issue27498@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 19:50:16 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 12 Jul 2016 23:50:16 +0000 Subject: [issue27497] csv module: Add return value to DictWriter.writeheader In-Reply-To: <1468336448.04.0.83850338242.issue27497@psf.upfronthosting.co.za> Message-ID: <1468367416.85.0.599813080527.issue27497@psf.upfronthosting.co.za> R. David Murray added the comment: It isn't documented that writer.writeline returns anything, but what it actually returns is whatever the write method of the underlying file object returns. Obviously (given the linked example), this fact is being used. There is value in consistency, so I think we should make this change. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 19:56:59 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 12 Jul 2016 23:56:59 +0000 Subject: [issue27503] support RUSAGE_THREAD as a constant in the resource module In-Reply-To: <1468366331.88.0.761138440335.issue27503@psf.upfronthosting.co.za> Message-ID: <1468367819.97.0.250521461218.issue27503@psf.upfronthosting.co.za> R. David Murray added the comment: Enhancements only go into the next feature release, which is what happened. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 20:40:21 2016 From: report at bugs.python.org (Mitchell Model) Date: Wed, 13 Jul 2016 00:40:21 +0000 Subject: [issue27504] Missing assertion methods in unittest documentation Message-ID: <1468370421.07.0.622363937754.issue27504@psf.upfronthosting.co.za> New submission from Mitchell Model: In looking at the source for unittest.TestCase I was very surprised to see quite a few assertion methods that are not included in the module documentation. Every available assertion method should be included in the library documentation. Users should not have to look at the source to see what's available ? in fact, why would it even occur to the typical user to do that? Also, I think the phrase "provides several assert methods to check for and report failures" is an understatement ? it provides MANY assert methods. I think "assertion method" is a better term than "assert method". ---------- assignee: docs at python components: Documentation messages: 270278 nosy: MLModel, docs at python priority: normal severity: normal status: open title: Missing assertion methods in unittest documentation type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 20:44:08 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 13 Jul 2016 00:44:08 +0000 Subject: [issue27487] -m switch regression in Python 3.5.2 (under rare circumstances) In-Reply-To: <1468268291.19.0.631980361837.issue27487@psf.upfronthosting.co.za> Message-ID: <1468370648.54.0.85836846068.issue27487@psf.upfronthosting.co.za> Martin Panter added the comment: In trying to understand this, I built a package with two simple files: $ cat package/*.py # package/__init__.py: from . import module # package/module.py: import sys sys.modules[__name__] = object() With this I can reproduce your __spec__ error, and I see it works without error in 3.5.0 and 2.7.11. FWIW, with the current 3.3 branch, I get a different error: /media/disk/home/proj/python/cpython/python: Error while finding loader for 'package.module' (: 'object' object has no attribute '__loader__') The revision that causes the regression is 3202d143a194. Since I made that change, I feel responsible for it. But I don?t have much time ATM to come up with an ideal solution. One quick solution would be to revert my change, but since this is an obscure use case, I am not enthusiastic about doing that :) Is it possible to set the __spec__ attribute to work around the problem? I don?t really understand the ?module spec? business, but ?runpy? seems to rely on that attribute. Is replacing sys.modules entries like this even supported usage? Even in 3.5.0, I can still produce the error by importing the package before using runpy: $ python3.5 -c 'import runpy, package; runpy.run_module("package.module")' Traceback (most recent call last): File "/usr/lib/python3.5/runpy.py", line 104, in _get_module_details spec = importlib.util.find_spec(mod_name) File "/usr/lib/python3.5/importlib/util.py", line 99, in find_spec raise ValueError('{}.__spec__ is not set'.format(name)) from None ValueError: package.module.__spec__ is not set The above exception was the direct cause of the following exception: Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.5/runpy.py", line 178, in run_module mod_name, mod_spec, code = _get_module_details(mod_name) File "/usr/lib/python3.5/runpy.py", line 110, in _get_module_details raise ImportError(msg.format(mod_name, type(ex), ex)) from ex ImportError: Error while finding spec for 'package.module' (: package.module.__spec__ is not set) [Exit 1] Wolfgang: Do you want to propose a specific wording to add to the documentation? Maybe something like ?runpy and the ?python -m? option require that after the module is imported, it should have a __spec__ attribute?. Where should this go? In the runpy, command line, and/or What?s New documentation? FWIW, 2.7.11 gives an even stranger error; perhaps this is a different bug: $ python2.7 -c 'import runpy, package.module; runpy.run_module("package.module")' Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/runpy.py", line 170, in run_module mod_name, loader, code, fname = _get_module_details(mod_name) File "/usr/lib/python2.7/runpy.py", line 101, in _get_module_details loader = get_loader(mod_name) File "/usr/lib/python2.7/pkgutil.py", line 464, in get_loader return find_loader(fullname) File "/usr/lib/python2.7/pkgutil.py", line 474, in find_loader for importer in iter_importers(fullname): File "/usr/lib/python2.7/pkgutil.py", line 424, in iter_importers if fullname.startswith('.'): AttributeError: 'object' object has no attribute 'startswith' [Exit 1] ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 20:47:07 2016 From: report at bugs.python.org (Ned Deily) Date: Wed, 13 Jul 2016 00:47:07 +0000 Subject: [issue27504] Missing assertion methods in unittest documentation In-Reply-To: <1468370421.07.0.622363937754.issue27504@psf.upfronthosting.co.za> Message-ID: <1468370827.26.0.0205603834489.issue27504@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +ezio.melotti, michael.foord, rbcollins versions: +Python 3.6 -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 21:03:24 2016 From: report at bugs.python.org (Demur Rumed) Date: Wed, 13 Jul 2016 01:03:24 +0000 Subject: [issue27078] Make f'' strings faster than .format: BUILD_STRING opcode? In-Reply-To: <1463858316.54.0.292581402272.issue27078@psf.upfronthosting.co.za> Message-ID: <1468371804.75.0.0144011224425.issue27078@psf.upfronthosting.co.za> Demur Rumed added the comment: The simplest perf fix is to first use BUILD_TUPLE instead of BUILD_LIST timeit 'x=1;(x,x,x)' 0.36 usec per loop timeit 'x=1;[x,x,x]' 0.425 usec per loop Introducing a new opcode BUILD_STRING to inline PyTuple_New + PyUnicode_Join to replace BUILD_TUPLE + CALL_FUNCTION should benchmark against BUILD_TUPLE version, not BUILD_LIST + CALL_FUNCTION ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 21:10:15 2016 From: report at bugs.python.org (Demur Rumed) Date: Wed, 13 Jul 2016 01:10:15 +0000 Subject: [issue27078] Make f'' strings faster than .format: BUILD_STRING opcode? In-Reply-To: <1463858316.54.0.292581402272.issue27078@psf.upfronthosting.co.za> Message-ID: <1468372215.18.0.225841035794.issue27078@psf.upfronthosting.co.za> Demur Rumed added the comment: Benchmarked f'X is {x}' with BUILD_TUPLE change: Before: 6.62 usec per loop After: 6.33 usec per loop f'X is {x} {x+2} {x+3}' Before: 15.1 usec per loop After: 14.7 usec per loop Attached patch ---------- keywords: +patch Added file: http://bugs.python.org/file43701/fstrtup.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 21:15:26 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 13 Jul 2016 01:15:26 +0000 Subject: [issue27504] Missing assertion methods in unittest documentation In-Reply-To: <1468370421.07.0.622363937754.issue27504@psf.upfronthosting.co.za> Message-ID: <1468372526.28.0.259522485422.issue27504@psf.upfronthosting.co.za> R. David Murray added the comment: If you are looking at the source, you can look at the source. If you are looking at the documentation, we believe they are all documented. If you use pydoc/help, they are all documented. I can't find the phrase you cite, but 'assert methods' is correct: all of the method names start with the word 'assert'. If there are specific methods you think are *not* in the library reference that you think should be, please give examples. I suspect they will turn out to be internal helper functions. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 21:22:14 2016 From: report at bugs.python.org (Michael Lazar) Date: Wed, 13 Jul 2016 01:22:14 +0000 Subject: [issue14977] mailcap does not respect precedence in the presence of wildcards In-Reply-To: <1338542933.25.0.233529643572.issue14977@psf.upfronthosting.co.za> Message-ID: <1468372934.48.0.701508068184.issue14977@psf.upfronthosting.co.za> Michael Lazar added the comment: I can certainly do that. Although in addition to adding a keyword argument, we would also have to change the return signature to switch between modes like this: if lineno is None: return caps else: return caps, lineno Overall I'm not a fan of this technique and would like to avoid it if possible. The problem is that we have to keep track of the current line between successive calls to readmailcapfile(). An alternative would be to go back to using lineno as a generator. This is close to what I had in the initial patch. lineno = itertools.count() caps = readmailcapfile(fp, lineno=lineno) caps = readmailcapfile(fp2, lineno=lineno) caps = readmailcapfile(fp3, lineno=lineno) ...etc Happy to hear any insights you have on this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 21:30:42 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 13 Jul 2016 01:30:42 +0000 Subject: [issue14977] mailcap does not respect precedence in the presence of wildcards In-Reply-To: <1338542933.25.0.233529643572.issue14977@psf.upfronthosting.co.za> Message-ID: <1468373442.26.0.838223431287.issue14977@psf.upfronthosting.co.za> R. David Murray added the comment: How about this: rename the existing readmailcapfile as an internal _readmailcapfile with the new signature. Then add a backward compatible readmailcapfile with the existing signature/return value that uses a dummy value for lineno and throws away the lineno on output. The point here is just to avoid breaking programs that are using the existing api, even though it is an internal one. Yes, it is cruft, but backward compatibility sometimes requires cruft. We could deprecate the old api with a message that says it is an internal method and should not be used, and see if anyone complains about it being deprecated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 21:32:01 2016 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 13 Jul 2016 01:32:01 +0000 Subject: [issue27505] Missing documentation for setting module __class__ attribute Message-ID: <1468373521.97.0.915242819681.issue27505@psf.upfronthosting.co.za> New submission from Nick Coghlan: Python 3.5 added the ability to set module __class__ attributes by way of http://bugs.python.org/issue22986 However, this isn't covered in the What's New guide or anywhere else in the documentation, and even in the NEWS file it appears under the cryptic title "Issue #22986: Allow changing an object?s __class__ between a dynamic type and static type in some cases." for 3.5.0a1 This should be documented somewhere (perhaps in the data model section of the language reference?) and an example given of using the feature to emit DeprecationWarning for access to a particular module level attribute. It should also be mentioned in the Python 3.5 What's New documentation. ---------- assignee: docs at python components: Documentation messages: 270285 nosy: docs at python, ncoghlan, njs priority: normal severity: normal stage: needs patch status: open title: Missing documentation for setting module __class__ attribute type: enhancement versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 21:32:13 2016 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 13 Jul 2016 01:32:13 +0000 Subject: [issue27505] Missing documentation for setting module __class__ attribute In-Reply-To: <1468373521.97.0.915242819681.issue27505@psf.upfronthosting.co.za> Message-ID: <1468373533.69.0.853583708052.issue27505@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- dependencies: +Improved handling of __class__ assignment _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 21:33:02 2016 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 13 Jul 2016 01:33:02 +0000 Subject: [issue22986] Improved handling of __class__ assignment In-Reply-To: <1417563561.24.0.575634102448.issue22986@psf.upfronthosting.co.za> Message-ID: <1468373582.48.0.273236674348.issue22986@psf.upfronthosting.co.za> Nick Coghlan added the comment: Just noting I filed http://bugs.python.org/issue27505 regarding the lack of documentation for the new-in-Python-3.5 ability to set module __class__ attributes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 21:34:39 2016 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 13 Jul 2016 01:34:39 +0000 Subject: [issue27487] -m switch regression in Python 3.5.2 (under rare circumstances) In-Reply-To: <1468268291.19.0.631980361837.issue27487@psf.upfronthosting.co.za> Message-ID: <1468373679.94.0.910012510401.issue27487@psf.upfronthosting.co.za> Nick Coghlan added the comment: Breaking down a few of the moving parts here: * Yes, modules replacing themselves in sys.modules as a side effect of import is supported behaviour (it's why the import system looks them up by name in sys.modules as the final step, rather than just returning whatever the loader returns) * the dependency on __spec__ attributes is actually in importlib, where following PEP 351 Brett has been pushing hard to ensure modules always have a __spec__ attribute so the rest of the import system (including, indirectly, runpy) can rely on having it available (however, as seen here, not everything in sys.modules is going to be a module, so we may need to either keep more of the workarounds that help tolerate folks breaking that assumption, or else find a way to try to enforce it even for custom objects) * explicitly copying __spec__ from the original module object to the replacement object (in Wolfgang's code) should indeed be enough to get the use case reported here restored to the way it behaved in 3.5.1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 21:36:05 2016 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 13 Jul 2016 01:36:05 +0000 Subject: [issue27487] -m switch regression in Python 3.5.2 (under rare circumstances) In-Reply-To: <1468268291.19.0.631980361837.issue27487@psf.upfronthosting.co.za> Message-ID: <1468373765.92.0.162454170839.issue27487@psf.upfronthosting.co.za> Nick Coghlan added the comment: Oops, that PEP reference was meant to be PEP 451 (which added the __spec__ attribute and the concept of module specs as something distinct from the modules themselves) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 22:13:26 2016 From: report at bugs.python.org (Mitchell Model) Date: Wed, 13 Jul 2016 02:13:26 +0000 Subject: [issue27504] Missing assertion methods in unittest documentation In-Reply-To: <1468372526.28.0.259522485422.issue27504@psf.upfronthosting.co.za> Message-ID: <10F6A097-592C-4112-9527-E14E867BDB99@software-concepts.org> Mitchell Model added the comment: My strong apology. I missed a section of the documentation. It didn't seem possible that they weren't there, but I made a mistake when I checked for them. Sorry. > On Jul 12, 2016, at 9:15 PM, R. David Murray wrote: > > > R. David Murray added the comment: > > If you are looking at the source, you can look at the source. If you are looking at the documentation, we believe they are all documented. If you use pydoc/help, they are all documented. > > I can't find the phrase you cite, but 'assert methods' is correct: all of the method names start with the word 'assert'. > > If there are specific methods you think are *not* in the library reference that you think should be, please give examples. I suspect they will turn out to be internal helper functions. > > ---------- > nosy: +r.david.murray > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 22:37:49 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 13 Jul 2016 02:37:49 +0000 Subject: [issue19142] Cross-compile fails trying to execute foreign pgen on build host In-Reply-To: <1380670898.69.0.308819053325.issue19142@psf.upfronthosting.co.za> Message-ID: <1468377469.03.0.553313001511.issue19142@psf.upfronthosting.co.za> Martin Panter added the comment: Since 2.7.12 and 3.5.2, pgen should not be executed when in cross-compilation mode, thanks to Issue 22359 and Issue 22625. So I suspect the main problem is basically solved now. Even though it should no longer be used, pgen is still cross-compiled depending on the timestamps and ?make touch?. (Evidence: Issue 27490.) My guess of why ?make touch? did not work for Trevor was that he was compiling Python 2. In this case, ?make touch? was added in revision da3f4774b939, and still only affects two files, neither of which are generated by pgen. Maybe Python 2?s ?make touch? rule could be expanded for other generated files including Include/graminit.h etc. ---------- nosy: +martin.panter superseder: -> When cross-compiling, don?t try to execute binaries _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 22:50:12 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 13 Jul 2016 02:50:12 +0000 Subject: [issue27504] Missing assertion methods in unittest documentation In-Reply-To: <1468370421.07.0.622363937754.issue27504@psf.upfronthosting.co.za> Message-ID: <1468378212.51.0.0088927237223.issue27504@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 22:55:17 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 13 Jul 2016 02:55:17 +0000 Subject: [issue19027] undefined symbol: _PyParser_Grammar In-Reply-To: <1379265648.95.0.708128098895.issue19027@psf.upfronthosting.co.za> Message-ID: <1468378517.26.0.873438621103.issue19027@psf.upfronthosting.co.za> Martin Panter added the comment: The same $(GRAMMAR_H) dependency and touch command still exists today, so I suspect this is still valid (though I didn?t try to reproduce it). I think we need to figure out if you can write a proper makefile rule that handles a single command that updates two targets at once. FWIW I don?t think ?make touch? will currently help on Python 2, because it only affects two files that are generated by pgen (see also my comment in Issue 19142). ---------- nosy: +martin.panter stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 23:13:57 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 13 Jul 2016 03:13:57 +0000 Subject: [issue27490] ARM cross-compile: pgen built without $(CFLAGS) as $(LIBRARY) dependency In-Reply-To: <1468276938.3.0.370267656827.issue27490@psf.upfronthosting.co.za> Message-ID: <1468379637.77.0.281727750601.issue27490@psf.upfronthosting.co.za> Martin Panter added the comment: I don?t know the details of how Python uses CFLAGS etc, but according to and , the general convention may be that CFLAGS and LDFLAGS are only for _compiler_ and _linker_ flags respectively, and CFLAGS may not be used for a link step. Why don?t you either use CC="arm-none-eabi-gcc -mfloat-abi=hard", or LDFLAGS="-mfloat-abi=hard"? If these options work for you, perhaps what we really need is better documentation of how to build Python. Ideally I would also like to make it so that compiling pgen is not necessary. But I think we can only use Gnu Make extensions if they are harmless in other operating systems (e.g. we have to keep the makefile compatible with BSD Make, though maybe it is okay to require Gnu Make for cross compiling). In I left some rambling thoughts on ways to make the file regeneration like pgen does less automatic and more up to the user to control. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 23:16:56 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 13 Jul 2016 03:16:56 +0000 Subject: [issue22981] Use CFLAGS when extracting multiarch In-Reply-To: <1417537230.69.0.64347205768.issue22981@psf.upfronthosting.co.za> Message-ID: <1468379816.93.0.705136152968.issue22981@psf.upfronthosting.co.za> Martin Panter added the comment: Why do you set CFLAGS=-m32? When I cross-compile a 32-bit Python on a 64-bit host, I set CC="gcc -m32" instead. (Otherwise, I would have to specify LDFLAGS="-m32" as well.) ---------- components: +Build nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 23:19:46 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 13 Jul 2016 03:19:46 +0000 Subject: [issue27133] python 3.5.1 will not compile because libffi module uses wrong CFLAGS In-Reply-To: <1464299251.55.0.694249257494.issue27133@psf.upfronthosting.co.za> Message-ID: <1468379986.75.0.082662065707.issue27133@psf.upfronthosting.co.za> Martin Panter added the comment: In the original report you mentioned a linker error caused by not using ?-m64? from CFLAGS. Perhaps would it make more sense to add LDFLAGS=?-m64?, or use CC=?cc -m64? instead? There is also Issue 27490 and Issue 22981, both apparently about setting the ABI with CFLAGS. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 12 23:41:21 2016 From: report at bugs.python.org (frank-e) Date: Wed, 13 Jul 2016 03:41:21 +0000 Subject: [issue27449] pip install --upgrade pip (Windows) In-Reply-To: <1467637705.46.0.30850712587.issue27449@psf.upfronthosting.co.za> Message-ID: <1468381281.11.0.776264847225.issue27449@psf.upfronthosting.co.za> frank-e added the comment: Thanks, worked, most likely an error on my side (command line window without admin rights). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 00:08:13 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 13 Jul 2016 04:08:13 +0000 Subject: [issue27498] Regression in repr() of class object In-Reply-To: <1468338842.06.0.843714859349.issue27498@psf.upfronthosting.co.za> Message-ID: <1468382893.61.0.908976084814.issue27498@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 00:14:42 2016 From: report at bugs.python.org (Kushal Das) Date: Wed, 13 Jul 2016 04:14:42 +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: <1468383282.82.0.236668696397.issue25548@psf.upfronthosting.co.za> Kushal Das added the comment: The NEWS file got a typo. Thanks for noticing that. This change did require a lot of updates to the tests. If rest of the people agrees to revert this change, then we should go ahead and do it. Just wondering if Raymond has anything to add. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 00:22:01 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 13 Jul 2016 04:22:01 +0000 Subject: [issue25393] 'resource' module documentation error In-Reply-To: <1444746542.39.0.814536865396.issue25393@psf.upfronthosting.co.za> Message-ID: <1468383721.59.0.779072048118.issue25393@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- keywords: +easy nosy: +berker.peksag stage: -> needs patch type: enhancement -> behavior versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 01:15:46 2016 From: report at bugs.python.org (lissacoffeyx) Date: Wed, 13 Jul 2016 05:15:46 +0000 Subject: [issue10225] Fix doctest runable examples in python manual In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za> Message-ID: <1468386946.95.0.18488816979.issue10225@psf.upfronthosting.co.za> lissacoffeyx added the comment: I had a thought that it made the template more readable, but the better solution was to just use real newlines instead of '\n'. Thanks http://www.fixithere.net/sky-customer-service/ ---------- nosy: +lissacoffeyx -andymaier, belopolsky, docs at python, eric.araujo, ezio.melotti, georg.brandl, lukasz.langa, rhettinger, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 01:23:27 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 13 Jul 2016 05:23:27 +0000 Subject: [issue10225] Fix doctest runable examples in python manual In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za> Message-ID: <1468387407.2.0.157669363054.issue10225@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +andymaier, belopolsky, docs at python, eric.araujo, ezio.melotti, georg.brandl, lukasz.langa, rhettinger, terry.reedy -lissacoffeyx _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 01:23:46 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 13 Jul 2016 05:23:46 +0000 Subject: [issue10225] Fix doctest runable examples in python manual In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za> Message-ID: <1468387426.76.0.573620459145.issue10225@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- Removed message: http://bugs.python.org/msg270297 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 02:44:35 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 13 Jul 2016 06:44:35 +0000 Subject: [issue27492] Enhance bytearray_repr with bytes_repr's logic In-Reply-To: <1468307381.71.0.764408700488.issue27492@psf.upfronthosting.co.za> Message-ID: <1468392275.7.0.989121761799.issue27492@psf.upfronthosting.co.za> Xiang Zhang added the comment: Hi, Serhiy. I've tried one version factoring the common parts out. I make them one function but it seems not very elegant. I also think about passing the object and use it to get the type and then determine how to get the string, what the pre/postfix are, and the exception message, but that seems not elegant either. And I don't figure out what the two function's advantage. Let me know your considerations. BTW, I am still not sure repr could be put into bytes_methods.c. The functions in it are all tp->methods. ---------- Added file: http://bugs.python.org/file43702/_Py_bytes_repr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 02:54:31 2016 From: report at bugs.python.org (Michael Lazar) Date: Wed, 13 Jul 2016 06:54:31 +0000 Subject: [issue14977] mailcap does not respect precedence in the presence of wildcards In-Reply-To: <1338542933.25.0.233529643572.issue14977@psf.upfronthosting.co.za> Message-ID: <1468392871.92.0.369385722326.issue14977@psf.upfronthosting.co.za> Michael Lazar added the comment: That works for me, patch updated to match your suggestion. So to recap, the proposed fix implements the following changes to the api: getcaps() The returned dict now has an additional `lineno` field. There's a *slim* chance that this could break behavior for somebody who relies on the output for something other than passing it to findmatch(). readmailcapfiles() Marked as deprecated, but the behavior will remain the same. lookup(caps, ...) If the caps dict contains `lineno`, the metadata will be used to sort the matching entries. If the caps dict does not contain `lineno`, for example if it was constructed manually, the behavior will remain the same. findmatch(caps, ...) Same as lookup() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 04:24:31 2016 From: report at bugs.python.org (Wolfgang Maier) Date: Wed, 13 Jul 2016 08:24:31 +0000 Subject: [issue27487] -m switch regression in Python 3.5.2 (under rare circumstances) In-Reply-To: <1468268291.19.0.631980361837.issue27487@psf.upfronthosting.co.za> Message-ID: <1468398271.35.0.252294678744.issue27487@psf.upfronthosting.co.za> Wolfgang Maier added the comment: @Martin and regarding Python3.3: Right, you cannot do the replacement when running the module as __main__. For my use case that's not required though so in the module I can just do: if __name__ == '__main__': print('running module as a script') else: # do not attempt this when __name__ == '__main__' in Python 3.3 sys.modules[__name__] = object() Apart from this limitation, such code is compatible with Python 3.2 - 3.5.1, but breaks under 3.5.2. It's the fact that it breaks in a maintenance release that I find disturbing. In fact, I learnt about the breakage only from an end-user who bought a new laptop with OS X, downloaded the latest Python release and suddenly could not get our package to run that had worked on his previous machine. Turns out, none of our test machines was running 3.5.2 yet, but were running 3.5.0 and 3.5.1. OTOH, I agree with you that the circumstances under which your change causes trouble are pretty exotic. As Nick points out, modules replacing themselves in sys.modules are not that special. What *makes* the situation special is that 1) the package __init__.py has to import the self-replacing module and that 2) the self-replacing module is intended to be run via python3 -m package.module That's why I wrote initially that I don't know if many (or, in fact, any other package would be affected by this). Nick's concern about the double import situation is more general, but since this is something earlier releases have been doing, an improvement here would be relevant only for a major release (3.6 or 3.7). Regarding 3.5.3, I'm not sure what the best solution would be: - the suggestion to copy over the __spec__ attribute to the replacement object is putting the burden on package maintainers. Given that probably only few packages will be affected that may well be acceptable. In fact, for my own case I have now refactored things a bit so I can avoid the import from __init__.py. - from a strict versioning perspective, you may also argue like Nick that if it was working in 3.5.0-1 it should work again in 3.5.3. I'm personally pretty neutral here. I just thought it may be good to report the issue so that it becomes easier for others to understand what is going on if they encounter the same error. Maybe even the fact that this issue exists now is serving this purpose as well as documenting the changed behaviour? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 04:57:34 2016 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 13 Jul 2016 08:57:34 +0000 Subject: [issue27487] -m switch regression in Python 3.5.2 (under rare circumstances) In-Reply-To: <1468268291.19.0.631980361837.issue27487@psf.upfronthosting.co.za> Message-ID: <1468400254.57.0.835179028471.issue27487@psf.upfronthosting.co.za> Nick Coghlan added the comment: Aye, the report is definitely appreciated - the interaction between "__main__" execution and normal module imports has always been tricky, so it's always good to be informed of new problems folks encounter. As an example illustrating the underlying problem here without involving the "-m" switch at all: >>> from importlib.util import find_spec >>> find_spec("dis") ModuleSpec(name='dis', loader=<_frozen_importlib_external.SourceFileLoader object at 0x7fa7ba859fd0>, origin='/usr/lib64/python3.5/dis.py') >>> import sys >>> sys.modules["dis"] = object() >>> find_spec("dis") Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.5/importlib/util.py", line 99, in find_spec raise ValueError('{}.__spec__ is not set'.format(name)) from None ValueError: dis.__spec__ is not set The difference between 3.5.1 and 3.5.2 is that if you do "find_spec('mypkg.mymod')" *before* "mypkg" is imported, then find_spec will use the original module object rather than the replacement inserted into sys.modules when it recurses down to look for "mypkg.mymod". However, if "mypkg" is already in sys.modules before find_spec is called, then find_spec will attempt to use that existing object, rather than the (potentially no longer available) original module object. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 05:05:16 2016 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 13 Jul 2016 09:05:16 +0000 Subject: [issue27487] -m switch regression in Python 3.5.2 (under rare circumstances) In-Reply-To: <1468268291.19.0.631980361837.issue27487@psf.upfronthosting.co.za> Message-ID: <1468400715.99.0.629220616132.issue27487@psf.upfronthosting.co.za> Nick Coghlan added the comment: Sorry, I got the levels slightly confused there - a bit more experimentation shows it isn't the parent package that needs a __spec__ attribute, but only the package being executed. # Parent package needs __path__ rather than __spec__ >>> find_spec("unittest.mock") ModuleSpec(name='unittest.mock', loader=<_frozen_importlib_external.SourceFileLoader object at 0x7fa7b6434b38>, origin='/usr/lib64/python3.5/unittest/mock.py') >>> sys.modules["unittest"] = object() >>> find_spec("unittest.mock") Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.5/importlib/util.py", line 89, in find_spec return _find_spec(fullname, parent.__path__) AttributeError: 'object' object has no attribute '__path__' # Leaf package needs __spec__ >>> del sys.modules["unittest"] >>> find_spec("unittest.mock") ModuleSpec(name='unittest.mock', loader=<_frozen_importlib_external.SourceFileLoader object at 0x7fa7b64344e0>, origin='/usr/lib64/python3.5/unittest/mock.py') >>> import unittest.mock >>> del sys.modules["unittest.mock"].__spec__ >>> find_spec("unittest.mock") Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.5/importlib/util.py", line 99, in find_spec raise ValueError('{}.__spec__ is not set'.format(name)) from None ValueError: unittest.mock.__spec__ is not set ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 05:48:57 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 13 Jul 2016 09:48:57 +0000 Subject: [issue27506] bytes/bytearray delete acts as keyword argument Message-ID: <1468403337.28.0.33019551319.issue27506@psf.upfronthosting.co.za> New submission from Xiang Zhang: Write a patch to make bytes/bytearray.translate's delete argument support acting as keyword arguments. This won't break any backwards compatibility and make the method more flexible to use. Besides, in the C code level, it stops using argument clinic's legacy optional group feature and removes the unnecessary group_right_1 parameter. ---------- components: Interpreter Core files: bytes_translate_delete_as_keyword_arguments.patch keywords: patch messages: 270303 nosy: serhiy.storchaka, xiang.zhang priority: normal severity: normal status: open title: bytes/bytearray delete acts as keyword argument type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43703/bytes_translate_delete_as_keyword_arguments.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 06:04:23 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 13 Jul 2016 10:04:23 +0000 Subject: [issue27506] bytes/bytearray delete acts as keyword argument In-Reply-To: <1468403337.28.0.33019551319.issue27506@psf.upfronthosting.co.za> Message-ID: <1468404263.39.0.0619491765105.issue27506@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 06:25:28 2016 From: report at bugs.python.org (Thomas Perl) Date: Wed, 13 Jul 2016 10:25:28 +0000 Subject: [issue27490] ARM cross-compile: pgen built without $(CFLAGS) as $(LIBRARY) dependency In-Reply-To: <1468276938.3.0.370267656827.issue27490@psf.upfronthosting.co.za> Message-ID: <1468405528.99.0.496885309837.issue27490@psf.upfronthosting.co.za> Thomas Perl added the comment: Yes setting "CC" would fix the problem, but i guess the CFLAGS issue was just the original symptom (and my first reaction to fixing it), whereas the underlying problem is that pgen gets built in cases where it shouldn't be built at all. The solution with "ifeq" does seem to require GNU make, and since these conditionals would still appear in the Makefile even for non-cross-builds, we can't really use this if compatibility with non-GNU make is a requirement. Based on http://gallium.inria.fr/blog/portable-conditionals-in-makefiles/, here is something that seems to work ($(PGEN_DEPS) will be $(PGEN) when cross_compiling=no, and empty when cross_compiling=yes, and configure.ac errors out if cross_compiling is "maybe", so we do not need to handle that case at the moment): ===== diff -ru Python-2.7.12/Makefile.pre.in Python-2.7.12-fix/Makefile.pre.in --- Python-2.7.12/Makefile.pre.in 2016-06-25 23:49:31.000000000 +0200 +++ Python-2.7.12-fix/Makefile.pre.in 2016-07-13 12:21:27.000000000 +0200 @@ -246,6 +246,8 @@ ########################################################################## # Parser PGEN= Parser/pgen$(EXE) +PGEN_DEPS0= ${cross_compiling:yes=} +PGEN_DEPS= ${PGEN_DEPS0:no=$(PGEN)} PSRCS= \ Parser/acceler.c \ @@ -680,7 +682,7 @@ Modules/pwdmodule.o: $(srcdir)/Modules/pwdmodule.c $(srcdir)/Modules/posixmodule.h -$(GRAMMAR_H): $(GRAMMAR_INPUT) $(PGEN) +$(GRAMMAR_H): $(GRAMMAR_INPUT) $(PGEN_DEPS) @$(MKDIR_P) Include # Avoid copying the file onto itself for an in-tree build if test "$(cross_compiling)" != "yes"; then \ ===== ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 08:11:57 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 13 Jul 2016 12:11:57 +0000 Subject: [issue27504] Missing assertion methods in unittest documentation In-Reply-To: <1468370421.07.0.622363937754.issue27504@psf.upfronthosting.co.za> Message-ID: <1468411917.62.0.635090291002.issue27504@psf.upfronthosting.co.za> R. David Murray added the comment: No problem. Personally I'd like to see a table of all of them at the top; however, that wasn't the decision that was made in issue 9796 when the tables were added. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 08:14:58 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 13 Jul 2016 12:14:58 +0000 Subject: [issue14977] mailcap does not respect precedence in the presence of wildcards In-Reply-To: <1338542933.25.0.233529643572.issue14977@psf.upfronthosting.co.za> Message-ID: <1468412098.4.0.573940203778.issue14977@psf.upfronthosting.co.za> R. David Murray added the comment: Looks like you didn't attach the new patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 08:18:41 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 13 Jul 2016 12:18:41 +0000 Subject: [issue27506] make bytes/bytearray deletechars a keyword argument named delete In-Reply-To: <1468403337.28.0.33019551319.issue27506@psf.upfronthosting.co.za> Message-ID: <1468412321.37.0.495681089821.issue27506@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- title: bytes/bytearray delete acts as keyword argument -> make bytes/bytearray deletechars a keyword argument named delete _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 08:18:55 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 13 Jul 2016 12:18:55 +0000 Subject: [issue22125] Cure signedness warnings introduced by #22003 In-Reply-To: <1407017512.42.0.779686467966.issue22125@psf.upfronthosting.co.za> Message-ID: <1468412335.05.0.00424088363569.issue22125@psf.upfronthosting.co.za> Berker Peksag added the comment: Since 2e29d54843a4 this is no longer needed. Thanks for the patches! ---------- nosy: +berker.peksag resolution: -> out of date stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 09:14:44 2016 From: report at bugs.python.org (Demur Rumed) Date: Wed, 13 Jul 2016 13:14:44 +0000 Subject: [issue27078] Make f'' strings faster than .format: BUILD_STRING opcode? In-Reply-To: <1463858316.54.0.292581402272.issue27078@psf.upfronthosting.co.za> Message-ID: <1468415684.65.0.295142600652.issue27078@psf.upfronthosting.co.za> Demur Rumed added the comment: fstrtup2.patch is a bit more of an involved optimization for when we are joining 2 strings. Instead it emits BINARY_ADD. This may be considered too 'niche' since it only triggers when the substitution occurs at the start or end of a string & there is only one substitution However, it reduces the "X is {x}" testcase on my machine to 4.9 usec Interesting thing, to consider ceiling of what we can do, Prefixing ./python -m timeit -s "x=1" '%s'%x 1.08 usec '%s'%(x,) 2.04 usec str(x) 2.9 usec f'{x}' 3.65 usec So we should not be aiming to compete with %. It may be worthy to convert the code to generate "x is {}".format calls tho ---------- Added file: http://bugs.python.org/file43704/fstrtup2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 09:47:04 2016 From: report at bugs.python.org (Emanuel Barry) Date: Wed, 13 Jul 2016 13:47:04 +0000 Subject: [issue27498] Regression in repr() of class object In-Reply-To: <1468338842.06.0.843714859349.issue27498@psf.upfronthosting.co.za> Message-ID: <1468417624.03.0.500782537577.issue27498@psf.upfronthosting.co.za> Changes by Emanuel Barry : ---------- nosy: +ebarry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 10:12:07 2016 From: report at bugs.python.org (Martin Teichmann) Date: Wed, 13 Jul 2016 14:12:07 +0000 Subject: [issue27366] PEP487: Simpler customization of class creation In-Reply-To: <1466579967.76.0.483118833643.issue27366@psf.upfronthosting.co.za> Message-ID: <1468419127.09.0.670621028166.issue27366@psf.upfronthosting.co.za> Changes by Martin Teichmann : Removed file: http://bugs.python.org/file43506/pep487.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 10:19:50 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 13 Jul 2016 14:19:50 +0000 Subject: [issue27490] ARM cross-compile: pgen built without $(CFLAGS) as $(LIBRARY) dependency In-Reply-To: <1468276938.3.0.370267656827.issue27490@psf.upfronthosting.co.za> Message-ID: <1468419590.23.0.475797266671.issue27490@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > the underlying problem is that pgen gets built in cases where it shouldn't This statement does not take into account the following note of your initial post: "note that the same $(CFLAGS) needs to be added to the rule for $(BUILDPYTHON) if one wants to build that as well". I agree with Martin that you should either use CC or set LDFLAGS to fix the problems that occur at the link stages of your cross-build. ---------- nosy: +xdegaye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 10:25:56 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 13 Jul 2016 14:25:56 +0000 Subject: [issue27506] make bytes/bytearray deletechars a keyword argument named delete In-Reply-To: <1468403337.28.0.33019551319.issue27506@psf.upfronthosting.co.za> Message-ID: <1468419956.94.0.318692917965.issue27506@psf.upfronthosting.co.za> Xiang Zhang added the comment: Hmm, David, that may be not quite right. Users only reading the doc never know it's deletechars not delete. The doc is always delete, though conflicting with __doc__. >>> print(bytes.translate.__doc__) B.translate(table[, deletechars]) -> bytes ... I deliberately change deletechars to delete to keep consistent with doc. But actually I think using deletechars won't break backwards compatibility too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 10:40:47 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 13 Jul 2016 14:40:47 +0000 Subject: [issue19142] Cross-compile fails trying to execute foreign pgen on build host In-Reply-To: <1380670898.69.0.308819053325.issue19142@psf.upfronthosting.co.za> Message-ID: <1468420847.82.0.765113153859.issue19142@psf.upfronthosting.co.za> Xavier de Gaye added the comment: I confirm that, on 3.6 and after the changesets that fixed issue 22359, pgen is always cross-compiled whatever the timestamps and that pgen is not run on a cross-build for Android. So I think it should work as well now for Trevor with v2.7.12. ---------- nosy: +xdegaye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 10:44:09 2016 From: report at bugs.python.org (Antti Haapala) Date: Wed, 13 Jul 2016 14:44:09 +0000 Subject: [issue27078] Make f'' strings faster than .format: BUILD_STRING opcode? In-Reply-To: <1463858316.54.0.292581402272.issue27078@psf.upfronthosting.co.za> Message-ID: <1468421049.74.0.421102567667.issue27078@psf.upfronthosting.co.za> Antti Haapala added the comment: Yet the test cases just prove what is so expensive there: name lookups (global name `str`; looking up `join` on a string instance); building a tuple (for function arguments) is expensive as well. Of course `__format__` will be costly as well as it is not a slot-method, needs to build a new string etc. However for strings, 'foo'.format() already returns the instance itself, so if you were formatting other strings into strings there are cheap shortcuts available to even overtake a = 'Hello' b = 'World' '%s %s' % (a, b) for fast string templates, namely, make FORMAT_VALUE without args return the original if `PyUnicode_CheckExact` and no arguments, don't need to build a tuple to join it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 10:59:40 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 13 Jul 2016 14:59:40 +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: <1468421980.1.0.520033124542.issue25548@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Would there be a way to confine this to just heap types? The user defined classes are where there is the most benefit. For the built-in types, it just seems to add noise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 11:07:52 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 13 Jul 2016 15:07:52 +0000 Subject: [issue25548] Show the address in the repr for class objects In-Reply-To: <1468421980.1.0.520033124542.issue25548@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Doing it only for user-defined types would still break my tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 11:22:44 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 13 Jul 2016 15:22:44 +0000 Subject: [issue27501] Create a collections.abc class that describes PEP 3118 buffer In-Reply-To: <1468346843.82.0.455431578723.issue27501@psf.upfronthosting.co.za> Message-ID: <1468423364.32.0.677324345655.issue27501@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I'll defer to typing gurus as to whether something like this might make sense in typing.py, but it doesn't make much sense as a collections.abc without an API exposed in pure python and without useful mixin methods. By way of comparison, consider that the named tuple protocol is in typing.NamedTuple but not in collections.abc; instead, we just use _fields to recognize it when the need arises (which is almost never). I would like collections.abc to remain a place for ABCs that can be usefully subclassed, that provide guaranteed behaviors, and that are in fact related to collections. The module's utility will be impaired if it becomes a dumping ground for miscellaneous type hinting concepts and registrations. Early on there was some experimentation with the "one-trick ponies" in collections.abc such as Callable and Hashable that turned-out to almost never be used in practice, so we don't want to continue to that line of development when there are more promising avenues such as typing.py. ---------- nosy: +rhettinger versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 11:30:32 2016 From: report at bugs.python.org (Thomas Perl) Date: Wed, 13 Jul 2016 15:30:32 +0000 Subject: [issue27490] ARM cross-compile: pgen built without $(CFLAGS) as $(LIBRARY) dependency In-Reply-To: <1468276938.3.0.370267656827.issue27490@psf.upfronthosting.co.za> Message-ID: <1468423831.99.0.524185428224.issue27490@psf.upfronthosting.co.za> Thomas Perl added the comment: Adding "-mfloat-abi=hard" to LDFLAGS fixes the issue for me, and also allows $(BUILDPYTHON) to be built correctly in addition to $(PGEN). So I guess the resolution to this issue is "works for me" (with setting CC or LDFLAGS properly for cross-compilation being the resolution/workaround). Does it make sense to create a new bug "Do not build pgen when it's not going to be used" as follow-up to this discussion (with a patch similar to the one in http://bugs.python.org/msg270304)? If so, I'll create one. Or maybe there should be a generic configure flag "do not run any generators" (like https://bugs.python.org/issue26662#msg270162, but including not running pgen), with the flag only issuing warnings instead of failing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 11:31:24 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 13 Jul 2016 15:31:24 +0000 Subject: [issue27506] make bytes/bytearray delete a keyword argument In-Reply-To: <1468403337.28.0.33019551319.issue27506@psf.upfronthosting.co.za> Message-ID: <1468423884.68.0.0104228421277.issue27506@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, I was looking at the 2.7 docs. ---------- nosy: +r.david.murray title: make bytes/bytearray deletechars a keyword argument named delete -> make bytes/bytearray delete a keyword argument _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 11:38:38 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 13 Jul 2016 15:38:38 +0000 Subject: [issue27506] make bytes/bytearray delete a keyword argument In-Reply-To: <1468403337.28.0.33019551319.issue27506@psf.upfronthosting.co.za> Message-ID: <1468424318.33.0.59028711733.issue27506@psf.upfronthosting.co.za> Xiang Zhang added the comment: Please review the new version. It makes two changes comparing with the last one. 1. It exposes Python parameter as "delete" (which the document always uses so I think it's the API) while still use "deletechars" (which I prefer as a C variable name) in C code. 2. It allows *delete* to be None. Before this is not allowed but I don't think this change breaks backwards compatibility. The reason for this change is that I don't want users to get surprised when they pass the default value to translate but then get an exception. ---------- Added file: http://bugs.python.org/file43705/bytes_translate_delete_as_keyword_arguments_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 11:47:56 2016 From: report at bugs.python.org (Demur Rumed) Date: Wed, 13 Jul 2016 15:47:56 +0000 Subject: [issue27078] Make f'' strings faster than .format: BUILD_STRING opcode? In-Reply-To: <1463858316.54.0.292581402272.issue27078@psf.upfronthosting.co.za> Message-ID: <1468424876.09.0.279179862176.issue27078@psf.upfronthosting.co.za> Demur Rumed added the comment: I'm not understanding your message. We don't call FORMAT_VALUE on constant strings in f"x is {x}" & FORMAT_VALUE doesn't take an argument. Are you saying in a hypothetical FORMAT_VALUE where BUILD_STRING takes a set of objects & applies formatting to them, thus allowing us to remove FORMAT_VALUE as an opcode? That seems like I'm imposing my own internal thoughts on what you're saying, but when I don't understand what someone's saying I'm prone to raise my own imaginations. Also note that f'{x}' compiles to 'LOAD X, FORMAT_VALUE' so there is no join lookup in the last benchmarks I posted Nitpick about fstrtup2: it assumes compiler_joined_str's len is at least 2. Either an assert should be added or the last if-else should be `else if (len == 1)` instead of a plain `else` ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 11:55:29 2016 From: report at bugs.python.org (Michael Lazar) Date: Wed, 13 Jul 2016 15:55:29 +0000 Subject: [issue14977] mailcap does not respect precedence in the presence of wildcards In-Reply-To: <1338542933.25.0.233529643572.issue14977@psf.upfronthosting.co.za> Message-ID: <1468425329.7.0.892623697872.issue14977@psf.upfronthosting.co.za> Michael Lazar added the comment: Whoops ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 11:57:16 2016 From: report at bugs.python.org (Michael Lazar) Date: Wed, 13 Jul 2016 15:57:16 +0000 Subject: [issue14977] mailcap does not respect precedence in the presence of wildcards In-Reply-To: <1338542933.25.0.233529643572.issue14977@psf.upfronthosting.co.za> Message-ID: <1468425436.37.0.893771200381.issue14977@psf.upfronthosting.co.za> Changes by Michael Lazar : Added file: http://bugs.python.org/file43706/mailcap_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 12:13:13 2016 From: report at bugs.python.org (Daniel Moisset) Date: Wed, 13 Jul 2016 16:13:13 +0000 Subject: [issue27501] Create a collections.abc class that describes PEP 3118 buffer In-Reply-To: <1468346843.82.0.455431578723.issue27501@psf.upfronthosting.co.za> Message-ID: <1468426393.72.0.329175842692.issue27501@psf.upfronthosting.co.za> Daniel Moisset added the comment: Thanks for the feedback. Just for the context, I opened this issue also based on this email: http://permalink.gmane.org/gmane.comp.python.devel/156411 Probably there are two different discussions to have here: 1) Is the "Buffer" a useful ABC to have even if there's no python API involved? My thoughts (that come from working with typing and PEP 484 and numpy) are "yes" 2) Where is the right place to put it? I suggested collections.abc after seeing the thread I linked, although I wouldn't mind if this was in typing.py or somewhere else. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 12:15:29 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 13 Jul 2016 16:15:29 +0000 Subject: [issue14977] mailcap does not respect precedence in the presence of wildcards In-Reply-To: <1338542933.25.0.233529643572.issue14977@psf.upfronthosting.co.za> Message-ID: <1468426529.64.0.746305653701.issue14977@psf.upfronthosting.co.za> R. David Murray added the comment: There's actually programmatic way to generate a deprecation warning when the function is called (and then we'd want a test to make sure it gets generated). if you don't feel like working through that hopefully someone else will pick it up. If you want to work on it, you can find examples by grepping for DeprecationWarning. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 12:38:58 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 13 Jul 2016 16:38:58 +0000 Subject: [issue27501] Add typing.py class describing a PEP 3118 buffer object In-Reply-To: <1468346843.82.0.455431578723.issue27501@psf.upfronthosting.co.za> Message-ID: <1468427938.82.0.970539335316.issue27501@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Since collections.abc is the wrong place, I'll change the title of this to typing and see if any of the typing aficionados think it is sufficiently useful (they are deliberately focusing on common use cases first since the whole static typing endeavor is exploratory and this limits of what should be done and what isn't really needed or useful isn't yet well understood). ---------- title: Create a collections.abc class that describes PEP 3118 buffer -> Add typing.py class describing a PEP 3118 buffer object _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 12:42:00 2016 From: report at bugs.python.org (Brett Cannon) Date: Wed, 13 Jul 2016 16:42:00 +0000 Subject: [issue27487] -m switch regression in Python 3.5.2 (under rare circumstances) In-Reply-To: <1468268291.19.0.631980361837.issue27487@psf.upfronthosting.co.za> Message-ID: <1468428120.79.0.942548839042.issue27487@psf.upfronthosting.co.za> Brett Cannon added the comment: So what I'm gathering is that Martin fixed a bug that accidentally introduced a new one in 3.5.2 (which Martin should not feel responsible for; this import stuff is all very subtle and people use every nuance of it). To me, the question is whether there is a way to not revert Martin's fix -- or any other fixes -- while fixing Wolfgang's problem. If the answer is yes, then great and we just need to know what the answer is in the form of a patch. :) My hope is someone will be inspired enough to figure out a solution and we can fix this for Wolfgang. But if the answer is no, then we need to decide what the lesser of two bugs are. For me, I see Wolfgang's issue is the lesser of two bugs and thus the one that stays broken if we can't fix it reasonably (sorry, Wolfgang). Because we are trying to eliminate the double-import as that causes serious problems for anyone using import side-effects, I don't want to suddenly slide backwards in 3.5.3 by letting that happen again (and I think Nick agrees w/ me on that point). I also don't want people continuing down a path where they think that they can blank out critical import metadata and have import continue to work (not that I'm blaming Wolfgang for relying on it, just that it won't hold in the future). And since the reliance on __spec__ is just going to grow thanks to the elimination of double imports and slowly making that attribute the ground truth for import metadata, Wolfgang's code would need to be updated for Python 3.6 or later anyway. But as I said, I'm sure everyone's utmost preference is if someone can figure out how to fix this in 3.5.3 without undoing another fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 12:43:00 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 13 Jul 2016 16:43:00 +0000 Subject: [issue27495] Pretty printing sorting for set and frozenset instances In-Reply-To: <1468323029.69.0.352634397545.issue27495@psf.upfronthosting.co.za> Message-ID: <1468428180.2.0.528452894251.issue27495@psf.upfronthosting.co.za> Raymond Hettinger added the comment: +1 for treating this as a bug fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 12:51:43 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 13 Jul 2016 16:51:43 +0000 Subject: [issue27495] Pretty printing sorting for set and frozenset instances In-Reply-To: <1468323029.69.0.352634397545.issue27495@psf.upfronthosting.co.za> Message-ID: <1468428703.14.0.237011988618.issue27495@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Since pprint() now supports all standard collections, I think it is worth to support them in saferepr() too. I have written an implementation and am finishing writing tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 13:02:38 2016 From: report at bugs.python.org (Demur Rumed) Date: Wed, 13 Jul 2016 17:02:38 +0000 Subject: [issue27078] Make f'' strings faster than .format: BUILD_STRING opcode? In-Reply-To: <1463858316.54.0.292581402272.issue27078@psf.upfronthosting.co.za> Message-ID: <1468429358.62.0.0734571252588.issue27078@psf.upfronthosting.co.za> Changes by Demur Rumed : ---------- type: enhancement -> performance _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 13:12:28 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 13 Jul 2016 17:12:28 +0000 Subject: [issue27507] bytearray.extend lacks overflow check when increasing buffer Message-ID: <1468429948.12.0.767304648411.issue27507@psf.upfronthosting.co.za> New submission from Xiang Zhang: As the title, bytearray.extend simply use `buf_size = len + (len >> 1) + 1;` to determine next *buf_size* when increasing buffer. But this can overflow in theory. So I suggest adding overflow check. ---------- components: Interpreter Core files: add_bytearray_extend_overflow_check.patch keywords: patch messages: 270327 nosy: serhiy.storchaka, xiang.zhang priority: normal severity: normal status: open title: bytearray.extend lacks overflow check when increasing buffer type: enhancement versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43707/add_bytearray_extend_overflow_check.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 13:15:21 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 13 Jul 2016 17:15:21 +0000 Subject: [issue27507] bytearray.extend lacks overflow check when increasing buffer In-Reply-To: <1468429948.12.0.767304648411.issue27507@psf.upfronthosting.co.za> Message-ID: <1468430121.58.0.697595434069.issue27507@psf.upfronthosting.co.za> Xiang Zhang added the comment: Ohh, sorry for the disturb. I made a mistake. This is not needed and now close it. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 13:20:48 2016 From: report at bugs.python.org (JA) Date: Wed, 13 Jul 2016 17:20:48 +0000 Subject: [issue27508] process thread with implicit join is killed unexpectedly Message-ID: <1468430448.11.0.0781111425971.issue27508@psf.upfronthosting.co.za> New submission from JA: On Ubuntu 16.04 python '3.5.1+ (default, Mar 30 2016, 22:46:26) \n[GCC 5.3.1 20160330]' The following code prints "hi" 4 times: import multiprocessing import time import threading class dumb(threading.Thread): def __init__(self): super(dumb, self).__init__() def run(self): while True: print("hi") time.sleep(1) def test(): for i in range(2): bar = dumb() bar.start() def main(): p = [] for i in range(2): p.append(multiprocessing.Process(target=test)) for i in p: i.start() for i in p: i.join() if __name__ == '__main__': main() Note: The above code runs fine on Python 3.5.2 (64-bit) on Windows 10 Joining the threads in test fixes the problem: def test(): p = [] for i in range(2): bar = dumb() bar.start() p.append(bar) for i in p: i.join() ---------- messages: 270329 nosy: JA priority: normal severity: normal status: open title: process thread with implicit join is killed unexpectedly versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 13:24:23 2016 From: report at bugs.python.org (Tim Peters) Date: Wed, 13 Jul 2016 17:24:23 +0000 Subject: [issue27508] process thread with implicit join is killed unexpectedly In-Reply-To: <1468430448.11.0.0781111425971.issue27508@psf.upfronthosting.co.za> Message-ID: <1468430663.37.0.52218041358.issue27508@psf.upfronthosting.co.za> Tim Peters added the comment: Note: this started on stackoverflow: https://stackoverflow.com/questions/38356584/python-multiprocessing-threading-code-exits-early I may be missing something obvious, but the only explanation I could think of for the behavior seen on Ubuntu is that the threads in the worker processes are being treated as daemon threads. The program works as intended for me on Windows - but, of course, there's a universe of differences between spawning (Windows) and forking (Ubuntu) processes too. ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 13:26:23 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 13 Jul 2016 17:26:23 +0000 Subject: [issue27507] bytearray.extend lacks overflow check when increasing buffer In-Reply-To: <1468429948.12.0.767304648411.issue27507@psf.upfronthosting.co.za> Message-ID: <1468430783.36.0.883961357456.issue27507@psf.upfronthosting.co.za> Xiang Zhang added the comment: Sorry, after checking again, this is still needed but maybe `if (len == PY_SSIZE_T_MAX)` part is not necessary since the iterable's length should not be larger than PY_SSIZE_T_MAX. But keep it to avoid theoretically bug is not a bad idea. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 13:27:53 2016 From: report at bugs.python.org (Tim Peters) Date: Wed, 13 Jul 2016 17:27:53 +0000 Subject: [issue27508] process thread with implicit join is killed unexpectedly In-Reply-To: <1468430448.11.0.0781111425971.issue27508@psf.upfronthosting.co.za> Message-ID: <1468430873.11.0.0765739838508.issue27508@psf.upfronthosting.co.za> Changes by Tim Peters : ---------- components: +Library (Lib) type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 13:34:36 2016 From: report at bugs.python.org (Danilo J. S. Bellini) Date: Wed, 13 Jul 2016 17:34:36 +0000 Subject: [issue27495] Pretty printing sorting for set and frozenset instances In-Reply-To: <1468323029.69.0.352634397545.issue27495@psf.upfronthosting.co.za> Message-ID: <1468431276.27.0.981383514537.issue27495@psf.upfronthosting.co.za> Danilo J. S. Bellini added the comment: Wouldn't a fix for all standard collections be a fix for Python 3.5+, therefore another issue? http://bugs.python.org/issue23870 This issue is about sets/frozensets Python 3.2+, and I'm pretty sure it's backwards compatible, as I don't think any code running on Python 3.2.6 would depend on pprint randomness (how could?). Also, a multiline pprint would sort (tested with Python 3.2.6): >>> pprint.pprint(set(string.digits), width=7) {'0', '1', '2', '3', '4', '5', '6', '7', '8', '9'} I see no reason to see a fix to this inconsistent behavior (sorting on multiline, not sorting on single line) as an enhancement just for a new Python 3.6 version. Besides being backwards compatible, the test_pprint was really verifying the order on set(range(n)) for small n, something that is already sorted by set.__repr__ but appears in test_pprint, which make me think it was intended as a pretty printer test, not as a set.__repr__ test. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 14:09:17 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 13 Jul 2016 18:09:17 +0000 Subject: [issue27078] Make f'' strings faster than .format: BUILD_STRING opcode? In-Reply-To: <1463858316.54.0.292581402272.issue27078@psf.upfronthosting.co.za> Message-ID: <1468433357.54.0.69984287225.issue27078@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yet one case for comparison (with msg270095): $ ./python -m timeit -s "x = 2" -- 'f"X is {x!s}"' 1000000 loops, best of 3: 0.625 usec per loop Seems f'{x!s}' is the fastest way to stringify a value. Thus there is an opportunity to speed up default formatting by special casing PyObject_Format() for most popular types (str and int). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 14:22:50 2016 From: report at bugs.python.org (Daniel Moisset) Date: Wed, 13 Jul 2016 18:22:50 +0000 Subject: [issue27501] Add typing.py class describing a PEP 3118 buffer object In-Reply-To: <1468346843.82.0.455431578723.issue27501@psf.upfronthosting.co.za> Message-ID: <1468434170.38.0.48066038803.issue27501@psf.upfronthosting.co.za> Daniel Moisset added the comment: OK. Just to give an obvious example of a place where this would be useful for annotations is in the argument for the memoryview() builtin (currently declared with "# TODO arg can be any obj supporting the buffer protocol" in the standard library typesheds) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 14:46:09 2016 From: report at bugs.python.org (Tim Peters) Date: Wed, 13 Jul 2016 18:46:09 +0000 Subject: [issue27508] process thread with implicit join is killed unexpectedly In-Reply-To: <1468430448.11.0.0781111425971.issue27508@psf.upfronthosting.co.za> Message-ID: <1468435569.62.0.121049426242.issue27508@psf.upfronthosting.co.za> Tim Peters added the comment: Curious: under Python 2.7.11 on Windows, the threads also terminate early (they run "forever" - as intended - under 3.5.2). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 15:32:53 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 13 Jul 2016 19:32:53 +0000 Subject: [issue27508] process thread with implicit join is killed unexpectedly In-Reply-To: <1468430448.11.0.0781111425971.issue27508@psf.upfronthosting.co.za> Message-ID: <1468438373.57.0.699070207808.issue27508@psf.upfronthosting.co.za> R. David Murray added the comment: On my gentoo system it prints hi four times in 2.7, and 3.2 through 3.6. I suspect multiprocessing is killing threads, daemon or not, when the main process thread ends. I expect that's a feature, although I didn't find it documented. Ah, found the explanation: issue 18966. Antoine indicates this could indeed be considered a bug but is part of a larger issue. If we aren't going to fix it, we should probably document it. ---------- assignee: -> docs at python components: +Documentation -Library (Lib) nosy: +docs at python, r.david.murray versions: +Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 15:58:10 2016 From: report at bugs.python.org (Tim Peters) Date: Wed, 13 Jul 2016 19:58:10 +0000 Subject: [issue27508] process thread with implicit join is killed unexpectedly In-Reply-To: <1468430448.11.0.0781111425971.issue27508@psf.upfronthosting.co.za> Message-ID: <1468439890.08.0.716156565291.issue27508@psf.upfronthosting.co.za> Tim Peters added the comment: Ah - good catch! I'm closing this as a duplicate of bug18966. The real mystery now is why the threads _don't_ terminate early under Windows 3.5.2 - heh. ---------- resolution: -> duplicate status: open -> closed superseder: -> Threads within multiprocessing Process terminate early _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 16:05:05 2016 From: report at bugs.python.org (Tim Peters) Date: Wed, 13 Jul 2016 20:05:05 +0000 Subject: [issue18966] Threads within multiprocessing Process terminate early In-Reply-To: <1378603227.91.0.146993702012.issue18966@psf.upfronthosting.co.za> Message-ID: <1468440305.92.0.540321578849.issue18966@psf.upfronthosting.co.za> Tim Peters added the comment: This came up again today as bug 27508. In the absence of "fixing it", we should add docs to multiprocessing explaining the high-level consequences of skipping "normal" exit processing (BTW, I'm unclear on why it's skipped). I've certainly mixed threads with multiprocessing too, but I always explicitly .join() my threads so never noticed this. It's sure a puzzle when it happens ;-) ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 16:11:37 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 13 Jul 2016 20:11:37 +0000 Subject: [issue27078] Make f'' strings faster than .format: BUILD_STRING opcode? In-Reply-To: <1463858316.54.0.292581402272.issue27078@psf.upfronthosting.co.za> Message-ID: <1468440697.46.0.259874161174.issue27078@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Proposed patch adds the BUILD_STRING opcode and speeds up PyObject_Format() in common cases. It makes f-strings the fastest method for simple formatting. $ ./python -m timeit -s "x = 2" -- 'f"X is {x}"' 1000000 loops, best of 3: 0.347 usec per loop ---------- Added file: http://bugs.python.org/file43708/fstring_build_string.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 16:15:06 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 13 Jul 2016 20:15:06 +0000 Subject: [issue27497] csv module: Add return value to DictWriter.writeheader In-Reply-To: <1468336448.04.0.83850338242.issue27497@psf.upfronthosting.co.za> Message-ID: <1468440906.09.0.94509255243.issue27497@psf.upfronthosting.co.za> Raymond Hettinger added the comment: It is a bit irritating to have this small API inconsistency, but I'm a little wary of propagating this undocumented and untested behavior especially given Victor's concern about whether it makes any sense in this context. Skip, what do you think? ---------- assignee: -> skip.montanaro nosy: +rhettinger, skip.montanaro _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 16:19:34 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 13 Jul 2016 20:19:34 +0000 Subject: [issue27497] csv module: Add return value to DictWriter.writeheader In-Reply-To: <1468336448.04.0.83850338242.issue27497@psf.upfronthosting.co.za> Message-ID: <1468441174.57.0.561850493389.issue27497@psf.upfronthosting.co.za> R. David Murray added the comment: It doesn't make sense when the return value is that provided by io.write. It does make sense in the context of the linked example (a psuedo-file object). However, it *is* an undocumented API, even if people are using it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 16:24:10 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 13 Jul 2016 20:24:10 +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: <1468441450.07.0.119515949876.issue25548@psf.upfronthosting.co.za> Raymond Hettinger added the comment: +1 on rolling this back. It sounds like it hurt more than it would have helped. To satisfy my curiosity, can you post one of the tests that broke. It would be nice to see what kind of tests are depend the repr of the class. AFAICT, there was never an issue with this for old-style classes in Python2.7, so something new must be occurring in the wild. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 16:30:59 2016 From: report at bugs.python.org (Eryk Sun) Date: Wed, 13 Jul 2016 20:30:59 +0000 Subject: [issue18966] Threads within multiprocessing Process terminate early In-Reply-To: <1378603227.91.0.146993702012.issue18966@psf.upfronthosting.co.za> Message-ID: <1468441859.91.0.831909829423.issue18966@psf.upfronthosting.co.za> Eryk Sun added the comment: In 3.4+ it works correctly with the "spawn" start method. This uses multiprocessing.spawn.spawn_main, which exits the child via sys.exit(exitcode). "fork" and "forkserver" exit the child via os._exit(code), respectively in multiprocessing.popen_fork.Popen._launch and multiprocessing.forkserver.main. ---------- nosy: +eryksun versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 16:40:31 2016 From: report at bugs.python.org (Antti Haapala) Date: Wed, 13 Jul 2016 20:40:31 +0000 Subject: [issue27078] Make f'' strings faster than .format: BUILD_STRING opcode? In-Reply-To: <1463858316.54.0.292581402272.issue27078@psf.upfronthosting.co.za> Message-ID: <1468442431.61.0.887889236908.issue27078@psf.upfronthosting.co.za> Antti Haapala added the comment: It seems Eric has done some special casing for strings already in FORMAT_VALUE. Here are the results from my computer after applying Demur's patch for concatenating *strings*. python3.6 -m timeit -s "x = 'a'" -- '"X is %s" % x' 1000000 loops, best of 3: 0.187 usec per loop python3.6 -m timeit -s "x = 'a'" -- 'f"X is {x}"' 10000000 loops, best of 3: 0.0972 usec per loop But then as more components are added, it starts to slow down rapidly: python3.6 -m timeit -s "x = 'a'" -- 'f"X is {x}a"' 1000000 loops, best of 3: 0.191 usec per loop python3.6 -m timeit -s "x = 'a'" -- '"X is %sa" % x' 1000000 loops, best of 3: 0.216 usec per loop Of course there is also the matter of string conversion vs "look up __format__": python3.6 -m timeit -s "x = 1" -- 'f"X is {x}"' 1000000 loops, best of 3: 0.349 usec per loop python3.6 -m timeit -s "x = 1" -- 'f"X is {x!s}"' 10000000 loops, best of 3: 0.168 usec per loop For FORMAT_VALUE opcode already has a special case for the latter. However I'd too say that switch/case for the some fastest builtin types in `PyObject_Format` as Eric has intended to do with Unicode in PyObject_Format (str, int, float), as those are commonly used to build strings such as text templates, text-like protocols like emails, HTTP protocol headers and such. For others the speed-up wouldn't really matter either way: either PyObject_Format would fall back to object.__format__ (for example functions) - no one really cares about efficiency when doing such debug dumps - if you cared, you'd not do them at all; or they'd have complex representations (say, lists, dictionaries) - and their use again would mostly be that of debug dumps; or they'd have `__format__` written in Python and that'd be dwarfed by anything so far. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 16:47:37 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 13 Jul 2016 20:47:37 +0000 Subject: [issue25548] Show the address in the repr for class objects In-Reply-To: <1468441450.07.0.119515949876.issue25548@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Thanks, let's roll it back. The reason it never was an issue for old-style classes is that they behaved like this from the start, so nobody wrote tests that depended on the predictability of repr(). But new-style classes have had this nice clean repr() since they were introduced (in 2.3?) so it's unsurprising that this is now depended upon. Here's a link to some test code for mypy that broke: https://github.com/python/mypy/blob/master/mypy/util.py#L22-L23 It may be irreprehensible code but it works for Python 3.2-3.5 (and for new-style classes in Python 2, except mypy requires Python 3), and broke in 3.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 17:32:21 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Jul 2016 21:32:21 +0000 Subject: [issue27497] csv module: Add return value to DictWriter.writeheader In-Reply-To: <1468441174.57.0.561850493389.issue27497@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Oh. I missed the django recipe to implement "streaming csv". It uses an Echo object, its write() method returns its parameter. This recipe looks like an abuse of the API, but I understand that there is a need for a kind of "partial write": give control to I/O to the caller. Maybe we should extend the API? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 17:56:47 2016 From: report at bugs.python.org (Demur Rumed) Date: Wed, 13 Jul 2016 21:56:47 +0000 Subject: [issue27078] Make f'' strings faster than .format: BUILD_STRING opcode? In-Reply-To: <1463858316.54.0.292581402272.issue27078@psf.upfronthosting.co.za> Message-ID: <1468447007.96.0.496391692732.issue27078@psf.upfronthosting.co.za> Changes by Demur Rumed : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 18:04:03 2016 From: report at bugs.python.org (Antti Haapala) Date: Wed, 13 Jul 2016 22:04:03 +0000 Subject: [issue27078] Make f'' strings faster than .format: BUILD_STRING opcode? In-Reply-To: <1463858316.54.0.292581402272.issue27078@psf.upfronthosting.co.za> Message-ID: <1468447443.67.0.472899199293.issue27078@psf.upfronthosting.co.za> Antti Haapala added the comment: Thanks Serhiy, I was writing my comment for a long time, and only now noticed that you'd already posted the patch. Indeed, it seems that not only is this the fastest method, it might also be the fastest string concatenation method in the history of Python. I did some comparison with 8-bit strings in Python 2, doing the equivalent of f'http://{domain}/{lang}/{path}' with domain = 'some_really_long_example.com' lang = 'en' path = 'some/really/long/path/' and the results look quite favourable: 0.151 ?s with your patch; 0.250ish for the second fastest method in Python 3.6 (''.join(tuple)) And the fastest method in Python 2 is a tie between concatenating with + or ''.join with bound method reference; both of them take 0.203 ?s on Python 2.7 with 8-bit strings and about 0.245 - 0.255 ?s if everything is Unicode. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 18:06:28 2016 From: report at bugs.python.org (ppperry) Date: Wed, 13 Jul 2016 22:06:28 +0000 Subject: [issue27157] Unhelpful error message when one calls a subclass of type with a custom metaclass In-Reply-To: <1464561968.54.0.551105312321.issue27157@psf.upfronthosting.co.za> Message-ID: <1468447588.61.0.196238771943.issue27157@psf.upfronthosting.co.za> ppperry added the comment: Ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 18:23:07 2016 From: report at bugs.python.org (Ned Deily) Date: Wed, 13 Jul 2016 22:23:07 +0000 Subject: [issue27487] -m switch regression in Python 3.5.2 (under rare circumstances) In-Reply-To: <1468268291.19.0.631980361837.issue27487@psf.upfronthosting.co.za> Message-ID: <1468448587.18.0.478781342629.issue27487@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 18:28:09 2016 From: report at bugs.python.org (Ned Deily) Date: Wed, 13 Jul 2016 22:28:09 +0000 Subject: [issue18966] Threads within multiprocessing Process terminate early In-Reply-To: <1378603227.91.0.146993702012.issue18966@psf.upfronthosting.co.za> Message-ID: <1468448889.24.0.777466983986.issue18966@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 18:30:47 2016 From: report at bugs.python.org (Ned Deily) Date: Wed, 13 Jul 2016 22:30:47 +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: <1468449047.09.0.565143891423.issue25548@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 18:49:42 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 13 Jul 2016 22:49:42 +0000 Subject: [issue27506] make bytes/bytearray delete a keyword argument In-Reply-To: <1468403337.28.0.33019551319.issue27506@psf.upfronthosting.co.za> Message-ID: <1468450182.8.0.0464778050035.issue27506@psf.upfronthosting.co.za> Martin Panter added the comment: Instead of allowing delete=None (which is not in the RST documentation), perhaps it is possible to change the doc string. I can?t remember the details, but I think Argument Clinic allows a virtual Python-level default, something like ?object(py_default=b"") = NULL?. Also, I think I like the change. What do you think about making the first argument optional (default to None), allowing calls like x.translate(delete=b'aeiou')? ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 19:11:58 2016 From: report at bugs.python.org (John Hagen) Date: Wed, 13 Jul 2016 23:11:58 +0000 Subject: [issue27455] Fix tkinter examples to be PEP8 compliant In-Reply-To: <1467724852.16.0.852334218439.issue27455@psf.upfronthosting.co.za> Message-ID: <1468451518.23.0.477439867274.issue27455@psf.upfronthosting.co.za> John Hagen added the comment: The patch was reviewed and marked ready to commit. Could someone with commit privileges perform the final commit? Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 21:54:46 2016 From: report at bugs.python.org (Davin Potts) Date: Thu, 14 Jul 2016 01:54:46 +0000 Subject: [issue18966] Threads within multiprocessing Process terminate early In-Reply-To: <1378603227.91.0.146993702012.issue18966@psf.upfronthosting.co.za> Message-ID: <1468461286.48.0.680272415854.issue18966@psf.upfronthosting.co.za> Davin Potts added the comment: It is a general rule that when a process terminates, it likewise terminates all its threads (unless a thread has been explicitly detached). How it goes about doing so is complicated. Remember that POSIX threads have no concept of parent/child among themselves and all threads are viewed as a single pool. The section "No parents, no children" at http://www.ibm.com/developerworks/library/l-posix1/ offers us motivation for why waiting on a pthread should be explicitly requested and not assumed as a default behavior. There are numerous differences between what a UNIX-style process and a win32 process does at termination. Though an older post from Microsoft, a strong sense of how complicated the process-termination-begets-thread-termination truly is can be had from reading https://blogs.msdn.microsoft.com/oldnewthing/20070503-00/?p=27003 which also helps reinforce the sentiment above (needs explicit instructions on what to do, no general solution can exist). Whereas the prior provided some sense of motivation, this link walks us through ugly complications and consequences that arise. The short of it is that the current use of os._exit() is most appropriate in multiprocessing. Threads should be signaled that the process is terminating but we are not generally expected to wait on those threads. These and many other reference-worthy links help support the call for atexit-like functionality to be exposed on multiprocessing.Process. There have been multiple issues opened on the bug tracker ultimately requesting this enhancement (do a search for multiprocessing and atexit). I think it's a very sensible enhancement (Antoine did too and perhaps still does) and worth taking the time to pursue. As an aside, I wonder if an equivalent to pthread_cleanup_push should also be exposed on threading.Thread. When it comes to documentation, I am of two minds. There seem to be an increasing number of people coming to Python without much prior exposure to the concepts of threads and processes and so it would be wrong for us to ignore this reality. On the flip side, attempting to convey all the core concepts of threads and processes and how they interact would result in a large documentation effort that ultimately few people would eagerly read to completion. Adding a one-sentence caveat hiding somewhere in the docs won't do much to help. Given this topic and a few other issues that have come up very recently, I suggest that a concise paragraph be added on the topic of using threads and processes together -- likely placed at the beginning of the docs on the Process class. I think I'm up for taking a crack at that but I'd very much appreciate critical eyes to review it with me. Per Eryk's point about the difference in multiprocessing's behavior when using spawn vs. fork, the explanation for why it's done that way is also described in the DeveloperWorks article I mentioned above. Finally, per the original post from pietvo for future readers, not only is it *not* weird to start a Thread within a Process, it's a popular and useful technique. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 22:35:58 2016 From: report at bugs.python.org (Tim Peters) Date: Thu, 14 Jul 2016 02:35:58 +0000 Subject: [issue18966] Threads within multiprocessing Process terminate early In-Reply-To: <1378603227.91.0.146993702012.issue18966@psf.upfronthosting.co.za> Message-ID: <1468463758.16.0.51369711552.issue18966@psf.upfronthosting.co.za> Tim Peters added the comment: Devin, a primary point of `threading.py` is to provide a sane alternative to the cross-platform thread mess. None of these reports are about making it easier for threads to go away "by magic" when the process ends. It's the contrary: they're asking for multiprocessing to respect threading.py's default behavior of making it the programmer's responsibility to shut down their threads cleanly. "Shut down your threads, or we refuse to let the process end." It doesn't matter that native OS threads may behave differently. threading.py very deliberately makes _its_ thread abstraction "non-daemonic" by default, and advertises that behavior for all platforms. So it's at best surprising that threading.Thread's default semantics get turned inside out when multiprocessing creates a process. I still see no reason to believe that's "a feature". As to docs, if it boils down to the difference between `sys.exit()` and `os._exit()`, then _those_ are the places to put details, and multiprocessing docs just need to point out when a created process will use one or the other. As is, the docs don't contain the slightest clue anywhere that a threading.Thread may violate its own docs (with respect to process-exit behavior) when created by a process launched by multiprocessing (or also by a concurrent.futures.ProcessPoolExecutor? I didn't check). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 22:50:34 2016 From: report at bugs.python.org (Eryk Sun) Date: Thu, 14 Jul 2016 02:50:34 +0000 Subject: [issue18966] Threads within multiprocessing Process terminate early In-Reply-To: <1378603227.91.0.146993702012.issue18966@psf.upfronthosting.co.za> Message-ID: <1468464634.44.0.937870213896.issue18966@psf.upfronthosting.co.za> Eryk Sun added the comment: > Per Eryk's point about the difference in multiprocessing's behavior > when using spawn vs. fork, the explanation for why it's done that > way is also described in the DeveloperWorks article I mentioned above. Please spell this out for me. Why can't the "fork" and "forkserver" variations call sys.exit(), and thus Py_Finalize? I don't see why it's OK to call the _shutdown function in Lib/threading.py from a spawned child but not a forked child. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 22:52:27 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 14 Jul 2016 02:52:27 +0000 Subject: [issue27506] make bytes/bytearray delete a keyword argument In-Reply-To: <1468403337.28.0.33019551319.issue27506@psf.upfronthosting.co.za> Message-ID: <1468464747.63.0.71673246606.issue27506@psf.upfronthosting.co.za> Xiang Zhang added the comment: Thanks for your comment Martin. I'll apply them later when we reach agreement on functions. I have already used object = NULL, the C default is not necessary here, and it works as you like I think. In patch version 1, b'abc'.translate(None, None) raises exception as before. I change it in patch version 2 because argument clinic generates function signature as "($self, table, /, delete=None)". So I don't want users get surprised when they provide None as the signature but get an exception. And using None as a placeholder for a keyword argument is normal in Python. But I'm OK to keep the previous behaviour and actually I prefer that. As for making the first argument optional, I don't quite like that since the doc seems to encourage users to set None explicitly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 23:24:32 2016 From: report at bugs.python.org (Tim Peters) Date: Thu, 14 Jul 2016 03:24:32 +0000 Subject: [issue18966] Threads within multiprocessing Process terminate early In-Reply-To: <1378603227.91.0.146993702012.issue18966@psf.upfronthosting.co.za> Message-ID: <1468466672.76.0.230889875286.issue18966@psf.upfronthosting.co.za> Tim Peters added the comment: About ""No parents, no children", that's fine so far as it goes. But Python isn't C, a threading.Thread is not a POSIX thread, and threading.py _does_ have a concept of "the main thread". There's no conceptual problem _in Python_ with saying "the main thread" waits to .join() other non-daemon threading.Threads at process exit. No parent/child relationships are implied by that either - it's just the concept that one thread is distinguished. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 23:30:19 2016 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 14 Jul 2016 03:30:19 +0000 Subject: [issue27487] -m switch regression in Python 3.5.2 (under rare circumstances) In-Reply-To: <1468268291.19.0.631980361837.issue27487@psf.upfronthosting.co.za> Message-ID: <1468467019.3.0.470043570214.issue27487@psf.upfronthosting.co.za> Nick Coghlan added the comment: In http://bugs.python.org/issue27487#msg270300, Wolfgang noted: "In fact, for my own case I have now refactored things a bit so I can avoid the import from __init__.py." So I take that to mean that Wolfgang's particular project is now compatible with the new 3.5.2 behaviour, or at least will be as of its next release (Wolfgang, please correct me if I've misinterpreted your comment). The "double import" implications involved here aren't entirely clearcut though, as even in 3.5.2 if a leaf module invoked via "-m" is a normal module, importing it from the parent package's __init__ module (or any other part of the startup process, like a .pth file) will still lead to it being executed twice. What's changed is that if the leaf module replaces itself in sys.modules with an object that doesn't have a __spec__ attribute, then executing it with -m will fail, rather than re-running the module level code as __main__ the way it will for a normal module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 23:37:23 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 14 Jul 2016 03:37:23 +0000 Subject: [issue22758] Regression in Python 3.2 cookie parsing In-Reply-To: <1414577677.93.0.364604019199.issue22758@psf.upfronthosting.co.za> Message-ID: <20160714033714.28247.72608.ABD6536D@psf.io> Roundup Robot added the comment: New changeset a0bf31e50da5 by Martin Panter in branch '3.2': Issue #22758: Move NEWS entry to Library section https://hg.python.org/cpython/rev/a0bf31e50da5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 23:37:23 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 14 Jul 2016 03:37:23 +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: <20160714033714.28247.18750.058F4CC2@psf.io> Roundup Robot added the comment: New changeset 5b64175c6c24 by Martin Panter in branch '3.2': Issue #27369: Don?t test error message detail that changed in Expat 2.2.0 https://hg.python.org/cpython/rev/5b64175c6c24 New changeset 1c06e02b968a by Martin Panter in branch '3.3': Issue #27369: Merge test_pyexpat from 3.2 into 3.3 https://hg.python.org/cpython/rev/1c06e02b968a New changeset 17ec4d58c046 by Martin Panter in branch '3.4': Issue #27369: Merge test_pyexpat from 3.3 into 3.4 https://hg.python.org/cpython/rev/17ec4d58c046 New changeset 2d6e6600c210 by Martin Panter in branch '2.7': Issue #27369: Don?t test error message detail that changed in Expat 2.2.0 https://hg.python.org/cpython/rev/2d6e6600c210 New changeset 0fbf3b88eed8 by Martin Panter in branch '3.5': Issue #27369: Merge test_pyexpat from 3.4 into 3.5 https://hg.python.org/cpython/rev/0fbf3b88eed8 New changeset 31dc480102fc by Martin Panter in branch 'default': Issue #27369: Merge test_pyexpat from 3.5 https://hg.python.org/cpython/rev/31dc480102fc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 13 23:44:38 2016 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 14 Jul 2016 03:44:38 +0000 Subject: [issue27487] -m switch regression in Python 3.5.2 (under rare circumstances) In-Reply-To: <1468268291.19.0.631980361837.issue27487@psf.upfronthosting.co.za> Message-ID: <1468467878.43.0.00339039871135.issue27487@psf.upfronthosting.co.za> Nick Coghlan added the comment: Perhaps a suitable outcome here would be to just add an unconditional RuntimeWarning when the target of "-m" is already in sys.modules after the parent package import, along the lines of: "RuntimeWarning: '' already in sys.modules prior to '__main__' execution; this may result in unpredictable behaviour" Then if folks get the "ValueError: package.module.__spec__ is not set" message, that would be an example of the noted "unpredictable behaviour", and the suggested resolution would be the path Wolfgang took: find a way to eliminate the warning when executing that particular module as __main__. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 00:11:32 2016 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 14 Jul 2016 04:11:32 +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: <1468469492.67.0.826877227586.issue27369@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 00:13:42 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 14 Jul 2016 04:13:42 +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: <20160714041339.66398.6254.DD86171B@psf.io> Roundup Robot added the comment: New changeset 4f11e6b72e8f by Benjamin Peterson in branch 'default': Backed out changeset af29d89083b3 (closes #25548) (closes #27498) https://hg.python.org/cpython/rev/4f11e6b72e8f ---------- nosy: +ned.deily resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 00:13:42 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 14 Jul 2016 04:13:42 +0000 Subject: [issue27498] Regression in repr() of class object In-Reply-To: <1468338842.06.0.843714859349.issue27498@psf.upfronthosting.co.za> Message-ID: <20160714041339.66398.17666.8D40CEA5@psf.io> Roundup Robot added the comment: New changeset 4f11e6b72e8f by Benjamin Peterson in branch 'default': Backed out changeset af29d89083b3 (closes #25548) (closes #27498) https://hg.python.org/cpython/rev/4f11e6b72e8f ---------- nosy: +ned.deily, python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 00:14:14 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 14 Jul 2016 04:14:14 +0000 Subject: [issue27507] bytearray.extend lacks overflow check when increasing buffer In-Reply-To: <1468429948.12.0.767304648411.issue27507@psf.upfronthosting.co.za> Message-ID: <1468469654.73.0.779451185502.issue27507@psf.upfronthosting.co.za> Martin Panter added the comment: It is possible to make an infinite iterable, e.g. iter(int, 1), so it is definitely worth checking for overflow. The patch looks okay to me. An alternative would be to raise the error without trying to allocate Py_SSIZE_T_MAX first, but I am okay with either way. ---------- nosy: +martin.panter stage: -> patch review versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 00:15:14 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 14 Jul 2016 04:15:14 +0000 Subject: [issue27497] csv module: Add return value to DictWriter.writeheader In-Reply-To: <1468336448.04.0.83850338242.issue27497@psf.upfronthosting.co.za> Message-ID: <1468469714.29.0.111514605706.issue27497@psf.upfronthosting.co.za> Berker Peksag added the comment: By the way, there is an open ticket about changing the recipe in Django documentation: https://code.djangoproject.com/ticket/26040 ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 00:32:55 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 14 Jul 2016 04:32:55 +0000 Subject: [issue27455] Fix tkinter examples to be PEP8 compliant In-Reply-To: <1467724852.16.0.852334218439.issue27455@psf.upfronthosting.co.za> Message-ID: <20160714043252.9468.67821.E7C0DCC0@psf.io> Roundup Robot added the comment: New changeset 453a88a41a58 by Berker Peksag in branch '3.5': Issue #27455: Improve examples in tkinter documentation https://hg.python.org/cpython/rev/453a88a41a58 New changeset 800c069e16a0 by Berker Peksag in branch 'default': Issue #27455: Merge from 3.5 https://hg.python.org/cpython/rev/800c069e16a0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 00:35:15 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 14 Jul 2016 04:35:15 +0000 Subject: [issue27455] Fix tkinter examples to be PEP8 compliant In-Reply-To: <1467724852.16.0.852334218439.issue27455@psf.upfronthosting.co.za> Message-ID: <1468470915.62.0.825520815928.issue27455@psf.upfronthosting.co.za> Berker Peksag added the comment: Since Terry is already busy with IDLE maintenance, I went ahead and commit the patch with minor modifications. Thanks for the patch, John! :) ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 00:45:00 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 14 Jul 2016 04:45:00 +0000 Subject: [issue27507] bytearray.extend lacks overflow check when increasing buffer In-Reply-To: <1468429948.12.0.767304648411.issue27507@psf.upfronthosting.co.za> Message-ID: <1468471500.35.0.346634189303.issue27507@psf.upfronthosting.co.za> Xiang Zhang added the comment: Nice to see the real example. I don't think of that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 00:45:03 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 14 Jul 2016 04:45:03 +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: <20160714044500.124674.46409.EAF5583A@psf.io> Roundup Robot added the comment: New changeset 270fd4493195 by Berker Peksag in branch '3.5': Issue #27180: Clarify Path.rename() behavior on Unix systems https://hg.python.org/cpython/rev/270fd4493195 New changeset 89821243621b by Berker Peksag in branch 'default': Issue #27180: Merge from 3.5 https://hg.python.org/cpython/rev/89821243621b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 00:45:56 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 14 Jul 2016 04:45:56 +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: <1468471556.77.0.726761915577.issue27180@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 Thu Jul 14 00:52:48 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 14 Jul 2016 04:52: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: <20160714045245.79029.66275.B513EAF1@psf.io> Roundup Robot added the comment: New changeset 6b4b73ebb054 by Berker Peksag in branch 'default': Issue #26446: Mention PSF CoC in core developer responsibilities https://hg.python.org/devguide/rev/6b4b73ebb054 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 00:54:31 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 14 Jul 2016 04:54:31 +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: <1468472071.76.0.87696145002.issue26446@psf.upfronthosting.co.za> Berker Peksag added the comment: Sorry, I finally found some time to clear my CPython TODO list. Thanks for the patch, Evelyn! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 00:58:59 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 14 Jul 2016 04:58:59 +0000 Subject: [issue27369] 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: <1468472339.92.0.516427848018.issue27369@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> resolved title: [PATCH] Tests break with --with-system-expat and Expat 2.2.0 -> Tests break with --with-system-expat and Expat 2.2.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 01:41:49 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 14 Jul 2016 05:41:49 +0000 Subject: [issue13312] test_time fails: strftime('%Y', y) for negative year In-Reply-To: <1320166359.06.0.160451222607.issue13312@psf.upfronthosting.co.za> Message-ID: <1468474909.35.0.161582020963.issue13312@psf.upfronthosting.co.za> Martin Panter added the comment: If you enable GCC?s -ftrapv option, the subtraction overflow triggers an abort. Alexander?s patch works around the problem for asctime(), but the problem still exists in other cases, such as: >>> time.mktime((-2**31 + 1899, *(0,) * 8)) Aborted (core dumped) [Exit 134] Attaching a version of the patch without the conflicting whitespace changes. Why does Python even need to support such extreme time values? It would seem much simpler to raise an exception. ---------- nosy: +martin.panter Added file: http://bugs.python.org/file43709/issue13312.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 01:54:37 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Thu, 14 Jul 2016 05:54:37 +0000 Subject: [issue10697] host and port attributes not documented well in function urllib.parse.urlparse and urlsplit In-Reply-To: <1292271440.42.0.107945784803.issue10697@psf.upfronthosting.co.za> Message-ID: <1468475677.22.0.523276388779.issue10697@psf.upfronthosting.co.za> Senthil Kumaran added the comment: I am unsure of the change too. I am willing to close this report as .port attribute is already documented. ---------- resolution: -> not a bug stage: needs patch -> resolved status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 02:29:05 2016 From: report at bugs.python.org (Michael Lazar) Date: Thu, 14 Jul 2016 06:29:05 +0000 Subject: [issue14977] mailcap does not respect precedence in the presence of wildcards In-Reply-To: <1338542933.25.0.233529643572.issue14977@psf.upfronthosting.co.za> Message-ID: <1468477745.64.0.28976752033.issue14977@psf.upfronthosting.co.za> Michael Lazar added the comment: Got it, I found some examples and it didn't look too complicated so I took a shot at it. Is there anything else that needs to be added? Does the documentation need to be updated at all? btw, thanks for the rapid iteration. I appreciate you taking the time to help guide me though this :) ---------- Added file: http://bugs.python.org/file43710/mailcap_v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 02:34:48 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 14 Jul 2016 06:34:48 +0000 Subject: [issue27501] Add typing.py class describing a PEP 3118 buffer object In-Reply-To: <1468346843.82.0.455431578723.issue27501@psf.upfronthosting.co.za> Message-ID: <1468478088.63.0.980130806507.issue27501@psf.upfronthosting.co.za> Changes by Ivan Levkivskyi : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 02:36:51 2016 From: report at bugs.python.org (Charles G.) Date: Thu, 14 Jul 2016 06:36:51 +0000 Subject: [issue27509] Some tests breaks PGO build on Windows Message-ID: <1468478211.0.0.475693084569.issue27509@psf.upfronthosting.co.za> New submission from Charles G.: Environment: Python 3.5.2 Visual Studio 2015 Update 2 Windows 7 amd64 I tried to build python with pgo (build.bat --pgo) but found that no python35!1.pgc or python!1.pgc was created. Then I run the tests one by one while checking the existence of python35!1.pgc and found that these tests when run prevents above pgcs from being created: test_concurrent_futures test_faulthandler test_multiprocessing_main_handling test_multiprocessing_spawn test_os test_subprocess I'm not sure of the reason why no pgc is produced when running these tests. ---------- components: Windows messages: 270374 nosy: Charles G., paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Some tests breaks PGO build on Windows type: compile error versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 02:42:06 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 14 Jul 2016 06:42:06 +0000 Subject: [issue18966] Threads within multiprocessing Process terminate early In-Reply-To: <1378603227.91.0.146993702012.issue18966@psf.upfronthosting.co.za> Message-ID: <1468478526.64.0.958081181317.issue18966@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I agree with Tim. Regardless of what OS threads do, Python tries to enforce predictable semantics of its own. There's no reason (apart from historical baggage) to not join Python threads (and only Python threads, of course, not other OS threads) at the shutdown of a child process. I don't exactly remember why using os._exit() rather than sys.exit() is required in child processes. Presumably it is because we don't want the child to clobber any resources shared with the parent (open files?). This doesn't have to be a binary thing, though: it may as well be os._exit() + a bunch of cleanup steps we know are safe to perform. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 02:42:23 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 14 Jul 2016 06:42:23 +0000 Subject: [issue18966] Threads within multiprocessing Process terminate early In-Reply-To: <1378603227.91.0.146993702012.issue18966@psf.upfronthosting.co.za> Message-ID: <1468478543.28.0.0481137837728.issue18966@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: -> needs patch type: behavior -> enhancement versions: -Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 03:08:05 2016 From: report at bugs.python.org (Decorater) Date: Thu, 14 Jul 2016 07:08:05 +0000 Subject: [issue27509] Some tests breaks PGO build on Windows In-Reply-To: <1468478211.0.0.475693084569.issue27509@psf.upfronthosting.co.za> Message-ID: <1468480085.96.0.185402926868.issue27509@psf.upfronthosting.co.za> Decorater added the comment: What Edition of Visual Studio are you using? I am using Update 3 of 2015 Community and PGO is only (as far as I am aware of) in the Ultimate Edition of Visual Studio. ---------- nosy: +Decorater _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 03:12:59 2016 From: report at bugs.python.org (Charles G.) Date: Thu, 14 Jul 2016 07:12:59 +0000 Subject: [issue27509] Some tests breaks PGO build on Windows In-Reply-To: <1468478211.0.0.475693084569.issue27509@psf.upfronthosting.co.za> Message-ID: <1468480379.64.0.0487886202856.issue27509@psf.upfronthosting.co.za> Charles G. added the comment: Community Edition. PGO is available in the Community Edition since at least VS 2012. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 03:19:01 2016 From: report at bugs.python.org (Charles G.) Date: Thu, 14 Jul 2016 07:19:01 +0000 Subject: [issue27509] Some tests breaks PGO build on Windows In-Reply-To: <1468478211.0.0.475693084569.issue27509@psf.upfronthosting.co.za> Message-ID: <1468480741.13.0.432482856099.issue27509@psf.upfronthosting.co.za> Charles G. added the comment: The compiler itself supports PGO in the Community Edition. I'm not sure about the IDE (not using it). Since I compiled python using the batch file (with msbuild) so it is not limited by the features of the IDE. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 03:27:19 2016 From: report at bugs.python.org (Wolfgang Maier) Date: Thu, 14 Jul 2016 07:27:19 +0000 Subject: [issue27487] -m switch regression in Python 3.5.2 (under rare circumstances) In-Reply-To: <1468268291.19.0.631980361837.issue27487@psf.upfronthosting.co.za> Message-ID: <1468481239.44.0.194550280107.issue27487@psf.upfronthosting.co.za> Wolfgang Maier added the comment: A warning like this sounds good to me though I'd prefer it to be slightly more verbose, like: "RuntimeWarning: '' found in sys.modules after import of package '', but prior to execution of '' as '__main__'; this may result in unpredictable behaviour" or it wouldn't really have helped me much to understand what was happening. P.S.: You understood correctly that my own code is fixed (patch sent to the affected user, next release will have the fix). Learnt something about the whole __spec__ and double import subject along the way so it wasn't completely wasted time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 03:51:52 2016 From: report at bugs.python.org (Decorater) Date: Thu, 14 Jul 2016 07:51:52 +0000 Subject: [issue27510] Found some Solution build missconfigurations. Message-ID: <1468482712.8.0.771661721324.issue27510@psf.upfronthosting.co.za> New submission from Decorater: I went in and looked in the batch build list to find some missconfigurations So, I went in and selected the right ones that I can see currently. ---------- components: Build, Windows files: pcbuild.sln messages: 270380 nosy: Decorater, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Found some Solution build missconfigurations. type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43711/pcbuild.sln _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 04:00:39 2016 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 14 Jul 2016 08:00:39 +0000 Subject: [issue27487] -m switch regression in Python 3.5.2 (under rare circumstances) In-Reply-To: <1468268291.19.0.631980361837.issue27487@psf.upfronthosting.co.za> Message-ID: <1468483239.48.0.878017549218.issue27487@psf.upfronthosting.co.za> Nick Coghlan added the comment: +1 for the more verbose version, since that will tend to nudge folks towards .__init__ as the likely culprit (and that does seem to be the most likely way for this particular double-import scenario to arise. Brett, does that resolution sound reasonable to you, too? Martin, would you have time to put together a follow-up patch adding the warning? (If not, I should be able to make time for it) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 04:33:23 2016 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 14 Jul 2016 08:33:23 +0000 Subject: [issue18966] Threads within multiprocessing Process terminate early In-Reply-To: <1468478543.31.0.832170975833.issue18966@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: One reason for not calling sys.exit() is because on Linux, the default implementation uses fork(), hence the address space in the chilren is a clone of the parent: so all atexit handlers, for example, would be called multiple times. There's also the problem that fork() isn't MT-safe, making the probability of screwups/deadlocks in various destructors/stack unwinding greater. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 04:36:03 2016 From: report at bugs.python.org (Charles G.) Date: Thu, 14 Jul 2016 08:36:03 +0000 Subject: [issue27509] Some tests breaks PGO build on Windows In-Reply-To: <1468478211.0.0.475693084569.issue27509@psf.upfronthosting.co.za> Message-ID: <1468485363.3.0.496928762336.issue27509@psf.upfronthosting.co.za> Charles G. added the comment: Tried with Visual Studio Community 2015 Update 3 with same result. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 04:41:55 2016 From: report at bugs.python.org (Decorater) Date: Thu, 14 Jul 2016 08:41:55 +0000 Subject: [issue27509] Some tests breaks PGO build on Windows In-Reply-To: <1468478211.0.0.475693084569.issue27509@psf.upfronthosting.co.za> Message-ID: <1468485715.72.0.418239429281.issue27509@psf.upfronthosting.co.za> Decorater added the comment: Have you tried the 3.6 branch maybe it was fixed there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 05:06:36 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 14 Jul 2016 09:06:36 +0000 Subject: [issue27511] Add PathLike objects support to BZ2File Message-ID: <1468487196.41.0.384134655138.issue27511@psf.upfronthosting.co.za> New submission from Xiang Zhang: Attach a patch to add PathLike objects support to BZ2File. ---------- files: add_PathLike_objects_support_to_BZ2File.patch keywords: patch messages: 270385 nosy: brett.cannon, ethan.furman, xiang.zhang priority: normal severity: normal status: open title: Add PathLike objects support to BZ2File Added file: http://bugs.python.org/file43712/add_PathLike_objects_support_to_BZ2File.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 05:07:21 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 14 Jul 2016 09:07:21 +0000 Subject: [issue27511] Add PathLike objects support to BZ2File In-Reply-To: <1468487196.41.0.384134655138.issue27511@psf.upfronthosting.co.za> Message-ID: <1468487241.01.0.206233537494.issue27511@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- components: +Library (Lib) type: -> enhancement versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 05:28:13 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 14 Jul 2016 09:28:13 +0000 Subject: [issue27512] os.fspath is certain to crash when exception raised in __fspath__ Message-ID: <1468488493.55.0.648642707869.issue27512@psf.upfronthosting.co.za> New submission from Xiang Zhang: When any exception is raised inside __fspath__, operations involving it like os.fspath, open are certain to crash. >>> import os >>> class Test: ... def __fspath__(self): ... raise RuntimeError ... >>> os.fspath(Test()) Segmentation fault (core dumped) Attach a patch to fix this. ---------- components: Extension Modules files: fix_fspath_crash.patch keywords: patch messages: 270386 nosy: brett.cannon, ethan.furman, xiang.zhang priority: normal severity: normal status: open title: os.fspath is certain to crash when exception raised in __fspath__ type: crash versions: Python 3.6 Added file: http://bugs.python.org/file43713/fix_fspath_crash.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 05:29:44 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 14 Jul 2016 09:29:44 +0000 Subject: [issue27512] os.fspath is certain to crash when exception raised in __fspath__ In-Reply-To: <1468488493.55.0.648642707869.issue27512@psf.upfronthosting.co.za> Message-ID: <1468488584.67.0.0325609613559.issue27512@psf.upfronthosting.co.za> Xiang Zhang added the comment: BTW, the code is also listed in PEP519. So maybe that also needs to be fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 06:01:31 2016 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 14 Jul 2016 10:01:31 +0000 Subject: [issue27497] csv module: Add return value to DictWriter.writeheader In-Reply-To: <1468336448.04.0.83850338242.issue27497@psf.upfronthosting.co.za> Message-ID: <1468490491.98.0.296360931193.issue27497@psf.upfronthosting.co.za> Skip Montanaro added the comment: I agree writeheader() should have returned the value of writerow(), but have no opinion on the more esoteric stuff you're discussing. I think you could argue that adding the "return" would be a bug fix. Personally, I long ago got in the habit of using the writerow(dict(zip(fh, fh))) idiom, didn't catch on at the time that writeheader() was even available in 2.7, and still just use the idiom most of the time. It's a one-liner. The OP could easily use that in contexts where writeheader() doesn't do the right thing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 06:06:32 2016 From: report at bugs.python.org (Logan) Date: Thu, 14 Jul 2016 10:06:32 +0000 Subject: [issue27497] csv module: Add return value to DictWriter.writeheader In-Reply-To: <1468336448.04.0.83850338242.issue27497@psf.upfronthosting.co.za> Message-ID: <1468490792.14.0.845144552209.issue27497@psf.upfronthosting.co.za> Logan added the comment: @berker.peksag: Good catch, thank you. In my code base I'm using a slightly different implementation which does use an iterator, so I didn't even catch that the default django example was incorrect. @skip.montanaro: That is exactly the one-liner I'm currently using. Thank you for documenting it here in case anyone else is looking for the same. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 06:16:34 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Jul 2016 10:16:34 +0000 Subject: [issue27512] os.fspath is certain to crash when exception raised in __fspath__ In-Reply-To: <1468488493.55.0.648642707869.issue27512@psf.upfronthosting.co.za> Message-ID: <1468491394.22.0.126094484451.issue27512@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you add tests? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 06:17:53 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Jul 2016 10:17:53 +0000 Subject: [issue27507] bytearray.extend lacks overflow check when increasing buffer In-Reply-To: <1468429948.12.0.767304648411.issue27507@psf.upfronthosting.co.za> Message-ID: <1468491473.35.0.0976652775484.issue27507@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Totally agreed with Martin. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 06:21:38 2016 From: report at bugs.python.org (Decorater) Date: Thu, 14 Jul 2016 10:21:38 +0000 Subject: [issue27507] bytearray.extend lacks overflow check when increasing buffer In-Reply-To: <1468429948.12.0.767304648411.issue27507@psf.upfronthosting.co.za> Message-ID: <1468491698.8.0.411595125075.issue27507@psf.upfronthosting.co.za> Changes by Decorater : ---------- nosy: +Decorater _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 06:26:49 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 14 Jul 2016 10:26:49 +0000 Subject: [issue27512] os.fspath is certain to crash when exception raised in __fspath__ In-Reply-To: <1468488493.55.0.648642707869.issue27512@psf.upfronthosting.co.za> Message-ID: <1468492009.55.0.863018286934.issue27512@psf.upfronthosting.co.za> Xiang Zhang added the comment: Ahh, adding tests is easy. But this seems to be just a careless omission, so maybe tests is not a must. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 06:34:13 2016 From: report at bugs.python.org (Decorater) Date: Thu, 14 Jul 2016 10:34:13 +0000 Subject: [issue27512] os.fspath is certain to crash when exception raised in __fspath__ In-Reply-To: <1468488493.55.0.648642707869.issue27512@psf.upfronthosting.co.za> Message-ID: <1468492453.95.0.94295765371.issue27512@psf.upfronthosting.co.za> Decorater added the comment: This does also happen in make_zip too as it does not known about the current changes. https://bpaste.net/show/ff826604a5f0 ---------- nosy: +Decorater _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 06:40:35 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 14 Jul 2016 10:40:35 +0000 Subject: [issue27507] bytearray.extend lacks overflow check when increasing buffer In-Reply-To: <1468429948.12.0.767304648411.issue27507@psf.upfronthosting.co.za> Message-ID: <1468492835.95.0.835003350056.issue27507@psf.upfronthosting.co.za> Xiang Zhang added the comment: So would you like to merge it like this or Martin's alternative way? But honestly speaking I don't get Martin's point, "without trying to allocate Py_SSIZE_T_MAX first", where is this place? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 06:41:14 2016 From: report at bugs.python.org (Antti Haapala) Date: Thu, 14 Jul 2016 10:41:14 +0000 Subject: [issue27507] bytearray.extend lacks overflow check when increasing buffer In-Reply-To: <1468429948.12.0.767304648411.issue27507@psf.upfronthosting.co.za> Message-ID: <1468492874.54.0.436292303205.issue27507@psf.upfronthosting.co.za> Antti Haapala added the comment: if (len == PY_SSIZE_T_MAX) is necessary for the case that the iterable is already PY_SSIZE_T_MAX items. However it could be moved inside the *other* if because if (len == PY_SSIZE_T_MAX) should also fail the overflow check. However, I believe it is theoretical at most with stuff that Python supports that it would even be possible to allocate an array of PY_SSIZE_T_MAX *pointers*. The reason is that the maximum size of object can be only that of `size_t`, and Py_ssize_t should be a signed type of that size; and it would thus be possible only to allocate an array of PY_SSIZE_T_MAX pointers only if they're 16 bits wide. In any case, this would be another place where my proposed macro "SUM_OVERFLOWS_PY_SSIZE_T" or something would be in order to make it read if (SUM_OVERFLOWS_PY_SSIZE_T(len, (len >> 1) + 1) which would make it easier to spot mistakes in the sign preceding 1. ---------- nosy: +ztane _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 06:44:04 2016 From: report at bugs.python.org (Decorater) Date: Thu, 14 Jul 2016 10:44:04 +0000 Subject: [issue27512] os.fspath is certain to crash when exception raised in __fspath__ In-Reply-To: <1468488493.55.0.648642707869.issue27512@psf.upfronthosting.co.za> Message-ID: <1468493044.94.0.0319553995268.issue27512@psf.upfronthosting.co.za> Decorater added the comment: nevermind the above traceback from it is a issue with the code that makes it try to copy the redist file from the v14 C++ runtime. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 06:45:50 2016 From: report at bugs.python.org (Antti Haapala) Date: Thu, 14 Jul 2016 10:45:50 +0000 Subject: [issue27512] os.fspath is certain to crash when exception raised in __fspath__ In-Reply-To: <1468488493.55.0.648642707869.issue27512@psf.upfronthosting.co.za> Message-ID: <1468493150.58.0.418995634655.issue27512@psf.upfronthosting.co.za> Antti Haapala added the comment: I believe tests is that they should *especially* be in place for any previously found "careless omissions". If it has been done before, who is to say that it wouldn't happen again? ---------- nosy: +ztane _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 06:48:34 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 14 Jul 2016 10:48:34 +0000 Subject: [issue27512] os.fspath is certain to crash when exception raised in __fspath__ In-Reply-To: <1468488493.55.0.648642707869.issue27512@psf.upfronthosting.co.za> Message-ID: <1468493314.89.0.491159174692.issue27512@psf.upfronthosting.co.za> Xiang Zhang added the comment: I think such omissions are hard to predict and you won't know where is the omission until you encounter it. So if you don't know, how do you know what to put in the tests? And if it is encountered and fixed, such errors should not happen again. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 06:50:11 2016 From: report at bugs.python.org (Hans-Peter Jansen) Date: Thu, 14 Jul 2016 10:50:11 +0000 Subject: [issue27513] email.utils.getaddresses raises exception from erroneous message get_all input Message-ID: <1468493411.01.0.0415400585896.issue27513@psf.upfronthosting.co.za> New submission from Hans-Peter Jansen: An unfortunate combination of get_all and getaddresses results in a Traceback: Traceback (most recent call last): File "misc/decode_from_header.py", line 17, in print('From: %s' % email.utils.getaddresses(val)) File "/usr/lib64/python3.4/email/utils.py", line 112, in getaddresses all = COMMASPACE.join(fieldvalues) TypeError: sequence item 0: expected str instance, Header found Here's the relevant part of it: Content-type: text/html;charset=iso-8859-1 From: Ita? Uniclass. Obviously, the From header is iso-8859-1 encoded as well, and violates RFC 2822 as such. But making it crash in the usual combination of val = msg.get('from') email.utils.getaddresses([val]) isn't the real McCoy either.. ---------- components: email files: iso-8859-1-encoded-from-header.mail messages: 270399 nosy: barry, frispete, r.david.murray priority: normal severity: normal status: open title: email.utils.getaddresses raises exception from erroneous message get_all input type: crash versions: Python 3.4 Added file: http://bugs.python.org/file43714/iso-8859-1-encoded-from-header.mail _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 06:54:05 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 14 Jul 2016 10:54:05 +0000 Subject: [issue27507] bytearray.extend lacks overflow check when increasing buffer In-Reply-To: <1468429948.12.0.767304648411.issue27507@psf.upfronthosting.co.za> Message-ID: <1468493645.56.0.396805570483.issue27507@psf.upfronthosting.co.za> Xiang Zhang added the comment: Thanks for the analysis Antti. I don't think if (len == PY_SSIZE_T_MAX) can be moved inside the *other* if. Their handlings are different. if (len == PY_SSIZE_T_MAX) is True, it should exit immediately. But in the *other* if, you can still have a try to allocate PY_SSIZE_T_MAX memory. As for your overflow macro, I think it's not very useful. First, not only Py_ssize_t can overflow, all signed types can. So a single SUM_OVERFLOWS_PY_SSIZE_T is not enough. Second, current overflow check pattern like a > PY_SSIZE_T_MAX - b is very obvious in my opinion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 06:56:08 2016 From: report at bugs.python.org (Hans-Peter Jansen) Date: Thu, 14 Jul 2016 10:56:08 +0000 Subject: [issue27513] email.utils.getaddresses raises exception from erroneous message get_all input In-Reply-To: <1468493411.01.0.0415400585896.issue27513@psf.upfronthosting.co.za> Message-ID: <1468493768.23.0.755996904007.issue27513@psf.upfronthosting.co.za> Hans-Peter Jansen added the comment: message.get cannot decode the header correctly, and returns a Header instance instead, which makes email.utils.getaddresses stumble upon... A much better behavior for getaddresses in this case would be returning the perfectly valid address, and ignoring the invalid dtext part. ---------- Added file: http://bugs.python.org/file43715/decode_from_header.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 07:42:22 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Jul 2016 11:42:22 +0000 Subject: [issue27512] os.fspath is certain to crash when exception raised in __fspath__ In-Reply-To: <1468488493.55.0.648642707869.issue27512@psf.upfronthosting.co.za> Message-ID: <1468496542.14.0.679232873458.issue27512@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think should be tests for following cases: 1) __fspath__ doesn't exist; 2) __fspath__ is not callable or calling __fspath__() raises an exception; 3) the result of __fspath__() is not valid (wrong type). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 07:50:18 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Jul 2016 11:50:18 +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: <1468497018.6.0.981978475553.issue26579@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: An alternative way is to expose a default state as object.__getstate__(). It is more efficient since it is implemented in C. Following patch implements this approach. ---------- Added file: http://bugs.python.org/file43716/object_getstate.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 08:25:39 2016 From: report at bugs.python.org (Emanuel Barry) Date: Thu, 14 Jul 2016 12:25:39 +0000 Subject: [issue27510] Found some Solution build missconfigurations. In-Reply-To: <1468482712.8.0.771661721324.issue27510@psf.upfronthosting.co.za> Message-ID: <1468499139.28.0.0963107011235.issue27510@psf.upfronthosting.co.za> Emanuel Barry added the comment: Please submit a patch file (see https://docs.python.org/devguide/patch.html ). ---------- nosy: +ebarry stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 08:33:51 2016 From: report at bugs.python.org (ppperry) Date: Thu, 14 Jul 2016 12:33:51 +0000 Subject: [issue27514] SystemError when compiling deeply nested for loops Message-ID: <1468499631.41.0.70687115065.issue27514@psf.upfronthosting.co.za> New submission from ppperry: The following code: for a in range(26): for b in range(26): for c in range(26): for d in range(26): for e in range(26): for f in range(26): for g in range(26): for h in range(26): for i in range(26): for j in range(26): for k in range(26): for l in range(26): for m in range(26): for o in range(26): for p in range(26): for q in range(26): for r in range(26): for s in range(26): for t in range(26): for u in range(26): for v in range(26): for w in range(26): pass fails to compile with `SystemError:too many statically nested blocks`, which was described as a serious bug in issue27081. ---------- components: Interpreter Core messages: 270405 nosy: benjamin.peterson, brett.cannon, georg.brandl, ncoghlan, ppperry, serhiy.storchaka, yselivanov priority: normal severity: normal status: open title: SystemError when compiling deeply nested for loops type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 08:35:59 2016 From: report at bugs.python.org (ppperry) Date: Thu, 14 Jul 2016 12:35:59 +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: <1468499759.65.0.359345384346.issue25733@psf.upfronthosting.co.za> ppperry added the comment: >SystemError is serious bug. Please open separate issue for this. Done. I created issue27514 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 08:38:44 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 14 Jul 2016 12:38:44 +0000 Subject: [issue27497] csv module: Add return value to DictWriter.writeheader In-Reply-To: <1468336448.04.0.83850338242.issue27497@psf.upfronthosting.co.za> Message-ID: <1468499924.46.0.670202102742.issue27497@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm now ok to add the return, but only in Python 3.6. It would be a minor new "feature". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 09:13:12 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 14 Jul 2016 13:13:12 +0000 Subject: [issue27512] os.fspath is certain to crash when exception raised in __fspath__ In-Reply-To: <1468488493.55.0.648642707869.issue27512@psf.upfronthosting.co.za> Message-ID: <1468501992.76.0.78006014317.issue27512@psf.upfronthosting.co.za> Xiang Zhang added the comment: The test requests for the whole fspath are reasonable. I just don't want to add tests for these two lines. 1) and 3) have already been tested. I add 2) and reorganize the existing tests a little. ---------- Added file: http://bugs.python.org/file43717/fix_fspath_crash_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 09:41:11 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Jul 2016 13:41:11 +0000 Subject: [issue27514] SystemError when compiling deeply nested for loops In-Reply-To: <1468499631.41.0.70687115065.issue27514@psf.upfronthosting.co.za> Message-ID: <1468503671.97.0.710454049002.issue27514@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There is a static limit for the number of statically nested blocks. Getting rid of this limit looks not easy. But SystemError is not an exception that should be raised. SystemError is for errors that can't be occurred in normal case. It should only be caused by incorrect use of C API or hacking Python internals. I think SyntaxError is more appropriate in this case (as in case of passing more than 255 arguments to a function). ---------- stage: -> needs patch versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 10:09:03 2016 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 14 Jul 2016 14:09:03 +0000 Subject: [issue27514] SystemError when compiling deeply nested for loops In-Reply-To: <1468499631.41.0.70687115065.issue27514@psf.upfronthosting.co.za> Message-ID: <1468505343.61.0.64917384501.issue27514@psf.upfronthosting.co.za> Nick Coghlan added the comment: +1 for Serhiy's recommendation. It's OK for the compiler to say "Don't do that", but the correct error is SyntaxError, even when it's a limitation later in the code generation pipeline (rather than failing to comply with the language grammar) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 10:12:15 2016 From: report at bugs.python.org (Jim Fulton) Date: Thu, 14 Jul 2016 14:12:15 +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: <1468505535.01.0.43399791412.issue27392@psf.upfronthosting.co.za> Jim Fulton added the comment: Here's a daft doc update. ---------- keywords: +patch Added file: http://bugs.python.org/file43718/connect_accepted_socket-doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 10:16:07 2016 From: report at bugs.python.org (Daniel Moisset) Date: Thu, 14 Jul 2016 14:16:07 +0000 Subject: [issue27501] Add typing.py class describing a PEP 3118 buffer object In-Reply-To: <1468346843.82.0.455431578723.issue27501@psf.upfronthosting.co.za> Message-ID: <1468505767.0.0.186636107782.issue27501@psf.upfronthosting.co.za> Daniel Moisset added the comment: As a description of the idea I'm attaching a rough patch with an implementation. Some tests fail because of the following: 1) I didn't find a good place to register the Buffer ABC for mmap.mmap, and array.mmap; the modeules themselves are C extensions (and it's possible but weird to register the ABC from the C API); I could import those in typing.py but then I'd make typing depend from mmap and array which also feels wrong; so I didn't do that and the related tests that I added fail. 2) I had a similar situation with io.BytesIO. In that case there's a python module and I'm doing the abc.register there, but now io imports typing, and the test_site fails because many new modules (typing and its dependencies) are imported on startup. The alternative is to make typing depend on io (in this case it could be a reasonable idea) After these, I'm feeling that typing.py may not be the best place for this (but given that collections.abc isn't either, I'm not sure where's the right place) ---------- keywords: +patch Added file: http://bugs.python.org/file43719/buffer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 10:21:09 2016 From: report at bugs.python.org (Steve Dower) Date: Thu, 14 Jul 2016 14:21:09 +0000 Subject: [issue27510] Found some Solution build missconfigurations. In-Reply-To: <1468482712.8.0.771661721324.issue27510@psf.upfronthosting.co.za> Message-ID: <1468506069.82.0.165259778921.issue27510@psf.upfronthosting.co.za> Steve Dower added the comment: I believe changes to the batch build dialog are local to your machine, so there won't be any changes to the solution file. A regular build should include all packages. Can you explain what didn't work and why you needed to fix it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 10:49:37 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 14 Jul 2016 14:49:37 +0000 Subject: [issue18858] dummy_threading lacks threading.get_ident() equivalent In-Reply-To: <1377638843.21.0.0472654933915.issue18858@psf.upfronthosting.co.za> Message-ID: <1468507777.98.0.531788031282.issue18858@psf.upfronthosting.co.za> Berker Peksag added the comment: > This patch adds a test but does not fix the bug. I forgot to explain what the first patch does. The specific problem reported by OP has already been fixed in default branch (but not in 3.5) so issue18858.diff was added a test to make sure that threading and dummy_threading API are in sync. dummy_threading.currentThread() and dummy_threading.activeCount() still don't work in both 3.5 and default branches so we basically need two different patches. I'm attaching a patch for 3.5. ---------- stage: needs patch -> patch review Added file: http://bugs.python.org/file43720/issue18858_v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 10:51:38 2016 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 14 Jul 2016 14:51:38 +0000 Subject: [issue13312] test_time fails: strftime('%Y', y) for negative year In-Reply-To: <1320166359.06.0.160451222607.issue13312@psf.upfronthosting.co.za> Message-ID: <1468507898.83.0.396043044977.issue13312@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 11:15:15 2016 From: report at bugs.python.org (Davin Potts) Date: Thu, 14 Jul 2016 15:15:15 +0000 Subject: [issue18966] Threads within multiprocessing Process terminate early In-Reply-To: <1378603227.91.0.146993702012.issue18966@psf.upfronthosting.co.za> Message-ID: <1468509315.43.0.2904238565.issue18966@psf.upfronthosting.co.za> Davin Potts added the comment: Tim: Totally agreed about threading.Thread not being a POSIX thread. It was not my intent to suggest that they were equivalent -- apologies for the confusion. Instead I was attempting to describe a mentality of processes and their common behavior across multiple platforms at termination. The behavior of child processes via multiprocessing currently appears to follow this common mentality of signal the threads then exit quickly. (To avoid confusion, I am making an observation here.) Whereas threading.Thread is attempting to provide something homogeneous across platforms, achieving a similar goal in multiprocessing.Process is complicated by the concepts of fork vs. spawn and their availability on various OSes (a source of real confusion for some). This further opens the question of what should the mentality be for multiprocessing.Process? The notion that a process can die in such a way that not all of its threads were given time to clean up does not strike me as a foreign concept. The notion that a threading.Thread should always be (or at least be attempted to be) joined makes sense. The notion of categorically refusing to let a process end perhaps overreaches in certain situations. I believe the more general solution exists in offering atexit handlers on multiprocessing.Process. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 11:31:26 2016 From: report at bugs.python.org (Ethan Furman) Date: Thu, 14 Jul 2016 15:31:26 +0000 Subject: [issue27512] os.fspath is certain to crash when exception raised in __fspath__ In-Reply-To: <1468488493.55.0.648642707869.issue27512@psf.upfronthosting.co.za> Message-ID: <1468510286.67.0.33613579118.issue27512@psf.upfronthosting.co.za> Ethan Furman added the comment: > I think such omissions are hard to predict and you won't know where is > the omission until you encounter it. So if you don't know, how do you > know what to put in the tests? True. > And if it is encountered and fixed, such errors should not happen again. False. Such errors *will* happen again -- they are called regressions. In order to avoid those we add tests, and those tests serve several purposes: - confirm the problem has been fixed (not every bug is a core-dump) - confirm that changes in the future don't reintroduce the bug - communicate past difficulties and possible gotchas to new developers In short: add tests; patches are not complete without them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 11:38:54 2016 From: report at bugs.python.org (Ethan Furman) Date: Thu, 14 Jul 2016 15:38:54 +0000 Subject: [issue27512] os.fspath is certain to crash when exception raised in __fspath__ In-Reply-To: <1468488493.55.0.648642707869.issue27512@psf.upfronthosting.co.za> Message-ID: <1468510734.57.0.746813442899.issue27512@psf.upfronthosting.co.za> Ethan Furman added the comment: > I ... reorganize the existing tests a little. Please don't. Moving tests around makes it harder for reviewers to see what actually changed. Rewriting tests to do the same thing as before also takes more work from reviewers as we have to verify the new code does the same as the old code, and then wonder why the change was made. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 11:57:38 2016 From: report at bugs.python.org (Futur Fusionneur) Date: Thu, 14 Jul 2016 15:57:38 +0000 Subject: [issue25144] 3.5 Win install fails with "TARGETDIR" In-Reply-To: <1442424932.17.0.0389991499722.issue25144@psf.upfronthosting.co.za> Message-ID: <1468511858.67.0.47480620245.issue25144@psf.upfronthosting.co.za> Futur Fusionneur added the comment: For me the custom installer worked by combining the two solutions above: 1. open an elevated command prompt 2. run the installer by specifying the TargetDir ---------- nosy: +Futur Fusionneur _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 11:58:12 2016 From: report at bugs.python.org (Eryk Sun) Date: Thu, 14 Jul 2016 15:58:12 +0000 Subject: [issue18966] Threads within multiprocessing Process terminate early In-Reply-To: <1378603227.91.0.146993702012.issue18966@psf.upfronthosting.co.za> Message-ID: <1468511892.27.0.865192119542.issue18966@psf.upfronthosting.co.za> Eryk Sun added the comment: > all atexit handlers, for example, would be called multiple times. Davin is (I think) proposing a multiprocessing atexit facility, which can be used to ensure threading._shutdown is called. But could Python's regular atexit handling be reset in the child, allowing Py_Finalize to be called? In other words, can atexit can be integrated into the PyOS_AfterFork (Modules/signalmodule.c) sequence? multiprocessing could set a sys flag that forces atexit to clear its registered handlers, and for Py_AtExit, reset the static nexitfuncs variable in Python/pylifecycle.c. Or is that just opening a can of worms that will cause Py_Finalize to crash in various scenarios? > There's also the problem that fork() isn't MT-safe This issue is about joining Python threads created in the child, which has a clean slate via PyOS_AfterFork, PyEval_ReInitThreads (Python/ceval.c), and threading._after_fork. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 12:06:17 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 14 Jul 2016 16:06:17 +0000 Subject: [issue27512] os.fspath is certain to crash when exception raised in __fspath__ In-Reply-To: <1468488493.55.0.648642707869.issue27512@psf.upfronthosting.co.za> Message-ID: <1468512377.58.0.74044254323.issue27512@psf.upfronthosting.co.za> Xiang Zhang added the comment: I have to explain for myself. First, I know tests *are* important. This is not the first time uploading patches here. I don't want to add tests for this case is because such codes: call something and test for failure appears all the places in the code base. This case is nothing special. For this reason, I think simply add the missing code back is enough. But then Serhiy presents his opinion that some test cases should be added, I think it's quite reasonable because it's testing the whole fspath behaviour, not just this case. Second, maybe I cannot agree with your opinions in your last message. I think changes are welcome if they *are* reasonable. The unreasonable aspects including what you have stated. For this patch, I don't know which part is unreasonable. Moving test_fsencode_fsdecode after test_pathlike makes the first 3 tests test for valid arguments. Extracting bad pathlike tests into a single test does not sounds like a bad idea. And it's small, right? So it's not hard to figure out what the change is made and what is actually changed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 12:36:43 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 14 Jul 2016 16:36:43 +0000 Subject: [issue18966] Threads within multiprocessing Process terminate early In-Reply-To: <1378603227.91.0.146993702012.issue18966@psf.upfronthosting.co.za> Message-ID: <1468514203.27.0.796481581409.issue18966@psf.upfronthosting.co.za> R. David Murray added the comment: As far as muliprocessing's "mentality" goes, it aims to provide the *same* API as Threading, so it is logical that it should preserve threading's behavior with respect to child threads in a process, rather than violating threading's model. Anything else is counter-intuitive to a python programmer, as demonstrated by this issue and Tim's comments :) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 12:37:57 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 14 Jul 2016 16:37:57 +0000 Subject: [issue18966] Threads within multiprocessing Process terminate early In-Reply-To: <1378603227.91.0.146993702012.issue18966@psf.upfronthosting.co.za> Message-ID: <1468514277.02.0.954510129625.issue18966@psf.upfronthosting.co.za> R. David Murray added the comment: Note, however, that fixing this will be a backward compatibility issue, since there are doubtless programs relying on this behavior, probably mostly unintentionally. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 12:45:59 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 14 Jul 2016 16:45:59 +0000 Subject: [issue14977] mailcap does not respect precedence in the presence of wildcards In-Reply-To: <1338542933.25.0.233529643572.issue14977@psf.upfronthosting.co.za> Message-ID: <1468514759.61.0.265140216546.issue14977@psf.upfronthosting.co.za> R. David Murray added the comment: I think a doc update is probably worthwhile, but I haven't looked at the docs so I'm not sure. I'll try to give this a complete review this weekend, though I'm a bit busy so it may not happen. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 12:47:24 2016 From: report at bugs.python.org (Eric Snow) Date: Thu, 14 Jul 2016 16:47:24 +0000 Subject: [issue23722] During metaclass.__init__, super() of the constructed class does not work In-Reply-To: <1426859061.43.0.510286082444.issue23722@psf.upfronthosting.co.za> Message-ID: <1468514844.31.0.116126289152.issue23722@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 12:49:36 2016 From: report at bugs.python.org (Jaysinh shukla) Date: Thu, 14 Jul 2016 16:49:36 +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: <1468514976.92.0.949205375082.issue20842@psf.upfronthosting.co.za> Jaysinh shukla added the comment: Adding updated patch after merging Issue 26896. Requesting to review. Thanks! ---------- Added file: http://bugs.python.org/file43721/issue20842_v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 12:56:41 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 14 Jul 2016 16:56:41 +0000 Subject: [issue27513] email.utils.getaddresses does not handle Header objects In-Reply-To: <1468493411.01.0.0415400585896.issue27513@psf.upfronthosting.co.za> Message-ID: <1468515401.91.0.811038002815.issue27513@psf.upfronthosting.co.za> R. David Murray added the comment: This appears to be something that was overlooked when btyes support was added in 3.2. getaddresses should indeed be able to handle a Header object if handed one. ---------- title: email.utils.getaddresses raises exception from erroneous message get_all input -> email.utils.getaddresses does not handle Header objects versions: +Python 3.5, Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 13:19:36 2016 From: report at bugs.python.org (Neil Schemenauer) Date: Thu, 14 Jul 2016 17:19:36 +0000 Subject: [issue27377] Add smarter socket.fromfd() In-Reply-To: <1466706816.6.0.72770597716.issue27377@psf.upfronthosting.co.za> Message-ID: <1468516776.5.0.561829363878.issue27377@psf.upfronthosting.co.za> Neil Schemenauer added the comment: I just tested on Windows. fdtype() fails with: OSError: [WinError 10022] An invalid argument was supplied The getsockname() call fails with WSAGetLastError() == 10022. getsockname() is used to find the address family. Perhaps there is some other way to get it on Windows. The easiest fix would be to #ifdef MS_WINDOWS out the whole socket_fdtype() function. Passing file descriptors around is not a thing on Windows anyhow. There is still the issue of unexpected errors getting returned inside fdtype() (e.g. as suggested by Martin). One idea is to commit the code as is and fix errors as they appear. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 13:24:16 2016 From: report at bugs.python.org (Brett Cannon) Date: Thu, 14 Jul 2016 17:24:16 +0000 Subject: [issue27487] -m switch regression in Python 3.5.2 (under rare circumstances) In-Reply-To: <1468268291.19.0.631980361837.issue27487@psf.upfronthosting.co.za> Message-ID: <1468517056.66.0.463544738128.issue27487@psf.upfronthosting.co.za> Brett Cannon added the comment: +1 from me ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 13:30:58 2016 From: report at bugs.python.org (Brett Cannon) Date: Thu, 14 Jul 2016 17:30:58 +0000 Subject: [issue27512] os.fspath is certain to crash when exception raised in __fspath__ In-Reply-To: <1468488493.55.0.648642707869.issue27512@psf.upfronthosting.co.za> Message-ID: <1468517458.63.0.880391737783.issue27512@psf.upfronthosting.co.za> Brett Cannon added the comment: The reordering of the tests is unnecessary. Because you both changed the code *and* moved a test you have to be very careful to notice the change, otherwise it just looks like you cut-and-pasted the code to another location. Had you left the test method where it was and just simplified the code then it would be very obvious what you changed and reviewing it would be much easier. ---------- assignee: -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 13:31:43 2016 From: report at bugs.python.org (Neil Schemenauer) Date: Thu, 14 Jul 2016 17:31:43 +0000 Subject: [issue27377] Add smarter socket.fromfd() In-Reply-To: <1466706816.6.0.72770597716.issue27377@psf.upfronthosting.co.za> Message-ID: <1468517503.46.0.0945386638167.issue27377@psf.upfronthosting.co.za> Neil Schemenauer added the comment: Updated patch, v5. Disable fdtype() function on Windows. Fix documentation nits as suggested by review of v4. ---------- Added file: http://bugs.python.org/file43722/fromfd2_v5.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 13:43:49 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 14 Jul 2016 17:43:49 +0000 Subject: [issue27512] os.fspath is certain to crash when exception raised in __fspath__ In-Reply-To: <1468488493.55.0.648642707869.issue27512@psf.upfronthosting.co.za> Message-ID: <1468518229.9.0.279472727533.issue27512@psf.upfronthosting.co.za> Xiang Zhang added the comment: Thanks Brett, also others. Restore the moving around. ---------- Added file: http://bugs.python.org/file43723/fix_fspath_crash_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 13:50:08 2016 From: report at bugs.python.org (Eric Snow) Date: Thu, 14 Jul 2016 17:50:08 +0000 Subject: [issue24254] Make class definition namespace ordered by default In-Reply-To: <1432186488.39.0.20621749373.issue24254@psf.upfronthosting.co.za> Message-ID: <1468518608.7.0.221441984338.issue24254@psf.upfronthosting.co.za> Eric Snow added the comment: FTR: PEP 520 "Preserving Class Attribute Definition Order" (https://www.python.org/dev/peps/pep-0520/) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 14:31:39 2016 From: report at bugs.python.org (Neil Schemenauer) Date: Thu, 14 Jul 2016 18:31:39 +0000 Subject: [issue27377] Add smarter socket.fromfd() In-Reply-To: <1466706816.6.0.72770597716.issue27377@psf.upfronthosting.co.za> Message-ID: <1468521099.64.0.395744800463.issue27377@psf.upfronthosting.co.za> Neil Schemenauer added the comment: Tested on FreeBSD 10.3. getsockname() on a IPPROTO_SCTP protocol socket returns errno = FileNoFoundError. We could just comment out that test I guess. My theory is that on FreeBSD, getsockname() on an SCTP socket fails if it is not bound. Indeed, adding a bind(('127.0.0.1', 11234)) call before the fdtype() call makes the test pass. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 14:46:35 2016 From: report at bugs.python.org (Tim Peters) Date: Thu, 14 Jul 2016 18:46:35 +0000 Subject: [issue18966] Threads within multiprocessing Process terminate early In-Reply-To: <1378603227.91.0.146993702012.issue18966@psf.upfronthosting.co.za> Message-ID: <1468521995.19.0.538272459706.issue18966@psf.upfronthosting.co.za> Tim Peters added the comment: About: "The notion of categorically refusing to let a process end perhaps overreaches in certain situations." threading.py addressed that all along: if the programmer _wants_ the process to exit without waiting for a particular threading.Thread, that's fine, they ask the Thread constructor for a "daemon" thread. Whether a threading.Thread does or doesn't prevent process exit before it's .join()'ed has always been the programmer's choice. Python never attempted to guess their intent (except for "the main thread", which is necessarily non-daemonic). That's why it's especially surprising that multiprocessing can silently overrule what had always been an explicit choice about process-exit threading.Thread behavior. About compatibility, yup, that's potentially painful. I will note that compability was already broken on Windows with no apparent angst, or subsequent complaints (the program in issue 27508 is an example: "runs forever" under 3.5.2 but "ends very quickly" under 2.7.11; "runs forever" is what the programmer wanted, matching how they expected non-daemon threading.Threads to work). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 15:36:44 2016 From: report at bugs.python.org (Alakshendra Yadav) Date: Thu, 14 Jul 2016 19:36:44 +0000 Subject: [issue25393] 'resource' module documentation error In-Reply-To: <1444746542.39.0.814536865396.issue25393@psf.upfronthosting.co.za> Message-ID: <1468525004.89.0.475139729321.issue25393@psf.upfronthosting.co.za> Alakshendra Yadav added the comment: It does seem that the mentioned line belongs under RLIMIT_STACK instead of RLIMIT_FSIZE. I am submitting a patch. ---------- keywords: +patch nosy: +Alakshendra Yadav Added file: http://bugs.python.org/file43724/resource.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 16:18:36 2016 From: report at bugs.python.org (Decorater) Date: Thu, 14 Jul 2016 20:18:36 +0000 Subject: [issue27510] Found some Solution build missconfigurations. In-Reply-To: <1468482712.8.0.771661721324.issue27510@psf.upfronthosting.co.za> Message-ID: <1468527516.5.0.63628424034.issue27510@psf.upfronthosting.co.za> Decorater added the comment: Some parts rargenting win32 was having the solution set of 64 bit making x86 with x64 setting mixups. Basically it was doing both 32 and 64 bit assembling at the same time which of course would make it fail. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 16:24:30 2016 From: report at bugs.python.org (Decorater) Date: Thu, 14 Jul 2016 20:24:30 +0000 Subject: [issue27510] Found some Solution build missconfigurations. In-Reply-To: <1468482712.8.0.771661721324.issue27510@psf.upfronthosting.co.za> Message-ID: <1468527870.66.0.88149624645.issue27510@psf.upfronthosting.co.za> Decorater added the comment: was targeting* ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 16:47:15 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 14 Jul 2016 20:47:15 +0000 Subject: [issue27501] Add typing.py class describing a PEP 3118 buffer object In-Reply-To: <1468346843.82.0.455431578723.issue27501@psf.upfronthosting.co.za> Message-ID: <1468529235.37.0.77055830545.issue27501@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Looking at the patch, I'm thinking that this endeavor isn't at all worthwhile. We don't need an ABC for everything especially if there in no pure python API involved. I recommend closing this one until there is a proven need and a clear path forward. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 16:48:35 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 14 Jul 2016 20:48:35 +0000 Subject: [issue27515] Dotted name re-import does not rebind after deletion Message-ID: <1468529315.51.0.393890498474.issue27515@psf.upfronthosting.co.za> New submission from Terry J. Reedy: https://docs.python.org/3/reference/simple_stmts.html#the-import-statement says that import , where can optionally be a dotted name referring to a module within a package, does two things: 1. Find a module object corresponding to , creating it if necessary. 2. Bind the object to the name in the local namespace. In short, 'import x' is shorthand for "x = __import__('x', ...)". AFAIK, this works for simple names, including re-imports after name deletion. >>> import email; email >>> del email >>> import email; email However, the same is not true for dotted names. >>> import email.charset; email.charset >>> del email.charset >>> import email.charset; email.charset Traceback (most recent call last): File "", line 1, in import email.charset; email.charset AttributeError: module 'email' has no attribute 'charset' It appears that for dotted names, when step 1 is cut short by finding the cached module, step 2 is (improperly) omitted. I consider this a bug in the code rather than the doc. I think the name binding should not depend on how the module was found. I don't know whether the bug is somewhere in importlib or in the core machinery that uses it. This bug, in relation to tkinter package modues, prevented and AFAIK prevents me from fixing the bug of #25507 in 3.x versions prior to 3.6 (Tkinter in 2.x was not a package). (For 3.6, I can and will refactor idlelib to eliminate the need for the deletion by preventing excess imports.) ---------- components: Interpreter Core, Library (Lib) messages: 270438 nosy: brett.cannon, eric.snow, ncoghlan, terry.reedy priority: normal severity: normal stage: test needed status: open title: Dotted name re-import does not rebind after deletion type: behavior versions: Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 16:56:46 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 14 Jul 2016 20:56:46 +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: <1468529806.87.0.374443429146.issue25958@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: What holds back this issue now? It looks like Andrew did a great job. When I was making a patch for #25987 following Andrew's ideas, I was surprised how many different idioms has been used for __subclasshook__. I was going to open an issue on this, when I noticed a week ago that there is already this issue. Is any help needed here? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 16:57:43 2016 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 14 Jul 2016 20:57:43 +0000 Subject: [issue27515] Dotted name re-import does not rebind after deletion In-Reply-To: <1468529315.51.0.393890498474.issue27515@psf.upfronthosting.co.za> Message-ID: <1468529863.57.0.0541562722021.issue27515@psf.upfronthosting.co.za> Guido van Rossum added the comment: I don't think this is a bug. You're paraphrasing step 2 incorrectly. The local name-binding behavior just creates a local named "email" -- it doesn't concern itself with ensuring that the email package has an attribute "charset". That attribute is set as a side effect of *loading* the charset submodule, not as a side effect of every import statement. ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 17:04:25 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 14 Jul 2016 21:04:25 +0000 Subject: [issue27515] Dotted name re-import does not rebind after deletion In-Reply-To: <1468529315.51.0.393890498474.issue27515@psf.upfronthosting.co.za> Message-ID: <1468530265.64.0.528512628877.issue27515@psf.upfronthosting.co.za> R. David Murray added the comment: Or, to put it another way, you deleted the charset attribute from the email module. On the second import, import finds email in sys.modules, so it doesn't reimport it, so charset doesn't get recreated. So, the difference is you didn't do 'del email'. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 17:08:57 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 14 Jul 2016 21:08:57 +0000 Subject: [issue27515] Dotted name re-import does not rebind after deletion In-Reply-To: <1468529315.51.0.393890498474.issue27515@psf.upfronthosting.co.za> Message-ID: <1468530537.43.0.448635875235.issue27515@psf.upfronthosting.co.za> R. David Murray added the comment: Heh, actually strike that last sentence. Doing a del doesn't remove the module from sys.modules, so the version of the email module with charset deleted is still there, and doing del email and import email or import email.charset will not change the fact that charset is still deleted in the extant module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 17:09:09 2016 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 14 Jul 2016 21:09:09 +0000 Subject: [issue27515] Dotted name re-import does not rebind after deletion In-Reply-To: <1468530265.64.0.528512628877.issue27515@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: > On the second import, import finds email in sys.modules Actually, it only takes the shortcut because it also finds email.charset in sys.modules. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 17:14:25 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 14 Jul 2016 21:14:25 +0000 Subject: [issue27515] Dotted name re-import does not rebind after deletion In-Reply-To: <1468529315.51.0.393890498474.issue27515@psf.upfronthosting.co.za> Message-ID: <1468530865.36.0.931551458761.issue27515@psf.upfronthosting.co.za> R. David Murray added the comment: So, Guido answered your actual question, and I was confused :( The important point is that email.charset still exists in sys.modules, so import doesn't reload it, and as Guido says module load is the thing that creates the attribute mapping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 17:24:07 2016 From: report at bugs.python.org (Ammar Askar) Date: Thu, 14 Jul 2016 21:24:07 +0000 Subject: [issue27514] SystemError when compiling deeply nested for loops In-Reply-To: <1468499631.41.0.70687115065.issue27514@psf.upfronthosting.co.za> Message-ID: <1468531447.95.0.69384026197.issue27514@psf.upfronthosting.co.za> Ammar Askar added the comment: This patch changes it to a SyntaxError instead of a SystemError. ---------- keywords: +patch nosy: +ammar2 Added file: http://bugs.python.org/file43725/nested_blocks.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 17:37:19 2016 From: report at bugs.python.org (Ammar Askar) Date: Thu, 14 Jul 2016 21:37:19 +0000 Subject: [issue27514] SystemError when compiling deeply nested for loops In-Reply-To: <1468499631.41.0.70687115065.issue27514@psf.upfronthosting.co.za> Message-ID: <1468532239.74.0.518428450379.issue27514@psf.upfronthosting.co.za> Ammar Askar added the comment: Amended patch with the comment fixed to refer to just the issue numbers according to advice from bitdancer. ---------- Added file: http://bugs.python.org/file43726/nested_blocks.diff2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 18:50:14 2016 From: report at bugs.python.org (Palm Kevin) Date: Thu, 14 Jul 2016 22:50:14 +0000 Subject: [issue27516] Wrong initialization of python path with embeddable distribution Message-ID: <1468536614.57.0.563747018021.issue27516@psf.upfronthosting.co.za> New submission from Palm Kevin: The way the python path is initialized with the embeddable python distribution makes no sense for me. If no environment variable PYTHONPATH is set, then the path is initialized like this: [python352]\python35.zip;.\DLLs;.\lib;[folder_of_executable] --> the distribution folder itself is not in the path ([python352]), an import of _socket will thus fail ! --> Having DLLs and lib in the path is useless (Notice, that when the PYTHONHOME is initialized, then the path '[python352]' is also used for DLLs and lib (instead of '.\') If the environment variable PYTHONPATH is set, then the path is extended like this: [python352]\python35.zip;[folder_of_executable] --> the distribution folder itself is not in the path ([python352]), an import of _socket will thus fail ! I would prefer this behavior: * python path is not initialized anymore with 'DLLs' and 'lib' * the distribution-folder should always be added to the python-path ---------- messages: 270447 nosy: palm.kevin priority: normal severity: normal status: open title: Wrong initialization of python path with embeddable distribution type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 18:55:17 2016 From: report at bugs.python.org (Steve Dower) Date: Thu, 14 Jul 2016 22:55:17 +0000 Subject: [issue27510] Found some Solution build missconfigurations. In-Reply-To: <1468482712.8.0.771661721324.issue27510@psf.upfronthosting.co.za> Message-ID: <1468536917.95.0.78910789396.issue27510@psf.upfronthosting.co.za> Steve Dower added the comment: I just checked and the pcbuild.sln you posted is identical to what's currently checked in. Batch build settings are not part of the checkin, so if you want to use that rather than using the build scripts we provide (see PCBuild/build.bat) then you'll need to configure the selection locally. ---------- resolution: -> not a bug stage: needs patch -> status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 19:10:10 2016 From: report at bugs.python.org (Ned Deily) Date: Thu, 14 Jul 2016 23:10:10 +0000 Subject: [issue27516] Wrong initialization of python path with embeddable distribution In-Reply-To: <1468536614.57.0.563747018021.issue27516@psf.upfronthosting.co.za> Message-ID: <1468537810.11.0.454801773948.issue27516@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 19:13:58 2016 From: report at bugs.python.org (Palm Kevin) Date: Thu, 14 Jul 2016 23:13:58 +0000 Subject: [issue27516] Wrong initialization of python path with embeddable distribution In-Reply-To: <1468536614.57.0.563747018021.issue27516@psf.upfronthosting.co.za> Message-ID: <1468538038.47.0.720854603642.issue27516@psf.upfronthosting.co.za> Palm Kevin added the comment: BTW: Is there a good reason, the folder-of-the-executable is added to the python-path? I don't see any... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 20:09:05 2016 From: report at bugs.python.org (Steve Dower) Date: Fri, 15 Jul 2016 00:09:05 +0000 Subject: [issue27516] Wrong initialization of python path with embeddable distribution In-Reply-To: <1468536614.57.0.563747018021.issue27516@psf.upfronthosting.co.za> Message-ID: <1468541345.49.0.969902532763.issue27516@psf.upfronthosting.co.za> Steve Dower added the comment: Environment variables shouldn't make any different to the embeddable distro - it is designed to ignore them. Have you modified it at all? The path is not as clean as I'd like it to be, but the initialization changes necessary are too significant for 3.5 at this stage (expect something better for 3.6). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 21:03:30 2016 From: report at bugs.python.org (Benjamin Fogle) Date: Fri, 15 Jul 2016 01:03:30 +0000 Subject: [issue27517] LZMACompressor and LZMADecompressor raise exceptions if given empty strings twice Message-ID: <1468544610.85.0.0793383244022.issue27517@psf.upfronthosting.co.za> New submission from Benjamin Fogle: To reproduce: >>> import lzma >>> c = lzma.LZMACompressor() >>> c.compress(b'') b'\xfd7zXZ\x00\x00\x04\xe6\xd6\xb4F' >>> c.compress(b'') b'' >>> c.compress(b'') Traceback (most recent call last): File "", line 1, in _lzma.LZMAError: Insufficient buffer space >>> d = lzma.LZMADecompressor() >>> d.decompress(b'') b'' >>> d.decompress(b'') Traceback (most recent call last): File "", line 1, in _lzma.LZMAError: Insufficient buffer space This can occur anytime during compression/decompression when an empty string is passed twice in a row. The problem is that that liblzma interprets a call to lzma_code() with avail_in == 0 as a buffer full condition. The second time in a row it encounters this, it returns LZMA_BUF_ERROR as per documentation. The attached patch prevents this condition from occurring. ---------- components: Extension Modules files: lzma.patch keywords: patch messages: 270451 nosy: benfogle priority: normal severity: normal status: open title: LZMACompressor and LZMADecompressor raise exceptions if given empty strings twice type: behavior versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43727/lzma.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 21:08:43 2016 From: report at bugs.python.org (Decorater) Date: Fri, 15 Jul 2016 01:08:43 +0000 Subject: [issue27517] LZMACompressor and LZMADecompressor raise exceptions if given empty strings twice In-Reply-To: <1468544610.85.0.0793383244022.issue27517@psf.upfronthosting.co.za> Message-ID: <1468544923.42.0.38649799081.issue27517@psf.upfronthosting.co.za> Decorater added the comment: Why you passing decompress without passing compress before decompressing it again? Also I would expect that it would show the same compress result trice in a row on the 1st test. This must definately be a issue. ---------- nosy: +Decorater _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 21:20:05 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 15 Jul 2016 01:20:05 +0000 Subject: [issue25507] IDLE: user code 'import tkinter; tkinter.font' should fail In-Reply-To: <1446113442.78.0.389498275803.issue25507@psf.upfronthosting.co.za> Message-ID: <1468545605.84.0.970933680068.issue25507@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- Removed message: http://bugs.python.org/msg259039 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 21:24:41 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 15 Jul 2016 01:24:41 +0000 Subject: [issue25507] IDLE: user code 'import tkinter; tkinter.font' should fail In-Reply-To: <1446113442.78.0.389498275803.issue25507@psf.upfronthosting.co.za> Message-ID: <1468545881.76.0.866291501583.issue25507@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The SO question and that brought the problem to my attention was in June 2015. https://stackoverflow.com/questions/30877112/tkinter-code-using-font-module-cant-run-from-command-line. The message I just unlinked had the wrong url. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 21:33:49 2016 From: report at bugs.python.org (Eryk Sun) Date: Fri, 15 Jul 2016 01:33:49 +0000 Subject: [issue27516] Wrong initialization of python path with embeddable distribution In-Reply-To: <1468536614.57.0.563747018021.issue27516@psf.upfronthosting.co.za> Message-ID: <1468546429.83.0.865208132118.issue27516@psf.upfronthosting.co.za> Eryk Sun added the comment: It looks like you haven't copied pyvenv.cfg to your application directory, so Python isn't using the "applocal" configuration. That's why you're seeing the default paths that are relative to the current directory. It's also why PYTHONPATH and PYTHONHOME aren't ignored. As to the extension modules, if you don't want them in the application directory, add them to the DLLs subdirectory. Here's a possible layout: App\ DLLs\ _socket.pyd ... Lib\ vendored_package ... app.exe pyvenv.cfg python35.dll python35.zip vcruntime140.dll I created this app in C:\Temp, and here's its sys.path: ['C:\\Temp\\App\\python35.zip', 'C:\\Temp\\App\\DLLs', 'C:\\Temp\\App\\lib', 'C:\\Temp\\App'] ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 21:58:33 2016 From: report at bugs.python.org (Benjamin Fogle) Date: Fri, 15 Jul 2016 01:58:33 +0000 Subject: [issue27517] LZMACompressor and LZMADecompressor raise exceptions if given empty strings twice In-Reply-To: <1468544610.85.0.0793383244022.issue27517@psf.upfronthosting.co.za> Message-ID: <1468547913.92.0.828016217275.issue27517@psf.upfronthosting.co.za> Benjamin Fogle added the comment: The above code demonstrates two separate issues. One with the decompressor, and one with the compressor. In the compressor example, the first output differs from the rest because it is a file header which is always emitted. That behavior is correct. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 22:08:44 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 15 Jul 2016 02:08:44 +0000 Subject: [issue27515] Dotted name re-import does not rebind after deletion In-Reply-To: <1468529315.51.0.393890498474.issue27515@psf.upfronthosting.co.za> Message-ID: <1468548524.42.0.307919261126.issue27515@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I don't understand the statement that having 'import email.charset' set email.charset is an optional side effect. Without the name setting, the module is inaccessible except through sys.modules, which is not obvious to beginners. To me, making a module directly accessible is the main point of an import. As it is now, the second 'import email.charset' in the example is equivalent to 'pass'. The test example is simplified to show the core behavior. The real life problem arises when the second 'import package.submodule' is in a different module, perhaps the main module, or in the case of an IDE such as IDLE, in user code exec()ed as is it were running in a main module. When a module runs 'import pack.sub' (for now, only the first time), the 'pack' module is 'monkey-patched' by externally injecting 'sub'. After this, without a deletion, the normally buggy "import pack; print(pack.sub)" executed anywhere in the process will work. Since June 2015, there have been 4 StackOverflow questions about IDLE giving implicit false positives by running code that fails when run directly in Python. I believe that this is more questions during this period than for any other IDLE issue. Currently, if a module author tries to be conscientious and clean up any injections it caused, then the process-global effect is to disable normally correct code. The point of this issue, however classified, is to make it possible for a module to access the modules of a different package without causing mysterious action-at-a-distance effects. Sorry I did not initially explain this better here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 22:17:17 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 15 Jul 2016 02:17:17 +0000 Subject: [issue27487] -m switch regression in Python 3.5.2 (under rare circumstances) In-Reply-To: <1468268291.19.0.631980361837.issue27487@psf.upfronthosting.co.za> Message-ID: <1468549037.0.0.402311407787.issue27487@psf.upfronthosting.co.za> Martin Panter added the comment: I can try to add the RuntimeWarning soon. Obviously we want the warning when executing a submodule like ?package.module?. It also seems reasonable to warn when executing a top-level module that has already been imported. I presume we want these to go into the next 3.5 release. What about 2.7? I guess we don?t want a warning when executing ?package.__main__?, even if the parent package is already imported. So I also need to check if sys.modules[...].__path__ exists. Another thing that I wonder about: What if the message ?Error finding spec for . . .? was changed to ?Error getting import information for . . .?? I am only just starting to understand that ?finding spec? may mean this (I think the documentation has improved since I last tried to understand it). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 22:24:00 2016 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 15 Jul 2016 02:24:00 +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: <1468549440.44.0.65729890932.issue27130@psf.upfronthosting.co.za> Xiang Zhang added the comment: ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 22:48:46 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 15 Jul 2016 02:48: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: <1468550926.34.0.132102477177.issue27130@psf.upfronthosting.co.za> Martin Panter added the comment: This is on my list of things to look at, just that I have been away and am a bit backlogged atm. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 22:53:36 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 15 Jul 2016 02:53:36 +0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1468551216.85.0.516904819054.issue1621@psf.upfronthosting.co.za> Martin Panter added the comment: Inspired by Issue 27473, I did a quick and dirty scan for obvious places that expect overflow to wrap, and found the following, which I think should be fixed: Modules/_ctypes/_ctypes.c:1388, in PyCArrayType_new() Objects/listobject.c:492, in list_concat() Objects/tupleobject.c:457, in tupleconcat() Objects/listobject.c:845, in listextend() Also I played with enabling GCC?s -ftrapv option. Attached is a patch with three changes: 1. configure --with-pydebug enables -ftrapv (experimental, not sure everyone would want this) 2. Easy fix for negation overflow in audioop (I am happy to apply this part) 3. Avoid dumb overflows at end of for loop in Element Tree code when handling slices with step=sys.maxsize. Technically the overflow is undefined behaviour, but the change is annoying, because ignoring the overflow at the end of the loop is much simpler than adding special cases. Not sure what I think about this part. ---------- dependencies: +test_time fails: strftime('%Y', y) for negative year nosy: +martin.panter Added file: http://bugs.python.org/file43728/trapv.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 22:57:54 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 15 Jul 2016 02:57:54 +0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1468551474.47.0.513267518551.issue1621@psf.upfronthosting.co.za> Martin Panter added the comment: I added Issue 13312 as a dependency, there is currently a test for a negative year that relies on overflow handling. Here is a patch where I tried to fix overflow detection for huge set objects. ---------- Added file: http://bugs.python.org/file43729/set-overflow.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 23:21:52 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Jul 2016 03:21:52 +0000 Subject: [issue27517] LZMACompressor and LZMADecompressor raise exceptions if given empty strings twice In-Reply-To: <1468544610.85.0.0793383244022.issue27517@psf.upfronthosting.co.za> Message-ID: <1468552912.46.0.794456754735.issue27517@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +nadeem.vawda, serhiy.storchaka stage: -> patch review versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 23:22:26 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Jul 2016 03:22:26 +0000 Subject: [issue27514] SystemError when compiling deeply nested for loops In-Reply-To: <1468499631.41.0.70687115065.issue27514@psf.upfronthosting.co.za> Message-ID: <1468552946.52.0.0145183435304.issue27514@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 14 23:48:13 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Jul 2016 03:48:13 +0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1468554493.62.0.0882846052044.issue1621@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The audioop part LGTM. If this case was found with the help of -ftrapv, I'm for adding this option in a debug build. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 01:02:21 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 15 Jul 2016 05:02:21 +0000 Subject: [issue27514] SystemError when compiling deeply nested for loops In-Reply-To: <1468499631.41.0.70687115065.issue27514@psf.upfronthosting.co.za> Message-ID: <20160715050218.19831.92910.34814C8D@psf.io> Roundup Robot added the comment: New changeset e6e7c8368c70 by Benjamin Peterson in branch '3.5': make too many nested blocks be a SyntaxError instead of a SystemError (closes #27514) https://hg.python.org/cpython/rev/e6e7c8368c70 New changeset 345ec7455b75 by Benjamin Peterson in branch '2.7': make too many nested blocks be a SyntaxError instead of a SystemError (closes #27514) https://hg.python.org/cpython/rev/345ec7455b75 New changeset d1da87d8b29c by Benjamin Peterson in branch 'default': merge 3.5 (#27514) https://hg.python.org/cpython/rev/d1da87d8b29c ---------- nosy: +python-dev resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 01:54:18 2016 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 15 Jul 2016 05:54:18 +0000 Subject: [issue27515] Dotted name re-import does not rebind after deletion In-Reply-To: <1468548524.42.0.307919261126.issue27515@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Are you sure you realize that "import email.charset" doesn't create a local variable named "email.charset"? It creates a local variable named "email" which happens to have an attribute "charset". The problem with "import pack; print(pack.sub)" being unpredictable is explainable though annoying, but I don't think it can be avoided. After all there's no intrinsic reason why module "pack" couldn't have some attribute named "sub" unrelated to a submodule. I'm not sure what you mean by injections or cleaning them up. Perhaps there's some overzealousness here that causes this broken behavior? Is there somewhere in the IDLE code that you'd like me to look at? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 02:43:24 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 15 Jul 2016 06:43:24 +0000 Subject: [issue25507] IDLE: user code 'import tkinter; tkinter.font' should fail In-Reply-To: <1446113442.78.0.389498275803.issue25507@psf.upfronthosting.co.za> Message-ID: <20160715064315.9659.96442.C5BECF78@psf.io> Roundup Robot added the comment: New changeset 93d325c64104 by Terry Jan Reedy in branch 'default': Issue #25507: Move 4 objects from pyshell to run and switch inports. https://hg.python.org/cpython/rev/93d325c64104 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 02:46:21 2016 From: report at bugs.python.org (Decorater) Date: Fri, 15 Jul 2016 06:46:21 +0000 Subject: [issue27515] Dotted name re-import does not rebind after deletion In-Reply-To: <1468529315.51.0.393890498474.issue27515@psf.upfronthosting.co.za> Message-ID: <1468565181.0.0.434873951699.issue27515@psf.upfronthosting.co.za> Decorater added the comment: I think on the 2nd example they did they got it wrong somewhat. I think this is what they wanted. >>> import email.charset; email.charset >>> del email #to actually delete the whole thing. >>> import email.charset; email.charset ---------- nosy: +Decorater _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 02:51:42 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 15 Jul 2016 06:51:42 +0000 Subject: [issue25507] IDLE: user code 'import tkinter; tkinter.font' should fail In-Reply-To: <1446113442.78.0.389498275803.issue25507@psf.upfronthosting.co.za> Message-ID: <1468565502.34.0.598968600128.issue25507@psf.upfronthosting.co.za> Terry J. Reedy added the comment: First step. Patch moves 4 objects from pyshell to run and reverses run importing pyshell to pyshell importing run. This initially failed because run imports stackbrowser and the stackbrowser import of something from pyshell failed. Since the import is only needed for htest, I just moved it into the htest code. Removing 'import pyshell' from run avoids 'import tkinter.messagebox' in pyshell. It also reduces len(sys.modules) in the user process by 37 from 193 to 156. ---------- assignee: -> terry.reedy stage: test needed -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 03:03:00 2016 From: report at bugs.python.org (Antti Haapala) Date: Fri, 15 Jul 2016 07:03:00 +0000 Subject: [issue27078] Make f'' strings faster than .format: BUILD_STRING opcode? In-Reply-To: <1463858316.54.0.292581402272.issue27078@psf.upfronthosting.co.za> Message-ID: <1468566180.82.0.11409853182.issue27078@psf.upfronthosting.co.za> Antti Haapala added the comment: Serhiy suggested this in Rietveld: > For additional optimization we can pack all constant strings, parsed formats and > flags in one constant object and use the single LOAD_CONST. But this requires > much larger changes (perhaps including changing the marshal format), and the > benefit may be small. Maybe we'll get to it eventually, if this approach proves > efficient enough. I was thinking about this and got an idea on how to do this too, without changes to marshal. Essentially, let TOS be a tuple of (flags, str1, str2, str3, str4, str5, str6, str7, str8, str9...) flags would be n bytes for n-part format string; each byte would tell whether: - the next component is a constant string (bit 0 = 0) from the tuple - the next component is an interpolated value (bit 0 = 1) - and whether it has !s, !r, !a or default conversions (bits 1-2) - and whether it has extra argument to format() or not (bit 3) (argument is the next string from the tuple) thus that tuple for a, b = 'Hello', 'World!' f'{a!s} {b:10}!' would be (b'\x03\x00\x05\x00', ' ', '10', '!') and the opcodes would be LOAD_FAST (b) LOAD_FAST (a) LOAD_CONST (0) (the tuple) BUILD_FORMAT_STRING 3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 04:08:41 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 15 Jul 2016 08:08:41 +0000 Subject: [issue27515] Dotted name re-import does not rebind after deletion In-Reply-To: <1468529315.51.0.393890498474.issue27515@psf.upfronthosting.co.za> Message-ID: <1468570121.7.0.9699112331.issue27515@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Decorator: as I tried to say in msg270456, the two examples are artificial tests stripped to the bare minimum. So is use of email and charset, other than the fact that it exists in 2.7 as well as current 3.x. The real situation where this issue came up for me is the subprocess that IDLE uses to execute user code, separate as much as possible from IDLE code. idlelib.run imports tkinter. It them imports a few other idlelib modules that collectively import at least tkinter.font, tkinter.messagebox, and tkinter.simpledialog. These indirect imports change the tkinter module. Consequently, when users submit code such as import tkinter as tk root = tk.Tk() myfont = tk.font.Font(...) # tk.font should raise NameError it runs. But when they try to run their 'correct' program directly with Python, they get the NameError and must add, for instance, 'import tk.font'. IDLE should help people write standard python code, not python with a few custom augmentations. My first attempt to fix this was to have run execute 'del tkinter.font', etcetera after the indirect imports are done. Then users would get the NameError they should. But currently, they would continue getting the NameError even after adding the needed import. This is because the first font import in *their* code is the second or later font import in the process. My second example is a condensed version of this failure. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 04:26:11 2016 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 15 Jul 2016 08:26:11 +0000 Subject: [issue27487] -m switch regression in Python 3.5.2 (under rare circumstances) In-Reply-To: <1468268291.19.0.631980361837.issue27487@psf.upfronthosting.co.za> Message-ID: <1468571171.43.0.324040534799.issue27487@psf.upfronthosting.co.za> Nick Coghlan added the comment: No changes to 2.7 - the import system logic there is fairly different, since it's still using the old pre-importlib implementation. For the "package.__main__" case, you're right that we don't want to emit the warning for "-m package", but we *do* want to emit the warning if package.__init__ imports package.__main__ for some reason. And that's an excellent point about "finding spec" being implementer focused jargon - would "finding module specification" be clearer? I'd still like to have a link between the error message and the fact the function is called "find_spec", and the official expansion of the abbreviation is "module specification" (hence _ModuleSpec). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 04:36:00 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 15 Jul 2016 08:36:00 +0000 Subject: [issue27515] Dotted name re-import does not rebind after deletion In-Reply-To: <1468529315.51.0.393890498474.issue27515@psf.upfronthosting.co.za> Message-ID: <1468571760.6.0.248090267317.issue27515@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Guido: I am aware that 'import tkinter.font' can create 0, 1, or 2 new modules and 0, 1, or 2 new name bindings, one in the *importing* module and one in the *imported* module. You are correct that point 2 in the doc only talks about the importing module, making my paraphrase not correct for dotted names. For the latter, the doc says. "If the module being imported is not a top level module, then the name of the top level package that contains the module is bound in the local namespace as a reference to the top level package. The imported module must be accessed using its full qualified name rather than directly." To me, this implies that the top level and intermediate packages will be modified as needed so that the 'full qualified name' works. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 04:39:03 2016 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 15 Jul 2016 08:39:03 +0000 Subject: [issue27515] Dotted name re-import does not rebind after deletion In-Reply-To: <1468529315.51.0.393890498474.issue27515@psf.upfronthosting.co.za> Message-ID: <1468571943.86.0.44801926567.issue27515@psf.upfronthosting.co.za> Nick Coghlan added the comment: To fully remove an imported submodule, you also need to purge it from the sys.modules cache: >>> import email.charset; email.charset >>> import sys >>> del email.charset; del sys.modules["email.charset"] >>> import email.charset; email.charset The reason we don't provide utilities in importlib to purge modules that way is because not all modules support being forcibly reloaded like this, and unlike imp.reload(), the errors happen at the point of importing it again later, not at the point where you purge it. However, if you can figure out precisely which "tk" submodules IDLE implicitly imports, you can do one of three things for each one: 1. Change IDLE to avoid importing it in the subprocess where user code runs; 2. Test it supports reloading, and do "del tk.; del sys.modules['tk.']" in the IDLE subprocess after you're finished with it; or 3. Change tk.__init__ to implicitly import that submodule (such that code that only imports "tk" will still be able to access it) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 05:57:48 2016 From: report at bugs.python.org (Oren Milman) Date: Fri, 15 Jul 2016 09:57:48 +0000 Subject: [issue15988] Inconsistency in overflow error messages of integer argument In-Reply-To: <1348167070.37.0.305629822418.issue15988@psf.upfronthosting.co.za> Message-ID: <1468576668.15.0.165089814331.issue15988@psf.upfronthosting.co.za> Oren Milman added the comment: I would be happy to write a patch for this issue, if you don't mind. Terry, as you were the one to commit the patch for #21559, I guess you are OK with keeping the OverflowError. Also, I agree that the error message for '_testcapi.getargs_b(-1)' (and for similar cases) could be improved. IMHO, the wording in PyLong_AsLong is quite clear, and also fits here, e.g. 'Python int too small to convert to C unsigned byte' for '_testcapi.getargs_b(-1)'. ISTM that implementing the patch by doing the following is quite straightforward: - replacing PyLong_AsLong with PyLong_AsLongAndOverflow (as Serhiy suggested) in cases 'b', 'h' and 'i', in convertsimple in getargs.c - changing some error messages in convertsimple - changing PyLong_AsLong and _PyLong_AsInt so that they too would give more helpful error messages (according to the long-lived suggestions of '/* XXX: could be cute and give a different message for overflow == -1 */') Serhiy, what did you mean by 'Unify an integer overflow error messages in different functions.'? ---------- nosy: +Oren Milman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 06:39:07 2016 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 15 Jul 2016 10:39:07 +0000 Subject: [issue27518] small typo error in Grammar/Grammar Message-ID: <1468579147.6.0.884332252172.issue27518@psf.upfronthosting.co.za> New submission from St?phane Wirtel: Here is a small patch for the Grammar/Grammar file, there is a typo in the comments. ---------- assignee: docs at python components: Documentation files: Grammar.diff keywords: patch messages: 270475 nosy: docs at python, matrixise priority: normal severity: normal status: open title: small typo error in Grammar/Grammar versions: Python 3.6 Added file: http://bugs.python.org/file43730/Grammar.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 07:12:37 2016 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 15 Jul 2016 11:12:37 +0000 Subject: [issue27519] update the references to http://mercurial.selenic.com Message-ID: <1468581157.12.0.317486616514.issue27519@psf.upfronthosting.co.za> New submission from St?phane Wirtel: In the devguide, there are some references to http://mercurial.selenic.com/wiki/ but the website has been migrated to http://mercurial-scm.org/wiki/ ---------- assignee: docs at python components: Documentation messages: 270476 nosy: docs at python, matrixise priority: normal severity: normal status: open title: update the references to http://mercurial.selenic.com versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 07:24:34 2016 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 15 Jul 2016 11:24:34 +0000 Subject: [issue27519] update the references to http://mercurial.selenic.com In-Reply-To: <1468581157.12.0.317486616514.issue27519@psf.upfronthosting.co.za> Message-ID: <1468581874.86.0.855567202005.issue27519@psf.upfronthosting.co.za> St?phane Wirtel added the comment: I just updated to the new url of the Mercurial Wiki for the devguide. ---------- components: +Devguide -Documentation keywords: +patch nosy: +ezio.melotti, willingc versions: +Python 3.5 Added file: http://bugs.python.org/file43731/issue27519.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 07:31:55 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Jul 2016 11:31:55 +0000 Subject: [issue15988] Inconsistency in overflow error messages of integer argument In-Reply-To: <1348167070.37.0.305629822418.issue15988@psf.upfronthosting.co.za> Message-ID: <1468582315.87.0.880682819673.issue15988@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: You plan looks good, Oren. I meant what you are planning in the last two items. There are also specific functions for converting to platform-depending integer types (size_t, time_t, uid_t, etc). Two most common patterns: "Python int too large to convert to C long" and "signed short integer is less/greater than maximum". Grep all code for raising OverflowError. ---------- versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 08:00:56 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 15 Jul 2016 12:00:56 +0000 Subject: [issue15988] Inconsistency in overflow error messages of integer argument In-Reply-To: <1348167070.37.0.305629822418.issue15988@psf.upfronthosting.co.za> Message-ID: <1468584056.81.0.773735257454.issue15988@psf.upfronthosting.co.za> Terry J. Reedy added the comment: At this point in time, I have nothing further to add. So follow Serhiy's advice. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 08:08:22 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 15 Jul 2016 12:08:22 +0000 Subject: [issue27515] Dotted name re-import does not rebind after deletion In-Reply-To: <1468529315.51.0.393890498474.issue27515@psf.upfronthosting.co.za> Message-ID: <1468584502.73.0.911252006667.issue27515@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I am pursuing 1. for 3.6. The first patch, moving 4 objects from pyshell to run and an import from run to pyshell, reduced a bloated len(sys.modules) from 193 to 156. I hope to get under 100. I will test 2., separately for each affected tkinter module, for 2.7 and 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 09:12:40 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 15 Jul 2016 13:12:40 +0000 Subject: [issue27518] small typo error in Grammar/Grammar In-Reply-To: <1468579147.6.0.884332252172.issue27518@psf.upfronthosting.co.za> Message-ID: <20160715131235.62863.2529.9A34A0E3@psf.io> Roundup Robot added the comment: New changeset db5a5679a9de by Berker Peksag in branch '3.5': Issue #27518: Fix typo in Grammar/Grammar https://hg.python.org/cpython/rev/db5a5679a9de New changeset bae0d7389e96 by Berker Peksag in branch 'default': Issue #27518: Merge from 3.5 https://hg.python.org/cpython/rev/bae0d7389e96 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 09:13:42 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 15 Jul 2016 13:13:42 +0000 Subject: [issue27518] small typo error in Grammar/Grammar In-Reply-To: <1468579147.6.0.884332252172.issue27518@psf.upfronthosting.co.za> Message-ID: <1468588422.83.0.302447586391.issue27518@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks, St?phane. ---------- 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 Jul 15 09:18:37 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 15 Jul 2016 13:18:37 +0000 Subject: [issue27519] update the references to http://mercurial.selenic.com In-Reply-To: <1468581157.12.0.317486616514.issue27519@psf.upfronthosting.co.za> Message-ID: <20160715131824.19036.75873.37AD2E8E@psf.io> Roundup Robot added the comment: New changeset 2edae149e8c5 by Berker Peksag in branch 'default': Issue #27519: Update Mercurial links to mercurial-scm.org https://hg.python.org/devguide/rev/2edae149e8c5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 09:19:20 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 15 Jul 2016 13:19:20 +0000 Subject: [issue27519] update the references to http://mercurial.selenic.com In-Reply-To: <1468581157.12.0.317486616514.issue27519@psf.upfronthosting.co.za> Message-ID: <1468588760.4.0.773142132831.issue27519@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks! ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 09:20:32 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 15 Jul 2016 13:20:32 +0000 Subject: [issue27519] update the references to http://mercurial.selenic.com In-Reply-To: <1468581157.12.0.317486616514.issue27519@psf.upfronthosting.co.za> Message-ID: <1468588832.66.0.762045610106.issue27519@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- versions: -Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 11:20:12 2016 From: report at bugs.python.org (Decorater) Date: Fri, 15 Jul 2016 15:20:12 +0000 Subject: [issue27519] update the references to http://mercurial.selenic.com In-Reply-To: <1468581157.12.0.317486616514.issue27519@psf.upfronthosting.co.za> Message-ID: <1468596012.11.0.0808830933134.issue27519@psf.upfronthosting.co.za> Decorater added the comment: Why not add url to the GUI version too that actually adds hg to the path? ---------- nosy: +Decorater _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 11:25:10 2016 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 15 Jul 2016 15:25:10 +0000 Subject: [issue27519] update the references to http://mercurial.selenic.com In-Reply-To: <1468581157.12.0.317486616514.issue27519@psf.upfronthosting.co.za> Message-ID: <1468596310.06.0.196055557703.issue27519@psf.upfronthosting.co.za> St?phane Wirtel added the comment: which GUI version ? it's in the documentation. please could you be more explicit ? thanks ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 11:27:02 2016 From: report at bugs.python.org (Decorater) Date: Fri, 15 Jul 2016 15:27:02 +0000 Subject: [issue27520] Issue when building PGO Message-ID: <1468596421.99.0.279689022473.issue27520@psf.upfronthosting.co.za> New submission from Decorater: I get this issue when trying a PGO build it seems that some projects do not create a pgd. (the link to simplify the size on here) https://bpaste.net/show/c704ee912c53 ---------- components: Build, Tests, Windows messages: 270487 nosy: Decorater, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Issue when building PGO versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 11:28:17 2016 From: report at bugs.python.org (Decorater) Date: Fri, 15 Jul 2016 15:28:17 +0000 Subject: [issue27519] update the references to http://mercurial.selenic.com In-Reply-To: <1468581157.12.0.317486616514.issue27519@psf.upfronthosting.co.za> Message-ID: <1468596497.4.0.628983209078.issue27519@psf.upfronthosting.co.za> Decorater added the comment: TortoiseHg ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 11:36:51 2016 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 15 Jul 2016 15:36:51 +0000 Subject: [issue27519] update the references to http://mercurial.selenic.com In-Reply-To: <1468581157.12.0.317486616514.issue27519@psf.upfronthosting.co.za> Message-ID: <1468597011.33.0.414884443622.issue27519@psf.upfronthosting.co.za> St?phane Wirtel added the comment: because we don't want to change a tool but just an URL. you can create an other issue if you prefer to use TortoiseHg. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 13:26:50 2016 From: report at bugs.python.org (Dor Dankner) Date: Fri, 15 Jul 2016 17:26:50 +0000 Subject: [issue27521] Misleading compress level header on files created with gzip Message-ID: <1468603610.22.0.92461778532.issue27521@psf.upfronthosting.co.za> New submission from Dor Dankner: When creating a gzip file using the gzip module, the wrong header is set as the compress level when not using the default (9). the reason is that the header is set blindly as \002, without really checking what compress level is. Patch to fix that behaviour is provided :) (Patch tested on python 3.5, but relevant to 2.x versions too) ---------- components: Extension Modules files: gzip_compressionlvl_header_fix.patch keywords: patch messages: 270490 nosy: ddorda priority: normal severity: normal status: open title: Misleading compress level header on files created with gzip 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/file43732/gzip_compressionlvl_header_fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 13:41:57 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 15 Jul 2016 17:41:57 +0000 Subject: [issue27512] os.fspath is certain to crash when exception raised in __fspath__ In-Reply-To: <1468488493.55.0.648642707869.issue27512@psf.upfronthosting.co.za> Message-ID: <20160715174154.93915.93727.FE432949@psf.io> Roundup Robot added the comment: New changeset 35bf83ff0828 by Brett Cannon in branch 'default': Issue #27512: Don't segfault when os.fspath() calls an object whose https://hg.python.org/cpython/rev/35bf83ff0828 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 13:51:07 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 15 Jul 2016 17:51:07 +0000 Subject: [issue27512] os.fspath is certain to crash when exception raised in __fspath__ In-Reply-To: <1468488493.55.0.648642707869.issue27512@psf.upfronthosting.co.za> Message-ID: <1468605067.06.0.169559383119.issue27512@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks for the patch, Xiang! Only thing I changed were braces around the `if` body in the C code and made the mock __fspath__() class raise an exception itself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 13:51:17 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 15 Jul 2016 17:51:17 +0000 Subject: [issue27512] os.fspath is certain to crash when exception raised in __fspath__ In-Reply-To: <1468488493.55.0.648642707869.issue27512@psf.upfronthosting.co.za> Message-ID: <1468605077.32.0.492239982851.issue27512@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 13:59:18 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 15 Jul 2016 17:59:18 +0000 Subject: [issue26844] Wrong error message during import In-Reply-To: <1461564546.15.0.190869698481.issue26844@psf.upfronthosting.co.za> Message-ID: <20160715175915.62799.83944.A8CD3F0E@psf.io> Roundup Robot added the comment: New changeset 22eaf6158e7b by Brett Cannon in branch '3.5': Issue #26844: Fix imp.find_module() to have the exception related to https://hg.python.org/cpython/rev/22eaf6158e7b New changeset 46da639f7114 by Brett Cannon in branch 'default': Merge for #26844 https://hg.python.org/cpython/rev/46da639f7114 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 13:59:36 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 15 Jul 2016 17:59:36 +0000 Subject: [issue26844] Wrong error message during import In-Reply-To: <1461564546.15.0.190869698481.issue26844@psf.upfronthosting.co.za> Message-ID: <1468605576.55.0.255586223137.issue26844@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks for the patch, Lev! ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 14:08:58 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 15 Jul 2016 18:08:58 +0000 Subject: [issue27512] os.fspath is certain to crash when exception raised in __fspath__ In-Reply-To: <1468488493.55.0.648642707869.issue27512@psf.upfronthosting.co.za> Message-ID: <1468606138.18.0.9120585435.issue27512@psf.upfronthosting.co.za> R. David Murray added the comment: Looks like the buildbots aren't happy: http://buildbot.python.org/all/builders/s390x%20SLES%203.x/builds/1396/steps/test/logs/stdio http://buildbot.python.org/all/builders/s390x%20Debian%203.x/builds/1374 ---------- nosy: +r.david.murray status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 14:11:47 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 15 Jul 2016 18:11:47 +0000 Subject: [issue27521] Misleading compress level header on files created with gzip In-Reply-To: <1468603610.22.0.92461778532.issue27521@psf.upfronthosting.co.za> Message-ID: <1468606307.35.0.591200519033.issue27521@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for the report and patch. Now we need a test. ---------- nosy: +r.david.murray stage: -> test needed versions: -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 14:27:00 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 15 Jul 2016 18:27:00 +0000 Subject: [issue27512] os.fspath is certain to crash when exception raised in __fspath__ In-Reply-To: <1468488493.55.0.648642707869.issue27512@psf.upfronthosting.co.za> Message-ID: <20160715182657.3685.1649.490020E2@psf.io> Roundup Robot added the comment: New changeset bb7686a555cc by Brett Cannon in branch 'default': Fix a failing test introduced as part of issue #27512 https://hg.python.org/cpython/rev/bb7686a555cc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 14:27:45 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 15 Jul 2016 18:27:45 +0000 Subject: [issue27512] os.fspath is certain to crash when exception raised in __fspath__ In-Reply-To: <1468488493.55.0.648642707869.issue27512@psf.upfronthosting.co.za> Message-ID: <1468607265.29.0.791637944024.issue27512@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks for catching that, David. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 14:55:30 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 15 Jul 2016 18:55:30 +0000 Subject: [issue27083] PYTHONCASEOK is ignored on Windows In-Reply-To: <1463899532.05.0.0164205622545.issue27083@psf.upfronthosting.co.za> Message-ID: <20160715185527.16503.33909.4BAA7CD7@psf.io> Roundup Robot added the comment: New changeset bedcb9ec3f26 by Brett Cannon in branch '3.5': Issue #27083: Respect the PYTHONCASEOK environment variable under https://hg.python.org/cpython/rev/bedcb9ec3f26 New changeset 777da58794ca by Brett Cannon in branch 'default': Merge for #27083 https://hg.python.org/cpython/rev/777da58794ca ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 14:56:03 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 15 Jul 2016 18:56:03 +0000 Subject: [issue27083] PYTHONCASEOK is ignored on Windows In-Reply-To: <1463899532.05.0.0164205622545.issue27083@psf.upfronthosting.co.za> Message-ID: <1468608963.45.0.143570726514.issue27083@psf.upfronthosting.co.za> Brett Cannon added the comment: I fixed this by simply checking for both b'PYTHONCASEOK' and 'PYTHONCASEOK'. Thanks for the bug report, Eryk! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 15:16:50 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 15 Jul 2016 19:16:50 +0000 Subject: [issue26696] Document collections.abc.ByteString In-Reply-To: <1459881544.79.0.834895685887.issue26696@psf.upfronthosting.co.za> Message-ID: <20160715191647.7520.55554.1EBE149D@psf.io> Roundup Robot added the comment: New changeset 8be87fde577f by Brett Cannon in branch '3.5': Issue #26696: Document collections.abc.ByteString. https://hg.python.org/cpython/rev/8be87fde577f New changeset 6ba86ca875a8 by Brett Cannon in branch 'default': Merge for #26696 https://hg.python.org/cpython/rev/6ba86ca875a8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 15:17:11 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 15 Jul 2016 19:17:11 +0000 Subject: [issue26696] Document collections.abc.ByteString In-Reply-To: <1459881544.79.0.834895685887.issue26696@psf.upfronthosting.co.za> Message-ID: <1468610231.97.0.503262675767.issue26696@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks for the patch, Xiang! ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 15:17:55 2016 From: report at bugs.python.org (Costas) Date: Fri, 15 Jul 2016 19:17:55 +0000 Subject: [issue27522] Reference cycle in email.feedparser Message-ID: <1468610275.0.0.18157946386.issue27522@psf.upfronthosting.co.za> New submission from Costas: Background: We have two (clusters of) servers running a high-throughput websocket application. One runs under Python 2.7, the other has been migrated to 3.4. Very similar code runs on both servers, and both manually call the gc periodically to reduce latency. Problem: We noticed that under load the 3.4 server seems to slowly "leak" memory between gc collections, while the 2.7 server doesn't have this issue. Investigation: I tracked down the source of all the garbage to email.feedparser, which is used by http.server to parse the headers of incoming requests. The initialiser of the FeedParser class creates a reference cycle by putting a lambda function into a member variable. The lambda contains a closure with its surrounding scope that points to the object, and the object points back to the lambda. Proposed fix: The lambda can be harmlessly replaced by a boolean value, which doesn't cause the problem, and it's much more readable too. I'm attaching a little patch. ---------- components: email files: emailfeedparsergc.patch keywords: patch messages: 270503 nosy: Costas, barry, r.david.murray priority: normal severity: normal status: open title: Reference cycle in email.feedparser type: resource usage versions: Python 3.5 Added file: http://bugs.python.org/file43733/emailfeedparsergc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 15:30:35 2016 From: report at bugs.python.org (Dor Dankner) Date: Fri, 15 Jul 2016 19:30:35 +0000 Subject: [issue27521] Misleading compress level header on files created with gzip In-Reply-To: <1468603610.22.0.92461778532.issue27521@psf.upfronthosting.co.za> Message-ID: <1468611035.58.0.327063967617.issue27521@psf.upfronthosting.co.za> Dor Dankner added the comment: Thank you for the fast reponse! tests patch for the proposal fix is attached :) ---------- Added file: http://bugs.python.org/file43734/compress_level_tests.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 15:41:07 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Jul 2016 19:41:07 +0000 Subject: [issue27078] Make f'' strings faster than .format: BUILD_STRING opcode? In-Reply-To: <1463858316.54.0.292581402272.issue27078@psf.upfronthosting.co.za> Message-ID: <1468611667.71.0.784034557797.issue27078@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Nice idea, Antti. But I tried to implement it, and surprisingly found that this approach is slower than FORMAT_VALUE + BUILD_STRING. At least for this particular example. Perhaps because we can't use a stack and need to allocate a new tuple containing literal strings and formatted values for PyUnicode_Join(). Not mentioning that the code is much more complex. Here is updated previous patch with fixed leak. ---------- Added file: http://bugs.python.org/file43735/fstring_build_string_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 15:47:24 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Jul 2016 19:47:24 +0000 Subject: [issue27083] PYTHONCASEOK is ignored on Windows In-Reply-To: <1463899532.05.0.0164205622545.issue27083@psf.upfronthosting.co.za> Message-ID: <1468612044.71.0.455446294324.issue27083@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Comparing bytes with str can emit a warning or raise an exception. Checking for b'PYTHONCASEOK' in os.environ looks as a bug to me. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 15:49:47 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 15 Jul 2016 19:49:47 +0000 Subject: [issue27083] PYTHONCASEOK is ignored on Windows In-Reply-To: <1463899532.05.0.0164205622545.issue27083@psf.upfronthosting.co.za> Message-ID: <1468612187.03.0.325989745471.issue27083@psf.upfronthosting.co.za> Brett Cannon added the comment: There's no direct comparison to trigger a warning; it's just seeing if a key in a dict exists. And b'PYTHONCASEOK' is not a bug as that's required for OS X (remember this is technically posix.environ, not os.environ). ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 15:55:54 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Jul 2016 19:55:54 +0000 Subject: [issue27083] PYTHONCASEOK is ignored on Windows In-Reply-To: <1463899532.05.0.0164205622545.issue27083@psf.upfronthosting.co.za> Message-ID: <1468612554.62.0.745520470487.issue27083@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Seeing if a key in a dict exists involves the key comparison if there is a key on the same position in the hash table. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 16:35:14 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 15 Jul 2016 20:35:14 +0000 Subject: [issue27083] PYTHONCASEOK is ignored on Windows In-Reply-To: <1463899532.05.0.0164205622545.issue27083@psf.upfronthosting.co.za> Message-ID: <1468614914.59.0.598142011145.issue27083@psf.upfronthosting.co.za> Brett Cannon added the comment: I think the best we can do is be platform-specific in what is checked for in the environ dict (e.g. b'PYTHONCASEOK' on darwin, 'PYTHONCASEOK' on win, and I don't know about cygwin), but otherwise one would have to iterate through the keys of the dict and do a type check before doing the comparison to fully avoid any potential warning being triggered. Does the platform-specific decision of what to look for work for you, Serhiy? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 16:48:13 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 15 Jul 2016 20:48:13 +0000 Subject: [issue27515] Dotted name re-import does not rebind after deletion In-Reply-To: <1468529315.51.0.393890498474.issue27515@psf.upfronthosting.co.za> Message-ID: <1468615693.49.0.0688516790951.issue27515@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Nick, do I understand correctly that if the reimport executes and I can access the module, everything should be okay? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 17:03:35 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 15 Jul 2016 21:03:35 +0000 Subject: [issue25507] IDLE: user code 'import tkinter; tkinter.font' should fail In-Reply-To: <1446113442.78.0.389498275803.issue25507@psf.upfronthosting.co.za> Message-ID: <1468616615.82.0.604798588174.issue25507@psf.upfronthosting.co.za> Terry J. Reedy added the comment: In #27515, Nick Coughlin said that 'del a.b', would work if sys.modules('a.b') is also deleted -- unless a.b objects to being reloaded. This seems not a problem for the current 8 tkinter submodules. The attached tkimports.py runs without error. I am not going to patch 2.7, which does not have the bug, just for the import reduction. The last patch could be applied to 3.5 since it does not remove anything from PyShell. Putting the three warning functions in a class and making the warning global a class attribute (a future issue) would be a different matter. ---------- versions: -Python 2.7 Added file: http://bugs.python.org/file43736/tkimports.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 17:05:45 2016 From: report at bugs.python.org (Decorater) Date: Fri, 15 Jul 2016 21:05:45 +0000 Subject: [issue27523] Silence Socket Depreciation Warnings. Message-ID: <1468616745.33.0.508663213615.issue27523@psf.upfronthosting.co.za> New submission from Decorater: I have made a patch to some of the warnings to silence them hopefully this will help a lot. ---------- files: socketmodule.c.patch keywords: patch messages: 270512 nosy: Decorater priority: normal severity: normal status: open title: Silence Socket Depreciation Warnings. versions: Python 3.6 Added file: http://bugs.python.org/file43737/socketmodule.c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 17:06:32 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 15 Jul 2016 21:06:32 +0000 Subject: [issue27524] Update os.path for PEP 519/__fspath__() Message-ID: <1468616792.91.0.199248434704.issue27524@psf.upfronthosting.co.za> New submission from Brett Cannon: As per PEP 519, os.path needs to be updated to support __fspath__(). ---------- assignee: brett.cannon components: Library (Lib) messages: 270513 nosy: brett.cannon priority: release blocker severity: normal stage: test needed status: open title: Update os.path for PEP 519/__fspath__() type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 17:06:50 2016 From: report at bugs.python.org (Decorater) Date: Fri, 15 Jul 2016 21:06:50 +0000 Subject: [issue27523] Silence Socket Depreciation Warnings. In-Reply-To: <1468616745.33.0.508663213615.issue27523@psf.upfronthosting.co.za> Message-ID: <1468616810.52.0.457332535316.issue27523@psf.upfronthosting.co.za> Decorater added the comment: Oh and ignore the exe on the patch if you see that 1 has changed. ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 17:06:56 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 15 Jul 2016 21:06:56 +0000 Subject: [issue27524] Update os.path for PEP 519/__fspath__() In-Reply-To: <1468616792.91.0.199248434704.issue27524@psf.upfronthosting.co.za> Message-ID: <1468616816.65.0.850141794359.issue27524@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- dependencies: +Support Path objects in the posix module, Support path objects in the ntpath module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 17:14:53 2016 From: report at bugs.python.org (Dor Dankner) Date: Fri, 15 Jul 2016 21:14:53 +0000 Subject: [issue27525] Wrong OS header on file created by gzip module Message-ID: <1468617293.43.0.813584223225.issue27525@psf.upfronthosting.co.za> New submission from Dor Dankner: The gzip module generates files with wrong OS header, by putting "Unknown" OS, instead of checking and filling the user's OS. >From the gzip RFC (rfc1952): "This identifies the type of file system on which compression took place. This may be useful in determining end-of-line convention for text files." The following patch contains a fix that fills the current OS flag (and testcase ;) ) * The bug is relevant to python 2.x too, but I did not test the patch on it. ** also, I did not run the testcase on Win/Mac, however it should work. ---------- components: Extension Modules files: gzip_os_header_fix_and_tests.patch keywords: patch messages: 270515 nosy: ddorda priority: normal severity: normal status: open title: Wrong OS header on file created by gzip module type: behavior versions: Python 2.7, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43738/gzip_os_header_fix_and_tests.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 17:20:23 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 15 Jul 2016 21:20:23 +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: <1468617623.08.0.114677760413.issue26800@psf.upfronthosting.co.za> Brett Cannon added the comment: Serhiy's patch LGTM. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 17:57:49 2016 From: report at bugs.python.org (Eric Snow) Date: Fri, 15 Jul 2016 21:57:49 +0000 Subject: [issue24254] Make class definition namespace ordered by default In-Reply-To: <1432186488.39.0.20621749373.issue24254@psf.upfronthosting.co.za> Message-ID: <1468619869.51.0.997641345479.issue24254@psf.upfronthosting.co.za> Eric Snow added the comment: post-review updates ---------- Added file: http://bugs.python.org/file43739/deforder-with-tp-slot.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 18:00:51 2016 From: report at bugs.python.org (Ethan Furman) Date: Fri, 15 Jul 2016 22:00:51 +0000 Subject: [issue27524] Update os.path for PEP 519/__fspath__() In-Reply-To: <1468616792.91.0.199248434704.issue27524@psf.upfronthosting.co.za> Message-ID: <1468620051.86.0.66278408673.issue27524@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 18:38:42 2016 From: report at bugs.python.org (Decorater) Date: Fri, 15 Jul 2016 22:38:42 +0000 Subject: [issue27523] Silence Socket Depreciation Warnings. In-Reply-To: <1468616745.33.0.508663213615.issue27523@psf.upfronthosting.co.za> Message-ID: <1468622322.75.0.49824432179.issue27523@psf.upfronthosting.co.za> Decorater added the comment: I just noticed it does not work the way I had hoped. Ignore this. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 18:53:13 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 15 Jul 2016 22:53:13 +0000 Subject: [issue27524] Update os.path for PEP 519/__fspath__() In-Reply-To: <1468616792.91.0.199248434704.issue27524@psf.upfronthosting.co.za> Message-ID: <1468623193.2.0.617731797342.issue27524@psf.upfronthosting.co.za> Brett Cannon added the comment: Here are tests for genericpath, posixpath, and ntpath (which should in the end cover all of os.path). ---------- keywords: +patch stage: test needed -> needs patch Added file: http://bugs.python.org/file43740/fspath_tests.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 19:12:52 2016 From: report at bugs.python.org (Ned Deily) Date: Fri, 15 Jul 2016 23:12:52 +0000 Subject: [issue27525] Wrong OS header on file created by gzip module In-Reply-To: <1468617293.43.0.813584223225.issue27525@psf.upfronthosting.co.za> Message-ID: <1468624372.95.0.781179375159.issue27525@psf.upfronthosting.co.za> Ned Deily added the comment: It appears that not including the OS value in the header is probably more of a feature rather than a bug considering how long the gzip module has been around with this behavior. Have you found any real-life cases where it makes a difference? In any case, the os.platform value 'mac' referred to ancient Mac OS Classic (Mac OS 9 and earlier), platforms current Pythons do not support. Current Mac OS X systems are platform 'darwin' and would use the same gzip value as platform 'posix'. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 19:22:09 2016 From: report at bugs.python.org (Demur Rumed) Date: Fri, 15 Jul 2016 23:22:09 +0000 Subject: [issue27213] Rework CALL_FUNCTION* opcodes In-Reply-To: <1465026334.02.0.369802561902.issue27213@psf.upfronthosting.co.za> Message-ID: <1468624929.29.0.745575695993.issue27213@psf.upfronthosting.co.za> Demur Rumed added the comment: Since the most common use of CALL_FUNCTION_EX is.. def f(*x,*kw): other_func(*x, **kw) I've added some code to BUILD_MAP_UNPACK_WITH_CALL & BUILD_TUPLE_UNPACK to not allocate a new object if called with oparg of 1 & TOP() is correct type ---------- Added file: http://bugs.python.org/file43741/callfunc5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 20:10:30 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 16 Jul 2016 00:10:30 +0000 Subject: [issue25507] IDLE: user code 'import tkinter; tkinter.font' should fail In-Reply-To: <1446113442.78.0.389498275803.issue25507@psf.upfronthosting.co.za> Message-ID: <1468627830.97.0.0338461020376.issue25507@psf.upfronthosting.co.za> Terry J. Reedy added the comment: run_autocomplete.diff is a preliminary patch for moving the completion list function into run.py and reversing the imports. However, the assert in test_autocomplete, line 103 newly fails because the call to open_completions in autocomplete_event (line 85) returns None. The None comes from l. 155. comp_lists = self.fetch_completions(comp_what, mode) if not comp_lists[0]: return None I do not yet know why moving the one function causes the completion lists for re to be blank. I am going to shelve this approach and return to deletion. ---------- keywords: +patch Added file: http://bugs.python.org/file43742/run_autocomplete.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 20:25:42 2016 From: report at bugs.python.org (Ethan Furman) Date: Sat, 16 Jul 2016 00:25:42 +0000 Subject: [issue26988] Add AutoNumberedEnum to stdlib In-Reply-To: <1462844071.91.0.106881823757.issue26988@psf.upfronthosting.co.za> Message-ID: <1468628742.16.0.13110560393.issue26988@psf.upfronthosting.co.za> Ethan Furman added the comment: Okay, here's an updated patch with the doc changes. Once the main patch is committed I'm going to reorganize the docs a bit, but that's later. ---------- assignee: -> ethan.furman Added file: http://bugs.python.org/file43743/issue26988.stoneleaf.02.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 20:28:10 2016 From: report at bugs.python.org (Ethan Furman) Date: Sat, 16 Jul 2016 00:28:10 +0000 Subject: [issue26988] Add AutoNumberedEnum to stdlib In-Reply-To: <1462844071.91.0.106881823757.issue26988@psf.upfronthosting.co.za> Message-ID: <1468628890.54.0.985411868593.issue26988@psf.upfronthosting.co.za> Ethan Furman added the comment: Oh, and yes, I'll fix the whole 80-column thing. ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 21:01:21 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 16 Jul 2016 01:01:21 +0000 Subject: [issue25729] update pure python datetime.timedelta creation In-Reply-To: <1448437946.34.0.869547453804.issue25729@psf.upfronthosting.co.za> Message-ID: <1468630881.44.0.185953814545.issue25729@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Brian, we had a similar discussion in issue 20858, but I am still unsure about the relationship between our datetime.py and that in PyPy. Do you use CPython version in PyPy? If not, have you applied this patch and if so, can you link to a PyPy issue or a commit? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 21:17:28 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 16 Jul 2016 01:17:28 +0000 Subject: [issue25729] update pure python datetime.timedelta creation In-Reply-To: <1448437946.34.0.869547453804.issue25729@psf.upfronthosting.co.za> Message-ID: <1468631848.51.0.239735487799.issue25729@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: For future reference, here is a link to PyPy history of datetime.py: https://bitbucket.org/pypy/pypy/history-node/919e00b3e558/lib_pypy/datetime.py?at=default ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 21:27:06 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 16 Jul 2016 01:27:06 +0000 Subject: [issue10225] Fix doctest runable examples in python manual In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za> Message-ID: <1468632426.54.0.215945111047.issue10225@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- assignee: belopolsky -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 21:30:21 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 16 Jul 2016 01:30:21 +0000 Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1468632621.46.0.764328514085.issue15873@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: -Alexander.Belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 21:30:38 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 Jul 2016 01:30:38 +0000 Subject: [issue27522] Reference cycle in email.feedparser In-Reply-To: <1468610275.0.0.18157946386.issue27522@psf.upfronthosting.co.za> Message-ID: <20160716013032.111306.76220.CC826340@psf.io> Roundup Robot added the comment: New changeset 6c7fd035bce3 by R David Murray in branch '3.5': #27522: break unintended cycle in feedparser. https://hg.python.org/cpython/rev/6c7fd035bce3 New changeset e1278508f3cb by R David Murray in branch 'default': Merge: #27522: break unintended cycle in feedparser. https://hg.python.org/cpython/rev/e1278508f3cb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 21:31:42 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 16 Jul 2016 01:31:42 +0000 Subject: [issue27522] Reference cycle in email.feedparser In-Reply-To: <1468610275.0.0.18157946386.issue27522@psf.upfronthosting.co.za> Message-ID: <1468632702.58.0.749105354133.issue27522@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Costas. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 21:31:58 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 16 Jul 2016 01:31:58 +0000 Subject: [issue27522] Reference cycle in email.feedparser In-Reply-To: <1468610275.0.0.18157946386.issue27522@psf.upfronthosting.co.za> Message-ID: <1468632718.63.0.826667356789.issue27522@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 21:41:33 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 16 Jul 2016 01:41:33 +0000 Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1468633293.37.0.278743850594.issue15873@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I would very much like to see this ready before the feature cut-off for Python 3.6. Could someone post a summary on python-ideas to get a show of hands on some of the remaining wrinkles? I would not worry about a C implementation at this point. We can put python implementation in _strptime.py and call it from C as we do for the strptime method. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 21:56:41 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 16 Jul 2016 01:56:41 +0000 Subject: [issue24954] No way to generate or parse timezone as produced by datetime.isoformat() In-Reply-To: <1440801281.72.0.545558404714.issue24954@psf.upfronthosting.co.za> Message-ID: <1468634201.57.0.784373020659.issue24954@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Since this is closely related to issue 15873, I am merging the nosy lists. As far as I can tell, the patch just needs tests and a final decision on issue 5288. I don't think it is at all controversial, but we need to relax the offset restrictions before ::z code can go in. shanmbic, you can use my PEP 495 branch to test. See . ---------- nosy: +Anders.Hovm?ller, Arfrever, Eric.Hanchrow, Roman.Evstifeev, SilentGhost, aymeric.augustin, barry, berker.peksag, cvrebert, davydov, deronnax, eric.araujo, flying sheep, haypo, jcea, jstasiak, jwilk, karlcow, kirpit, mcepl, mihaic, nagle, pbryan, perey, piotr.dobrogost, r.david.murray, roysmith stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 21:59:24 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 16 Jul 2016 01:59:24 +0000 Subject: [issue24954] No way to generate or parse timezone as produced by datetime.isoformat() In-Reply-To: <1440801281.72.0.545558404714.issue24954@psf.upfronthosting.co.za> Message-ID: <1468634364.17.0.392928470188.issue24954@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Sorry, the tracker messed up the URL: go to https://github.com/abalkin/cpython.git and select branch:issue24773-s3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 22:06:49 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 16 Jul 2016 02:06:49 +0000 Subject: [issue12750] datetime.strftime('%s') should respect tzinfo In-Reply-To: <1313375473.21.0.352014190788.issue12750@psf.upfronthosting.co.za> Message-ID: <1468634809.49.0.42846428801.issue12750@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +shanmbic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 22:08:19 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 16 Jul 2016 02:08:19 +0000 Subject: [issue12750] datetime.strftime('%s') should respect tzinfo In-Reply-To: <1313375473.21.0.352014190788.issue12750@psf.upfronthosting.co.za> Message-ID: <1468634899.8.0.434724642348.issue12750@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 22:09:05 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 16 Jul 2016 02:09:05 +0000 Subject: [issue27526] test_venv.TestEnsurePip fails mysteriously when /tmp is too small Message-ID: <1468634945.4.0.415897452337.issue27526@psf.upfronthosting.co.za> New submission from R. David Murray: I've been having a failure in test_venv when running the tests suite for some months now. Since the buildbots aren't, I was guessing it was a local problem. I finally got around to looking at it today, and I had no clue what was wrong here, after setting maxDiff to None: ====================================================================== FAIL: test_with_pip (test.test_venv.EnsurePipTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/rdmurray/python/p35/Lib/test/test_venv.py", line 381, in test_with_pip self.assertEqual(err, "") AssertionError: 'Traceback (most recent call last):\n Fil[741 chars]\'\n' != '' - Traceback (most recent call last): - File "/home/rdmurray/python/p35/Lib/runpy.py", line 174, in _run_module_as_main - mod_name, mod_spec, code = _get_module_details(mod_name, _Error) - File "/home/rdmurray/python/p35/Lib/runpy.py", line 133, in _get_module_details - return _get_module_details(pkg_main_name, error) - File "/home/rdmurray/python/p35/Lib/runpy.py", line 109, in _get_module_details - __import__(pkg_name) - File "/tmp/tmpcpx0dj2o/lib/python3.5/site-packages/pip/__init__.py", line 14, in - from pip.utils import get_installed_distributions, get_prog - File "/tmp/tmpcpx0dj2o/lib/python3.5/site-packages/pip/utils/__init__.py", line 27, in - from pip._vendor import pkg_resources - ImportError: cannot import name 'pkg_resources' It turns out that the problem was that the virtual machine I was running this in had a /tmp that was too small for pip to operate. I've had this problem often with pip on my VMs. I'm reporting this because it seems to me reasonably likely that ensurepip will fail mysteriously if /tmp is too small. I'm OK with this issue getting closed as won't fix, since my setup is rather odd and it may be that no one else will run in to this. But it may be that someone else will, and at least there will be a bug report to find. ---------- messages: 270532 nosy: dstufft, r.david.murray priority: normal severity: normal status: open title: test_venv.TestEnsurePip fails mysteriously when /tmp is too small type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 22:13:35 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 16 Jul 2016 02:13:35 +0000 Subject: [issue12750] add cross-platform support for %s strftime-format code In-Reply-To: <1313375473.21.0.352014190788.issue12750@psf.upfronthosting.co.za> Message-ID: <1468635215.37.0.0241206038485.issue12750@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Given that we have the .timestamp() method, I am not sure this would be a very useful feature, but maybe it is a way to eliminate an attractive nuisance. If anyone is still interested in getting this in - please check with python-ideas. ---------- title: datetime.strftime('%s') should respect tzinfo -> add cross-platform support for %s strftime-format code _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 22:19:02 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 16 Jul 2016 02:19:02 +0000 Subject: [issue22246] add strptime(s, '%s') In-Reply-To: <1408664936.57.0.427329646216.issue22246@psf.upfronthosting.co.za> Message-ID: <1468635542.15.0.961018594167.issue22246@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- assignee: -> belopolsky versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 22:24:04 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 16 Jul 2016 02:24:04 +0000 Subject: [issue22246] add strptime(s, '%s') In-Reply-To: <1408664936.57.0.427329646216.issue22246@psf.upfronthosting.co.za> Message-ID: <1468635844.59.0.808678840838.issue22246@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: With PEP 495, conversion from timestamp to naive datetime will no longer loose information. In light of this, I would like to reconsider what strftime('%s') should return in the absence of %z. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 15 22:34:06 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 16 Jul 2016 02:34:06 +0000 Subject: [issue15443] datetime module has no support for nanoseconds In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za> Message-ID: <1468636446.29.0.565481495644.issue15443@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Note that the patches attached so far to this issue are nowhere close to a complete implementation. I don't think a python-only prototype (a patch to datetime.py) would be hard to implement, but implementation would be easier if nanoseconds replaced microseconds in datetime and timedelta objects with new microsecond(s) becoming a computed property. ---------- keywords: -patch versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 00:05:27 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Sat, 16 Jul 2016 04:05:27 +0000 Subject: [issue27485] urllib.splitport -- is it official or not? In-Reply-To: <1468260123.51.0.000787877209911.issue27485@psf.upfronthosting.co.za> Message-ID: <1468641927.84.0.164849120938.issue27485@psf.upfronthosting.co.za> Senthil Kumaran added the comment: I think that we use encourage everyone to use the higher level functions like urlparse() or urlsplit() and then get the .port from the named tuple result. Two things to do. 1. Update that Note the documentation which states a false statement that those helper functions are not exposed in urllib.parse 2. Raise a DeprecationWarning and rename them to _splitport() ---------- nosy: +orsenthil versions: -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 00:37:30 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 Jul 2016 04:37:30 +0000 Subject: [issue27083] PYTHONCASEOK is ignored on Windows In-Reply-To: <1463899532.05.0.0164205622545.issue27083@psf.upfronthosting.co.za> Message-ID: <1468643850.19.0.756015473653.issue27083@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, I think it will work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 01:16:03 2016 From: report at bugs.python.org (Decorater) Date: Sat, 16 Jul 2016 05:16:03 +0000 Subject: [issue27527] Make not yielding from or awaiting a coroutine a SyntaxError Message-ID: <1468646163.93.0.141694067848.issue27527@psf.upfronthosting.co.za> New submission from Decorater: Currently there is a waring printed in python when you try to call a coroutine without yieling from or awaiting it but I would like it to be a SyntaxError when this happens instead. ---------- components: Windows messages: 270538 nosy: Decorater, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Make not yielding from or awaiting a coroutine a SyntaxError versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 01:21:19 2016 From: report at bugs.python.org (Decorater) Date: Sat, 16 Jul 2016 05:21:19 +0000 Subject: [issue27527] Make not yielding from or awaiting a coroutine a SyntaxError In-Reply-To: <1468646163.93.0.141694067848.issue27527@psf.upfronthosting.co.za> Message-ID: <1468646479.26.0.293917004749.issue27527@psf.upfronthosting.co.za> Decorater added the comment: I am thinking like this example: import asyncio @asyncio.coroutine def SomeCoroutine(): print("test...") @asyncio.coroutine def SomeNormalFunction(): SomeCoroutine() Will print a warning instead I would like it to be a SyntaxError when the function is called that tries to call a coroutine that has not been yielded/awaited at all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 01:28:11 2016 From: report at bugs.python.org (Decorater) Date: Sat, 16 Jul 2016 05:28:11 +0000 Subject: [issue27527] Make not yielding from or awaiting a coroutine a SyntaxError In-Reply-To: <1468646163.93.0.141694067848.issue27527@psf.upfronthosting.co.za> Message-ID: <1468646891.89.0.0967313599913.issue27527@psf.upfronthosting.co.za> Changes by Decorater : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 02:12:08 2016 From: report at bugs.python.org (Decorater) Date: Sat, 16 Jul 2016 06:12:08 +0000 Subject: [issue27527] Make not yielding from or awaiting a coroutine a SyntaxError In-Reply-To: <1468646163.93.0.141694067848.issue27527@psf.upfronthosting.co.za> Message-ID: <1468649528.28.0.11172229478.issue27527@psf.upfronthosting.co.za> Decorater added the comment: Oh it does not happen if you use the asyncio.coroutine decorater but it does do RuntimeWarning if you use the async def on it. ---------- versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 02:12:48 2016 From: report at bugs.python.org (Decorater) Date: Sat, 16 Jul 2016 06:12:48 +0000 Subject: [issue27527] Make not yielding from or awaiting a coroutine a SyntaxError In-Reply-To: <1468646163.93.0.141694067848.issue27527@psf.upfronthosting.co.za> Message-ID: <1468649568.54.0.215741591296.issue27527@psf.upfronthosting.co.za> Decorater added the comment: So to make it Error it must be : import asyncio async def SomeCoroutine(): print("test...") SomeCoroutine() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 02:45:52 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 16 Jul 2016 06:45:52 +0000 Subject: [issue27515] Dotted name re-import does not rebind after deletion In-Reply-To: <1468529315.51.0.393890498474.issue27515@psf.upfronthosting.co.za> Message-ID: <1468651552.79.0.413628206367.issue27515@psf.upfronthosting.co.za> Nick Coghlan added the comment: Terry: it's not a 100% guarantee, but it should be sufficient for your purposes (the more obscure failure modes mostly relate to C level globals, Python level module globals, pickling, and module import having side effects on state in other modules, and it's unlikely you'll hit any of those here as long as the main "tk" module and any modules it implicitly imports stay loaded. If you do end up getting bug reports about this, we can treat those as a bug in the affected modules) As far as the module count goes, a plain "import tkinter" gets the imported module count up to 63, so that's presumably an absolute lower bound on your efforts. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 02:49:01 2016 From: report at bugs.python.org (Antti Haapala) Date: Sat, 16 Jul 2016 06:49:01 +0000 Subject: [issue24954] No way to generate or parse timezone as produced by datetime.isoformat() In-Reply-To: <1440801281.72.0.545558404714.issue24954@psf.upfronthosting.co.za> Message-ID: <1468651741.16.0.884974337252.issue24954@psf.upfronthosting.co.za> Antti Haapala added the comment: "Be conservative in what you do, be liberal in what you accept from others" they say. Also Z as a timezone designator is also widely used in iso 8601 timestamps. I believe the effort should be made to *parse* *any/all* of the ISO 8601 supported time-zone codes with one conversion, the list is not that long, just 'Z', HH, HH:MM, HHMM, longest match. Literal 'Z' really does not need to be supported for *output* at all, but for input, please. Otherwise this will still go down the road of iso8601 library, which just tries to support all the YYmmddTHHMMSS.FFFFFFzzzz variants. It uses regular expressions to parse the dates as it is faster than trying N different formats with `strptime` ---------- nosy: +ztane _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 03:27:46 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 16 Jul 2016 07:27:46 +0000 Subject: [issue27083] PYTHONCASEOK is ignored on Windows In-Reply-To: <1463899532.05.0.0164205622545.issue27083@psf.upfronthosting.co.za> Message-ID: <1468654066.43.0.592703320704.issue27083@psf.upfronthosting.co.za> Martin Panter added the comment: This appears to have broken the tests on Windows: http://buildbot.python.org/all/builders/x86%20Windows7%203.5/builds/1030/steps/test/logs/stdio ====================================================================== FAIL: test_insensitive (test.test_importlib.source.test_case_sensitivity.Frozen_CaseSensitivityTestPEP302) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\cygwin\home\db3l\buildarea\3.5.bolen-windows7\build\lib\test\test_importlib\source\test_case_sensitivity.py", line 65, in test_insensitive self.assertIsNotNone(insensitive) AssertionError: unexpectedly None (Plus three more failures) ---------- nosy: +martin.panter status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 03:29:19 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 Jul 2016 07:29:19 +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: <20160716072913.32538.48210.7BD6743A@psf.io> Roundup Robot added the comment: New changeset 0d8f139a6e19 by Martin Panter in branch 'default': Issue #27285: Cleanup leftover susp-ignored entry after text was changed https://hg.python.org/cpython/rev/0d8f139a6e19 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 03:47:50 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 16 Jul 2016 07:47:50 +0000 Subject: [issue27528] Document that filterwarnings(message=...) matches the start of a message Message-ID: <1468655270.19.0.264691959865.issue27528@psf.upfronthosting.co.za> New submission from Martin Panter: I assumed that the ?message? parameter could be used to match any substring of a warning message, but it turns out it calls regex.match(), which is anchored at the beginning of the search string (but is not anchored at the end). I propose this patch to clarify the documentation, and add some tests. ---------- assignee: docs at python components: Documentation files: match-start.patch keywords: patch messages: 270546 nosy: docs at python, martin.panter priority: normal severity: normal stage: patch review status: open title: Document that filterwarnings(message=...) matches the start of a message versions: Python 2.7, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43744/match-start.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 04:43:03 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 16 Jul 2016 08:43:03 +0000 Subject: [issue27487] -m switch regression in Python 3.5.2 (under rare circumstances) In-Reply-To: <1468268291.19.0.631980361837.issue27487@psf.upfronthosting.co.za> Message-ID: <1468658583.85.0.714461935127.issue27487@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch with the proposed warning. I think ?Error finding module specification? might be a bit better than the current ?finding spec?, so I included that change. With the patch, this is what the messages look like: $ ./python -m package.module /media/disk/home/proj/python/cpython/Lib/runpy.py:125: RuntimeWarning: 'package.module' found in sys.modules after import of any parent packages, but prior to execution; this may result in unpredictable behaviour warn(RuntimeWarning(msg)) /media/disk/home/proj/python/cpython/python: Error while finding module specification for 'package.module' (ValueError: package.module.__spec__ is not set) [Exit 1] The warning also occurs when running toplevel modules that are already imported: $ ./python -m runpy /media/disk/home/proj/python/cpython/Lib/runpy.py:125: RuntimeWarning: 'runpy' found in sys.modules after import of any parent packages, but prior to execution; this may result in unpredictable behaviour warn(RuntimeWarning(msg)) No module specified for execution FWIW, to fully avoid the regression and keep my original bug fixed at the same time, I think we would need a way for importlib.util.find_spec() to differentiate its own exceptions (the ValueError for missing __spec__, the ImportError for nonexistent parent package, etc) from exceptions raised by __init__.py code. The exceptions currently raised by find_spec() are not flexible enough for the runpy use case. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file43745/warn-imported.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 04:46:43 2016 From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=) Date: Sat, 16 Jul 2016 08:46:43 +0000 Subject: [issue21136] fractions.Fraction.__pow__ does unneeded renormalization In-Reply-To: <1396482750.35.0.873465877702.issue21136@psf.upfronthosting.co.za> Message-ID: <1468658803.68.0.338956548274.issue21136@psf.upfronthosting.co.za> Vedran ?a?i? added the comment: Unfortunately, this introduced a bug. It seems Mark Dickinson should go easier on his LGTMs. :-) >>> import fractions >>> fractions.Fraction(-1, 2) ** -1 Fraction(2, -1) That is a really strange object, since it's not normalized, and many functions expect all Fractions to be. For example, >>> _ == -2 False Of course, the easy fix would be to change line 52 of fractions.py to _normalize=True - but that would reintroduce the slowness talked about in the original message. Alternative fix would be to be careful about sign of the base, which might be messy if we intend to be completely general -- for example, in finite quotient rings, fractions don't have well-defined signs. [I'm not quite sure why the code in fractions.py is so general, maybe someone really wanted such a level of generality. I don't, so I'd be fine with this working only on int/int Fractions.] ---------- nosy: +Vedran.?a?i? versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 04:57:17 2016 From: report at bugs.python.org (Dor Dankner) Date: Sat, 16 Jul 2016 08:57:17 +0000 Subject: [issue27525] Wrong OS header on file created by gzip module In-Reply-To: <1468617293.43.0.813584223225.issue27525@psf.upfronthosting.co.za> Message-ID: <1468659437.23.0.291691557167.issue27525@psf.upfronthosting.co.za> Dor Dankner added the comment: It does not seem like a feature after you see this issue #27521. The OS was just hardcoded, the same way the compression level was hardcoded. you may say it's a feature too :P The way I see it, the gzip module should at least work like the original GNU gzip, if not following the RFC (which I believe is even better). Anyways i verified that OS X fills a UNIX OS header, and fixed my code (patch included) :) ---------- Added file: http://bugs.python.org/file43746/gzip_os_header_fix_and_tests_mac_fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 04:59:54 2016 From: report at bugs.python.org (Mirano Tuk) Date: Sat, 16 Jul 2016 08:59:54 +0000 Subject: [issue27529] Tkinter memory leak on OS X Message-ID: <1468659594.57.0.874170107699.issue27529@psf.upfronthosting.co.za> New submission from Mirano Tuk: There seems to be a memory leak in tkinter on OSX (Windows and Linux don't seem to be affected). Explicitly calling Tk.update() sometimes permanently allocates a multiple of 4096 bytes. Allocation happens more frequently if update calls are in close succession. import time from tkinter import Tk root = Tk() while True: root.update() # Huge memory leak while True: root.update() # No memory leaks time.sleep(1) Issue occurs on python3.3 and above, did not test on older versions. ---------- components: Macintosh, Tkinter messages: 270550 nosy: Mirano Tuk, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Tkinter memory leak on OS X type: resource usage versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 05:50:49 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 16 Jul 2016 09:50:49 +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: <1468662649.25.0.216847201784.issue20842@psf.upfronthosting.co.za> Martin Panter added the comment: I still think the links are too dense. Three links to the same term in two short paragraphs is too much. Do you think it would be okay to just link the first occurrence for pkgutil.ImpImporter? Also, there is still a problem at least the definition of ?finder? used by the ImpImporter documentation. In PEP 302, ?a finder object has a single method: finder.find_module(fullname, path=None)?. This seems to be a pretty good description of the ImpImporter API. However, by dropping the reference to PEP 302, and linking to the glossary definition, we are suggesting that ImpImporter implements importlib.abc.MetaPathFinder and/or importlib.abc.PathEntryFinder. Both these APIs require some sort of find_spec() method, which is not provided by ImpImporter. As I see it, either Python?s ?finder? glossary entry should be adjusted to accommodate PEP 302, or we should retain the PEP 302 reference and not point at the wrong definition of ?finder?. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 06:17:33 2016 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Sat, 16 Jul 2016 10:17:33 +0000 Subject: [issue25571] Improve the lltrace feature with the Py_Debug mode In-Reply-To: <1446844426.01.0.118649403374.issue25571@psf.upfronthosting.co.za> Message-ID: <1468664253.08.0.108629793403.issue25571@psf.upfronthosting.co.za> St?phane Wirtel added the comment: Here is a small example of lltrace when you enable it. ``` stephane at sg1 ~/s/h/cpython> ./python Python 3.6.0a3+ (default:0d8f139a6e19+, Jul 16 2016, 11:59:46) [GCC 6.1.1 20160621 (Red Hat 6.1.1-3)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> print >>> print("hello") hello >>> __ltrace__ = None >>> print("hello") 0: LOAD_NAME, 0 push 2: LOAD_CONST, 0 push 'hello' 4: CALL_FUNCTION, 1 ext_pop 'hello' hello ext_pop push None 6: PRINT_EXPR pop None 8: LOAD_CONST, 1 push None 10: RETURN_VALUE pop None >>> del __ltrace__ 0: DELETE_NAME, 0 2: LOAD_CONST, 0 push None 4: RETURN_VALUE pop None >>> print("hello") hello >>> print("hello") ``` ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 06:21:51 2016 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Sat, 16 Jul 2016 10:21:51 +0000 Subject: [issue25571] Improve the lltrace feature with the Py_Debug mode In-Reply-To: <1446844426.01.0.118649403374.issue25571@psf.upfronthosting.co.za> Message-ID: <1468664511.6.0.261674349644.issue25571@psf.upfronthosting.co.za> St?phane Wirtel added the comment: here is the patch, if you want to test it, just use the REPL and add __ltrace__ = None in the REPL. ---------- Added file: http://bugs.python.org/file43747/issue25571-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 06:44:57 2016 From: report at bugs.python.org (Oleg Broytman) Date: Sat, 16 Jul 2016 10:44:57 +0000 Subject: [issue23262] webbrowser module broken with Firefox 36+ In-Reply-To: <1421554616.48.0.911036047072.issue23262@psf.upfronthosting.co.za> Message-ID: <1468665897.55.0.0169238097294.issue23262@psf.upfronthosting.co.za> Oleg Broytman added the comment: Patch for Python 2.7 to support Firefox >= 36.0, with version test. ---------- keywords: +patch Added file: http://bugs.python.org/file43748/webbrowser.py-2.7-newfox.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 06:45:29 2016 From: report at bugs.python.org (Oleg Broytman) Date: Sat, 16 Jul 2016 10:45:29 +0000 Subject: [issue23262] webbrowser module broken with Firefox 36+ In-Reply-To: <1421554616.48.0.911036047072.issue23262@psf.upfronthosting.co.za> Message-ID: <1468665929.85.0.471031186435.issue23262@psf.upfronthosting.co.za> Oleg Broytman added the comment: Patch for Python 3.4 and 3.5 to support Firefox >= 36.0, with version test. ---------- Added file: http://bugs.python.org/file43749/webbrowser.py-3.4-newfox.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 06:47:08 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 16 Jul 2016 10:47:08 +0000 Subject: [issue23262] webbrowser module broken with Firefox 36+ In-Reply-To: <1421554616.48.0.911036047072.issue23262@psf.upfronthosting.co.za> Message-ID: <1468666028.91.0.48149719951.issue23262@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: -pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 08:34:27 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 16 Jul 2016 12:34:27 +0000 Subject: [issue23262] webbrowser module broken with Firefox 36+ In-Reply-To: <1421554616.48.0.911036047072.issue23262@psf.upfronthosting.co.za> Message-ID: <1468672467.97.0.299264944275.issue23262@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patches! Can't you just use a function from the high level subprocess API (like subprocess.run()? ---------- stage: -> patch review versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 08:45:34 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 16 Jul 2016 12:45:34 +0000 Subject: [issue27527] Make not yielding from or awaiting a coroutine a SyntaxError In-Reply-To: <1468646163.93.0.141694067848.issue27527@psf.upfronthosting.co.za> Message-ID: <1468673134.63.0.836561285089.issue27527@psf.upfronthosting.co.za> R. David Murray added the comment: It can't be a syntax error. There are legitimate reasons for calling a coroutine and then passing around the resulting object before awaiting it. ---------- nosy: +r.david.murray resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 08:48:08 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 16 Jul 2016 12:48:08 +0000 Subject: [issue27527] Make not yielding from or awaiting a coroutine a SyntaxError In-Reply-To: <1468646163.93.0.141694067848.issue27527@psf.upfronthosting.co.za> Message-ID: <1468673288.18.0.114860696849.issue27527@psf.upfronthosting.co.za> R. David Murray added the comment: Also, fyi it was couterproductive to code this as a Windows issue...that alerted the windows experts, but it is not a windows-specific issue, so it just pinged them needlessly. Also FYI, enahancements can only go into the next feature release, so the correct versions selection would have been 3.6 only. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 09:07:13 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 16 Jul 2016 13:07:13 +0000 Subject: [issue27525] Wrong OS header on file created by gzip module In-Reply-To: <1468617293.43.0.813584223225.issue27525@psf.upfronthosting.co.za> Message-ID: <1468674433.0.0.194721997418.issue27525@psf.upfronthosting.co.za> R. David Murray added the comment: This is a harder call than #27521. There (IUUC), the *wrong* compression level was specified. Here, 'unknown' is a valid value. The biggest disadvantage of changing this is the maintenance burden of keeping it up to date with platform changes (eg: we're eventually adding android support, and andriod (may not be?) posix. Without a defined benefit, I'm -0.5 on changing this. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 10:29:49 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 16 Jul 2016 14:29: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: <1468679389.08.0.734546480929.issue27130@psf.upfronthosting.co.za> Xiang Zhang added the comment: Upload the v9 version. It applies your last comment and catch up with the hg tip. ---------- Added file: http://bugs.python.org/file43750/64bit_support_for_zlib_v9.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 11:11:25 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 16 Jul 2016 15:11:25 +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: <1468681885.87.0.939975372844.issue27130@psf.upfronthosting.co.za> Martin Panter added the comment: I added one comment, but I think this might almost be ready ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 11:11:54 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 16 Jul 2016 15:11:54 +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: <1468681914.48.0.445268760263.issue27130@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- Removed message: http://bugs.python.org/msg270561 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 11:16:00 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 16 Jul 2016 15:16:00 +0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1468682160.67.0.551884707716.issue1621@psf.upfronthosting.co.za> Martin Panter added the comment: I tried the newer -fsanitize=undefined mode, and it is better than -ftrapv. It adds instrumentation that by default nicely reports the errors and continues running. My problem with the large slice step is not restricted to Element Tree; it affects list objects too: >>> "abcdef"[3::sys.maxsize] Objects/unicodeobject.c:13794:55: runtime error: signed integer overflow: 3 + 9223372036854775807 cannot be represented in type 'long int' 'd' Regarding Antti?s overflow macros, I noticed there is already a macro _PyTime_check_mul_overflow() in Python/pytime.c which does that kind of thing. Maybe it could help, though I am not sure. Has this sort of thing been done in other projects? We might need to be careful about the sign, e.g. clarify the macro is only for positive values, add an assertion, or handle both positive and negative. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 11:24:51 2016 From: report at bugs.python.org (Oleg Broytman) Date: Sat, 16 Jul 2016 15:24:51 +0000 Subject: [issue23262] webbrowser module broken with Firefox 36+ In-Reply-To: <1421554616.48.0.911036047072.issue23262@psf.upfronthosting.co.za> Message-ID: <1468682691.07.0.736655518885.issue23262@psf.upfronthosting.co.za> Oleg Broytman added the comment: Not subprocess.run() as I'm aiming to Python 2.7. Perhaps subprocess.check_output(). I'll try it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 11:35:25 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 16 Jul 2016 15:35:25 +0000 Subject: [issue27507] bytearray.extend lacks overflow check when increasing buffer In-Reply-To: <1468429948.12.0.767304648411.issue27507@psf.upfronthosting.co.za> Message-ID: <1468683325.83.0.281039068579.issue27507@psf.upfronthosting.co.za> Martin Panter added the comment: Not particularly related, but the special fast case in Objects/listobject.c:811, listextend(), also seems to lack an overflow check. ?An alternative would be to raise the error without trying to allocate Py_SSIZE_T_MAX first?: what I meant was removing the special case to allocate PY_SSIZE_T_MAX. As soon as it attempts to overallocate 2+ GiB of memory it fails. Something more like addition = len >> 1; if (addition > PY_SSIZE_T_MAX - len - 1) { /* . . . */ return PyErr_NoMemory(); } buf_size = len + addition; Antti: in this case we are allocating an array of _bytes_, not pointers. So maybe it is possible to reach the limit with a 32-bit address space. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 11:47:15 2016 From: report at bugs.python.org (Oleg Broytman) Date: Sat, 16 Jul 2016 15:47:15 +0000 Subject: [issue23262] webbrowser module broken with Firefox 36+ In-Reply-To: <1421554616.48.0.911036047072.issue23262@psf.upfronthosting.co.za> Message-ID: <1468684035.35.0.904232496618.issue23262@psf.upfronthosting.co.za> Oleg Broytman added the comment: Updated patch for Python 2.7 with subprocess.check_output(). ---------- Added file: http://bugs.python.org/file43751/webbrowser.py-2.7-newfox.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 11:47:31 2016 From: report at bugs.python.org (Oleg Broytman) Date: Sat, 16 Jul 2016 15:47:31 +0000 Subject: [issue23262] webbrowser module broken with Firefox 36+ In-Reply-To: <1421554616.48.0.911036047072.issue23262@psf.upfronthosting.co.za> Message-ID: <1468684051.51.0.611404395916.issue23262@psf.upfronthosting.co.za> Oleg Broytman added the comment: Updated patch for Python 3.4+ with subprocess.check_output(). ---------- Added file: http://bugs.python.org/file43752/webbrowser.py-3.4-newfox.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 11:49:21 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 16 Jul 2016 15:49:21 +0000 Subject: [issue23262] webbrowser module broken with Firefox 36+ In-Reply-To: <1421554616.48.0.911036047072.issue23262@psf.upfronthosting.co.za> Message-ID: <1468684161.88.0.655961152883.issue23262@psf.upfronthosting.co.za> Berker Peksag added the comment: I was talking about webbrowser.py-3.4-newfox.patch 3.4 is now in security-fix-only mode so we can't push the patch to the 3.4 branch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 11:51:14 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 16 Jul 2016 15:51:14 +0000 Subject: [issue27507] bytearray.extend lacks overflow check when increasing buffer In-Reply-To: <1468429948.12.0.767304648411.issue27507@psf.upfronthosting.co.za> Message-ID: <1468684274.85.0.260880560763.issue27507@psf.upfronthosting.co.za> Xiang Zhang added the comment: I can't totally agree the point. The code means every time we increase the buffer by half the current length. So when the length arrives 2/3 * PY_SSIZE_T_MAX it's going to overflow. There is a 1/3 * PY_SSIZE_T_MAX gap between the theoretical upper limit. I think leaving such a gap and exiting is somewhat too rude. So in such case I make it have a try. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 11:53:40 2016 From: report at bugs.python.org (Oleg Broytman) Date: Sat, 16 Jul 2016 15:53:40 +0000 Subject: [issue23262] webbrowser module broken with Firefox 36+ In-Reply-To: <1421554616.48.0.911036047072.issue23262@psf.upfronthosting.co.za> Message-ID: <1468684420.7.0.969917614194.issue23262@psf.upfronthosting.co.za> Oleg Broytman added the comment: I am on Debian 8 "jessie" that only has Python 3.4, so I want to patch webbrowser.py in a backward-compatible way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 11:55:01 2016 From: report at bugs.python.org (Ned Deily) Date: Sat, 16 Jul 2016 15:55:01 +0000 Subject: [issue27529] Tkinter memory leak on OS X In-Reply-To: <1468659594.57.0.874170107699.issue27529@psf.upfronthosting.co.za> Message-ID: <1468684501.49.0.608515566746.issue27529@psf.upfronthosting.co.za> Ned Deily added the comment: tkinter is pretty much just a thin wrapper around the Tcl/Tk C API so suspicion for behavior like this start there. Usually, the easiest way to confirm that is to write an equivalent test in Tcl using its wish shell but, in this case, there's an even easier way. The memory leak is easy to see if you use the badly out-of-date and seriously flawed system Tcl/Tk 8.5.x supplied by Apple in OS X releases since 10.6. If tkinter is linked with an up-to-date Tcl/Tk, the leak should go away. At least that's the case when using python3.5 from python.org 10.6+ installers and with ActiveTcl 8.5.18 installed. See https://www.python.org/download/mac/tcltk/ for more info. ---------- resolution: -> third party stage: -> resolved status: open -> closed versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 11:55:44 2016 From: report at bugs.python.org (Ned Deily) Date: Sat, 16 Jul 2016 15:55:44 +0000 Subject: [issue27529] Tkinter memory leak on OS X In-Reply-To: <1468659594.57.0.874170107699.issue27529@psf.upfronthosting.co.za> Message-ID: <1468684544.34.0.551184207897.issue27529@psf.upfronthosting.co.za> Ned Deily added the comment: tkinter is pretty much just a thin wrapper around the Tcl/Tk C API so suspicion for behavior like this should start there. Usually, the easiest way to confirm that is to write an equivalent test in Tcl using its wish shell but, in this case, there's an even easier way. The memory leak is easy to see if you use the badly out-of-date and seriously flawed system Tcl/Tk 8.5.x supplied by Apple in OS X releases since 10.6. If tkinter is linked with an up-to-date Tcl/Tk, the leak should go away. At least that's the case when using python3.5 from python.org 10.6+ installers and with ActiveTcl 8.5.18 installed. See https://www.python.org/download/mac/tcltk/ for more info. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 11:55:58 2016 From: report at bugs.python.org (Ned Deily) Date: Sat, 16 Jul 2016 15:55:58 +0000 Subject: [issue27529] Tkinter memory leak on OS X In-Reply-To: <1468659594.57.0.874170107699.issue27529@psf.upfronthosting.co.za> Message-ID: <1468684558.0.0.725203510499.issue27529@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- Removed message: http://bugs.python.org/msg270570 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 13:05:44 2016 From: report at bugs.python.org (Daniel Lord) Date: Sat, 16 Jul 2016 17:05:44 +0000 Subject: [issue27530] Non-Critical Compiler WARNING: Python Embedding C++11 does not allow non-constant string literals Message-ID: <1468688744.22.0.0620333802067.issue27530@psf.upfronthosting.co.za> New submission from Daniel Lord: ERROR SUMMARY: abstract.h:1332:60: warning: ISO C++ forbids converting a string constant to ?char*? [-Wwrite-strings] #define PyMapping_Keys(O) PyObject_CallMethod(O,"keys",NULL) ISSUE CRITICALITY: Non-fatal Warning (will become an error eventually when deprecations expire and errors are introduced in c++XX or later) COMPILER: g++ -std=c++11 g++ 4.2.1 $g++ -v Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 7.3.0 (clang-703.0.31) Target: x86_64-apple-darwin15.5.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin FILE: abstract.h WORKAROUND: add compiler option: -Wc++11-compat-deprecated-writable-strings and -Wwritable-strings. In theory anyway: doesn't seem to work (still get the warning) and when I tried g++ 5.3.0, the compiler marks that option as an error and unsupported. g++-5.3.0: error: unrecognized command line option ?-Wwritable-strings? g++-5.3.0: error: unrecognized command line option ?-Wc++11-compat-deprecated-writable-strings? ERROR MESSAGE: warning: ISO C++11 does not allow conversion from string literal to 'char *' [-Wwritable-strings] pList = PyMapping_Keys(pDict); ^ /Users/xxxxxx/anaconda/include/python2.7/abstract.h:1332:49: note: expanded from macro 'PyMapping_Keys' #define PyMapping_Keys(O) PyObject_CallMethod(O,"keys",NULL) ^ 1 warning generated. OFFENDING STATEMNT: #define PyMapping_Keys(O) PyObject_CallMethod(O,"keys",NULL) PROBLEM: "keys" is a string literal but not declared as a constant. COMMENTS: This is not a big deal...yet. I can compile with g++ C++11 using the above flag to allow deprecated writeable string literals for my application embedding Python 2.7. However, I assume the embedding code is replete with non-constant string literals which eventually need to be fixed though this is the first one I have run into. ---------- components: Extension Modules messages: 270572 nosy: Daniel Lord priority: normal severity: normal status: open title: Non-Critical Compiler WARNING: Python Embedding C++11 does not allow non-constant string literals type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 13:09:22 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 16 Jul 2016 17:09:22 +0000 Subject: [issue24954] No way to generate or parse timezone as produced by datetime.isoformat() In-Reply-To: <1440801281.72.0.545558404714.issue24954@psf.upfronthosting.co.za> Message-ID: <1468688962.77.0.0650589607676.issue24954@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: "Be conservative in what you do, be liberal in what you accept from others" I would agree to this approach with respect to a proposed fromisoformat() method (see issue 15873), but setptime seems to be about specifying an exact format. For example, "%Y%m%d" will not accept "2016-07-16". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 13:17:28 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 16 Jul 2016 17:17:28 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <1468689448.74.0.555420440783.issue24773@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Submitting the latest Github snapshot as a patch against master for review. See issue24773-s3-2.diff. ---------- Added file: http://bugs.python.org/file43753/issue24773-s3-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 13:20:26 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 16 Jul 2016 17:20:26 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <1468689626.77.0.104929730814.issue24773@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +haypo stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 13:26:26 2016 From: report at bugs.python.org (Antti Haapala) Date: Sat, 16 Jul 2016 17:26:26 +0000 Subject: [issue24954] No way to generate or parse timezone as produced by datetime.isoformat() In-Reply-To: <1440801281.72.0.545558404714.issue24954@psf.upfronthosting.co.za> Message-ID: <1468689986.08.0.967481929415.issue24954@psf.upfronthosting.co.za> Antti Haapala added the comment: Alexander: that is true, because they are *separate* conversion flags. However even the POSIX standard strptime has some leniency: '%m` and `%d` accept the numbers *without* leading zeroes. This actually also means that one cannot use `%Y%m%d` to detect an invalid ISO timestamp: >>> datetime.datetime.strptime('111122', '%Y%m%d') datetime.datetime(1111, 2, 2, 0, 0) The `arrow` library depends on the supposed "strict" behaviour of strptime that has never been guaranteed, which often results in very buggy behaviour under some conditions. ---- (Also, it must be noted that GNU date program doesn't use these formats to *parse* dates, and POSIX strptime in *C* library outright ignores any timezone information) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 13:46:19 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 Jul 2016 17:46:19 +0000 Subject: [issue27083] PYTHONCASEOK is ignored on Windows In-Reply-To: <1463899532.05.0.0164205622545.issue27083@psf.upfronthosting.co.za> Message-ID: <20160716174616.31391.27349.83FFCAE4@psf.io> Roundup Robot added the comment: New changeset 6b46c1510bfa by Brett Cannon in branch '3.5': Fix regressions introduced by fixes for issue #27083. https://hg.python.org/cpython/rev/6b46c1510bfa New changeset f4c91b883772 by Brett Cannon in branch 'default': Merge for #27083 https://hg.python.org/cpython/rev/f4c91b883772 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 14:00:02 2016 From: report at bugs.python.org (Michael Killough) Date: Sat, 16 Jul 2016 18:00:02 +0000 Subject: [issue27531] Documentation for assert_not_called() has wrong signature Message-ID: <1468692002.86.0.178541373215.issue27531@psf.upfronthosting.co.za> New submission from Michael Killough: The documentation for `Mock.assert_not_called` gives its signature as `assert_not_called(*args, **kwargs)`. Since 01ae1ac2daf4, its signature has just been `assert_not_called()`. I've attached a trivial patch that updates the documentation to match the new signature. ---------- assignee: docs at python components: Documentation files: docs-assert_not_called.patch keywords: patch messages: 270577 nosy: docs at python, mjkillough priority: normal severity: normal status: open title: Documentation for assert_not_called() has wrong signature versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43754/docs-assert_not_called.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 14:20:12 2016 From: report at bugs.python.org (Brett Cannon) Date: Sat, 16 Jul 2016 18:20:12 +0000 Subject: [issue27083] PYTHONCASEOK is ignored on Windows In-Reply-To: <1463899532.05.0.0164205622545.issue27083@psf.upfronthosting.co.za> Message-ID: <1468693212.43.0.954503576573.issue27083@psf.upfronthosting.co.za> Brett Cannon added the comment: Buildbots are green again and I addressed the key type issue. Thanks for letting me know about the failure, Martin. ---------- stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 14:21:37 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 16 Jul 2016 18:21:37 +0000 Subject: [issue24954] No way to generate or parse timezone as produced by datetime.isoformat() In-Reply-To: <1440801281.72.0.545558404714.issue24954@psf.upfronthosting.co.za> Message-ID: <1468693297.2.0.814853964453.issue24954@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Antti, while I see some convenience in making %z parsing promiscuous, there is clear utility in adding %:z to strftime. If we do that, not allowing the same for parsing will be odd. Let's start with that. A case for a promiscuous %z can be made later. On a separate issue, note that datetime.isoformat() has recently grown a timespec option. See issue 19475. I wonder if it would make sense to add a tzspec option to control the way timezone is formatted. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 15:03:35 2016 From: report at bugs.python.org (Jeffrey Walton) Date: Sat, 16 Jul 2016 19:03:35 +0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1468682160.67.0.551884707716.issue1621@psf.upfronthosting.co.za> Message-ID: Jeffrey Walton added the comment: > Has this sort of thing been done in other projects? Yes. If you are using C, you can use safe_iop. Android uses it for safer integer operations. If you are using C++, you can use David LeBlanc's SafeInt class. Microsoft uses it for safer inter operations. Jeff ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 15:08:05 2016 From: report at bugs.python.org (James Lu) Date: Sat, 16 Jul 2016 19:08:05 +0000 Subject: [issue27532] Dictionary iterator has no len() Message-ID: <1468696085.0.0.60768174571.issue27532@psf.upfronthosting.co.za> New submission from James Lu: This would be useful for libraries like tqdm (progress bar module). ---------- components: Interpreter Core messages: 270581 nosy: James.Lu priority: normal severity: normal status: open title: Dictionary iterator has no len() type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 15:11:26 2016 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 16 Jul 2016 19:11:26 +0000 Subject: [issue22246] add strptime(s, '%s') In-Reply-To: <1408664936.57.0.427329646216.issue22246@psf.upfronthosting.co.za> Message-ID: <1468696286.7.0.361178629082.issue22246@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 15:14:50 2016 From: report at bugs.python.org (Antti Haapala) Date: Sat, 16 Jul 2016 19:14:50 +0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1468696490.51.0.765273833427.issue1621@psf.upfronthosting.co.za> Antti Haapala added the comment: Gnulib portability library has https://www.gnu.org/software/gnulib/manual/html_node/Integer-Range-Overflow.html and https://www.gnu.org/softwarhe/gnulib/manual/html_node/Integer-Type-Overflow.html and even macros for producing well-defined integer wraparound for signed integers: https://www.gnu.org/software/gnulib/manual/html_node/Wraparound-Arithmetic.html That code is under GPL but I believe there is no problem if someone just looks into that for ideas on how to write similar macros. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 16:13:54 2016 From: report at bugs.python.org (Jeremy Spiegel) Date: Sat, 16 Jul 2016 20:13:54 +0000 Subject: [issue27533] release GIL in nt._isdir Message-ID: <1468700034.79.0.260183682177.issue27533@psf.upfronthosting.co.za> New submission from Jeremy Spiegel: In Modules/posixmodule.c, the function os__isdir_impl calls GetFileAttributesA/GetFileAttributesW without releasing the GIL. This is problematic since it can result in disk or network I/O, depending on the filesystem. ---------- components: Library (Lib) files: _isdir.patch keywords: patch messages: 270583 nosy: jeremyspiegel priority: normal severity: normal status: open title: release GIL in nt._isdir Added file: http://bugs.python.org/file43755/_isdir.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 17:15:16 2016 From: report at bugs.python.org (James Lu) Date: Sat, 16 Jul 2016 21:15:16 +0000 Subject: [issue27532] Dictionary iterator has no len() In-Reply-To: <1468696085.0.0.60768174571.issue27532@psf.upfronthosting.co.za> Message-ID: James Lu added the comment: same for itertools iterators - libraries such as tqdm would benefit from this On Sat, Jul 16, 2016 at 3:08 PM, James Lu wrote: > > New submission from James Lu: > > This would be useful for libraries like tqdm (progress bar module). > > ---------- > components: Interpreter Core > messages: 270581 > nosy: James.Lu > priority: normal > severity: normal > status: open > title: Dictionary iterator has no len() > type: enhancement > versions: Python 3.6 > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 17:22:53 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 16 Jul 2016 21:22:53 +0000 Subject: [issue27532] Dictionary iterator has no len() In-Reply-To: <1468696085.0.0.60768174571.issue27532@psf.upfronthosting.co.za> Message-ID: <1468704173.59.0.835652911207.issue27532@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> duplicate stage: -> resolved superseder: -> Add __len__ to map, everything in itertools _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 17:23:09 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 16 Jul 2016 21:23:09 +0000 Subject: [issue27532] Dictionary iterator has no len() In-Reply-To: <1468696085.0.0.60768174571.issue27532@psf.upfronthosting.co.za> Message-ID: <1468704189.89.0.945820379621.issue27532@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 17:24:23 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 16 Jul 2016 21:24:23 +0000 Subject: [issue27532] Dictionary iterator has no len() In-Reply-To: <1468696085.0.0.60768174571.issue27532@psf.upfronthosting.co.za> Message-ID: <1468704263.9.0.207659399196.issue27532@psf.upfronthosting.co.za> R. David Murray added the comment: If you read issue 24849, you will see that iterators having len was rejected by Guido long ago. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 17:25:36 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 16 Jul 2016 21:25:36 +0000 Subject: [issue22246] add strptime(s, '%s') In-Reply-To: <1408664936.57.0.427329646216.issue22246@psf.upfronthosting.co.za> Message-ID: <1468704336.99.0.470397008122.issue22246@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 17:26:03 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 16 Jul 2016 21:26:03 +0000 Subject: [issue27533] release GIL in nt._isdir In-Reply-To: <1468700034.79.0.260183682177.issue27533@psf.upfronthosting.co.za> Message-ID: <1468704363.29.0.40295118963.issue27533@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 18:09:28 2016 From: report at bugs.python.org (Stefan Krah) Date: Sat, 16 Jul 2016 22:09:28 +0000 Subject: [issue26974] Crash in Decimal.from_float In-Reply-To: <1462684427.76.0.86950702335.issue26974@psf.upfronthosting.co.za> Message-ID: <1468706968.98.0.589076272708.issue26974@psf.upfronthosting.co.za> Stefan Krah added the comment: The approaches look good, but for clarity I want to replace all method calls that should never be overridden by the plain C functions of their corresponding static types. I have no opinion about the Python version. The diff also "fixes" #26975 for the C version, so perhaps the Python version should be in sync. It is an academic question, since no one will write a class that triggers it. Preemptively, I'm aware that long_bit_length() is defined with a single argument, then cast to a CFunction, then called with two arguments. ceval.c does the same. -- We had a discussion about that with MvL a while ago, he preferred to define all CFunctions with two arguments. I'd also prefer that, but that is another issue. ---------- Added file: http://bugs.python.org/file43756/issue26974.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 18:15:52 2016 From: report at bugs.python.org (James Lu) Date: Sat, 16 Jul 2016 22:15:52 +0000 Subject: [issue27532] Dictionary iterator has no len() In-Reply-To: <1468704263.9.0.207659399196.issue27532@psf.upfronthosting.co.za> Message-ID: James Lu added the comment: I think you closed it too quickly. You see, computing the length of combinations() doesn't require looping all the way through the iterator; you can compute it quickly. I created a wrapper class just for this purpose. On Sat, Jul 16, 2016 at 5:24 PM, R. David Murray wrote: > > R. David Murray added the comment: > > If you read issue 24849, you will see that iterators having len was > rejected by Guido long ago. > > ---------- > nosy: +r.david.murray > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 18:18:08 2016 From: report at bugs.python.org (Steve Dower) Date: Sat, 16 Jul 2016 22:18:08 +0000 Subject: [issue27533] release GIL in nt._isdir In-Reply-To: <1468700034.79.0.260183682177.issue27533@psf.upfronthosting.co.za> Message-ID: <1468707488.45.0.219958379873.issue27533@psf.upfronthosting.co.za> Steve Dower added the comment: LGTM. This is the kind of patch I can't wait to have a one-click merge button... right now it'll have to wait until I have a clean repo. But if anyone else wants to get it, go ahead. ---------- stage: -> patch review type: -> behavior versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 18:19:10 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 16 Jul 2016 22:19:10 +0000 Subject: [issue27532] Dictionary iterator has no len() In-Reply-To: <1468696085.0.0.60768174571.issue27532@psf.upfronthosting.co.za> Message-ID: <1468707550.35.0.833240424615.issue27532@psf.upfronthosting.co.za> R. David Murray added the comment: Please read the referenced issue. Your points are addressed there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 18:27:26 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 Jul 2016 22:27:26 +0000 Subject: [issue25507] IDLE: user code 'import tkinter; tkinter.font' should fail In-Reply-To: <1446113442.78.0.389498275803.issue25507@psf.upfronthosting.co.za> Message-ID: <20160716222723.111571.58195.9A3AEEF6@psf.io> Roundup Robot added the comment: New changeset 8df5200064c4 by Terry Jan Reedy in branch '3.5': Issue #25507: IDLE no longer runs buggy code because of its tkinter imports. https://hg.python.org/cpython/rev/8df5200064c4 New changeset af602a891892 by Terry Jan Reedy in branch 'default': Issue #25507: Merge from 3.5 with ttk replacing colorchooser. https://hg.python.org/cpython/rev/af602a891892 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 18:29:00 2016 From: report at bugs.python.org (Eryk Sun) Date: Sat, 16 Jul 2016 22:29:00 +0000 Subject: [issue27533] release GIL in nt._isdir In-Reply-To: <1468700034.79.0.260183682177.issue27533@psf.upfronthosting.co.za> Message-ID: <1468708140.16.0.867175251503.issue27533@psf.upfronthosting.co.za> Eryk Sun added the comment: Should this be backported to 2.7 posix__isdir()? ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 18:39:49 2016 From: report at bugs.python.org (Jeremy Spiegel) Date: Sat, 16 Jul 2016 22:39:49 +0000 Subject: [issue27533] release GIL in nt._isdir In-Reply-To: <1468700034.79.0.260183682177.issue27533@psf.upfronthosting.co.za> Message-ID: <1468708789.4.0.0742295533737.issue27533@psf.upfronthosting.co.za> Changes by Jeremy Spiegel : Added file: http://bugs.python.org/file43757/_isdir.2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 18:40:37 2016 From: report at bugs.python.org (Jeremy Spiegel) Date: Sat, 16 Jul 2016 22:40:37 +0000 Subject: [issue27533] release GIL in nt._isdir In-Reply-To: <1468700034.79.0.260183682177.issue27533@psf.upfronthosting.co.za> Message-ID: <1468708837.13.0.749656514715.issue27533@psf.upfronthosting.co.za> Changes by Jeremy Spiegel : Removed file: http://bugs.python.org/file43757/_isdir.2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 18:41:22 2016 From: report at bugs.python.org (Jeremy Spiegel) Date: Sat, 16 Jul 2016 22:41:22 +0000 Subject: [issue27533] release GIL in nt._isdir In-Reply-To: <1468700034.79.0.260183682177.issue27533@psf.upfronthosting.co.za> Message-ID: <1468708882.36.0.170091108071.issue27533@psf.upfronthosting.co.za> Changes by Jeremy Spiegel : Added file: http://bugs.python.org/file43758/_isdir.2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 19:19:16 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 16 Jul 2016 23:19:16 +0000 Subject: [issue27534] IDLE: Reduce number and time for user process imports Message-ID: <1468711156.27.0.318866145341.issue27534@psf.upfronthosting.co.za> New submission from Terry J. Reedy: This issue continues #25507. I still want to reduce the number of modules imported when run.py starts a user process and the time they require. In the process, I expect to reduce the number of tkinter module imports that need to be reversed and thereby make parts of the #25507 fix unnecessary. "New changeset 93d325c64104 by Terry Jan Reedy in branch 'default': Issue #25507: Move 4 objects from pyshell to run and switch inports. https://hg.python.org/cpython/rev/93d325c64104" This commit for #25507 was not needed for the fix I eventually choose, but it reduced the size of sys.modules in the user process from 193 to 156. I have since determined that it reduced the time for startup imports on my machine from .45 to .25 seconds. I now regard it as the first patch for this issue. The attached file was explained in msg270522. This and similar refactorings should be done when or after I have otherwise revised the module and tests in question. For a Windows build of repository 3.6, importing tkinter into a fresh python process increases len(sys.modules) from 41 to 65. But run only imports tkinter so it can call _tkinter.tkapp().eval('update') in its interactive input loop. If other indirect imports were eliminated, I suspect _tkinter could be imported instead. ---------- assignee: terry.reedy components: IDLE files: run_autocomplete.diff keywords: patch messages: 270592 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: IDLE: Reduce number and time for user process imports type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43759/run_autocomplete.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 19:19:51 2016 From: report at bugs.python.org (Steve Dower) Date: Sat, 16 Jul 2016 23:19:51 +0000 Subject: [issue27469] Unicode filename gets crippled on Windows when drag and drop In-Reply-To: <1467992332.72.0.0240653508758.issue27469@psf.upfronthosting.co.za> Message-ID: <1468711191.09.0.465416304097.issue27469@psf.upfronthosting.co.za> Steve Dower added the comment: Attached my first pass at the shell extension. As this has the potential to crash Windows Explorer, I want to be _really_ thorough, so all reviews and feedback welcomed. ---------- keywords: +patch Added file: http://bugs.python.org/file43760/27469_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 19:39:32 2016 From: report at bugs.python.org (Steve Dower) Date: Sat, 16 Jul 2016 23:39:32 +0000 Subject: [issue27533] release GIL in nt._isdir In-Reply-To: <1468700034.79.0.260183682177.issue27533@psf.upfronthosting.co.za> Message-ID: <1468712372.15.0.664842176698.issue27533@psf.upfronthosting.co.za> Steve Dower added the comment: No, it's not a security fix, so it doesn't go in 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 20:17:31 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 17 Jul 2016 00:17:31 +0000 Subject: [issue25507] IDLE: user code 'import tkinter; tkinter.font' should fail In-Reply-To: <1446113442.78.0.389498275803.issue25507@psf.upfronthosting.co.za> Message-ID: <1468714651.12.0.0533576024656.issue25507@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I decided to fix this issue for both 3.5 and 3.6 by deleting the submodules both from tkinter and sys.modules (as discussed in #27515). I used a new version of tkimports.py to check the result of user imports after the patch. When this file loaded into IDLE and run with F5, the dir listing for each submodule, after previous import and deletion in run startup, is the same as when the file is run with " tkimports". I opened #27534 to continue run import reduction. I consider 93d325c64104 and run_autocomplete.diff to be part of that issue. ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed Added file: http://bugs.python.org/file43761/tkimports.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 20:18:59 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 17 Jul 2016 00:18:59 +0000 Subject: [issue25507] IDLE: user code 'import tkinter; tkinter.font' should fail In-Reply-To: <1446113442.78.0.389498275803.issue25507@psf.upfronthosting.co.za> Message-ID: <1468714739.54.0.175225438059.issue25507@psf.upfronthosting.co.za> Terry J. Reedy added the comment: PS: the test suite run without error on my Win10, 32bit build. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 20:28:20 2016 From: report at bugs.python.org (Eryk Sun) Date: Sun, 17 Jul 2016 00:28:20 +0000 Subject: [issue27533] release GIL in nt._isdir In-Reply-To: <1468700034.79.0.260183682177.issue27533@psf.upfronthosting.co.za> Message-ID: <1468715300.04.0.470548955039.issue27533@psf.upfronthosting.co.za> Eryk Sun added the comment: OK. I thought fixing bugs in 2.7 was at the discretion of core developers, including small tweaks for performance -- just not enhancements with significant amounts of new code and features. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 20:43:47 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 17 Jul 2016 00:43:47 +0000 Subject: [issue25507] IDLE: user code 'import tkinter; tkinter.font' should fail In-Reply-To: <1446113442.78.0.389498275803.issue25507@psf.upfronthosting.co.za> Message-ID: <1468716227.84.0.737216625824.issue25507@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I am thinking about addin a test. ---------- status: closed -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 20:48:38 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 17 Jul 2016 00:48:38 +0000 Subject: [issue27515] Dotted name re-import does not rebind after deletion In-Reply-To: <1468529315.51.0.393890498474.issue27515@psf.upfronthosting.co.za> Message-ID: <1468716518.81.0.246417793079.issue27515@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I understand the reluctance to generically encourage something that does not always arise. With Nick's promise to help examine any particular problems with deletion of tkinter modules, should they arise, I feel comfortable closing this. I already tested and applied double deletion to both 3.5 and 3.6. The tkinter import example illustrates potential benefits from refactoring (which I will continue in #27534). For me, on Win10, 'import tkinter' in a fresh interactive interpreter boosts 'len(sys.modules) from 41 to 65. Except when run cannot start, it only uses tkinter to call _tkinter.tkapp().eval('update') in its interactive input loop. Importing _tkinter instead (a slight risk) would not import anything else. Guido: when I need help with some of the more obscure IDLE code, I will ask. ---------- resolution: -> rejected stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 21:53:43 2016 From: report at bugs.python.org (=?utf-8?b?0JDQu9C10LrRgdCw0L3QtNGAINCa0LDRgNC/0LjQvdGB0LrQuNC5?=) Date: Sun, 17 Jul 2016 01:53:43 +0000 Subject: [issue27535] Memory leaks when opening tons of files Message-ID: <1468720423.06.0.361257976034.issue27535@psf.upfronthosting.co.za> New submission from ????????? ??????????: Actually, this issue is related to the warning module. The test script creates a lot of files with different names and deletes them. On the first pass the scripts calls the `f.close()` method for every file. On the second it doesn't. As a result, on the first pass, the memory consumption is constant and is about 3.9 Mb for my environment. For the second pass, the memory consumption constantly grows up to 246 Mb for 1 million files. I.e. memory leak is about 254 bytes for every opened file. This happens because of warning about not closed files. The memory is consumed for storing all possible warning messages generated for different file names to prevent further warnings with the same messages. Which is not the case if we are always opening new files. While not calling f.close() **might** lead to memory issues, the warning which notifies about this **absolutely guaranteed** leads to memory issue. Although f.close() is highly recommended, this is still the issue for code which doesn't use it for some reasons and doesn't experience other problems with not closed files because files are actually always closed in IOBase.__del__. This issue was discovered in this report: https://github.com/python-pillow/Pillow/issues/2019 The best way to fix this is excluding file name from warning message. As a result, the message for every file will be the same and warnings registry will not grow. For now, the message looks like this: ./memory.py:23: ResourceWarning: unclosed file <_io.FileIO name='__999.tmp' mode='wb' closefd=True> open_files(number, close) It may looks like this: ./memory.py:23: ResourceWarning: unclosed file open_files(number, close) ---------- components: IO files: memory.py messages: 270600 nosy: ????????? ?????????? priority: normal severity: normal status: open title: Memory leaks when opening tons of files type: resource usage versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file43762/memory.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 21:55:18 2016 From: report at bugs.python.org (Steve Dower) Date: Sun, 17 Jul 2016 01:55:18 +0000 Subject: [issue27533] release GIL in nt._isdir In-Reply-To: <1468700034.79.0.260183682177.issue27533@psf.upfronthosting.co.za> Message-ID: <1468720518.43.0.741312635634.issue27533@psf.upfronthosting.co.za> Steve Dower added the comment: Maybe so. If you find a core developer who cares about performance in 2.7, maybe they'll merge it :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 22:36:24 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 17 Jul 2016 02:36:24 +0000 Subject: [issue27507] bytearray.extend lacks overflow check when increasing buffer In-Reply-To: <1468429948.12.0.767304648411.issue27507@psf.upfronthosting.co.za> Message-ID: <1468722984.48.0.676698243706.issue27507@psf.upfronthosting.co.za> Martin Panter added the comment: Yeah I see your point. Anyway I think the current patch is fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 22:43:42 2016 From: report at bugs.python.org (Decorater) Date: Sun, 17 Jul 2016 02:43:42 +0000 Subject: [issue27507] bytearray.extend lacks overflow check when increasing buffer In-Reply-To: <1468429948.12.0.767304648411.issue27507@psf.upfronthosting.co.za> Message-ID: <1468723422.31.0.298126163782.issue27507@psf.upfronthosting.co.za> Decorater added the comment: Only 1 way to find out, test it till it breaks. :P ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 23:04:17 2016 From: report at bugs.python.org (Louis Taylor) Date: Sun, 17 Jul 2016 03:04:17 +0000 Subject: [issue27536] Convert readme to markdown Message-ID: <1468724657.01.0.14643953429.issue27536@psf.upfronthosting.co.za> New submission from Louis Taylor: Since the move to github is happening, the readme should probably be changed to markdown in order to render nicer on the github web interface. Issue 27476 introduced a .github folder, so it seems that preemptive changes for the migration are okay. ---------- files: readme-to-markdown.patch keywords: patch messages: 270604 nosy: louis.taylor priority: normal severity: normal status: open title: Convert readme to markdown type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43763/readme-to-markdown.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 23:14:54 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 17 Jul 2016 03:14:54 +0000 Subject: [issue27536] Convert readme to markdown In-Reply-To: <1468724657.01.0.14643953429.issue27536@psf.upfronthosting.co.za> Message-ID: <1468725294.13.0.285018230633.issue27536@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the patch. If we do want to use a markup language for the README, we would want to use reStructuredText, the standard markup language for CPython, rather than Markdown, which we currently don't use at all. Github supports both, doesn't it? And, for simple documents, like the README, the differences between the two shouldn't be that big. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 23:18:55 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 17 Jul 2016 03:18:55 +0000 Subject: [issue27536] Convert readme to markdown In-Reply-To: <1468724657.01.0.14643953429.issue27536@psf.upfronthosting.co.za> Message-ID: <1468725535.04.0.17218546052.issue27536@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 23:29:01 2016 From: report at bugs.python.org (Louis Taylor) Date: Sun, 17 Jul 2016 03:29:01 +0000 Subject: [issue27536] Convert readme to markdown In-Reply-To: <1468724657.01.0.14643953429.issue27536@psf.upfronthosting.co.za> Message-ID: <1468726141.89.0.0659574927911.issue27536@psf.upfronthosting.co.za> Louis Taylor added the comment: Oh, that's a very good point. Patch updated. ---------- Added file: http://bugs.python.org/file43764/readme-to-rst.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 16 23:39:12 2016 From: report at bugs.python.org (Louis Taylor) Date: Sun, 17 Jul 2016 03:39:12 +0000 Subject: [issue27536] Convert readme to reStructuredText In-Reply-To: <1468724657.01.0.14643953429.issue27536@psf.upfronthosting.co.za> Message-ID: <1468726752.39.0.367372169533.issue27536@psf.upfronthosting.co.za> Changes by Louis Taylor : ---------- title: Convert readme to markdown -> Convert readme to reStructuredText _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 01:32:54 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 Jul 2016 05:32:54 +0000 Subject: [issue27525] Wrong OS header on file created by gzip module In-Reply-To: <1468617293.43.0.813584223225.issue27525@psf.upfronthosting.co.za> Message-ID: <1468733574.96.0.841776604311.issue27525@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This byte identifies the type of file system. How can you determine it? Note that different filesystems can be used on the same OS. FAT still widely used on Windows (and what about exFAT, should it be considered as a flavour of FAT or separate type?), virtually any file system can be mounted on Linux. See 2.3.1.2 in RFC 1952: A compliant compressor must produce files with correct ID1, ID2, CM, CRC32, and ISIZE, but may set all the other fields in the fixed-length part of the header to default values (255 for OS, 0 for all others). [...] a decompressor may ignore FTEXT and OS and always produce binary output, and still be compliant. Since the gzip module never sets the FTEXT flag, the value of the OS field is useless. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 01:38:04 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 Jul 2016 05:38:04 +0000 Subject: [issue27535] Memory leaks when opening tons of files In-Reply-To: <1468720423.06.0.361257976034.issue27535@psf.upfronthosting.co.za> Message-ID: <1468733884.88.0.0419372333664.issue27535@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The file name is helpful for determining the source of the leak. If you don't want to close files in your script, set an appropriate warning filter to silence this kind of warnings. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 01:46:24 2016 From: report at bugs.python.org (=?utf-8?b?0JDQu9C10LrRgdCw0L3QtNGAINCa0LDRgNC/0LjQvdGB0LrQuNC5?=) Date: Sun, 17 Jul 2016 05:46:24 +0000 Subject: [issue27535] Memory leaks when opening tons of files In-Reply-To: <1468720423.06.0.361257976034.issue27535@psf.upfronthosting.co.za> Message-ID: <1468734384.13.0.305671408266.issue27535@psf.upfronthosting.co.za> ????????? ?????????? added the comment: @serhiy.storchaka Any filters not solves the problem because warnings module SAVES EVERY WARNING MESSAGE for further duplication checks. Yes, the file name is helpful for determining the source of the POSSIBLE leak. While file name in error message IS SOURCE OF THE LEAK. When you aware about not closed files, you can log file names. You have a way to do that. But if you want to ignore the warning, the memory will leak. Not because of not closed files, but because of warning itself. I do want to close files in my script, but in Pillow, it is not so easy due to backward compatibility. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 01:47:17 2016 From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=) Date: Sun, 17 Jul 2016 05:47:17 +0000 Subject: [issue21136] fractions.Fraction.__pow__ does unneeded renormalization In-Reply-To: <1396482750.35.0.873465877702.issue21136@psf.upfronthosting.co.za> Message-ID: <1468734437.64.0.223403418666.issue21136@psf.upfronthosting.co.za> Changes by Vedran ?a?i? : ---------- type: performance -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 01:52:11 2016 From: report at bugs.python.org (Dor Dankner) Date: Sun, 17 Jul 2016 05:52:11 +0000 Subject: [issue27525] Wrong OS header on file created by gzip module In-Reply-To: <1468617293.43.0.813584223225.issue27525@psf.upfronthosting.co.za> Message-ID: <1468734731.8.0.189083270535.issue27525@psf.upfronthosting.co.za> Dor Dankner added the comment: I'm convinced. Thank you all for your comments :) ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 02:02:29 2016 From: report at bugs.python.org (pablo sacristan) Date: Sun, 17 Jul 2016 06:02:29 +0000 Subject: [issue27537] Segfault Via Resource Exhaustion Message-ID: <1468735349.04.0.416587593882.issue27537@psf.upfronthosting.co.za> New submission from pablo sacristan: The code is very simple: import sys sys.setrecursionlimit(1<<20) test=lambda test:test(test) test(test) It basically works by changing the recursion limit and then starting an infinite recursion, this quickly gives a segfault. This can be used to crash python. ---------- messages: 270611 nosy: pabstersac priority: normal severity: normal status: open title: Segfault Via Resource Exhaustion versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 02:16:53 2016 From: report at bugs.python.org (pablo sacristan) Date: Sun, 17 Jul 2016 06:16:53 +0000 Subject: [issue27538] Segfault on error in code object checking Message-ID: <1468736213.35.0.202003298623.issue27538@psf.upfronthosting.co.za> New submission from pablo sacristan: The code is also simple on this one: from types import CodeType as code exec code(0, 2, 3, 0, "lol lolol", (), (), (), "", "", 0, "") The interpreter isn't checking if the code object is correct, therefore it is possible to segfault by putting wrong opcodes and more. ---------- messages: 270612 nosy: pabstersac priority: normal severity: normal status: open title: Segfault on error in code object checking versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 02:24:42 2016 From: report at bugs.python.org (Decorater) Date: Sun, 17 Jul 2016 06:24:42 +0000 Subject: [issue27538] Segfault on error in code object checking In-Reply-To: <1468736213.35.0.202003298623.issue27538@psf.upfronthosting.co.za> Message-ID: <1468736682.2.0.677972069524.issue27538@psf.upfronthosting.co.za> Decorater added the comment: Why are you even using v2.7 anyway when you can use asyncio with the coroutines in 3.4 or newer (which is pretty fast on things and is thread safe). ---------- nosy: +Decorater _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 02:29:51 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 17 Jul 2016 06:29:51 +0000 Subject: [issue27537] Segfault Via Resource Exhaustion In-Reply-To: <1468735349.04.0.416587593882.issue27537@psf.upfronthosting.co.za> Message-ID: <1468736991.2.0.146388265219.issue27537@psf.upfronthosting.co.za> Ned Deily added the comment: Sorry, the documentation for sys.setrecursionlimit() explicitly warns you against doing this: "The highest possible limit is platform-dependent. A user may need to set the limit higher when she has a program that requires deep recursion and a platform that supports a higher limit. This should be done with care, because a too-high limit can lead to a crash." https://docs.python.org/2.7/library/sys.html#sys.setrecursionlimit ---------- nosy: +ned.deily resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 03:23:43 2016 From: report at bugs.python.org (Ammar Askar) Date: Sun, 17 Jul 2016 07:23:43 +0000 Subject: [issue27538] Segfault on error in code object checking In-Reply-To: <1468736213.35.0.202003298623.issue27538@psf.upfronthosting.co.za> Message-ID: <1468740223.35.0.550958159705.issue27538@psf.upfronthosting.co.za> Ammar Askar added the comment: Can recreate on both py2.7 and py3.6 Constructor for CodeType in py3.6 is slightly different: exec(code(0, 0, 2, 3, 0, b"lol lolol", (), (), (), "", "", 0, b"")) ---------- nosy: +ammar2 versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 03:32:11 2016 From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=) Date: Sun, 17 Jul 2016 07:32:11 +0000 Subject: [issue27539] negative Fraction ** negative int not normalized Message-ID: <1468740731.71.0.38394274484.issue27539@psf.upfronthosting.co.za> New submission from Vedran ?a?i?: I already wrote http://bugs.python.org/msg270548, but can't seem to reopen the issue, so I think the best thing is to report the bug separately. So, in issue http://bugs.python.org/issue21136, performance enhancement https://hg.python.org/cpython/rev/91d7fadac271/ enabled a shortcut for some operations (__pow__ among them) to avoid reducing the result to lowest terms if it can be concluded it's already reduced. However, the logic has a corner case that was handled incorrectly. If a negative Fraction is raised to a negative integer, the result is a Fraction with a negative denominator, which is not normalized and in fact breaks many other operations (which rightly assume their operands to be normalized). >>> import fractions >>> fractions.Fraction(-1, 2) ** -1 Fraction(2, -1) >>> _ == -2 False Of course, the easy fix would be to change line 52 of fractions.py to _normalize=True - but that would reintroduce the slowness talked about in http://bugs.python.org/issue21136#msg215409. Alternative fix is to branch depending on the sign of the base, which might be messy if we intend to be completely general -- for example, in finite quotient rings, fractions don't have well-defined signs. [BTW I'm not quite sure why the code in fractions.py is so general, with many weird cases trying to support every imaginable construction - maybe someone really wanted such a level of generality. I don't, so I'd be fine with this working only on ordinary int/int Fractions.] ---------- components: Library (Lib) messages: 270616 nosy: Vedran.?a?i? priority: normal severity: normal status: open title: negative Fraction ** negative int not normalized type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 04:05:29 2016 From: report at bugs.python.org (Eryk Sun) Date: Sun, 17 Jul 2016 08:05:29 +0000 Subject: [issue27469] Unicode filename gets crippled on Windows when drag and drop In-Reply-To: <1467992332.72.0.0240653508758.issue27469@psf.upfronthosting.co.za> Message-ID: <1468742729.09.0.531184874991.issue27469@psf.upfronthosting.co.za> Eryk Sun added the comment: Thanks, Steve. I manually added this shell extension as the drop handler for Python.File. It's working with non-ANSI filenames, e.g. "???? ???? ???? ???? ???? ????.txt" in a Western locale. Also, I was able to drop 939 files from the System32 directory, with a total command-line length of 32766 characters. However, I ran into heap corruption that crashed Explorer when dropping files from "C:\Program Files (x86)\Windows Kits\10\Include\10.0.10586.0\um". I used gflags to enable the page heap for Explorer and tracked the problem down to FilenameListCchLength[W|A]. It wasn't allocating space for the double quotes for paths with spaces in them. So I made the following changes: FilenameListCchLengthW: length += oneLength + (wcschr(pszSource, L' ') ? 3 : 1); FilenameListCchLengthA: length += oneLength + (strchr(pszSource, ' ') ? 3 : 1); After this I was able to drop 421 files from the above-mentioned Include directory, with a total command-line length of 32737 characters. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 04:11:15 2016 From: report at bugs.python.org (pablo sacristan) Date: Sun, 17 Jul 2016 08:11:15 +0000 Subject: [issue27538] Segfault on error in code object checking In-Reply-To: <1468736213.35.0.202003298623.issue27538@psf.upfronthosting.co.za> Message-ID: <1468743075.92.0.0200816744056.issue27538@psf.upfronthosting.co.za> pablo sacristan added the comment: I can also reproduce on 3.5 and on 3.4. Thank you. ---------- versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 04:19:53 2016 From: report at bugs.python.org (SilentGhost) Date: Sun, 17 Jul 2016 08:19:53 +0000 Subject: [issue27539] negative Fraction ** negative int not normalized In-Reply-To: <1468740731.71.0.38394274484.issue27539@psf.upfronthosting.co.za> Message-ID: <1468743593.59.0.400140647819.issue27539@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +mark.dickinson, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 04:36:13 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 Jul 2016 08:36:13 +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: <20160717083610.7301.50520.0C97E7B4@psf.io> Roundup Robot added the comment: New changeset f6a41552a312 by Serhiy Storchaka in branch '3.5': Issue #17711: Fixed unpickling by the persistent ID with protocol 0. https://hg.python.org/cpython/rev/f6a41552a312 New changeset df8857c6f3eb by Serhiy Storchaka in branch 'default': Issue #17711: Fixed unpickling by the persistent ID with protocol 0. https://hg.python.org/cpython/rev/df8857c6f3eb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 04:38:20 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 Jul 2016 08:38:20 +0000 Subject: [issue21708] Deprecate nonstandard behavior of a dumbdbm database In-Reply-To: <1402425082.25.0.679069092867.issue21708@psf.upfronthosting.co.za> Message-ID: <1468744700.18.0.0784917764973.issue21708@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 04:43:32 2016 From: report at bugs.python.org (Armin Rigo) Date: Sun, 17 Jul 2016 08:43:32 +0000 Subject: [issue27540] msvcrt.ungetwch() calls _ungetch() Message-ID: <1468745012.08.0.321893951317.issue27540@psf.upfronthosting.co.za> New submission from Armin Rigo: In Python 2.7, PC/msvcrtmodule.c, the function msvcrt_ungetwch() calls _ungetch() instead of _ungetwch() as was probably intended. ---------- components: Extension Modules messages: 270620 nosy: arigo priority: normal severity: normal status: open title: msvcrt.ungetwch() calls _ungetch() type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 04:54:36 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 Jul 2016 08:54:36 +0000 Subject: [issue27541] Repr of collection's subclasses Message-ID: <1468745676.7.0.929499219743.issue27541@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: The repr of subclasses of some collection classes contains a name of the subclass: >>> class S(set): pass ... >>> S([1, 2, 3]) S({1, 2, 3}) >>> import collections >>> class OD(collections.OrderedDict): pass ... >>> OD({1: 2}) OD([(1, 2)]) >>> class C(collections.Counter): pass ... >>> C('senselessness') C({'s': 6, 'e': 4, 'n': 2, 'l': 1}) But the repr of subclasses of some collection classes contains a name of the base class: >>> class BA(bytearray): pass ... >>> BA([1, 2, 3]) bytearray(b'\x01\x02\x03') >>> class D(collections.deque): pass ... >>> D([1, 2, 3]) deque([1, 2, 3]) >>> class DD(collections.defaultdict): pass ... >>> DD(int, {1: 2}) defaultdict(, {1: 2}) Shouldn't a name of the subclass always be used? ---------- components: Extension Modules, Interpreter Core messages: 270621 nosy: rhettinger, serhiy.storchaka, xiang.zhang priority: normal severity: normal status: open title: Repr of collection's subclasses type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 05:17:35 2016 From: report at bugs.python.org (Antti Haapala) Date: Sun, 17 Jul 2016 09:17:35 +0000 Subject: [issue27507] bytearray.extend lacks overflow check when increasing buffer In-Reply-To: <1468429948.12.0.767304648411.issue27507@psf.upfronthosting.co.za> Message-ID: <1468747055.45.0.556377255705.issue27507@psf.upfronthosting.co.za> Antti Haapala added the comment: Ah indeed, this is a bytearray and it is indeed possible to theoretically allocate PY_SSIZE_T_MAX bytes, if on an architecture that does segmented memory. As for if (addition > PY_SSIZE_T_MAX - len - 1) { it is very clear to *us* but it is not quite self-documenting on why to do it this way to someone who doesn't know undefined behaviours in C (hint: next to no one knows, judging from the amount of complaints that the GCC "bug" received), instead of say if (INT_ADD_OVERFLOW(len, addition)) Where the INT_ADD_OVERFLOW would have a comment above explaining why it has to be done that way. But more discussion about it at https://bugs.python.org/issue1621 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 05:30:26 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 17 Jul 2016 09:30:26 +0000 Subject: [issue27541] Repr of collection's subclasses In-Reply-To: <1468745676.7.0.929499219743.issue27541@psf.upfronthosting.co.za> Message-ID: <1468747826.6.0.468807198338.issue27541@psf.upfronthosting.co.za> Xiang Zhang added the comment: How about other built-in classes? If repr does matter, maybe str, int, dict should also respect this rule? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 05:52:31 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 Jul 2016 09:52:31 +0000 Subject: [issue27419] Bugs in PyImport_ImportModuleLevelObject In-Reply-To: <1467275301.6.0.860119433525.issue27419@psf.upfronthosting.co.za> Message-ID: <20160717095228.31697.46028.AE3E0863@psf.io> Roundup Robot added the comment: New changeset c88ec1bb67d0 by Serhiy Storchaka in branch '3.5': Issue #27419: Standard __import__() no longer look up "__import__" in globals https://hg.python.org/cpython/rev/c88ec1bb67d0 New changeset d87f99e297d5 by Serhiy Storchaka in branch 'default': Issue #27419: Standard __import__() no longer look up "__import__" in globals https://hg.python.org/cpython/rev/d87f99e297d5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 06:00:55 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 Jul 2016 10:00:55 +0000 Subject: [issue27541] Repr of collection's subclasses In-Reply-To: <1468745676.7.0.929499219743.issue27541@psf.upfronthosting.co.za> Message-ID: <1468749655.29.0.991701852942.issue27541@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This can break third-party code. For example the code that explicitly makes the repr containing a subclass name: class MyStr(str): def __repr__(self): return 'MyStr(%s)' % str.__repr__(self) I think the chance of breaking third-party code for bytearray or deque is smaller, since the repr is not literal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 06:03:23 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 Jul 2016 10:03:23 +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: <1468749803.88.0.890440570149.issue23908@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 06:04:38 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 Jul 2016 10:04:38 +0000 Subject: [issue26984] int() can return not exact int instance In-Reply-To: <1462802551.63.0.282711121635.issue26984@psf.upfronthosting.co.za> Message-ID: <1468749878.01.0.67942929863.issue26984@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please make a review Mark? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 06:05:33 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 Jul 2016 10:05:33 +0000 Subject: [issue23782] Leak in _PyTraceback_Add In-Reply-To: <1427365502.47.0.105321888995.issue23782@psf.upfronthosting.co.za> Message-ID: <1468749933.3.0.443538062841.issue23782@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 06:12:47 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 17 Jul 2016 10:12:47 +0000 Subject: [issue27541] Repr of collection's subclasses In-Reply-To: <1468745676.7.0.929499219743.issue27541@psf.upfronthosting.co.za> Message-ID: <1468750367.24.0.936982511073.issue27541@psf.upfronthosting.co.za> Xiang Zhang added the comment: Yes. So if we are not going to change other built-in types, maybe we'd better not change bytearray either. My opinion is that don't change built-in classes, even bytearray. If users would like a more reasonable repr, they can provide a custom __repr__ as your example. But make such changes to classes in collections sounds like a good idea to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 06:26:32 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 Jul 2016 10:26:32 +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: <20160717102629.80366.30346.3332D704@psf.io> Roundup Robot added the comment: New changeset efd4ffa88173 by Serhiy Storchaka in branch '3.5': Issues #23147, #23148: Presumably fixed bugs in folding UnstructuredTokenList. https://hg.python.org/cpython/rev/efd4ffa88173 New changeset 33593fcdf8b0 by Serhiy Storchaka in branch 'default': Issues #23147, #23148: Presumably fixed bugs in folding UnstructuredTokenList. https://hg.python.org/cpython/rev/33593fcdf8b0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 06:26:32 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 Jul 2016 10:26:32 +0000 Subject: [issue23147] Possible error in _header_value_parser.py In-Reply-To: <1420194679.08.0.467668822135.issue23147@psf.upfronthosting.co.za> Message-ID: <20160717102629.80366.7120.5FC31385@psf.io> Roundup Robot added the comment: New changeset efd4ffa88173 by Serhiy Storchaka in branch '3.5': Issues #23147, #23148: Presumably fixed bugs in folding UnstructuredTokenList. https://hg.python.org/cpython/rev/efd4ffa88173 New changeset 33593fcdf8b0 by Serhiy Storchaka in branch 'default': Issues #23147, #23148: Presumably fixed bugs in folding UnstructuredTokenList. https://hg.python.org/cpython/rev/33593fcdf8b0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 06:43:29 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 17 Jul 2016 10:43:29 +0000 Subject: [issue27419] Bugs in PyImport_ImportModuleLevelObject In-Reply-To: <1467275301.6.0.860119433525.issue27419@psf.upfronthosting.co.za> Message-ID: <1468752209.39.0.20143835888.issue27419@psf.upfronthosting.co.za> Berker Peksag added the comment: I'm getting a segfault after d87f99e297d5 (SubinterpreterTest.test_subinterps). $ ./python -m test test_capi Run tests sequentially 0:00:00 [1/1] test_capi Fatal Python error: Segmentation fault Current thread 0x00007fd5e401d700 (most recent call first): File "/home/berker/projects/cpython/default/Lib/test/support/__init__.py", line 2440 in run_in_subinterp File "/home/berker/projects/cpython/default/Lib/test/test_capi.py", line 337 in test_subinterps File "/home/berker/projects/cpython/default/Lib/unittest/case.py", line 600 in run File "/home/berker/projects/cpython/default/Lib/unittest/case.py", line 648 in __call__ File "/home/berker/projects/cpython/default/Lib/unittest/suite.py", line 122 in run File "/home/berker/projects/cpython/default/Lib/unittest/suite.py", line 84 in __call__ File "/home/berker/projects/cpython/default/Lib/unittest/suite.py", line 122 in run File "/home/berker/projects/cpython/default/Lib/unittest/suite.py", line 84 in __call__ File "/home/berker/projects/cpython/default/Lib/unittest/suite.py", line 122 in run File "/home/berker/projects/cpython/default/Lib/unittest/suite.py", line 84 in __call__ File "/home/berker/projects/cpython/default/Lib/test/support/__init__.py", line 1704 in run File "/home/berker/projects/cpython/default/Lib/test/support/__init__.py", line 1805 in _run_suite File "/home/berker/projects/cpython/default/Lib/test/support/__init__.py", line 1839 in run_unittest File "/home/berker/projects/cpython/default/Lib/test/libregrtest/runtest.py", line 179 in test_runner File "/home/berker/projects/cpython/default/Lib/test/libregrtest/runtest.py", line 180 in runtest_inner File "/home/berker/projects/cpython/default/Lib/test/libregrtest/runtest.py", line 144 in runtest File "/home/berker/projects/cpython/default/Lib/test/libregrtest/main.py", line 334 in run_tests_sequential File "/home/berker/projects/cpython/default/Lib/test/libregrtest/main.py", line 406 in run_tests File "/home/berker/projects/cpython/default/Lib/test/libregrtest/main.py", line 466 in _main File "/home/berker/projects/cpython/default/Lib/test/libregrtest/main.py", line 446 in main File "/home/berker/projects/cpython/default/Lib/test/libregrtest/main.py", line 508 in main File "/home/berker/projects/cpython/default/Lib/test/__main__.py", line 2 in File "/home/berker/projects/cpython/default/Lib/runpy.py", line 85 in _run_code File "/home/berker/projects/cpython/default/Lib/runpy.py", line 184 in _run_module_as_main Segmentation fault (core dumped) See also http://buildbot.python.org/all/builders/s390x%20RHEL%203.x/builds/1387/steps/test/logs/stdio for the same failure on buildbots. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 07:16:34 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 Jul 2016 11:16:34 +0000 Subject: [issue27419] Bugs in PyImport_ImportModuleLevelObject In-Reply-To: <1467275301.6.0.860119433525.issue27419@psf.upfronthosting.co.za> Message-ID: <20160717111629.22644.76083.824B4D0E@psf.io> Roundup Robot added the comment: New changeset 4c07faa33915 by Serhiy Storchaka in branch '3.5': Issue #27419: Added temporary workaround for subinterpreters. https://hg.python.org/cpython/rev/4c07faa33915 New changeset 5540234ca517 by Serhiy Storchaka in branch 'default': Issue #27419: Added temporary workaround for subinterpreters. https://hg.python.org/cpython/rev/5540234ca517 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 07:20:46 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 Jul 2016 11:20:46 +0000 Subject: [issue27419] Bugs in PyImport_ImportModuleLevelObject In-Reply-To: <1467275301.6.0.860119433525.issue27419@psf.upfronthosting.co.za> Message-ID: <1468754446.56.0.515606924291.issue27419@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Added temporary workaround to make buildbots working. The bug is partially reappeared in __import__ in subinterpreter. I think this is better than reverting all patches. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 07:31:26 2016 From: report at bugs.python.org (Julien) Date: Sun, 17 Jul 2016 11:31:26 +0000 Subject: [issue27542] Segfault in gcmodule.c:360 visit_decref Message-ID: <1468755086.8.0.27245311458.issue27542@psf.upfronthosting.co.za> New submission from Julien: Was running `python -m pip install ansible` when I got a "segmentation fault". bt is: (gdb) bt #0 0x00000000004a7ec4 in visit_decref () at ../Modules/gcmodule.c:360 #1 0x00000000004a7fa9 in dict_traverse () at ../Objects/dictobject.c:2144 #2 0x00000000004a6f88 in subtract_refs () at ../Modules/gcmodule.c:385 #3 collect.lto_priv () at ../Modules/gcmodule.c:925 #4 0x0000000000500d2e in PyGC_Collect () at ../Modules/gcmodule.c:1440 #5 0x0000000000500184 in Py_Finalize () at ../Python/pythonrun.c:448 #6 0x0000000000525148 in Py_Exit (sts=0) at ../Python/pythonrun.c:1783 #7 0x0000000000522553 in handle_system_exit () at ../Python/pythonrun.c:1151 #8 0x0000000000521e46 in PyErr_PrintEx () at ../Python/pythonrun.c:1161 #9 0x0000000000520dc9 in RunModule.lto_priv.1258 () at ../Modules/main.c:194 #10 0x000000000049de26 in Py_Main () at ../Modules/main.c:587 #11 0x00007fddb03e25f0 in __libc_start_main (main=0x49d710
, argc=6, argv=0x7ffdfcb8cfe8, init=, fini=, rtld_fini=, stack_end=0x7ffdfcb8cfd8) at libc-start.c:291 #12 0x000000000049d639 in _start () Problem looks obvious: (gdb) p (((PyObject*)(op))->ob_type) $86202 = (struct _typeobject *) 0x0 But `subtract_refs()` from `Modules/gcmodule.c:385` is iterating a very long chained list, and I'm not sure it's of any help iterating over it. Can provide core dump if of any help. Python version: Python 2.7.12 PIP version: pip 8.1.2 from /usr/lib/python2.7/dist-packages (python 2.7) Looks reproductible: ``` $ python -m pip install --user ansible Collecting ansible Collecting jinja2 (from ansible) Using cached Jinja2-2.8-py2.py3-none-any.whl Collecting setuptools (from ansible) Using cached setuptools-24.0.3-py2.py3-none-any.whl Collecting PyYAML (from ansible) Collecting pycrypto>=2.6 (from ansible) Collecting paramiko (from ansible) Using cached paramiko-2.0.1-py2.py3-none-any.whl Collecting MarkupSafe (from jinja2->ansible) Collecting cryptography>=1.1 (from paramiko->ansible) Collecting pyasn1>=0.1.7 (from paramiko->ansible) Using cached pyasn1-0.1.9-py2.py3-none-any.whl Collecting enum34 (from cryptography>=1.1->paramiko->ansible) Using cached enum34-1.1.6-py2-none-any.whl Collecting idna>=2.0 (from cryptography>=1.1->paramiko->ansible) Using cached idna-2.1-py2.py3-none-any.whl Collecting cffi>=1.4.1 (from cryptography>=1.1->paramiko->ansible) Using cached cffi-1.7.0-cp27-cp27mu-manylinux1_x86_64.whl Collecting ipaddress (from cryptography>=1.1->paramiko->ansible) Using cached ipaddress-1.0.16-py27-none-any.whl Collecting six>=1.4.1 (from cryptography>=1.1->paramiko->ansible) Using cached six-1.10.0-py2.py3-none-any.whl Collecting pycparser (from cffi>=1.4.1->cryptography>=1.1->paramiko->ansible) Installing collected packages: MarkupSafe, jinja2, setuptools, PyYAML, pycrypto, enum34, idna, pycparser, cffi, ipaddress, six, pyasn1, cryptography, paramiko, ansible Successfully installed MarkupSafe-0.23 PyYAML-3.11 ansible-2.1.0.0 cffi-1.7.0 cryptography-1.4 enum34-1.1.6 idna-2.1 ipaddress-1.0.16 jinja2-2.8 paramiko-2.0.1 pyasn1-0.1.9 pycparser-2.14 pycrypto-2.6.1 setuptools-24.0.3 six-1.10.0 Segmentation fault (core dumped) ``` I tried installing only a few packages to see if one in particular causes the bug and yes, cffi may be the one: ``` $ python -m pip install --user cffi Collecting cffi Using cached cffi-1.7.0-cp27-cp27mu-manylinux1_x86_64.whl Collecting pycparser (from cffi) Installing collected packages: pycparser, cffi Successfully installed cffi-1.7.0 pycparser-2.14 Segmentation fault (core dumped) ``` But not pycparser alone: ``` $ python -m pip install --user pycparser Collecting pycparser Installing collected packages: pycparser Successfully installed pycparser-2.14 ``` ---------- components: Interpreter Core messages: 270633 nosy: sizeof priority: normal severity: normal status: open title: Segfault in gcmodule.c:360 visit_decref versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 08:14:09 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 Jul 2016 12:14:09 +0000 Subject: [issue26974] Crash in Decimal.from_float In-Reply-To: <1462684427.76.0.86950702335.issue26974@psf.upfronthosting.co.za> Message-ID: <20160717121405.111471.69428.187AA536@psf.io> Roundup Robot added the comment: New changeset f8cb955efd6a by Stefan Krah in branch '3.5': Issue #26974: Fix segfault in the presence of absurd subclassing. Proactively https://hg.python.org/cpython/rev/f8cb955efd6a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 08:20:16 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 Jul 2016 12:20:16 +0000 Subject: [issue26974] Crash in Decimal.from_float In-Reply-To: <1462684427.76.0.86950702335.issue26974@psf.upfronthosting.co.za> Message-ID: <1468758016.66.0.07114886091.issue26974@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Couldn't keeping references in static variables cause problems in subinterpreters? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 08:26:40 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 Jul 2016 12:26:40 +0000 Subject: [issue27531] Documentation for assert_not_called() has wrong signature In-Reply-To: <1468692002.86.0.178541373215.issue27531@psf.upfronthosting.co.za> Message-ID: <20160717122631.31697.4201.5E6286DB@psf.io> Roundup Robot added the comment: New changeset b43f61118793 by Berker Peksag in branch '3.5': Issue #27531: Update signature of Mock.assert_not_called method https://hg.python.org/cpython/rev/b43f61118793 New changeset f4541c56c353 by Berker Peksag in branch 'default': Issue #27531: Merge from 3.5 https://hg.python.org/cpython/rev/f4541c56c353 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 08:27:23 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 17 Jul 2016 12:27:23 +0000 Subject: [issue27531] Documentation for assert_not_called() has wrong signature In-Reply-To: <1468692002.86.0.178541373215.issue27531@psf.upfronthosting.co.za> Message-ID: <1468758443.01.0.812924913985.issue27531@psf.upfronthosting.co.za> Berker Peksag added the comment: Good catch, thanks Michael! ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 08:41:53 2016 From: report at bugs.python.org (Stefan Krah) Date: Sun, 17 Jul 2016 12:41:53 +0000 Subject: [issue26974] Crash in Decimal.from_float In-Reply-To: <1462684427.76.0.86950702335.issue26974@psf.upfronthosting.co.za> Message-ID: <1468759313.81.0.228846481781.issue26974@psf.upfronthosting.co.za> Stefan Krah added the comment: These are builtin static types. Even with non-builtin static types, the address of the type should always be the same. C-extensions aren't reloaded. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 08:50:12 2016 From: report at bugs.python.org (Stefan Krah) Date: Sun, 17 Jul 2016 12:50:12 +0000 Subject: [issue26974] Crash in Decimal.from_float In-Reply-To: <1462684427.76.0.86950702335.issue26974@psf.upfronthosting.co.za> Message-ID: <1468759812.5.0.0654996064226.issue26974@psf.upfronthosting.co.za> Stefan Krah added the comment: Also, IMO the whole capsule mechanism would be broken if function pointers in dynamic libs could just be invalidated due to reloading. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 08:50:26 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 17 Jul 2016 12:50:26 +0000 Subject: [issue27487] -m switch regression in Python 3.5.2 (under rare circumstances) In-Reply-To: <1468268291.19.0.631980361837.issue27487@psf.upfronthosting.co.za> Message-ID: <1468759826.23.0.242060350814.issue27487@psf.upfronthosting.co.za> Nick Coghlan added the comment: Running pre-imported top level packages like "runpy" or "site" with "-m" is supported behaviour, so that shouldn't emit a warning. ("python -m site" in particular is a debugging tool used to print out the default sys.path configuration) Otherwise, the warning mostly looks good to me, except I'd suggest either dropping the word "any" from "any parent packages", or else replacing it with the word "all" (since the key point to be conveyed is that by the time the module starts executing and this check is made, all the parent packages have already been imported, thus triggering their side effects, if any). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 08:54:41 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 17 Jul 2016 12:54:41 +0000 Subject: [issue27541] Repr of collection's subclasses In-Reply-To: <1468745676.7.0.929499219743.issue27541@psf.upfronthosting.co.za> Message-ID: <1468760081.48.0.0837726098857.issue27541@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 09:03:36 2016 From: report at bugs.python.org (Stefan Krah) Date: Sun, 17 Jul 2016 13:03:36 +0000 Subject: [issue26974] Crash in Decimal.from_float In-Reply-To: <1462684427.76.0.86950702335.issue26974@psf.upfronthosting.co.za> Message-ID: <1468760616.59.0.105962434719.issue26974@psf.upfronthosting.co.za> Stefan Krah added the comment: I'm leaving this open in case anyone wants to do something about the Python version. I tend to agree with Raymond: It is impractical to "fix" all such constructs in the Python version, unless one consistently uses a style like: float.as_integer_ratio(float.__abs__(-1.5)) ---------- resolution: -> fixed stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 10:27:19 2016 From: report at bugs.python.org (Martin Teichmann) Date: Sun, 17 Jul 2016 14:27:19 +0000 Subject: [issue23722] During metaclass.__init__, super() of the constructed class does not work In-Reply-To: <1426859061.43.0.510286082444.issue23722@psf.upfronthosting.co.za> Message-ID: <1468765639.68.0.88932700909.issue23722@psf.upfronthosting.co.za> Martin Teichmann added the comment: Currently, a class is created as follows: the compiler turns the class statement into a call to __build_class__. This runs the class body. If __class__ or super() is used within a method of the class, an empty PyCell is created, to be filled later with the class once its done. The class body returns this cell. Then the metaclass is called to create the actual class, and finally the cell is set to whatever the metaclass returns. This has the disadvantage that in the metaclasses __new__ and __init__, __class__ and super() are not set. This is a pity, especially because the two parameter version of super() doesn't work either, as the class is not yet bound to a name. The attached patch lets the compiler add said cell as __classcell__ to the classes namespace, where it will later be taken out by type.__new__ in order to be properly filled. This resembles the approach used for __qualname__, with the difference that __qualname__ is already added at the beginning of the classes body, such that it is visible to the user. This way __class__ will be properly set immediately after it is created, thus all methods are immediately usable, already in a metaclasses __new__ or __init__. This changes the behavior if a metaclass returns another class. currently, __build_class__ will try to set the __class__ in the methods of the class body to whatever __new__ returns, which might be completely unrelated to the classes body. ---------- keywords: +patch Added file: http://bugs.python.org/file43765/pep487.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 10:27:35 2016 From: report at bugs.python.org (Martin Teichmann) Date: Sun, 17 Jul 2016 14:27:35 +0000 Subject: [issue23722] During metaclass.__init__, super() of the constructed class does not work In-Reply-To: <1426859061.43.0.510286082444.issue23722@psf.upfronthosting.co.za> Message-ID: <1468765655.09.0.513403795304.issue23722@psf.upfronthosting.co.za> Changes by Martin Teichmann : Removed file: http://bugs.python.org/file38604/patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 11:02:53 2016 From: report at bugs.python.org (R. David Murray) Date: Sun, 17 Jul 2016 15:02:53 +0000 Subject: [issue27533] release GIL in nt._isdir In-Reply-To: <1468700034.79.0.260183682177.issue27533@psf.upfronthosting.co.za> Message-ID: <1468767773.88.0.52719171237.issue27533@psf.upfronthosting.co.za> R. David Murray added the comment: Correct, 2.7 is not in security fix only mode (yet), but new features (anything that changes an API) or bug fixes that we wouldn't put in a maintenance release (things that would break existing programs) are not allowed. A special exception has been made for 2.7 for performance enhancements; we wouldn't normally do those in a maintenance release unless they were significant. But as Steve says, it depends on a core developer being interested in applying the fix/backport. Which we may have, we'll wait and see :) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 11:11:14 2016 From: report at bugs.python.org (R. David Murray) Date: Sun, 17 Jul 2016 15:11:14 +0000 Subject: [issue27535] Memory leaks when opening tons of files In-Reply-To: <1468720423.06.0.361257976034.issue27535@psf.upfronthosting.co.za> Message-ID: <1468768274.48.0.945438598099.issue27535@psf.upfronthosting.co.za> R. David Murray added the comment: I recommend rejecting this. Properly closing flies is the correct programming habit, which is why the ResourceWarning exists. The Pillow example seems to just indicate that people using Pillow need to pay attention to the ResourceWarning and close the files they open with pillow. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 11:14:52 2016 From: report at bugs.python.org (R. David Murray) Date: Sun, 17 Jul 2016 15:14:52 +0000 Subject: [issue27525] Wrong OS header on file created by gzip module In-Reply-To: <1468617293.43.0.813584223225.issue27525@psf.upfronthosting.co.za> Message-ID: <1468768492.13.0.767638160924.issue27525@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> rejected stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 11:21:22 2016 From: report at bugs.python.org (R. David Murray) Date: Sun, 17 Jul 2016 15:21:22 +0000 Subject: [issue27538] Segfault on error in code object checking In-Reply-To: <1468736213.35.0.202003298623.issue27538@psf.upfronthosting.co.za> Message-ID: <1468768882.81.0.872164512766.issue27538@psf.upfronthosting.co.za> R. David Murray added the comment: I don't think this is a bug. You can construct whatever code object you like; it is your responsibility at that point to make sure it is correct. This is an example of why we call Python a "consenting adults" language. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 11:30:29 2016 From: report at bugs.python.org (R. David Murray) Date: Sun, 17 Jul 2016 15:30:29 +0000 Subject: [issue27541] Repr of collection's subclasses In-Reply-To: <1468745676.7.0.929499219743.issue27541@psf.upfronthosting.co.za> Message-ID: <1468769429.16.0.131095528654.issue27541@psf.upfronthosting.co.za> R. David Murray added the comment: It certainly seems that collections should be consistent about this. The question of builtin types is a different issue, and I agree that it is probably way more trouble than it is worth to change them, especially since, for example, repr(str) is often used just to get the quote marks in contexts where you *don't* want the subclass name. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 11:32:58 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 Jul 2016 15:32:58 +0000 Subject: [issue27535] Memory leaks when opening tons of files In-Reply-To: <1468720423.06.0.361257976034.issue27535@psf.upfronthosting.co.za> Message-ID: <1468769578.93.0.629373710364.issue27535@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thus, the problem is that even ignored warnings are saved. If there is a simple fix of this problem we can fix it. But if there is no simple and straightforward way, it may be not worth to complicate the code for such case. I'll look at the code. ---------- assignee: -> serhiy.storchaka priority: normal -> low versions: +Python 3.6 -Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 11:50:26 2016 From: report at bugs.python.org (Eryk Sun) Date: Sun, 17 Jul 2016 15:50:26 +0000 Subject: [issue27540] msvcrt.ungetwch() calls _ungetch() In-Reply-To: <1468745012.08.0.321893951317.issue27540@psf.upfronthosting.co.za> Message-ID: <1468770626.71.0.512017465865.issue27540@psf.upfronthosting.co.za> Eryk Sun added the comment: Parsing the argument is also broken: static PyObject * msvcrt_ungetwch(PyObject *self, PyObject *args) { Py_UNICODE ch; if (!PyArg_ParseTuple(args, "u:ungetwch", &ch)) return NULL; if (_ungetch(ch) == EOF) return PyErr_SetFromErrno(PyExc_IOError); Py_INCREF(Py_None); return Py_None; } Format "u" is a `Py_UNICODE *`. There's no "C" format code in 2.x, so it will first have to check that the string length is exactly 1 and then use index 0. ---------- components: +Windows nosy: +eryksun, paul.moore, steve.dower, tim.golden, zach.ware stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 12:10:56 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 17 Jul 2016 16:10:56 +0000 Subject: [issue27538] Segfault on error in code object checking In-Reply-To: <1468736213.35.0.202003298623.issue27538@psf.upfronthosting.co.za> Message-ID: <1468771856.96.0.328101893714.issue27538@psf.upfronthosting.co.za> Ned Deily added the comment: I agree with RDM. CPython makes no guarantee that you can't crash the interpreter if you really try to. "Consenting adult" means we don't impose performance penalties on everyone just to protect some users from their own attempts to exploit edge cases. ---------- nosy: +ned.deily resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 12:20:14 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 Jul 2016 16:20:14 +0000 Subject: [issue27541] Repr of collection's subclasses In-Reply-To: <1468745676.7.0.929499219743.issue27541@psf.upfronthosting.co.za> Message-ID: <1468772414.99.0.0513025761293.issue27541@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It looks to me that the repr of a collection contains a dynamic name if it is implemented in Python and hardcoded base name if it is implemented in C (OrderedDict originally was implemented in Python). Maybe just because tp_name contains full qualified name, and extracting a bare class name needs few lines of code. There is similar issue with the io module classes: issue21861. Since this problem is already solved for OrderedDict, I think it is easy to use this solution in other classes. Maybe factoring out the following code into helper function. const char *classname; classname = strrchr(Py_TYPE(self)->tp_name, '.'); if (classname == NULL) classname = Py_TYPE(self)->tp_name; else classname++; ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 12:23:52 2016 From: report at bugs.python.org (Martin Teichmann) Date: Sun, 17 Jul 2016 16:23:52 +0000 Subject: [issue23722] During metaclass.__init__, super() of the constructed class does not work In-Reply-To: <1426859061.43.0.510286082444.issue23722@psf.upfronthosting.co.za> Message-ID: <1468772632.67.0.0876329341568.issue23722@psf.upfronthosting.co.za> Changes by Martin Teichmann : Removed file: http://bugs.python.org/file43765/pep487.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 12:25:01 2016 From: report at bugs.python.org (Martin Teichmann) Date: Sun, 17 Jul 2016 16:25:01 +0000 Subject: [issue23722] During metaclass.__init__, super() of the constructed class does not work In-Reply-To: <1426859061.43.0.510286082444.issue23722@psf.upfronthosting.co.za> Message-ID: <1468772701.1.0.183790936741.issue23722@psf.upfronthosting.co.za> Changes by Martin Teichmann : Added file: http://bugs.python.org/file43766/pep487.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 13:01:07 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 17 Jul 2016 17:01:07 +0000 Subject: [issue27538] Segfault on error in code object checking In-Reply-To: <1468736213.35.0.202003298623.issue27538@psf.upfronthosting.co.za> Message-ID: <1468774867.42.0.819626966038.issue27538@psf.upfronthosting.co.za> Ned Deily added the comment: Let me add that, in principle, no one is opposed to making Python more fault-tolerant, certainly if there are demonstrable cases where the behavior can be exploited to deny services to others. Cases like this, where it would seem that exploiters could only deny service to themselves, are much less interesting. If someone were to submit a patch with tests and with benchmarking to show that the fix has minimal performance implications, a core developer might be inclined to review it. But that seems like a lot of work for little gain when there are far more important problems that need attention. Hence "consenting adults". ---------- resolution: not a bug -> wont fix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 13:15:26 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 17 Jul 2016 17:15:26 +0000 Subject: [issue26662] configure/Makefile doesn't check if "python" command works, needed to build Objects/typeslots.inc In-Reply-To: <1459247902.98.0.893274525942.issue26662@psf.upfronthosting.co.za> Message-ID: <1468775725.99.0.402113522288.issue26662@psf.upfronthosting.co.za> Xavier de Gaye added the comment: This patch follows the first mechanism listed by Martin. The change in configure.ac fixes the problem described by Victor, it does not generate an empty Objects/typeslots.inc file when python is not found that would cause the cryptic " : invalid slot offset" errors on subsequent builds. The change in Objects/typeslots.py is not strictly necessary to fix the problem but prevents typeslots.py to create an invalid typeslots.inc file through the previous stdout redirection mechanism when, for example, typeslots.py is modified inadvertently with a change that is not python2 compatible and typeslots.py is run by python2 and fails. ---------- nosy: +xdegaye stage: -> patch review versions: +Python 3.5 Added file: http://bugs.python.org/file43767/py_for_gen_26662.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 13:21:29 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 17 Jul 2016 17:21:29 +0000 Subject: [issue26662] configure/Makefile doesn't check if "python" command works, needed to build Objects/typeslots.inc In-Reply-To: <1459247902.98.0.893274525942.issue26662@psf.upfronthosting.co.za> Message-ID: <1468776089.85.0.590616746263.issue26662@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Forgot to say that with the patch and no python in $PATH, the following error message is output: $ touch Include/typeslots.h $ make Cannot generate Objects/typeslots.inc, python not found ! Re-run configure with python in PATH. make: *** [Makefile:908: Objects/typeslots.inc] Error 1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 13:28:08 2016 From: report at bugs.python.org (pablo sacristan) Date: Sun, 17 Jul 2016 17:28:08 +0000 Subject: [issue27538] Segfault on error in code object checking In-Reply-To: <1468736213.35.0.202003298623.issue27538@psf.upfronthosting.co.za> Message-ID: <1468776488.08.0.00345988738889.issue27538@psf.upfronthosting.co.za> pablo sacristan added the comment: I do agree it is not a very big problem, but it is still a problem. If a python program took user input (maybe HTTP server) took user input (POST values) and construct a code object with that input. It would be possible to crash it and that can be bad for the web application. Even though it is not the most important Python problem, it is still a problem which can cause moderate problems, and it can be exploited remotely if the HTTP server did what I said before. One vulnerable HTTP server is one too many ;) Hope it helps :) ---------- resolution: wont fix -> remind status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 13:38:12 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 Jul 2016 17:38:12 +0000 Subject: [issue27538] Segfault on error in code object checking In-Reply-To: <1468736213.35.0.202003298623.issue27538@psf.upfronthosting.co.za> Message-ID: <1468777092.48.0.937854422899.issue27538@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If you construct a code object with user input without a checking, the segfault is the least of your problems. The user can inject a code that formats your hard disk or steals your passwords. It is impossible to write general checker that accepts all legitimate bytecode, but rejects malicious bytecode. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 13:43:41 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 17 Jul 2016 17:43:41 +0000 Subject: [issue27538] Segfault on error in code object checking In-Reply-To: <1468736213.35.0.202003298623.issue27538@psf.upfronthosting.co.za> Message-ID: <1468777421.81.0.502607447418.issue27538@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- resolution: remind -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 13:48:44 2016 From: report at bugs.python.org (pablo sacristan) Date: Sun, 17 Jul 2016 17:48:44 +0000 Subject: [issue27538] Segfault on error in code object checking In-Reply-To: <1468736213.35.0.202003298623.issue27538@psf.upfronthosting.co.za> Message-ID: <1468777724.14.0.907306002154.issue27538@psf.upfronthosting.co.za> pablo sacristan added the comment: Yes, but it is possible to blacklist some bytecode (it may be possible to blacklist all or almost all malicious bytecode) and even more if the attacker just wants to crash the target then the segfault would be an easy crash. It is still an attack scenario that is possible. Hope it helps :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 14:04:43 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 17 Jul 2016 18:04:43 +0000 Subject: [issue27542] Segfault in gcmodule.c:360 visit_decref In-Reply-To: <1468755086.8.0.27245311458.issue27542@psf.upfronthosting.co.za> Message-ID: <1468778683.4.0.0756904480145.issue27542@psf.upfronthosting.co.za> Ned Deily added the comment: Try installing cffi from source rather than using the pre-compiled wheel: python -m pip uninstall cffi python -m pip install -v --no-use-wheel --user cffi If that works, there could be an incompatibility between the Python 2.7.12 you are using and the C extensions in the wheel. What platform are you on and what is the source of the Python 2.7? ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 14:14:01 2016 From: report at bugs.python.org (Marc) Date: Sun, 17 Jul 2016 18:14:01 +0000 Subject: [issue27543] from module import function creates package reference to the module Message-ID: <1468779241.06.0.301525903069.issue27543@psf.upfronthosting.co.za> New submission from Marc: Hello, I've found an issue in python 2.7 and 3.4 and I don't if this is a bug or a feature that acts strange to me. The import of a module or method from a module creates a reference in the package to that module only the first time, which could lead to unexpected behavior. Description: In following code there's one line marked with 'this line fixes the code to what I expected' 1. Without that line package.a.test() results in 'from module a' 2. With the line package.a.test() results in 'from module b' Situation 1 is unexpected because I did not create the reference to 'module a', python did that with the statement 'from package.a import test' and this will happen from any place in the code that loads 'module a' for the first time. The documentation says that this reference will not be created. Kind regards, Marc # FILES USED # # test.py # package # __init__.py # a.py # b.py # --------------------- # Content of a.py: def test(): print('from module a') # --------------------- # Content of a.py: def test(): print('from module b') # --------------------- # Content of __init__.py #import a # <--- this line fixes the code to what I expected import b as a from a import test # --------------------- # Content of test.py import package print(dir(package)) package.a.test() ---------- components: Interpreter Core messages: 270658 nosy: m.nijland priority: normal severity: normal status: open title: from module import function creates package reference to the module type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 14:14:20 2016 From: report at bugs.python.org (Julien) Date: Sun, 17 Jul 2016 18:14:20 +0000 Subject: [issue27542] Segfault in gcmodule.c:360 visit_decref In-Reply-To: <1468755086.8.0.27245311458.issue27542@psf.upfronthosting.co.za> Message-ID: <1468779260.75.0.320504099855.issue27542@psf.upfronthosting.co.za> Julien added the comment: @Ned Despite the segfault, cffi installs well, the segfault occurs during a garbage collect, very late, inside Py_Exit according to the backtrace, so it has no impact. > What platform are you on and what is the source of the Python 2.7 Debian stretch, python (and sources) 2.7.12-1 from Debian testing packages, pip 8.1.2 from Debian packages too, version 8.1.2-2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 14:21:33 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 17 Jul 2016 18:21:33 +0000 Subject: [issue27542] Segfault in gcmodule.c:360 visit_decref In-Reply-To: <1468755086.8.0.27245311458.issue27542@psf.upfronthosting.co.za> Message-ID: <1468779693.79.0.915574374065.issue27542@psf.upfronthosting.co.za> Ned Deily added the comment: It would still be interesting to know whether you see the same behavior with building from source. If a cffi extension module is invoked during the install process, it might screw things up. Otherwise, unless you can reproduce the problem with a vanilla Python 2.7.12 built from scratch, you'll probably have to pursue this with the Debian folks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 14:24:14 2016 From: report at bugs.python.org (Julien) Date: Sun, 17 Jul 2016 18:24:14 +0000 Subject: [issue27542] Segfault in gcmodule.c:360 visit_decref In-Reply-To: <1468755086.8.0.27245311458.issue27542@psf.upfronthosting.co.za> Message-ID: <1468779854.47.0.993586562938.issue27542@psf.upfronthosting.co.za> Julien added the comment: @ned Oh ok. I just tried, with `--no-use-wheel`: no segfault. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 14:28:04 2016 From: report at bugs.python.org (Stefan Krah) Date: Sun, 17 Jul 2016 18:28:04 +0000 Subject: [issue27542] Segfault in gcmodule.c:360 visit_decref In-Reply-To: <1468755086.8.0.27245311458.issue27542@psf.upfronthosting.co.za> Message-ID: <1468780084.09.0.667267908806.issue27542@psf.upfronthosting.co.za> Stefan Krah added the comment: Which makes me think that --no-use-wheel should be the default in pip ... As a Linux user I'm *very* uneasy about this whole binary wheel thing. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 14:28:59 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 Jul 2016 18:28:59 +0000 Subject: [issue27543] from module import function creates package reference to the module In-Reply-To: <1468779241.06.0.301525903069.issue27543@psf.upfronthosting.co.za> Message-ID: <1468780139.69.0.392894316392.issue27543@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +brett.cannon, eric.snow, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 14:29:29 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 17 Jul 2016 18:29:29 +0000 Subject: [issue27542] Segfault in gcmodule.c:360 visit_decref In-Reply-To: <1468755086.8.0.27245311458.issue27542@psf.upfronthosting.co.za> Message-ID: <1468780169.28.0.909130632837.issue27542@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for trying! Perhaps the first thing to do is to check with the cffi project; perhaps Armin will recognize something. I'm going to mark this issue as "closed" but feel free to re-open it if a problem with Python turns up. ---------- resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 14:41:35 2016 From: report at bugs.python.org (Julien) Date: Sun, 17 Jul 2016 18:41:35 +0000 Subject: [issue27542] Segfault in gcmodule.c:360 visit_decref In-Reply-To: <1468755086.8.0.27245311458.issue27542@psf.upfronthosting.co.za> Message-ID: <1468780895.9.0.538029897585.issue27542@psf.upfronthosting.co.za> Julien added the comment: CFFI issue, like for the record: https://bitbucket.org/cffi/cffi/issues/272/segfault-while-installing-via-pip ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 15:39:25 2016 From: report at bugs.python.org (Armin Rigo) Date: Sun, 17 Jul 2016 19:39:25 +0000 Subject: [issue27540] msvcrt.ungetwch() calls _ungetch() In-Reply-To: <1468745012.08.0.321893951317.issue27540@psf.upfronthosting.co.za> Message-ID: <1468784365.35.0.365311866418.issue27540@psf.upfronthosting.co.za> Armin Rigo added the comment: Uh, you're right. Then I can also add that putwch() strangely checks for unicode strings of length != 0 instead of == 1, despite what it says it its error message. These functions appear not to be tested or even (in case of ungetwch()) used by anyone. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 16:15:08 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 17 Jul 2016 20:15:08 +0000 Subject: [issue27535] Memory leaks when opening tons of files In-Reply-To: <1468720423.06.0.361257976034.issue27535@psf.upfronthosting.co.za> Message-ID: <1468786508.0.0.593458519249.issue27535@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I would like to see this fixed. It is rather unfortunate that a tool designed to help find possible resource leaks is itself a certain resource leak. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 19:05:16 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 17 Jul 2016 23:05:16 +0000 Subject: [issue26662] configure/Makefile doesn't check if "python" command works, needed to build Objects/typeslots.inc In-Reply-To: <1459247902.98.0.893274525942.issue26662@psf.upfronthosting.co.za> Message-ID: <1468796716.14.0.595879018519.issue26662@psf.upfronthosting.co.za> Martin Panter added the comment: The PYTHON_FOR_GEN scheme seems reasonable to me, as is changing the way typeslots script is run. I do wonder about the advice in the message. If I ran into the problem, I would probably either override PYTHON_FOR_GEN when running Make, or try something like ?make touch? instead. But that?t not a big deal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 19:52:01 2016 From: report at bugs.python.org (Brett Cannon) Date: Sun, 17 Jul 2016 23:52:01 +0000 Subject: [issue27543] from module import function creates package reference to the module In-Reply-To: <1468779241.06.0.301525903069.issue27543@psf.upfronthosting.co.za> Message-ID: <1468799521.46.0.592334249172.issue27543@psf.upfronthosting.co.za> Brett Cannon added the comment: I'm not at a computer where I can verify what you're seeing, Marc,but I should mention that at least for Python 3 your imports are wrong as you should be doing relative imports, e.g. `from . import b as a`, otherwise the imports won't work unless you're accidentally executing Python from within the directory of the package. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 19:52:53 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 17 Jul 2016 23:52:53 +0000 Subject: [issue27377] Add smarter socket.fromfd() In-Reply-To: <1466706816.6.0.72770597716.issue27377@psf.upfronthosting.co.za> Message-ID: <1468799573.49.0.783421887988.issue27377@psf.upfronthosting.co.za> Martin Panter added the comment: The Windows problem, error 10022 = WSAEINVAL from getsockname(), seems to be documented at : ?The socket has not been bound?. Regarding the SCTP problem, raising an error seems like an OS bug to me. However, according to POSIX , we cannot rely on getsockname() indicating any particular address family if the socket is unbound. So on some platforms, it seems like it will only work with bound sockets, or you have to use less-standard options like SO_PROTOCOL_INFO or SO_DOMAIN. Although SO_DOMAIN won?t help on Free BSD. The simplest solution may be to document and test that it only works with bound sockets. For the problem with SO_PROTOCOL being unsupported at run-time, I think it would be better to anticipate EINVAL now, rather than wait for someone to complain. But it is not a big deal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 20:03:40 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 18 Jul 2016 00:03:40 +0000 Subject: [issue19142] Cross-compile fails trying to execute foreign pgen on build host In-Reply-To: <1380670898.69.0.308819053325.issue19142@psf.upfronthosting.co.za> Message-ID: <1468800220.4.0.0771734220149.issue19142@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 20:24:09 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 18 Jul 2016 00:24:09 +0000 Subject: [issue27490] ARM cross-compile: pgen built without $(CFLAGS) as $(LIBRARY) dependency In-Reply-To: <1468276938.3.0.370267656827.issue27490@psf.upfronthosting.co.za> Message-ID: <1468801449.92.0.439510925674.issue27490@psf.upfronthosting.co.za> Martin Panter added the comment: I am happy to repurpose this bug to improve how code generators like pgen work if you want. Or open a separate report if you think that is best. My problem with the proposal involving PGEN_DEPS0 is that it relies on makefile syntax intended for changing filename suffixes, and it is hard to understand. I wonder if it is better to solve the problem with e.g. documentation and manually overriding it with ?make PGEN_DEP="" ?. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 20:30:23 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 18 Jul 2016 00:30:23 +0000 Subject: [issue27543] from module import function creates package reference to the module In-Reply-To: <1468779241.06.0.301525903069.issue27543@psf.upfronthosting.co.za> Message-ID: <1468801823.91.0.969142609412.issue27543@psf.upfronthosting.co.za> R. David Murray added the comment: The same example can be constructed for python3 by modifying the imports. I think what is happening here is that if a has not yet been imported, then when 'from .a import test' is done, the import machinery loads a and then defines 'a' in the local namespace, overriding the previous 'import package.b as a'. On the other hand, if a has already been imported, the import machinery finds 'a' in sys.modules and skips the import-and-set-name-in-local-namespace step. IMO the bug is that 'a' gets set at all when 'from a import test' is done, but the fact that it does so has a long history. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 21:25:16 2016 From: report at bugs.python.org (hannah) Date: Mon, 18 Jul 2016 01:25:16 +0000 Subject: [issue27544] Document checking dict types Message-ID: <1468805116.02.0.14575319212.issue27544@psf.upfronthosting.co.za> New submission from hannah: While there is documentation that dict.keys(), dict.values(), and dict.items() are now view objects(https://docs.python.org/3/library/stdtypes.html#dict-views), there's no mention dictviews, dict_keys, dict_values, and dict_items not being built-ins. This is confusing because type(dict.keys()) returns dict_keys, type(dict.values()) returns dict_values, etc., and the documentation uses `dictview` as the object signature, and so it's unclear how to do object introspection on dictview objects. The #python-dev channel suggested that the canonical way to do the object introspection is to use the collections.abc.mapview types; the documentation for dicts should reflect this (and that dictview and the rest are not __builtin__ types/in the python namspace). ---------- assignee: docs at python components: Documentation messages: 270672 nosy: docs at python, story645 priority: normal severity: normal status: open title: Document checking dict types type: enhancement versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 21:26:43 2016 From: report at bugs.python.org (hannah) Date: Mon, 18 Jul 2016 01:26:43 +0000 Subject: [issue27544] documentiona of dict view types In-Reply-To: <1468805116.02.0.14575319212.issue27544@psf.upfronthosting.co.za> Message-ID: <1468805203.16.0.785982824563.issue27544@psf.upfronthosting.co.za> Changes by hannah : ---------- title: Document checking dict types -> documentiona of dict view types _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 21:38:59 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 18 Jul 2016 01:38:59 +0000 Subject: [issue8238] Proxy handling very slow In-Reply-To: <1269588795.92.0.67904846936.issue8238@psf.upfronthosting.co.za> Message-ID: <1468805939.69.0.689369092173.issue8238@psf.upfronthosting.co.za> Martin Panter added the comment: If this is still a problem, you should narrow down what is causing the slowdown. If you interrupt it, what is the stack trace? My best guess is perhaps there is a bypass hostname setting and a slow or failing DNS lookup. A call to urllib.proxy_bypass() was added in 2.6.4 for Issue 6894, and in 2.6.5 the Windows registry implementation called gethostname() and gethostbyname(). Perhaps this is fixed by Issue 1648102. ---------- components: +Windows -None nosy: +martin.panter, paul.moore, steve.dower, tim.golden, zach.ware status: open -> pending superseder: -> proxy_bypass in urllib handling of macro title: Proxy handling -> Proxy handling very slow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 21:41:17 2016 From: report at bugs.python.org (Emanuel Barry) Date: Mon, 18 Jul 2016 01:41:17 +0000 Subject: [issue27544] documentiona of dict view types In-Reply-To: <1468805116.02.0.14575319212.issue27544@psf.upfronthosting.co.za> Message-ID: <1468806077.68.0.710648358356.issue27544@psf.upfronthosting.co.za> Emanuel Barry added the comment: "The #python-dev channel" being me in this context ;) Patch attached. ---------- keywords: +patch nosy: +ebarry stage: -> patch review Added file: http://bugs.python.org/file43768/dict_view_doc_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 21:43:08 2016 From: report at bugs.python.org (Emanuel Barry) Date: Mon, 18 Jul 2016 01:43:08 +0000 Subject: [issue27544] Document the ABCs for instance/subclass checks of dict view types In-Reply-To: <1468805116.02.0.14575319212.issue27544@psf.upfronthosting.co.za> Message-ID: <1468806188.91.0.583512192059.issue27544@psf.upfronthosting.co.za> Changes by Emanuel Barry : ---------- title: documentiona of dict view types -> Document the ABCs for instance/subclass checks of dict view types _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 22:16:32 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 18 Jul 2016 02:16:32 +0000 Subject: [issue23722] During metaclass.__init__, super() of the constructed class does not work In-Reply-To: <1426859061.43.0.510286082444.issue23722@psf.upfronthosting.co.za> Message-ID: <1468808192.17.0.516843591127.issue23722@psf.upfronthosting.co.za> Guido van Rossum added the comment: I don't think this requires adding it to the PEP, and I think doing this is fine. (But I can't review the code.) ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 22:36:15 2016 From: report at bugs.python.org (Brett Cannon) Date: Mon, 18 Jul 2016 02:36:15 +0000 Subject: [issue27543] from module import function creates package reference to the module In-Reply-To: <1468779241.06.0.301525903069.issue27543@psf.upfronthosting.co.za> Message-ID: <1468809375.06.0.740209106884.issue27543@psf.upfronthosting.co.za> Brett Cannon added the comment: So the problem is that you doing `from .a import test` and not `from . import a; test = a.test`. Whenever you do `from X import Y`, import actually imports X. Since X wasn't in sys.modules, it performs a proper import which means it sets the attribute on the package accordingly. But had Y been what you were after, then import simply looks for the Y attribute on the package instead of doing a full import. IOW everything is working as expected (and I still wish people weren't allowed to import objects out of modules directly). ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 23:08:09 2016 From: report at bugs.python.org (Decorater) Date: Mon, 18 Jul 2016 03:08:09 +0000 Subject: [issue27545] missing pyshellext.vcxproj prevents puilding 3.6 Message-ID: <1468811289.51.0.698571569689.issue27545@psf.upfronthosting.co.za> New submission from Decorater: I have a issue with building 3.6 now since I got the last hg update it seems the github repo is broken too. This does need a fix. ---------- components: Build messages: 270677 nosy: Decorater priority: normal severity: normal status: open title: missing pyshellext.vcxproj prevents puilding 3.6 type: compile error versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 23:20:05 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 18 Jul 2016 03:20:05 +0000 Subject: [issue27545] missing pyshellext.vcxproj prevents puilding 3.6 In-Reply-To: <1468811289.51.0.698571569689.issue27545@psf.upfronthosting.co.za> Message-ID: <1468812005.5.0.630984406003.issue27545@psf.upfronthosting.co.za> Xiang Zhang added the comment: Could you post the error message and your platform? I just tried and everything went fine. ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 23:24:22 2016 From: report at bugs.python.org (Decorater) Date: Mon, 18 Jul 2016 03:24:22 +0000 Subject: [issue27545] missing pyshellext.vcxproj prevents puilding 3.6 In-Reply-To: <1468811289.51.0.698571569689.issue27545@psf.upfronthosting.co.za> Message-ID: <1468812262.0.0.0882438704118.issue27545@psf.upfronthosting.co.za> Decorater added the comment: I am using Win32 and x64 configurations and this is the error: E:\Users\Elsword\Desktop\DecoraterBot\Async\DecoraterBot-indev\python36-indev\c python\PCbuild\pcbuild.proj(78,5): error MSB3202: The project file "pyshellext. vcxproj" was not found. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 23:37:21 2016 From: report at bugs.python.org (Decorater) Date: Mon, 18 Jul 2016 03:37:21 +0000 Subject: [issue27545] missing pyshellext.vcxproj prevents puilding 3.6 In-Reply-To: <1468811289.51.0.698571569689.issue27545@psf.upfronthosting.co.za> Message-ID: <1468813041.2.0.307318968154.issue27545@psf.upfronthosting.co.za> Decorater added the comment: Also I am using the windows target OS on it as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 23:43:47 2016 From: report at bugs.python.org (Eryk Sun) Date: Mon, 18 Jul 2016 03:43:47 +0000 Subject: [issue27545] missing pyshellext.vcxproj prevents puilding 3.6 In-Reply-To: <1468811289.51.0.698571569689.issue27545@psf.upfronthosting.co.za> Message-ID: <1468813427.4.0.325612980359.issue27545@psf.upfronthosting.co.za> Eryk Sun added the comment: Steve committed part of the update for the new shell extension DLL in changeset 6b0023810108. I didn't notice because I have the patch from issue 27469 imported in order to build and test pyshellext.dll. ---------- components: +Windows nosy: +eryksun, paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 23:44:42 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 18 Jul 2016 03:44:42 +0000 Subject: [issue27545] missing pyshellext.vcxproj prevents puilding 3.6 In-Reply-To: <1468811289.51.0.698571569689.issue27545@psf.upfronthosting.co.za> Message-ID: <1468813482.96.0.315386669992.issue27545@psf.upfronthosting.co.za> Steve Dower added the comment: Whoops, that wasn't supposed to slip in. I'll fix :) ---------- assignee: -> steve.dower versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 23:46:21 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 18 Jul 2016 03:46:21 +0000 Subject: [issue27545] missing pyshellext.vcxproj prevents puilding 3.6 In-Reply-To: <1468811289.51.0.698571569689.issue27545@psf.upfronthosting.co.za> Message-ID: <20160718034618.31549.9795.965EDD5B@psf.io> Roundup Robot added the comment: New changeset d044e03fbed6 by Steve Dower in branch '3.5': Closes #27545: Remove pyshellext.vcxproj from pcbuild.proj https://hg.python.org/cpython/rev/d044e03fbed6 New changeset f7a161e48af8 by Steve Dower in branch 'default': Closes #27545: Remove pyshellext.vcxproj from pcbuild.proj https://hg.python.org/cpython/rev/f7a161e48af8 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 23:50:51 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 18 Jul 2016 03:50:51 +0000 Subject: [issue27533] release GIL in nt._isdir In-Reply-To: <1468700034.79.0.260183682177.issue27533@psf.upfronthosting.co.za> Message-ID: <20160718035048.31307.64959.763DD8C1@psf.io> Roundup Robot added the comment: New changeset ebf9a4c933e9 by Steve Dower in branch '3.5': Issue #27533: Release GIL in nt._isdir https://hg.python.org/cpython/rev/ebf9a4c933e9 New changeset 8823c660820e by Steve Dower in branch 'default': Issue #27533: Release GIL in nt._isdir https://hg.python.org/cpython/rev/8823c660820e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 23:51:06 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 18 Jul 2016 03:51:06 +0000 Subject: [issue27533] release GIL in nt._isdir In-Reply-To: <1468700034.79.0.260183682177.issue27533@psf.upfronthosting.co.za> Message-ID: <1468813866.97.0.300756693588.issue27533@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- assignee: -> steve.dower resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 23:52:31 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 18 Jul 2016 03:52:31 +0000 Subject: [issue27469] Unicode filename gets crippled on Windows when drag and drop In-Reply-To: <1467992332.72.0.0240653508758.issue27469@psf.upfronthosting.co.za> Message-ID: <1468813951.04.0.799780597984.issue27469@psf.upfronthosting.co.za> Steve Dower added the comment: Thanks, I've merged that change into my patch. I doubt anyone else is going to build and test this, but just in case I'll let it set for a couple of days before merging. Perhaps someone will at least look at the code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 23:53:42 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 18 Jul 2016 03:53:42 +0000 Subject: [issue27417] Call CoInitializeEx on startup In-Reply-To: <1467224377.99.0.571630822652.issue27417@psf.upfronthosting.co.za> Message-ID: <1468814022.51.0.208212162994.issue27417@psf.upfronthosting.co.za> Steve Dower added the comment: Mark's argument is strong, so I'm withdrawing this proposal. Thanks for the discussion and comments, everyone! ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 23:54:54 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 18 Jul 2016 03:54:54 +0000 Subject: [issue27407] prepare_ssl.py missing in PCBuild folder In-Reply-To: <1467129101.75.0.190967311264.issue27407@psf.upfronthosting.co.za> Message-ID: <1468814094.83.0.27455725529.issue27407@psf.upfronthosting.co.za> Steve Dower added the comment: Giving this to Zach to resolve/close as he feels appropriate. ---------- assignee: -> zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 00:10:10 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 18 Jul 2016 04:10:10 +0000 Subject: [issue27546] Integrate tkinter and asyncio (and async) Message-ID: <1468815010.57.0.709565417017.issue27546@psf.upfronthosting.co.za> New submission from Terry J. Reedy: The last week of last February, there was a discussion of this topic on python-ideas as part of "How the heck does async/await work in Python 3.5". I would like to re-start the discussion along with rescuing the two big chunks of code that were posted. Guido, you said "it would be very useful to have an asyncio loop integrated with Tkinter". Were you thinking of something added to either the asyncio or tkinter modules? What would be the minimum that you think would be worth adding? What would a mininal test look like? There are, of course, multiple strategies. Maxime posted the code I copied into the attached tkselector.py. No example usage was given. I cannot run it on Windows because it uses a unix-only function. Maxime, for us to use this, you need to sign the contributor agreement, which can be done via the net. See https://www.python.org/psf/contrib/ As soon as I submit this, I will also upload my tkloop.py. It defines a TkEventLoop class that adds root.update in the run_forever method. It then uses the class for working example of a asyncio callback modifying a tk widget at times intervals. As I note in the doc string, there is an issue with asyncio's _run_once() blocking forever. I recently noticed that idlelib.run.main does something similar, running a loop that gets user input with 1/20 second timeout and calling tkapp.eval('update') whenever there is none. Motivations: 1. Mix gui events (key, mouse, and others) with i/o events. 2. Use gui events with the new async syntax. My simple example, in the callback typical of tkinter apps, has widgets, callback, and dynamics defined in different places. I would like to be able to write the app in a more 'natural' style, using loops: something like async def display_date(interval, end_time, loop=ai.get_event_loop()): label = tk.Label(root) label.pack() async for tick in timer(interval, end_time, loop): label['text'] = datetime.datetime.now() Some python-tkinter beginners try to do something like this, except that for time delays they use while and time.sleep. There have been many Stackoverflow questions about the resulting failures. I would like to find out if I presume that converting my example to something like the above, using TkEventLoop, could be done easily enough by someone who knows how. For only supporting tk events, it would be better to have a tkinter implementation of the needed subset of asyncio.events.AbstractEventLoop. The run and call methods are needed, the io methods not, but I am not sure where to draw the line in between. The implementation of a few methods should be fairly easy: run_forever is mainloop, close is destroy; run_until_complete will be harder. ---------- files: tkselector.py messages: 270688 nosy: Maxime S, gvanrossum, serhiy.storchaka, terry.reedy, yselivanov priority: normal severity: normal stage: test needed status: open title: Integrate tkinter and asyncio (and async) type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43769/tkselector.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 00:10:28 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 18 Jul 2016 04:10:28 +0000 Subject: [issue27546] Integrate tkinter and asyncio (and async) In-Reply-To: <1468815010.57.0.709565417017.issue27546@psf.upfronthosting.co.za> Message-ID: <1468815028.58.0.772451982924.issue27546@psf.upfronthosting.co.za> Changes by Terry J. Reedy : Added file: http://bugs.python.org/file43770/tkloop.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 00:12:10 2016 From: report at bugs.python.org (Decorater) Date: Mon, 18 Jul 2016 04:12:10 +0000 Subject: [issue27469] Unicode filename gets crippled on Windows when drag and drop In-Reply-To: <1467992332.72.0.0240653508758.issue27469@psf.upfronthosting.co.za> Message-ID: <1468815130.61.0.7651611998.issue27469@psf.upfronthosting.co.za> Decorater added the comment: Oh and when the shell extension is done could you make a custom icon for pyd's and have the desciption of "Python C Compiled DLL" to easy selcting them when you have no icons for any *.lib, *.exp and *.pdb's Would ease up comping pyd files as well. On further note it seems that python (when told to read from python36.zip seems to not read any pyd's that are in the zip as well) I would like for it to be able too if someone wants to embed PyNacl with _sodium.cp36-win32.pyd or _sodium.cp36-win_amd64.pyd files in it. (Also readign pyd's in the zips could also simplify things like a ImportError on stuff that is actually there. ---------- nosy: +Decorater _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 00:25:57 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 18 Jul 2016 04:25:57 +0000 Subject: [issue27469] Unicode filename gets crippled on Windows when drag and drop In-Reply-To: <1467992332.72.0.0240653508758.issue27469@psf.upfronthosting.co.za> Message-ID: <1468815957.72.0.684186916703.issue27469@psf.upfronthosting.co.za> Steve Dower added the comment: A custom icon for .pyd files doesn't require a shell extension - it only really requires the icon. I don't want to use the same as .pyc, since that has the implication that it can be deleted safely, or .py, since that can be double-clicked. So we'd need something new. The rest of the request requires exposing new public APIs in Windows so that we can load executables from arbitrary memory locations. That's not something I can fix here :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 00:40:20 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 18 Jul 2016 04:40:20 +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: <20160718044017.22473.94079.CAA71DF1@psf.io> Roundup Robot added the comment: New changeset 7ffb7f3c345d by Steve Dower in branch '3.5': Issue #27309: Enables proper Windows styles in python[w].exe manifest. https://hg.python.org/cpython/rev/7ffb7f3c345d New changeset da735eb8b7a2 by Steve Dower in branch 'default': Issue #27309: Enables proper Windows styles in python[w].exe manifest. https://hg.python.org/cpython/rev/da735eb8b7a2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 00:42:01 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 18 Jul 2016 04:42:01 +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: <1468816921.75.0.447359674614.issue27309@psf.upfronthosting.co.za> Steve Dower added the comment: Updated the manifest to include the correct common controls DLL, which ensures the correct style is used for native dialogs. I applied this to Python 3.5 and 3.6, since it's not a behavioural change and should not break any code, and arguably since it's been the recommended default for all apps targeting XP or later it's a bug that we weren't already doing it. ---------- assignee: -> steve.dower resolution: -> fixed stage: test needed -> resolved status: open -> closed versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 00:47:11 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 18 Jul 2016 04:47:11 +0000 Subject: [issue27546] Integrate tkinter and asyncio (and async) In-Reply-To: <1468815028.6.0.188713230319.issue27546@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I expect it should eventually be added to tkinter. But I also think it might be worthwhile to first develop it as a 3rd party package on PyPI, to see if it can actually be done well enough to put it in the stdlib. I guess a demo app should be part of the project; the demo should show that some independently developed asyncio code (perhaps derived from examples/crawl.py in the asyncio repo) can run while also maintaining a UI built using Tkinter responsive. Ideally there would also be a demonstration of how the UI and the crawl code interact. And no threads. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 00:48:30 2016 From: report at bugs.python.org (Decorater) Date: Mon, 18 Jul 2016 04:48:30 +0000 Subject: [issue26624] Windows hangs in call to CRT setlocale() In-Reply-To: <1458747871.12.0.710719467032.issue26624@psf.upfronthosting.co.za> Message-ID: <1468817310.6.0.480956723009.issue26624@psf.upfronthosting.co.za> Decorater added the comment: Cant someone just copy these dlls from Windows 10 itself if they have it installed? ucrtbase: 10.0.14295.1000 (03/19/2016) ucrtbased: 10.0.10586.15 (11/20/2015) vcruntime140d: 14.0.23506.0 (11/05/2015) I have windows 10 on another partition btw so I could manually update mine to fix this stuff on my windows 7. thank god for 64 bit OSes. ---------- nosy: +Decorater _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 00:54:08 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 18 Jul 2016 04:54:08 +0000 Subject: [issue26624] Windows hangs in call to CRT setlocale() In-Reply-To: <1458747871.12.0.710719467032.issue26624@psf.upfronthosting.co.za> Message-ID: <1468817648.96.0.0133983193002.issue26624@psf.upfronthosting.co.za> Steve Dower added the comment: You should get these files by installing the latest Windows 10 SDK (regardless of your OS - the SDK version relates to the latest it can target, not the latest it can be used on). For some reason, they decided it shouldn't be "automatic" to update the SDK when you're updating other parts of the compiler toolset. I'll bring it up next time I chat to those guys at work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 00:56:38 2016 From: report at bugs.python.org (Eryk Sun) Date: Mon, 18 Jul 2016 04:56:38 +0000 Subject: [issue27469] Unicode filename gets crippled on Windows when drag and drop In-Reply-To: <1467992332.72.0.0240653508758.issue27469@psf.upfronthosting.co.za> Message-ID: <1468817798.8.0.841152563058.issue27469@psf.upfronthosting.co.za> Eryk Sun added the comment: Steve, will you be uploading a new patch? The current patch doesn't include "pyshellext.vcxproj" in the build, since that was accidentally committed and then removed. When you call ShellExecute, I suggest passing NULL for lpOperation, to use the default verb. If no default is defined the shell uses "open" anyway. Decorater, there's a memory importer for extension modules in py2exe, based on Joachim Bauch's MemoryModule.c: https://sourceforge.net/p/py2exe/svn/HEAD/tree/trunk/py2exe-3/source ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 01:07:54 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 18 Jul 2016 05:07:54 +0000 Subject: [issue27469] Unicode filename gets crippled on Windows when drag and drop In-Reply-To: <1467992332.72.0.0240653508758.issue27469@psf.upfronthosting.co.za> Message-ID: <1468818474.54.0.849775276331.issue27469@psf.upfronthosting.co.za> Steve Dower added the comment: Sure, added a new patch with all of your suggestions. I also added pyshellext.vcxproj to pcbuild.sln. (And my final word on the magic used to load DLLs from memory is that I'm not willing to maintain that code within CPython itself, so it won't be going into the core unless someone steps up with a 10+ year promise to look after it.) ---------- stage: -> patch review Added file: http://bugs.python.org/file43771/27469_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 01:11:24 2016 From: report at bugs.python.org (Decorater) Date: Mon, 18 Jul 2016 05:11:24 +0000 Subject: [issue27469] Unicode filename gets crippled on Windows when drag and drop In-Reply-To: <1467992332.72.0.0240653508758.issue27469@psf.upfronthosting.co.za> Message-ID: <1468818684.69.0.932579576913.issue27469@psf.upfronthosting.co.za> Decorater added the comment: I actually like py2exe's memory loader. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 01:37:10 2016 From: report at bugs.python.org (Decorater) Date: Mon, 18 Jul 2016 05:37:10 +0000 Subject: [issue26624] Windows hangs in call to CRT setlocale() In-Reply-To: <1458747871.12.0.710719467032.issue26624@psf.upfronthosting.co.za> Message-ID: <1468820230.98.0.80283378362.issue26624@psf.upfronthosting.co.za> Decorater added the comment: Also can you ask them why sometimes the IDE takes too long to respond AKA freezes / crashes randomly? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 01:39:04 2016 From: report at bugs.python.org (pablo sacristan) Date: Mon, 18 Jul 2016 05:39:04 +0000 Subject: [issue27547] Integer Overflow Crash On float(array.array()) Message-ID: <1468820344.69.0.285015698444.issue27547@psf.upfronthosting.co.za> New submission from pablo sacristan: There is an integer overflow because python doesn't check the length as it does with bytearray() and it still goes on, so by doing something like: >>> import array >>> float(array.array("L",b"a"*0xFFFFFFFFFFFFFFF+100000**8000000000)) It returns: Python(2179,0x7fff7ad6a000) malloc: *** mach_vm_map(size=1152921504606851072) failed (error code=3) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug And then it just crashes Or you can skip the error and just do: >>> import array >>> float(array.array("L",b"a"*0xFFFFFFFFFFFFFFF**10000000000**80000000000000000)) That will just make python freeze until you restart it, which is as good as crashed. The file would be: import array float(array.array("L",b"a"*0xFFFFFFFFFFFFFFF**10000000000**80000000000000000)) Hope it helps ;) ---------- messages: 270700 nosy: pabstersac priority: normal severity: normal status: open title: Integer Overflow Crash On float(array.array()) versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 01:41:51 2016 From: report at bugs.python.org (Decorater) Date: Mon, 18 Jul 2016 05:41:51 +0000 Subject: [issue26624] Windows hangs in call to CRT setlocale() In-Reply-To: <1458747871.12.0.710719467032.issue26624@psf.upfronthosting.co.za> Message-ID: <1468820511.44.0.637656023076.issue26624@psf.upfronthosting.co.za> Decorater added the comment: not to mention build processes seems to be taking a lot of CPU recently but older C/C++ compilers do not EG the ones from like 2008 or so running faster than the same stuff being compiled againt 2010~2015 ones. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 01:54:55 2016 From: report at bugs.python.org (pablo sacristan) Date: Mon, 18 Jul 2016 05:54:55 +0000 Subject: [issue27548] Integer Overflow On bin() Message-ID: <1468821295.01.0.886780512463.issue27548@psf.upfronthosting.co.za> New submission from pablo sacristan: There is an integer overflow in bin() because python incorrectly checks the length of the input in bin(). bin(0xFFFFFFFFFFFFFFF+100000**8000000000) That line will freeze python until you restart it, which basically is a crash because python stops working completely. Hope it helps ;) ---------- messages: 270702 nosy: pabstersac priority: normal severity: normal status: open title: Integer Overflow On bin() versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 01:54:59 2016 From: report at bugs.python.org (pablo sacristan) Date: Mon, 18 Jul 2016 05:54:59 +0000 Subject: [issue27549] Integer Overflow Crash On bytearray() Message-ID: <1468821299.76.0.127950361859.issue27549@psf.upfronthosting.co.za> New submission from pablo sacristan: There is an integer overflow because python doesn't check the length correctly on bytearray: bytearray(0xFFFFFFFFFFFFFFF**10000000000**80000000000000000) That will not return an overflow message, and even though my hex knowledge is very bad I do believe 0xFFFFFFFFFFFFFFF**10000000000**80000000000000000 is more than 0xFFFFFFFFFFFFFFFF which does return a overflow message. Hope it helps ;) ---------- messages: 270703 nosy: pabstersac priority: normal severity: normal status: open title: Integer Overflow Crash On bytearray() versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 01:56:32 2016 From: report at bugs.python.org (pablo sacristan) Date: Mon, 18 Jul 2016 05:56:32 +0000 Subject: [issue27550] Integer Overflow Crash On Arithmetic Operations Message-ID: <1468821392.71.0.241203163582.issue27550@psf.upfronthosting.co.za> New submission from pablo sacristan: There is an integer overflow because python doesn't check the length correctly on arithmetic operations: 0xFFFFFFFFFFFFFFF**10000000000**80000000000000000 Just that line will freeze python, no oveflow message appears, no memory error, and python basically crashes because it just stops working. Hope it helps ;) ---------- messages: 270704 nosy: pabstersac priority: normal severity: normal status: open title: Integer Overflow Crash On Arithmetic Operations versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 01:56:39 2016 From: report at bugs.python.org (pablo sacristan) Date: Mon, 18 Jul 2016 05:56:39 +0000 Subject: [issue27551] Integer Overflow On print() Message-ID: <1468821399.2.0.180204407388.issue27551@psf.upfronthosting.co.za> New submission from pablo sacristan: There is an integer overflow because python doesn't check the length correctly on print() statements: print(0xFFFFFFFFFFFFFFF**10000000000**80000000000000000) That will overflow and python would stop working, so it would be as good as crashed :) Hope it helps ;) ---------- messages: 270705 nosy: pabstersac priority: normal severity: normal status: open title: Integer Overflow On print() versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 02:02:39 2016 From: report at bugs.python.org (pablo sacristan) Date: Mon, 18 Jul 2016 06:02:39 +0000 Subject: [issue27552] Integer Overflow On min() Message-ID: <1468821759.48.0.396391812874.issue27552@psf.upfronthosting.co.za> New submission from pablo sacristan: There is an integer overflow on min() statements because python incorrectly checks the length to put the overflow message, so it is possible to overflow min() min(0xFFFFFFFFFFFFFFF+100000**8000000000) That line freezes python until you restart it, which is basically as if you were crashing it, the effect is the same, python stops working. Hope it helps ;) ---------- messages: 270706 nosy: pabstersac priority: normal severity: normal status: open title: Integer Overflow On min() versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 02:04:24 2016 From: report at bugs.python.org (pablo sacristan) Date: Mon, 18 Jul 2016 06:04:24 +0000 Subject: [issue27553] Integer Overflow On unicode() Message-ID: <1468821864.13.0.013612270682.issue27553@psf.upfronthosting.co.za> New submission from pablo sacristan: There is an integer overflow in unicode() because python incorrectly checks the length of unicode(): unicode(0xFFFFFFFFFFFFFFF+100000**8000000000) That freezes python until you restart it which is basically the same effect as crashing python. Hope it helps ;) ---------- messages: 270707 nosy: pabstersac priority: normal severity: normal status: open title: Integer Overflow On unicode() versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 02:05:41 2016 From: report at bugs.python.org (pablo sacristan) Date: Mon, 18 Jul 2016 06:05:41 +0000 Subject: [issue27554] Integer Overflow On dir() Message-ID: <1468821941.88.0.767862457306.issue27554@psf.upfronthosting.co.za> New submission from pablo sacristan: There is an integer overflow in dir(): dir(0xFFFFFFFFFFFFFFF+100000**8000000000) That line will freeze python until you restart it, which makes it have the same effect as a crash. Hope it helps ;) ---------- messages: 270708 nosy: pabstersac priority: normal severity: normal status: open title: Integer Overflow On dir() versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 02:11:29 2016 From: report at bugs.python.org (pablo sacristan) Date: Mon, 18 Jul 2016 06:11:29 +0000 Subject: [issue27555] Integer Overflow on oct() Message-ID: <1468822289.98.0.19542711871.issue27555@psf.upfronthosting.co.za> New submission from pablo sacristan: There is an integer overflow on oct() because of incorrectly checking the length. oct(0xFFFFFFFFFFFFFFF+100000**8000000000) That line will freeze python until you restart it, which is as good as crashed. Hope it helps ;) ---------- messages: 270709 nosy: pabstersac priority: normal severity: normal status: open title: Integer Overflow on oct() versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 02:14:00 2016 From: report at bugs.python.org (pablo sacristan) Date: Mon, 18 Jul 2016 06:14:00 +0000 Subject: [issue27556] Integer overflow on hex() Message-ID: <1468822440.54.0.519269097524.issue27556@psf.upfronthosting.co.za> New submission from pablo sacristan: There is an integer overflow on hex() because python incorrectly checks the length of the value to return overflow message if it were too big. hex(0xFFFFFFFFFFFFFFF+100000**8000000000) That line will freeze python until you restart it, which is the same thing as crashing python. Hope it helps ;) ---------- messages: 270710 nosy: pabstersac priority: normal severity: normal status: open title: Integer overflow on hex() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 02:21:48 2016 From: report at bugs.python.org (pablo sacristan) Date: Mon, 18 Jul 2016 06:21:48 +0000 Subject: [issue27557] Integer Overflow on int() Message-ID: <1468822908.93.0.0686992762741.issue27557@psf.upfronthosting.co.za> New submission from pablo sacristan: There is an integer overflow on int() because python incorrectly checks the length of the input. int(0xFFFFFFFFFFFFFFF+100000**8000000000) That line of code will freeze python until you restart it, which is as annoying as if python had crashed. Hope it helps ;) ---------- messages: 270711 nosy: pabstersac priority: normal severity: normal status: open title: Integer Overflow on int() versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 02:22:06 2016 From: report at bugs.python.org (Antti Haapala) Date: Mon, 18 Jul 2016 06:22:06 +0000 Subject: [issue27556] Integer overflow on hex() In-Reply-To: <1468822440.54.0.519269097524.issue27556@psf.upfronthosting.co.za> Message-ID: <1468822926.8.0.458921169186.issue27556@psf.upfronthosting.co.za> Antti Haapala added the comment: Note that this has nothing to do with `hex()` function. The part that is problem here is 100000**8000000000, which takes ages to compute. You can interrupt it with Ctrl-C. ---------- nosy: +ztane _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 02:26:15 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Jul 2016 06:26:15 +0000 Subject: [issue27556] Integer overflow on hex() In-Reply-To: <1468822440.54.0.519269097524.issue27556@psf.upfronthosting.co.za> Message-ID: <1468823175.19.0.16483015494.issue27556@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 02:26:43 2016 From: report at bugs.python.org (Romuald Brunet) Date: Mon, 18 Jul 2016 06:26:43 +0000 Subject: [issue27558] SystemError inside multiprocessing.dummy Pool.map Message-ID: <1468823203.61.0.708048243679.issue27558@psf.upfronthosting.co.za> New submission from Romuald Brunet: Raising without a previous exception inside a method called from multiprocessing.dummy.Pool.map will trigger a SystemError. SystemError: PyEval_EvalFrameEx returned NULL without setting an error Traceback (most recent call last): File "example.py", line 16, in main() File "example.py", line 11, in main result = pool.map(test, [1]) File "/usr/local/Cellar/python3/3.5.2/Frameworks/Python.framework/Versions/3.5/lib/python3.5/multiprocessing/pool.py", line 260, in map return self._map_async(func, iterable, mapstar, chunksize).get() File "/usr/local/Cellar/python3/3.5.2/Frameworks/Python.framework/Versions/3.5/lib/python3.5/multiprocessing/pool.py", line 608, in get raise self._value File "/usr/local/Cellar/python3/3.5.2/Frameworks/Python.framework/Versions/3.5/lib/python3.5/multiprocessing/pool.py", line 119, in worker result = (True, func(*args, **kwds)) File "/usr/local/Cellar/python3/3.5.2/Frameworks/Python.framework/Versions/3.5/lib/python3.5/multiprocessing/pool.py", line 44, in mapstar return list(map(*args)) SystemError: PyEval_EvalFrameEx returned NULL without setting an error Reproducible example is attached ---------- components: Interpreter Core files: example.py messages: 270713 nosy: Romuald priority: normal severity: normal status: open title: SystemError inside multiprocessing.dummy Pool.map type: behavior versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file43772/example.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 02:27:28 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Jul 2016 06:27:28 +0000 Subject: [issue27557] Integer Overflow on int() In-Reply-To: <1468822908.93.0.0686992762741.issue27557@psf.upfronthosting.co.za> Message-ID: <1468823248.58.0.940772782818.issue27557@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See msg270712. ---------- nosy: +serhiy.storchaka resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 02:27:42 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 18 Jul 2016 06:27:42 +0000 Subject: [issue27549] Integer Overflow Crash On bytearray() In-Reply-To: <1468821299.76.0.127950361859.issue27549@psf.upfronthosting.co.za> Message-ID: <1468823262.82.0.349281170698.issue27549@psf.upfronthosting.co.za> Xiang Zhang added the comment: So if it doesn't return an overflow message, what does it returns? ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 02:27:49 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Jul 2016 06:27:49 +0000 Subject: [issue27555] Integer Overflow on oct() In-Reply-To: <1468822289.98.0.19542711871.issue27555@psf.upfronthosting.co.za> Message-ID: <1468823269.29.0.379122682002.issue27555@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See msg270712. ---------- nosy: +serhiy.storchaka resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 02:28:12 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Jul 2016 06:28:12 +0000 Subject: [issue27554] Integer Overflow On dir() In-Reply-To: <1468821941.88.0.767862457306.issue27554@psf.upfronthosting.co.za> Message-ID: <1468823292.23.0.334501752679.issue27554@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See msg270712. ---------- nosy: +serhiy.storchaka resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 02:28:41 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Jul 2016 06:28:41 +0000 Subject: [issue27553] Integer Overflow On unicode() In-Reply-To: <1468821864.13.0.013612270682.issue27553@psf.upfronthosting.co.za> Message-ID: <1468823321.59.0.113442890391.issue27553@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See msg270712. ---------- nosy: +serhiy.storchaka resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 02:29:00 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Jul 2016 06:29:00 +0000 Subject: [issue27552] Integer Overflow On min() In-Reply-To: <1468821759.48.0.396391812874.issue27552@psf.upfronthosting.co.za> Message-ID: <1468823340.07.0.530311311921.issue27552@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See msg270712. ---------- nosy: +serhiy.storchaka resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 02:29:18 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Jul 2016 06:29:18 +0000 Subject: [issue27551] Integer Overflow On print() In-Reply-To: <1468821399.2.0.180204407388.issue27551@psf.upfronthosting.co.za> Message-ID: <1468823358.49.0.764002204172.issue27551@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See msg270712. ---------- nosy: +serhiy.storchaka resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 02:30:33 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Jul 2016 06:30:33 +0000 Subject: [issue27549] Integer Overflow Crash On bytearray() In-Reply-To: <1468821299.76.0.127950361859.issue27549@psf.upfronthosting.co.za> Message-ID: <1468823433.62.0.269967925071.issue27549@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See msg270712. ---------- nosy: +serhiy.storchaka resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 02:30:51 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Jul 2016 06:30:51 +0000 Subject: [issue27550] Integer Overflow Crash On Arithmetic Operations In-Reply-To: <1468821392.71.0.241203163582.issue27550@psf.upfronthosting.co.za> Message-ID: <1468823451.8.0.198555501733.issue27550@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 02:31:01 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Jul 2016 06:31:01 +0000 Subject: [issue27550] Integer Overflow Crash On Arithmetic Operations In-Reply-To: <1468821392.71.0.241203163582.issue27550@psf.upfronthosting.co.za> Message-ID: <1468823461.56.0.650889687141.issue27550@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See msg270712. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 02:31:23 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Jul 2016 06:31:23 +0000 Subject: [issue27548] Integer Overflow On bin() In-Reply-To: <1468821295.01.0.886780512463.issue27548@psf.upfronthosting.co.za> Message-ID: <1468823483.18.0.797588285368.issue27548@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See msg270712. ---------- nosy: +serhiy.storchaka resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 02:31:57 2016 From: report at bugs.python.org (Maxime S) Date: Mon, 18 Jul 2016 06:31:57 +0000 Subject: [issue27546] Integrate tkinter and asyncio (and async) In-Reply-To: <1468815010.57.0.709565417017.issue27546@psf.upfronthosting.co.za> Message-ID: <1468823517.21.0.748875246794.issue27546@psf.upfronthosting.co.za> Maxime S added the comment: I've signed the CLA. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 02:35:32 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 18 Jul 2016 06:35:32 +0000 Subject: [issue27558] SystemError inside multiprocessing.dummy Pool.map In-Reply-To: <1468823203.61.0.708048243679.issue27558@psf.upfronthosting.co.za> Message-ID: <1468823732.89.0.613326977695.issue27558@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 03:47:53 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 18 Jul 2016 07:47:53 +0000 Subject: [issue27487] -m switch regression in Python 3.5.2 (under rare circumstances) In-Reply-To: <1468268291.19.0.631980361837.issue27487@psf.upfronthosting.co.za> Message-ID: <1468828073.04.0.337001802726.issue27487@psf.upfronthosting.co.za> Martin Panter added the comment: Here is an updated patch. Since the message no longer applies to top-level modules, I went back to a version closer to Wolfgang?s suggestion, which should eliminate the problem with ?any parent packages?. Now the messages look like this: /media/disk/home/proj/python/cpython/Lib/runpy.py:125: RuntimeWarning: 'package.module' found in sys.modules after import of package 'package', but prior to execution of 'package.module'; this may result in unpredictable behaviour warn(RuntimeWarning(msg)) /media/disk/home/proj/python/cpython/python: Error while finding module specification for 'package.module' (ValueError: package.module.__spec__ is not set) [Exit 1] ---------- Added file: http://bugs.python.org/file43773/warn-imported.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 04:22:55 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 18 Jul 2016 08:22:55 +0000 Subject: [issue27507] bytearray.extend lacks overflow check when increasing buffer In-Reply-To: <1468429948.12.0.767304648411.issue27507@psf.upfronthosting.co.za> Message-ID: <20160718082224.22451.11463.17D89ADD@psf.io> Roundup Robot added the comment: New changeset 54cc0480904c by Martin Panter in branch '3.5': Issue #27507: Check for integer overflow in bytearray.extend() https://hg.python.org/cpython/rev/54cc0480904c New changeset 6e166b66aa44 by Martin Panter in branch '2.7': Issue #27507: Check for integer overflow in bytearray.extend() https://hg.python.org/cpython/rev/6e166b66aa44 New changeset 646ad4894c32 by Martin Panter in branch 'default': Issue #27507: Merge overflow check from 3.5 https://hg.python.org/cpython/rev/646ad4894c32 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 04:38:52 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 18 Jul 2016 08:38:52 +0000 Subject: [issue16191] ceval cleanup In-Reply-To: <1349913895.1.0.124857708978.issue16191@psf.upfronthosting.co.za> Message-ID: <20160718083849.121399.12177.E6F77D84@psf.io> Roundup Robot added the comment: New changeset 6cf4386de3cc by Martin Panter in branch '3.5': Issue #16191: Fix up references to renamed variables https://hg.python.org/cpython/rev/6cf4386de3cc New changeset c10fe99afced by Martin Panter in branch 'default': Issue #16191: Merge comment fixes from 3.5 https://hg.python.org/cpython/rev/c10fe99afced ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 04:51:34 2016 From: report at bugs.python.org (Antti Haapala) Date: Mon, 18 Jul 2016 08:51:34 +0000 Subject: [issue27558] SystemError inside multiprocessing.dummy Pool.map In-Reply-To: <1468823203.61.0.708048243679.issue27558@psf.upfronthosting.co.za> Message-ID: <1468831894.85.0.234383584557.issue27558@psf.upfronthosting.co.za> Antti Haapala added the comment: Reproducible on Python 3.6a4ish on Ubuntu. I believe this needs forking multiprocessing. do_raise is called with 2 NULLs as arguments, it should raise PyErr_SetString(PyExc_RuntimeError, "No active exception to reraise"); What happens is that PyThreadState is initialized to *all* NULL pointers on the new thread on multiprocessing, however `type` is expected to point to `Py_None` when no exception has been raised: PyThreadState *tstate = PyThreadState_GET(); PyObject *tb; type = tstate->exc_type; value = tstate->exc_value; tb = tstate->exc_traceback; if (type == Py_None) { PyErr_SetString(PyExc_RuntimeError, "No active exception to reraise"); return 0; } I am not sure where the thread state should have been initialized though ---------- nosy: +ztane _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 05:06:24 2016 From: report at bugs.python.org (Antti Haapala) Date: Mon, 18 Jul 2016 09:06:24 +0000 Subject: [issue27558] SystemError inside multiprocessing.dummy Pool.map In-Reply-To: <1468823203.61.0.708048243679.issue27558@psf.upfronthosting.co.za> Message-ID: <1468832784.4.0.775295895554.issue27558@psf.upfronthosting.co.za> Antti Haapala added the comment: OTOH, if you put sys.exc_info() in place of raise there, it correctly (None, None, None) there, because it does (sysmodule.c:sys_exc_info) tstate->exc_type != NULL ? tstate->exc_type : Py_None, Easiest fix would be to make do_raise test for both NULL and None, but I'd really consider fixing the new thread initialization if possible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 05:07:47 2016 From: report at bugs.python.org (Antti Haapala) Date: Mon, 18 Jul 2016 09:07:47 +0000 Subject: [issue27558] SystemError inside multiprocessing.dummy Pool.map In-Reply-To: <1468823203.61.0.708048243679.issue27558@psf.upfronthosting.co.za> Message-ID: <1468832867.2.0.765651633157.issue27558@psf.upfronthosting.co.za> Antti Haapala added the comment: more easily reproducible by import threading def foo(): raise threading.Thread(target=foo).start() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 05:08:05 2016 From: report at bugs.python.org (pablo sacristan) Date: Mon, 18 Jul 2016 09:08:05 +0000 Subject: [issue27559] Crash On bytearray() Message-ID: <1468832885.3.0.732999083359.issue27559@psf.upfronthosting.co.za> New submission from pablo sacristan: There is a crash on bytearray(), not really a crash but rather the process gets killed by the kernel, but that is a crash, and the keyboard interrupt stops working while bytearray is working, so you can either restart python or wait for python to get killed by the kernel. The biggest problem is that while bytearray() is trying to do something, you can't interrupt it just doesn't work for some reason. This should be enough for bytearray to crash : bytearray(0xFFFFFFFFFF) It crashes after some time with a Killed: 9 error. Hope it helps ;) ---------- messages: 270731 nosy: pabstersac priority: normal severity: normal status: open title: Crash On bytearray() versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 05:08:54 2016 From: report at bugs.python.org (pablo sacristan) Date: Mon, 18 Jul 2016 09:08:54 +0000 Subject: [issue27560] zlib.compress() crash and keyboard interrupt stops working Message-ID: <1468832934.6.0.711776862351.issue27560@psf.upfronthosting.co.za> New submission from pablo sacristan: zlib.compress crashes when you put a lot of stuff into it and even when you try keyboard interrupts it doesn't work for some reason, and Python gets killed because trying to compress so much data gets the Python process get killed by the kernel. If you put a large amount of data in it will get killed quicker. A problem is that keyboard interrupts stop working while the program is running, which is usually around 5 - 15 seconds during which python stops working (including interrupts) until it gets killed by the kernel. This may be used to crash python remotely if a server takes user input and runs it through zlib.compress(b'variable' * 2**32) which is not very likely. You probably should set a limit for what you compress and how much it is. The output is: Killed: 9 Even though you try doing keyboard interrupt it doesn't work. ---------- files: crash.py messages: 270732 nosy: pabstersac priority: normal severity: normal status: open title: zlib.compress() crash and keyboard interrupt stops working Added file: http://bugs.python.org/file43774/crash.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 05:13:56 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 18 Jul 2016 09:13:56 +0000 Subject: [issue27558] SystemError inside multiprocessing.dummy Pool.map In-Reply-To: <1468823203.61.0.708048243679.issue27558@psf.upfronthosting.co.za> Message-ID: <1468833236.46.0.408626862018.issue27558@psf.upfronthosting.co.za> Xiang Zhang added the comment: It seems the thread state is initialized in thread_PyThread_start_new_thread. It calls _PyThreadState_Prealloc which initialize exc_type to NULL. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 05:21:15 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 18 Jul 2016 09:21:15 +0000 Subject: [issue27558] SystemError inside multiprocessing.dummy Pool.map In-Reply-To: <1468823203.61.0.708048243679.issue27558@psf.upfronthosting.co.za> Message-ID: <1468833675.18.0.634387947615.issue27558@psf.upfronthosting.co.za> Xiang Zhang added the comment: I am curious why individual `raise` doesn't get the same problem in single thread program. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 05:25:18 2016 From: report at bugs.python.org (Antti Haapala) Date: Mon, 18 Jul 2016 09:25:18 +0000 Subject: [issue27558] SystemError inside multiprocessing.dummy Pool.map In-Reply-To: <1468823203.61.0.708048243679.issue27558@psf.upfronthosting.co.za> Message-ID: <1468833918.79.0.761124279334.issue27558@psf.upfronthosting.co.za> Antti Haapala added the comment: I was thinking that perhaps an exception is always raised somewhere before? I tried skipping site, but it still works, so I am not too sure. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 05:33:39 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 18 Jul 2016 09:33:39 +0000 Subject: [issue27559] Crash On bytearray() In-Reply-To: <1468832885.3.0.732999083359.issue27559@psf.upfronthosting.co.za> Message-ID: <1468834418.99.0.550832469522.issue27559@psf.upfronthosting.co.za> Martin Panter added the comment: bytearray(n) needs to allocate n bytes. Unless your computer has 1024 GiB of memory, this is not going to be possible. If you are using an OS like Linux, it may pretend to allocate that much memory, and then kill the process when it realizes it has overallocated. If you need more robust behaviour on Linux, I suggest looking into disabling memory overcommit. ---------- nosy: +martin.panter resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 05:37:12 2016 From: report at bugs.python.org (pablo sacristan) Date: Mon, 18 Jul 2016 09:37:12 +0000 Subject: [issue27559] Crash On bytearray() In-Reply-To: <1468832885.3.0.732999083359.issue27559@psf.upfronthosting.co.za> Message-ID: <1468834632.28.0.524839151212.issue27559@psf.upfronthosting.co.za> pablo sacristan added the comment: I know, but then shouldn't you try limiting the amount of data it allocates? Or maybe allow for keyboard interrupts to be used while the it is going on, because keyboard interrupts weren't working while it was working. ---------- resolution: not a bug -> remind _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 05:38:06 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 18 Jul 2016 09:38:06 +0000 Subject: [issue27560] zlib.compress() crash and keyboard interrupt stops working In-Reply-To: <1468832934.6.0.711776862351.issue27560@psf.upfronthosting.co.za> Message-ID: <1468834686.52.0.258346938105.issue27560@psf.upfronthosting.co.za> Martin Panter added the comment: There is a good chance crashes and related 2 GiB and 4 GiB limits in zlib will be solved by Issue 27130. Do you want to see if the patch improves the situation? (I cannot test it directly because I don?t have enough memory.) ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 05:42:11 2016 From: report at bugs.python.org (pablo sacristan) Date: Mon, 18 Jul 2016 09:42:11 +0000 Subject: [issue27560] zlib.compress() crash and keyboard interrupt stops working In-Reply-To: <1468832934.6.0.711776862351.issue27560@psf.upfronthosting.co.za> Message-ID: <1468834931.9.0.944902526091.issue27560@psf.upfronthosting.co.za> pablo sacristan added the comment: I'd like to but I don't have enough memory either, sorry. ---------- versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 05:46:44 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 18 Jul 2016 09:46:44 +0000 Subject: [issue27560] zlib.compress() crash and keyboard interrupt stops working In-Reply-To: <1468832934.6.0.711776862351.issue27560@psf.upfronthosting.co.za> Message-ID: <1468835204.28.0.447545466743.issue27560@psf.upfronthosting.co.za> Xiang Zhang added the comment: Compressing large data is born to be slow and it's highly possible to cause the kernel halt then due to resource limit. > This may be used to crash python remotely if a server takes user input and runs it through zlib.compress(b'variable' * 2**32) which is not very likely. You probably should set a limit for what you compress and how much it is. This is the responsibility of application code not library code. ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 05:48:18 2016 From: report at bugs.python.org (Antti Haapala) Date: Mon, 18 Jul 2016 09:48:18 +0000 Subject: [issue27560] zlib.compress() crash and keyboard interrupt stops working In-Reply-To: <1468832934.6.0.711776862351.issue27560@psf.upfronthosting.co.za> Message-ID: <1468835298.95.0.811729876359.issue27560@psf.upfronthosting.co.za> Antti Haapala added the comment: I am pretty sure **it never calls zlib.compress**. I get memory error from that argument alone, on Linux with overcommit memory enabled, 16G ram, swap. ---------- nosy: +ztane _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 05:49:26 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 18 Jul 2016 09:49:26 +0000 Subject: [issue27559] Crash On bytearray() In-Reply-To: <1468832885.3.0.732999083359.issue27559@psf.upfronthosting.co.za> Message-ID: <1468835366.77.0.684572430981.issue27559@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: remind -> not a bug stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 05:57:33 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 18 Jul 2016 09:57:33 +0000 Subject: [issue27507] bytearray.extend lacks overflow check when increasing buffer In-Reply-To: <1468429948.12.0.767304648411.issue27507@psf.upfronthosting.co.za> Message-ID: <1468835853.69.0.17906750896.issue27507@psf.upfronthosting.co.za> Martin Panter added the comment: Committed without any macro for the time being ---------- resolution: not a bug -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 06:00:24 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 18 Jul 2016 10:00:24 +0000 Subject: [issue27507] bytearray.extend lacks overflow check when increasing buffer In-Reply-To: <1468429948.12.0.767304648411.issue27507@psf.upfronthosting.co.za> Message-ID: <1468836024.35.0.820072261822.issue27507@psf.upfronthosting.co.za> Xiang Zhang added the comment: Thanks for your work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 06:09:05 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 18 Jul 2016 10:09:05 +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: <1468836545.96.0.996322310995.issue27130@psf.upfronthosting.co.za> Xiang Zhang added the comment: I may be hard to test this change without enough memory. I upload the test results with the latest change. ---------- Added file: http://bugs.python.org/file43775/zlib_test_result _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 06:36:22 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 18 Jul 2016 10:36:22 +0000 Subject: [issue27547] Integer Overflow Crash On float(array.array()) In-Reply-To: <1468820344.69.0.285015698444.issue27547@psf.upfronthosting.co.za> Message-ID: <1468838182.86.0.799691118197.issue27547@psf.upfronthosting.co.za> Martin Panter added the comment: Perhaps this is the same as Issue 5614, i.e. the problem lies with OS X rather than Python? ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 06:41:34 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 18 Jul 2016 10:41:34 +0000 Subject: [issue27558] SystemError inside multiprocessing.dummy Pool.map In-Reply-To: <1468823203.61.0.708048243679.issue27558@psf.upfronthosting.co.za> Message-ID: <1468838494.72.0.137820198987.issue27558@psf.upfronthosting.co.za> Xiang Zhang added the comment: > Easiest fix would be to make do_raise test for both NULL and None, but I'd really consider fixing the new thread initialization if possible. I think the easiest fix is OK. The new thread initialization is consistent and should not be changed. The Py_None seems to be set in somewhere in ceval but I am not sure where. You can see at https://hg.python.org/cpython/file/tip/Python/ceval.c#l1200 both NULL and Py_None are checked. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 06:44:06 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 18 Jul 2016 10:44:06 +0000 Subject: [issue27560] Memory overallocation crash and keyboard interrupt stops working In-Reply-To: <1468832934.6.0.711776862351.issue27560@psf.upfronthosting.co.za> Message-ID: <1468838646.5.0.0748711639212.issue27560@psf.upfronthosting.co.za> Martin Panter added the comment: Yes you are probably right Antti. The input to compress would need 31 TB of memory, and is a text string, while Python 3?s zlib.compress() requires bytes. In other words, this will be the same problem of overallocating memory as Issue 27559. Pablo: I suggest you carefully look at the code, try to understand what it is doing, eliminating the unnecessary parts, etc. Especially when so many of your reports today involve similar techniques. ---------- resolution: -> duplicate status: open -> closed superseder: -> Crash On bytearray() title: zlib.compress() crash and keyboard interrupt stops working -> Memory overallocation crash and keyboard interrupt stops working _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 07:06:02 2016 From: report at bugs.python.org (Emanuel Barry) Date: Mon, 18 Jul 2016 11:06:02 +0000 Subject: [issue27558] SystemError with bare `raise` in threading or multiprocessing In-Reply-To: <1468823203.61.0.708048243679.issue27558@psf.upfronthosting.co.za> Message-ID: <1468839962.54.0.208396032696.issue27558@psf.upfronthosting.co.za> Changes by Emanuel Barry : ---------- nosy: +davin, ebarry, pitrou stage: -> needs patch title: SystemError inside multiprocessing.dummy Pool.map -> SystemError with bare `raise` in threading or multiprocessing versions: +Python 3.6 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 07:44:27 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 18 Jul 2016 11:44:27 +0000 Subject: [issue27543] from module import function creates package reference to the module In-Reply-To: <1468779241.06.0.301525903069.issue27543@psf.upfronthosting.co.za> Message-ID: <1468842267.22.0.552958786823.issue27543@psf.upfronthosting.co.za> R. David Murray added the comment: Note that conceptually this is closely related to issue 27515. In both cases the conceptual problem (the thing that trips up user expectations) is that what import does to the namespaces differs depending on whether the base module exists in sys.modules or not. I don't know that there is a fix, but it is certainly an inconsistency that causes mental hiccoughs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 08:59:55 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 18 Jul 2016 12:59:55 +0000 Subject: [issue26624] Windows hangs in call to CRT setlocale() In-Reply-To: <1458747871.12.0.710719467032.issue26624@psf.upfronthosting.co.za> Message-ID: <1468846795.97.0.152642843836.issue26624@psf.upfronthosting.co.za> Steve Dower added the comment: Lot of different people involved in those areas, so can't promise an answer, but I'll see. Also, unless you think a closed issue needs to be reopened, please avoid using them for chat. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 09:01:35 2016 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 18 Jul 2016 13:01:35 +0000 Subject: [issue27539] negative Fraction ** negative int not normalized In-Reply-To: <1468740731.71.0.38394274484.issue27539@psf.upfronthosting.co.za> Message-ID: <1468846895.93.0.123831549422.issue27539@psf.upfronthosting.co.za> Mark Dickinson added the comment: Oops, that's an embarrassing bug. Branching depending on the sign sounds fine to me. There's no point worrying about supporting strange Fraction-like things without a concrete idea of exactly which such things we want to support. Are you interested in writing a patch? ---------- priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 09:15:21 2016 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 18 Jul 2016 13:15:21 +0000 Subject: [issue11822] Improve disassembly to show embedded code objects In-Reply-To: <1302467152.39.0.854888976189.issue11822@psf.upfronthosting.co.za> Message-ID: <1468847721.25.0.73902382933.issue11822@psf.upfronthosting.co.za> St?phane Wirtel added the comment: hello, we can continue the discussion on this issue ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 09:19:15 2016 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 18 Jul 2016 13:19:15 +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: <1468847955.85.0.0755714107259.issue3119@psf.upfronthosting.co.za> St?phane Wirtel added the comment: hello, I think we can close this issue because Python 3.1 is not supported. or we keep it if this issue is confirmed for Python 3.6. ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 09:22:46 2016 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 18 Jul 2016 13:22:46 +0000 Subject: [issue26380] Add an http method enum In-Reply-To: <1455776645.01.0.0347855430312.issue26380@psf.upfronthosting.co.za> Message-ID: <1468848166.7.0.778096730842.issue26380@psf.upfronthosting.co.za> St?phane Wirtel added the comment: what's the status of your issue ? ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 09:30:51 2016 From: report at bugs.python.org (Kirk Hansen) Date: Mon, 18 Jul 2016 13:30:51 +0000 Subject: [issue27561] Warn against subclassing builtins, and overriding their methods Message-ID: <1468848651.49.0.804648096873.issue27561@psf.upfronthosting.co.za> New submission from Kirk Hansen: I tried subclassing dict, and overriding its __setitem__ and __getitem__ and got some interesting results. See http://stackoverflow.com/questions/38362420/subclassing-dict-dict-update-returns-incorrrect-value-python-bug?noredirect=1#comment64142710_38362420 for an example. I tried sub-classing UserDict.UserDict and experienced some of the same problems. Eventually, I discovered that subclassing MutableMapping was my best bet. After an hour or two of searching and reading I discovered that CPython will not call overridden built-in methods of the same object (https://pypy.readthedocs.io/en/latest/cpython_differences.html#subclasses-of-built-in-types). This behaviour could (and did) cause some hard to track down bugs in code. I briefly looked at the later versions of python documentation and didn't see a mention of this (sorry if it's there), but python2.7 definitely does not mention this. In fact, python2.7 seems to __encourage__ users to subclass the built-ins (see the note https://docs.python.org/2.7/library/stdtypes.html?highlight=dict#built-in-types). Subclassing dict to __extend__ functionality is great, but there should be a big bad warning when trying to __override__ built-ins like __setitem__ and __getitem__. ---------- assignee: docs at python components: Documentation messages: 270754 nosy: Kirk Hansen, docs at python priority: normal severity: normal status: open title: Warn against subclassing builtins, and overriding their methods type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 09:38:27 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 18 Jul 2016 13:38:27 +0000 Subject: [issue27558] SystemError with bare `raise` in threading or multiprocessing In-Reply-To: <1468823203.61.0.708048243679.issue27558@psf.upfronthosting.co.za> Message-ID: <1468849106.99.0.966878272785.issue27558@psf.upfronthosting.co.za> Xiang Zhang added the comment: Upload a patch. ---------- keywords: +patch Added file: http://bugs.python.org/file43776/issue27558.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 09:48:21 2016 From: report at bugs.python.org (Iovan Irinel) Date: Mon, 18 Jul 2016 13:48:21 +0000 Subject: [issue27562] Import error encodings (Windows xp compatibility) Message-ID: <1468849701.41.0.980015051967.issue27562@psf.upfronthosting.co.za> New submission from Iovan Irinel: I have python embeded intro my application. I wanted to upgrade to python 2.7.12 i use also a static library. Not DLL. I have defined "Py_NO_ENABLE_SHARE" Ok, all work fine with 2.7.6 I want to say this error happen just when i run it under windows xp. Under windows 10 it works , my application start.. Pythoncore and application is build with v140_xp toolset i user visual studio 2015. I can make a video with error if is necessary. Thanks. Traceback (most recent call last): File "Lib/site.py", line 548, in File "Lib/site.py", line 537, in main File "Lib/site.py", line 465, in aliasmbcs File "Lib/locale.py", line 13, in ImportError: No module named encodings I made more test and i come with a reply. ---------- components: Windows messages: 270756 nosy: Iovan Irinel, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Import error encodings (Windows xp compatibility) versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 10:06:20 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 18 Jul 2016 14:06:20 +0000 Subject: [issue27558] SystemError with bare `raise` in threading or multiprocessing In-Reply-To: <1468823203.61.0.708048243679.issue27558@psf.upfronthosting.co.za> Message-ID: <1468850780.9.0.542785902471.issue27558@psf.upfronthosting.co.za> Berker Peksag added the comment: I would prefer Antti's test case in msg270730 since the bug can be reproduced by using threading module (you can use assert_python_ok() as a helper.) Lib/test_threading.py is probably a better place for the test. ---------- nosy: +berker.peksag stage: needs patch -> patch review versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 10:27:43 2016 From: report at bugs.python.org (Ram Rachum) Date: Mon, 18 Jul 2016 14:27:43 +0000 Subject: [issue27563] docs for `gc.get_referrers` should explain the result format (i.e. what keys in the dict mean) Message-ID: <1468852063.19.0.0147283697672.issue27563@psf.upfronthosting.co.za> Changes by Ram Rachum : ---------- assignee: docs at python components: Documentation nosy: cool-RR, docs at python priority: normal severity: normal status: open title: docs for `gc.get_referrers` should explain the result format (i.e. what keys in the dict mean) 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 Jul 18 10:28:47 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Jul 2016 14:28:47 +0000 Subject: [issue27558] SystemError with bare `raise` in threading or multiprocessing In-Reply-To: <1468823203.61.0.708048243679.issue27558@psf.upfronthosting.co.za> Message-ID: <1468852127.26.0.856788979575.issue27558@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 10:29:23 2016 From: report at bugs.python.org (Ram Rachum) Date: Mon, 18 Jul 2016 14:29:23 +0000 Subject: [issue27563] docs for `gc.get_referrers` should explain the result format (i.e. what keys in the dict mean) Message-ID: <1468852163.19.0.0852873955518.issue27563@psf.upfronthosting.co.za> New submission from Ram Rachum: My mistake ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 10:36:43 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 18 Jul 2016 14:36:43 +0000 Subject: [issue27558] SystemError with bare `raise` in threading or multiprocessing In-Reply-To: <1468823203.61.0.708048243679.issue27558@psf.upfronthosting.co.za> Message-ID: <1468852603.17.0.785327186592.issue27558@psf.upfronthosting.co.za> Xiang Zhang added the comment: It's reasonable but I'd still like to hear others' voices since it looks more like to me it's the behaviour of raise itself rather than threading that crashes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 10:43:41 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 18 Jul 2016 14:43:41 +0000 Subject: [issue27561] Warn against subclassing builtins, and overriding their methods In-Reply-To: <1468848651.49.0.804648096873.issue27561@psf.upfronthosting.co.za> Message-ID: <1468853021.11.0.378229204534.issue27561@psf.upfronthosting.co.za> R. David Murray added the comment: Where in the docs do you think such a note should go? I suppose it could go in the intro to the chapter you link to. I doubt many people will find it there, though :( ---------- nosy: +r.david.murray versions: -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 10:52:00 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 18 Jul 2016 14:52:00 +0000 Subject: [issue27558] SystemError with bare `raise` in threading or multiprocessing In-Reply-To: <1468823203.61.0.708048243679.issue27558@psf.upfronthosting.co.za> Message-ID: <1468853520.56.0.407537613128.issue27558@psf.upfronthosting.co.za> R. David Murray added the comment: Since ceval already has such a check, I think we should fix it by adding the check as proposed. Investigating whether the codebase could be simplified by making sure that Py_None is always there after startup would be a separate issue, I think, possibly related to PEP 432. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 11:29:06 2016 From: report at bugs.python.org (Tom Middleton) Date: Mon, 18 Jul 2016 15:29:06 +0000 Subject: [issue27564] 2.7.12 Windows Installer package broken. Message-ID: <1468855746.01.0.612957751077.issue27564@psf.upfronthosting.co.za> New submission from Tom Middleton: I was running: Python 2.7.11 (v2.7.11:6d1b6a68f775, Dec 5 2015, 20:32:19) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. I downloaded the msi for Python 2.7.12 and attempted to run it. During the installation it gave me the following error: "There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor." Then it "rolls back" the action, which killed my current 2.7.11 installation. Despite that it states: "Python 2.7.12 setup ended prematurely because of an error. Your system has not been modified. To install this program at a later time, please run the installation again." (pardon any typos in the error messages since I wasn't able to copy the text directly.) I attempted this twice with the same result. Thanks, Tom ---------- components: Installation messages: 270762 nosy: busfault priority: normal severity: normal status: open title: 2.7.12 Windows Installer package broken. type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 11:30:02 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 18 Jul 2016 15:30:02 +0000 Subject: [issue27558] SystemError with bare `raise` in threading or multiprocessing In-Reply-To: <1468823203.61.0.708048243679.issue27558@psf.upfronthosting.co.za> Message-ID: <1468855802.29.0.993665741726.issue27558@psf.upfronthosting.co.za> Xiang Zhang added the comment: A simple try ... except ... can set the variable to Py_None: >>> import threading >>> def foo(): ... try: ... raise RuntimeError ... except: ... pass ... raise ... >>> threading.Thread(target=foo).start() >>> Exception in thread Thread-1: Traceback (most recent call last): File "/usr/lib/python3.4/threading.py", line 920, in _bootstrap_inner self.run() File "/usr/lib/python3.4/threading.py", line 868, in run self._target(*self._args, **self._kwargs) File "", line 6, in foo RuntimeError: No active exception to reraise In the startup procedure, some c-apis are called and there are patterns like: try: import some_module except ImportError: some_module = ... So I think after startup the variable can't be NULL. But we do see a NULL case here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 11:47:13 2016 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 18 Jul 2016 15:47:13 +0000 Subject: [issue14375] Add socketserver running property In-Reply-To: <1332262391.3.0.759761369976.issue14375@psf.upfronthosting.co.za> Message-ID: <1468856833.24.0.205372544643.issue14375@psf.upfronthosting.co.za> St?phane Wirtel added the comment: what's the status of this issue ? ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 11:50:03 2016 From: report at bugs.python.org (Emanuel Barry) Date: Mon, 18 Jul 2016 15:50:03 +0000 Subject: [issue27364] Deprecate invalid unicode escape sequences In-Reply-To: <1466541260.02.0.320668077341.issue27364@psf.upfronthosting.co.za> Message-ID: <1468857003.73.0.675115134205.issue27364@psf.upfronthosting.co.za> Emanuel Barry added the comment: Here's a new patch which also deprecates invalid escape sequences in bytes. Tests included with test_codecs. Patch includes and supersedes deprecate_invalid_escapes_only_3.patch, and I have not found a single instance of an invalid escape sequence other than in test_codecs, so this should be fine now. ---------- Added file: http://bugs.python.org/file43777/deprecate_invalid_escapes_both_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 11:50:52 2016 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 18 Jul 2016 15:50:52 +0000 Subject: [issue18049] Re-enable threading test on OSX In-Reply-To: <1369405666.05.0.54874731136.issue18049@psf.upfronthosting.co.za> Message-ID: <1468857052.96.0.336737259633.issue18049@psf.upfronthosting.co.za> St?phane Wirtel added the comment: for my part, I think you should use a #ifdef PY_DEBUG in your code and increase the default size of the stack for the threads, and only if you are on APPLE and PY_DEBUG mode. ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 11:58:48 2016 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 18 Jul 2016 15:58:48 +0000 Subject: [issue20767] Some python extensions can't be compiled with clang 3.4 In-Reply-To: <1393335198.15.0.97052317234.issue20767@psf.upfronthosting.co.za> Message-ID: <1468857528.96.0.764645100198.issue20767@psf.upfronthosting.co.za> St?phane Wirtel added the comment: I have checked the status of the FreeBSD issue, and it's "New". What do you think for the fix ? ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 12:02:11 2016 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 18 Jul 2016 16:02:11 +0000 Subject: [issue25910] Fixing links in documentation In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za> Message-ID: <1468857731.21.0.314861948633.issue25910@psf.upfronthosting.co.za> St?phane Wirtel added the comment: maybe we can continue on this issue and close it asap. what do you think ? ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 12:03:08 2016 From: report at bugs.python.org (Iovan Irinel) Date: Mon, 18 Jul 2016 16:03:08 +0000 Subject: [issue27562] Import error encodings (Windows xp compatibility) In-Reply-To: <1468849701.41.0.980015051967.issue27562@psf.upfronthosting.co.za> Message-ID: <1468857788.36.0.57880693375.issue27562@psf.upfronthosting.co.za> Iovan Irinel added the comment: I tested again. And the answer is this: Problem is stati library. I tested: - 2.7.6 - 2.7.7 - 2.7.8 - 2.7.9 - 2.7.10 - 2.7.11 - 2.7.12 This issue happen just when pythoncore is compiled as static library. With DLL it works. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 12:03:53 2016 From: report at bugs.python.org (Zachary Ware) Date: Mon, 18 Jul 2016 16:03:53 +0000 Subject: [issue27564] 2.7.12 Windows Installer package broken. In-Reply-To: <1468855746.01.0.612957751077.issue27564@psf.upfronthosting.co.za> Message-ID: <1468857833.86.0.398195793888.issue27564@psf.upfronthosting.co.za> Zachary Ware added the comment: What happens if you first uninstall 2.7.11 and then install 2.7.12? ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 12:10:48 2016 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 18 Jul 2016 16:10:48 +0000 Subject: [issue10496] Python startup should not require passwd entry In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za> Message-ID: <1468858248.97.0.229261297127.issue10496@psf.upfronthosting.co.za> St?phane Wirtel added the comment: Hi @victor I have compiled the bug.c file with my fedora 24. there is python 2.7.11 and 3.5.1 and I don't have the bug with these versions. What can we do with this issue ? Thanks, Stephane ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 12:31:42 2016 From: report at bugs.python.org (Brett Cannon) Date: Mon, 18 Jul 2016 16:31:42 +0000 Subject: [issue27562] Import error encodings (Windows xp compatibility) In-Reply-To: <1468849701.41.0.980015051967.issue27562@psf.upfronthosting.co.za> Message-ID: <1468859502.47.0.682825241391.issue27562@psf.upfronthosting.co.za> Brett Cannon added the comment: Is the stati library a third-party project? ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 12:37:26 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 18 Jul 2016 16:37:26 +0000 Subject: [issue27564] 2.7.12 Windows Installer package broken. In-Reply-To: <1468855746.01.0.612957751077.issue27564@psf.upfronthosting.co.za> Message-ID: <1468859846.84.0.435385795109.issue27564@psf.upfronthosting.co.za> Steve Dower added the comment: Or if you first repair 2.7.11 and then install 2.7.12. This error often happens because your pip installation is corrupt, and then pip fails to uninstall itself which aborts the whole installation. Generally repairing the install before uninstalling resolves it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 12:41:04 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 18 Jul 2016 16:41:04 +0000 Subject: [issue27562] Import error encodings (Windows xp compatibility) In-Reply-To: <1468849701.41.0.980015051967.issue27562@psf.upfronthosting.co.za> Message-ID: <1468860064.33.0.0931692733728.issue27562@psf.upfronthosting.co.za> Steve Dower added the comment: You're compiling Python in a completely unsupported way right now, so I'm afraid you'll need to submit a patch to get it fixed. Python 2.7 is only officially supported with VC 9.0 (not VC 14.0), and I don't believe the other volunteers test the static library build either, so I'm afraid you're somewhat on your own. That said, if you do find a fix and submit a patch, it may be merged in. However, to even be able to build with VC 14.0 you've probably made a great number of changes that certainly won't be accepted at this stage. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 12:47:50 2016 From: report at bugs.python.org (Brett Cannon) Date: Mon, 18 Jul 2016 16:47:50 +0000 Subject: [issue27562] Import error encodings (Windows xp compatibility) In-Reply-To: <1468849701.41.0.980015051967.issue27562@psf.upfronthosting.co.za> Message-ID: <1468860470.98.0.518827371947.issue27562@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 12:50:46 2016 From: report at bugs.python.org (Tom Middleton) Date: Mon, 18 Jul 2016 16:50:46 +0000 Subject: [issue27564] 2.7.12 Windows Installer package broken. In-Reply-To: <1468855746.01.0.612957751077.issue27564@psf.upfronthosting.co.za> Message-ID: <1468860646.96.0.786781958664.issue27564@psf.upfronthosting.co.za> Tom Middleton added the comment: @Steve, I think my pip install was fine? I was using pip pretty regularly with 2.7.11. I had to do a restore to get 2.7.11 working again, and after an install of 2.7.12 failed again with the same issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 12:53:16 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 18 Jul 2016 16:53:16 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <1468860796.4.0.369659911692.issue24773@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Naoki, thanks for the review. I addressed your comments in https://github.com/abalkin/cpython/commit/a61a25d2dd04336361b2ea676c80afdb2639f579 Attached patch, issue24773-s3-3.diff, incorporates your comments and a few other fixes. See github for the full history. ---------- Added file: http://bugs.python.org/file43778/issue24773-s3-3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 12:59:27 2016 From: report at bugs.python.org (Tom Middleton) Date: Mon, 18 Jul 2016 16:59:27 +0000 Subject: [issue27564] 2.7.12 Windows Installer package broken. In-Reply-To: <1468855746.01.0.612957751077.issue27564@psf.upfronthosting.co.za> Message-ID: <1468861167.81.0.251501136209.issue27564@psf.upfronthosting.co.za> Tom Middleton added the comment: @Zachary, I tried to uninstall (the C:\python27\ directory seemed to persist after) the install of 2.7.12 failed again same message. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 13:18:29 2016 From: report at bugs.python.org (Tom Middleton) Date: Mon, 18 Jul 2016 17:18:29 +0000 Subject: [issue27564] 2.7.12 Windows Installer package broken. In-Reply-To: <1468855746.01.0.612957751077.issue27564@psf.upfronthosting.co.za> Message-ID: <1468862309.16.0.296035283587.issue27564@psf.upfronthosting.co.za> Tom Middleton added the comment: Ok, so really bizarre. I uninstalled 2.7.11, then I was getting the same error with the 2.7.11 msi. So I was thinking that I should go back to the original version I had installed (2.7.10) the installer showed a "repair" option so I did that, then the 2.7.11 install worked. And then the 2.7.12 installer worked. I would have to agree with Steve Dower. I think that it had something to do with pip because there were a couple cmd windows that popped up during the install process that showed something to do with pip which didn't the first time I ran the installer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 14:05:49 2016 From: report at bugs.python.org (Iovan Irinel) Date: Mon, 18 Jul 2016 18:05:49 +0000 Subject: [issue27562] Import error encodings (Windows xp compatibility) In-Reply-To: <1468849701.41.0.980015051967.issue27562@psf.upfronthosting.co.za> Message-ID: <1468865149.35.0.67046896974.issue27562@psf.upfronthosting.co.za> Iovan Irinel added the comment: It's ok for me to use vc .9 but when i try to link it says " This library was created with an older visual stuido toolset " And it trow in a error. And about v140 compatibility i don't maded so much changes. It was 3 minutes of work. Maybe someone take a look, i'm new in c++ development and python too. I don't think i'm able to find a fix. Maybe some ideea about how to make vs2015 to link with a library from vc 9.0 ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 14:17:58 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 18 Jul 2016 18:17:58 +0000 Subject: [issue27562] Import error encodings (Windows xp compatibility) In-Reply-To: <1468849701.41.0.980015051967.issue27562@psf.upfronthosting.co.za> Message-ID: <1468865878.72.0.570381539917.issue27562@psf.upfronthosting.co.za> Steve Dower added the comment: Unfortunately, you can't do that either. Projects including static libraries all need to use the same compiler. So either build python27.dll separately and dynamically link to it (or just use the one that we build and release, and be careful not to mix up memory or file management functions as they will be incompatible), build everything with VS 9.0, or you'll need help to find a fix. Most - possibly all - of our volunteers are not going to be willing to go deep on custom Python 2.7 build issues. You're probably going to have to find someone who can offer paid support. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 14:18:13 2016 From: report at bugs.python.org (Kirk Hansen) Date: Mon, 18 Jul 2016 18:18:13 +0000 Subject: [issue27561] Warn against subclassing builtins, and overriding their methods In-Reply-To: <1468848651.49.0.804648096873.issue27561@psf.upfronthosting.co.za> Message-ID: <1468865893.02.0.92318670769.issue27561@psf.upfronthosting.co.za> Kirk Hansen added the comment: I think it could make sense at the top of the intro. It could also make sense to have it sit https://docs.python.org/2.7/library/stdtypes.html?highlight=dict#mapping-types-dict and have the intro link to it, or vice-versa. Thoughts? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 14:27:37 2016 From: report at bugs.python.org (Iovan Irinel) Date: Mon, 18 Jul 2016 18:27:37 +0000 Subject: [issue27562] Import error encodings (Windows xp compatibility) In-Reply-To: <1468849701.41.0.980015051967.issue27562@psf.upfronthosting.co.za> Message-ID: <1468866457.79.0.738206126457.issue27562@psf.upfronthosting.co.za> Iovan Irinel added the comment: Thanks, i don't think is a big issue. Because on windows 7, 8 , 8.1 , 10 it works. Just with windows xp i have this issue. It's ok paid. No problem, soo if someone want to fix for me this : Sure paid contact me please. And someone want to do it free contact me too and we will submit a patch to help all users. Even paid i will share the fix. Regards. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 15:09:10 2016 From: report at bugs.python.org (Jim Fulton) Date: Mon, 18 Jul 2016 19:09: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: <1468868950.44.0.368660288095.issue27392@psf.upfronthosting.co.za> Jim Fulton added the comment: Does the draft doc change look OK? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 15:31:04 2016 From: report at bugs.python.org (Claudiu Saftoiu) Date: Mon, 18 Jul 2016 19:31:04 +0000 Subject: [issue27565] Offer error context manager for code.interact Message-ID: <1468870264.4.0.689422874662.issue27565@psf.upfronthosting.co.za> New submission from Claudiu Saftoiu: When debugging code that raises unexpected exceptions, I often find myself doing this: try: some_code except: import code; code.interact(local=locals()) raise My suggestion is a context manager to make this less verbose: with code.interact_on_error(): some_code The effect would be the same: if an exception is caught, `code.interact` is called with the locals of the function, and re-raised when `code.interact` ends. ---------- components: Library (Lib) messages: 270786 nosy: Claudiu Saftoiu priority: normal severity: normal status: open title: Offer error context manager for code.interact type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 15:40:30 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Jul 2016 19:40:30 +0000 Subject: [issue27469] Unicode filename gets crippled on Windows when drag and drop In-Reply-To: <1467992332.72.0.0240653508758.issue27469@psf.upfronthosting.co.za> Message-ID: <1468870830.27.0.412195363859.issue27469@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: -haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 15:50:39 2016 From: report at bugs.python.org (David D) Date: Mon, 18 Jul 2016 19:50:39 +0000 Subject: [issue27566] Freeze: winmakemakefile.py: clean: Linux instead of Windows command Message-ID: <1468871439.96.0.540268707664.issue27566@psf.upfronthosting.co.za> New submission from David D: The command for the clean target in the Windows makefile is the same as the one in the Linux one: using `rm -f`. Should be changed to `del /f` or `erase /f`. ---------- components: Demos and Tools, Windows messages: 270787 nosy: David D, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Freeze: winmakemakefile.py: clean: Linux instead of Windows command 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 Jul 18 15:53:43 2016 From: report at bugs.python.org (Zachary Ware) Date: Mon, 18 Jul 2016 19:53:43 +0000 Subject: [issue27566] Tools/freeze/winmakemakefile.py clean target should use 'del' instead of 'rm' In-Reply-To: <1468871439.96.0.540268707664.issue27566@psf.upfronthosting.co.za> Message-ID: <1468871623.16.0.621097664497.issue27566@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- keywords: +easy stage: -> needs patch title: Freeze: winmakemakefile.py: clean: Linux instead of Windows command -> Tools/freeze/winmakemakefile.py clean target should use 'del' instead of 'rm' versions: -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 16:00:36 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Mon, 18 Jul 2016 20:00:36 +0000 Subject: [issue27567] Add constants EPOLLRDHUP and EPOLLHUP to module select. Message-ID: <1468872036.69.0.576706331519.issue27567@psf.upfronthosting.co.za> New submission from ???? ?????????: These constants are supported since Linux kernel 2.6.17 ---------- messages: 270788 nosy: mmarkk priority: normal severity: normal status: open title: Add constants EPOLLRDHUP and EPOLLHUP to module select. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 16:01:05 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Mon, 18 Jul 2016 20:01:05 +0000 Subject: [issue27567] Add constants EPOLLRDHUP and EPOLLHUP to module select. In-Reply-To: <1468872036.69.0.576706331519.issue27567@psf.upfronthosting.co.za> Message-ID: <1468872065.26.0.354119742289.issue27567@psf.upfronthosting.co.za> Changes by ???? ????????? : ---------- components: +Library (Lib) type: -> enhancement versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 16:15:09 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 18 Jul 2016 20:15:09 +0000 Subject: [issue27561] Warn against subclassing builtins, and overriding their methods In-Reply-To: <1468848651.49.0.804648096873.issue27561@psf.upfronthosting.co.za> Message-ID: <1468872909.12.0.413260198709.issue27561@psf.upfronthosting.co.za> R. David Murray added the comment: It doesn't just apply to dicts, it applies to all the built in collection types (and possibly to other built in types). But not to all the methods, which will make the documentation somewhat vague ("you may not be able to successfully override base class methods such as __setitem__...") Oh, and I suppose it needs to be marked as a CPython implementation detail. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 17:31:02 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 18 Jul 2016 21:31:02 +0000 Subject: [issue27561] Warn against subclassing builtins, and overriding their methods In-Reply-To: <1468848651.49.0.804648096873.issue27561@psf.upfronthosting.co.za> Message-ID: <1468877462.62.0.452551221369.issue27561@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This is an example of the open-closed-principle (the class is open for extension but closed for modification). It is good thing to have because it allows subclassers to extend or override a method without unintentionally triggering behavior changes in others and without breaking the classes's invariants. We even do this in pure python code as well; for example, inside the pure python ordered dict code, the class local call from __init__ to update() is done using name mangling. This allows a subclasser to override update() without accidentally breaking __init__. Sometimes, this is inconvenient. It means that a subclasser has to override every method whose behavior they want to change including get(), update(), and others. However, there are offsetting benefits (protection of internal invariants, preventing implementation details from leaking from the abstraction, and allowing users to assume the methods are independent of one another). This style (chosen by Guido from the outset) is the default for the builtin types (otherwise we would forever be fighting segfaulting invariant violations) and for some pure python classes. We do document when there is a departure from the default. For example, the cmd module uses the framework design pattern, letting the user define various do_action() methods. Also, some of the http modules do the same, specifically documentation that the user's do_get method gets called and that some specifically named user handler method gets called. In the absence of specifically documented method hooks (i.e. those listed above or methods like __missing__), a subclasser should presume method independence. Otherwise, how are you to know whether __getitem__ calls get() under the hood or vice-versa? FWIW, this isn't unique to Python. It comes up quite a bit in object oriented programming. Correctly designed classes either document root methods that affect the behavior of other methods or they are presumed to be independent. There may need to be a FAQ for this, but nothing is broken or wrong here (other than Python having way to many dict variants to chose from). Also, R David Murray almost no one would be helped by a note in some random place in the docs. If someone assumes or believes that __getitem__ must be called by the other accessor methods, they find out very quickly that assumption is wrong (that is if they run even minimal tests on the code). ---------- assignee: docs at python -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 17:31:24 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 18 Jul 2016 21:31:24 +0000 Subject: [issue27561] Warn against subclassing builtins, and overriding their methods In-Reply-To: <1468848651.49.0.804648096873.issue27561@psf.upfronthosting.co.za> Message-ID: <1468877484.76.0.256274629203.issue27561@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 17:33:30 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 18 Jul 2016 21:33:30 +0000 Subject: [issue26380] Add an http method enum In-Reply-To: <1455776645.01.0.0347855430312.issue26380@psf.upfronthosting.co.za> Message-ID: <1468877610.58.0.11612317689.issue26380@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I concur that the enum adding nothing of value here. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 17:50:11 2016 From: report at bugs.python.org (Ethan Furman) Date: Mon, 18 Jul 2016 21:50:11 +0000 Subject: [issue26380] Add an http method enum In-Reply-To: <1455776645.01.0.0347855430312.issue26380@psf.upfronthosting.co.za> Message-ID: <1468878611.94.0.103887427854.issue26380@psf.upfronthosting.co.za> Ethan Furman added the comment: That was the last nudge I needed. Thanks, everyone. ---------- assignee: -> ethan.furman resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 17:52:05 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 18 Jul 2016 21:52:05 +0000 Subject: [issue27561] Warn against subclassing builtins, and overriding their methods In-Reply-To: <1468848651.49.0.804648096873.issue27561@psf.upfronthosting.co.za> Message-ID: <1468878725.27.0.53190966909.issue27561@psf.upfronthosting.co.za> R. David Murray added the comment: Raymond: yes, I was dubious about the benefit of the doc note. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 18:01:22 2016 From: report at bugs.python.org (Julien) Date: Mon, 18 Jul 2016 22:01:22 +0000 Subject: [issue27542] Segfault in gcmodule.c:360 visit_decref In-Reply-To: <1468755086.8.0.27245311458.issue27542@psf.upfronthosting.co.za> Message-ID: <1468879282.24.0.95727870971.issue27542@psf.upfronthosting.co.za> Julien added the comment: At cffi they thinks the bug may be from cpython or pip, as ``` $ python -m pip install --user cffi Collecting cffi Using cached cffi-1.7.0-cp27-cp27mu-manylinux1_x86_64.whl Collecting pycparser (from cffi) Installing collected packages: pycparser, cffi Successfully installed cffi-1.7.0 pycparser-2.14 Segmentation fault (core dumped) ``` may not import cffi. c.f.: https://bitbucket.org/cffi/cffi/issues/272/segfault-while-installing-via-pip#comment-29256302 ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 18:30:13 2016 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Rampin?=) Date: Mon, 18 Jul 2016 22:30:13 +0000 Subject: [issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts Message-ID: <1468881013.81.0.152859673137.issue27568@psf.upfronthosting.co.za> New submission from R?mi Rampin: https://httpoxy.org/ It is possible to set the HTTP_PROXY in CGI scripts by passing the Proxy header. If the script is a Python script and downloads files, urllib will happily use the attacker-supplied proxy to make requests. This should be mitigated like it is in Perl (since 2001), Ruby, and libraries like curl. See also: bug against python-requests https://github.com/kennethreitz/requests/issues/3422 ---------- components: Library (Lib) messages: 270795 nosy: remram priority: normal severity: normal status: open title: "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 18:31:03 2016 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Rampin?=) Date: Mon, 18 Jul 2016 22:31:03 +0000 Subject: [issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts In-Reply-To: <1468881013.81.0.152859673137.issue27568@psf.upfronthosting.co.za> Message-ID: <1468881063.73.0.533160917887.issue27568@psf.upfronthosting.co.za> Changes by R?mi Rampin : ---------- keywords: +patch Added file: http://bugs.python.org/file43779/python-2.7-httpoxy-mitigation.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 18:31:20 2016 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Rampin?=) Date: Mon, 18 Jul 2016 22:31:20 +0000 Subject: [issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts In-Reply-To: <1468881013.81.0.152859673137.issue27568@psf.upfronthosting.co.za> Message-ID: <1468881080.1.0.176464278208.issue27568@psf.upfronthosting.co.za> Changes by R?mi Rampin : Added file: http://bugs.python.org/file43780/python-3.5-httpoxy-mitigation.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 18:47:04 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 18 Jul 2016 22:47:04 +0000 Subject: [issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts In-Reply-To: <1468881013.81.0.152859673137.issue27568@psf.upfronthosting.co.za> Message-ID: <1468882024.52.0.943874008072.issue27568@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +orsenthil stage: -> patch review type: enhancement -> security versions: +Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 18:48:49 2016 From: report at bugs.python.org (Ned Deily) Date: Mon, 18 Jul 2016 22:48:49 +0000 Subject: [issue27542] Segfault in gcmodule.c:360 visit_decref In-Reply-To: <1468755086.8.0.27245311458.issue27542@psf.upfronthosting.co.za> Message-ID: <1468882129.9.0.268478967249.issue27542@psf.upfronthosting.co.za> Ned Deily added the comment: IMO, there are too many possible scenarios here where a segfault could be caused by the Debian patches, by pip, by wheel, or by cffi - too many to assume a CPython problem. FWIW, I am unable to reproduce the segfault on a pretty current Debian testing system using a vanilla built-from-source Python 2.7.12 and the currently available wheel on PyPI and, for that matter, I'm unable to reproduce using a current Debian python2.7.12-1/pip 8.1.2-2/wheel 0.29.0-1. Unless someone can provide a reproducible test case that points to a Python problem using a vanilla Python 2.7.12, the issue will have to remain closed as we just don't have the resources to try to isolate every problem like this. Sorry! ---------- resolution: third party -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 19:54:37 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 18 Jul 2016 23:54:37 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <1468886077.9.0.46060275293.issue24773@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: The new patch passes test_datetime on Windows. This was the last stumbling block for me to commit this patch. Unless anyone would ask for more time to review, I plan to commit later this week. ---------- Added file: http://bugs.python.org/file43781/issue24773-s3-4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 20:27:28 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 19 Jul 2016 00:27:28 +0000 Subject: [issue25591] refactor imaplib tests In-Reply-To: <1447107407.81.0.130095933409.issue25591@psf.upfronthosting.co.za> Message-ID: <1468888048.16.0.850644044381.issue25591@psf.upfronthosting.co.za> R. David Murray added the comment: Reitveld can diff patchsets, so I used that for review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 21:17:48 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 19 Jul 2016 01:17:48 +0000 Subject: [issue14375] Add socketserver running property In-Reply-To: <1332262391.3.0.759761369976.issue14375@psf.upfronthosting.co.za> Message-ID: <1468891068.76.0.456162350763.issue14375@psf.upfronthosting.co.za> Martin Panter added the comment: Some responses to the issues raised by Terry would be helpful, especially the incompatibility by adding the RuntimeError. It looks like it forces a race on the normal usage of shutdown(). See also Issue 12463: it seems different people have different ideas about what this method should do. Without understanding the motivation(s), I can?t really suggest anything better. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 21:22:00 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 19 Jul 2016 01:22:00 +0000 Subject: [issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts In-Reply-To: <1468881013.81.0.152859673137.issue27568@psf.upfronthosting.co.za> Message-ID: <1468891320.29.0.885131821769.issue27568@psf.upfronthosting.co.za> Martin Panter added the comment: I suspect this won?t help on OSes like Windows where environment variable names are case-insensitive (correct me if I am wrong). Regardless, it may be worth making the change. It would be nice to also add test case(s). And I wonder if it would be appropriate to add a notice to the documentation saying that uppercase HTTP_PROXY is ignored if REQUEST_METHOD exists. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 21:47:21 2016 From: report at bugs.python.org (Ricardo Esperanza) Date: Tue, 19 Jul 2016 01:47:21 +0000 Subject: [issue27569] Windows install problems Message-ID: <1468892841.27.0.521360350751.issue27569@psf.upfronthosting.co.za> New submission from Ricardo Esperanza: Downloaded 3.5.2 package and recived following errors during install also tried with 3.6 version and got same errors Using Win 10 X64 attached complete log [13A0:26B4][2016-07-18T22:40:59]i305: Verified acquired payload: exe_JustForMe at path: C:\Users\Ricardo\AppData\Local\Package Cache\.unverified\exe_JustForMe, moving to: C:\Users\Ricardo\AppData\Local\Package Cache\{33B10015-A9B1-4210-B50A-26C6443979B0}v3.5.2150.0\exe.msi. [13A0:0EE0][2016-07-18T22:40:59]e000: Error 0x80070643: Failed to install MSI package. [13A0:0EE0][2016-07-18T22:40:59]e000: Error 0x80070643: Failed to configure per-user MSI package. [13A0:0EE0][2016-07-18T22:40:59]i319: Applied execute package: core_JustForMe, result: 0x80070643, restart: None [13A0:0EE0][2016-07-18T22:40:59]e000: Error 0x80070643: Failed to execute MSI package. [13A0:0EE0][2016-07-18T22:40:59]i318: Skipped rollback of package: core_JustForMe, action: Uninstall, already: Absent ---------- components: Installation files: Python 3.5.2 (32-bit)_20160718224049.log messages: 270801 nosy: ricardoe priority: normal severity: normal status: open title: Windows install problems versions: Python 3.5 Added file: http://bugs.python.org/file43782/Python 3.5.2 (32-bit)_20160718224049.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 21:54:31 2016 From: report at bugs.python.org (Zachary Ware) Date: Tue, 19 Jul 2016 01:54:31 +0000 Subject: [issue27569] Windows install problems In-Reply-To: <1468892841.27.0.521360350751.issue27569@psf.upfronthosting.co.za> Message-ID: <1468893271.41.0.0535832637796.issue27569@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- assignee: -> steve.dower components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 22:11:09 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 19 Jul 2016 02:11:09 +0000 Subject: [issue27569] Windows install problems In-Reply-To: <1468892841.27.0.521360350751.issue27569@psf.upfronthosting.co.za> Message-ID: <1468894269.34.0.611676016268.issue27569@psf.upfronthosting.co.za> Steve Dower added the comment: You should have another log file for "core_JustForMe" near the one you uploaded. Could you include that one too? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 22:26:35 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 19 Jul 2016 02:26:35 +0000 Subject: [issue26207] distutils msvccompiler fails due to mspdb140.dll error on debug builds In-Reply-To: <1453813782.88.0.185045860262.issue26207@psf.upfronthosting.co.za> Message-ID: <1468895195.61.0.534608178227.issue26207@psf.upfronthosting.co.za> Steve Dower added the comment: We're a couple more updates along and it all seems good. ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 22:51:18 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 19 Jul 2016 02:51:18 +0000 Subject: [issue27528] Document that filterwarnings(message=...) matches the start of a message In-Reply-To: <1468655270.19.0.264691959865.issue27528@psf.upfronthosting.co.za> Message-ID: <20160719025114.79671.523.EA013377@psf.io> Roundup Robot added the comment: New changeset 739f638bb9f8 by Martin Panter in branch '2.7': Issue #27528: Document and test warning messages must match at beginning https://hg.python.org/cpython/rev/739f638bb9f8 New changeset 7571432200a2 by Martin Panter in branch '3.5': Issue #27528: Document and test warning messages must match at beginning https://hg.python.org/cpython/rev/7571432200a2 New changeset e0761e817deb by Martin Panter in branch 'default': Issue #27528: Merge warning doc and test from 3.5 https://hg.python.org/cpython/rev/e0761e817deb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 22:54:58 2016 From: report at bugs.python.org (Ricardo Esperanza) Date: Tue, 19 Jul 2016 02:54:58 +0000 Subject: [issue27569] Windows install problems In-Reply-To: <1468892841.27.0.521360350751.issue27569@psf.upfronthosting.co.za> Message-ID: <1468896898.72.0.944505638119.issue27569@psf.upfronthosting.co.za> Ricardo Esperanza added the comment: attaching justforme. log ---------- Added file: http://bugs.python.org/file43783/Python 3.5.2 (32-bit)_20160718232956_000_core_JustForMe.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 22:57:10 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 19 Jul 2016 02:57:10 +0000 Subject: [issue27570] Avoid memcpy(. . ., NULL, 0) etc calls Message-ID: <1468897030.77.0.552858173381.issue27570@psf.upfronthosting.co.za> New submission from Martin Panter: This patch fixes errors reported by GCC?s undefined behaviour sanitizer about calling functions with a null pointer: ./configure CC="gcc -fsanitize=undefined" Using Issue 22605 as a precedent, I propose to avoid calling memcpy() and memmove() for zero-length copies when there may be a null pointer. ---------- components: Interpreter Core, ctypes files: memcpy-null.patch keywords: patch messages: 270806 nosy: martin.panter priority: normal severity: normal stage: patch review status: open title: Avoid memcpy(. . ., NULL, 0) etc calls type: behavior versions: Python 2.7, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43784/memcpy-null.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 23:09:15 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 19 Jul 2016 03:09:15 +0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <20160719030912.31697.50056.3F405399@psf.io> Roundup Robot added the comment: New changeset d6a86018ab33 by Martin Panter in branch 'default': Issue #1621: Avoid signed int negation overflow in audioop https://hg.python.org/cpython/rev/d6a86018ab33 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 23:18:46 2016 From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=) Date: Tue, 19 Jul 2016 03:18:46 +0000 Subject: [issue27539] negative Fraction ** negative int not normalized In-Reply-To: <1468740731.71.0.38394274484.issue27539@psf.upfronthosting.co.za> Message-ID: <1468898326.74.0.154897920852.issue27539@psf.upfronthosting.co.za> Vedran ?a?i? added the comment: Unfortunately, until now I was just a happy user of Python. I suppose some day I would have to give something back, and now is as good a day as any:-), but I have studied https://docs.python.org/devguide/ for a while and it seems really scary. It means I have to install and get acquainted with Mercurial [BTW I thought Python was on git since this year, it seems PEP 481 was just wishful thinking:(], and probably with Visual Studio since I use Windows - and I have never successfully installed that (I have some weird academic Windows licence it doesn't like, and it seems really hard to install for a single non-admin user, which is a must since this is actually not my machine:). So, let's put the cards on the table: if the idea of your post was to initiate me in the process of becoming a good open-source citizen, then I'll bite the bullet and try to do everything in my power to actually get my equipment into a state where I can contribute to Python - but it will take time. On the other hand, if the idea was to just fix the bug in time for 3.6b1, it would be a great deal simpler if you wrote the patch. :-/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 23:35:38 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 19 Jul 2016 03:35:38 +0000 Subject: [issue27528] Document that filterwarnings(message=...) matches the start of a message In-Reply-To: <1468655270.19.0.264691959865.issue27528@psf.upfronthosting.co.za> Message-ID: <1468899338.8.0.558807140893.issue27528@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 23:44:38 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 19 Jul 2016 03:44:38 +0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1468899878.62.0.169122086271.issue1621@psf.upfronthosting.co.za> Martin Panter added the comment: I committed the fix for negation in audioop. slice-step.patch includes a better fix for the remaining part of trapv.patch, with Element Tree slicing. I think this fix is much less intrusive, and I have copied it to other places that handle slicing, and added corresponding test cases. The undefined behaviour sanitizer produces lots of errors about bit shifting signed integers in low-level modules like ctypes, struct, audioop. Typically this is for code converting signed integers to and from bytes, and big/little-endian conversions. This is technically undefined behaviour, but I think it may be less serious than the other overflows with traditional arithmetic like addition and multiplication. E.g. GCC explicitly documents that this is handled as expected with twos-complement, so with GCC there should be no nasty surprises with optimizing out undefined behaviour. My set-overflow.patch would also be in this boat. ---------- versions: +Python 3.6 Added file: http://bugs.python.org/file43785/slice-step.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 23:53:39 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 19 Jul 2016 03:53:39 +0000 Subject: [issue27569] Windows install problems In-Reply-To: <1468892841.27.0.521360350751.issue27569@psf.upfronthosting.co.za> Message-ID: <1468900419.03.0.534410232653.issue27569@psf.upfronthosting.co.za> Steve Dower added the comment: Hmm... very unusual to get this error code without more information about what failed - the log file is oddly empty. Do you perhaps need to reboot your machine to finish installing some other program or update? Do you have an earlier version of Python 3.5 installed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 00:14:13 2016 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Rampin?=) Date: Tue, 19 Jul 2016 04:14:13 +0000 Subject: [issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts In-Reply-To: <1468881013.81.0.152859673137.issue27568@psf.upfronthosting.co.za> Message-ID: <1468901653.34.0.864486913618.issue27568@psf.upfronthosting.co.za> R?mi Rampin added the comment: I am willing to work on documentation and tests if there is an interest in the patch. On Windows, if REQUEST_METHOD is set, it is probably safe to assume that HTTP_* variables come from the web server: setting this variable is not the way we set a proxy there, so ignoring this dubious variable is probably fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 00:31:03 2016 From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=) Date: Tue, 19 Jul 2016 04:31:03 +0000 Subject: [issue27539] negative Fraction ** negative int not normalized In-Reply-To: <1468740731.71.0.38394274484.issue27539@psf.upfronthosting.co.za> Message-ID: <1468902663.29.0.664966634379.issue27539@psf.upfronthosting.co.za> Vedran ?a?i? added the comment: If it is of any help, here is the patch I wrote online: http://www.mergely.com/TwCVpiFp/ (also in attachment). I also took the liberty of properly isolating the _normalize argument by requiring it to be keyword-only (starting its name with underscore doesn't mean much if people could just call e.g. `Fraction(2, 3, 4)` without error). ---------- keywords: +patch Added file: http://bugs.python.org/file43786/TwCVpiFp.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 00:47:54 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 19 Jul 2016 04:47:54 +0000 Subject: [issue27567] Add constants EPOLLRDHUP and EPOLLHUP to module select. In-Reply-To: <1468872036.69.0.576706331519.issue27567@psf.upfronthosting.co.za> Message-ID: <20160719044749.22708.85586.CE0A8A78@psf.io> Roundup Robot added the comment: New changeset af98e92f3b30 by Benjamin Peterson in branch 'default': expose EPOLLRDHUP (closes #27567) https://hg.python.org/cpython/rev/af98e92f3b30 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 02:54:30 2016 From: report at bugs.python.org (Maciej Szulik) Date: Tue, 19 Jul 2016 06:54:30 +0000 Subject: [issue25591] refactor imaplib tests In-Reply-To: <1447107407.81.0.130095933409.issue25591@psf.upfronthosting.co.za> Message-ID: <1468911270.96.0.539056517996.issue25591@psf.upfronthosting.co.za> Maciej Szulik added the comment: Thanks, I'll try to update the patch in the following days. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 03:03:03 2016 From: report at bugs.python.org (Decorater) Date: Tue, 19 Jul 2016 07:03:03 +0000 Subject: [issue27571] 3.6 Seems to be ignoring all pyd's installed and compiled by pip Message-ID: <1468911783.53.0.349371581627.issue27571@psf.upfronthosting.co.za> New submission from Decorater: in 3.5 the following would succed: >>>import nacl._sodium None but in 3.6 (I even compiled it for 3.6 specifically) this happens: >>>import nacl._sodium Traceback (most recent call last): import nacl._sodium ImportError: No module named 'nacl._sodium' ---------- messages: 270815 nosy: Decorater priority: normal severity: normal status: open title: 3.6 Seems to be ignoring all pyd's installed and compiled by pip versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 03:04:43 2016 From: report at bugs.python.org (Decorater) Date: Tue, 19 Jul 2016 07:04:43 +0000 Subject: [issue27571] 3.6 Seems to be ignoring all pyd's installed and compiled by pip In-Reply-To: <1468911783.53.0.349371581627.issue27571@psf.upfronthosting.co.za> Message-ID: <1468911883.78.0.487871279859.issue27571@psf.upfronthosting.co.za> Changes by Decorater : Added file: http://bugs.python.org/file43787/_sodium.cp36-win_amd64.pyd _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 03:05:35 2016 From: report at bugs.python.org (Decorater) Date: Tue, 19 Jul 2016 07:05:35 +0000 Subject: [issue27571] 3.6 Seems to be ignoring all pyd's installed and compiled by pip In-Reply-To: <1468911783.53.0.349371581627.issue27571@psf.upfronthosting.co.za> Message-ID: <1468911935.63.0.542180962178.issue27571@psf.upfronthosting.co.za> Decorater added the comment: Attacked are the 2 versions of _sodium for PyNacl that it seems to not be able to find. ---------- Added file: http://bugs.python.org/file43788/_sodium.cp36-win32.pyd _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 03:11:01 2016 From: report at bugs.python.org (Decorater) Date: Tue, 19 Jul 2016 07:11:01 +0000 Subject: [issue27571] 3.6 Seems to be ignoring the _sodium pyd file made with pip. In-Reply-To: <1468911783.53.0.349371581627.issue27571@psf.upfronthosting.co.za> Message-ID: <1468912261.51.0.152836005377.issue27571@psf.upfronthosting.co.za> Decorater added the comment: It dooes work foor _cffi_backend however on reading it so this issue is only on nacl._sodium then. ---------- title: 3.6 Seems to be ignoring all pyd's installed and compiled by pip -> 3.6 Seems to be ignoring the _sodium pyd file made with pip. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 04:56:16 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 19 Jul 2016 08:56:16 +0000 Subject: [issue27572] Support bytes-like objects when base is given to int() Message-ID: <1468918576.73.0.596747914515.issue27572@psf.upfronthosting.co.za> New submission from Xiang Zhang: Right now, int() supports bytes-like objects when *base* is not given: >>> int(memoryview(b'100')) 100 When *base* is given bytes-like objects are not supported: >>> int(memoryview(b'100'), base=2) Traceback (most recent call last): File "", line 1, in TypeError: int() can't convert non-string with explicit base Is there any obvious reason not to support it when *base* is given? I suggest add it. ---------- components: Interpreter Core files: bytes_like_support_to_int.patch keywords: patch messages: 270818 nosy: martin.panter, xiang.zhang priority: normal severity: normal status: open title: Support bytes-like objects when base is given to int() versions: Python 3.6 Added file: http://bugs.python.org/file43789/bytes_like_support_to_int.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 04:56:23 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 19 Jul 2016 08:56:23 +0000 Subject: [issue27572] Support bytes-like objects when base is given to int() In-Reply-To: <1468918576.73.0.596747914515.issue27572@psf.upfronthosting.co.za> Message-ID: <1468918583.86.0.816085171422.issue27572@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 05:01:44 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 19 Jul 2016 09:01:44 +0000 Subject: [issue27572] Support bytes-like objects when base is given to int() In-Reply-To: <1468918576.73.0.596747914515.issue27572@psf.upfronthosting.co.za> Message-ID: <1468918904.16.0.741587656092.issue27572@psf.upfronthosting.co.za> Changes by Xiang Zhang : Removed file: http://bugs.python.org/file43789/bytes_like_support_to_int.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 05:01:58 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 19 Jul 2016 09:01:58 +0000 Subject: [issue27572] Support bytes-like objects when base is given to int() In-Reply-To: <1468918576.73.0.596747914515.issue27572@psf.upfronthosting.co.za> Message-ID: <1468918918.8.0.0758696249943.issue27572@psf.upfronthosting.co.za> Changes by Xiang Zhang : Added file: http://bugs.python.org/file43790/bytes_like_support_to_int.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 05:45:43 2016 From: report at bugs.python.org (Cory Benfield) Date: Tue, 19 Jul 2016 09:45:43 +0000 Subject: [issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts In-Reply-To: <1468881013.81.0.152859673137.issue27568@psf.upfronthosting.co.za> Message-ID: <1468921543.53.0.803784104972.issue27568@psf.upfronthosting.co.za> Cory Benfield added the comment: I like this patch a great deal, I'll happily review it with docs and tests. ---------- nosy: +Lukasa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 07:44:01 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Tue, 19 Jul 2016 11:44:01 +0000 Subject: [issue27567] Add constants EPOLLRDHUP and POLLRDHUP to module select. In-Reply-To: <1468872036.69.0.576706331519.issue27567@psf.upfronthosting.co.za> Message-ID: <1468928641.01.0.0723490516738.issue27567@psf.upfronthosting.co.za> ???? ????????? added the comment: Thanks, but POLLRDHUP is also missing...I have typo in subject(fixed) ---------- title: Add constants EPOLLRDHUP and EPOLLHUP to module select. -> Add constants EPOLLRDHUP and POLLRDHUP to module select. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 07:44:28 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Tue, 19 Jul 2016 11:44:28 +0000 Subject: [issue27567] Add constants EPOLLRDHUP and POLLRDHUP to module select. In-Reply-To: <1468872036.69.0.576706331519.issue27567@psf.upfronthosting.co.za> Message-ID: <1468928668.03.0.0952302670173.issue27567@psf.upfronthosting.co.za> Changes by ???? ????????? : ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 08:30:43 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Tue, 19 Jul 2016 12:30:43 +0000 Subject: [issue27561] Warn against subclassing builtins, and overriding their methods In-Reply-To: <1468848651.49.0.804648096873.issue27561@psf.upfronthosting.co.za> Message-ID: <1468931443.46.0.425044344537.issue27561@psf.upfronthosting.co.za> Steven D'Aprano added the comment: Raymond, that was a fantastic explanation. Would you be willing to turn it into a FAQ? Or if you don't have the time, to allow somebody to steal your description and use it? ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 08:43:15 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 Jul 2016 12:43:15 +0000 Subject: [issue20932] Undefined behavior flagged by Clang 3.4 (Python 3.5 from hg) In-Reply-To: <1394851052.88.0.193633571289.issue20932@psf.upfronthosting.co.za> Message-ID: <1468932195.95.0.308339368443.issue20932@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 08:55:40 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Tue, 19 Jul 2016 12:55:40 +0000 Subject: [issue27573] code.interact() should print an exit message Message-ID: <1468932940.76.0.523388198835.issue27573@psf.upfronthosting.co.za> New submission from Steven D'Aprano: Way too often I've lost track of whether I'm in the code.interact() REPL or the original REPL, or hit Ctrl-D once too often, and accidentally quit the real REPL. It is easy to lose track, since the real and imitation REPL both use the same prompts. It would be useful if code.interact() and the InteractiveConsole printed a message when they exited. ---------- components: Library (Lib) files: code.patch keywords: patch messages: 270822 nosy: steven.daprano priority: normal severity: normal status: open title: code.interact() should print an exit message type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43791/code.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 08:57:32 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 Jul 2016 12:57:32 +0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1468933052.42.0.800555566552.issue1621@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Does this work with negative steps? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 09:16:47 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 19 Jul 2016 13:16:47 +0000 Subject: [issue26662] configure/Makefile doesn't check if "python" command works, needed to build Objects/typeslots.inc In-Reply-To: <1459247902.98.0.893274525942.issue26662@psf.upfronthosting.co.za> Message-ID: <1468934207.97.0.947818462502.issue26662@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Following (and thanks to :) Martin's review and comments, this new patch: * does not use the not portable '-e' echo option * uses single quotes (') to avoid the escaping * improves the error message ?make touch? does not always fix the problem, for example when Objects/typeslots.py has been modified or when this file has been touched, so it is not mentioned in the error message. ---------- Added file: http://bugs.python.org/file43792/py_for_gen_26662_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 09:34:59 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Tue, 19 Jul 2016 13:34:59 +0000 Subject: [issue27573] code.interact() should print an exit message In-Reply-To: <1468932940.76.0.523388198835.issue27573@psf.upfronthosting.co.za> Message-ID: <1468935299.03.0.287325786979.issue27573@psf.upfronthosting.co.za> Changes by Steven D'Aprano : Removed file: http://bugs.python.org/file43791/code.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 09:36:23 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Tue, 19 Jul 2016 13:36:23 +0000 Subject: [issue27573] code.interact() should print an exit message In-Reply-To: <1468932940.76.0.523388198835.issue27573@psf.upfronthosting.co.za> Message-ID: <1468935383.59.0.924886495758.issue27573@psf.upfronthosting.co.za> Steven D'Aprano added the comment: This time, with a patch that includes updated tests. ---------- Added file: http://bugs.python.org/file43793/code.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 09:56:48 2016 From: report at bugs.python.org (=?utf-8?q?Anders_Hovm=C3=B6ller?=) Date: Tue, 19 Jul 2016 13:56:48 +0000 Subject: [issue24954] No way to generate or parse timezone as produced by datetime.isoformat() In-Reply-To: <1468689986.08.0.967481929415.issue24954@psf.upfronthosting.co.za> Message-ID: Anders Hovm?ller added the comment: > The `arrow` library depends on the supposed "strict" behaviour of strptime that has never been guaranteed, which often results in very buggy behaviour under some conditions. Well? the arrow library accepts all sorts of broken input and gives you a date back. I think they even think that?s a feature and not a bug so no use in trying to help people who are adamant that they don?t want to be helped :/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 10:06:40 2016 From: report at bugs.python.org (Antti Haapala) Date: Tue, 19 Jul 2016 14:06:40 +0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1468937200.88.0.141188278801.issue1621@psf.upfronthosting.co.za> Antti Haapala added the comment: About shifts, according to C standard, right shifts >> of negative numbers are implementation-defined: "[in E1 >> E2], If E1 has a signed type and a negative value, the resulting value is implementation-defined." In K&R this meant that the number can be either zero-extended or sign-extended. In any case it cannot lead to undefined behaviour, but the implementation must document what is happening there. Now, GCC says that >> is always arithmetic/sign-extended. This is the implementation-defined behaviour, now GCC has defined what its implementation will do, but some implementation can choose zero-extension. (unlikely) As for the other part as it says "GCC does not use the latitude given in C99 only to treat certain aspects of signed ?< _______________________________________ From report at bugs.python.org Tue Jul 19 10:07:26 2016 From: report at bugs.python.org (=?utf-8?q?Anders_Hovm=C3=B6ller?=) Date: Tue, 19 Jul 2016 14:07:26 +0000 Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times In-Reply-To: <1468633293.37.0.278743850594.issue15873@psf.upfronthosting.co.za> Message-ID: Anders Hovm?ller added the comment: The tests attached to this ticket seem pretty bare. Issues that I can spot directly: - only tests for datetimes, not times or dates - only tests for zulu and "-8:00? timezones - no tests for invalid input (parsing a valid date as a datetime for example) - only tests for YYYY-MM-DDTHH:MM:SSZ, but ISO8601 supports: - Naive times - Timezone information (specified as offsets or as Z for 0 offset) - Year - Year-month - Year-month-date - Year-week - Year-week-weekday - Year-ordinal day - Hour - Hour-minute - Hour-minute - Hour-minute-second - Hour-minute-second-microsecond - All combinations of the three "families" above! (the above list is a copy paste from my project that implements all ISO8601 that fits into native python: https://github.com/boxed/iso8601 ) This is a more reasonable test suite: https://github.com/boxed/iso8601/blob/master/iso8601.py#L166 although it lacks the tests for bogus inputs. > On 2016-07-16, at 03:41, Alexander Belopolsky wrote: > > > Alexander Belopolsky added the comment: > > I would very much like to see this ready before the feature cut-off for Python 3.6. Could someone post a summary on python-ideas to get a show of hands on some of the remaining wrinkles? > > I would not worry about a C implementation at this point. We can put python implementation in _strptime.py and call it from C as we do for the strptime method. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 10:20:33 2016 From: report at bugs.python.org (Mathieu Dupuy) Date: Tue, 19 Jul 2016 14:20:33 +0000 Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times In-Reply-To: Message-ID: Mathieu Dupuy added the comment: because it limits itself to only support the RFC 3339 subset, as explained in the begining of the discussion. 2016-07-19 16:07 GMT+02:00 Anders Hovm?ller : > > Anders Hovm?ller added the comment: > > The tests attached to this ticket seem pretty bare. Issues that I can spot directly: > > - only tests for datetimes, not times or dates > - only tests for zulu and "-8:00? timezones > - no tests for invalid input (parsing a valid date as a datetime for example) > - only tests for YYYY-MM-DDTHH:MM:SSZ, but ISO8601 supports: > - Naive times > - Timezone information (specified as offsets or as Z for 0 offset) > - Year > - Year-month > - Year-month-date > - Year-week > - Year-week-weekday > - Year-ordinal day > - Hour > - Hour-minute > - Hour-minute > - Hour-minute-second > - Hour-minute-second-microsecond > - All combinations of the three "families" above! > (the above list is a copy paste from my project that implements all ISO8601 that fits into native python: https://github.com/boxed/iso8601 ) > > This is a more reasonable test suite: https://github.com/boxed/iso8601/blob/master/iso8601.py#L166 although it lacks the tests for bogus inputs. > >> On 2016-07-16, at 03:41, Alexander Belopolsky wrote: >> >> >> Alexander Belopolsky added the comment: >> >> I would very much like to see this ready before the feature cut-off for Python 3.6. Could someone post a summary on python-ideas to get a show of hands on some of the remaining wrinkles? >> >> I would not worry about a C implementation at this point. We can put python implementation in _strptime.py and call it from C as we do for the strptime method. >> >> ---------- >> >> _______________________________________ >> Python tracker >> >> _______________________________________ > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 10:47:34 2016 From: report at bugs.python.org (Kirk Hansen) Date: Tue, 19 Jul 2016 14:47:34 +0000 Subject: [issue27561] Warn against subclassing builtins, and overriding their methods In-Reply-To: <1468848651.49.0.804648096873.issue27561@psf.upfronthosting.co.za> Message-ID: <1468939654.19.0.134100734936.issue27561@psf.upfronthosting.co.za> Kirk Hansen added the comment: Raymond: Thanks for essentially answering my stackoverflow question (if you are a member, and add most of your response, I'll accept it). I agree enough with your documentation statement. An entry in an FAQ would have been just as helpful to me as a note in the documentation, and the FAQ is probably more accessible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 11:05:37 2016 From: report at bugs.python.org (=?utf-8?q?Anders_Hovm=C3=B6ller?=) Date: Tue, 19 Jul 2016 15:05:37 +0000 Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times In-Reply-To: Message-ID: <334BC07F-3321-4678-8EA9-96CF53E6D85C@killingar.net> Anders Hovm?ller added the comment: Hmm, ok. I guess I was confused by "dates and times" part of the subject. Ok, so only datetimes. My other comments still apply though. > On 19 Jul 2016, at 16:20, Mathieu Dupuy wrote: > > > Mathieu Dupuy added the comment: > > because it limits itself to only support the RFC 3339 subset, as > explained in the begining of the discussion. > > 2016-07-19 16:07 GMT+02:00 Anders Hovm?ller : >> >> Anders Hovm?ller added the comment: >> >> The tests attached to this ticket seem pretty bare. Issues that I can spot directly: >> >> - only tests for datetimes, not times or dates >> - only tests for zulu and "-8:00? timezones >> - no tests for invalid input (parsing a valid date as a datetime for example) >> - only tests for YYYY-MM-DDTHH:MM:SSZ, but ISO8601 supports: >> - Naive times >> - Timezone information (specified as offsets or as Z for 0 offset) >> - Year >> - Year-month >> - Year-month-date >> - Year-week >> - Year-week-weekday >> - Year-ordinal day >> - Hour >> - Hour-minute >> - Hour-minute >> - Hour-minute-second >> - Hour-minute-second-microsecond >> - All combinations of the three "families" above! >> (the above list is a copy paste from my project that implements all ISO8601 that fits into native python: https://github.com/boxed/iso8601 ) >> >> This is a more reasonable test suite: https://github.com/boxed/iso8601/blob/master/iso8601.py#L166 although it lacks the tests for bogus inputs. >> >>> On 2016-07-16, at 03:41, Alexander Belopolsky wrote: >>> >>> >>> Alexander Belopolsky added the comment: >>> >>> I would very much like to see this ready before the feature cut-off for Python 3.6. Could someone post a summary on python-ideas to get a show of hands on some of the remaining wrinkles? >>> >>> I would not worry about a C implementation at this point. We can put python implementation in _strptime.py and call it from C as we do for the strptime method. >>> >>> ---------- >>> >>> _______________________________________ >>> Python tracker >>> >>> _______________________________________ >> >> ---------- >> >> _______________________________________ >> Python tracker >> >> _______________________________________ > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 11:20:05 2016 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 19 Jul 2016 15:20:05 +0000 Subject: [issue25571] Improve the lltrace feature with the Py_Debug mode In-Reply-To: <1446844426.01.0.118649403374.issue25571@psf.upfronthosting.co.za> Message-ID: <1468941605.29.0.117580220314.issue25571@psf.upfronthosting.co.za> Changes by St?phane Wirtel : ---------- components: +Interpreter Core versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 11:49:15 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 19 Jul 2016 15:49:15 +0000 Subject: [issue27472] add the 'unix_shell' attribute to test.support In-Reply-To: <1468077155.86.0.151085889776.issue27472@psf.upfronthosting.co.za> Message-ID: <1468943355.84.0.240243829946.issue27472@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- nosy: +haypo stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 12:03:58 2016 From: report at bugs.python.org (Brett Cannon) Date: Tue, 19 Jul 2016 16:03:58 +0000 Subject: [issue27571] 3.6 Seems to be ignoring the _sodium pyd file made with pip. In-Reply-To: <1468911783.53.0.349371581627.issue27571@psf.upfronthosting.co.za> Message-ID: <1468944238.13.0.0231072195558.issue27571@psf.upfronthosting.co.za> Brett Cannon added the comment: If it's only affecting a single library then chances are it's not Python's fault. ---------- components: +Windows nosy: +brett.cannon, paul.moore, steve.dower, tim.golden, zach.ware resolution: -> third party status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 12:03:57 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 Jul 2016 16:03:57 +0000 Subject: [issue27574] Faster parsing keyword arguments Message-ID: <1468944235.85.0.107735525995.issue27574@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Parsing keyword arguments is much more slow than parsing positional arguments. Parsing time can be larger that useful execution time. $ ./python -m timeit "b'a:b:c'.split(b':', 1)" 1000000 loops, best of 3: 0.638 usec per loop $ ./python -m timeit "b'a:b:c'.split(b':', maxsplit=1)" 1000000 loops, best of 3: 1.64 usec per loop The main culprit is that Python strings are created for every keyword name on every call. Proposed patch adds alternative API that caches keyword names as Python strings in special object. Argument Clinic is changed to use this API in generated file. An effect of the optimization: $ ./python -m timeit "b'a:b:c'.split(b':', maxsplit=1)" 1000000 loops, best of 3: 0.826 usec per loop Invocations of PyArg_ParseTupleAndKeywords() in non-generated code are kept, since API is not stable yet. Later I'm going to cache parsed format strings and speed up parsing positional arguments too. ---------- components: Interpreter Core files: faster_keyword_args_parse.patch keywords: patch messages: 270832 nosy: serhiy.storchaka priority: normal severity: normal status: open title: Faster parsing keyword arguments type: performance versions: Python 3.6 Added file: http://bugs.python.org/file43794/faster_keyword_args_parse.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 12:41:20 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 19 Jul 2016 16:41:20 +0000 Subject: [issue16255] subrocess.Popen needs /bin/sh but Android only has /system/bin/sh In-Reply-To: <1350421202.49.0.905467284446.issue16255@psf.upfronthosting.co.za> Message-ID: <1468946480.2.0.0690705895202.issue16255@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The attached patch fixes the issue. There is at least already an existing test case: test_subprocess.MiscTests.test_getoutput calls subprocess.getstatusoutput() that runs a Popen instance with shell=True. ---------- stage: -> patch review Added file: http://bugs.python.org/file43795/unix_shell_16255.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 12:45:20 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 19 Jul 2016 16:45:20 +0000 Subject: [issue27571] 3.6 Seems to be ignoring the _sodium pyd file made with pip. In-Reply-To: <1468911783.53.0.349371581627.issue27571@psf.upfronthosting.co.za> Message-ID: <1468946720.64.0.743073990497.issue27571@psf.upfronthosting.co.za> Steve Dower added the comment: Any chance this is a regression in the "extension module within a package" issue we saw during 3.5? There's a pretty relevant difference between: >>> import nacl._sodium >>> import _cffi_backend ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 12:49:14 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 19 Jul 2016 16:49:14 +0000 Subject: [issue16255] subrocess.Popen needs /bin/sh but Android only has /system/bin/sh In-Reply-To: <1350421202.49.0.905467284446.issue16255@psf.upfronthosting.co.za> Message-ID: <1468946954.78.0.463687245448.issue16255@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 13:51:47 2016 From: report at bugs.python.org (David Su) Date: Tue, 19 Jul 2016 17:51:47 +0000 Subject: [issue27575] dict viewkeys intersection slow for large dicts Message-ID: <1468950707.74.0.640405379684.issue27575@psf.upfronthosting.co.za> New submission from David Su: In dictobject.c, the function dictviews_and performs a very expensive set creation operation on the keys of the self dict object: >From Python 2.7: ... static PyObject* dictviews_and(PyObject* self, PyObject *other) { PyObject *result = PySet_New(self); ... tmp = PyObject_CallMethod(result, "intersection_update", "(O)", other); ... Similar logic can be found in the Python 3 code as well. For large dicts (~10 000 000 keys), it takes a significant amount of time to copy the keys into a new set, and also wastes a lot of memory. This issue is amplified when the intersection operation is performed many times. This implementation uses O(len(self)) time and space, while it is expected to use O(min(len(self), len(other)) time and space. Solution 1: Manually copy the keys of the dict into a set, and perform all intersection operations on that set. However, still wastes lots of memory. Solution 2 (Recommended): Port the intersection logic from the set class to the dict view class. ---------- components: Library (Lib) messages: 270836 nosy: David Su2 priority: normal severity: normal status: open title: dict viewkeys intersection slow for large dicts type: performance versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 14:08:42 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 19 Jul 2016 18:08:42 +0000 Subject: [issue27567] Add constants EPOLLRDHUP and POLLRDHUP to module select. In-Reply-To: <1468872036.69.0.576706331519.issue27567@psf.upfronthosting.co.za> Message-ID: <20160719180836.16051.67265.8A5DA78F@psf.io> Roundup Robot added the comment: New changeset d87f30c29ad4 by Berker Peksag in branch 'default': Issue #27567: Expose the POLLRDHUP constant in the select module https://hg.python.org/cpython/rev/d87f30c29ad4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 14:09:36 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 19 Jul 2016 18:09:36 +0000 Subject: [issue27567] Add constants EPOLLRDHUP and POLLRDHUP to module select. In-Reply-To: <1468872036.69.0.576706331519.issue27567@psf.upfronthosting.co.za> Message-ID: <1468951776.74.0.777520600231.issue27567@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks! ---------- nosy: +berker.peksag status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 14:24:46 2016 From: report at bugs.python.org (Brett Cannon) Date: Tue, 19 Jul 2016 18:24:46 +0000 Subject: [issue27571] 3.6 Seems to be ignoring the _sodium pyd file made with pip. In-Reply-To: <1468911783.53.0.349371581627.issue27571@psf.upfronthosting.co.za> Message-ID: <1468952686.29.0.70693496732.issue27571@psf.upfronthosting.co.za> Brett Cannon added the comment: Anything is possible, but I'm not aware of any big changes in extension loading in 3.6. Would need a test case to verify. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 14:41:39 2016 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Rampin?=) Date: Tue, 19 Jul 2016 18:41:39 +0000 Subject: [issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts In-Reply-To: <1468881013.81.0.152859673137.issue27568@psf.upfronthosting.co.za> Message-ID: <1468953699.18.0.636107934256.issue27568@psf.upfronthosting.co.za> Changes by R?mi Rampin : Removed file: http://bugs.python.org/file43779/python-2.7-httpoxy-mitigation.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 14:41:46 2016 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Rampin?=) Date: Tue, 19 Jul 2016 18:41:46 +0000 Subject: [issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts In-Reply-To: <1468881013.81.0.152859673137.issue27568@psf.upfronthosting.co.za> Message-ID: <1468953706.87.0.598393757318.issue27568@psf.upfronthosting.co.za> Changes by R?mi Rampin : Removed file: http://bugs.python.org/file43780/python-3.5-httpoxy-mitigation.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 14:43:55 2016 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Rampin?=) Date: Tue, 19 Jul 2016 18:43:55 +0000 Subject: [issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts In-Reply-To: <1468881013.81.0.152859673137.issue27568@psf.upfronthosting.co.za> Message-ID: <1468953835.38.0.34042844778.issue27568@psf.upfronthosting.co.za> Changes by R?mi Rampin : Added file: http://bugs.python.org/file43796/python-2.7-httpoxy.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 14:44:08 2016 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Rampin?=) Date: Tue, 19 Jul 2016 18:44:08 +0000 Subject: [issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts In-Reply-To: <1468881013.81.0.152859673137.issue27568@psf.upfronthosting.co.za> Message-ID: <1468953848.83.0.659963280582.issue27568@psf.upfronthosting.co.za> Changes by R?mi Rampin : Added file: http://bugs.python.org/file43797/python-3.5-httpoxy.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 15:18:44 2016 From: report at bugs.python.org (Cory Benfield) Date: Tue, 19 Jul 2016 19:18:44 +0000 Subject: [issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts In-Reply-To: <1468881013.81.0.152859673137.issue27568@psf.upfronthosting.co.za> Message-ID: <1468955924.75.0.368303009149.issue27568@psf.upfronthosting.co.za> Cory Benfield added the comment: Ok, so I've taken a preliminary look at this patch. It looks good to me! I have one question: right now the patch as written will blow away not just HTTP_PROXY, but also any other mixed-case spelling of that name (e.g. HtTp_PrOxY) in a CGI environment. That's *probably* not a concern: I think in practice such a spelling is almost never used. However, I wanted to draw it out explicitly: we should probably include a code comment that indicates that we know that it's a side effect of the code, and that we don't care. For what it's worth, we should also consider commenting with a note regarding the CVE number assigned to Python. We may want to consider getting a CVE number for this specific fix as well, though I'd need to chat to someone in the PSRT at this point to get an idea of what they think. Good work! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 17:01:28 2016 From: report at bugs.python.org (Evelyn Mitchell) Date: Tue, 19 Jul 2016 21:01:28 +0000 Subject: [issue25393] 'resource' module documentation error In-Reply-To: <1444746542.39.0.814536865396.issue25393@psf.upfronthosting.co.za> Message-ID: <1468962088.06.0.876828450679.issue25393@psf.upfronthosting.co.za> Evelyn Mitchell added the comment: I've looked at the patch, and the fix looks correct to me. Thanks Alakshendra! I'll verify it builds correctly. ---------- nosy: +Evelyn Mitchell _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 17:01:30 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 19 Jul 2016 21:01:30 +0000 Subject: [issue27576] An unexpected difference between dict and OrderedDict Message-ID: <1468962090.7.0.636707577928.issue27576@psf.upfronthosting.co.za> New submission from Alexander Belopolsky: Consider the following code: $ cat x.py from collections import OrderedDict class X: def items(self): print('items') return [] def keys(self): print('keys') return [] print(dict(X())) print(OrderedDict(X())) When I run it under python 3.4, I get $ python3.4 x.py keys {} keys OrderedDict() but under python 3.5, I get $ python3.5 x.py keys {} items OrderedDict() Under 3.4 both dict and OrderedDict constructors call the keys() method of the underlying object (and then call __getitem__ repeatedly if keys() returns a non-empty list), but in 3.5 OrderedDict behavior changed and it calls the values() method instead. ---------- keywords: 3.4regression messages: 270842 nosy: belopolsky priority: normal severity: normal status: open title: An unexpected difference between dict and OrderedDict type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 17:12:16 2016 From: report at bugs.python.org (Ammar Askar) Date: Tue, 19 Jul 2016 21:12:16 +0000 Subject: [issue19489] move quick search box above TOC In-Reply-To: <1383546510.68.0.587653327623.issue19489@psf.upfronthosting.co.za> Message-ID: <1468962736.03.0.70127305333.issue19489@psf.upfronthosting.co.za> Ammar Askar added the comment: bump, added the documentation experts list, not sure if the core dev who made this issue is still active. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 17:17:15 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 19 Jul 2016 21:17:15 +0000 Subject: [issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts In-Reply-To: <1468881013.81.0.152859673137.issue27568@psf.upfronthosting.co.za> Message-ID: <1468963035.1.0.0812839407282.issue27568@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Thanks for this patch. The CVE number assigned to python - CVE-2016-1000110. There is redundancy in /Doc/library/urllib.request.rst change where the same paragraph is repeated twice. See if you can have it at a single location as a `Note` and reference it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 17:34:57 2016 From: report at bugs.python.org (Decorater) Date: Tue, 19 Jul 2016 21:34:57 +0000 Subject: [issue27571] 3.6 Seems to be ignoring the _sodium pyd file made with pip. In-Reply-To: <1468911783.53.0.349371581627.issue27571@psf.upfronthosting.co.za> Message-ID: <1468964097.91.0.164933744423.issue27571@psf.upfronthosting.co.za> Decorater added the comment: hmm unless it has something to do with only my bot's debug command doing the following as it seems it could possible be only my bot's debug command however commenting out 1 thing in Discord.py also generates this Issue. Debug Command Code: https://bpaste.net/show/904eccf5bdc0 (what I was using when I found this issue) Result of Uncommenting Import Error Catch in Discord.py: Traceback (most recent call last): File "E:\Users\Elsword\Desktop\DecoraterBot\Async\DecoraterBot.py", line 10, i n import discord File "E:\Users\Elsword\Desktop\DecoraterBot\Async\resources\Dependencies\disco rd\__init__.py", line 20, in from .client import Client, AppInfo File "E:\Users\Elsword\Desktop\DecoraterBot\Async\resources\Dependencies\disco rd\client.py", line 42, in from .voice_client import VoiceClient File "E:\Users\Elsword\Desktop\DecoraterBot\Async\resources\Dependencies\disco rd\voice_client.py", line 58, in import nacl.secret File "nacl\secret.py", line 18, in File "nacl\bindings\__init__.py", line 17, in File "nacl\bindings\crypto_box.py", line 17, in ImportError: No module named 'nacl._sodium' Yep this must be some Regression in 3.6 or something uncaught it does however work in 3.5.2 as expected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 17:42:28 2016 From: report at bugs.python.org (Decorater) Date: Tue, 19 Jul 2016 21:42:28 +0000 Subject: [issue27571] 3.6 Seems to be ignoring the _sodium pyd file made with pip. In-Reply-To: <1468911783.53.0.349371581627.issue27571@psf.upfronthosting.co.za> Message-ID: <1468964548.59.0.466026724384.issue27571@psf.upfronthosting.co.za> Decorater added the comment: Commenting* ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 17:48:47 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 19 Jul 2016 21:48:47 +0000 Subject: [issue25393] 'resource' module documentation error In-Reply-To: <1444746542.39.0.814536865396.issue25393@psf.upfronthosting.co.za> Message-ID: <20160719214839.16868.34494.0AF32AE2@psf.io> Roundup Robot added the comment: New changeset 434fc614c506 by Zachary Ware in branch '2.7': Issue #25393: Fix probable copy/paste error in resource docs https://hg.python.org/cpython/rev/434fc614c506 New changeset 0fe2b7509707 by Zachary Ware in branch '3.5': Issue #25393: Fix probable copy/paste error in resource docs https://hg.python.org/cpython/rev/0fe2b7509707 New changeset 829117ae2e55 by Zachary Ware in branch 'default': Closes #25393: Merge with 3.5 https://hg.python.org/cpython/rev/829117ae2e55 ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 17:49:27 2016 From: report at bugs.python.org (Zachary Ware) Date: Tue, 19 Jul 2016 21:49:27 +0000 Subject: [issue25393] 'resource' module documentation error In-Reply-To: <1444746542.39.0.814536865396.issue25393@psf.upfronthosting.co.za> Message-ID: <1468964967.02.0.274048553755.issue25393@psf.upfronthosting.co.za> Zachary Ware added the comment: Thanks to Christos for the report and Alakshendra for the patch! ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 18:26:27 2016 From: report at bugs.python.org (Eric Snow) Date: Tue, 19 Jul 2016 22:26:27 +0000 Subject: [issue24254] Make class definition namespace ordered by default In-Reply-To: <1432186488.39.0.20621749373.issue24254@psf.upfronthosting.co.za> Message-ID: <1468967187.77.0.133509219479.issue24254@psf.upfronthosting.co.za> Changes by Eric Snow : Removed file: http://bugs.python.org/file43629/deforder-with-tp-slot.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 18:26:35 2016 From: report at bugs.python.org (Eric Snow) Date: Tue, 19 Jul 2016 22:26:35 +0000 Subject: [issue24254] Make class definition namespace ordered by default In-Reply-To: <1432186488.39.0.20621749373.issue24254@psf.upfronthosting.co.za> Message-ID: <1468967195.4.0.551982730475.issue24254@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- hgrepos: -310 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 18:38:00 2016 From: report at bugs.python.org (Zachary Ware) Date: Tue, 19 Jul 2016 22:38:00 +0000 Subject: [issue27571] 3.6 Seems to be ignoring the _sodium pyd file made with pip. In-Reply-To: <1468911783.53.0.349371581627.issue27571@psf.upfronthosting.co.za> Message-ID: <1468967880.95.0.02246589987.issue27571@psf.upfronthosting.co.za> Zachary Ware added the comment: I have confirmed that this is not a Python issue. PyNaCl takes some special coercion and a third-party library to build (see https://github.com/pyca/pynacl/issues/165), but I managed to get it to build with 3.5.1 and 3.6 and imported nacl._sodium in both with no problem. ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 19:00:05 2016 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 Jul 2016 23:00:05 +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: <1468969205.58.0.97068025346.issue27392@psf.upfronthosting.co.za> Yury Selivanov added the comment: Jim, the patch lgtm. Will merge it soon. ---------- assignee: -> yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 19:13:18 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 19 Jul 2016 23:13:18 +0000 Subject: [issue27576] An unexpected difference between dict and OrderedDict In-Reply-To: <1468962090.7.0.636707577928.issue27576@psf.upfronthosting.co.za> Message-ID: <1468969998.85.0.300298710614.issue27576@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This does need to be fixed. FWIW, here is the relevant docstring from MutableMapping: ''' D.update([E, ]**F) -> None. Update D from mapping/iterable E and F. If E present and has a .keys() method, does: for k in E: D[k] = E[k] If E present and lacks .keys() method, does: for (k, v) in E: D[k] = v In either case, this is followed by: for k, v in F.items(): D[k] = v ''' ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 19:15:19 2016 From: report at bugs.python.org (Emanuel Barry) Date: Tue, 19 Jul 2016 23:15:19 +0000 Subject: [issue27576] An unexpected difference between dict and OrderedDict In-Reply-To: <1468962090.7.0.636707577928.issue27576@psf.upfronthosting.co.za> Message-ID: <1468970119.0.0.115966181296.issue27576@psf.upfronthosting.co.za> Changes by Emanuel Barry : ---------- assignee: -> eric.snow components: +Library (Lib) keywords: +3.5regression -3.4regression nosy: +ebarry, eric.snow stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 20:01:03 2016 From: report at bugs.python.org (Ricardo Esperanza) Date: Wed, 20 Jul 2016 00:01:03 +0000 Subject: [issue27569] Windows install problems In-Reply-To: <1468892841.27.0.521360350751.issue27569@psf.upfronthosting.co.za> Message-ID: <1468972863.69.0.960128608518.issue27569@psf.upfronthosting.co.za> Ricardo Esperanza added the comment: Steve CCleanr my registry, then restarted and execute instal again It worked for a longer period and ended with different error attached log. logs attached ---------- Added file: http://bugs.python.org/file43798/Python 3.5.2 (32-bit)_20160719204204_000_core_JustForMe_rollback.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 20:01:44 2016 From: report at bugs.python.org (Ricardo Esperanza) Date: Wed, 20 Jul 2016 00:01:44 +0000 Subject: [issue27569] Windows install problems In-Reply-To: <1468892841.27.0.521360350751.issue27569@psf.upfronthosting.co.za> Message-ID: <1468972904.53.0.814061761172.issue27569@psf.upfronthosting.co.za> Ricardo Esperanza added the comment: Steve another log file ---------- Added file: http://bugs.python.org/file43799/Python 3.5.2 (32-bit)_20160719204204.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 00:07:46 2016 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Rampin?=) Date: Wed, 20 Jul 2016 04:07:46 +0000 Subject: [issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts In-Reply-To: <1468881013.81.0.152859673137.issue27568@psf.upfronthosting.co.za> Message-ID: <1468987666.47.0.0947003898948.issue27568@psf.upfronthosting.co.za> R?mi Rampin added the comment: - Added CVE number - Link to full note on getproxies() doc - Improved comment on uppercase (lowercase will be preferred to mIxED_case too) ---------- Added file: http://bugs.python.org/file43800/python-2.7-httpoxy.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 00:07:56 2016 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Rampin?=) Date: Wed, 20 Jul 2016 04:07:56 +0000 Subject: [issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts In-Reply-To: <1468881013.81.0.152859673137.issue27568@psf.upfronthosting.co.za> Message-ID: <1468987676.56.0.336350501604.issue27568@psf.upfronthosting.co.za> Changes by R?mi Rampin : Added file: http://bugs.python.org/file43801/python-3.5-httpoxy.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 00:08:13 2016 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Rampin?=) Date: Wed, 20 Jul 2016 04:08:13 +0000 Subject: [issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts In-Reply-To: <1468881013.81.0.152859673137.issue27568@psf.upfronthosting.co.za> Message-ID: <1468987693.7.0.703460022303.issue27568@psf.upfronthosting.co.za> Changes by R?mi Rampin : Removed file: http://bugs.python.org/file43796/python-2.7-httpoxy.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 00:08:14 2016 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Rampin?=) Date: Wed, 20 Jul 2016 04:08:14 +0000 Subject: [issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts In-Reply-To: <1468881013.81.0.152859673137.issue27568@psf.upfronthosting.co.za> Message-ID: <1468987694.58.0.566186961498.issue27568@psf.upfronthosting.co.za> Changes by R?mi Rampin : Removed file: http://bugs.python.org/file43797/python-3.5-httpoxy.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 00:38:41 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 20 Jul 2016 04:38:41 +0000 Subject: [issue27546] Integrate tkinter and asyncio (and async) In-Reply-To: <1468815010.57.0.709565417017.issue27546@psf.upfronthosting.co.za> Message-ID: <1468989521.03.0.854074314481.issue27546@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Guido, that seems like a reasonable roadmap. The examples directory is not in the CPython repo, but I found it here. https://github.com/python/asyncio/tree/master/examples For a demo based on crawl.py, the goal would be a live status report. Perhaps as files are fetched, they could be entered into a Treeview-based url tree, with columns for the statistics. (I still have to learn to practical use of Treeview.) This would require adding widget data insertion commands within the crawl code. Who actually wrote it, that would understand it? Responsiveness should be a matter of prioritizing events. Using the asyncio loop as a base, I did the minimum needed for the first demo and for the initial part of the follow-up below. For general use, _run_once should be modified to always let gui events be handled 'soon' by either not blocking or having a short timeout. The root.update call could be moved from run_forever to multiple places within _run_once. At an extreme, the _process_events implementations could be modified to call root.update() after processing each io event. According to timeit.timeit(root.update), a do-nothing call takes less than 4 microseconds on my machine. --- I implemented my idea of updating a tk widget in an async for loop. The attached tkaloop does so, with the syntax I proposed previously. There is only a change to the timer api. With respect to the datetime clock, the behavior is essentially the same as with the first code. Given that one can do the same thing with a normal for loop and explicit update (as some beginners try to do), is this useful? 1. Responsiveness: A normal for-loop blocks, freezing the gui. To test that this is not so here, I added a button to do something visible - change a background color. While the clock is running, it only sort-of works, because clicks are only processed after each 1 second tick. The reason is that the select call in _run_once gets a timeout that is the minimum time to a scheduled event. (The same should be true in tkloop.py if similarly modified.) The next step is to modify _run_once as discussed above. Tk allows one to specify delays to the nearest millisecond and on my machine, that precision is real. from tkinter import * import time root = Tk() root.withdraw() timer = time.perf_counter ##n = 999 ##delay = 1 n=1 delay=337 def tick(): global n if n: n -= 1 root.after(delay, tick) else: print(timer() - start) tick() start = timer() root.mainloop() prints .3370... in multiple runs. 1000 loops with a delay of 1 ms takes 1.05... seconds. Similar performance would be a target for run_forever. 2. Parallel looping. Supposed we wanted to automate the background color changes, with an interval of, say x seconds. If x is, say, .3, then one could use .1 second ticks and an update block that flips the background every 3 ticks and the clock every 10. But what if the intervals are not so conveniently commensurable or the separate updates not so easily mashed together into one loop block? Parallel looping with chained callbacks, whether with tk or asyncio is fairly easy. I presume it could be done with asyncio coroutines (but have no experience). What I would like, but cannot see, is a way to do so with async for. Within a function, async for blocks execution of remaining code after the for statement the same as normal for statement. My conclusion thus far: with the response issue solved, a single async for loop could work for some time-driven applications, including some that beginners write, but not all. An alternative for reducing the callback boilerplate is an animate function. I have thought of writing one for tkinter, but have not yet because I have not yet needed one for IDLE. ---------- Added file: http://bugs.python.org/file43802/tkaloop.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 01:00:18 2016 From: report at bugs.python.org (Lisa Roach) Date: Wed, 20 Jul 2016 05:00: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: <1468990818.95.0.644442597832.issue23951@psf.upfronthosting.co.za> Lisa Roach added the comment: Thanks for the feedback! I've cleaned up the patch, hopefully I've been able to catch all the little things that needed to be removed. I was able to wire in rstlint to the make.bat and makefile, so 'make check' should now work. I believe tools/static/py.png is included in the patch, if you are still not seeing it let me know. One thing I haven't been able to figure out: both the devguide and python 3 documentation have below the search bar this sentence: "Enter search terms or a module, class or function name. " This sentence is not appearing below my patch's search bar, I am not sure why. Additionally, the "go" button is being generated slightly differently (in a div), causing it to appear below the search bar instead of beside it. Any ideas on how to fix this? ---------- Added file: http://bugs.python.org/file43803/devguide_theme_revised.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 01:06:54 2016 From: report at bugs.python.org (Lisa Roach) Date: Wed, 20 Jul 2016 05:06:54 +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: <1468991214.33.0.120561785283.issue23951@psf.upfronthosting.co.za> Lisa Roach added the comment: Whoops, forgot to remove some errant code. ---------- Added file: http://bugs.python.org/file43804/devguide_theme_revised.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 04:17:22 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 20 Jul 2016 08:17:22 +0000 Subject: [issue27577] tuple and list parameter name conflicts between doc and implementation Message-ID: <1469002642.37.0.996165914529.issue27577@psf.upfronthosting.co.za> New submission from Xiang Zhang: For tuple and list, their signatures are tuple([iterable]) and list([iterable]). But actually they support keyword argument *sequence*. The parameter names in doc are sometimes just placeholders but sometimes are real parameter names. So I suggest make the implementation and doc more compliant. One method is make the parameter name in implementation *iterable*. The other is totally suppress keyword argument since it is never documented. This is not a necessary change but I think the compliment is not a bad idea. ---------- components: Interpreter Core messages: 270858 nosy: serhiy.storchaka, xiang.zhang priority: normal severity: normal status: open title: tuple and list parameter name conflicts between doc and implementation type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 04:18:51 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 20 Jul 2016 08:18:51 +0000 Subject: [issue27577] Make implementation and doc of tuple and list more compliant In-Reply-To: <1469002642.37.0.996165914529.issue27577@psf.upfronthosting.co.za> Message-ID: <1469002731.4.0.716869048274.issue27577@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- title: tuple and list parameter name conflicts between doc and implementation -> Make implementation and doc of tuple and list more compliant _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 04:35:50 2016 From: report at bugs.python.org (Xavier Combelle) Date: Wed, 20 Jul 2016 08:35:50 +0000 Subject: [issue25571] Improve the lltrace feature with the Py_Debug mode In-Reply-To: <1446844426.01.0.118649403374.issue25571@psf.upfronthosting.co.za> Message-ID: <1469003750.81.0.845604723174.issue25571@psf.upfronthosting.co.za> Xavier Combelle added the comment: I made some comment on code in review. A thing that worry me that there is zero automated test. In my opinion the minimal should be to test the expected output. A nice to have would be a test for the write_contents function of makeopcodetranslations.py ---------- nosy: +xcombelle _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 04:51:11 2016 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Jul 2016 08:51:11 +0000 Subject: [issue25571] Improve the lltrace feature with the Py_Debug mode In-Reply-To: <1469003750.81.0.845604723174.issue25571@psf.upfronthosting.co.za> Message-ID: <20160720085108.77lgleyqiwy6dy3i@sg1> St?phane Wirtel added the comment: Totally agree with you, I am going to check that, because currently, there is no test with this "hidden" feature in Python. I am going to discuss with Victor about this point. Thanks, Stephane On 07/20, Xavier Combelle wrote: > >Xavier Combelle added the comment: > >I made some comment on code in review. > >A thing that worry me that there is zero automated test. > >In my opinion the minimal should be to test the expected output. > >A nice to have would be a test for the write_contents function of makeopcodetranslations.py > >---------- >nosy: +xcombelle > >_______________________________________ >Python tracker > >_______________________________________ >_______________________________________________ >Python-bugs-list mailing list >Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/stephane%40wirtel.be > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 05:49:14 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 20 Jul 2016 09:49:14 +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: <20160720094910.79690.70939.9CD1CEFD@psf.io> Roundup Robot added the comment: New changeset 9e7b1bc15ba7 by Victor Stinner in branch 'default': Use the same style than Python ref doc https://hg.python.org/devguide/rev/9e7b1bc15ba7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 05:50:03 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Jul 2016 09:50:03 +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: <1469008203.27.0.239578721497.issue23951@psf.upfronthosting.co.za> STINNER Victor added the comment: I pushed your new style, thanks. I didn't see any malware in the new Javascript nor new HTML :-) I keep the issue open until the online doc is updated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 07:05:56 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Jul 2016 11:05:56 +0000 Subject: [issue25571] Improve the lltrace feature with the Py_Debug mode In-Reply-To: <1446844426.01.0.118649403374.issue25571@psf.upfronthosting.co.za> Message-ID: <1469012756.18.0.404952773823.issue25571@psf.upfronthosting.co.za> STINNER Victor added the comment: It would be nice to have unit tests and docs :-) For unit test, you can use a script like: --- def func(): return 1 __ltrace__ = True func() --- Run the script with test.support.assert_python_ok(), and check stdout. To skip the test if Python is compiled in released mode, you can use: --- # Were we compiled --with-pydebug or with #define Py_DEBUG? Py_DEBUG = hasattr(sys, 'gettotalrefcount') ... @unittest.skipUnless(Py_DEBUG, 'need Py_DEBUG') --- ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 07:10:04 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Jul 2016 11:10:04 +0000 Subject: [issue25571] Improve the lltrace feature with the Py_Debug mode In-Reply-To: <1446844426.01.0.118649403374.issue25571@psf.upfronthosting.co.za> Message-ID: <1469013004.28.0.0490044523883.issue25571@psf.upfronthosting.co.za> STINNER Victor added the comment: Sorry, I don't know what is the best place to add new unit tests. I don't know neither what is the best place to document the __ltrace__ feature. Maybe somewhere near: * https://docs.python.org/dev/library/debug.html Or maybe: * https://docs.python.org/dev/library/trace.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 07:37:24 2016 From: report at bugs.python.org (Stefan Krah) Date: Wed, 20 Jul 2016 11:37:24 +0000 Subject: [issue16255] subrocess.Popen needs /bin/sh but Android only has /system/bin/sh In-Reply-To: <1350421202.49.0.905467284446.issue16255@psf.upfronthosting.co.za> Message-ID: <1469014644.72.0.289449365112.issue16255@psf.upfronthosting.co.za> Stefan Krah added the comment: Apparently sysconfig.get_config_var() is already called in site.py anyway, so in principle I'm fine with using it here. In the stdlib it seems to be the first use outside site.py though, and site.py can be disabled by using "python -S", so perhaps we should be extra careful, set UNIX_SHELL unconditionally to "/bin/sh" and move the Android conditional inside a try/except. But perhaps I'm being irrational here. Victor, what do you think? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 07:49:38 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 20 Jul 2016 11:49: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: <1469015378.07.0.764788943746.issue27130@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a possible patch for 2.7. To fix everything on 2.7 I changed the module to accept input buffers over 2 GiB by enabling PY_SSIZE_T_CLEAN. As a consequence, the patch also includes ports of Nadeem Vawda?s adler32(), crc32() changes from Issue 10276, and my tests from Issue 25626. I have only tested this on computers with less than 4 GiB of memory. I can test compression and checksums with more input by using a sparse memory map, but not decompression. fm = open("5GiB.sparse", "w+b") fm.truncate(5 * 2**30) m = mmap(fm.fileno(), 0) z = compress(m) ---------- type: -> crash Added file: http://bugs.python.org/file43805/64bit_support_for_zlib_v10-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 08:05:58 2016 From: report at bugs.python.org (Alexander Todorov) Date: Wed, 20 Jul 2016 12:05:58 +0000 Subject: [issue27578] inspect.findsource raises exception with empty __init__.py Message-ID: <1469016358.37.0.125453636257.issue27578@psf.upfronthosting.co.za> New submission from Alexander Todorov: $ python2 Python 2.7.5 (default, Oct 11 2015, 17:47:16) [GCC 4.8.3 20140911 (Red Hat 4.8.3-9)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import inspect >>> from pykickstart import handlers >>> inspect.getsource(handlers) Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python2.7/inspect.py", line 701, in getsource lines, lnum = getsourcelines(object) File "/usr/lib64/python2.7/inspect.py", line 690, in getsourcelines lines, lnum = findsource(object) File "/usr/lib64/python2.7/inspect.py", line 538, in findsource raise IOError('could not get source code') IOError: could not get source code >>> There is a `pykickstart/handlers/__init__.py` file which is empty and the above import works fine as you can see. However `inspect.findsource` raises an exception. The same problem exists in Python 3.5 as well. The error comes from here: 532 module = getmodule(object, file) 533 if module: 534 lines = linecache.getlines(file, module.__dict__) 535 else: 536 lines = linecache.getlines(file) 537 if not lines: 538 raise IOError('could not get source code') At this point `lines` is an empty list and we raise the exception. I'm hitting this problem when using a mutation testing tool that relies on getsource (which calls findsource). One possible workaround is to add a comment in the __init__.py file and everything seems to be working then. Another one is to patch the tool I'm using to take into account empty __init__.py files. ---------- components: Library (Lib) messages: 270867 nosy: Alexander Todorov priority: normal severity: normal status: open title: inspect.findsource raises exception with empty __init__.py type: behavior versions: Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 08:21:40 2016 From: report at bugs.python.org (Max Khon) Date: Wed, 20 Jul 2016 12:21:40 +0000 Subject: [issue14903] dictobject infinite loop in module set-up In-Reply-To: <1337890784.99.0.00556765207687.issue14903@psf.upfronthosting.co.za> Message-ID: <1469017300.17.0.605387206615.issue14903@psf.upfronthosting.co.za> Max Khon added the comment: I reproduced the problem with Python 2.7.5 as shipped with CentOS 7: root at 192.168.0.86 /home/padmin # python -V Python 2.7.5 root at 192.168.0.86 /home/padmin # rpm -q python python-2.7.5-34.el7.x86_64 root at 192.168.0.86 /home/padmin # (gdb) bt #0 lookdict_string (mp=, key='RPMTAG_OPTFLAGS', hash=411442822543039667) at /usr/src/debug/Python-2.7.5/Objects/dictobject.c:461 #1 0x00007f92d6d9f2c9 in insertdict (mp=0x2502600, key='RPMTAG_OPTFLAGS', hash=411442822543039667, value=1122) at /usr/src/debug/Python-2.7.5/Objects/dictobject.c:559 #2 0x00007f92d6d9f3b0 in dict_set_item_by_hash_or_entry ( op={'RPMTAG_HEADERREGIONS': 64, 'RPMTAG_EXCLUSIVEOS': 1062, 'fi': , 'RPMTAG_CHANGELOGNAME': 1081, 'RPMTAG_CONFLICTNEVRS': 5044, 'RPMTAG_FILECAPS': 5010, 'RPMTAG_FILERDEVS': 1033, 'RPMTAG_COLLECTIONS': 5029, 'RPMTAG_BUGURL': 5012, 'setStats': , 'RPMTAG_FILEDIGESTALGO': 5011, 'RPMTAG_DEPENDSDICT': 1145, 'RPMTAG_CLASSDICT': 1142, 'RPMTAG_FILEMODES': 1030, 'RPMTAG_FILEDEPENDSN': 1144, 'RPMTAG_BUILDTIME': 1006, 'ii': , 'RPMTAG_INSTALLCOLOR': 1127, 'RPMTAG_CHANGELOGTEXT': 1082, 'RPMTAG_HEADERCOLOR': 5017, 'RPMTAG_CONFLICTNAME': 1054, 'RPMTAG_CONFLICTS': 1054, 'setLogFile': , 'versionCompare': , 'RPMTAG_CONFLICTVERSION': 1055, 'RPMTAG_NVRA': 1196, 'RPMTAG_NOPATCH': 1052, 'RPMTAG_HEADERI18NTABLE': 100, 'RPMTAG_LONGARCHIVESIZE': 271, 'RPMTAG_FILEREQUIRE': 5002, 'RPMTAG_FILEDEPENDSX': 1143, 'RPMTAG_EVR': 5013, 'RPMTAG_INSTALLTIME': 1008, 'RPMTAG_NAME': 1000, 'RPMTAG_LONG...(truncated), key=, hash=, ep=, value=) at /usr/src/debug/Python-2.7.5/Objects/dictobject.c:774 #3 0x00007f92d6da18a8 in PyDict_SetItemString ( v={'RPMTAG_HEADERREGIONS': 64, 'RPMTAG_EXCLUSIVEOS': 1062, 'fi': , 'RPMTAG_CHANGELOGNAME': 1081, 'RPMTAG_CONFLICTNEVRS': 5044, 'RPMTAG_FILECAPS': 5010, 'RPMTAG_FILERDEVS': 1033, 'RPMTAG_COLLECTIONS': 5029, 'RPMTAG_BUGURL': 5012, 'setStats': , 'RPMTAG_FILEDIGESTALGO': 5011, 'RPMTAG_DEPENDSDICT': 1145, 'RPMTAG_CLASSDICT': 1142, 'RPMTAG_FILEMODES': 1030, 'RPMTAG_FILEDEPENDSN': 1144, 'RPMTAG_BUILDTIME': 1006, 'ii': , 'RPMTAG_INSTALLCOLOR': 1127, 'RPMTAG_CHANGELOGTEXT': 1082, 'RPMTAG_HEADERCOLOR': 5017, 'RPMTAG_CONFLICTNAME': 1054, 'RPMTAG_CONFLICTS': 1054, 'setLogFile': , 'versionCompare': , 'RPMTAG_CONFLICTVERSION': 1055, 'RPMTAG_NVRA': 1196, 'RPMTAG_NOPATCH': 1052, 'RPMTAG_HEADERI18NTABLE': 100, 'RPMTAG_LONGARCHIVESIZE': 271, 'RPMTAG_FILEREQUIRE': 5002, 'RPMTAG_FILEDEPENDSX': 1143, 'RPMTAG_EVR': 5013, 'RPMTAG_INSTALLTIME': 1008, 'RPMTAG_NAME': 1000, 'RPMTAG_LONG...(truncated), key=key at entry=0x7f92c83bf537 "RPMTAG_OPTFLAGS", item=item at entry=1122) at /usr/src/debug/Python-2.7.5/Objects/dictobject.c:2448 #4 0x00007f92d6e181f2 in PyModule_AddObject (m=m at entry=, name=name at entry=0x7f92c83bf537 "RPMTAG_OPTFLAGS", o=o at entry=1122) at /usr/src/debug/Python-2.7.5/Python/modsupport.c:616 #5 0x00007f92d6e182d8 in PyModule_AddIntConstant (m=m at entry=, name=name at entry=0x7f92c83bf537 "RPMTAG_OPTFLAGS", value=value at entry=1122) at /usr/src/debug/Python-2.7.5/Python/modsupport.c:628 #6 0x00007f92c85e2b20 in addRpmTags (module=) at rpmmodule.c:200 #7 initModule (m=) at rpmmodule.c:343 #8 init_rpm () at rpmmodule.c:281 #9 0x00007f92d6e13ed9 in _PyImport_LoadDynamicModule (name=name at entry=0x24f69d0 "rpm._rpm", pathname=pathname at entry=0x24f79e0 "/usr/lib64/python2.7/site-packages/rpm/_rpmmodule.so", fp=) at /usr/src/debug/Python-2.7.5/Python/importdl.c:53 ... The infinite loop happens when "import rpm" is called in low-memory conditions (e.g. when handling ENOMEM or exceptions.MemoryError - RedHat/CentOS abrt-addon-python package which installs sys.excepthook handler). ---------- nosy: +Max Khon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 08:48:44 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 20 Jul 2016 12:48:44 +0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1469018924.0.0.461245359054.issue1621@psf.upfronthosting.co.za> Martin Panter added the comment: Serhiy: slice-step.patch seems to be fine with negative slice steps. The actual indexes are still positive, and ?unsigned? arithmetic is really modular arithmetic, so when you add the negative ?unsigned? step value, it decrements the index properly. Antti: if you use the sanitizer, (almost?) all the shift errors are for left shifts, either of a positive signed overflow, or a negative value. There is a bit more discussion of bit shift errors in Issue 20932. Examples: Modules/audioop.c:1527:43: runtime error: left shift of negative value -24 Objects/unicodeobject.c:5152:29: runtime error: left shift of 255 by 24 places cannot be represented in type 'int' I didn?t see any sanitizer reports about right shifts; perhaps it doesn?t report those (being implemenation-defined, rather than undefined, behaviour). And the only report about an excessive shift size is due to a known bug in ctypes, Issue 15119. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 09:27:29 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 20 Jul 2016 13:27:29 +0000 Subject: [issue20932] Undefined behavior flagged by Clang 3.4 (Python 3.5 from hg) In-Reply-To: <1394851052.88.0.193633571289.issue20932@psf.upfronthosting.co.za> Message-ID: <1469021249.47.0.165733524059.issue20932@psf.upfronthosting.co.za> Martin Panter added the comment: Serhiy?s patch does fix about half the errors (1 whole screenful reduces to a bit over 1/2 a screenful). I do find it a bit ugly though (four casts in the one term of a macro!). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 09:54:45 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 Jul 2016 13:54:45 +0000 Subject: [issue27578] inspect.findsource raises exception with empty __init__.py In-Reply-To: <1469016358.37.0.125453636257.issue27578@psf.upfronthosting.co.za> Message-ID: <1469022885.86.0.726272891027.issue27578@psf.upfronthosting.co.za> R. David Murray added the comment: I agree that this is inconsistent. It might be quite tricky to fix, though, unless we special case file.endswith('__init__.py'), which feels like a hack. But maybe it is appropriate. ---------- nosy: +r.david.murray versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 10:02:14 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 20 Jul 2016 14:02:14 +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: <1469023334.98.0.836143313501.issue23951@psf.upfronthosting.co.za> Berker Peksag added the comment: -1 I think the current devguide theme looks fine and it would be nice to keep devguide and Python documentations use different themes. I'd be -0 if the patch was small, but diff stat "11 files changed, 1651 insertions(+), 10 deletions(-)" is huge and it would be nice to avoid code duplication. The current theme has some bugs and now we will have to update two different repos everytime we touch the docs.p.o theme. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 10:10:28 2016 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 20 Jul 2016 14:10:28 +0000 Subject: [issue8406] Make some setup.py paths exclude-able In-Reply-To: <1271301152.77.0.297402624492.issue8406@psf.upfronthosting.co.za> Message-ID: <1469023828.24.0.671481787267.issue8406@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I don't understand why this issue was closed. Apparently it was closed because it is an old issue without checking if the issue is still relevant??? To be honest the way setup.py looks for libraries could use some attention, the current methods is a bit too magical to my taste. It is also too easy to accidentally depend on libraries you don't want to rely on (I have to create CPython builds for internal redistribution on a separate VM to avoid relying on HomeBrew). P.S. Sorry about the late reaction, the bug tracker mails about this came in just before I went on a trip. I'm finally catching up with older mail. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 10:15:39 2016 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 20 Jul 2016 14:15:39 +0000 Subject: [issue13376] readline: pre_input_hook not getting called In-Reply-To: <1320825555.41.0.989618903693.issue13376@psf.upfronthosting.co.za> Message-ID: <1469024139.62.0.71626529893.issue13376@psf.upfronthosting.co.za> Ronald Oussoren added the comment: The problem with fixing in editline is that Apple ships a copy of editline and that is used when build CPython by default. IMHO it would be acceptable to work around this in the readline extension if that can be done in a clean way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 10:24:37 2016 From: report at bugs.python.org (Carol Willing) Date: Wed, 20 Jul 2016 14:24:37 +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: <1469024677.91.0.530553180346.issue23951@psf.upfronthosting.co.za> Carol Willing added the comment: Lisa, thanks for your work and persistence on this patch. In particular, the pydoctheme's sidebar improves the user's ability to navigate through the devguide's content. Thank you! If folks desire more distinction between the devguide and the language docs, color and styling could be tweaked in a future patch or PR. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 10:42:29 2016 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Jul 2016 14:42:29 +0000 Subject: [issue27579] Add a tutorial for AsyncIO in the documentation Message-ID: <1469025749.21.0.829921979586.issue27579@psf.upfronthosting.co.za> New submission from St?phane Wirtel: The documentation of AsyncIO is well written for a developer, but it's a reference. We have the description of all the methods, classes, etc... But we want to learn to develop with AsyncIO, it's difficult, because there is no many examples in this reference and we have to look for some examples on Internet. Could we add a AsyncIO tutorial|cookbook|howto ? because we have a "Logging Cookbook" but not a "AsyncIO 101". Thank you Stephane ---------- assignee: docs at python components: Documentation messages: 270876 nosy: asvetlov, docs at python, haypo, matrixise, yselivanov priority: normal severity: normal status: open title: Add a tutorial for AsyncIO in the documentation versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 10:45:31 2016 From: report at bugs.python.org (Carol Willing) Date: Wed, 20 Jul 2016 14:45:31 +0000 Subject: [issue8406] Make some setup.py paths exclude-able In-Reply-To: <1271301152.77.0.297402624492.issue8406@psf.upfronthosting.co.za> Message-ID: <1469025931.63.0.00412329628084.issue8406@psf.upfronthosting.co.za> Carol Willing added the comment: Ronald, while I may have closed this issue prematurely in other folks' view, I did not do so without thought or reflecting if the issue was relevant. My recommendation to close the issue was based on several factors: - the desire to assist triaging issues that are not actionable in their current state - the lack of activity for over 6 years on an overly broad issue topic - an opportunity for a more suitable issue to be opened which more accurately reflects the development needed and actions needed - this issue's history, if necessary, could easily be referred to in a better scoped issue Overall, I see closing this issue as an opportunity to address in a new issue the specific setup.py improvements that would be helpful today. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 10:53:26 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 20 Jul 2016 14:53:26 +0000 Subject: [issue27579] Add a tutorial for AsyncIO in the documentation In-Reply-To: <1469025749.21.0.829921979586.issue27579@psf.upfronthosting.co.za> Message-ID: <3DA8F43D-3F5B-47EE-BE3E-086F41B44F19@gmail.com> Yury Selivanov added the comment: I guess someone has to step forward -- i can propose an initial patch with the tutorial. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 10:58:21 2016 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 20 Jul 2016 14:58:21 +0000 Subject: [issue8406] Make some setup.py paths exclude-able In-Reply-To: <1271301152.77.0.297402624492.issue8406@psf.upfronthosting.co.za> Message-ID: <1469026701.87.0.708962422258.issue8406@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Did you create that new issue? If not this feature request will likely be forgotten. Hmmm... Issue7713 appears to be good enough for remembering that there is a problem with the way setup.py looks for libraries. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 10:58:57 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 Jul 2016 14:58:57 +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: <1469026737.51.0.0980115654288.issue23951@psf.upfronthosting.co.za> R. David Murray added the comment: I think a reasonably consistent look and feel for all our docs is a good thing. It's a "branding" kind of thing. Differentiation by color works for me, but really I don't care about differentiating them, myself. (I actually find it jarring that I don't get a table of contents as the main page, like I do in the rest of our docs.) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 11:04:12 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 Jul 2016 15:04:12 +0000 Subject: [issue8406] Make some setup.py paths exclude-able In-Reply-To: <1271301152.77.0.297402624492.issue8406@psf.upfronthosting.co.za> Message-ID: <1469027052.03.0.200090233507.issue8406@psf.upfronthosting.co.za> R. David Murray added the comment: Right. Only close an issue if there is an existing open issue that addresses the topic better. Age alone is never a criteria for closing issues. Since Ronald agrees the other issue is enough we'll leave this closed, but it wouldn't be crazy to reopen it either. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 11:08:24 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 Jul 2016 15:08:24 +0000 Subject: [issue8406] Make some setup.py paths exclude-able In-Reply-To: <1271301152.77.0.297402624492.issue8406@psf.upfronthosting.co.za> Message-ID: <1469027304.4.0.63665183726.issue8406@psf.upfronthosting.co.za> R. David Murray added the comment: Heh, that should have been "only close an old issue that hasn't been otherwise resolved if...". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 11:18:42 2016 From: report at bugs.python.org (Carol Willing) Date: Wed, 20 Jul 2016 15:18:42 +0000 Subject: [issue8406] Make some setup.py paths exclude-able In-Reply-To: <1271301152.77.0.297402624492.issue8406@psf.upfronthosting.co.za> Message-ID: <1469027922.84.0.98802953519.issue8406@psf.upfronthosting.co.za> Carol Willing added the comment: Fair enough. Ronald and David, I respect your suggestions and thoughts, and I will not triage or close old issues. FWIW, I was trying to be helpful. We regularly close issues that are 1+ year old on Jupyter/IPython or rescope the issue to be actionable for contribution. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 11:32:32 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 20 Jul 2016 15:32:32 +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: <1469028751.99.0.244137934843.issue23951@psf.upfronthosting.co.za> Berker Peksag added the comment: Can we at least serve images and JS files (py.png -- this gives 404 now, copybutton.js, sidebar.js) from docs.python.org? It seems like devguide_theme_revised.patch was committed accidentally: https://hg.python.org/devguide/rev/9e7b1bc15ba7#l3.3 The color of a:hover needs to be tweaked here: https://dl.dropboxusercontent.com/u/166024/devguide.png I'd also delete rstllint.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 11:34:09 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 20 Jul 2016 15:34:09 +0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1469028849.81.0.531621431981.issue1621@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- nosy: -gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 11:37:23 2016 From: report at bugs.python.org (Steve Holden) Date: Wed, 20 Jul 2016 15:37:23 +0000 Subject: [issue15443] datetime module has no support for nanoseconds In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za> Message-ID: <1469029043.22.0.855489866034.issue15443@psf.upfronthosting.co.za> Steve Holden added the comment: BTW, I presume it's a bug in the issue tracker that my view of this message ends after a few lines of msg166386? Makes it rather difficult to track the issue! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 12:03:37 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 Jul 2016 16:03:37 +0000 Subject: [issue15443] datetime module has no support for nanoseconds In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za> Message-ID: <1469030617.92.0.470418184416.issue15443@psf.upfronthosting.co.za> R. David Murray added the comment: I doubt it is a bug in the tracker. I've seen that kind of thing when I am having network issues...the browser renders what it gets, and if it doesn't get it all it looks like the page ends early. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 12:05:08 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Jul 2016 16:05:08 +0000 Subject: [issue15443] datetime module has no support for nanoseconds In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za> Message-ID: <1469030708.93.0.315680386557.issue15443@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: -pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 12:05:43 2016 From: report at bugs.python.org (Tim Peters) Date: Wed, 20 Jul 2016 16:05:43 +0000 Subject: [issue15443] datetime module has no support for nanoseconds In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za> Message-ID: <1469030743.89.0.417547637237.issue15443@psf.upfronthosting.co.za> Tim Peters added the comment: FYI, I'm seeing the same kind of odd truncation Steve sees - but it goes away if I refresh the page. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 12:32:32 2016 From: report at bugs.python.org (Ludovic Gasc) Date: Wed, 20 Jul 2016 16:32:32 +0000 Subject: [issue27579] Add a tutorial for AsyncIO in the documentation In-Reply-To: <1469025749.21.0.829921979586.issue27579@psf.upfronthosting.co.za> Message-ID: <1469032352.41.0.482957176471.issue27579@psf.upfronthosting.co.za> Changes by Ludovic Gasc : ---------- nosy: +Ludovic.Gasc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 13:09:51 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 20 Jul 2016 17:09:51 +0000 Subject: [issue15443] datetime module has no support for nanoseconds In-Reply-To: <1469029043.22.0.855489866034.issue15443@psf.upfronthosting.co.za> Message-ID: <69F520C5-EE63-40A5-BE70-0AF2008A6AED@gmail.com> Alexander Belopolsky added the comment: I've seen a similar glitch. Reloading the page usually fixes the problem. > On Jul 20, 2016, at 11:37 AM, Steve Holden wrote: > > > Steve Holden added the comment: > > BTW, I presume it's a bug in the issue tracker that my view of this message ends after a few lines of msg166386? Makes it rather difficult to track the issue! > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 14:31:08 2016 From: report at bugs.python.org (Brett Cannon) Date: Wed, 20 Jul 2016 18:31:08 +0000 Subject: [issue27574] Faster parsing keyword arguments In-Reply-To: <1468944235.85.0.107735525995.issue27574@psf.upfronthosting.co.za> Message-ID: <1469039468.85.0.374185616703.issue27574@psf.upfronthosting.co.za> Brett Cannon added the comment: I haven't reviewed the patch, but the idea is great as I know one of Larry's hopes of using Argument Clinic was to allow for this kind of speed-up. ---------- nosy: +brett.cannon, larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 15:22:56 2016 From: report at bugs.python.org (Ned Deily) Date: Wed, 20 Jul 2016 19:22:56 +0000 Subject: [issue21136] fractions.Fraction.__pow__ does unneeded renormalization In-Reply-To: <1396482750.35.0.873465877702.issue21136@psf.upfronthosting.co.za> Message-ID: <1469042576.65.0.183518534288.issue21136@psf.upfronthosting.co.za> Ned Deily added the comment: @Vedran, the original issue is closed and the code for it already released. Please open a new issue referencing this one, otherwise your comments here will likely be forgotten. ---------- nosy: +ned.deily versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 15:25:55 2016 From: report at bugs.python.org (Alakshendra Yadav) Date: Wed, 20 Jul 2016 19:25:55 +0000 Subject: [issue27576] An unexpected difference between dict and OrderedDict In-Reply-To: <1468962090.7.0.636707577928.issue27576@psf.upfronthosting.co.za> Message-ID: <1469042755.91.0.401796658322.issue27576@psf.upfronthosting.co.za> Changes by Alakshendra Yadav : ---------- nosy: +alakyadav _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 15:48:34 2016 From: report at bugs.python.org (Ned Deily) Date: Wed, 20 Jul 2016 19:48:34 +0000 Subject: [issue21136] fractions.Fraction.__pow__ does unneeded renormalization In-Reply-To: <1396482750.35.0.873465877702.issue21136@psf.upfronthosting.co.za> Message-ID: <1469044114.56.0.247718226839.issue21136@psf.upfronthosting.co.za> Ned Deily added the comment: I now see Vedran has already opened Issue27539 for this. Sorry for the additional noise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 16:14:12 2016 From: report at bugs.python.org (David Su) Date: Wed, 20 Jul 2016 20:14:12 +0000 Subject: [issue27575] dict viewkeys intersection slow for large dicts In-Reply-To: <1468950707.74.0.640405379684.issue27575@psf.upfronthosting.co.za> Message-ID: <1469045652.55.0.046112464259.issue27575@psf.upfronthosting.co.za> Changes by David Su : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 16:19:06 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 20 Jul 2016 20:19:06 +0000 Subject: [issue27294] Better repr for Tkinter event objects In-Reply-To: <1465648557.25.0.737232700025.issue27294@psf.upfronthosting.co.za> Message-ID: <1469045946.23.0.428740861712.issue27294@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- Removed message: http://bugs.python.org/msg268824 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 16:19:29 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 20 Jul 2016 20:19:29 +0000 Subject: [issue27294] Better repr for Tkinter event objects In-Reply-To: <1465648557.25.0.737232700025.issue27294@psf.upfronthosting.co.za> Message-ID: <1469045969.58.0.905205720469.issue27294@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- Removed message: http://bugs.python.org/msg268826 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 16:57:29 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 20 Jul 2016 20:57:29 +0000 Subject: [issue27294] Better repr for Tkinter event objects In-Reply-To: <1465648557.25.0.737232700025.issue27294@psf.upfronthosting.co.za> Message-ID: <1469048249.79.0.778461601175.issue27294@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Addendum: I verified flag 8 is Mod1 is Numlock on Windows. http://infohost.nmt.edu/tcc/help/pubs/tkinter/web/event-handlers.html has table that claims that 8 is Left Alt and that 16 is NumLock. From what you say above, true on non-mac *nix, and only there. Flag 32 is Mod3 = Scrolllock on Windows. Question: autocomplete.py refers to event.mc_state in if hasattr(event, "mc_state") and event.mc_state: # A modifier was pressed along with the tab, continue as usual. return It is not mentioned as an event field in either the NMT ref or http://www.tcl.tk/man/tcl8.6/TkCmd/event.htm#M29. However, it seems to be the state minus any 'lock' flags, Nun/Caps/Scrolllock on Windows. It must use a system-specific mask. The only Google hit for "tk event mc_state" is my recent commit of test_autocomplete.py. Is this a normal tk event attribute or a local addition? There is also mc_type, which is 0 for a tab combinations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 17:06:43 2016 From: report at bugs.python.org (Steve Dower) Date: Wed, 20 Jul 2016 21:06:43 +0000 Subject: [issue27569] Windows install problems In-Reply-To: <1468892841.27.0.521360350751.issue27569@psf.upfronthosting.co.za> Message-ID: <1469048803.37.0.929419720392.issue27569@psf.upfronthosting.co.za> Steve Dower added the comment: That time it looks like it failed to install the launcher for all users. Did you get an elevation prompt? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 18:25:12 2016 From: report at bugs.python.org (Ricardo Esperanza) Date: Wed, 20 Jul 2016 22:25:12 +0000 Subject: [issue27569] Windows install problems In-Reply-To: <1468892841.27.0.521360350751.issue27569@psf.upfronthosting.co.za> Message-ID: <1469053512.2.0.577556539739.issue27569@psf.upfronthosting.co.za> Ricardo Esperanza added the comment: Steve I tried again an installed correctly. Don?t understand what happened, but anyway it installed thanks ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 18:40:24 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Jul 2016 22:40:24 +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: <1469054424.53.0.907955903447.issue23951@psf.upfronthosting.co.za> STINNER Victor added the comment: Berker Peksag > -1. I think the current devguide theme looks fine and it would be nice to keep devguide and Python documentations use different themes. I pushed the change because there were 3 positive votes and no negative vote, and I like the proposed them. > I'd be -0 if the patch was small, but diff stat "11 files changed, 1651 insertions(+), 10 deletions(-)" is huge and it would be nice to avoid code duplication. The current theme has some bugs and now we will have to update two different repos everytime we touch the docs.p.o theme. Sorry but I don't know anything about Sphinx theme. If you know how to fix mentionned issues, please write a patch and/or push directly changes. > It seems like devguide_theme_revised.patch was committed accidentally: https://hg.python.org/devguide/rev/9e7b1bc15ba7#l3.3 What do you mean? It was deliberate for me to push devguide_theme_revised.patch. I don't see strong reason in comments to not push the change. > I'd also delete rstllint.py. It adds a new "make check" which doesn't hurt. Maybe it may be better to contribute to Sphinx, but again, it's short and doesn't hurt. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 18:59:18 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 20 Jul 2016 22:59: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: <20160720225915.25489.49033.51BE82C8@psf.io> Roundup Robot added the comment: New changeset 7d8f988522ed by Victor Stinner in branch 'default': Issue #23951: remove devguide_theme_revised.patch https://hg.python.org/devguide/rev/7d8f988522ed ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 20:55:49 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 21 Jul 2016 00:55:49 +0000 Subject: [issue3559] IDLE: Pasted newline doesn't trigger execution when typed newline would In-Reply-To: <1218778489.95.0.525643042727.issue3559@psf.upfronthosting.co.za> Message-ID: <1469062549.37.0.068300343967.issue3559@psf.upfronthosting.co.za> Terry J. Reedy added the comment: My initial experiments indicate that pasted tabs are at least sometimes treated differently, but I need to do more to be sure. ---------- versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 20:58:37 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 21 Jul 2016 00:58:37 +0000 Subject: [issue16198] IDLE - tabbing in a string always brings up file completion window In-Reply-To: <1349974121.21.0.319562901545.issue16198@psf.upfronthosting.co.za> Message-ID: <1469062717.7.0.279275204936.issue16198@psf.upfronthosting.co.za> Terry J. Reedy added the comment: It is intentional that be treated as a normal tab. The autocomplete_event tab handler begins with if hasattr(event, "mc_state") and event.mc_state: # A modifier was pressed along with the tab, continue as usual. return To fix the problem with tabs at the beginning of a line within multiline strings, I am adding to the condition a clause to catch tabs at the beginning of lines, whether within a multiline string or not. or not self.text.get("insert linestart", "insert").strip() Tests still pass with this addition. I need to add a test that fails without it. I think a tab should bring up completion box even immediately after an opening quote, as in open(' Typing a letter fails to open a box if there is only one completion, so that is not a foolproof way to get a box with all choices. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 21:21:35 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 21 Jul 2016 01:21:35 +0000 Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1469064095.34.0.292073932617.issue15873@psf.upfronthosting.co.za> Martin Panter added the comment: Mathieu: Maybe you haven?t seen some of the comments on your older patches. E.g. my comment on fromisoformat4.patch about improper use of ?with self.assertRaises(...)? still stands. Also, adding some documentation to the patch might help the likes of Anders figure out the scope of the change. I think we decided to parse RFC 3339?s ?internet date and time format? profile of ISO 8601 with the date, time, and datetime classes, including tolerating arbitrary resolutions of fractions of seconds in the time, and parsing time zones. I don?t think we need to test every combination of the other ISO 8601 formats. There are already a couple of negative tests. Are there any in particular you think are important to add? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 21:29:11 2016 From: report at bugs.python.org (irdb) Date: Thu, 21 Jul 2016 01:29:11 +0000 Subject: [issue9618] IDLE shell ignores all but first statement In-Reply-To: <1281912730.25.0.579832640698.issue9618@psf.upfronthosting.co.za> Message-ID: <1469064551.12.0.429215430718.issue9618@psf.upfronthosting.co.za> Changes by irdb : ---------- nosy: +irdb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 21:51:06 2016 From: report at bugs.python.org (Patrick Stewart) Date: Thu, 21 Jul 2016 01:51:06 +0000 Subject: [issue17310] Ctypes callbacks shows problem on Windows Python (64bit) In-Reply-To: <1361980274.18.0.791136497364.issue17310@psf.upfronthosting.co.za> Message-ID: <1469065866.33.0.602168145108.issue17310@psf.upfronthosting.co.za> Patrick Stewart added the comment: This also fixes python 3.5 ---------- nosy: +Patrick Stewart _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 21:54:18 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 21 Jul 2016 01:54:18 +0000 Subject: [issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts In-Reply-To: <1468881013.81.0.152859673137.issue27568@psf.upfronthosting.co.za> Message-ID: <1469066058.24.0.504605571166.issue27568@psf.upfronthosting.co.za> Martin Panter added the comment: I think I misunderstood the Windows situation. Now I understand Windows has no lower-case variable names, so this patch would stop accepting any HTTP_PROXY variable there (in CGI mode). But that is okay by me. I agree the mixed-case scenario is not worth worrying too much about. The normal scenario is all lowercase (http_proxy), and I think all-uppercase (HTTP_PROXY) is only supported for compatibility with some older browsers or OSes (can?t remember the details). However, since we already document ?a case-insensitive approach?, perhaps it needs tweaking somehow. Perhaps it would be more correct to say, in CGI mode: * Only lowercase _proxy suffix is accepted (stricter than just ignoring uppercase) * No variable is accepted where names must be uppercase, i.e. Windows. As I understand it, you cannot have a lowercase http_proxy variable there. Also, I think the ?note? additions should be indented under the getproxies() etc headings. (Or drop the markup and make it an ordinary sentence or paragraph. ?Note that? is also redundant IMO.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 21:58:15 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 21 Jul 2016 01:58:15 +0000 Subject: [issue734176] Make Tkinter.py's nametowidget work with cloned menu widgets Message-ID: <1469066295.05.0.24026413368.issue734176@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Serhiy, if you are sure your patch is an improvement, then I think you should commit it without waiting for perfection. Only the other hand, #18686 does not demonstrate a problem *to me* as it does not fail for me. Does anyone else reproduce the failure on a current non-Windows system? Based just on what I can see, I would be inclined to close this. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 22:54:50 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 21 Jul 2016 02:54:50 +0000 Subject: [issue15786] IDLE code completion window can hang or misbehave with mouse In-Reply-To: <1346027701.33.0.908436854594.issue15786@psf.upfronthosting.co.za> Message-ID: <1469069690.71.0.708681893783.issue15786@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Serhiy, could you take at least a quick look at this troublesome issue? The issue seems to be this: idlelib.autocomplete_w.py has # at the top LISTUPDATE_SEQUENCE = "" # within show_window method self.listupdateid = listbox.bind(LISTUPDATE_SEQUENCE, self.listselect_event) # and later def listselect_event(self, event): However, when one clicks on a completion box, the click is only seen by the text window underneath, and the box disappears. On Mac, there are also nasty symptoms like IDLE freezing. I that changing the sequence to '' and addint 'return "break"' to the end of listselect_event might solve the problem. When it did not, I added prints to the top of __init__ and listselect_event. Running in the console, the first printed, the second did not. Do you have any idea why not? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 23:05:36 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 21 Jul 2016 03:05:36 +0000 Subject: [issue26662] configure/Makefile doesn't check if "python" command works, needed to build Objects/typeslots.inc In-Reply-To: <1459247902.98.0.893274525942.issue26662@psf.upfronthosting.co.za> Message-ID: <1469070336.08.0.178381442419.issue26662@psf.upfronthosting.co.za> Martin Panter added the comment: The new patch looks good enough. The main reason I complained about the error message is that it sounds like you need Python in order to build Python. Obviously you need Python to run a modified file like typeslots.py, but there is supposed to be an alternative if you don?t need to regenerate files. I think running ?make touch? should fudge the timestamps so that Make does not run it. It works for me: $ touch Objects/typeslots.py $ make touch cd .; \ hg --config extensions.touch=Tools/hg/hgtouch.py touch -v Touching Objects/typeslots.inc $ make # Does not run typeslots.py gcc [. . .] Objects/typeobject.c [. . .] Unfortunately, I understand ?make touch? requires Mercurial, which requires Python 2. That weakens my argument about bootstrapping Python, but it is still valid in some scenarios. Maybe we should recommend ?make -t Objects/typeslots.inc? etc instead of ?make touch?. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 23:30:38 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 21 Jul 2016 03:30:38 +0000 Subject: [issue27575] dict viewkeys intersection slow for large dicts In-Reply-To: <1468950707.74.0.640405379684.issue27575@psf.upfronthosting.co.za> Message-ID: <1469071838.68.0.906239348491.issue27575@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, sets and dicts convert back and forth very efficiently (the hash values are reused and the collection is presized with just a single memory allocation). Also, the sets and dicts have shared pointers to the underlying data (which is often much bigger than the containers that refers to the data). Also, the use case of having very large dicts with repeated intersection operations isn't common enough to warrant any significant code expansion (your solution two). I don't understand your "solution one". PySet_New(self) does copy references to the keys from the dict to a set and the intersection_update() does perform operations on that set. Lastly, since there was no clear example given, there isn't an opportunity to look at it to see if the code would have been better designed to simply use sets for the set operations and keep the dict around to the key to value transformations (in other words, the current toolset may already afford some way to accomplish the goal). ---------- versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 00:28:37 2016 From: report at bugs.python.org (David Su) Date: Thu, 21 Jul 2016 04:28:37 +0000 Subject: [issue27575] dict viewkeys intersection slow for large dicts In-Reply-To: <1468950707.74.0.640405379684.issue27575@psf.upfronthosting.co.za> Message-ID: <1469075317.32.0.367056288254.issue27575@psf.upfronthosting.co.za> David Su added the comment: Here are some tests that I ran: Using current naive viewkeys intersection: $ python -m timeit -n 100 -s "d = dict.fromkeys(xrange(10000000), 0)" "d.viewkeys() & {0}" 100 loops, best of 3: 447 msec per loop Nearly half a second per iteration is unacceptably slow. Solution 1 from my previous comment: $ python -m timeit -n 100 -s "d = dict.fromkeys(xrange(10000000), 0); s = set(d)" "s & {0}" 100 loops, best of 3: 0.391 usec per loop This solution caches the keys of the dict in a set, then performs all intersections on that set. The initial creation of the set is slow, and it wastes a lot of memory, but each iteration is much faster. The workaround that I ended up using: $ python -m timeit -n 100 -s "d = dict.fromkeys(xrange(10000000), 0)" "{item for item in {0} if item in d}" 100 loops, best of 3: 0.629 usec per loop This solution just looks up each value in the set to see if it is also in the dict using a set comprehension. This avoids wasting time and space on creating a set. For my use case, memory was a bigger issue as my dictionary can approach tens of GBs in size, and almost doubling the memory consumption from creating a cache set was unacceptable. Of course, in the set comprehension, the smaller of the dict/set should be iterated over to satisfy the O(min(len(d), len(s))) condition as specified in https://wiki.python.org/moin/TimeComplexity. A implementation would look something like this: def efficient_intersection(smaller_dict_or_set, bigger_dict_or_set): if len(bigger_dict_or_set) < len(smaller_dict_or_set): bigger_dict_or_set, smaller_dict_or_set = smaller_dict_or_set, bigger_dict_or_set return {item for item in smaller_dict_or_set if item in bigger_dict_or_set} In conclusion, porting over the set intersection logic to viewkeys would be the ideal solution. It avoids wasting memory like in the set cache solution, and I am sure the C implementation will be much faster than my workaround of manually performing an intersection using set comprehensions. My view is that dict.viewkeys() & set(...) should be as performant as the syntax suggests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 00:53:57 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 21 Jul 2016 04:53:57 +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: <1469076837.71.0.0713910282832.issue27130@psf.upfronthosting.co.za> Xiang Zhang added the comment: Hi, Martin. I replied your last comment and your patch looks good to me except one test fails: [1/1] test_zlib test_abcdefghijklmnop (test.test_zlib.ChecksumTestCase) test issue1202 compliance: signed crc32, adler32 in 2.x ... ok test_adler32empty (test.test_zlib.ChecksumTestCase) ... ok test_adler32start (test.test_zlib.ChecksumTestCase) ... ok test_crc32empty (test.test_zlib.ChecksumTestCase) ... ok test_crc32start (test.test_zlib.ChecksumTestCase) ... ok test_negative_crc_iv_input (test.test_zlib.ChecksumTestCase) ... ok test_penguins (test.test_zlib.ChecksumTestCase) ... ok test_same_as_binascii_crc32 (test.test_zlib.ChecksumTestCase) ... ok test_big_buffer (test.test_zlib.ChecksumBigBufferTestCase) ... ERROR test_badcompressobj (test.test_zlib.ExceptionTestCase) ... ok test_baddecompressobj (test.test_zlib.ExceptionTestCase) ... ok test_badlevel (test.test_zlib.ExceptionTestCase) ... ok test_decompressobj_badflush (test.test_zlib.ExceptionTestCase) ... ok test_overflow (test.test_zlib.ExceptionTestCase) ... ok test_64bit_compress (test.test_zlib.CompressTestCase) ... ok test_big_compress_buffer (test.test_zlib.CompressTestCase) ... ok test_big_decompress_buffer (test.test_zlib.CompressTestCase) ... ok test_custom_bufsize (test.test_zlib.CompressTestCase) ... ok test_incomplete_stream (test.test_zlib.CompressTestCase) ... ok test_large_bufsize (test.test_zlib.CompressTestCase) ... ok test_speech (test.test_zlib.CompressTestCase) ... ok test_speech128 (test.test_zlib.CompressTestCase) ... ok test_64bit_compress (test.test_zlib.CompressObjectTestCase) ... ok test_badcompresscopy (test.test_zlib.CompressObjectTestCase) ... ok test_baddecompresscopy (test.test_zlib.CompressObjectTestCase) ... ok test_big_compress_buffer (test.test_zlib.CompressObjectTestCase) ... ok test_big_decompress_buffer (test.test_zlib.CompressObjectTestCase) ... ok test_clear_unconsumed_tail (test.test_zlib.CompressObjectTestCase) ... ok test_compresscopy (test.test_zlib.CompressObjectTestCase) ... ok test_compressincremental (test.test_zlib.CompressObjectTestCase) ... ok test_compressoptions (test.test_zlib.CompressObjectTestCase) ... ok test_compresspickle (test.test_zlib.CompressObjectTestCase) ... ok test_decompimax (test.test_zlib.CompressObjectTestCase) ... ok test_decompinc (test.test_zlib.CompressObjectTestCase) ... ok test_decompincflush (test.test_zlib.CompressObjectTestCase) ... ok test_decompress_incomplete_stream (test.test_zlib.CompressObjectTestCase) ... ok test_decompress_unused_data (test.test_zlib.CompressObjectTestCase) ... ok test_decompresscopy (test.test_zlib.CompressObjectTestCase) ... ok test_decompressmaxlen (test.test_zlib.CompressObjectTestCase) ... ok test_decompressmaxlenflush (test.test_zlib.CompressObjectTestCase) ... ok test_decompresspickle (test.test_zlib.CompressObjectTestCase) ... ok test_empty_flush (test.test_zlib.CompressObjectTestCase) ... ok test_flush_custom_length (test.test_zlib.CompressObjectTestCase) ... ok test_flush_large_length (test.test_zlib.CompressObjectTestCase) ... ok test_flush_with_freed_input (test.test_zlib.CompressObjectTestCase) ... ok test_flushes (test.test_zlib.CompressObjectTestCase) ... ok test_large_unconsumed_tail (test.test_zlib.CompressObjectTestCase) ... ok test_large_unused_data (test.test_zlib.CompressObjectTestCase) ... ok test_maxlen_custom (test.test_zlib.CompressObjectTestCase) ... ok test_maxlen_large (test.test_zlib.CompressObjectTestCase) ... ok test_maxlenmisc (test.test_zlib.CompressObjectTestCase) ... ok test_odd_flush (test.test_zlib.CompressObjectTestCase) ... ok test_pair (test.test_zlib.CompressObjectTestCase) ... ok test_wbits (test.test_zlib.CompressObjectTestCase) ... ok ====================================================================== ERROR: test_big_buffer (test.test_zlib.ChecksumBigBufferTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/zhangxiang3/Python-2.7.12/Lib/test/test_support.py", line 1348, in wrapper return f(self, maxsize) File "/usr/home/zhangxiang3/Python-2.7.12/Lib/test/test_zlib.py", line 90, in test_big_buffer ChecksumTestCase.assertEqual32(self, zlib.crc32(data), 1044521549) TypeError: unbound method assertEqual32() must be called with ChecksumTestCase instance as first argument (got ChecksumBigBufferTestCase instance instead) ---------------------------------------------------------------------- Ran 54 tests in 317.008s FAILED (errors=1) test test_zlib failed -- Traceback (most recent call last): File "/usr/home/zhangxiang3/Python-2.7.12/Lib/test/test_support.py", line 1348, in wrapper return f(self, maxsize) File "/usr/home/zhangxiang3/Python-2.7.12/Lib/test/test_zlib.py", line 90, in test_big_buffer ChecksumTestCase.assertEqual32(self, zlib.crc32(data), 1044521549) TypeError: unbound method assertEqual32() must be called with ChecksumTestCase instance as first argument (got ChecksumBigBufferTestCase instance instead) 1 test failed: test_zlib ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 01:02:48 2016 From: report at bugs.python.org (Bobby Ocean) Date: Thu, 21 Jul 2016 05:02:48 +0000 Subject: [issue27580] CSV Null Byte Error Message-ID: <1469077368.13.0.160030895608.issue27580@psf.upfronthosting.co.za> New submission from Bobby Ocean: I think this has been asked before, but it has been awhile and I think needs to be re-addressed. Why doesn't the CSV module handle NULL bytes? Let me do some examples, ascii = [chr(n) for n in range(256)] #No errors print(ascii) #No errors print(dict(zip(ascii,ascii))) #No errors open('temp','r').writelines(ascii) #No errors f=open('temp','r') for line in f: print(line) #No errors f.close() Python hsndles every ascii chr, DEL, ESC, RETURN, etc. It displays those characters, uses them as keys or values, etc. But now try, import csv data = csv.DictReader(ascii) for line in data: print(line) #NULL Byte Error But we can quick fix this easily, ascii.pop(0) data = csv.DictReader(ascii) for line in data: print(line) #No Errors Doesn't it seem odd that we allow the use of every chr as keys, vslues, prints, etc. but then we hold a special exception for using the csv module and yhat special exception is not the ESC or DEL or any other non-printable chr, the exception is for the NULL? ---------- components: Extension Modules messages: 270908 nosy: bobbyocean priority: normal severity: normal status: open title: CSV Null Byte Error type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 01:36:48 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 21 Jul 2016 05:36:48 +0000 Subject: [issue27581] Fix overflow check in PySequence_Tuple Message-ID: <1469079408.21.0.622161481276.issue27581@psf.upfronthosting.co.za> New submission from Xiang Zhang: Overflow check in PySequence_Tuple relies on undefined behaviour, fix it. ---------- components: Interpreter Core files: overflow_check_in_PySequence_Tuple.patch keywords: patch messages: 270909 nosy: martin.panter, serhiy.storchaka, xiang.zhang priority: normal severity: normal status: open title: Fix overflow check in PySequence_Tuple type: enhancement versions: Python 2.7, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43806/overflow_check_in_PySequence_Tuple.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 05:03:57 2016 From: report at bugs.python.org (SilentGhost) Date: Thu, 21 Jul 2016 09:03:57 +0000 Subject: [issue27580] CSV Null Byte Error In-Reply-To: <1469077368.13.0.160030895608.issue27580@psf.upfronthosting.co.za> Message-ID: <1469091837.76.0.250764120261.issue27580@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 06:37:03 2016 From: report at bugs.python.org (Iovan Irinel) Date: Thu, 21 Jul 2016 10:37:03 +0000 Subject: [issue27562] Import error encodings (Windows xp compatibility) In-Reply-To: <1468849701.41.0.980015051967.issue27562@psf.upfronthosting.co.za> Message-ID: <1469097423.81.0.333185032507.issue27562@psf.upfronthosting.co.za> Iovan Irinel added the comment: Still searching for someone who can do it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 07:28:17 2016 From: report at bugs.python.org (Antti Haapala) Date: Thu, 21 Jul 2016 11:28:17 +0000 Subject: [issue27578] inspect.findsource raises exception with empty __init__.py In-Reply-To: <1469016358.37.0.125453636257.issue27578@psf.upfronthosting.co.za> Message-ID: <1469100497.11.0.0585088029608.issue27578@psf.upfronthosting.co.za> Antti Haapala added the comment: Or perhaps getlines should return [''] for empty regular files? ---------- nosy: +ztane _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 07:30:03 2016 From: report at bugs.python.org (Antti Haapala) Date: Thu, 21 Jul 2016 11:30:03 +0000 Subject: [issue27578] inspect.findsource raises exception with empty __init__.py In-Reply-To: <1469016358.37.0.125453636257.issue27578@psf.upfronthosting.co.za> Message-ID: <1469100603.57.0.359181578326.issue27578@psf.upfronthosting.co.za> Antti Haapala added the comment: It must be noted that `getlines` itself is not documented, and thus there is no backwards-compatibility to preserve really. `getline` returns '' for *any* erroneous line, so it wouldn't affect it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 07:49:14 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 21 Jul 2016 11:49:14 +0000 Subject: [issue26662] configure/Makefile doesn't check if "python" command works, needed to build Objects/typeslots.inc In-Reply-To: <1459247902.98.0.893274525942.issue26662@psf.upfronthosting.co.za> Message-ID: <1469101754.17.0.152697895336.issue26662@psf.upfronthosting.co.za> Xavier de Gaye added the comment: So the error message could be ('$@' being the target): Cannot generate $@, python not found ! To skip re-generation of $@ run 'make touch' or 'make -t $@'. Otherwise, set python in PATH and run configure or run make with PYTHON_FOR_GEN=python. Martin, what do you think ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 07:54:14 2016 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 21 Jul 2016 11:54:14 +0000 Subject: [issue27582] Mispositioned SyntaxError caret for unknown code points Message-ID: <1469102054.52.0.839726574023.issue27582@psf.upfronthosting.co.za> New submission from Nick Coghlan: Reporting by Rustom Mody on python-ideas, the SyntaxError caret is confusingly mispositioned when an invalid Unicode codepoint appears as part of a larger sequence of invalid codepoints and/or valid identifier characters: >>> varname = ?d?a?t?apoint File "", line 1 varname = ?d?a?t?apoint ^ SyntaxError: invalid character in identifier >>> varname = ?d?a?t?apoint.evidence File "", line 1 varname = ?d?a?t?apoint.evidence ^ SyntaxError: invalid character in identifier >>> varname = ?d?a?t?apoint[evidence] File "", line 1 varname = ?d?a?t?apoint[evidence] ^ SyntaxError: invalid character in identifier >>> varname = ?d?a?t?apoint(evidence) File "", line 1 varname = ?d?a?t?apoint(evidence) ^ SyntaxError: invalid character in identifier If the invalid character is a non-identifiers ASCII character, the error message loses the trailing "in identifier" phrase and points to the correct place: >>> varname = $d$a$t$apoint File "", line 1 varname = $d$a$t$apoint ^ SyntaxError: invalid syntax >>> varname = d$a$t$apoint File "", line 1 varname = d$a$t$apoint ^ SyntaxError: invalid syntax >>> varname = ^d$a$t$apoint File "", line 1 varname = ^d$a$t$apoint ^ SyntaxError: invalid syntax >>> varname = !d$a$t$apoint File "", line 1 varname = !d$a$t$apoint ^ SyntaxError: invalid syntax >>> varname = `d$a$t$apoint File "", line 1 varname = `d$a$t$apoint ^ SyntaxError: invalid syntax ---------- messages: 270914 nosy: ncoghlan priority: normal severity: normal stage: needs patch status: open title: Mispositioned SyntaxError caret for unknown code points type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 07:57:50 2016 From: report at bugs.python.org (Chris Angelico) Date: Thu, 21 Jul 2016 11:57:50 +0000 Subject: [issue27582] Mispositioned SyntaxError caret for unknown code points In-Reply-To: <1469102054.52.0.839726574023.issue27582@psf.upfronthosting.co.za> Message-ID: <1469102270.43.0.184940715607.issue27582@psf.upfronthosting.co.za> Changes by Chris Angelico : ---------- nosy: +Rosuav _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 08:03:34 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 21 Jul 2016 12:03:34 +0000 Subject: [issue26662] configure/Makefile doesn't check if "python" command works, needed to build Objects/typeslots.inc In-Reply-To: <1459247902.98.0.893274525942.issue26662@psf.upfronthosting.co.za> Message-ID: <1469102614.15.0.936140149205.issue26662@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Issue 24034 is a duplicate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 08:08:32 2016 From: report at bugs.python.org (Patrick Stewart) Date: Thu, 21 Jul 2016 12:08:32 +0000 Subject: [issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs) In-Reply-To: <1389087474.06.0.281853443562.issue20160@psf.upfronthosting.co.za> Message-ID: <1469102912.39.0.753044289376.issue20160@psf.upfronthosting.co.za> Patrick Stewart added the comment: This is still a problem, and the suggested fix seems to work. There is another error a few lines above where it is allocating 4 bytes for a pointer. I've attached a new patch with both fixes, but without Bob's tests. This issue is a duplicate of 17310 ---------- nosy: +Patrick Stewart Added file: http://bugs.python.org/file43807/ffi_msvc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 08:10:44 2016 From: report at bugs.python.org (Patrick Stewart) Date: Thu, 21 Jul 2016 12:10:44 +0000 Subject: [issue17310] Ctypes callbacks shows problem on Windows Python (64bit) In-Reply-To: <1361980274.18.0.791136497364.issue17310@psf.upfronthosting.co.za> Message-ID: <1469103044.83.0.46093706414.issue17310@psf.upfronthosting.co.za> Patrick Stewart added the comment: I've attached a patch with an extra fix to the duplicated issue 20160 http://bugs.python.org/issue20160 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 08:54:13 2016 From: report at bugs.python.org (rk) Date: Thu, 21 Jul 2016 12:54:13 +0000 Subject: [issue27583] configparser: modifying default_section at runtime Message-ID: <1469105653.63.0.572086425799.issue27583@psf.upfronthosting.co.za> New submission from rk: Modifying "default_section" in the configparser at runtime does not behave as described. The documentation says about default_section: When default_section is given, it specifies the name for the special section holding default values for other sections and interpolation purposes (normally named "DEFAULT"). This value can be retrieved and changed on runtime using the default_section instance attribute. [https://docs.python.org/3/library/configparser.html] So, if I modify default_section at runtime, the default values for other sections should then come from the new default_section. But this is not the case. Instead, the default-values still come from self._default, which was set by self._read. So, this is either a bug in the library or a bug in the documentation. I've attached a testcase. ---------- components: Library (Lib) files: bug_configparser_default_section.py messages: 270918 nosy: rk priority: normal severity: normal status: open title: configparser: modifying default_section at runtime 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/file43808/bug_configparser_default_section.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 09:08:43 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 21 Jul 2016 13:08:43 +0000 Subject: [issue16255] subrocess.Popen needs /bin/sh but Android only has /system/bin/sh In-Reply-To: <1350421202.49.0.905467284446.issue16255@psf.upfronthosting.co.za> Message-ID: <1469106523.43.0.96776663114.issue16255@psf.upfronthosting.co.za> Xavier de Gaye added the comment: New patch that does not call sysconfig.get_config_var() on platforms that have '/bin/sh'. ---------- Added file: http://bugs.python.org/file43809/unix_shell_16255_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 09:24:17 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 21 Jul 2016 13:24:17 +0000 Subject: [issue26852] android: add a COMPILEALL_FLAGS Makefile variable In-Reply-To: <1461674611.23.0.732409522866.issue26852@psf.upfronthosting.co.za> Message-ID: <1469107457.34.0.567505887165.issue26852@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > The python '-E' option was needed on 3.4 when this patch was first implemented and is not needed anymore See msg 269359 in issue 22724. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 09:26:46 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 21 Jul 2016 13:26:46 +0000 Subject: [issue27582] Mispositioned SyntaxError caret for unknown code points In-Reply-To: <1469102054.52.0.839726574023.issue27582@psf.upfronthosting.co.za> Message-ID: <1469107606.29.0.5348912713.issue27582@psf.upfronthosting.co.za> Berker Peksag added the comment: This looks like a duplicate of issue 2382. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 09:28:41 2016 From: report at bugs.python.org (Chris Angelico) Date: Thu, 21 Jul 2016 13:28:41 +0000 Subject: [issue27582] Mispositioned SyntaxError caret for unknown code points In-Reply-To: <1469102054.52.0.839726574023.issue27582@psf.upfronthosting.co.za> Message-ID: <1469107721.84.0.394649961699.issue27582@psf.upfronthosting.co.za> Chris Angelico added the comment: The question was raised that there might be a problem with (UTF-8) bytes vs characters, but that's definitely not it - pythonrun.c:1362 UTF-8-decodes the line of source and then gets its character length to use as the new offset. So I don't think this is a duplicate of 2382. (Side point: There appears to be quite a bit of complexity inside the CPython parser to cope with the fact that it does everything in UTF-8 bytes rather than simply decoding to text and lexing that. I presume that's for the sake of efficiency - that it'd be too slow to work through PyUnicode everywhere?) Am looking into the rest. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 09:31:21 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 21 Jul 2016 13:31:21 +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: <1469107881.75.0.727118288782.issue26859@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- stage: test needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 09:40:57 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 21 Jul 2016 13:40:57 +0000 Subject: [issue27580] CSV Null Byte Error In-Reply-To: <1469077368.13.0.160030895608.issue27580@psf.upfronthosting.co.za> Message-ID: <1469108457.81.0.31172539598.issue27580@psf.upfronthosting.co.za> R. David Murray added the comment: By "discussed before" I presume you are referring to issue 1599055. It is true that have been changes since then in Python's handling of null bytes. Perhaps it is indeed time to revisit this. I'll leave that to the experts...this can be closed as a duplicate of issue 1599055 if I'm wrong about things having possibly changed in the interim. ---------- nosy: +r.david.murray, serhiy.storchaka, skip.montanaro _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 09:43:26 2016 From: report at bugs.python.org (Marco Paolini) Date: Thu, 21 Jul 2016 13:43:26 +0000 Subject: [issue26081] Implement asyncio Future in C to improve performance In-Reply-To: <1452533022.97.0.443242974791.issue26081@psf.upfronthosting.co.za> Message-ID: <1469108606.43.0.134316337704.issue26081@psf.upfronthosting.co.za> Marco Paolini added the comment: THe guys developing uvloop say their implementation is already quite fast [1]. Is it worth integrating it? [1] https://github.com/MagicStack/uvloop ---------- nosy: +mpaolini _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 09:44:17 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 21 Jul 2016 13:44:17 +0000 Subject: [issue27578] inspect.findsource raises exception with empty __init__.py In-Reply-To: <1469016358.37.0.125453636257.issue27578@psf.upfronthosting.co.za> Message-ID: <1469108657.7.0.683487797296.issue27578@psf.upfronthosting.co.za> R. David Murray added the comment: I think someone should propose a patch with tests and we'll evaluate it. We prefer to retain backward compatibility even on undocumented interfaces, if possible, but yes they are more open to change (though only in a feature release, in general). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 09:47:57 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 21 Jul 2016 13:47:57 +0000 Subject: [issue27583] configparser: modifying default_section at runtime In-Reply-To: <1469105653.63.0.572086425799.issue27583@psf.upfronthosting.co.za> Message-ID: <1469108877.31.0.863077973615.issue27583@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +lukasz.langa versions: -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 10:12:34 2016 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 21 Jul 2016 14:12:34 +0000 Subject: [issue27580] CSV Null Byte Error In-Reply-To: <1469077368.13.0.160030895608.issue27580@psf.upfronthosting.co.za> Message-ID: <1469110354.64.0.112183759271.issue27580@psf.upfronthosting.co.za> Skip Montanaro added the comment: Beyond whether or not the csv module can handle NUL bytes, you might figure out if Excel will. Since the CSV format isn't some sort of "standard", its operational definition has always been what Excel will produce or consume. I don't have Excel (not a Windows guy), but I do have Gnumeric and LibreOffice. I constructed a simple CSV file by hand which contains several NUL bytes to see what they would do. Gnumeric pops up a dialog and converts them to spaces (and then, oddly enough, doesn't think the file has been modified). LibreOffice didn't complain while loading the file, but when I saved it, it silently deleted the NULs. I've attached the file should anyone like to experiment with other spreadsheets. ---------- Added file: http://bugs.python.org/file43810/nul.csv _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 10:19:04 2016 From: report at bugs.python.org (Chris Angelico) Date: Thu, 21 Jul 2016 14:19:04 +0000 Subject: [issue27582] Mispositioned SyntaxError caret for unknown code points In-Reply-To: <1469102054.52.0.839726574023.issue27582@psf.upfronthosting.co.za> Message-ID: <1469110744.57.0.181920176875.issue27582@psf.upfronthosting.co.za> Chris Angelico added the comment: Actually pinpointing the invalid character may be impractical, as there are two boolean situations: either a UnicodeDecodeError (because you had an invalid UTF-8 stream), or PyUnicode_IsIdentifier returns false. Either way, it applies to the whole identifier. So there are a few possibilities, corresponding to the patches I'm attaching. 1) Change the way this one specific error is handled, in tokenizer.c verify_identifier(). If it finds an error, adjust tok->cur to point to the beginning of it. No new failures in test suite. 2) As above, but also change tok->inp, because of this comment in tokenizer.h:31 /* NB If done != E_OK, cur must be == inp!!! */ which I have no idea about the meaning of. This results in truncated error messages, but suggests that method 1 might be breaking an invariant that results in breakage elsewhere. If there are, though, they're not exercised by 'make test', which itself may be a problem. No new test failures. 3) Change the handling of ALL parser errors, in parsetok.c parsetok(), so now they all point to tok->start. Octal literals with 8s or 9s in them now get the caret pointing to the invalid digit, rather than the end of the literal. Unterminated strings point to the opening quote. And some forms of IndentationError now segfault Python. Test suite fails (unsurprisingly). 4) In response to the above segfault, hack it back to the old way of doing things if there's no tok->start. Maybe the condition should be done differently? No new failures in the test suite. I'd ideally like to use the technique from method 3 (either as patch 4 or with some other guard condition). Failing that, can anyone explain the "NB" above, and what ought to be done to comply with it? ---------- keywords: +patch Added file: http://bugs.python.org/file43811/method1-change-cur.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 10:19:14 2016 From: report at bugs.python.org (Chris Angelico) Date: Thu, 21 Jul 2016 14:19:14 +0000 Subject: [issue27582] Mispositioned SyntaxError caret for unknown code points In-Reply-To: <1469102054.52.0.839726574023.issue27582@psf.upfronthosting.co.za> Message-ID: <1469110754.85.0.348376115564.issue27582@psf.upfronthosting.co.za> Changes by Chris Angelico : Added file: http://bugs.python.org/file43812/method2-change-cur-and-inp.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 10:19:20 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 Jul 2016 14:19:20 +0000 Subject: [issue26081] Implement asyncio Future in C to improve performance In-Reply-To: <1469108606.43.0.134316337704.issue26081@psf.upfronthosting.co.za> Message-ID: Yury Selivanov added the comment: Yes. Most people will use vanilla asyncio anyways. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 10:19:22 2016 From: report at bugs.python.org (Chris Angelico) Date: Thu, 21 Jul 2016 14:19:22 +0000 Subject: [issue27582] Mispositioned SyntaxError caret for unknown code points In-Reply-To: <1469102054.52.0.839726574023.issue27582@psf.upfronthosting.co.za> Message-ID: <1469110762.91.0.884823422512.issue27582@psf.upfronthosting.co.za> Changes by Chris Angelico : Added file: http://bugs.python.org/file43813/method3-change-all-errors.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 10:19:36 2016 From: report at bugs.python.org (Chris Angelico) Date: Thu, 21 Jul 2016 14:19:36 +0000 Subject: [issue27582] Mispositioned SyntaxError caret for unknown code points In-Reply-To: <1469102054.52.0.839726574023.issue27582@psf.upfronthosting.co.za> Message-ID: <1469110776.03.0.22785722891.issue27582@psf.upfronthosting.co.za> Changes by Chris Angelico : Added file: http://bugs.python.org/file43814/method4-change-all-errors-if-possible.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 10:22:41 2016 From: report at bugs.python.org (Chris Angelico) Date: Thu, 21 Jul 2016 14:22:41 +0000 Subject: [issue27582] Mispositioned SyntaxError caret for unknown code points In-Reply-To: <1469102054.52.0.839726574023.issue27582@psf.upfronthosting.co.za> Message-ID: <1469110961.22.0.0620545452771.issue27582@psf.upfronthosting.co.za> Chris Angelico added the comment: BTW, here's how a session looks using method 4's change: >>> varname = asdf?d?a?t?apoint File "", line 1 varname = asdf?d?a?t?apoint ^ SyntaxError: invalid character in identifier >>> varname = asdf?d?a?t?apoint.evidence File "", line 1 varname = asdf?d?a?t?apoint.evidence ^ SyntaxError: invalid character in identifier >>> varname = $d$a$t$apoint File "", line 1 varname = $d$a$t$apoint ^ SyntaxError: invalid syntax >>> varname = asdf$d$a$t$apoint File "", line 1 varname = asdf$d$a$t$apoint ^ SyntaxError: invalid syntax >>> varname = 0o1234987654 + 123 File "", line 1 varname = 0o1234987654 + 123 ^ SyntaxError: invalid syntax >>> varname = "asdf" + "qwer File "", line 1 varname = "asdf" + "qwer ^ SyntaxError: EOL while scanning string literal ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 10:31:13 2016 From: report at bugs.python.org (rk) Date: Thu, 21 Jul 2016 14:31:13 +0000 Subject: [issue27583] configparser: modifying default_section at runtime In-Reply-To: <1469105653.63.0.572086425799.issue27583@psf.upfronthosting.co.za> Message-ID: <1469111473.96.0.0502608974182.issue27583@psf.upfronthosting.co.za> rk added the comment: Verified/tested with Python 2.7.9, 3.2.6, 3.3.6, 3.4.2, 3.5.1. The bug exists in all versions, so I've added 3.2, 3.3, 3.4 again. I've also attached an updated testcase, which now works in both Python 2 and Python 3. ---------- versions: +Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file43815/bug_configparser_default_section.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 10:33:36 2016 From: report at bugs.python.org (rk) Date: Thu, 21 Jul 2016 14:33:36 +0000 Subject: [issue27583] configparser: modifying default_section at runtime In-Reply-To: <1469105653.63.0.572086425799.issue27583@psf.upfronthosting.co.za> Message-ID: <1469111616.75.0.947696925665.issue27583@psf.upfronthosting.co.za> rk added the comment: (removed Python 2.7, since default_section was not supported there) ---------- versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 10:33:54 2016 From: report at bugs.python.org (rk) Date: Thu, 21 Jul 2016 14:33:54 +0000 Subject: [issue27583] configparser: modifying default_section at runtime In-Reply-To: <1469105653.63.0.572086425799.issue27583@psf.upfronthosting.co.za> Message-ID: <1469111634.69.0.114943781857.issue27583@psf.upfronthosting.co.za> Changes by rk : Removed file: http://bugs.python.org/file43815/bug_configparser_default_section.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 10:52:17 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 21 Jul 2016 14:52:17 +0000 Subject: [issue27583] configparser: modifying default_section at runtime In-Reply-To: <1469105653.63.0.572086425799.issue27583@psf.upfronthosting.co.za> Message-ID: <1469112737.0.0.386288836744.issue27583@psf.upfronthosting.co.za> R. David Murray added the comment: We use the versions field to indicate which versions it might get fixed in. Since this is not a security issue, that would be 3.5 and 3.6, if it doesn't affect 2.7. If we decide to make the code match the docs, it will probably only get fixed in 3.6, since it is a behavior change. ---------- nosy: +r.david.murray versions: -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 11:06:14 2016 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 21 Jul 2016 15:06:14 +0000 Subject: [issue27582] Mispositioned SyntaxError caret for unknown code points In-Reply-To: <1469102054.52.0.839726574023.issue27582@psf.upfronthosting.co.za> Message-ID: <1469113574.75.0.991325182412.issue27582@psf.upfronthosting.co.za> Nick Coghlan added the comment: Looking at issue 2382, I agree that's a different problem (I'm seeing the current misbehaviour even though everything is consistently encoded as UTF-8) The main case we're interested in here is the PyUnicode_IsIdentifier one, so if we wanted to do better than "start or end of the token", we could introduce a new internal "_PyUnicode_FindNonIdentifier" that reported the position of the first non-identifier character (or -1 if it's a valid identifier). Unfortunately, I'm not at all familiar with parsetok.c myself (my own work with the code generator has been from the AST on), so I don't have a ready answer for your other questions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 11:36:20 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 21 Jul 2016 15:36:20 +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: <20160721153617.6816.71389.99CCA985@psf.io> Roundup Robot added the comment: New changeset 5a19fbb8501f by Zachary Ware in branch 'default': Issue #23951: Add missing icon https://hg.python.org/devguide/rev/5a19fbb8501f New changeset 0f642c1ba901 by Zachary Ware in branch 'default': Issue #23951: Clean up rstlint makefile integration https://hg.python.org/devguide/rev/0f642c1ba901 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 11:36:30 2016 From: report at bugs.python.org (Cathy Avery) Date: Thu, 21 Jul 2016 15:36:30 +0000 Subject: [issue27584] New addition of vSockets to the python socket module Message-ID: <1469115390.74.0.838831983223.issue27584@psf.upfronthosting.co.za> New submission from Cathy Avery: I have added AF_VSOCK support to python's 3.6 socket module ( socketmodule.c socketmodule.h cloned from https://hg.python.org/cpython ). The implementation is very similar to AF_NETLINK. AF_VSOCK requires the VMware-specific VMCI transport which is currently upstream or the virtio-vsock drivers developed by Stefan Hajnoczi at Red Hat. The virtio-vsock drivers are not upstream yet but more information with source and build instructions can be found at http://qemu-project.org/Features/VirtioVsock. More information on vSocket programming can be found at https://pubs.vmware.com/vsphere-60/topic/com.vmware.ICbase/PDF/ws9_esx60_vmci_sockets.pdf The VMCI transport supports SOCK_DGRAM and SOCK_STREAM on both Linux and Windows. Virtio-vsock currently supports SOCK_STREAM only on Linux. My python addition supports SOCK_STREAM and SOCK_DGRAM calls on Linux only. I have tested my implementation on both driver sets on Linux. Attached is a diff file so you can see which files I've modified. These include a new configure.ac. I have already tested the new file generation by running autoreconf. Also included in the patch is an updated socket.rst file however I could not get the final html page to be double spaced. ---------- components: Library (Lib) files: vsocket.patch hgrepos: 349 keywords: patch messages: 270935 nosy: Cathy Avery, gregory.p.smith priority: normal severity: normal status: open title: New addition of vSockets to the python socket module type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43816/vsocket.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 11:54:56 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 21 Jul 2016 15:54:56 +0000 Subject: [issue26944] android: test_posix fails In-Reply-To: <1462348873.26.0.373017977506.issue26944@psf.upfronthosting.co.za> Message-ID: <1469116496.83.0.661657356011.issue26944@psf.upfronthosting.co.za> Xavier de Gaye added the comment: New patch with cosmetic changes. ---------- assignee: -> xdegaye stage: -> patch review Added file: http://bugs.python.org/file43817/test_getgroups_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 11:56:36 2016 From: report at bugs.python.org (Larry Hastings) Date: Thu, 21 Jul 2016 15:56:36 +0000 Subject: [issue26944] android: test_posix fails In-Reply-To: <1462348873.26.0.373017977506.issue26944@psf.upfronthosting.co.za> Message-ID: <1469116595.99.0.316206766482.issue26944@psf.upfronthosting.co.za> Larry Hastings added the comment: Is there a plan to make Android a supported platform in 3.6? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 11:58:46 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 21 Jul 2016 15:58:46 +0000 Subject: [issue23951] Update devguide style to use a similar theme as Docs In-Reply-To: <20160721153617.6816.71389.99CCA985@psf.io> Message-ID: STINNER Victor added the comment: Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 12:14:52 2016 From: report at bugs.python.org (Bobby Ocean) Date: Thu, 21 Jul 2016 16:14:52 +0000 Subject: [issue27580] CSV Null Byte Error In-Reply-To: <1469077368.13.0.160030895608.issue27580@psf.upfronthosting.co.za> Message-ID: <1469117692.62.0.118168158295.issue27580@psf.upfronthosting.co.za> Bobby Ocean added the comment: @ Skip Montanaro, Actually, CSV has nothing to do with excel. Excel is a gui that processes CSV like many other programs. CSV stands for comma seperated values and is basic standard for data.https://en.m.wikipedia.org/wiki/Comma-separated_values As far as I know, many programs handle NULL bytes fine (either as a empty atring or a # or something else). In any case, it really should be irrelevent how some particular programs handle a CSV file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 12:21:12 2016 From: report at bugs.python.org (Brett Cannon) Date: Thu, 21 Jul 2016 16:21:12 +0000 Subject: [issue27562] Import error encodings (Windows xp compatibility) In-Reply-To: <1468849701.41.0.980015051967.issue27562@psf.upfronthosting.co.za> Message-ID: <1469118072.18.0.555642791849.issue27562@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: -brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 12:33:21 2016 From: report at bugs.python.org (Chris Angelico) Date: Thu, 21 Jul 2016 16:33:21 +0000 Subject: [issue27582] Mispositioned SyntaxError caret for unknown code points In-Reply-To: <1469102054.52.0.839726574023.issue27582@psf.upfronthosting.co.za> Message-ID: <1469118801.77.0.00941611299979.issue27582@psf.upfronthosting.co.za> Chris Angelico added the comment: Hmm, that'd be curious. The code to do that is actually pretty simple - see attached patch - but actually using that to affect error messages is a bit harder. Is it safe to mess with tok->start? ---------- Added file: http://bugs.python.org/file43818/where-did-that-error-come-from.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 12:35:15 2016 From: report at bugs.python.org (Chris Angelico) Date: Thu, 21 Jul 2016 16:35:15 +0000 Subject: [issue27582] Mispositioned SyntaxError caret for unknown code points In-Reply-To: <1469102054.52.0.839726574023.issue27582@psf.upfronthosting.co.za> Message-ID: <1469118915.76.0.640661212256.issue27582@psf.upfronthosting.co.za> Chris Angelico added the comment: Attached is a combined patch that has the new private function for IsIdentifier, method 4's error handling change, and a bit of glue in the middle to make use of it. The result is a passing test suite (bar test_site which was already failing on my system) and a caret that points to the errant Unicode character, or the beginning of the identifier if it's a decode problem. ---------- Added file: http://bugs.python.org/file43819/combined.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 13:03:22 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 21 Jul 2016 17:03:22 +0000 Subject: [issue26865] Meta-issue: support of the android platform In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za> Message-ID: <1469120602.58.0.110763483305.issue26865@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Larry asked in msg 270937: > Is there a plan to make Android a supported platform in 3.6? This is the list of Android related issues that will modify the standard library and core Python when fixed: issue 16255: subrocess.Popen needs /bin/sh but Android only has /system/bin/sh [1] issue 26851: android compilation and link flags issue 22724: byte-compile fails for cross-builds issue 23968: rename the platform directory from plat-$(MACHDEP) to plat-$(PLATFORM_TRIPLET) issue 26919: android: test_cmd_line fails issue 26920: android: test_sys fails issue 26928: _bootlocale imports locale at startup on Android, causing test_site to fail issue 26937: android: test_tarfile fails issue 26934: android: test_faulthandler fails issue 26929: android: test_strptime fails [2] issue 26942: android: test_ctypes crashes on armv7 All the other issues listed here in this meta-issue are changes to the test suite (mostly skipping some tests). A buildbot must also be setup for the Android emulators and maybe also for an Android device. That means installing the Android sdk and ndk and a build system on the buildbot. [1] Issue 26851 is an enhancement. [2] The root cause in issue 26942 is unknown yet. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 13:05:38 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 21 Jul 2016 17:05:38 +0000 Subject: [issue26944] android: test_posix fails In-Reply-To: <1462348873.26.0.373017977506.issue26944@psf.upfronthosting.co.za> Message-ID: <1469120738.32.0.497712397314.issue26944@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > Is there a plan to make Android a supported platform in 3.6? Answer in the Android meta-issue at msg 270942. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 13:06:41 2016 From: report at bugs.python.org (sss) Date: Thu, 21 Jul 2016 17:06:41 +0000 Subject: [issue27585] asyncio.Lock deadlock after cancellation Message-ID: <1469120801.4.0.62510822161.issue27585@psf.upfronthosting.co.za> New submission from sss: The lock.py file prints DEADLOCK HERE _locked: False _waiters: deque([]) I think the problem is that acquire() will block because of the cancelled future in _waiters, but release() has already ran so no one will wake it up. ---------- components: asyncio files: lock.py messages: 270944 nosy: gvanrossum, haypo, sss, yselivanov priority: normal severity: normal status: open title: asyncio.Lock deadlock after cancellation versions: Python 3.5 Added file: http://bugs.python.org/file43820/lock.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 13:11:48 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 21 Jul 2016 17:11:48 +0000 Subject: [issue27580] CSV Null Byte Error In-Reply-To: <1469077368.13.0.160030895608.issue27580@psf.upfronthosting.co.za> Message-ID: <1469121108.78.0.483958760943.issue27580@psf.upfronthosting.co.za> R. David Murray added the comment: Bobby: Skip is one of the authors of the csv module, and has been maintaining it since it was added to the standard library. He knows whereof he speaks: there is no standard for csv (as noted in the article you link), and all csv parsers that want to be interoperable refer back to Microsoft's implementation when dealing with any quirks. That implementation currently is Excel. That said, your are right that others have adopted the format, and there is an argument to be made that we don't have to *limit* ourselves to what Microsoft supports. Although we probably don't want to be emitting stuff that they don't without being explicit about it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 13:15:04 2016 From: report at bugs.python.org (Stephen J. Turnbull) Date: Thu, 21 Jul 2016 17:15:04 +0000 Subject: [issue27582] Mispositioned SyntaxError caret for unknown code points In-Reply-To: <1469102054.52.0.839726574023.issue27582@psf.upfronthosting.co.za> Message-ID: <1469121304.17.0.528382017648.issue27582@psf.upfronthosting.co.za> Stephen J. Turnbull added the comment: I still think the easiest thing to do would be to make all non-ASCII characters instances of "invalid_character_token", self-delimiting in the same way that operators are. That would automatically point to exactly the right place in the token stream, and requires zero changes to the error handling code. I don't have time to look at the code, but I suspect that you could handle this exactly the same way that ? and $ are handled, and maybe even use the same token type. ---------- nosy: +sjt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 13:26:37 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 21 Jul 2016 17:26:37 +0000 Subject: [issue27585] asyncio.Lock deadlock after cancellation In-Reply-To: <1469120801.4.0.62510822161.issue27585@psf.upfronthosting.co.za> Message-ID: <1469121997.53.0.401645863928.issue27585@psf.upfronthosting.co.za> R. David Murray added the comment: If you give the loop a chance to run (an await asyncio.sleep(0)) before doing the acquire) it does not deadlock. I don't understand enough of the asyncio internals to know if this is expected or a bug. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 13:27:09 2016 From: report at bugs.python.org (Bobby Ocean) Date: Thu, 21 Jul 2016 17:27:09 +0000 Subject: [issue27580] CSV Null Byte Error In-Reply-To: <1469077368.13.0.160030895608.issue27580@psf.upfronthosting.co.za> Message-ID: <1469122029.83.0.687352499889.issue27580@psf.upfronthosting.co.za> Bobby Ocean added the comment: I am sorry I must have mis-read the history part of that article. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 13:41:13 2016 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 21 Jul 2016 17:41:13 +0000 Subject: [issue1521950] shlex.split() does not tokenize like the shell Message-ID: <1469122873.07.0.760031627745.issue1521950@psf.upfronthosting.co.za> Vinay Sajip added the comment: This has been knocking around since 3.3, but never got enough attention to make it in. Barring objections from anyone, I'd like to commit this patch once I check that it applies cleanly against 3.6, before we get into 3.6 beta. ---------- versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 13:49:17 2016 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 21 Jul 2016 17:49:17 +0000 Subject: [issue27493] logging module fails with unclear error when supplied a (Posix)Path In-Reply-To: <1468314884.39.0.604549697605.issue27493@psf.upfronthosting.co.za> Message-ID: <1469123357.37.0.503530972328.issue27493@psf.upfronthosting.co.za> Vinay Sajip added the comment: > the answer would be "not at all". Not sure about that. If all logging did were to pass the path to lower levels such as open or abspath, that may be true. However, some handlers do path computations (e.g. the rotating file handlers) and so logging would need to have a minimal awareness of PEP 519 or else call str() on any putative filename passed in, and be completely unaware of it (assuming that str() on a Path would return the same as __fspath__(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 14:11:54 2016 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 21 Jul 2016 18:11:54 +0000 Subject: [issue27580] CSV Null Byte Error In-Reply-To: <1469077368.13.0.160030895608.issue27580@psf.upfronthosting.co.za> Message-ID: <1469124714.57.0.980083634863.issue27580@psf.upfronthosting.co.za> Skip Montanaro added the comment: I wasn't familiar with RFC 4180. (Or, quite possibly, I forgot I used to be familiar with it.) Note that at the bottom of the BNF definition of the file structure is the definition of TEXTDATA: TEXTDATA = %x20-21 / %x23-2B / %x2D-7E That pretty explicitly excludes NUL bytes (%x00 I think). I'd still like someone load my nul.csv file into Excel and report back what it does (or doesn't) do with it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 14:12:36 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 21 Jul 2016 18:12:36 +0000 Subject: [issue1521950] shlex.split() does not tokenize like the shell Message-ID: <1469124756.16.0.50829629693.issue1521950@psf.upfronthosting.co.za> R. David Murray added the comment: No objection from me. I'm not likely to have the time to give it the kind of thorough review I'd *like* to, but I don't think it is really needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 14:13:13 2016 From: report at bugs.python.org (Rob Nester) Date: Thu, 21 Jul 2016 18:13:13 +0000 Subject: [issue27144] concurrent.futures.as_completed() memory inefficiency In-Reply-To: <1464441935.81.0.0559700033116.issue27144@psf.upfronthosting.co.za> Message-ID: <1469124793.85.0.250741090801.issue27144@psf.upfronthosting.co.za> Changes by Rob Nester : ---------- nosy: +rnester _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 14:56:32 2016 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 21 Jul 2016 18:56:32 +0000 Subject: [issue26533] logging.config does not allow disable_existing_loggers=True In-Reply-To: <1457648926.18.0.758256853063.issue26533@psf.upfronthosting.co.za> Message-ID: <1469127392.5.0.203192341836.issue26533@psf.upfronthosting.co.za> Vinay Sajip added the comment: I think this is just a documentation issue. You can send a dictionary suitable for dictConfig() as JSON over the listen() socket. This is supported by 2.7 and 3.2+ - the documentation doesn't mention this, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 15:20:27 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 21 Jul 2016 19:20:27 +0000 Subject: [issue13849] Add tests for NUL checking in certain strs In-Reply-To: <1327370754.29.0.66468771639.issue13849@psf.upfronthosting.co.za> Message-ID: <1469128827.38.0.780315053455.issue13849@psf.upfronthosting.co.za> Berker Peksag added the comment: Attached patch adds tests for common members of Lib/genericpath.py. ---------- keywords: +patch nosy: +berker.peksag stage: needs patch -> patch review versions: +Python 3.6 -Python 3.4 Added file: http://bugs.python.org/file43821/issue13849.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 15:35:07 2016 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 21 Jul 2016 19:35:07 +0000 Subject: [issue27546] Integrate tkinter and asyncio (and async) In-Reply-To: <1468815010.57.0.709565417017.issue27546@psf.upfronthosting.co.za> Message-ID: <1469129707.89.0.887979246688.issue27546@psf.upfronthosting.co.za> Guido van Rossum added the comment: > Who actually wrote it [crawl.py], that would understand it? I wrote it, and I can probably still recover my understanding of it. Basically you say "python3 crawl.py xkcd.com -q" and it crawls the XKCD.com website -- that takes about 4 seconds on my machine, fetching 1764 urls. The -q is to make it more quiet while it's working -- but somehow it doesn't suppress the final report, which includes a full list of all crawled URLs -- this could use some surgery to pass the log level into Fetcher.report(). A test site that has only one URL is www.pythonlabs.com. I ran the test program (tkaloop.py) and it appears to work, with one caveat: updates in response to Tk events (specifically clicking the button that toggles the color of the "Hello" label) seem to take an effect only once the self.root.update() call in your run_forever() is made, which appears to be only once per "interval" (i.e. 1 second). Hopefully future development will make it so that when a Tk event happens, *somehow* the asyncio selector gets woken up. (PS. Please don't abbreviate asyncio to aio. It makes your code harder to read for asyncio veterans. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 17:03:42 2016 From: report at bugs.python.org (Bruce Eckel) Date: Thu, 21 Jul 2016 21:03:42 +0000 Subject: [issue27586] Is this a regular expression library bug? Message-ID: <1469135022.02.0.0194014811902.issue27586@psf.upfronthosting.co.za> New submission from Bruce Eckel: This looks suspicious to me, like it could be a library bug, but before chasing it down I was hoping someone might be able to tell me whether I might be on to something: Traceback (most recent call last): File "update_extracted_example_output.py", line 22, in new_javatext = find_output.sub(new_output, javatext) File "C:\Python35\lib\re.py", line 325, in _subx template = _compile_repl(template, pattern) File "C:\Python35\lib\re.py", line 312, in _compile_repl p = sre_parse.parse_template(repl, pattern) File "C:\Python35\lib\sre_parse.py", line 872, in parse_template raise s.error("missing <") sre_constants.error: missing < at position 100 (line 4, column 41) ---------- components: Library (Lib) messages: 270956 nosy: Bruce Eckel priority: normal severity: normal status: open title: Is this a regular expression library bug? type: compile error versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 17:07:32 2016 From: report at bugs.python.org (Tim Peters) Date: Thu, 21 Jul 2016 21:07:32 +0000 Subject: [issue27586] Is this a regular expression library bug? In-Reply-To: <1469135022.02.0.0194014811902.issue27586@psf.upfronthosting.co.za> Message-ID: <1469135252.12.0.78568285495.issue27586@psf.upfronthosting.co.za> Tim Peters added the comment: If you don't show us the regular expression, it's going to be darned hard to guess what it is ;-) ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 17:09:43 2016 From: report at bugs.python.org (Bruce Eckel) Date: Thu, 21 Jul 2016 21:09:43 +0000 Subject: [issue27586] Is this a regular expression library bug? In-Reply-To: <1469135022.02.0.0194014811902.issue27586@psf.upfronthosting.co.za> Message-ID: <1469135383.97.0.714850033855.issue27586@psf.upfronthosting.co.za> Bruce Eckel added the comment: Sorry, I thought maybe the error message would be indicative of something. Here's the re: find_output = re.compile(r"/\* (Output:.*)\*/", re.DOTALL) Here's the program: #! py -3 # Requires Python 3.5 # Updates generated output into extracted Java programs in "On Java 8" from pathlib import Path import re import pprint import sys if __name__ == '__main__': find_output = re.compile(r"/\* (Output:.*)\*/", re.DOTALL) for outfile in Path(".").rglob("*.p1"): print(str(outfile)) javafile = outfile.with_suffix(".java") if not javafile.exists(): print(str(outfile) + " has no javafile") sys.exit(1) javatext = javafile.read_text() if "/* Output:" not in javatext: print(str(javafile) + " has no /* Output:") sys.exit(1) new_output = outfile.read_text() new_javatext = find_output.sub(new_output, javatext) javafile.write_text(new_javatext) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 17:16:30 2016 From: report at bugs.python.org (Bobby Ocean) Date: Thu, 21 Jul 2016 21:16:30 +0000 Subject: [issue27580] CSV Null Byte Error In-Reply-To: <1469077368.13.0.160030895608.issue27580@psf.upfronthosting.co.za> Message-ID: <1469135790.96.0.578926078342.issue27580@psf.upfronthosting.co.za> Bobby Ocean added the comment: I attempted to open the file in excel; raised no errors. In any case (regardless of Microsoft-concerns), I am glad to see a discussion started and possibly some concern that an update might be useful to the community (it would certainly cut down on the number of stack-exchange posts about this very topic). I certainly would put my vote to have csv handle the NULL byte, in the same way as python does natively. Thanks for you time. Oh, and since you are one of the author's, thanks for writing/working on the csv module, VERY USEFUL. :-) ---------- Added file: http://bugs.python.org/file43822/Opening_CSV.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 17:30:17 2016 From: report at bugs.python.org (Tim Peters) Date: Thu, 21 Jul 2016 21:30:17 +0000 Subject: [issue27586] Is this a regular expression library bug? In-Reply-To: <1469135022.02.0.0194014811902.issue27586@psf.upfronthosting.co.za> Message-ID: <1469136617.29.0.313503728451.issue27586@psf.upfronthosting.co.za> Tim Peters added the comment: Well, some backslash escapes are processed in the "replacement" argument to `.sub()`. If your replacement text contains a substring of the form \g not immediately followed by < that will raise the exception you're seeing. The parser is expecting to see a "matched group" reference after "\g", like \g<1> \g So it depends on the value of your `new_output`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 17:51:43 2016 From: report at bugs.python.org (Bruce Eckel) Date: Thu, 21 Jul 2016 21:51:43 +0000 Subject: [issue27586] Is this a regular expression library bug? In-Reply-To: <1469135022.02.0.0194014811902.issue27586@psf.upfronthosting.co.za> Message-ID: <1469137903.29.0.675428013384.issue27586@psf.upfronthosting.co.za> Bruce Eckel added the comment: Urk. There was exactly a \g in the input. Sorry for the bother. ---------- resolution: -> not a bug _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 17:56:32 2016 From: report at bugs.python.org (Tim Peters) Date: Thu, 21 Jul 2016 21:56:32 +0000 Subject: [issue27586] Is this a regular expression library bug? In-Reply-To: <1469135022.02.0.0194014811902.issue27586@psf.upfronthosting.co.za> Message-ID: <1469138192.48.0.795421534423.issue27586@psf.upfronthosting.co.za> Changes by Tim Peters : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 18:00:49 2016 From: report at bugs.python.org (Grazfather x) Date: Thu, 21 Jul 2016 22:00:49 +0000 Subject: [issue26533] logging.config does not allow disable_existing_loggers=True In-Reply-To: <1457648926.18.0.758256853063.issue26533@psf.upfronthosting.co.za> Message-ID: <1469138449.75.0.852475879662.issue26533@psf.upfronthosting.co.za> Grazfather x added the comment: That's not really what this is about. This is about setting up the listener so that by default that setting is used. In logging/config.py: ```python def listen(port=DEFAULT_LOGGING_CONFIG_PORT, verify=None): ... try: fileConfig(file) except Exception: traceback.print_exc() ... def fileConfig(fname, defaults=None, disable_existing_loggers=True): ... ``` ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 18:12:37 2016 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 21 Jul 2016 22:12:37 +0000 Subject: [issue26533] logging.config does not allow disable_existing_loggers=True In-Reply-To: <1457648926.18.0.758256853063.issue26533@psf.upfronthosting.co.za> Message-ID: <1469139157.77.0.90392418408.issue26533@psf.upfronthosting.co.za> Vinay Sajip added the comment: > That's not really what this is about. As I see it, it's about the ability to configure disabling of existing loggers on reconfiguration via the listener. While it can't be done using fileConfig(), it *can* be done using dictConfig(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 18:12:58 2016 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 21 Jul 2016 22:12:58 +0000 Subject: [issue27580] CSV Null Byte Error In-Reply-To: <1469077368.13.0.160030895608.issue27580@psf.upfronthosting.co.za> Message-ID: <1469139178.55.0.137874839337.issue27580@psf.upfronthosting.co.za> Skip Montanaro added the comment: Thanks. The display you showed looks about like I saw in LibreOffice. If you export it back to another CSV file, does the new file match the original exactly, or does (like LibreOffice) it save a file without NUL bytes? I don't mind having the discussion, but even though we have traditionally treated CSV files as binary files in Python (at least when I was closely involved in the 2.x days), that was mostly so end-of-line sequences weren't corrupted. As others have pointed out, in 2.x Python String objects stored the data as a normal NUL-terminated pointer-to-char for efficiency when interacting with C libraries. C uses NUL as a string terminator, so we couldn't work with embedded NULs. I haven't looked at the 3.x string stuff (I know Unicode is much more intimately involved). If it still maintains that close working relationship with the typical C strings, supporting NUL bytes will be problematic. In cases where the underlying representation isn't quite what I want, I've been able to get away with a file wrapper which suitably mangles the input before passing it up the chain to the csv module. For example, the __next__ method of your file wrapper could delete NULs or replace them with something suitably innocuous, like "\001", or some other non-printable character you are certain won't be in the input. If you want to preserve NULs, reverse the translation during the write(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 18:44:45 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 21 Jul 2016 22:44:45 +0000 Subject: [issue13849] Add tests for NUL checking in certain strs In-Reply-To: <1327370754.29.0.66468771639.issue13849@psf.upfronthosting.co.za> Message-ID: <1469141085.83.0.926372619374.issue13849@psf.upfronthosting.co.za> STINNER Victor added the comment: issue13849.diff: LGTM. If the tests pass on Python 2.7 and 3.5, I think that it's worth to add the tests to these versions as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 18:51:27 2016 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 21 Jul 2016 22:51:27 +0000 Subject: [issue13849] Add tests for NUL checking in certain strs In-Reply-To: <1327370754.29.0.66468771639.issue13849@psf.upfronthosting.co.za> Message-ID: <1469141487.03.0.589018470451.issue13849@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 21:53:34 2016 From: report at bugs.python.org (Matthias Bussonnier) Date: Fri, 22 Jul 2016 01:53:34 +0000 Subject: [issue8406] Make some setup.py paths exclude-able In-Reply-To: <1271301152.77.0.297402624492.issue8406@psf.upfronthosting.co.za> Message-ID: <1469152414.44.0.749171308071.issue8406@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: > We regularly close issues that are 1+ year old on Jupyter/IPython or rescope the issue to be actionable for contribution. Sorry if me doing that on IPython/Jupyter recently have put you (willingc) in a bad position in here, sincere apologies, you are doing a great job. On the Jupyter/IPython repositories we find that too many open issues and/or patch proposals open tend to repel contributors away. So we try to actively clean things up, especially the ones that are old and inactive. It's true that project might have different policies though. I, personally, would prefer some of my patch/issues to be closed with a "Sorry, we don't have time to review that and that's going to be controversial anyway, though we appreciate you doing the effort" than leave them in limbo with no responses. It happen of course that committers overzealously close issue, of course ? we are human after all and make mistakes, whether we have years of experience, or a new contributor who does not know the protocol.? It is always a good time to show the example, and show how we could have improved the process.I don't think that making a mistake should be seen as dramatic as it's often communicated. After all, we have revision control, and we can reopen right ? For example, I think that recently we [IPython/Jupyter] did a better job at reopening and explaining what could have been done better ? and actually do it ? instead of what was not done. But most of the time the closing of languishing issue was the right choice, and the cost/benefit, despite the false positive was worth it. I also think the closing an issue [with or without patch], make the author react if they really do care, often more than that if you just ask for a status update. This author, in general, is often more aware of potential new issues that supersede the closed one and thus can link to it. Again, I know that working on multiple projects can be hard and that practices that differ between project can also be hard to follow, and my recent spring-cleaning might have biased your practices here. Thanks for your hard work both on IPython/Jupyter, here and at on the PSF board, and sorry if it put you into trouble. ---------- nosy: +mbussonn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 22:36:52 2016 From: report at bugs.python.org (Emanuel Barry) Date: Fri, 22 Jul 2016 02:36:52 +0000 Subject: [issue27586] Is this a regular expression library bug? In-Reply-To: <1469135022.02.0.0194014811902.issue27586@psf.upfronthosting.co.za> Message-ID: <1469155012.88.0.864459275677.issue27586@psf.upfronthosting.co.za> Emanuel Barry added the comment: For future reference, if your input can have arbitrary escapes, it might be a good idea to pass it through re.escape; it does proper escaping so that stuff like e.g. \g in your input will get treated as a literal backslash, followed by a literal 'g', and not an escape sequence. ---------- nosy: +ebarry type: compile error -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 23:37:10 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 22 Jul 2016 03:37:10 +0000 Subject: [issue26662] configure/Makefile doesn't check if "python" command works, needed to build Objects/typeslots.inc In-Reply-To: <1459247902.98.0.893274525942.issue26662@psf.upfronthosting.co.za> Message-ID: <1469158630.2.0.0158718436369.issue26662@psf.upfronthosting.co.za> Martin Panter added the comment: I think that error message would be okay. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 23:41:40 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 22 Jul 2016 03:41:40 +0000 Subject: [issue24034] Make fails Objects/typeslots.inc In-Reply-To: <1429764430.06.0.333500600321.issue24034@psf.upfronthosting.co.za> Message-ID: <1469158900.41.0.97044413083.issue24034@psf.upfronthosting.co.za> Martin Panter added the comment: Sorry nobody acted on your patch earlier. This is the same as Issue 26662, which has a more general patch that does the same sort of thing. ---------- nosy: +martin.panter resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 00:45:58 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 22 Jul 2016 04:45: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: <1469162758.79.0.164758567144.issue27130@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a new patch for 2.7 that should avoid the problem with ChecksumBigBufferTestCase. I tested a hacked version of the test, so I am more confident in it now :) ---------- Added file: http://bugs.python.org/file43823/64bit_support_for_zlib_v11-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 02:34:16 2016 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 22 Jul 2016 06:34: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: <1469169256.02.0.786681152612.issue27130@psf.upfronthosting.co.za> Xiang Zhang added the comment: All tests passed now. :) I think it's OK. Also upload the v10 version restore the statement to avoid the crash you mentioned in comments. [1/1] test_zlib test_abcdefghijklmnop (test.test_zlib.ChecksumTestCase) test issue1202 compliance: signed crc32, adler32 in 2.x ... ok test_adler32empty (test.test_zlib.ChecksumTestCase) ... ok test_adler32start (test.test_zlib.ChecksumTestCase) ... ok test_crc32empty (test.test_zlib.ChecksumTestCase) ... ok test_crc32start (test.test_zlib.ChecksumTestCase) ... ok test_negative_crc_iv_input (test.test_zlib.ChecksumTestCase) ... ok test_penguins (test.test_zlib.ChecksumTestCase) ... ok test_same_as_binascii_crc32 (test.test_zlib.ChecksumTestCase) ... ok test_big_buffer (test.test_zlib.ChecksumBigBufferTestCase) ... ok test_badcompressobj (test.test_zlib.ExceptionTestCase) ... ok test_baddecompressobj (test.test_zlib.ExceptionTestCase) ... ok test_badlevel (test.test_zlib.ExceptionTestCase) ... ok test_decompressobj_badflush (test.test_zlib.ExceptionTestCase) ... ok test_overflow (test.test_zlib.ExceptionTestCase) ... ok test_64bit_compress (test.test_zlib.CompressTestCase) ... ok test_big_compress_buffer (test.test_zlib.CompressTestCase) ... ok test_big_decompress_buffer (test.test_zlib.CompressTestCase) ... ok test_custom_bufsize (test.test_zlib.CompressTestCase) ... ok test_incomplete_stream (test.test_zlib.CompressTestCase) ... ok test_large_bufsize (test.test_zlib.CompressTestCase) ... ok test_speech (test.test_zlib.CompressTestCase) ... ok test_speech128 (test.test_zlib.CompressTestCase) ... ok test_64bit_compress (test.test_zlib.CompressObjectTestCase) ... ok test_badcompresscopy (test.test_zlib.CompressObjectTestCase) ... ok test_baddecompresscopy (test.test_zlib.CompressObjectTestCase) ... ok test_big_compress_buffer (test.test_zlib.CompressObjectTestCase) ... ok test_big_decompress_buffer (test.test_zlib.CompressObjectTestCase) ... ok test_clear_unconsumed_tail (test.test_zlib.CompressObjectTestCase) ... ok test_compresscopy (test.test_zlib.CompressObjectTestCase) ... ok test_compressincremental (test.test_zlib.CompressObjectTestCase) ... ok test_compressoptions (test.test_zlib.CompressObjectTestCase) ... ok test_compresspickle (test.test_zlib.CompressObjectTestCase) ... ok test_decompimax (test.test_zlib.CompressObjectTestCase) ... ok test_decompinc (test.test_zlib.CompressObjectTestCase) ... ok test_decompincflush (test.test_zlib.CompressObjectTestCase) ... ok test_decompress_incomplete_stream (test.test_zlib.CompressObjectTestCase) ... ok test_decompress_unused_data (test.test_zlib.CompressObjectTestCase) ... ok test_decompresscopy (test.test_zlib.CompressObjectTestCase) ... ok test_decompressmaxlen (test.test_zlib.CompressObjectTestCase) ... ok test_decompressmaxlenflush (test.test_zlib.CompressObjectTestCase) ... ok test_decompresspickle (test.test_zlib.CompressObjectTestCase) ... ok test_empty_flush (test.test_zlib.CompressObjectTestCase) ... ok test_flush_custom_length (test.test_zlib.CompressObjectTestCase) ... ok test_flush_large_length (test.test_zlib.CompressObjectTestCase) ... ok test_flush_with_freed_input (test.test_zlib.CompressObjectTestCase) ... ok test_flushes (test.test_zlib.CompressObjectTestCase) ... ok test_large_unconsumed_tail (test.test_zlib.CompressObjectTestCase) ... ok test_large_unused_data (test.test_zlib.CompressObjectTestCase) ... ok test_maxlen_custom (test.test_zlib.CompressObjectTestCase) ... ok test_maxlen_large (test.test_zlib.CompressObjectTestCase) ... ok test_maxlenmisc (test.test_zlib.CompressObjectTestCase) ... ok test_odd_flush (test.test_zlib.CompressObjectTestCase) ... ok test_pair (test.test_zlib.CompressObjectTestCase) ... ok test_wbits (test.test_zlib.CompressObjectTestCase) ... ok ---------------------------------------------------------------------- Ran 54 tests in 324.004s OK 1 test OK. ---------- Added file: http://bugs.python.org/file43824/64bit_support_for_zlib_v10.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 02:55:09 2016 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 22 Jul 2016 06:55:09 +0000 Subject: [issue27572] Support bytes-like objects when base is given to int() In-Reply-To: <1468918576.73.0.596747914515.issue27572@psf.upfronthosting.co.za> Message-ID: <1469170509.43.0.574553378752.issue27572@psf.upfronthosting.co.za> Xiang Zhang added the comment: Thanks for the reviews Martin. Change the doc and test. ---------- Added file: http://bugs.python.org/file43825/bytes_like_support_to_int_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 03:17:19 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 22 Jul 2016 07:17:19 +0000 Subject: [issue27572] Support bytes-like objects when base is given to int() In-Reply-To: <1468918576.73.0.596747914515.issue27572@psf.upfronthosting.co.za> Message-ID: <1469171839.37.0.208972079329.issue27572@psf.upfronthosting.co.za> Martin Panter added the comment: I am torn on this. On one hand, it would be good to be consistent with the single-argument behaviour. But on the other hand, APIs normally accept arbitrary bytes-like objects (like memoryview) to minimise unnecessary copying, whereas this case has to make a copy to append a null terminator. Perhaps another option is to deprecate int(byteslike) support instead, in favour of explicitly making a copy using bytes(byteslike). Similarly for float, compile, eval, exec, which also do copying thanks to Issue 24802. But PyNumber_Long() has called PyObject_AsCharBuffer() (predecessor of Python 3?s bytes-like objects) since 1.5.2 (revision 74b7213fb609). So this option would probably need wider discussion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 03:22:12 2016 From: report at bugs.python.org (Pavel Belikov) Date: Fri, 22 Jul 2016 07:22:12 +0000 Subject: [issue27587] Issues, reported by PVS-Studio static analyzer Message-ID: <1469172132.31.0.293406285451.issue27587@psf.upfronthosting.co.za> New submission from Pavel Belikov: To demonstrate the capabilities of our analyzer, we regularly perform analysis of open source projects. We had recently checked the CPython project. Here is the link to the article about it: http://www.viva64.com/en/b/0414/ Official page of the analyzer: http://www.viva64.com/en/pvs-studio/ If you have any questions, or if you are interested in the evaluation of our static analyzer or in any other source code quality control services that our company provides, please contact us at support at viva64.com. ---------- messages: 270974 nosy: pavel-belikov priority: normal severity: normal status: open title: Issues, reported by PVS-Studio static analyzer type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 03:27:06 2016 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 22 Jul 2016 07:27:06 +0000 Subject: [issue27572] Support bytes-like objects when base is given to int() In-Reply-To: <1468918576.73.0.596747914515.issue27572@psf.upfronthosting.co.za> Message-ID: <1469172426.71.0.222004282831.issue27572@psf.upfronthosting.co.za> Xiang Zhang added the comment: It's reasonable. My original intention is to make the behaviour consistent. If the single-argument behaviour is OK with bytes-like objects, why not others? So I think we'd better wait for other developers to see what their opinions are. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 03:48:26 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 22 Jul 2016 07:48:26 +0000 Subject: [issue27546] Integrate tkinter and asyncio (and async) In-Reply-To: <1468815010.57.0.709565417017.issue27546@psf.upfronthosting.co.za> Message-ID: <1469173706.58.0.163898282915.issue27546@psf.upfronthosting.co.za> Terry J. Reedy added the comment: New file loop_tk.py solve the responsiveness problem, at least for this example, by using the asyncio loop as it is and doing tk updates in a callback loop. It works with both SelectorEventLoop and ProactorEventLoop. I was inspired to try this, instead of my planned modification of _run_once, but Yury's post on uvloop http://magic.io/blog/uvloop-make-python-networking-great-again/. I realized that any modification of asyncio.XyzLoop would only work for that class, where as a standard callback loop would work with any sufficiently compatible loop. Yury, if you happen to read this, could you try loop_tk.py with the two uvloop lines added and get_event_loop uncommented? ---------- Added file: http://bugs.python.org/file43826/loop_tk.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 04:12:10 2016 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 22 Jul 2016 08:12:10 +0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1469175130.48.0.560578837624.issue1621@psf.upfronthosting.co.za> Xiang Zhang added the comment: @Martin, attach a patch to fix the overflow check you mentioned in tuple and list objects. ---------- nosy: +xiang.zhang Added file: http://bugs.python.org/file43827/tuple_and_list.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 04:14:56 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 22 Jul 2016 08:14:56 +0000 Subject: [issue27587] Issues, reported by PVS-Studio static analyzer In-Reply-To: <1469172132.31.0.293406285451.issue27587@psf.upfronthosting.co.za> Message-ID: <1469175296.25.0.246757261649.issue27587@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for the report. You seem to have identified some code from Open SSL as being from Python (e.g. ASN1_PRINTABLE_type() function in a_print.c). Here?s a quick copy of the details relevant to Python: V547 Expression 's->sock_fd < 0' is always false. Unsigned type value is never < 0. Modules/socketmodule.c:655 V547 Expression 's->sock_fd < 0' is always false. Unsigned type value is never < 0. Modules/_ssl.c:1702 V547 Expression 'sock->sock_fd < 0' is always false. Unsigned type value is never < 0. Modules/_ssl.c:2018 Suggestion: compare with INVALID_SOCKET V614 Potentially uninitialized pointer 'sigint_event' used. Modules/_multiprocessing/semaphore.c:120 V728 An excessive check can be simplified. The '||' operator is surrounded by opposite expressions 'quotetabs' and '!quotetabs'. Modules/binascii.c:1453 Null pointer check after use of ?def? in _PyState_AddModule(), Python/pystate.c V595 The 'self->extra' pointer was utilized before it was verified against nullptr. Check lines: 917, 923. Modules/_elementtree.c:917 The first two groups (sock_fd and sigint_event) look like Windows-specific code, and I suspect would be diagnosed with GCC (but building Python with GCC on Windows needs work). ---------- components: +Windows nosy: +martin.panter, paul.moore, steve.dower, tim.golden, zach.ware type: enhancement -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 04:26:13 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 22 Jul 2016 08:26:13 +0000 Subject: [issue27546] Integrate tkinter and asyncio (and async) In-Reply-To: <1468815010.57.0.709565417017.issue27546@psf.upfronthosting.co.za> Message-ID: <1469175973.16.0.291524963276.issue27546@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Using the callback loop from loop_tk.py, 3.6 repository IDLE runs with an asyncio loop. See idle-async.diff. So far, it seems about as snappy. I need to do a more stressful (longer running) gui operation test to be sure: change syntax highlighting with 10 or 20 editor windows open. ---------- keywords: +patch Added file: http://bugs.python.org/file43828/idle-async.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 05:29:01 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 22 Jul 2016 09:29:01 +0000 Subject: [issue26662] configure/Makefile doesn't check if "python" command works, needed to build Objects/typeslots.inc In-Reply-To: <1459247902.98.0.893274525942.issue26662@psf.upfronthosting.co.za> Message-ID: <1469179741.96.0.356548576691.issue26662@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Patch with a new error message. ---------- Added file: http://bugs.python.org/file43829/py_for_gen_26662_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 05:50:51 2016 From: report at bugs.python.org (Gareth Rees) Date: Fri, 22 Jul 2016 09:50:51 +0000 Subject: [issue27588] Type objects are hashable and comparable for equality but this is not documented Message-ID: <1469181051.15.0.925508125369.issue27588@psf.upfronthosting.co.za> New submission from Gareth Rees: The type objects constructed by the metaclasses in the typing module are hashable and comparable for equality: >>> from typing import * >>> {Mapping[str, int], Mapping[int, str]} {typing.Mapping[int, str], typing.Mapping[str, int]} >>> Union[str, int, float] == Union[float, int, str] True >>> List[int] == List[float] False but this is not clearly documented in the documentation for the typing module (there are a handful of examples using equality, but it's not explicit that these are runnable). It would be nice if there were explicit documentation for these properties of type objects. ---------- assignee: docs at python components: Documentation messages: 270981 nosy: Gareth.Rees, docs at python priority: normal severity: normal status: open title: Type objects are hashable and comparable for equality but this is not documented type: enhancement versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 06:08:25 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 22 Jul 2016 10:08:25 +0000 Subject: [issue27589] asyncio doc: issue in as_completed() doc Message-ID: <1469182105.52.0.303554063448.issue27589@psf.upfronthosting.co.za> New submission from STINNER Victor: Remark on as_completed() doc by Hynek. https://docs.python.org/dev/library/asyncio-task.html#asyncio.as_completed Futures are yielded in an unexpected order: as soon as a future completes. ---------- assignee: docs at python components: Documentation, asyncio messages: 270982 nosy: docs at python, gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: asyncio doc: issue in as_completed() doc versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 06:17:35 2016 From: report at bugs.python.org (Thomas Perl) Date: Fri, 22 Jul 2016 10:17:35 +0000 Subject: [issue27490] Do not run pgen when it is not going to be used (cross-compiling) In-Reply-To: <1468276938.3.0.370267656827.issue27490@psf.upfronthosting.co.za> Message-ID: <1469182655.45.0.212846964945.issue27490@psf.upfronthosting.co.za> Thomas Perl added the comment: Repurposing this bug as "do not run pgen". Documenting and using 'make PGEN_DEP=""' might also work; however, given that the configure script uses autoconf, and there's also code in place for PYTHON_FOR_BUILD, I've attached a patch that makes the PGEN dependency just a autoconf substitution -- this might make it clear and not depend on any make substitution features? Patch attached against current Hg cpython default branch tip, a similar patch also applies against 2.7. ---------- keywords: +patch title: ARM cross-compile: pgen built without $(CFLAGS) as $(LIBRARY) dependency -> Do not run pgen when it is not going to be used (cross-compiling) Added file: http://bugs.python.org/file43830/pgen_dependencies.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 06:36:43 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 Jul 2016 10:36:43 +0000 Subject: [issue27472] add the 'unix_shell' attribute to test.support In-Reply-To: <1468077155.86.0.151085889776.issue27472@psf.upfronthosting.co.za> Message-ID: <20160722103639.21454.22792.53B762D1@psf.io> Roundup Robot added the comment: New changeset 15835311b5e6 by Xavier de Gaye in branch 'default': Issue #27472: Add test.support.unix_shell as the path to the default shell. https://hg.python.org/cpython/rev/15835311b5e6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 06:38:17 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 22 Jul 2016 10:38:17 +0000 Subject: [issue27472] add the 'unix_shell' attribute to test.support In-Reply-To: <1468077155.86.0.151085889776.issue27472@psf.upfronthosting.co.za> Message-ID: <1469183897.29.0.99212320788.issue27472@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 Fri Jul 22 07:02:15 2016 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 22 Jul 2016 11:02:15 +0000 Subject: [issue1521950] shlex.split() does not tokenize like the shell Message-ID: <1469185335.76.0.777756307583.issue1521950@psf.upfronthosting.co.za> Changes by Vinay Sajip : Added file: http://bugs.python.org/file43831/refresh-2016.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 07:44:21 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 22 Jul 2016 11:44:21 +0000 Subject: [issue27490] Do not run pgen when it is not going to be used (cross-compiling) In-Reply-To: <1468276938.3.0.370267656827.issue27490@psf.upfronthosting.co.za> Message-ID: <1469187861.41.0.852492225901.issue27490@psf.upfronthosting.co.za> Martin Panter added the comment: This patch looks okay to me. I will commit it in a few days, unless anyone comes up with a better option. ---------- stage: -> patch review versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 09:30:44 2016 From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=) Date: Fri, 22 Jul 2016 13:30:44 +0000 Subject: [issue27582] Mispositioned SyntaxError caret for unknown code points In-Reply-To: <1469102054.52.0.839726574023.issue27582@psf.upfronthosting.co.za> Message-ID: <1469194244.91.0.42840230815.issue27582@psf.upfronthosting.co.za> Adam Barto? added the comment: Maybe this is related: http://bugs.python.org/issue26152. ---------- nosy: +Drekin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 09:33:50 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 22 Jul 2016 13:33:50 +0000 Subject: [issue8406] Make some setup.py paths exclude-able In-Reply-To: <1271301152.77.0.297402624492.issue8406@psf.upfronthosting.co.za> Message-ID: <1469194430.81.0.930346038184.issue8406@psf.upfronthosting.co.za> R. David Murray added the comment: No, no trouble. We appreciate Carol's efforts! As you say, any changes can be reversed; we prefer that people exercise triage privileges and make mistakes than that they feel too cautious to do anything. If our tone came across as confrontational that was unintentional. It is, rather, a matter, as you say, of communicating our community's style and standards. The only time a problem arises is if someone ignores or flat out rejects the feedback instead of accepting the community conventions or engaging in civil discussion about them, and that is certainly not the case here! There is also the possibility that our approach is not optimal, but that is a meta discussion that would take place on python-dev. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 09:57:55 2016 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 22 Jul 2016 13:57:55 +0000 Subject: [issue8406] Make some setup.py paths exclude-able In-Reply-To: <1271301152.77.0.297402624492.issue8406@psf.upfronthosting.co.za> Message-ID: <1469195875.22.0.788880978617.issue8406@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I'm sorry if my comment was too harsh, it wasn't intended as such. I was surprised at seeing a number of e-mails about issues that were closed because they were out of date. I don't agree with closing old issues when there is actionable content in them because that might result in losing valuable information as closed issues are effectively gone. Closing old issues is fine when it is clear that the are no longer relevant, but that should IMHO be done with a message that explains why the issue is closed (such as when an issue can no longer be reproduced in supported branches on Python and/or on supported OS releases). BTW. Feel free to ping me about issues assigned to me when they appear to be no longer relevant but you're not sure. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 10:01:55 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 22 Jul 2016 14:01:55 +0000 Subject: [issue27572] Support bytes-like objects when base is given to int() In-Reply-To: <1468918576.73.0.596747914515.issue27572@psf.upfronthosting.co.za> Message-ID: <1469196115.38.0.866973969346.issue27572@psf.upfronthosting.co.za> R. David Murray added the comment: Since bytes are accepted in both cases, the inconsistency does seem odd. Looking at the history, I think the else statement that checks the types that can be handled was introduced during the initial py3k conversion, and I'm guessing that else was just forgotten in subsequent updates that added additional bytes-like types. The non-base branch calls PyNumber_Long, where I presume it picked up the additional type support. If a copy has to be done anyway, perhaps we can future proof the code by doing a bytes conversion internally in long_new? Disallowing something that currently works without a good reason isn't good for backward compatibility, so I'd vote for making this work consistently one way or another. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 10:06:06 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 22 Jul 2016 14:06:06 +0000 Subject: [issue27588] Type (typing) objects are hashable and comparable for equality but this is not documented In-Reply-To: <1469181051.15.0.925508125369.issue27588@psf.upfronthosting.co.za> Message-ID: <1469196366.01.0.135258790827.issue27588@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- title: Type objects are hashable and comparable for equality but this is not documented -> Type (typing) objects are hashable and comparable for equality but this is not documented _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 11:11:06 2016 From: report at bugs.python.org (Yujie Chen) Date: Fri, 22 Jul 2016 15:11:06 +0000 Subject: [issue27590] tarfile module next() method hides exceptions Message-ID: <1469200266.16.0.443973453456.issue27590@psf.upfronthosting.co.za> New submission from Yujie Chen: I have seen a similar ticket, however that was opened 2 years ago and has nothing more than a brief description. So I opened this new one here, hoping to get some answers. tarfile.TarFile object is iterable and has a next() method. next() will parse the header and save parsed info. During parsing, a lot of checks are done, to make sure the header is valid. And if there is something wrong with the header, exceptions will be thrown. next() catches a lot of them but not reraise what it catches in all cases. I have a tgz file, one of the headers is corrupted with a wrong checksum section. thus during parsing, InvalidHeaderError was thrown. next() catches that but hide it silently. From source code (https://hg.python.org/cpython/file/2.7/Lib/tarfile.py#l2335), we can see that InvalidHeaderError will ONLY be raised if it happens in the beginning of the tar file. Actually, a lot of exceptions are hidden by tarfile module. tarfile module simply thinks these exceptions mark the end of tarball. Why does tarfile module hide so many exceptions? or in other words, why does tarfile treat these exceptions as the end marker of tarball but not errors? Is it because of this from GNU doc: "At the end of the archive file there are two 512-byte blocks filled with binary zeros as an end-of-file marker. A reasonable system should write such end-of-file marker at the end of an archive, but must not assume that such a block exists when reading an archive."? Thanks! ---------- components: Library (Lib) messages: 270990 nosy: JieGhost priority: normal severity: normal status: open title: tarfile module next() method hides exceptions type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 11:12:39 2016 From: report at bugs.python.org (Chris Angelico) Date: Fri, 22 Jul 2016 15:12:39 +0000 Subject: [issue27591] multiprocessing: Possible uninitialized pointer use in Windows builds Message-ID: <1469200359.36.0.370469252953.issue27591@psf.upfronthosting.co.za> New submission from Chris Angelico: Originally reported (if you can call it "reported") here: http://www.viva64.com/en/b/0414/ AFAICT, this is an easy and inconsequential fix. ---------- files: uninitialized-pointer.patch keywords: patch messages: 270991 nosy: Rosuav priority: normal severity: normal status: open title: multiprocessing: Possible uninitialized pointer use in Windows builds versions: Python 3.6 Added file: http://bugs.python.org/file43832/uninitialized-pointer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 11:27:56 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 22 Jul 2016 15:27:56 +0000 Subject: [issue27591] multiprocessing: Possible uninitialized pointer use in Windows builds In-Reply-To: <1469200359.36.0.370469252953.issue27591@psf.upfronthosting.co.za> Message-ID: <1469201276.71.0.750308048988.issue27591@psf.upfronthosting.co.za> Berker Peksag added the comment: LGTM ---------- assignee: -> berker.peksag components: +Extension Modules nosy: +berker.peksag stage: -> patch review type: -> behavior versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 11:28:43 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 Jul 2016 15:28:43 +0000 Subject: [issue26559] logging.handlers.MemoryHandler flushes on shutdown but not removal In-Reply-To: <1457978506.77.0.246614135279.issue26559@psf.upfronthosting.co.za> Message-ID: <20160722152840.24675.64235.E2DB427E@psf.io> Roundup Robot added the comment: New changeset a399daacb591 by Vinay Sajip in branch 'default': Closes #26559: Allow configuring flush-on-close behaviour of MemoryHandler. https://hg.python.org/cpython/rev/a399daacb591 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 11:32:02 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 22 Jul 2016 15:32:02 +0000 Subject: [issue27572] Support bytes-like objects when base is given to int() In-Reply-To: <1468918576.73.0.596747914515.issue27572@psf.upfronthosting.co.za> Message-ID: <1469201522.48.0.768338533468.issue27572@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It looks to me that the support of bytes-like objects besides bytes and bytearray was added accidentally, as a side effect of supporting Unicode. Note, that this support had a bug until issue24802, thus correct support of other bytes-like objects exists less than a year. The option of deprecating other bytes-like objects support looks reasonable to me. Especially in the light of deprecating bytearray paths support (issue26800). On other side, the need of copying a buffer can be considered as implementation detail, since low-level int parsing functions require NUL-terminated C strings. We can add alternative low-level functions that work with not-NUL-terminated strings. This needs more work. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 11:54:42 2016 From: report at bugs.python.org (Chris Angelico) Date: Fri, 22 Jul 2016 15:54:42 +0000 Subject: [issue27591] multiprocessing: Possible uninitialized pointer use in Windows builds In-Reply-To: <1469200359.36.0.370469252953.issue27591@psf.upfronthosting.co.za> Message-ID: <1469202882.44.0.715899091341.issue27591@psf.upfronthosting.co.za> Chris Angelico added the comment: Berker, I don't push code to CPython (I have the commitbit for PEP editing), so do you want to push that? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 12:21:35 2016 From: report at bugs.python.org (Matthias Bussonnier) Date: Fri, 22 Jul 2016 16:21:35 +0000 Subject: [issue8406] Make some setup.py paths exclude-able In-Reply-To: <1271301152.77.0.297402624492.issue8406@psf.upfronthosting.co.za> Message-ID: <1469204495.35.0.722847459976.issue8406@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: > [2 nice response] Thanks for the nice responses, we all know it can be hard to find the right balance between making a concise comment, and being delicate enough. Thanks all for your hard work on CPython, and looking forward to have time to contribute more ! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 12:23:37 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Fri, 22 Jul 2016 16:23:37 +0000 Subject: [issue27588] Type (typing) objects are hashable and comparable for equality but this is not documented In-Reply-To: <1469181051.15.0.925508125369.issue27588@psf.upfronthosting.co.za> Message-ID: <1469204617.23.0.920707414433.issue27588@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: I am not sure that this feature will survive the resolution of https://github.com/python/typing/issues/136 Types in typing are primarily intended for use with static type checkers and similar tools, their runtime properties are still under some discussions. ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 12:25:29 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 22 Jul 2016 16:25:29 +0000 Subject: [issue27590] tarfile module next() method hides exceptions In-Reply-To: <1469200266.16.0.443973453456.issue27590@psf.upfronthosting.co.za> Message-ID: <1469204729.47.0.615614253712.issue27590@psf.upfronthosting.co.za> R. David Murray added the comment: That would be my guess. If we are reading along and we hit garbage data, we assume we've reached the end of the tar. That doesn't mean there isn't room for improvement, or perhaps issuing a warning message about why we think we hit the end of the tar. What is the issue number of the other issue? If it is still open we should consolidate the issues if appropriate. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 12:31:50 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 22 Jul 2016 16:31:50 +0000 Subject: [issue27572] Support bytes-like objects when base is given to int() In-Reply-To: <1468918576.73.0.596747914515.issue27572@psf.upfronthosting.co.za> Message-ID: <1469205110.72.0.342339504363.issue27572@psf.upfronthosting.co.za> R. David Murray added the comment: So less than a year means only some versions of 3.5? So we could drop it in 3.6 and hope we don't break anybody's code? I'm not sure I like that...I think the real problem is the complexity of handling multiple bytes types, and that ought to have a more general solution. I'm not volunteering to work on it, though, so I'm not voting against dropping it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 12:34:02 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 22 Jul 2016 16:34:02 +0000 Subject: [issue27591] multiprocessing: Possible uninitialized pointer use in Windows builds In-Reply-To: <1469200359.36.0.370469252953.issue27591@psf.upfronthosting.co.za> Message-ID: <1469205242.12.0.854260347652.issue27591@psf.upfronthosting.co.za> Berker Peksag added the comment: Yes, that's why I assigned it to myself :) Thanks for the patch! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 12:37:15 2016 From: report at bugs.python.org (Chris Angelico) Date: Fri, 22 Jul 2016 16:37:15 +0000 Subject: [issue27591] multiprocessing: Possible uninitialized pointer use in Windows builds In-Reply-To: <1469200359.36.0.370469252953.issue27591@psf.upfronthosting.co.za> Message-ID: <1469205435.06.0.22133692187.issue27591@psf.upfronthosting.co.za> Chris Angelico added the comment: Cool cool! Then someone will need to notify the PVS-Studio people that we've fixed the two bugs that are actually our bugs :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 12:49:37 2016 From: report at bugs.python.org (Chris Rebert) Date: Fri, 22 Jul 2016 16:49:37 +0000 Subject: [issue27561] Warn against subclassing builtins, and overriding their methods In-Reply-To: <1468848651.49.0.804648096873.issue27561@psf.upfronthosting.co.za> Message-ID: <1469206177.58.0.469113661006.issue27561@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 12:49:48 2016 From: report at bugs.python.org (Chris Rebert) Date: Fri, 22 Jul 2016 16:49:48 +0000 Subject: [issue27587] Issues, reported by PVS-Studio static analyzer In-Reply-To: <1469172132.31.0.293406285451.issue27587@psf.upfronthosting.co.za> Message-ID: <1469206188.38.0.930026765356.issue27587@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 13:31:36 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 22 Jul 2016 17:31:36 +0000 Subject: [issue27587] Issues, reported by PVS-Studio static analyzer In-Reply-To: <1469172132.31.0.293406285451.issue27587@psf.upfronthosting.co.za> Message-ID: <1469208696.91.0.632754919845.issue27587@psf.upfronthosting.co.za> Berker Peksag added the comment: > V547 Expression 's->sock_fd < 0' is always false. Unsigned type value is never < 0. Modules/socketmodule.c:655 > V547 Expression 's->sock_fd < 0' is always false. Unsigned type value is never < 0. Modules/_ssl.c:1702 > V547 Expression 'sock->sock_fd < 0' is always false. Unsigned type value is never < 0. Modules/_ssl.c:2018 Victor fixed these issues in 6c11f52ab9db and 025281485318. > V614 Potentially uninitialized pointer 'sigint_event' used. Modules/_multiprocessing/semaphore.c:120 See issue 27591. ---------- nosy: +berker.peksag stage: -> needs patch versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 13:40:40 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 22 Jul 2016 17:40:40 +0000 Subject: [issue27591] multiprocessing: Possible uninitialized pointer use in Windows builds In-Reply-To: <1469200359.36.0.370469252953.issue27591@psf.upfronthosting.co.za> Message-ID: <1469209240.88.0.841213552127.issue27591@psf.upfronthosting.co.za> STINNER Victor added the comment: It's a little strange that nobody reports a multiprocessing crash on Windows before. It looks like ResetEvent() is called with a random number (coming from the uninitialized stack memory). Windows is probably smart and does nothing if the argument is not a known handle of an event object. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 13:41:20 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 22 Jul 2016 17:41:20 +0000 Subject: [issue27591] multiprocessing: Possible uninitialized pointer use in Windows builds In-Reply-To: <1469200359.36.0.370469252953.issue27591@psf.upfronthosting.co.za> Message-ID: <1469209280.42.0.844294437681.issue27591@psf.upfronthosting.co.za> STINNER Victor added the comment: I suggested a different way to fix the issue on the review. Python 2.7 is not affected by the bug, but Python 3.5 and 3.6 are affected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 13:42:12 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 22 Jul 2016 17:42:12 +0000 Subject: [issue27587] Issues, reported by PVS-Studio static analyzer In-Reply-To: <1469172132.31.0.293406285451.issue27587@psf.upfronthosting.co.za> Message-ID: <1469209332.82.0.538409539833.issue27587@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 13:58:50 2016 From: report at bugs.python.org (Yujie Chen) Date: Fri, 22 Jul 2016 17:58:50 +0000 Subject: [issue27590] tarfile module next() method hides exceptions In-Reply-To: <1469200266.16.0.443973453456.issue27590@psf.upfronthosting.co.za> Message-ID: <1469210330.07.0.748564633996.issue27590@psf.upfronthosting.co.za> Yujie Chen added the comment: The other issue is http://bugs.python.org/issue16858 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 14:02:24 2016 From: report at bugs.python.org (Cristi Fati) Date: Fri, 22 Jul 2016 18:02:24 +0000 Subject: [issue27592] FIPS_mode() and FIPS_mode_set() functions in Python (ssl) Message-ID: <1469210543.94.0.196720087995.issue27592@psf.upfronthosting.co.za> New submission from Cristi Fati: During last years, the FIPS mode, has become more and more popular, especially in US (probably because it was "promoted" by government institutions). All OpenSSL versions (didn't check 1.0.0 or lower since they're no longer supported), have the "basic FIPS functionality", even if built without openssl-fips module. By "basic FIPS functionality", I mean the 2 functions: - `int FIPS_mode(void)` - used to get the current FIPS mode (for non FIPS openssl, it simply returns 0) - `int FIPS_mode_set(int r)` - used to set the current FIPS mode in the currently loaded libcrypto/libeay32 (for non FIPS openssl it sets the openssl error: "error:0F06D065:common libcrypto routines:FIPS_mode_set:fips mode not supported") The goal of this patch is to add the 2 functions in Python (3.4.4 source tarball) - ssl (and _ssl) module - in order to be able to control FIPS mode from within a Python process (I am aware that some platforms allow setting FIPS at a global level, but this offers more granularity). The patch is simple, for the getter it simply returns the OpenSSL function value, while for the setter it doesn't return anything but throws an exception if some error occurs. Note0 (about how do I set the error): `_setSSLError(ERR_error_string(ERR_get_error(), NULL) , 0, __FILE__, __LINE__);` as opposed to the regular way: `_setSSLError(NULL, 0, __FILE__, __LINE__);`. I didn't use the whole make_ssl_data.py mechanism because: - 1 - it binds against the OpenSSL version used at compile time - 1.1 - on Ux (where Python modules are dynamically linked to OpenSSL), if compiling against one OpenSSL version and at runtime another (newer) version which defines new functionality (and new error codes) is present, if one of those newer errors is encountered, the error message won't be as complete: "ssl.SSLError: fips mode already set (_ssl.c:3763)" as opposed to "ssl.SSLError: error:2D078072:FIPS routines:FIPS_module_mode_set:fips mode already set (_ssl.c:3763)" - 1.2 - on Win (where Python modules are statically linked to OpenSSL), there won't be such a problem. However, regarding static linking (this is not related to this post), this is not a scalable solution (now if only _ssl and _hashlib link to OpenSSL, it's __sort of__ OK, but if another one, or more will be added it won't be), so dynamic linking should be used, although that comes with its problems. 2 possible ways to solve them: - 1.2.1 - simply dynamic link to OpenSSL and at runtime it will fail importing the modules; this will happen a lot since (as opposed to Ux), I think that there's a 90%+ chance that no OpenSSL is installed on a Win machine - 1.2.2 - dynamic link to OpenSSL and also redistribute the OpenSSL dlls (although I didn't check what this would mean from licensing PoV). This would also raise the problem of precedence: which dlls should be used by default if an OpenSSL version is installed on the machine. - 2 - It is simpler (here I might be missing something). To me it seems cleaner to delegate the job to (runtime) OpenSSL instead of make_ssl_data.py and the logic from `fill_and_set_sslerror` (which could be removed in the future, I'd say). Note1: The whole thing could also be applied to hashlib (simply copy the changes from ssl.py to hashlib.py - to have as less duplicate code as possible), but since due to hashlib caching, changing the FIPS mode on the fly won't be reflected in the possibility/impossibility of using a hash (e.g. `md5`), I figured that it doesn't worth the effort. As a workaround, for someone who really needs to set it, they can do it from ssl. ---------- files: Python-3.4.4-ssl_fips.patch keywords: patch messages: 271006 nosy: CristiFati priority: normal severity: normal status: open title: FIPS_mode() and FIPS_mode_set() functions in Python (ssl) type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file43833/Python-3.4.4-ssl_fips.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 14:02:59 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 Jul 2016 18:02:59 +0000 Subject: [issue27493] logging module fails with unclear error when supplied a (Posix)Path In-Reply-To: <1468314884.39.0.604549697605.issue27493@psf.upfronthosting.co.za> Message-ID: <20160722180256.6795.58647.1868220B@psf.io> Roundup Robot added the comment: New changeset fada654c5f72 by Vinay Sajip in branch 'default': Closes #27493: accepted Path objects in file handlers for logging. https://hg.python.org/cpython/rev/fada654c5f72 ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 14:09:46 2016 From: report at bugs.python.org (Alex Gaynor) Date: Fri, 22 Jul 2016 18:09:46 +0000 Subject: [issue27592] FIPS_mode() and FIPS_mode_set() functions in Python (ssl) In-Reply-To: <1469210543.94.0.196720087995.issue27592@psf.upfronthosting.co.za> Message-ID: <1469210986.32.0.803946267736.issue27592@psf.upfronthosting.co.za> Alex Gaynor added the comment: I'm opposed to adding FIPS knobs to Python's SSL module for a few reasons: - FIPS is a bad standard (which I'm happy to talk at length about) - OpenSSL is regularly on the verge of dropping FIPS support (https://www.openssl.org/blog/blog/2016/07/20/fips/ is the most recent rescue from the brink of removal) - It further ties us to the OpenSSL API, in favor of being a more general purpose SSL API. ---------- nosy: +alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 14:32:35 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 22 Jul 2016 18:32:35 +0000 Subject: [issue27572] Support bytes-like objects when base is given to int() In-Reply-To: <1468918576.73.0.596747914515.issue27572@psf.upfronthosting.co.za> Message-ID: <1469212355.01.0.838945559929.issue27572@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: No, the fix was applied to all maintained versions (2.7 and 3.4+). This means that we need some deprecation period before dropping this feature (if decide to drop it). What about other Python implementations? Are they support byte-likes objects besides bytes and bytearray? Do they correctly handle embedded NUL and not-NUL-terminated buffers? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 15:38:45 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 22 Jul 2016 19:38:45 +0000 Subject: [issue16858] tarfile silently hides errors In-Reply-To: <1357286028.6.0.98597292825.issue16858@psf.upfronthosting.co.za> Message-ID: <1469216325.56.0.390368692923.issue16858@psf.upfronthosting.co.za> R. David Murray added the comment: Closing this in favor of issue 27590, which at least got a little discussion. ---------- nosy: +r.david.murray resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> tarfile module next() method hides exceptions _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 15:41:07 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 22 Jul 2016 19:41:07 +0000 Subject: [issue27590] tarfile module next() method hides exceptions In-Reply-To: <1469200266.16.0.443973453456.issue27590@psf.upfronthosting.co.za> Message-ID: <1469216467.25.0.0405830804705.issue27590@psf.upfronthosting.co.za> R. David Murray added the comment: OK, I've closed #16858 in favor of this one, since we at least had some discussion here. I see you selected 2.7. Does python3 have the same issues? (I'm guessing it does, though there has been some work done on the module.) ---------- nosy: +mmarkk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 15:46:36 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 22 Jul 2016 19:46:36 +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: <1469216796.37.0.123627185733.issue23951@psf.upfronthosting.co.za> Brett Cannon added the comment: Moved to https://github.com/python/devguide/issues/6 ---------- nosy: +brett.cannon resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 15:47:22 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 22 Jul 2016 19:47:22 +0000 Subject: [issue24016] Add a Sprints organization/preparation section to devguide In-Reply-To: <1429545736.46.0.134603387564.issue24016@psf.upfronthosting.co.za> Message-ID: <1469216842.27.0.217362577826.issue24016@psf.upfronthosting.co.za> Brett Cannon added the comment: Moved to https://github.com/python/devguide/issues/7 ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 15:48:18 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 22 Jul 2016 19:48:18 +0000 Subject: [issue24682] Add Quick Start: Communications section to devguide In-Reply-To: <1437540333.82.0.609056038167.issue24682@psf.upfronthosting.co.za> Message-ID: <1469216898.29.0.596290450093.issue24682@psf.upfronthosting.co.za> Brett Cannon added the comment: Moved to https://github.com/python/devguide/issues/8 ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 15:48:20 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 22 Jul 2016 19:48:20 +0000 Subject: [issue27592] FIPS_mode() and FIPS_mode_set() functions in Python (ssl) In-Reply-To: <1469210543.94.0.196720087995.issue27592@psf.upfronthosting.co.za> Message-ID: <1469216900.34.0.577967016565.issue27592@psf.upfronthosting.co.za> R. David Murray added the comment: See also issue 9216 and issue 9146. Even if we wanted to do it it sounds like it isn't quite as easy as allowing the mode to be set. I'm inclined to agree with Alex, since he's the expert. Especially since it *is* possible to set it from outside the process. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 15:49:21 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 22 Jul 2016 19:49:21 +0000 Subject: [issue20851] Update devguide to cover testing from a tarball In-Reply-To: <1393944432.91.0.924701829685.issue20851@psf.upfronthosting.co.za> Message-ID: <1469216961.69.0.670827316733.issue20851@psf.upfronthosting.co.za> Brett Cannon added the comment: I don't think this is worth doing. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 15:50:02 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 22 Jul 2016 19:50:02 +0000 Subject: [issue24689] Add tips for effective online communication to devguide In-Reply-To: <1437626209.97.0.982042727918.issue24689@psf.upfronthosting.co.za> Message-ID: <1469217002.18.0.634567355842.issue24689@psf.upfronthosting.co.za> Brett Cannon added the comment: Moved to https://github.com/python/devguide/issues/9 ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 15:50:50 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 22 Jul 2016 19:50:50 +0000 Subject: [issue10965] dev task of documenting undocumented APIs In-Reply-To: <1295566423.14.0.859020697485.issue10965@psf.upfronthosting.co.za> Message-ID: <1469217050.06.0.840134406719.issue10965@psf.upfronthosting.co.za> Brett Cannon added the comment: Moved to https://github.com/python/devguide/issues/10 ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 15:51:32 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 22 Jul 2016 19:51:32 +0000 Subject: [issue17227] devguide: buggy heading numbers In-Reply-To: <1361217002.34.0.936078305401.issue17227@psf.upfronthosting.co.za> Message-ID: <1469217092.48.0.67750156055.issue17227@psf.upfronthosting.co.za> Brett Cannon added the comment: Moved to https://github.com/python/devguide/issues/11 ---------- nosy: +brett.cannon resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 15:52:05 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 22 Jul 2016 19:52:05 +0000 Subject: [issue16930] mention limitations and/or alternatives to hg graft In-Reply-To: <1357893519.23.0.747104705775.issue16930@psf.upfronthosting.co.za> Message-ID: <1469217125.39.0.226872504647.issue16930@psf.upfronthosting.co.za> Brett Cannon added the comment: With the migration to git pending, this won't be worth the effort. ---------- nosy: +brett.cannon resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 15:53:26 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 22 Jul 2016 19:53:26 +0000 Subject: [issue16931] mention work-around to create diffs in default/non-git mode In-Reply-To: <1357894611.9.0.235167303817.issue16931@psf.upfronthosting.co.za> Message-ID: <1469217206.27.0.284272339647.issue16931@psf.upfronthosting.co.za> Brett Cannon added the comment: With the pending migration to git, this probably isn't worth the effort. ---------- nosy: +brett.cannon resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 15:54:44 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 22 Jul 2016 19:54:44 +0000 Subject: [issue23320] devguide should mention rules about "paragraph reflow" in the documentation In-Reply-To: <1422219993.92.0.674256323538.issue23320@psf.upfronthosting.co.za> Message-ID: <1469217284.88.0.433059121544.issue23320@psf.upfronthosting.co.za> Brett Cannon added the comment: Moved to https://github.com/python/devguide/issues/12 ---------- nosy: +brett.cannon resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 15:55:02 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 22 Jul 2016 19:55:02 +0000 Subject: [issue27539] negative Fraction ** negative int not normalized In-Reply-To: <1468740731.71.0.38394274484.issue27539@psf.upfronthosting.co.za> Message-ID: <1469217302.36.0.0564054246413.issue27539@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Vedran: The migration to git and GitHub is in progress. The devguide is being moved today. CPython itself should be done by the end of the year, but after 3.6.0 is released in Sept. I am on Windows and yes, setting up on Windows can be a nuisance. Learning VS is not needed, as one can just run PCBuild/build.bat to compile. But installing 9 GB of even the free version, to use the compiler, is. TortoiseHG makes minimal use of hg pretty easy. I had never used any source control system before. But this will be unnecessary soon. I let Mark decide if he can use the diff as is. Are the line numbers those of fractions.py, or do they need to be translated? ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 15:55:20 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 22 Jul 2016 19:55:20 +0000 Subject: [issue18041] mention issues with code churn in the devguide In-Reply-To: <1369280251.47.0.219323501066.issue18041@psf.upfronthosting.co.za> Message-ID: <1469217320.56.0.943271723006.issue18041@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 15:56:25 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 22 Jul 2016 19:56:25 +0000 Subject: [issue14218] include rendered output in addition to markup In-Reply-To: <1331111194.08.0.943407781198.issue14218@psf.upfronthosting.co.za> Message-ID: <1469217385.71.0.553860425394.issue14218@psf.upfronthosting.co.za> Brett Cannon added the comment: Moved to https://github.com/python/devguide/issues/14 ---------- nosy: +brett.cannon resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 15:57:37 2016 From: report at bugs.python.org (Martin Teichmann) Date: Fri, 22 Jul 2016 19:57:37 +0000 Subject: [issue27366] PEP487: Simpler customization of class creation In-Reply-To: <1466579967.76.0.483118833643.issue27366@psf.upfronthosting.co.za> Message-ID: <1469217457.5.0.688039371002.issue27366@psf.upfronthosting.co.za> Changes by Martin Teichmann : Removed file: http://bugs.python.org/file43611/pep487a.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 15:58:16 2016 From: report at bugs.python.org (Martin Teichmann) Date: Fri, 22 Jul 2016 19:58:16 +0000 Subject: [issue27366] PEP487: Simpler customization of class creation In-Reply-To: <1466579967.76.0.483118833643.issue27366@psf.upfronthosting.co.za> Message-ID: <1469217496.08.0.612485998523.issue27366@psf.upfronthosting.co.za> Changes by Martin Teichmann : Added file: http://bugs.python.org/file43834/pep487.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 16:02:59 2016 From: report at bugs.python.org (Christian Heimes) Date: Fri, 22 Jul 2016 20:02:59 +0000 Subject: [issue27592] FIPS_mode() and FIPS_mode_set() functions in Python (ssl) In-Reply-To: <1469216900.34.0.577967016565.issue27592@psf.upfronthosting.co.za> Message-ID: Christian Heimes added the comment: I second Alex's statement, too. Am 22. Juli 2016 21:48:20 MESZ, schrieb "R. David Murray" : > >R. David Murray added the comment: > >See also issue 9216 and issue 9146. Even if we wanted to do it it >sounds like it isn't quite as easy as allowing the mode to be set. > >I'm inclined to agree with Alex, since he's the expert. Especially >since it *is* possible to set it from outside the process. > >---------- >nosy: +r.david.murray > >_______________________________________ >Python tracker > >_______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 16:09:51 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 22 Jul 2016 20:09:51 +0000 Subject: [issue27592] FIPS_mode() and FIPS_mode_set() functions in Python (ssl) In-Reply-To: <1469210543.94.0.196720087995.issue27592@psf.upfronthosting.co.za> Message-ID: <1469218191.4.0.755475166204.issue27592@psf.upfronthosting.co.za> R. David Murray added the comment: Heh, I should have said "an" expert. With two weighing in I think I'll close this. Thanks for the contribution, though. Sorry we aren't going to make use of it. ---------- resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 16:18:17 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 22 Jul 2016 20:18:17 +0000 Subject: [issue27561] Warn against subclassing builtins, and overriding their methods In-Reply-To: <1468848651.49.0.804648096873.issue27561@psf.upfronthosting.co.za> Message-ID: <1469218697.21.0.97228262024.issue27561@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Will do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 16:22:28 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 22 Jul 2016 20:22:28 +0000 Subject: [issue27366] PEP487: Simpler customization of class creation In-Reply-To: <1466579967.76.0.483118833643.issue27366@psf.upfronthosting.co.za> Message-ID: <1469218948.28.0.841485743838.issue27366@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- components: +Interpreter Core -Library (Lib) nosy: +berker.peksag stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 16:22:33 2016 From: report at bugs.python.org (Bruce Eckel) Date: Fri, 22 Jul 2016 20:22:33 +0000 Subject: [issue27586] Is this a regular expression library bug? In-Reply-To: <1469135022.02.0.0194014811902.issue27586@psf.upfronthosting.co.za> Message-ID: <1469218953.05.0.158366603145.issue27586@psf.upfronthosting.co.za> Bruce Eckel added the comment: Thank you ebarry, very helpful. Tim, sorry I missed you at Pycon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 16:28:14 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 22 Jul 2016 20:28:14 +0000 Subject: [issue27544] Document the ABCs for instance/subclass checks of dict view types In-Reply-To: <1468805116.02.0.14575319212.issue27544@psf.upfronthosting.co.za> Message-ID: <1469219294.32.0.0829406205546.issue27544@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The view objects *are* built-ins, but are not exposed in the __builtins__ module. This is true of many internal types, perhaps even a majority. The function and list_iterator classes are other examples. >>> type(lambda: 0) >>> type(iter([])) A few such 'hidden' classes are exposed in the types module. "This module provides names for many of the types that are required to implement a Python interpreter. It deliberately avoids including some of the types that arise only incidentally during processing such as the listiterator type. Typical use of these names is for isinstance() or issubclass() checks." The function class is. "types.FunctionType types.LambdaType The type of user-defined functions and functions created by lambda expressions." The list_iterator class is not. Perhaps the rationale is that there is no reason to know whether an iterator is iterating over a list, tuple, range, set, frozenset, dict, or anything else. They are all used the same. On the other hand, Different view types are used a bit differently. Types includes a generic MappingProxyType. Perhaps you should propose adding the specific dict view types. Or you can create them yourself. KeysViewType = type({}.keys()) ValuesViewType = type({}.values()) ItemsViewType = type({}.items()) This is the code that would be used in the module if they were added there. ---------- nosy: +terry.reedy versions: -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 16:35:07 2016 From: report at bugs.python.org (Martin Teichmann) Date: Fri, 22 Jul 2016 20:35:07 +0000 Subject: [issue27366] PEP487: Simpler customization of class creation In-Reply-To: <1466579967.76.0.483118833643.issue27366@psf.upfronthosting.co.za> Message-ID: <1469219707.79.0.138426524153.issue27366@psf.upfronthosting.co.za> Changes by Martin Teichmann : Removed file: http://bugs.python.org/file43834/pep487.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 16:35:34 2016 From: report at bugs.python.org (Martin Teichmann) Date: Fri, 22 Jul 2016 20:35:34 +0000 Subject: [issue27366] PEP487: Simpler customization of class creation In-Reply-To: <1466579967.76.0.483118833643.issue27366@psf.upfronthosting.co.za> Message-ID: <1469219734.94.0.664828797963.issue27366@psf.upfronthosting.co.za> Changes by Martin Teichmann : Added file: http://bugs.python.org/file43835/pep487.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 16:47:35 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 22 Jul 2016 20:47:35 +0000 Subject: [issue27547] Crash or freeze trying to execute b'a' * 0xFFFFFFFFFFFFFFF In-Reply-To: <1468820344.69.0.285015698444.issue27547@psf.upfronthosting.co.za> Message-ID: <1469220455.28.0.600709042055.issue27547@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Crash reports should include the minimum code needed to produce the crash. Adding function calls that never happen because the arguments cannot be computed adds noise that obscures the problem. Here, b"a"*0xFFFFFFFFFFFFFFF would require more memory that any current computer has. Float and array are irrelevant. On Windows, it freezes python. A MemoryError would be nicer, but this may be "won't fix". ---------- nosy: +terry.reedy title: Integer Overflow Crash On float(array.array()) -> Crash or freeze trying to execute b'a' * 0xFFFFFFFFFFFFFFF _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 16:51:25 2016 From: report at bugs.python.org (Yujie Chen) Date: Fri, 22 Jul 2016 20:51:25 +0000 Subject: [issue27590] tarfile module next() method hides exceptions In-Reply-To: <1469200266.16.0.443973453456.issue27590@psf.upfronthosting.co.za> Message-ID: <1469220685.68.0.383889921844.issue27590@psf.upfronthosting.co.za> Yujie Chen added the comment: Yeah, I just tried on Python3.5 and it didn't report any errors either. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 16:54:59 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Fri, 22 Jul 2016 20:54:59 +0000 Subject: [issue27271] asyncio lost udp packets In-Reply-To: <1465417059.51.0.620953300582.issue27271@psf.upfronthosting.co.za> Message-ID: <1469220899.17.0.738905281211.issue27271@psf.upfronthosting.co.za> ???? ????????? added the comment: @yselivanov Can you prove that packets may be lost even in UNIX sockets ? (it is not related to this task directly) ---------- nosy: +mmarkk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 17:19:09 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 22 Jul 2016 21:19:09 +0000 Subject: [issue27590] tarfile module next() method hides exceptions In-Reply-To: <1469200266.16.0.443973453456.issue27590@psf.upfronthosting.co.za> Message-ID: <1469222349.37.0.18446080824.issue27590@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Lars Gust?bel did most of the work on this and it would be nice to get his thoughts. The exception swallowing is explicit here rather than accidental. See http://bugs.python.org/issue6123 ---------- nosy: +lars.gustaebel, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 17:23:10 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 22 Jul 2016 21:23:10 +0000 Subject: [issue27577] Make implementation and doc of tuple and list more compliant In-Reply-To: <1469002642.37.0.996165914529.issue27577@psf.upfronthosting.co.za> Message-ID: <1469222590.86.0.891774560806.issue27577@psf.upfronthosting.co.za> Terry J. Reedy added the comment: >>> help(tuple) Help on class tuple in module builtins: class tuple(object) | tuple() -> empty tuple | tuple(iterable) -> tuple initialized from iterable's items ... >>> tuple(sequence=[1,2,3]) (1, 2, 3) I am surprised. Searches with Google, Githup, Nullage turned up no example of such usage. 'tuple(sequence)' has, rather naturally, been used. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 17:23:54 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 22 Jul 2016 21:23:54 +0000 Subject: [issue27575] dict viewkeys intersection slow for large dicts In-Reply-To: <1468950707.74.0.640405379684.issue27575@psf.upfronthosting.co.za> Message-ID: <1469222634.59.0.50131933895.issue27575@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Do you encounter an actual real-world use case or is this just a theoretical issue? ISTM, the performance is already good enough for most practical applications. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 17:24:20 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 22 Jul 2016 21:24:20 +0000 Subject: [issue27579] Add a tutorial for AsyncIO in the documentation In-Reply-To: <1469025749.21.0.829921979586.issue27579@psf.upfronthosting.co.za> Message-ID: <1469222660.07.0.292051233182.issue27579@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 17:27:03 2016 From: report at bugs.python.org (Cristi Fati) Date: Fri, 22 Jul 2016 21:27:03 +0000 Subject: [issue27592] FIPS_mode() and FIPS_mode_set() functions in Python (ssl) In-Reply-To: <1469210543.94.0.196720087995.issue27592@psf.upfronthosting.co.za> Message-ID: <1469222823.33.0.599253789108.issue27592@psf.upfronthosting.co.za> Cristi Fati added the comment: Thank you all for chiming in (so quickly). I did this in 2013 (maybe back then the situation was different), and have successfully used it since. Regarding comments: - Alex: 1: I'm not an expert, so I'm not going to argue with it. However I thought that if it's enforced by the government (and NIST) it would make sense. Nowadays I get this feeling that when it comes to security, people tend to lose their technical common sense and implement stuff without questioning. 2: I've just read Steve Marquess's post (and a couple of others linked from it) and I'm a little bit surprised since the FIPS funcs have been added to OpenSSL stating with version 1.0.* and they're about to be removed. Anyway, there are IT mammoths that have deals with the government (big bucks deals - involving FIPS) and use OpenSSL as a cryptography and secure socket provider (personally I consider those corporations that make use of open source software in order to get millions and give nothing back, parasites). I think when OpenSSL will publicly announce the FIPS drop, they'll will have nothing to do but chip in, as it will be extremely difficult to switch to other providers (if any - I've seen Bladelogic name mentioned,I'm not sure it will cover, also for Java apps there was RSA or EMC, which is also going out of support). 3: This is a good point, since there's no other alternative (that I know of), that uses/doesn't use FIPS. - David: bug9216 - the patch from RedHat (`usedforsecurity` parameter for md5 hash), I'm using it for 3 years; I didn't encounter the 2nd one. But both apply to hashlib. Reagrding ssl, changing FIPS mode would make a difference, e.g. when creating secure connections with certificates with (now considered weak anyway) md5 hash algorithms. Thanks everyone for reviewing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 17:43:25 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 22 Jul 2016 21:43:25 +0000 Subject: [issue27593] Deprecate sys._mercurial and create sys._git Message-ID: <1469223805.51.0.614192375682.issue27593@psf.upfronthosting.co.za> New submission from Brett Cannon: This is part of the GitHub migration. And by "deprecate" sys._mercurial I mean fill it with default values (https://www.python.org/dev/peps/pep-0512/#deprecate-sys-mercurial). ---------- components: Library (Lib) messages: 271037 nosy: brett.cannon priority: normal severity: normal status: open title: Deprecate sys._mercurial and create sys._git _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 18:32:06 2016 From: report at bugs.python.org (ap) Date: Fri, 22 Jul 2016 22:32:06 +0000 Subject: [issue27594] Assertion failure when running "test_ast" tests with coverage. Message-ID: <1469226726.58.0.53789092151.issue27594@psf.upfronthosting.co.za> New submission from ap: This is with a build of the default branch on OS X 10.11.6: $ hg identify fada654c5f72 tip $ ./python.exe --version Python 3.6.0a3+ $ The "test_ast" tests appear to run fine without coverage tracking enabled: $ ./python.exe -m test test_ast Run tests sequentially 0:00:00 [1/1] test_ast 1 test OK. Total duration: 0:00:07 $ But when coverage tracking is enabled, an assertion fails: $ ./python.exe -m test --coverage -D`pwd`/coverage_data test_ast Run tests sequentially 0:00:00 [1/1] test_ast Assertion failed: (line > 0), function _PyCode_CheckLineNumber, file Objects/codeobject.c, line 717. Fatal Python error: Aborted Current thread 0x00007fff76279000 (most recent call first): File "test", line 0 in File "/python-dev/cpython/Lib/test/test_ast.py", line 559 in test_level_as_none File "/python-dev/cpython/Lib/unittest/case.py", line 600 in run File "/python-dev/cpython/Lib/unittest/case.py", line 648 in __call__ File "/python-dev/cpython/Lib/unittest/suite.py", line 122 in run File "/python-dev/cpython/Lib/unittest/suite.py", line 84 in __call__ File "/python-dev/cpython/Lib/unittest/suite.py", line 122 in run File "/python-dev/cpython/Lib/unittest/suite.py", line 84 in __call__ File "/python-dev/cpython/Lib/unittest/suite.py", line 122 in run File "/python-dev/cpython/Lib/unittest/suite.py", line 84 in __call__ File "/python-dev/cpython/Lib/test/support/__init__.py", line 1709 in run File "/python-dev/cpython/Lib/test/support/__init__.py", line 1810 in _run_suite File "/python-dev/cpython/Lib/test/support/__init__.py", line 1844 in run_unittest File "/python-dev/cpython/Lib/test/libregrtest/runtest.py", line 179 in test_runner File "/python-dev/cpython/Lib/test/libregrtest/runtest.py", line 180 in runtest_inner File "/python-dev/cpython/Lib/test/libregrtest/runtest.py", line 144 in runtest File "", line 1 in File "/python-dev/cpython/Lib/trace.py", line 469 in runctx File "/python-dev/cpython/Lib/test/libregrtest/main.py", line 330 in run_tests_sequential File "/python-dev/cpython/Lib/test/libregrtest/main.py", line 406 in run_tests File "/python-dev/cpython/Lib/test/libregrtest/main.py", line 466 in _main File "/python-dev/cpython/Lib/test/libregrtest/main.py", line 446 in main File "/python-dev/cpython/Lib/test/libregrtest/main.py", line 508 in main File "/python-dev/cpython/Lib/test/__main__.py", line 2 in File "/python-dev/cpython/Lib/runpy.py", line 85 in _run_code File "/python-dev/cpython/Lib/runpy.py", line 184 in _run_module_as_main Abort trap: 6 $ ---------- components: Tests messages: 271038 nosy: ap priority: normal severity: normal status: open title: Assertion failure when running "test_ast" tests with coverage. versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 18:45:14 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 22 Jul 2016 22:45:14 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <1469227514.58.0.379224427526.issue24773@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I am posting the final version of the patch complete with the NEWS entry. Compared with the previous patch, issue24773-final.diff contains a fix for a reference leak. I would like to use this opportunity to thank Zachary Ware for providing a Windows VM with a complete Python development setup, as well as everyone who participated in PEP 495 discussions and code reviews. ---------- Added file: http://bugs.python.org/file43836/issue24773-final.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 18:47:13 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 Jul 2016 22:47:13 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <20160722224706.20011.35299.226ECDCF@psf.io> Roundup Robot added the comment: New changeset 7c0917670ab8 by Alexander Belopolsky in branch 'default': Closes issue #24773: Implement PEP 495 (Local Time Disambiguation). https://hg.python.org/cpython/rev/7c0917670ab8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 18:52:34 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 22 Jul 2016 22:52:34 +0000 Subject: [issue27595] Document PEP 495 (Local Time Disambiguation) features Message-ID: <1469227954.48.0.374414498519.issue27595@psf.upfronthosting.co.za> New submission from Alexander Belopolsky: PEP 495 has been implemented in issue 24773. This issue is created to track the necessary changes to the datetime module documentation. ---------- assignee: belopolsky components: Documentation messages: 271041 nosy: akira, belopolsky, haypo, stub, tim.peters priority: normal severity: normal stage: needs patch status: open title: Document PEP 495 (Local Time Disambiguation) features type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 18:53:22 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 22 Jul 2016 22:53:22 +0000 Subject: [issue27595] Document PEP 495 (Local Time Disambiguation) features In-Reply-To: <1469227954.48.0.374414498519.issue27595@psf.upfronthosting.co.za> Message-ID: <1469228002.65.0.101811278059.issue27595@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- dependencies: +Implement PEP 495 (Local Time Disambiguation) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 18:54:10 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 22 Jul 2016 22:54:10 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <1469228050.52.0.702468892327.issue24773@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed superseder: -> Document PEP 495 (Local Time Disambiguation) features _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 19:55:28 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 22 Jul 2016 23:55:28 +0000 Subject: [issue27587] Issues, reported by PVS-Studio static analyzer In-Reply-To: <1469172132.31.0.293406285451.issue27587@psf.upfronthosting.co.za> Message-ID: <1469231728.28.0.842843856353.issue27587@psf.upfronthosting.co.za> Martin Panter added the comment: Christian Heimes posted a patch for _PyState_AddModule() on Python-dev: https://marc.info/?l=python-dev&m=146922730716425&w=2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 19:56:19 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 22 Jul 2016 23:56:19 +0000 Subject: [issue27579] Add a tutorial for AsyncIO in the documentation In-Reply-To: <1469222660.13.0.122929704593.issue27579@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: The tutorial is happening but outside Python: https://github.com/asyncio-doc/asyncio-doc I suggest to now close this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 20:03:47 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 23 Jul 2016 00:03:47 +0000 Subject: [issue27591] multiprocessing: Possible uninitialized pointer use in Windows builds In-Reply-To: <1469200359.36.0.370469252953.issue27591@psf.upfronthosting.co.za> Message-ID: <1469232227.36.0.122448699414.issue27591@psf.upfronthosting.co.za> Berker Peksag added the comment: Here is an updated patch. Thanks, Victor. ---------- Added file: http://bugs.python.org/file43837/issue27591_v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 20:06:51 2016 From: report at bugs.python.org (STINNER Victor) Date: Sat, 23 Jul 2016 00:06:51 +0000 Subject: [issue27591] multiprocessing: Possible uninitialized pointer use in Windows builds In-Reply-To: <1469200359.36.0.370469252953.issue27591@psf.upfronthosting.co.za> Message-ID: <1469232411.8.0.987190552603.issue27591@psf.upfronthosting.co.za> STINNER Victor added the comment: issue27591_v2.diff LGTM except of a minor comment (PEP 7!) on the review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 20:15:07 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 23 Jul 2016 00:15:07 +0000 Subject: [issue27587] Issues, reported by PVS-Studio static analyzer In-Reply-To: <1469172132.31.0.293406285451.issue27587@psf.upfronthosting.co.za> Message-ID: <1469232907.54.0.56214967393.issue27587@psf.upfronthosting.co.za> Martin Panter added the comment: Also on python-dev, Chris Angelico pointed out that the _elementtree.c case is a false positive. So that would leave the binascii one, which I think is worth simpifying, but is probably not very serious. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 23:08:14 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 23 Jul 2016 03:08:14 +0000 Subject: [issue27493] logging module fails with unclear error when supplied a (Posix)Path In-Reply-To: <1468314884.39.0.604549697605.issue27493@psf.upfronthosting.co.za> Message-ID: <1469243294.48.0.643433277224.issue27493@psf.upfronthosting.co.za> Martin Panter added the comment: Windows fails the test: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/7989/steps/test/logs/stdio ====================================================================== ERROR: test_path_objects (test.test_logging.HandlerTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_logging.py", line 599, in test_path_objects os.unlink(fn) PermissionError: [WinError 32] The process cannot access the file because it is being used by another process: 'C:\\Users\\Buildbot\\AppData\\Local\\Temp\\tmplffg6d26' ---------- nosy: +martin.panter status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 23:09:59 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 23 Jul 2016 03:09:59 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <1469243399.95.0.33235800131.issue24773@psf.upfronthosting.co.za> Martin Panter added the comment: This upset the buildbots: http://buildbot.python.org/all/builders/PPC64%20Fedora%203.x/builds/1259/steps/test/logs/stdio ====================================================================== FAIL: test_all (test.datetimetester.ZoneInfoCompleteTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/test/datetimetester.py", line 4784, in test_all self.assertTrue(result.wasSuccessful(), name + ' ' + suffix) AssertionError: False is not true : Africa/El_Aaiun system_transitions ---------- nosy: +martin.panter status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 23:15:00 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 23 Jul 2016 03:15:00 +0000 Subject: [issue27577] Make implementation and doc of tuple and list more compliant In-Reply-To: <1469002642.37.0.996165914529.issue27577@psf.upfronthosting.co.za> Message-ID: <1469243700.07.0.544598670004.issue27577@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This should have been changed in Python 3.0 which is when were allowed to make non-backwards compatible changes. Since it wasn't, we have to live this mild annoyance forever (you can't change it without breaking somebody's working code somewhere). I'm open to a small documentation patch that indicates that the actual keyword is "sequence" but the main entry of list(iterable) should remain because it is more descriptive of the kind of argument that is allowed. ---------- assignee: -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 00:02:10 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jul 2016 04:02:10 +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: <20160723040206.6854.92629.F03D20F2@psf.io> Roundup Robot added the comment: New changeset bd61bcd9bee8 by Martin Panter in branch '3.5': Issue #27130: Fix handling of buffers exceeding UINT_MAX in ?zlib? module https://hg.python.org/cpython/rev/bd61bcd9bee8 New changeset bd556f748cf8 by Martin Panter in branch 'default': Issue #27130: Merge zlib 64-bit fixes from 3.5 https://hg.python.org/cpython/rev/bd556f748cf8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 00:13:47 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jul 2016 04:13:47 +0000 Subject: [issue27591] multiprocessing: Possible uninitialized pointer use in Windows builds In-Reply-To: <1469200359.36.0.370469252953.issue27591@psf.upfronthosting.co.za> Message-ID: <20160723041344.21137.3080.BB790502@psf.io> Roundup Robot added the comment: New changeset da955567d7c7 by Berker Peksag in branch '3.5': Issue #27591: Set sigint_event to NULL if _PyOS_IsMainThread() returns false https://hg.python.org/cpython/rev/da955567d7c7 New changeset d5f796da4013 by Berker Peksag in branch 'default': Issue #27591: Merge from 3.5 https://hg.python.org/cpython/rev/d5f796da4013 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 00:15:16 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jul 2016 04:15:16 +0000 Subject: [issue27493] logging module fails with unclear error when supplied a (Posix)Path In-Reply-To: <1468314884.39.0.604549697605.issue27493@psf.upfronthosting.co.za> Message-ID: <20160723041515.6924.63718.9DE085F1@psf.io> Roundup Robot added the comment: New changeset 5424252ce174 by Berker Peksag in branch 'default': Issue #27493: Fix test_path_objects under Windows https://hg.python.org/cpython/rev/5424252ce174 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 00:16:16 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 23 Jul 2016 04:16:16 +0000 Subject: [issue27591] multiprocessing: Possible uninitialized pointer use in Windows builds In-Reply-To: <1469200359.36.0.370469252953.issue27591@psf.upfronthosting.co.za> Message-ID: <1469247376.19.0.29505195848.issue27591@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks! I should read PEP 7 again :) ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 00:30:12 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jul 2016 04:30:12 +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: <20160723043009.59781.12172.17B15722@psf.io> Roundup Robot added the comment: New changeset 2192edcfea02 by Martin Panter in branch '2.7': Issue #27130: Fix handling of buffers exceeding (U)INT_MAX in ?zlib? module https://hg.python.org/cpython/rev/2192edcfea02 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 00:32:17 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jul 2016 04:32:17 +0000 Subject: [issue13849] Add tests for NUL checking in certain strs In-Reply-To: <1327370754.29.0.66468771639.issue13849@psf.upfronthosting.co.za> Message-ID: <20160723043215.11141.84806.7F711348@psf.io> Roundup Robot added the comment: New changeset 899f06eb390c by Berker Peksag in branch '3.5': Issue #13849: Add tests for null byte checking in test_genericpath https://hg.python.org/cpython/rev/899f06eb390c New changeset 9498736fbd8f by Berker Peksag in branch 'default': Issue #13849: Merge from 3.5 https://hg.python.org/cpython/rev/9498736fbd8f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 00:35:17 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 23 Jul 2016 04:35:17 +0000 Subject: [issue13849] Add tests for NUL checking in certain strs In-Reply-To: <1327370754.29.0.66468771639.issue13849@psf.upfronthosting.co.za> Message-ID: <1469248517.82.0.76464333014.issue13849@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for your review, Victor. I don't care about 2.7 at this point so I went with 3.5+ :) ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 00:35:47 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 23 Jul 2016 04:35:47 +0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1469248547.17.0.705402368367.issue1621@psf.upfronthosting.co.za> Martin Panter added the comment: Apart from the empty ?if? statement style (see review), tuple_and_list.patch looks good to me. I understand the patches from 2011 and earlier have all been committed (correct me if I missed something). Here is another patch fixing a 64-bit overflow in _thread, detected by the test_timeout() method in test_threading: Modules/_threadmodule.c:59:17: runtime error: signed integer overflow: 6236628528058 + 9223372036000000000 cannot be represented in type 'long int' ---------- Added file: http://bugs.python.org/file43838/thread.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 01:09:51 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 23 Jul 2016 05:09:51 +0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1469250591.29.0.335961253279.issue1621@psf.upfronthosting.co.za> Martin Panter added the comment: Perhaps we should add a test for the __length_hint__() overflow to tuple_and_list.patch: >>> a = [1,2,3,4] >>> import sys >>> class B: ... def __iter__(s): return s ... def __next__(s): raise StopIteration() ... def __length_hint__(s): return sys.maxsize ... >>> a.extend(B()) Objects/listobject.c:844:8: runtime error: signed integer overflow: 4 + 2147483647 cannot be represented in type 'int' array-size.patch fixes the ctypes array size overflow (including a test). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 01:17:08 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 23 Jul 2016 05:17:08 +0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1469251028.65.0.738108937192.issue1621@psf.upfronthosting.co.za> Changes by Martin Panter : Added file: http://bugs.python.org/file43839/array-size.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 01:21:05 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 23 Jul 2016 05:21:05 +0000 Subject: [issue13849] Add tests for NUL checking in certain strs In-Reply-To: <1327370754.29.0.66468771639.issue13849@psf.upfronthosting.co.za> Message-ID: <1469251265.49.0.099991900558.issue13849@psf.upfronthosting.co.za> Martin Panter added the comment: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.5/builds/1072/steps/test/logs/stdio ====================================================================== FAIL: test_null_bytes (test.test_genericpath.TestGenericTest) (attr='getsize') ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\buildbot.python.org\3.5.kloth-win64\build\lib\test\test_genericpath.py", line 285, in test_null_bytes self.assertEqual(str(cm.exception), 'embedded null byte') AssertionError: 'stat: embedded null character' != 'embedded null byte' - stat: embedded null character + embedded null byte ---------- nosy: +martin.panter status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 01:28:44 2016 From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=) Date: Sat, 23 Jul 2016 05:28:44 +0000 Subject: [issue27539] negative Fraction ** negative int not normalized In-Reply-To: <1468740731.71.0.38394274484.issue27539@psf.upfronthosting.co.za> Message-ID: <1469251724.62.0.194818518916.issue27539@psf.upfronthosting.co.za> Vedran ?a?i? added the comment: The .diff format of patch for fractions.py is at http://bugs.python.org/file43786/TwCVpiFp.diff The line numbers in it are the newest I could get (from https://hg.python.org/cpython/file/default/Lib/fractions.py). I would also add the test I was talking about (Fraction(-1, 2) ** -1), if I knew where to do it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 01:43:09 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jul 2016 05:43:09 +0000 Subject: [issue13849] Add tests for NUL checking in certain strs In-Reply-To: <1327370754.29.0.66468771639.issue13849@psf.upfronthosting.co.za> Message-ID: <20160723054306.49570.97622.1406525E@psf.io> Roundup Robot added the comment: New changeset 9e997c8f4876 by Berker Peksag in branch '3.5': Issue #13849: Fix test_null_bytes under Windows https://hg.python.org/cpython/rev/9e997c8f4876 New changeset a28abe83cf5c by Berker Peksag in branch 'default': Issue #13849: Merge from 3.5 https://hg.python.org/cpython/rev/a28abe83cf5c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 02:02:44 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 23 Jul 2016 06:02:44 +0000 Subject: [issue27581] Fix overflow check in PySequence_Tuple In-Reply-To: <1469079408.21.0.622161481276.issue27581@psf.upfronthosting.co.za> Message-ID: <1469253764.52.0.0115221664258.issue27581@psf.upfronthosting.co.za> Martin Panter added the comment: Hmm maybe this patch is okay. We are assuming size_t will fit more than PY_SSIZE_T_MAX. The alternatives I can think of would be equally ugly: /* Risks loss of precision, e.g. 64 bit integer from floating point */ if (n < (Py_ssize_t)(PY_SSIZE_T_MAX / 1.25) - 10)) /* PY_SSIZE_T_MAX * 4/5 - 10 without loss of precision or overflowing */ if (n < PY_SSIZE_T_MAX / 5 * 4 + PY_SSIZE_T_MAX % 5 * 4 / 5 - 10) ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 02:48:05 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 23 Jul 2016 06:48:05 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <1469256485.58.0.348893049202.issue24773@psf.upfronthosting.co.za> Martin Panter added the comment: FYI, other failures that may be different problems: http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/4930/steps/test/logs/stdio Timeout (0:15:00)! Thread 0x00007fff71296cc0 (most recent call first): File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/datetime.py", line 447 in __new__ File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/datetime.py", line 1444 in _fromtimestamp File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/datetime.py", line 1467 in utcfromtimestamp File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/datetimetester.py", line 4637 in transitions File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/datetimetester.py", line 4659 in folds File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/datetimetester.py", line 4688 in test_folds File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/case.py", line 600 in run File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/datetimetester.py", line 4783 in test_all http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%203.x/builds/11008/steps/test/logs/stdio ====================================================================== ERROR: test_folds (test.datetimetester.IranTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/datetimetester.py", line 4680, in setUp self.tz = ZoneInfo.fromname(self.zonename) File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/datetimetester.py", line 4514, in fromname with open(path, 'rb') as f: FileNotFoundError: [Errno 2] No such file or directory: '/usr/share/zoneinfo/Iran' http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/13492/steps/test/logs/stdio (I also get this OverflowError for a 32-bit ABI build) ====================================================================== ERROR: test_timestamp_naive (test.datetimetester.TestSubclassDateTime) ---------------------------------------------------------------------- Traceback (most recent call last): File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/support/__init__.py", line 1563, in inner return func(*args, **kwds) File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/datetimetester.py", line 1931, in test_timestamp_naive self.assertEqual(self.theclass.fromtimestamp(s), t) OverflowError: timestamp out of range for platform time_t ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 03:46:33 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 23 Jul 2016 07:46:33 +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: <1469259993.17.0.97881387859.issue27130@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks Xiang for your work on this, and Klamann for the report. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 04:20:03 2016 From: report at bugs.python.org (Klamann) Date: Sat, 23 Jul 2016 08:20: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: <1469262003.21.0.494031216135.issue27130@psf.upfronthosting.co.za> Klamann added the comment: Thanks Xiang and Martin for solving this, you guys are awesome :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 04:40:33 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 23 Jul 2016 08:40:33 +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: <1469263233.93.0.343377989342.issue24291@psf.upfronthosting.co.za> Martin Panter added the comment: The bug should no longer be a problem in 3.6, as long as my change for Issue 26721 survives. Here is an updated patch against 3.5. ---------- versions: -Python 3.6 Added file: http://bugs.python.org/file43840/wfile-partial.v5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 05:24:11 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 23 Jul 2016 09:24:11 +0000 Subject: [issue27539] negative Fraction ** negative int not normalized In-Reply-To: <1468740731.71.0.38394274484.issue27539@psf.upfronthosting.co.za> Message-ID: <1469265851.28.0.304186067657.issue27539@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Tests for fractions are in Lib/test/test_fractions.py. In necessary, post the new code in a message. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 06:38:52 2016 From: report at bugs.python.org (Ronald Oussoren) Date: Sat, 23 Jul 2016 10:38:52 +0000 Subject: [issue15661] OS X installer packages should be signed for OS X 10.8 Gatekeeper feature In-Reply-To: <1345013707.82.0.343684011424.issue15661@psf.upfronthosting.co.za> Message-ID: <1469270332.89.0.0737426368468.issue15661@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Ned, Can this issue be closed? The current installers on www.python.org are signed. Ronald ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 06:49:43 2016 From: report at bugs.python.org (Ronald Oussoren) Date: Sat, 23 Jul 2016 10:49:43 +0000 Subject: [issue27596] Build failure with Xcode 8 beta on OSX 10.11 Message-ID: <1469270983.6.0.702583698233.issue27596@psf.upfronthosting.co.za> New submission from Ronald Oussoren: I just noticed that building the Xcode 8 beta 2 on OSX 10.11 results in a link failure of the python binary. Based on a quick glance at the error (before switching back to Xcode 7): 1) macOS 10.12 appears to have a getentropy function that's detected by the configure script. 2) For some reason the build environment for configure and the actual build are different resulting in the link error. Even with the link failure fixed the build will fail because getentropy isn't present on 10.11 and hence the binary won't work on 10.11. IMHO it would be worthwhile to at least create a patch that makes it possible to use Xcode 8 for building on OSX 10.11, and better yet deploy on older OSX releases. Based on the invasiveness of such a patch we could discuss if the patch would be acceptable for merging. ---------- assignee: ronaldoussoren components: Macintosh messages: 271069 nosy: ned.deily, ronaldoussoren priority: low severity: normal stage: needs patch status: open title: Build failure with Xcode 8 beta on OSX 10.11 type: compile error versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 06:50:48 2016 From: report at bugs.python.org (Ronald Oussoren) Date: Sat, 23 Jul 2016 10:50:48 +0000 Subject: [issue27596] Build failure with Xcode 8 beta on OSX 10.11 In-Reply-To: <1469270983.6.0.702583698233.issue27596@psf.upfronthosting.co.za> Message-ID: <1469271048.52.0.85783279174.issue27596@psf.upfronthosting.co.za> Ronald Oussoren added the comment: P.S. This issue is mostly a reminder for myself, Xcode 8 is still in beta and hence patches to CPython to support it are IMHO still out of scope for merging at this time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 06:56:32 2016 From: report at bugs.python.org (Ronald Oussoren) Date: Sat, 23 Jul 2016 10:56:32 +0000 Subject: [issue18049] Re-enable threading test on OSX In-Reply-To: <1369405666.05.0.54874731136.issue18049@psf.upfronthosting.co.za> Message-ID: <1469271392.54.0.728095305917.issue18049@psf.upfronthosting.co.za> Ronald Oussoren added the comment: The patch increases the stack size for threads to slightly less than size as is used for the main thread, see this fragment in configure.ac: # Issue #18075: the default maximum stack size (8MBytes) is too # small for the default recursion limit. Increase the stack size # to ensure that tests don't crash LINKFORSHARED="-Wl,-stack_size,1000000 $LINKFORSHARED" Maybe the patch should be updated to use the same size? The disadvantage of any increase of size is that this reduces the number of threads that can be used, in particular for 32-bit builds (64-bit builds have more than enough address space) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 06:58:10 2016 From: report at bugs.python.org (Ram Rachum) Date: Sat, 23 Jul 2016 10:58:10 +0000 Subject: [issue27597] Add usage examples for TracebackException, StackSummary and FrameSummary Message-ID: <1469271490.04.0.794512221992.issue27597@psf.upfronthosting.co.za> New submission from Ram Rachum: I saw these new interesting classes in the `traceback` docs, but if I were shown an example of how they are used, I might get inspired to use them in my own code. ---------- assignee: docs at python components: Documentation messages: 271072 nosy: cool-RR, docs at python priority: normal severity: normal status: open title: Add usage examples for TracebackException, StackSummary and FrameSummary type: enhancement versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 07:24:26 2016 From: report at bugs.python.org (koobs) Date: Sat, 23 Jul 2016 11:24:26 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <1469273066.68.0.0975314570338.issue24773@psf.upfronthosting.co.za> koobs added the comment: Also failing on all freebsd buildbots, all tests failing with: FileNotFoundError: [Errno 2] No such file or directory: '/usr/share/zoneinfo/Iran' ---------- nosy: +koobs resolution: fixed -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 09:13:18 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 23 Jul 2016 13:13:18 +0000 Subject: [issue27506] make bytes/bytearray delete a keyword argument In-Reply-To: <1468403337.28.0.33019551319.issue27506@psf.upfronthosting.co.za> Message-ID: <1469279598.95.0.879973885269.issue27506@psf.upfronthosting.co.za> Martin Panter added the comment: This patch is what I had in mind for setting the documented default as delete=b'', but using NULL internally. I also changed it to allow the table argument to be omitted. We can change the documentation accordingly. These are just suggestions; use either or both aspects as you please :) ---------- Added file: http://bugs.python.org/file43841/table-optional-delete-empty.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 09:20:44 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 23 Jul 2016 13:20:44 +0000 Subject: [issue13849] Add tests for NUL checking in certain strs In-Reply-To: <1327370754.29.0.66468771639.issue13849@psf.upfronthosting.co.za> Message-ID: <1469280044.35.0.913425094643.issue13849@psf.upfronthosting.co.za> Martin Panter added the comment: Buildbots seem happier now ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 09:40:35 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 23 Jul 2016 13:40:35 +0000 Subject: [issue27581] Fix overflow check in PySequence_Tuple In-Reply-To: <1469079408.21.0.622161481276.issue27581@psf.upfronthosting.co.za> Message-ID: <1469281235.46.0.49294565836.issue27581@psf.upfronthosting.co.za> Xiang Zhang added the comment: I'd prefer the size_t method. The others seems to make the logic not clear. I've seen some codes using size_t to do overflow checking, such as https://hg.python.org/cpython/file/tip/Python/bltinmodule.c#l1954. There are more if you use a simple grep. So I think the logic is okay. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 09:43:54 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 23 Jul 2016 13:43:54 +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: <1469281434.5.0.566012209469.issue27130@psf.upfronthosting.co.za> Xiang Zhang added the comment: Thanks Martin too. Nobody than me knows how much work you have done to this. :) I could have made it better at first. :( Sorry for the noise to everyone. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 09:44:31 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 23 Jul 2016 13:44:31 +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: <1469281470.99.0.189906473352.issue27130@psf.upfronthosting.co.za> Xiang Zhang added the comment: Thanks Martin too. Nobody than me knows how much work you have done to this. :) I could have made it better at first. :( Sorry for the noise to everyone. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 09:47:15 2016 From: report at bugs.python.org (Christian Heimes) Date: Sat, 23 Jul 2016 13:47:15 +0000 Subject: [issue27587] Issues, reported by PVS-Studio static analyzer In-Reply-To: <1469172132.31.0.293406285451.issue27587@psf.upfronthosting.co.za> Message-ID: <1469281635.21.0.28823905924.issue27587@psf.upfronthosting.co.za> Christian Heimes added the comment: Hi Pavel, The issues in ASN1_PRINTABLE_type() [N2], BN_mask_bits() [N4 bn_lib.c, digest.c, evp_enc.c], dh_cms_set_peerkey() [N5, dh_ameth.c] and cms_env_set_version() [N6, cms_env.c] are all OpenSSL issues and should be reported to OpenSSL. The Windows build system also builds a static version of OpenSSL and a couple of other dependencies. ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 09:57:36 2016 From: report at bugs.python.org (Chris Angelico) Date: Sat, 23 Jul 2016 13:57:36 +0000 Subject: [issue27587] Issues, reported by PVS-Studio static analyzer In-Reply-To: <1469172132.31.0.293406285451.issue27587@psf.upfronthosting.co.za> Message-ID: <1469282256.48.0.346889023692.issue27587@psf.upfronthosting.co.za> Changes by Chris Angelico : ---------- nosy: +Rosuav _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 10:47:54 2016 From: report at bugs.python.org (Julien) Date: Sat, 23 Jul 2016 14:47:54 +0000 Subject: [issue26462] Patch to enhance literal block language declaration In-Reply-To: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za> Message-ID: <1469285274.56.0.191330793761.issue26462@psf.upfronthosting.co.za> Julien added the comment: Hi, Look like it has not been merged, is there something I can do to help with this? Bests ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 10:57:10 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 23 Jul 2016 14:57:10 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1469273066.68.0.0975314570338.issue24773@psf.upfronthosting.co.za> Message-ID: <659E61D4-9B2A-4AA2-AC43-1DF8B9B940D3@gmail.com> Alexander Belopolsky added the comment: Does anyone know whether zoneinfo is installed on FreeBSD buildbot? If it is, at which path? > On Jul 23, 2016, at 7:24 AM, koobs wrote: > > > koobs added the comment: > > Also failing on all freebsd buildbots, all tests failing with: > > FileNotFoundError: [Errno 2] No such file or directory: '/usr/share/zoneinfo/Iran' > > ---------- > nosy: +koobs > resolution: fixed -> > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 11:02:27 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jul 2016 15:02:27 +0000 Subject: [issue27469] Unicode filename gets crippled on Windows when drag and drop In-Reply-To: <1467992332.72.0.0240653508758.issue27469@psf.upfronthosting.co.za> Message-ID: <20160723150223.19925.68990.75214122@psf.io> Roundup Robot added the comment: New changeset 3005fc6cff8a by Steve Dower in branch '3.5': Issue #27469: Adds a shell extension to the launcher so that drag and drop works correctly. https://hg.python.org/cpython/rev/3005fc6cff8a New changeset f56adb9800fa by Steve Dower in branch 'default': Issue #27469: Adds a shell extension to the launcher so that drag and drop works correctly. https://hg.python.org/cpython/rev/f56adb9800fa ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 11:04:44 2016 From: report at bugs.python.org (Steve Dower) Date: Sat, 23 Jul 2016 15:04:44 +0000 Subject: [issue27469] Unicode filename gets crippled on Windows when drag and drop In-Reply-To: <1467992332.72.0.0240653508758.issue27469@psf.upfronthosting.co.za> Message-ID: <1469286284.67.0.0830410187029.issue27469@psf.upfronthosting.co.za> Steve Dower added the comment: Fixed. This should get out into the wild first with 3.6.0a4, and then 3.5.3[rc1] ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 11:06:50 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 23 Jul 2016 15:06:50 +0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1469286410.71.0.204397590998.issue1621@psf.upfronthosting.co.za> Xiang Zhang added the comment: Change tuple_and_list.patch with empty curly braces. I don't add the test for __length_hint__. According to the comment, when overflow happens, it is either ignored or a MemoryError will finally be raised. I am not willing to test a MemoryError in this case. BTW, how do you get the error? ---------- Added file: http://bugs.python.org/file43842/tuple_and_list_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 11:16:36 2016 From: report at bugs.python.org (Emanuel Barry) Date: Sat, 23 Jul 2016 15:16:36 +0000 Subject: [issue26823] Shrink recursive tracebacks In-Reply-To: <1461292585.22.0.159887337407.issue26823@psf.upfronthosting.co.za> Message-ID: <1469286996.29.0.282401843933.issue26823@psf.upfronthosting.co.za> Emanuel Barry added the comment: After discussing with someone, I realized that the tests actually test the Python implementation twice, and never the C implementation (since I use traceback.print_exc() to "test" the C implementation). I don't think it's possible to both catch the output from the C implementation and prevent it from exiting out of the function prematurely, but if anyone knows how to do that, be my guest! In the meantime, I'm going to mess about with _testcapi and see if I can add something there to help with this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 11:17:01 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jul 2016 15:17:01 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <20160723151658.49297.11127.62786326@psf.io> Roundup Robot added the comment: New changeset e72aab080165 by Alexander Belopolsky in branch 'default': Issue 24773: Make zoneinfo tests more robust. https://hg.python.org/cpython/rev/e72aab080165 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 11:36:42 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 23 Jul 2016 15:36:42 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <1469288202.91.0.327035805734.issue24773@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > AssertionError: False is not true : Africa/El_Aaiun system_transitions This may be an indication of misconfigured zoneinfo on the buildbot. What system_transitions test does is compare the results obtained from the system timezone computations to the same computations using an explicitly loaded timezone. This may fail if /usr/share/zoneinfo exists, but the system is using a different database. Is there a way to troubleshoot the buildbot short of trying a series of hg commits? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 11:46:49 2016 From: report at bugs.python.org (Brett Cannon) Date: Sat, 23 Jul 2016 15:46:49 +0000 Subject: [issue27598] Add SizedIterable to collections.abc and typing Message-ID: <1469288809.56.0.543825422436.issue27598@psf.upfronthosting.co.za> New submission from Brett Cannon: See the discussion on python-ideas entitled "An ABC representing "Iterable, Sized, Container"". ---------- components: Library (Lib) messages: 271088 nosy: brett.cannon, gvanrossum priority: normal severity: normal stage: test needed status: open title: Add SizedIterable to collections.abc and typing versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 11:50:38 2016 From: report at bugs.python.org (Emanuel Barry) Date: Sat, 23 Jul 2016 15:50:38 +0000 Subject: [issue26823] Shrink recursive tracebacks In-Reply-To: <1461292585.22.0.159887337407.issue26823@psf.upfronthosting.co.za> Message-ID: <1469289038.64.0.143319745745.issue26823@psf.upfronthosting.co.za> Emanuel Barry added the comment: Turns out there's already some functions in _testcapi that do this, great! Here's an updated patch actually testing the C implementation (and the tests pass, obviously :) ---------- Added file: http://bugs.python.org/file43843/short_tracebacks_5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 11:52:07 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 23 Jul 2016 15:52:07 +0000 Subject: [issue27506] make bytes/bytearray delete a keyword argument In-Reply-To: <1468403337.28.0.33019551319.issue27506@psf.upfronthosting.co.za> Message-ID: <1469289127.36.0.530465834409.issue27506@psf.upfronthosting.co.za> Xiang Zhang added the comment: LGTM. Using b'' instead of the None as the default value of *delete* looks better since it doesn't break backwards compatibility. As for the first argument optional or not, actually it's both okay. You have changed the doc accordingly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 11:55:18 2016 From: report at bugs.python.org (Stefan Krah) Date: Sat, 23 Jul 2016 15:55:18 +0000 Subject: [issue26974] Crash in Decimal.from_float In-Reply-To: <1462684427.76.0.86950702335.issue26974@psf.upfronthosting.co.za> Message-ID: <1469289318.69.0.128013732165.issue26974@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 12:02:44 2016 From: report at bugs.python.org (Brett Cannon) Date: Sat, 23 Jul 2016 16:02:44 +0000 Subject: [issue27594] Assertion failure when running "test_ast" tests with coverage. In-Reply-To: <1469226726.58.0.53789092151.issue27594@psf.upfronthosting.co.za> Message-ID: <1469289764.5.0.140356162604.issue27594@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +benjamin.peterson, georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 12:19:00 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 23 Jul 2016 16:19:00 +0000 Subject: [issue27577] Make implementation and doc of tuple and list more compliant In-Reply-To: <1469002642.37.0.996165914529.issue27577@psf.upfronthosting.co.za> Message-ID: <1469290740.3.0.0128732379345.issue27577@psf.upfronthosting.co.za> Xiang Zhang added the comment: Thanks for replies. Attach a small documentation patch. ---------- keywords: +patch Added file: http://bugs.python.org/file43844/tuple_and_list_parameter_name.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 12:31:32 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 Jul 2016 16:31:32 +0000 Subject: [issue27599] Buffer overrun in binascii Message-ID: <1469291492.89.0.37008226611.issue27599@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: There is reading one byte past the end of the input buffer in binascii.b2a_qp(). Following example shows the behavior difference depending on the value of this byte: >>> binascii.b2a_qp(memoryview(b'..')[:-1]) b'.' >>> binascii.b2a_qp(bytes(memoryview(b'..')[:-1])) b'=2E' In rare cases (memoryview of mmap object or custom buffer) this can cause a segfault. Maybe there are similar issues with other binascii functions (not checked). ---------- components: Extension Modules messages: 271092 nosy: serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Buffer overrun in binascii type: behavior versions: Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 12:51:08 2016 From: report at bugs.python.org (Thanatas Pongpanotkorn) Date: Sat, 23 Jul 2016 16:51:08 +0000 Subject: [issue27600] None Message-ID: <1469292668.75.0.484494556791.issue27600@psf.upfronthosting.co.za> Changes by Thanatas Pongpanotkorn : ---------- hgrepos: 350 nosy: xaxadmin priority: normal severity: normal status: open title: None _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 12:59:57 2016 From: report at bugs.python.org (Thanatas Pongpanotkorn) Date: Sat, 23 Jul 2016 16:59:57 +0000 Subject: [issue27600] None Message-ID: <1469293197.69.0.51956369788.issue27600@psf.upfronthosting.co.za> Changes by Thanatas Pongpanotkorn : ---------- hgrepos: -350 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 13:01:24 2016 From: report at bugs.python.org (Thanatas Pongpanotkorn) Date: Sat, 23 Jul 2016 17:01:24 +0000 Subject: [issue27600] None Message-ID: <1469293284.4.0.876233867558.issue27600@psf.upfronthosting.co.za> Changes by Thanatas Pongpanotkorn : ---------- components: +Build, XML, email nosy: +barry, r.david.murray versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 13:04:43 2016 From: report at bugs.python.org (Emanuel Barry) Date: Sat, 23 Jul 2016 17:04:43 +0000 Subject: [issue27600] Spam Message-ID: <1469293483.58.0.932981401693.issue27600@psf.upfronthosting.co.za> Changes by Emanuel Barry : ---------- components: -Build, XML, email nosy: -barry, r.david.murray, xaxadmin resolution: -> not a bug stage: -> resolved status: open -> closed title: None -> Spam versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 13:30:26 2016 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 23 Jul 2016 17:30:26 +0000 Subject: [issue27271] asyncio lost udp packets In-Reply-To: <1465417059.51.0.620953300582.issue27271@psf.upfronthosting.co.za> Message-ID: <1469295026.64.0.578406781711.issue27271@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Can you prove that packets may be lost even in UNIX sockets ? > (it is not related to this task directly) Quoting wiki: """Like named pipes, Unix domain sockets support transmission of a reliable stream of bytes (SOCK_STREAM, compare to TCP). In addition, they support ordered and reliable transmission of datagrams (SOCK_SEQPACKET), or unordered and unreliable transmission of datagrams (SOCK_DGRAM, compare to UDP).""" I'm also sure I saw that UDP can never be used as a reliable protocol in Stevens books. (I'm sure you can google this too.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 13:41:08 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 23 Jul 2016 17:41:08 +0000 Subject: [issue27598] Add SizedIterable to collections.abc and typing In-Reply-To: <1469288809.56.0.543825422436.issue27598@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I'm thinking that it should be called Collection after all. --Guido (mobile) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 14:05:29 2016 From: report at bugs.python.org (David Su) Date: Sat, 23 Jul 2016 18:05:29 +0000 Subject: [issue27575] dict viewkeys intersection slow for large dicts In-Reply-To: <1468950707.74.0.640405379684.issue27575@psf.upfronthosting.co.za> Message-ID: <1469297129.91.0.759319864373.issue27575@psf.upfronthosting.co.za> David Su added the comment: I am trying to implement the following algorithm: http://blog.faroo.com/2012/06/07/improved-edit-distance-based-spelling-correction/ This algorithm is used for fast nearest neighbor queries for spell correction. Given a corpus of strings, for each string s, I generate all subsequences (Note: subsequence, not substring) of that string length (len(n) - k), call that subsequence t, where k is a tunable parameter. Then, I create a dict mapping the subsequences t to the original string s. This process creates a very large dict from a relatively small corpus. For example, my corpus of ~500k strings blew up to a dict of ~10M keys, with k=3. Then, for a query string q, you generate all subsequences of (len(q) - k), and perform an intersection with the keys of the dict. Then, the values of the dict corresponding to the key intersection will be possible misspelling of the query string q. In pseudo-python: def get_subseq(s: str, k: int): returns all subsequences of s of length len(s) - k def build_dict(corpus: List[str], k: int): d = defaultdict(list) for orig_str in corpus: for subseq in get_subseq(orig_str, k): d[subseq].append(orig_str) return d def query(d: dict, q: str, k:int): q_subseq = set(get_subseq(q, k)) intersection = d.viewkeys() & q_subseq # this is slow when len(d) is large return [orig_str for k in intersection for orig_str in d[k]] By exposing an intersection interface, a certain degree of performance is expected by the user. It took me a considerable amount of debugging to realize that the dict.viewkeys() intersection was the performance bottleneck. I finally decided to dig into the CPython source code before discovering the root cause of the issue. While I am familiar with C and found the issue relatively quickly, for those that aren't, it should not be necessary to dig into the source code for a mainstream programming language like Python. I am currently looking at how to potentially fix this in the CPython repository. I may submit a patch in the near future if I find a good solution. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 14:10:44 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 Jul 2016 18:10:44 +0000 Subject: [issue27454] PyUnicode_InternInPlace can use PyDict_SetDefault In-Reply-To: <1467723696.2.0.276855964684.issue27454@psf.upfronthosting.co.za> Message-ID: <1469297444.86.0.216102178977.issue27454@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 14:17:52 2016 From: report at bugs.python.org (Aleksandr Koshkin) Date: Sat, 23 Jul 2016 18:17:52 +0000 Subject: [issue27601] Minor inaccuracy in hash documentation Message-ID: <1469297872.54.0.246840894647.issue27601@psf.upfronthosting.co.za> New submission from Aleksandr Koshkin: https://docs.python.org/3.6/library/stdtypes.html#hashing-of-numeric-types Look at semantics example for hash_complex function. The variable 'hash' is clearly misused - it is not defined or refers to builtin function 'hash'. Either way the example is incorrect. ---------- assignee: docs at python components: Documentation messages: 271097 nosy: docs at python, magniff priority: normal severity: normal status: open title: Minor inaccuracy in hash documentation versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 14:21:29 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 23 Jul 2016 18:21:29 +0000 Subject: [issue27469] Unicode filename gets crippled on Windows when drag and drop In-Reply-To: <1467992332.72.0.0240653508758.issue27469@psf.upfronthosting.co.za> Message-ID: <1469298089.31.0.530823493595.issue27469@psf.upfronthosting.co.za> Terry J. Reedy added the comment: > Certainly some of the requests for IDLE could be accommodated). Steve, what did you have in mind here? ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 14:25:17 2016 From: report at bugs.python.org (Aleksandr Koshkin) Date: Sat, 23 Jul 2016 18:25:17 +0000 Subject: [issue27601] Minor inaccuracy in hash documentation In-Reply-To: <1469297872.54.0.246840894647.issue27601@psf.upfronthosting.co.za> Message-ID: <1469298317.09.0.507374187014.issue27601@psf.upfronthosting.co.za> Aleksandr Koshkin added the comment: Moreover this example contains following code if hash_ == -1: hash_ == -2 return hash_ that doesn`t make too much sense. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 14:42:16 2016 From: report at bugs.python.org (Ned Deily) Date: Sat, 23 Jul 2016 18:42:16 +0000 Subject: [issue15661] OS X installer packages should be signed for OS X 10.8 Gatekeeper feature In-Reply-To: <1345013707.82.0.343684011424.issue15661@psf.upfronthosting.co.za> Message-ID: <1469299336.21.0.442780115606.issue15661@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 Sat Jul 23 14:49:52 2016 From: report at bugs.python.org (Emanuel Barry) Date: Sat, 23 Jul 2016 18:49:52 +0000 Subject: [issue27601] Minor inaccuracy in hash documentation In-Reply-To: <1469297872.54.0.246840894647.issue27601@psf.upfronthosting.co.za> Message-ID: <1469299792.74.0.816396021697.issue27601@psf.upfronthosting.co.za> Emanuel Barry added the comment: Indeed, nicely spotted! Patch attached (hash_complex_type_1.patch) P.S.: I don't like the 'hash_' name as a variable for this example; it looks like grit on Tim's monitor to me, so I went ahead and renamed it to 'hash_value' in that block. Attached as a separate patch for good measure (hash_doc_renamed_1.patch) ---------- keywords: +patch nosy: +ebarry stage: -> patch review versions: -Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file43845/hash_complex_typo_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 14:50:07 2016 From: report at bugs.python.org (Emanuel Barry) Date: Sat, 23 Jul 2016 18:50:07 +0000 Subject: [issue27601] Minor inaccuracy in hash documentation In-Reply-To: <1469297872.54.0.246840894647.issue27601@psf.upfronthosting.co.za> Message-ID: <1469299807.1.0.0635547626338.issue27601@psf.upfronthosting.co.za> Changes by Emanuel Barry : Added file: http://bugs.python.org/file43846/hash_doc_renamed_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 15:00:17 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 23 Jul 2016 19:00:17 +0000 Subject: [issue27572] Support bytes-like objects when base is given to int() In-Reply-To: <1468918576.73.0.596747914515.issue27572@psf.upfronthosting.co.za> Message-ID: <1469300417.91.0.385285888088.issue27572@psf.upfronthosting.co.za> Xiang Zhang added the comment: pypy seems so. [PyPy 5.2.0-alpha0 with GCC 4.8.2] on linux >>>> int(memoryview(b'123A'[1:3])) 23 >>>> int(memoryview(b'123 '[1:3])) 23 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 15:03:08 2016 From: report at bugs.python.org (Aleksandr Koshkin) Date: Sat, 23 Jul 2016 19:03:08 +0000 Subject: [issue27601] Minor inaccuracy in hash documentation In-Reply-To: <1469297872.54.0.246840894647.issue27601@psf.upfronthosting.co.za> Message-ID: <1469300588.3.0.394392869536.issue27601@psf.upfronthosting.co.za> Aleksandr Koshkin added the comment: Thanks) ---------- resolution: -> fixed versions: +Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 15:03:57 2016 From: report at bugs.python.org (Aleksandr Koshkin) Date: Sat, 23 Jul 2016 19:03:57 +0000 Subject: [issue27601] Minor inaccuracy in hash documentation In-Reply-To: <1469297872.54.0.246840894647.issue27601@psf.upfronthosting.co.za> Message-ID: <1469300637.37.0.495407803188.issue27601@psf.upfronthosting.co.za> Changes by Aleksandr Koshkin : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 15:10:21 2016 From: report at bugs.python.org (Ned Deily) Date: Sat, 23 Jul 2016 19:10:21 +0000 Subject: [issue27490] Do not run pgen when it is not going to be used (cross-compiling) In-Reply-To: <1468276938.3.0.370267656827.issue27490@psf.upfronthosting.co.za> Message-ID: <1469301021.74.0.0667103934235.issue27490@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +doko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 15:11:18 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 23 Jul 2016 19:11:18 +0000 Subject: [issue27601] Minor inaccuracy in hash documentation In-Reply-To: <1469297872.54.0.246840894647.issue27601@psf.upfronthosting.co.za> Message-ID: <1469301078.52.0.627997127624.issue27601@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: docs at python -> mark.dickinson nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 15:19:56 2016 From: report at bugs.python.org (SilentGhost) Date: Sat, 23 Jul 2016 19:19:56 +0000 Subject: [issue27601] Minor inaccuracy in hash documentation In-Reply-To: <1469297872.54.0.246840894647.issue27601@psf.upfronthosting.co.za> Message-ID: <1469301596.49.0.0579960286195.issue27601@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 15:29:36 2016 From: report at bugs.python.org (Steve Dower) Date: Sat, 23 Jul 2016 19:29:36 +0000 Subject: [issue27469] Unicode filename gets crippled on Windows when drag and drop In-Reply-To: <1467992332.72.0.0240653508758.issue27469@psf.upfronthosting.co.za> Message-ID: <1469302176.71.0.667998048234.issue27469@psf.upfronthosting.co.za> Steve Dower added the comment: The "Edit in IDLE" submenu we implemented could be moved from a collection of registry keys into the shell extension, which would also let us detect all Python installations, as right now we only have 3.5 and later (we could even filter out those that are missing IDLE for whatever reason). We'd also be able to fully control launching it, so we could set the working directory properly and any environment variables that may be needed/helpful. I believe we can also do other tricks like treating Shift+Click differently from a regular click, if that was any value (run in IDLE and leave the interactive session open, perhaps?). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 15:34:16 2016 From: report at bugs.python.org (Emanuel Barry) Date: Sat, 23 Jul 2016 19:34:16 +0000 Subject: [issue27601] Minor inaccuracy in hash documentation In-Reply-To: <1469297872.54.0.246840894647.issue27601@psf.upfronthosting.co.za> Message-ID: <1469302456.65.0.336458366913.issue27601@psf.upfronthosting.co.za> Emanuel Barry added the comment: Do note that nothing has been changed in the docs yet. I submitted the patch, and now other developers need to review it, decide whether it's correct or need modifications, and then someone needs to commit it. Let the bikeshedding start =) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 15:49:06 2016 From: report at bugs.python.org (Zachary Ware) Date: Sat, 23 Jul 2016 19:49:06 +0000 Subject: [issue26462] Patch to enhance literal block language declaration In-Reply-To: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za> Message-ID: <1469303346.38.0.00324787418894.issue26462@psf.upfronthosting.co.za> Zachary Ware added the comment: Hi Julien, there are still a few unanswered review comments. Check the 'review' link on 'issue26462_regen.diff' (which was your patch, I just recreated it in a format that our Rietveld review tool would accept). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 15:52:31 2016 From: report at bugs.python.org (Zachary Ware) Date: Sat, 23 Jul 2016 19:52:31 +0000 Subject: [issue19489] move quick search box above TOC In-Reply-To: <1383546510.68.0.587653327623.issue19489@psf.upfronthosting.co.za> Message-ID: <1469303551.63.0.219850678884.issue19489@psf.upfronthosting.co.za> Zachary Ware added the comment: The patch needs some work, as it stands it makes the 'Report a Bug' link disappear. I haven't looked into it far enough to determine why. For an alternative bikeshed color, would it be possible to put the quick search in the header, just left of the 'previous | next | modules | index' links? ---------- nosy: +zach.ware versions: +Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 16:20:13 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 23 Jul 2016 20:20:13 +0000 Subject: [issue27601] Minor inaccuracy in hash documentation In-Reply-To: <1469297872.54.0.246840894647.issue27601@psf.upfronthosting.co.za> Message-ID: <1469305213.93.0.423865390736.issue27601@psf.upfronthosting.co.za> R. David Murray added the comment: Adding a _ after a keyword is a very common trick. The fact that one got lost indicates that it isn't necessarily optimal :). I don't really have an opinion one way or the other on the variable rename. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 16:21:19 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 23 Jul 2016 20:21:19 +0000 Subject: [issue27469] Unicode filename gets crippled on Windows when drag and drop In-Reply-To: <1467992332.72.0.0240653508758.issue27469@psf.upfronthosting.co.za> Message-ID: <1469305279.1.0.549794775156.issue27469@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Having "Edit in IDLE' work uniformly for all installed versions would be great. > set the working directory properly This needs some discussion and coordination. I am thinking of patching IDLE to switch to $HOME when cwd is the python install dir, but this would very likely only be done for 3.6 as part of re-writing the startup code. > and any environment variables that may be needed/helpful. Can't think of anything at the moment, but this has never been an option. > treating Shift+Click differently from a regular click, if that was any value (run in IDLE and leave the interactive session open, perhaps?). IDLE's "-r file.py" runs the file and leaves Shell open. I believe this is meant as a substitute for setting $IDLESTARTUP or $PYTHONSTARTUP and using -s. For development, one should open in the editor and hit f5. There might be a controversy whether to run in IDLE or 'python -i'. If control or alt click could be distinguished, both would be possible. Are you going to open issues, or should I? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 16:24:11 2016 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 23 Jul 2016 20:24:11 +0000 Subject: [issue27601] Minor inaccuracy in hash documentation In-Reply-To: <1469297872.54.0.246840894647.issue27601@psf.upfronthosting.co.za> Message-ID: <1469305451.1.0.449616950611.issue27601@psf.upfronthosting.co.za> Mark Dickinson added the comment: The changes look good to me. Thanks for spotting this! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 16:32:15 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 23 Jul 2016 20:32:15 +0000 Subject: [issue27598] Add SizedIterable to collections.abc and typing In-Reply-To: <1469288809.56.0.543825422436.issue27598@psf.upfronthosting.co.za> Message-ID: <1469305935.16.0.140420063238.issue27598@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Does all of the recognition patterns in typing.py also need to be in collections.abc? AFAICT, the current collections.abc classes for Sized, Iterable, and Container almost never get used (possibly because they don't provide any useful mixin methods). In the interest of maximizing the ratio of useful ABCs (like MutableMapping), could we defer expanding collections.abc until we've seen some real use cases? ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 16:41:39 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 23 Jul 2016 20:41:39 +0000 Subject: [issue27602] Enable py launcher to launch repository Python. Message-ID: <1469306499.45.0.411476180863.issue27602@psf.upfronthosting.co.za> New submission from Terry J. Reedy: Running a repository build by typing a path such as F:\Python\dev\36\PCbuild\win32\python_d.exe is tedious and error prone and I have to remember to omit '\win32' for 2.7 and it takes up much of a command line. I would like to be able to run something like py -register 3.6r # 'r' for repository, or possibly '+' and subsequently have py -3.6r launch the locally compiled but un-installed binary. Possible? I did not find 'py launcher' in Expert's Index or Components, so selected you two from memory and 'Windows'. Please modify Components and Nosy as appropriate. I have an impression that there is a launcher version for Mac but know nothing about it. ---------- components: Windows messages: 271111 nosy: paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware priority: normal severity: normal stage: test needed status: open title: Enable py launcher to launch repository Python. type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 17:02:58 2016 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 23 Jul 2016 21:02:58 +0000 Subject: [issue25170] 3.4.4, 3.4.5, 3.5.0, 3.5.1, 3.5.2 documentation archives missing In-Reply-To: <1442601694.39.0.291720811899.issue25170@psf.upfronthosting.co.za> Message-ID: <1469307778.57.0.279836166282.issue25170@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- title: 3.5.0 documentation archives missing -> 3.4.4, 3.4.5, 3.5.0, 3.5.1, 3.5.2 documentation archives missing versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 17:09:17 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 23 Jul 2016 21:09:17 +0000 Subject: [issue27598] Add SizedIterable to collections.abc and typing In-Reply-To: <1469305935.16.0.140420063238.issue27598@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: It would be a deviation from existing practice for a collection ABC to exist in typing but not in collections.abc, and it would mean the inheritance tree for the types in typing.py would be different from that in collections.abc. These ABCs, while not so useful by themselves, are building blocks for the more useful ABCs. They also give people the right terminology. That arguably is the biggest problem here -- it's clear that people desperately want to be able to talk about the common API for sets and sequences, which happens to be __len__, __iter__ and __contains__. But it's also clear that people often believe that that common API is called Iterable, which it isn't. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 17:18:40 2016 From: report at bugs.python.org (Paul Moore) Date: Sat, 23 Jul 2016 21:18:40 +0000 Subject: [issue27602] Enable py launcher to launch repository Python. In-Reply-To: <1469306499.45.0.411476180863.issue27602@psf.upfronthosting.co.za> Message-ID: <1469308720.23.0.127937193864.issue27602@psf.upfronthosting.co.za> Paul Moore added the comment: This sounds like 2 related items (but I'm happy for them both to be under this issue, I'm not suggesting we need 2 issues): 1. Allowing py -register to add PEP 514 metadata to the registry for the given path. 2. Allowing py - to use PEP 514 metadata more generally, rather than its current explicit registry scan. I'm OK with both of these in principle. I'd suggest that (1) register under HKEY_CURRENT_USER (so that it doesn't need elevation, and so it's a per-user setting) and that it uses the PythonCore "Company" value (as it's a core CPython facility). We might need an "unregister" option as well, to avoid leaving clutter in the registry, and maybe even some means of listing what's been registered. That may be overkill, and manual registry tidy-up may be fine (but the same could be said of -register). There are other considerations, too - this should probably be solely for interactive invocations. I assume you wouldn't expect to support shebang lines like "#!python3.6r"? I'm not likely to have time to work on this myself in the short term (my C skills are a bit rusty, TBH) but I'm happy to review patches, etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 17:24:53 2016 From: report at bugs.python.org (Zachary Ware) Date: Sat, 23 Jul 2016 21:24:53 +0000 Subject: [issue27602] Enable py launcher to launch repository Python. In-Reply-To: <1469306499.45.0.411476180863.issue27602@psf.upfronthosting.co.za> Message-ID: <1469309093.17.0.582821334924.issue27602@psf.upfronthosting.co.za> Zachary Ware added the comment: --register sounds interesting. It could write to the user-specific py.ini, and would be useful for other things, like for `py --register pypy C:\pypy\pypy.exe`. I've also thought it would be useful to be able to use py.exe directly to invoke interpreters configured in py.ini. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 18:01:11 2016 From: report at bugs.python.org (Eryk Sun) Date: Sat, 23 Jul 2016 22:01:11 +0000 Subject: [issue27602] Enable py launcher to launch repository Python. In-Reply-To: <1469306499.45.0.411476180863.issue27602@psf.upfronthosting.co.za> Message-ID: <1469311271.57.0.257306147629.issue27602@psf.upfronthosting.co.za> Eryk Sun added the comment: > I assume you wouldn't expect to support shebang lines > like "#!python3.6r"? That's already supported in py.ini in the [commands] section, per PEP 397. I've used this from Vinay's initial releases on Bitbucket, before the launcher was officially distributed with Python. One catch is that commands can't start with "python" because that's special-cased in the launcher. Instead you could use the following: [commands] rpython3.6=F:\Python\dev\36\PCbuild\win32\python_d.exe Then create a script with the shebang `#!rpython3.6 -i` that starts the REPL after it executes. What's missing is a way to run custom commands directly from the py[w].exe command line. I wouldn't want to hog a letter such as "r" that a python.exe option could use someday (noting that command-line options can be combined like `-SORE`). But maybe it could use "--" or some other symbol to demarcate the command. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 18:17:28 2016 From: report at bugs.python.org (Paul Moore) Date: Sat, 23 Jul 2016 22:17:28 +0000 Subject: [issue27602] Enable py launcher to launch repository Python. In-Reply-To: <1469311271.57.0.257306147629.issue27602@psf.upfronthosting.co.za> Message-ID: Paul Moore added the comment: On 23 July 2016 at 23:01, Eryk Sun wrote: >> I assume you wouldn't expect to support shebang lines >> like "#!python3.6r"? > > That's already supported in py.ini in the [commands] section, per PEP 397. True, I'd forgotten that. I was meaning for interactive use, which as you say isn't supported (I asked for it a long time back, but it was rejected - maybe it's worth revisiting the idea, as I don't recall the reason for the rejection). Of course, having two places for launcher configuration, the registry and the ini file, seems like it would be confusing. So that's an argument for everything being controlled via the ini file. (BTW, the documentation in https://docs.python.org/3/using/windows.html#customization doesn't give much detail about what can go in the ini file, maybe that needs improving) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 18:25:04 2016 From: report at bugs.python.org (Julien) Date: Sat, 23 Jul 2016 22:25:04 +0000 Subject: [issue26462] Patch to enhance literal block language declaration In-Reply-To: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za> Message-ID: <1469312704.25.0.127764321171.issue26462@psf.upfronthosting.co.za> Julien added the comment: Hi, I completly missed the "review" link, sry. I reviewed comments, and I'm trying to provide an up-to-date patch that you'll hopefully won't have to doctor to make Rietveld eat it. ---------- Added file: http://bugs.python.org/file43847/issue26462.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 20:10:29 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 24 Jul 2016 00:10:29 +0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1469319029.58.0.453893802721.issue1621@psf.upfronthosting.co.za> Martin Panter added the comment: The error message comes from Undefined Behaviour Sanitizer, which was added to newer versions of GCC and Clang. Currently I am compiling with ./configure --with-pydebug CC="gcc -fsanitize=undefined -fno-sanitize=alignment -fno-sanitize=shift" https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#index-fsanitize_003dundefined-962 I thought it is worth adding a test for the impossible __length_hint__() value. Since the test iterator returns no elements, there will not be a MemoryError, but if overflow detection is enabled (such as UB Sanitizer or -ftrapv), it is guaranteed to exercise the overflow path and would be detected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 21:28:17 2016 From: report at bugs.python.org (Ammar Askar) Date: Sun, 24 Jul 2016 01:28:17 +0000 Subject: [issue19489] move quick search box above TOC In-Reply-To: <1383546510.68.0.587653327623.issue19489@psf.upfronthosting.co.za> Message-ID: <1469323697.93.0.670092161908.issue19489@psf.upfronthosting.co.za> Ammar Askar added the comment: Thank you for pointing that out to me, it completely slipped past. It looks like the 'Report a Bug' link disappears because deprecated api is used in Doc/tools/templates/layout.html {% block sidebarsourcelink %} {% endblock %} http://www.sphinx-doc.org/en/stable/templating.html#blocks >The following four blocks are only used for pages that do not have >assigned a list of custom sidebars in the html_sidebars config >value" I've amended the patch to fix this by using the way they recommend with a custom html_sidebar. As far as putting it in the title bar goes, I think it's slightly more prone to breakage since we're essentially duplicating sphinx's searchbar code. It's easy enough to add it to the right of those links, there's a {% block relbaritems %} for that. Adding it to the left is slightly more complicated. Personally I like just pinning it to the top of the sidebar but I can look into that as well if you really want. https://github.com/sphinx-doc/sphinx/blob/master/sphinx/themes/basic/layout.html#L27-L46 ---------- Added file: http://bugs.python.org/file43848/searchbar.diff2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 21:47:39 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 24 Jul 2016 01:47:39 +0000 Subject: [issue27546] Integrate tkinter and asyncio (and async) In-Reply-To: <1468815010.57.0.709565417017.issue27546@psf.upfronthosting.co.za> Message-ID: <1469324859.8.0.825341124356.issue27546@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Speed tests: First -- raw loops/second. The attached loopspeed.py has code for tk and asyncio that is equivalent as I know how. The tkasync loop is for the asyncio loop with a root.update() call added, where the root is a fresh instance of Tk(). (Reusing the old root resulted in the tk loop restarting.) tcl/tk loop: 13300 l/s asyncio loop: 14900 l/s tkasync loop: 10900 l/s (uncomment commented lines) The two bare loops have a std.dev. of roughly around 100, with +- up to 300. This suggests to me that the tcl loop might be written in tcl, not C. This result reduces my motivation to write a tcl/tk based replacement for BaseEventLoop, thought I still might. Second -- IDLE syntax highlighting speed. I opened 9 idlelib files in installed 3.6.0a3 and patched repository 3.6.0a3+. I switched between a light default and custom custom theme and hit apply. For stock IDLE, it took 2 subjective mental 'thousand and one...' counts. For patched IDLE, three. Reducing the call_later delay from .01 to .001 reduced the count to about two and a half. Replacing call_later with call_soon may have given a small further speedup. Changing highlight theme (or changing font or font size, which trigger re-highlighting) with at least a few thousand lines of code to process, is sufficiently rare that a slowdown of 25% or less does not bother me. When I want to try to experiment with using asyncio with IDLE, I will use the current patch until it proves not to work. I am now thinking of this as perhaps just a doc issue. ---------- Added file: http://bugs.python.org/file43849/loopspeed.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 22:09:19 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 24 Jul 2016 02:09:19 +0000 Subject: [issue27579] Add a tutorial for AsyncIO in the documentation In-Reply-To: <1469025749.21.0.829921979586.issue27579@psf.upfronthosting.co.za> Message-ID: <1469326159.12.0.284934891988.issue27579@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I would like the tutorial to include something like the following. Adding Tkinter GUI to Asyncio Program ------------------------------------- Assuming that the tkinter Tk instance is called 'root' and the asyncio loop is called 'loop', add the following callback loop. def tk_update(): root.update() loop.call_soon(tk_update) Before each loop.run_forever() or loop.run_until_complete(...) call, add tk_update() Do not call root.mainloop() or root.quit(). Loop.stop() or completion of run_until_complete will stop the tk_update loop. --- This is the result of my experiments in #27546. One of my tests was running IDLE with an asyncio loop augmented with the above replacing root.mainloop. I don't yet know how to work with git and github. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 23:46:39 2016 From: report at bugs.python.org (Steve Dower) Date: Sun, 24 Jul 2016 03:46:39 +0000 Subject: [issue27602] Enable py launcher to launch repository Python. In-Reply-To: <1469306499.45.0.411476180863.issue27602@psf.upfronthosting.co.za> Message-ID: <1469331999.24.0.510569449395.issue27602@psf.upfronthosting.co.za> Steve Dower added the comment: I think this is best written as: * extend py.exe to handle PEP 514 properly * write "PythonCore\dev36" (or equivalent - maybe "PythonDev\dev36"?) keys on each build That way you could use "py -dev36" to get your latest build from source (actual tag open to bikeshedding). Right now we write "python.bat" in the root of the source directory for the most recent build, so maybe that's a good enough workaround? While I'd like to enable a "register" command, it's complicated enough and I suspect of limited value compared to directly editing the registry (or updating other interpreter's installers) that I'd rather not worry. A big part of the reason for PEP 514 is to be able to point other interpreters to it and say "do this and your users won't need to know where you installed everything". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 23:59:59 2016 From: report at bugs.python.org (Steve Dower) Date: Sun, 24 Jul 2016 03:59:59 +0000 Subject: [issue27603] Migrate IDLE context menu items to shell extension Message-ID: <1469332799.74.0.70339682021.issue27603@psf.upfronthosting.co.za> New submission from Steve Dower: Currently (on Windows) we register a set of subcommands in order to display an expanding list of versions of IDLE when users right-click a .py file. With issue27469, a proper shell extension was added, which means we can now use IContextMenu to implement the menu rather than fixed registry keys. This would allow us to detect all installed versions of IDLE and present them without having to register new keys (i.e. forwards and backwards compatibility). ---------- assignee: terry.reedy components: IDLE, Windows messages: 271123 nosy: paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware priority: low severity: normal stage: needs patch status: open title: Migrate IDLE context menu items to shell extension type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 00:00:11 2016 From: report at bugs.python.org (Steve Dower) Date: Sun, 24 Jul 2016 04:00:11 +0000 Subject: [issue27603] Migrate IDLE context menu items to shell extension In-Reply-To: <1469332799.74.0.70339682021.issue27603@psf.upfronthosting.co.za> Message-ID: <1469332811.75.0.460860364247.issue27603@psf.upfronthosting.co.za> Steve Dower added the comment: Another idea: we can also provide extra ("extended") commands when the user holds Shift and right-clicks a file. We could use this to add items to do "-r file.py" with IDLE, which would run the file with IDLE and leave the Shell open. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 00:00:59 2016 From: report at bugs.python.org (Steve Dower) Date: Sun, 24 Jul 2016 04:00:59 +0000 Subject: [issue27469] Unicode filename gets crippled on Windows when drag and drop In-Reply-To: <1467992332.72.0.0240653508758.issue27469@psf.upfronthosting.co.za> Message-ID: <1469332859.8.0.726345347744.issue27469@psf.upfronthosting.co.za> Steve Dower added the comment: I just created issue27603 for any work that goes into adapting the IDLE context menu. Pretty good chance I'll get to look at it for 3.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 00:02:58 2016 From: report at bugs.python.org (Steve Dower) Date: Sun, 24 Jul 2016 04:02:58 +0000 Subject: [issue27602] Enable py launcher to launch repository Python. In-Reply-To: <1469306499.45.0.411476180863.issue27602@psf.upfronthosting.co.za> Message-ID: <1469332978.11.0.249020334585.issue27602@psf.upfronthosting.co.za> Steve Dower added the comment: > having two places for launcher configuration, the registry and the ini file, seems like it would be confusing My hope here is that the registry is "the place where all your Pythons are registered" and py.ini is "the place where settings for py.exe are kept". By default (in time), py.exe will look through the registry at all your Pythons, but changes that should only affect py.exe go in its settings file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 00:03:49 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 24 Jul 2016 04:03:49 +0000 Subject: [issue27366] PEP487: Simpler customization of class creation In-Reply-To: <1466579967.76.0.483118833643.issue27366@psf.upfronthosting.co.za> Message-ID: <1469333029.13.0.275225847238.issue27366@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 00:13:48 2016 From: report at bugs.python.org (koobs) Date: Sun, 24 Jul 2016 04:13:48 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <1469333628.51.0.365256077686.issue24773@psf.upfronthosting.co.za> koobs added the comment: I can help providing information on the koobs-* freebsd buildbots (I run them). In a default installation, the timezone entries are available in /usr/share/zoneinfo (see attachment for contents) Iran is not in the root directory, 'Tehran' is in Asia/ subdirectory tzsetup man page: https://www.freebsd.org/cgi/man.cgi?query=tzsetup&sektion=8 The misc/zoneinfo port/package [1] can be installed which overwrites entries in the above location. The files this port/package installs are in the pkg-plist file: https://svnweb.freebsd.org/ports/head/misc/zoneinfo/pkg-plist?view=log There doesn't appear to be an 'Iran' entry in the root of this port/package either, so my guess is its a distribution specific location [1] https://svnweb.freebsd.org/ports/head/misc/zoneinfo/ Beyond the above, tests should not fail (but skip) if the resources it requires are not available, so the change in e72aab080165 is welcome ---------- Added file: http://bugs.python.org/file43850/koobs-freebsd-current-usr-share-zoneinfo.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 00:18:46 2016 From: report at bugs.python.org (koobs) Date: Sun, 24 Jul 2016 04:18:46 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <1469333926.45.0.284067963407.issue24773@psf.upfronthosting.co.za> koobs added the comment: See Also: non standard (standard?) timezones. https://lists.freebsd.org/pipermail/freebsd-hackers/2015-May/047765.html I don't know to what extent these links are considered standard, but I'll talk to Julian about whether we can get these links installed in FreeBSD base (and the zoneinfo port/package). having said that, even if they can be/are added, the tests should still not expect them (blindly) to be available. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 01:15:02 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 24 Jul 2016 05:15:02 +0000 Subject: [issue27366] PEP487: Simpler customization of class creation In-Reply-To: <1466579967.76.0.483118833643.issue27366@psf.upfronthosting.co.za> Message-ID: <1469337302.41.0.00207886823295.issue27366@psf.upfronthosting.co.za> Nick Coghlan added the comment: I started reviewing Martin's patch, and I initially thought I had found a problem with the way __init_subclass__ is currently defined. It turned out I was wrong about it actually being broken, but I *do* now think it's inherently confusing, and we may be able to do something different that's more obviously correct (or at least easier to document - it was proposing revisions to the documentation that got me thinking along this path). Specifically, I was thinking using super() in either the zero argument form or the explicit form could create an infinite loop due to the way we're currently proposing to interact with the MRO. Consider: class BaseClass: @classmethod def __init_subclass__(cls): super(cls, BaseClass).__init_subclass__() class SubClass(BaseClass): pass If the initial call made by type.__new__() is effectively "SubClass.mro()[1].__init_subclass__()", then the super() call is going to call BaseClass.__init_subclass__ again. However, it turned out I was wrong, as that's not what happens: the call made by the type machinery is instead "super(SubClass, SubClass).__init_subclass__", which gets it to the right place in the MRO and causes further super() calls to do the right thing. However, the "more obviously correct" signature that occurred to me was to do this instead: class BaseClass: @classmethod def __init_subclass__(cls, subcls): super(cls, BaseClass).__init_subclass__(subcls) class SubClass(BaseClass): pass Then the invocation from type.__new__ could be defined more simply as: SubClass.mro()[1].__init_subclass__(SubClass) In all cases then (regardless of where you were in the MRO), "cls" would refer to "the class first in the MRO after the class being defined" and "subcls" would refer to "the class currently being defined". If you consider the plugin example in the PEP, with the revised signature, it would look like: class PluginBase: subclasses = [] def __init_subclass__(cls, subcls, **kwargs): super().__init_subclass__(**kwargs) cls.subclasses.append(subcls) And *even if the subclass being defined shadowed the "subclasses" attribute*, this initialisation would still work. (You can still get yourself in trouble if a subclass somewhere else in the MRO shadows the attribute, but that's life in complex type hierarchies) In the version in the PEP, the fact that "cls" is actually a subclass, and we're relying on the MRO to find "subclasses" is a really subtle implementation detail, while having two parameters makes it clear that "the class defining __init_subclass__" is distinct from the "new subclass being defined". ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 01:29:20 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 Jul 2016 05:29:20 +0000 Subject: [issue734176] Make Tkinter.py's nametowidget work with cloned menu widgets Message-ID: <1469338160.64.0.122668946483.issue734176@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Issue18686 is reproducible to me. Here is a script based on issue18686 example. Run it and open the "File" menu. $ python3 issue18686.py .#3069298188.#3069298188#3069298252 Exception in Tkinter callback Traceback (most recent call last): File "/usr/lib/python3.5/tkinter/__init__.py", line 1553, in __call__ return self.func(*args) File "issue18686.py", line 24, in entry_focus_lost widget_with_focus = self.focus_get() File "/usr/lib/python3.5/tkinter/__init__.py", line 550, in focus_get return self._nametowidget(name) File "/usr/lib/python3.5/tkinter/__init__.py", line 1204, in nametowidget w = w.children[n] KeyError: '#3069298188' But my patch doesn't help in case of tearoff menu. Detach the "File" menu and hover a mouse on its item. $ ./python issue18686.py .#`menu.#`menu#`menu .`menu.`menu .tearoff1 Exception in Tkinter callback Traceback (most recent call last): File "/home/serhiy/py/cpython/Lib/tkinter/__init__.py", line 1712, in __call__ return self.func(*args) File "issue18686.py", line 24, in entry_focus_lost widget_with_focus = self.focus_get() File "/home/serhiy/py/cpython/Lib/tkinter/__init__.py", line 692, in focus_get return self._nametowidget(name) File "/home/serhiy/py/cpython/Lib/tkinter/__init__.py", line 1344, in nametowidget w = w.children[n] KeyError: 'tearoff1' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 01:32:07 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 Jul 2016 05:32:07 +0000 Subject: [issue734176] Make Tkinter.py's nametowidget work with cloned menu widgets Message-ID: <1469338327.75.0.987060323172.issue734176@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Following patch tries to handle the case when there are multiple clones (but it doesn't help with tearoff menus). ---------- Added file: http://bugs.python.org/file43851/nametowidget_clonedmenus_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 01:32:35 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 Jul 2016 05:32:35 +0000 Subject: [issue734176] Make Tkinter.py's nametowidget work with cloned menu widgets Message-ID: <1469338355.62.0.00489406876512.issue734176@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- type: enhancement -> behavior versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 01:33:49 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 24 Jul 2016 05:33:49 +0000 Subject: [issue27366] PEP487: Simpler customization of class creation In-Reply-To: <1466579967.76.0.483118833643.issue27366@psf.upfronthosting.co.za> Message-ID: <1469338429.28.0.221678167636.issue27366@psf.upfronthosting.co.za> Nick Coghlan added the comment: Scratch that, my revised idea is fundamentally broken, as this example illustrates: >>> class BaseClass: pass ... >>> class OtherClass: pass ... >>> class SubClass(OtherClass, BaseClass): pass ... >>> SubClass.mro() [, , , ] The PEP as written handles this correctly, while the alternative signature would fail miserably ("OtherClass" wouldn't chain up to "BaseClass" properly). So I'll review the rest of the patch, and we can figure out the documentation problem later. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 01:34:31 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 24 Jul 2016 05:34:31 +0000 Subject: [issue27366] PEP487: Simpler customization of class creation In-Reply-To: <1466579967.76.0.483118833643.issue27366@psf.upfronthosting.co.za> Message-ID: <1469338471.39.0.281130178143.issue27366@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: -> ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 02:31:22 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 24 Jul 2016 06:31:22 +0000 Subject: [issue27581] Fix overflow check in PySequence_Tuple In-Reply-To: <1469079408.21.0.622161481276.issue27581@psf.upfronthosting.co.za> Message-ID: <1469341882.56.0.597221456378.issue27581@psf.upfronthosting.co.za> Martin Panter added the comment: I don?t accept that the bltinmodule.c code is similar to your patch. It gets a size_t from calling strlen() on a string that potentially comes from outside Python, so it is definitely valid to check for PY_SSIZE_T_MAX. However I did find PyByteArray_Resize() (revision 1590c594550e), where this technique of calculating in size_t and then checking for overflow is used. And also in your favour is the definition in Include/pyport.h which currently guarantees size_t can store up to double PY_SSIZE_T_MAX: /* Largest positive value of type Py_ssize_t. */ #define PY_SSIZE_T_MAX ((Py_ssize_t)(((size_t)-1)>>1)) So I am convinced there should be no real problem with your patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 03:06:24 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 24 Jul 2016 07:06:24 +0000 Subject: [issue7063] Memory errors in array.array In-Reply-To: <1254730349.27.0.71088310024.issue7063@psf.upfronthosting.co.za> Message-ID: <1469343984.85.0.95429310491.issue7063@psf.upfronthosting.co.za> Martin Panter added the comment: The patch looks good to me (assuming it still applies). Should also remove the ?b? macro. ---------- components: +Extension Modules -Library (Lib), Tests nosy: +martin.panter stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 03:25:55 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 24 Jul 2016 07:25:55 +0000 Subject: [issue27570] Avoid memcpy(. . ., NULL, 0) etc calls In-Reply-To: <1468897030.77.0.552858173381.issue27570@psf.upfronthosting.co.za> Message-ID: <1469345155.19.0.0905640852709.issue27570@psf.upfronthosting.co.za> Martin Panter added the comment: V2 patch adds another fix, uncovered by recent datetime tests: >>> a = array("B") >>> a[:] = a /media/disk/home/proj/python/cpython/Modules/arraymodule.c:748:5: runtime error: null pointer passed as argument 1, which is declared to never be null /media/disk/home/proj/python/cpython/Modules/arraymodule.c:748:5: runtime error: null pointer passed as argument 2, which is declared to never be null ---------- Added file: http://bugs.python.org/file43852/memcpy-null.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 03:45:44 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 24 Jul 2016 07:45:44 +0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1469346344.54.0.403285935836.issue1621@psf.upfronthosting.co.za> Xiang Zhang added the comment: It's cool, but I get one problem when writing tests. support.captured_stderr cannot capture the runtime error message. So we have nothing to do with the assertion and the test will always succeed even when overflow does happen (the message will be output). To solve this problem, we have to do io redirect in file descriptor level, I wonder does this deserve that? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 03:56:54 2016 From: report at bugs.python.org (Ronald Oussoren) Date: Sun, 24 Jul 2016 07:56:54 +0000 Subject: [issue18181] PEP447: Add type.__getdescriptor__ In-Reply-To: <1370870153.93.0.646087371852.issue18181@psf.upfronthosting.co.za> Message-ID: <1469347014.19.0.0959400691765.issue18181@psf.upfronthosting.co.za> Changes by Ronald Oussoren : Added file: http://bugs.python.org/file43853/pep447-2015-07-26.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 04:29:11 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 24 Jul 2016 08:29:11 +0000 Subject: [issue27366] PEP487: Simpler customization of class creation In-Reply-To: <1466579967.76.0.483118833643.issue27366@psf.upfronthosting.co.za> Message-ID: <1469348951.6.0.384921289429.issue27366@psf.upfronthosting.co.za> Nick Coghlan added the comment: Martin's current implementation basically looks good to me - I've mainly suggested some changes to the documentation and additional test cases that help stress test some of the more complex inheritance hierarchies described above, although there are a few other other suggestions as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 04:30:51 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 24 Jul 2016 08:30:51 +0000 Subject: [issue27582] Mispositioned SyntaxError caret for unknown code points In-Reply-To: <1469102054.52.0.839726574023.issue27582@psf.upfronthosting.co.za> Message-ID: <1469349051.45.0.168261114255.issue27582@psf.upfronthosting.co.za> Nick Coghlan added the comment: Drekin, agreed, that looks like the same problem. Since this one has draft patches attached, I'll mark the other one as a duplicate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 04:33:41 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 24 Jul 2016 08:33:41 +0000 Subject: [issue26152] A non-breaking space in a source In-Reply-To: <1453204897.88.0.969876573405.issue26152@psf.upfronthosting.co.za> Message-ID: <1469349221.83.0.696769587518.issue26152@psf.upfronthosting.co.za> Nick Coghlan added the comment: http://bugs.python.org/issue27582 is a later mention of the same problem that attracted patches before Adam noticed it was a repeat of this issue. Marking this as the duplicate, since the problem applies to more than just Unicode whitespace, and the problems being discussed there should also help with this subproblem. ---------- nosy: +ncoghlan superseder: -> Mispositioned SyntaxError caret for unknown code points _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 04:33:56 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 24 Jul 2016 08:33:56 +0000 Subject: [issue26152] A non-breaking space in a source In-Reply-To: <1453204897.88.0.969876573405.issue26152@psf.upfronthosting.co.za> Message-ID: <1469349236.42.0.185406321494.issue26152@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 04:35:48 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 24 Jul 2016 08:35:48 +0000 Subject: [issue26823] Shrink recursive tracebacks In-Reply-To: <1461292585.22.0.159887337407.issue26823@psf.upfronthosting.co.za> Message-ID: <1469349348.22.0.393620777727.issue26823@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: ebarry -> ncoghlan stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 05:01:57 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 24 Jul 2016 09:01:57 +0000 Subject: [issue26823] Shrink recursive tracebacks In-Reply-To: <1461292585.22.0.159887337407.issue26823@psf.upfronthosting.co.za> Message-ID: <1469350917.72.0.501341063519.issue26823@psf.upfronthosting.co.za> Nick Coghlan added the comment: Thanks Emanuel, and sorry for the long delay in getting a review! My main substantive comment is that the approach of hardcoding the recursion count won't work cross platform, as the default recursion limit is set differently depending on how the platform's C runtime behaves. Fortunately, sys.getrecursionlimit() and len(inspect.stack()) should make it possible to tweak the tests to avoid the hardcoded assumption. I also have some additional readability suggestions, which can be found in Rietveld. ---------- assignee: ncoghlan -> ebarry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 05:04:05 2016 From: report at bugs.python.org (Martin Teichmann) Date: Sun, 24 Jul 2016 09:04:05 +0000 Subject: [issue27366] PEP487: Simpler customization of class creation In-Reply-To: <1466579967.76.0.483118833643.issue27366@psf.upfronthosting.co.za> Message-ID: <1469351045.81.0.567094336717.issue27366@psf.upfronthosting.co.za> Martin Teichmann added the comment: Thanks for the nice review! I made the proposed changes, see attached patch. I am still waiting for a decision whether type.__setattr__ should call __set_name__ from python-dev, once that's sorted out I'll implement and test the one or the other behavior. ---------- Added file: http://bugs.python.org/file43854/pep487.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 05:46:21 2016 From: report at bugs.python.org (Ram Rachum) Date: Sun, 24 Jul 2016 09:46:21 +0000 Subject: [issue27604] More details about `-O` flag Message-ID: <1469353581.38.0.811049911305.issue27604@psf.upfronthosting.co.za> New submission from Ram Rachum: I wanted to ensure that the `-O` flag doesn't really do anything more than remove assert statement and make `__debug__` equal `False`. But the documentation for `-O` doesn't cover it: https://docs.python.org/3/using/cmdline.html#cmdoption-O https://docs.python.org/3/using/cmdline.html#envvar-PYTHONOPTIMIZE It just says "basic optimizations". Are there any other optimizations except the two I mentioned? ---------- assignee: docs at python components: Documentation messages: 271142 nosy: cool-RR, docs at python priority: normal severity: normal status: open title: More details about `-O` flag type: enhancement versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 06:48:37 2016 From: report at bugs.python.org (Chris Mayo) Date: Sun, 24 Jul 2016 10:48:37 +0000 Subject: [issue25170] 3.4.4, 3.4.5, 3.5.0, 3.5.1, 3.5.2 documentation archives missing In-Reply-To: <1442601694.39.0.291720811899.issue25170@psf.upfronthosting.co.za> Message-ID: <1469357317.62.0.37508112764.issue25170@psf.upfronthosting.co.za> Changes by Chris Mayo : ---------- nosy: +cjmayo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 06:50:15 2016 From: report at bugs.python.org (Chris Mayo) Date: Sun, 24 Jul 2016 10:50:15 +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: <1469357415.09.0.119648747673.issue27226@psf.upfronthosting.co.za> Changes by Chris Mayo : ---------- nosy: +cjmayo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 07:04:03 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 Jul 2016 11:04:03 +0000 Subject: [issue15303] Minor revision to the method in Tkinter In-Reply-To: <1341822350.55.0.995662615633.issue15303@psf.upfronthosting.co.za> Message-ID: <1469358243.44.0.551357800698.issue15303@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka type: behavior -> enhancement versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 08:08:27 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 24 Jul 2016 12:08:27 +0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1469362107.95.0.825995741477.issue1621@psf.upfronthosting.co.za> Martin Panter added the comment: Xiang: I don?t think we need to make the tests do anything special. Just make sure they exercise the code that handles overflows. I have been running the test suite without any -j0 option, and I can look over the output and see the error messages. Or if we get to a stage where all the errors are eliminated, you could run with UBSAN_OPTIONS=halt_on_error=1. E.g. in this patch, I add two simple tests to cover parts of the code that weren?t covered before (and if I hadn?t fixed the overflows, the tests would trigger extra UBSAN errors). ctypes_v2.patch is an update of array-size.patch. I improved the test case, and added a new fix for overflows like the following: >>> class S(ctypes.Structure): ... _fields_ = (("field", ctypes.c_longlong, 64),) ... >>> s = S() >>> s.field = 3 Modules/_ctypes/cfield.c:900:9: runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long long int' ---------- Added file: http://bugs.python.org/file43855/ctypes_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 08:12:53 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 24 Jul 2016 12:12:53 +0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1469362373.27.0.758576760716.issue1621@psf.upfronthosting.co.za> Martin Panter added the comment: unicode.patch avoids an overflow in PyUnicode_Join(): >>> size = int(sys.maxsize**0.5) + 1 >>> "".join(("A" * size,) * size) Objects/unicodeobject.c:9927:12: runtime error: signed integer overflow: 46341 + 2147441940 cannot be represented in type 'int' OverflowError: join() result is too long for a Python string ---------- Added file: http://bugs.python.org/file43856/unicode.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 08:13:15 2016 From: report at bugs.python.org (Vasiliy Faronov) Date: Sun, 24 Jul 2016 12:13:15 +0000 Subject: [issue27605] Inconsistent calls to __eq__ from built-in __contains__ Message-ID: <1469362395.06.0.246923750082.issue27605@psf.upfronthosting.co.za> New submission from Vasiliy Faronov: Consider the attached example program. I expect it to run successfully, because the Python 3 language reference says [1]: > For container types such as list, tuple, set, frozenset, dict, or collections.deque, the expression `x in y` is equivalent to `any(x is e or x == e for e in y)`. and [2]: > `x==y` calls `x.__eq__(y)` Instead, under Python 3.5.2, the program crashes with an assertion error, because `dict.__contains__` calls `Bar.__eq__` instead of `Foo.__eq__`. The same happens if you replace the dict with a set or a frozenset. But if you replace it with a list or a tuple, the behavior is as documented. This seems to me like a bug in either the implementation or the documentation. The language reference clearly says [3] that equality should be symmetric "if possible", but is not required to be, and indeed that is hard to guarantee when different classes are involved. [1] https://docs.python.org/3/reference/expressions.html#membership-test-details [2] https://docs.python.org/3/reference/datamodel.html#object.__eq__ [3] https://docs.python.org/3/reference/expressions.html#value-comparisons ---------- files: contains_eq.py messages: 271145 nosy: vfaronov priority: normal severity: normal status: open title: Inconsistent calls to __eq__ from built-in __contains__ type: behavior Added file: http://bugs.python.org/file43857/contains_eq.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 08:27:43 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 24 Jul 2016 12:27:43 +0000 Subject: [issue27606] Android cross-built for armv5te with clang and '-mthumb' crashes with SIGSEGV or SIGILL Message-ID: <1469363263.55.0.186080490257.issue27606@psf.upfronthosting.co.za> New submission from Xavier de Gaye: Android ndk version r11c. The crash happens very early on python startup. The SIGILL occurs when python is built 'with-pydebug'. Python runs fine on the armv5te emulator when built with clang without '-mthumb'. Python runs fine on the armv5te emulator when built with gcc 4.9 with or without '-mthumb'. Attaching the strace and logcat output for each type of build. The backtrace when python is built 'with-pydebug' (but logcat.txt says that the SIGSEGV occurs at PyUnicode_DecodeUTF8Stateful when not built 'with-pydebug'): Program received signal SIGILL, Illegal instruction. 0xb6d77e0a in r_object (p=0xbed89588) at Python/marshal.c:1340 1340 idx = r_ref_reserve(flag, p); (gdb) bt #0 0xb6d77e0a in r_object (p=0xbed89588) at Python/marshal.c:1340 #1 0xb6d76ba2 in PyMarshal_ReadObjectFromString (str=0xb6e5f9ae <_Py_M__importlib> "c", len=30106) at Python/marshal.c:1584 #2 0xb6d72506 in PyImport_ImportFrozenModuleObject (name='_frozen_importlib') at Python/import.c:1187 #3 0xb6d727ec in PyImport_ImportFrozenModule (name=0xb6e49ac0 "_frozen_importlib") at Python/import.c:1236 #4 0xb6d7ff96 in import_init (interp=0xb6919068, sysmod=) at Python/pylifecycle.c:243 #5 0xb6d7fc80 in _Py_InitializeEx_Private (install_sigs=1, install_importlib=1) at Python/pylifecycle.c:413 #6 0xb6d80f30 in Py_InitializeEx (install_sigs=1) at Python/pylifecycle.c:450 #7 0xb6d80f3e in Py_Initialize () at Python/pylifecycle.c:456 #8 0xb6daa5e6 in Py_Main (argc=1, argv=0xb6901068) at Modules/main.c:678 #9 0xb6f9b84c in ?? () ---------- components: Cross-Build files: strace.txt messages: 271146 nosy: Alex.Willmer, xdegaye priority: normal severity: normal status: open title: Android cross-built for armv5te with clang and '-mthumb' crashes with SIGSEGV or SIGILL type: crash versions: Python 3.6 Added file: http://bugs.python.org/file43858/strace.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 08:27:58 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 24 Jul 2016 12:27:58 +0000 Subject: [issue27606] Android cross-built for armv5te with clang and '-mthumb' crashes with SIGSEGV or SIGILL In-Reply-To: <1469363263.55.0.186080490257.issue27606@psf.upfronthosting.co.za> Message-ID: <1469363278.37.0.351021175175.issue27606@psf.upfronthosting.co.za> Changes by Xavier de Gaye : Added file: http://bugs.python.org/file43859/logcat.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 08:28:17 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 24 Jul 2016 12:28:17 +0000 Subject: [issue27606] Android cross-built for armv5te with clang and '-mthumb' crashes with SIGSEGV or SIGILL In-Reply-To: <1469363263.55.0.186080490257.issue27606@psf.upfronthosting.co.za> Message-ID: <1469363297.69.0.488540451495.issue27606@psf.upfronthosting.co.za> Changes by Xavier de Gaye : Added file: http://bugs.python.org/file43860/strace-pydebug.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 08:28:36 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 24 Jul 2016 12:28:36 +0000 Subject: [issue27606] Android cross-built for armv5te with clang and '-mthumb' crashes with SIGSEGV or SIGILL In-Reply-To: <1469363263.55.0.186080490257.issue27606@psf.upfronthosting.co.za> Message-ID: <1469363316.63.0.84087410934.issue27606@psf.upfronthosting.co.za> Changes by Xavier de Gaye : Added file: http://bugs.python.org/file43861/logcat-pydebug.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 08:29:22 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 24 Jul 2016 12:29:22 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <1469363362.62.0.39751061923.issue24773@psf.upfronthosting.co.za> Martin Panter added the comment: FWIW I can produce two of these failures locally: the time_t OverflowError, and the test_all() system_transitions one. Let me know if you want any more info. In my case the message for the test_all() failure is ?posix/Africa/Casablanca system_transitions?. I am on 64-bit Arch Linux, but Python is currently compiled for the 32-bit ABI. $ pacman -Qo /usr/share/zoneinfo/posix/Africa/Casablanca /usr/share/zoneinfo/posix/Africa/Casablanca is owned by tzdata 2013h-1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 08:32:57 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 24 Jul 2016 12:32:57 +0000 Subject: [issue26865] Meta-issue: support of the android platform In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za> Message-ID: <1469363577.15.0.736929233748.issue26865@psf.upfronthosting.co.za> Xavier de Gaye added the comment: issue #27606: Android cross-built for armv5te with clang and '-mthumb' crashes with SIGSEGV or SIGILL ---------- dependencies: +Android cross-built for armv5te with clang and '-mthumb' crashes with SIGSEGV or SIGILL _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 08:36:10 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 24 Jul 2016 12:36:10 +0000 Subject: [issue27606] Android cross-built for armv5te with clang and '-mthumb' crashes with SIGSEGV or SIGILL In-Reply-To: <1469363263.55.0.186080490257.issue27606@psf.upfronthosting.co.za> Message-ID: <1469363770.65.0.982761162819.issue27606@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The reference to '-mthumb' in the ndk documentation: https://developer.android.com/ndk/guides/standalone_toolchain.html#abi. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 09:33:30 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 24 Jul 2016 13:33:30 +0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1469367210.76.0.0026346909981.issue1621@psf.upfronthosting.co.za> Xiang Zhang added the comment: It turns out you just want to see the output. That is easy. Patch v3 adding the test. ---------- Added file: http://bugs.python.org/file43862/tuple_and_list_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 09:38:52 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 24 Jul 2016 13:38:52 +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: <1469367532.28.0.38389947926.issue26915@psf.upfronthosting.co.za> Xiang Zhang added the comment: Ping again. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 09:50:29 2016 From: report at bugs.python.org (Emanuel Barry) Date: Sun, 24 Jul 2016 13:50:29 +0000 Subject: [issue26823] Shrink recursive tracebacks In-Reply-To: <1461292585.22.0.159887337407.issue26823@psf.upfronthosting.co.za> Message-ID: <1469368229.34.0.562545889917.issue26823@psf.upfronthosting.co.za> Emanuel Barry added the comment: Thank you Nick for the comments! Updated patch attached. The new patch uses inspect.stack() to calculate the total stack size, but I'm unable to get the exact number needed, and I found that I'm either 19 or 20 above (depending on whether I run it with -m or manually). The test now "just works" with it, but I'm quite sure it's going to break at some point. Any idea? The other alternative would be to use traceback.walk_tb(exc.__traceback__), but the Python implementation uses that, so it'd be comparing itself; and that's about as useful as not caring about the size at all. (On the other hand, the C and Python implementations get the exact same number, so it can confirm it's fine) ---------- stage: commit review -> patch review Added file: http://bugs.python.org/file43863/short_tracebacks_6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 10:05:50 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 24 Jul 2016 14:05:50 +0000 Subject: [issue23545] Turn on extra warnings on GCC In-Reply-To: <1425076183.98.0.20319163057.issue23545@psf.upfronthosting.co.za> Message-ID: <1469369150.68.0.204432432715.issue23545@psf.upfronthosting.co.za> Martin Panter added the comment: -Wall is already added (unconditionally) to $OPT above. What?s the point of also adding it to $CFLAGS_NODIST as well? Does it have to be added to both? ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 10:23:28 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Sun, 24 Jul 2016 14:23:28 +0000 Subject: [issue27605] Inconsistent calls to __eq__ from built-in __contains__ In-Reply-To: <1469362395.06.0.246923750082.issue27605@psf.upfronthosting.co.za> Message-ID: <1469370208.64.0.810999982094.issue27605@psf.upfronthosting.co.za> Steven D'Aprano added the comment: I'm reluctant to call this a behaviour bug, because I'm reluctant to guarantee the *precise* behaviour when the classes are different. I haven't checked the source of dict.__contains__, but by experimentation it seems that: needle in {key: value} calls key == needle, rather than needle == key as the docs would imply. This seems to apply going all the way back to at least CPython2.4. On the other hand, Jython2.5 and IronPython2.6 seem to call needle == key as Vasily expected. But the docs are clearly incomplete, as they suggest a linear search through all the keys of the dict (or set), which is wrong. Only if needle hashes to the same value as key will == be called. I suggest updating the docs to make it clear that the sample code shown is only the *approximate* behaviour, which may call == in either direction. ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 10:25:54 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 Jul 2016 14:25:54 +0000 Subject: [issue27495] Pretty printing sorting for set and frozenset instances In-Reply-To: <1468323029.69.0.352634397545.issue27495@psf.upfronthosting.co.za> Message-ID: <1469370354.12.0.646941146763.issue27495@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Following patch adds support of all standard collections in pprint.saferepr(). ---------- Added file: http://bugs.python.org/file43864/saferepr_collections.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 10:35:11 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 24 Jul 2016 14:35:11 +0000 Subject: [issue26823] Shrink recursive tracebacks In-Reply-To: <1461292585.22.0.159887337407.issue26823@psf.upfronthosting.co.za> Message-ID: <1469370911.38.0.63120300667.issue26823@psf.upfronthosting.co.za> Nick Coghlan added the comment: Since you're ultimately comparing a list of lines, it may be useful to split the checks into two parts: 1. Check the deterministic lines 2. Check the variable line (which should always be at index -2 in the splitlines() result) For the recursion error, we're not too worried about the *exact* repetition count, we're mostly interested in checking that it abbreviated the traceback. Once you've pulled that line out of the main "Are they the same?" comparison, you can use a regex (or just string operations) to extract the repetition count, convert it to an integer and check that it gives the right answer to within (say) +/- 50 repetitions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 10:36:35 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 Jul 2016 14:36:35 +0000 Subject: [issue27605] Inconsistent calls to __eq__ from built-in __contains__ In-Reply-To: <1469362395.06.0.246923750082.issue27605@psf.upfronthosting.co.za> Message-ID: <1469370995.79.0.995515119746.issue27605@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 10:38:25 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 24 Jul 2016 14:38:25 +0000 Subject: [issue8623] Aliasing warnings in socketmodule.c In-Reply-To: <1273067856.13.0.617035378143.issue8623@psf.upfronthosting.co.za> Message-ID: <1469371105.02.0.756128661504.issue8623@psf.upfronthosting.co.za> Martin Panter added the comment: I think the time for backporting to 3.2 has passed. Is there anything else to do for this report? ---------- nosy: +martin.panter versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 10:42:30 2016 From: report at bugs.python.org (R. David Murray) Date: Sun, 24 Jul 2016 14:42:30 +0000 Subject: [issue27605] Inconsistent calls to __eq__ from built-in __contains__ In-Reply-To: <1469362395.06.0.246923750082.issue27605@psf.upfronthosting.co.za> Message-ID: <1469371350.45.0.995109170647.issue27605@psf.upfronthosting.co.za> R. David Murray added the comment: I did look at the code. Indeed list and tuple compare x to e, while dict, set, and frozenset (well, I didn't check each one, just list and set) compare the e to x, where e is they key stored at hash(x). Steve has a good point about the iteration. And a user class can do anything it wants in contains. I wonder if it would be even more accurate to say "conceptually equal" rather than "approximately equal", given that hash table 'in' doesn't do iteration at all. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 10:50:33 2016 From: report at bugs.python.org (Julien) Date: Sun, 24 Jul 2016 14:50:33 +0000 Subject: [issue26546] Provide translated french translation on docs.python.org In-Reply-To: <1457794223.79.0.618185263259.issue26546@psf.upfronthosting.co.za> Message-ID: <1469371833.75.0.351945053239.issue26546@psf.upfronthosting.co.za> Julien added the comment: I'm on the way of simplifying my [pull request for docsbuild-script](https://github.com/python/docsbuild-scripts/pull/1) with two goals in mind: - Simplify to make it more robust - Avoid executing external (~untrusted) Makefile on docs.python.org servers To achieve this, I need to pass sphinx options to the `Doc/Makefile`, I'd like to call, typically: make autobuild-stable SPHINXOPTS='-D language=fr -D locale_dirs=./locale/' Which work if `Doc/Makefile` don't erase but append to the `SPHINXOPTS` variable. Which is done by `allow_sphinxopts.diff`. We may simplify it further by adding `locale_dirs` to `Doc/conf.py` which does not break the english build, but I'm not sure if it's of any interest. We may abstract it further by accepting a new parameter like SPHINXLANG='fr', with a default of 'en', but in every case I think it's a good thing to allow passing arbitrary SPHINXOPTS so let's start with this? ---------- Added file: http://bugs.python.org/file43865/allow_sphinxopts.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 10:51:23 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 24 Jul 2016 14:51:23 +0000 Subject: [issue8623] Aliasing warnings in socketmodule.c In-Reply-To: <1273067856.13.0.617035378143.issue8623@psf.upfronthosting.co.za> Message-ID: <1469371883.57.0.269467625445.issue8623@psf.upfronthosting.co.za> Martin Panter added the comment: The Modules/_multiprocessing/multiprocessing.c code was removed in 3.3 (Issue 12981). Therefore I am calling this fixed. ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 10:56:32 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 24 Jul 2016 14:56:32 +0000 Subject: [issue10036] compiler warnings for various modules on Linux buildslaves In-Reply-To: <1286344285.28.0.174737248843.issue10036@psf.upfronthosting.co.za> Message-ID: <1469372192.78.0.243117715738.issue10036@psf.upfronthosting.co.za> Martin Panter added the comment: The three unused results in Modules/_posixsubprocess.c are probably fixed by revision dd18cccb55b0. The Modules/socketmodule.c pointer aliasing was addressed in 3.3 by Issue 8623, and the Modules/_multiprocessing/multiprocessing.c type-punning has been eliminated in 3.3 by Issue 12981. Also, I tend to agree about the libffi stuff. So I am closing this. ---------- nosy: +martin.panter resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Aliasing warnings in socketmodule.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 11:00:12 2016 From: report at bugs.python.org (Emanuel Barry) Date: Sun, 24 Jul 2016 15:00:12 +0000 Subject: [issue26823] Shrink recursive tracebacks In-Reply-To: <1461292585.22.0.159887337407.issue26823@psf.upfronthosting.co.za> Message-ID: <1469372412.54.0.981996517328.issue26823@psf.upfronthosting.co.za> Emanuel Barry added the comment: Alright, I think this works now. No more magic number, just some regex as well as checking that the number is in range(sys.getrecursionlimit()-50, sys.getrecursionlimit()) :) ---------- Added file: http://bugs.python.org/file43866/short_tracebacks_7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 11:21:04 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 24 Jul 2016 15:21:04 +0000 Subject: [issue27366] PEP487: Simpler customization of class creation In-Reply-To: <1469351045.81.0.567094336717.issue27366@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: That's a no from me. On Sunday, July 24, 2016, Martin Teichmann wrote: > > Martin Teichmann added the comment: > > Thanks for the nice review! > > I made the proposed changes, see attached patch. > > I am still waiting for a decision whether type.__setattr__ should call > __set_name__ from python-dev, once that's sorted out I'll implement and > test the one or the other behavior. > > ---------- > Added file: http://bugs.python.org/file43854/pep487.patch > > _______________________________________ > Python tracker > > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 11:46:17 2016 From: report at bugs.python.org (Sylvia van Os) Date: Sun, 24 Jul 2016 15:46:17 +0000 Subject: [issue27607] Enums never match if imported from another file Message-ID: <1469375177.67.0.287991264427.issue27607@psf.upfronthosting.co.za> New submission from Sylvia van Os: If main imports another file, and this file imports an Enum class from main, isinstance will return false for Enum variables set in this file, causing the Enums to never match. A proof of concept is added as a zip. I thank Kwpolska for simplifying my initial proof of concept. To test this, unzip both files into the same directory and launch main.py with Python 3. I have succesfully been able to reproduce this issue on Python 3.4.3. >From discussion on IRC with Vgr, PEP 499 may be related to this issue: https://www.python.org/dev/peps/pep-0499/. ---------- components: Interpreter Core files: a040de8b978dcc4c272c0571d456a382-ea6d8fb8acc988a1f060c94070f70a6ed8439069.zip messages: 271164 nosy: Kwpolska, SylvieLorxu priority: normal severity: normal status: open title: Enums never match if imported from another file type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file43867/a040de8b978dcc4c272c0571d456a382-ea6d8fb8acc988a1f060c94070f70a6ed8439069.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 12:06:24 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 24 Jul 2016 16:06:24 +0000 Subject: [issue27605] Inconsistent calls to __eq__ from built-in __contains__ In-Reply-To: <1469362395.06.0.246923750082.issue27605@psf.upfronthosting.co.za> Message-ID: <1469376384.8.0.000630149832552.issue27605@psf.upfronthosting.co.za> Raymond Hettinger added the comment: +1 for "approximately equivalent". The "conceptually equivalent" wording raises more questions in my mind than it answers. What we're really trying to say here is that for typically symmetric operations such as __eq__(), an implementation is free to use either a==b or b==a. The choice usually doesn't matter, but can be revealed by a clever user. Pretty all of the pure python equivalents in the docs are only approximate equivalents. 1) Tracebacks are different. 2) Timing of exceptions can be different (C functions tend to check arguments before the body of the function and pure python code tends to check when the argument is used). 3) Thread-safety may be different (C datatypes have to work hard to prevent segfaulting when a container mutates in the middle of a call, but in pure python code that tends to be too expensive and the consequences don't result in a segfault). 4) The internal algorithms may be different. With respect to 4, we really do want to preserve implementation freedom. Otherwise, it would have been impossible to switch to the timsort algorithm or for set intersection to decide to iterate over the smaller input set. Another reason that implementation freedom is important is that what is fast, clear, and convenient in one implementation is may by slow, obscure, and difficult in another. Lastly, the primary purpose of the pure python approximate equivalents in the docs is to help people get a high level understanding of what is going on. If we were to modify the pure python code to be an exact equivalent, it would 1) tend to over-specify the implementation resulting in unnecessary rigidity and 2) it would tend to be more obscure, defeating our goal of making the docs more clear. Perhaps, there should be a general FAQ entry to this effect. The approximate pure python equivalents should be read loosely with the goal of understanding overall functionality and not be interpreted as exact drop in replacements (the PyPy folks can attest that exact drop-in replacements tend to be much more difficult than you might guess). The FAQ should also mention that in order to make even simple examples of pure python code possible, there needs to be generous reading of the code the precludes the uncommon, exotic, or diabolical contortions that the language is capable of doing. For example, after "b = a", there a values that cause all of these assertions to fail "assert a==b; assert b==a; assert a==b;". For another example, after "s = {a, a}", there are values than can cause these to fail "assert a in s; assert len(s) == 1". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 12:07:00 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 24 Jul 2016 16:07:00 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <1469376420.38.0.977018522742.issue24773@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > the time_t OverflowError The issue here is that for a large date, dt.timestamp() returns a float large enough to cause overflow in fromtimestamp. > Let me know if you want any more info. Can you figure out what date causes this (0002-01-01 or 9998-12-12 or both)? What value is returned by dt.timestamp()? Does pure python implementation behave the same as C? (SEt sys.modules['_datetime'] to None before importing datetime to get a pure python implementation.) > In my case the message for the test_all() failure is ?posix/Africa/Casablanca system_transitions?. Do you get this failure only on a 32-bit interpreter? Please add class CasablancaTest(ZoneInfoTest): zonename = 'Africa/Casablanca' to datetimetester.py and run python -mtest -v test_datetime. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 12:11:09 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 24 Jul 2016 16:11:09 +0000 Subject: [issue27493] logging module fails with unclear error when supplied a (Posix)Path In-Reply-To: <1468314884.39.0.604549697605.issue27493@psf.upfronthosting.co.za> Message-ID: <1469376669.14.0.495363583289.issue27493@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 12:18:12 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 24 Jul 2016 16:18:12 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <1469377092.17.0.0370501495582.issue24773@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Looking at the stable buildbots. http://buildbot.python.org/all/waterfall?category=3.x.stable AMD64 OpenIndiana 3.x - unrelated failures AMD64 Snow Leop 3.x - crash in test_all / system_transitions PPC64 Fedora 3.x - fail in test_all Africa/El_Aaiun system_transitions x86 Ubuntu Shared 3.x - two failures: time_t overflow and Africa/El_Aaiun ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 12:27:40 2016 From: report at bugs.python.org (Brett Cannon) Date: Sun, 24 Jul 2016 16:27:40 +0000 Subject: [issue27604] More details about `-O` flag In-Reply-To: <1469353581.38.0.811049911305.issue27604@psf.upfronthosting.co.za> Message-ID: <1469377660.95.0.507054930836.issue27604@psf.upfronthosting.co.za> Brett Cannon added the comment: No, there are only the two optimizations, but I think historically the vagueness has been on purpose to allow us to add appropriate optimizations without breaking backwards-compatibility with what is documented. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 12:27:59 2016 From: report at bugs.python.org (Brett Cannon) Date: Sun, 24 Jul 2016 16:27:59 +0000 Subject: [issue27607] Enums never match if imported from another file In-Reply-To: <1469375177.67.0.287991264427.issue27607@psf.upfronthosting.co.za> Message-ID: <1469377679.93.0.948527331825.issue27607@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 12:28:57 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 24 Jul 2016 16:28:57 +0000 Subject: [issue27607] Enums never match if imported from another file In-Reply-To: <1469375177.67.0.287991264427.issue27607@psf.upfronthosting.co.za> Message-ID: <1469377737.1.0.800883871938.issue27607@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 12:41:12 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 24 Jul 2016 16:41:12 +0000 Subject: [issue26851] android compilation and link flags In-Reply-To: <1461673211.54.0.945034926098.issue26851@psf.upfronthosting.co.za> Message-ID: <1469378472.32.0.429939219194.issue26851@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The previous patch was using awkwardly, a 'host_cpu' configure argument to specify the arm ABI and missed setting LDFLAGS for the armv7 ABI. This patch instead uses the __ARM_ARCH macro defined by each compiler of the Android toolchains: echo | ./clang -target armv7-none-linux-androideabi -dM -E - | grep ARM_ARCH #define __ARM_ARCH 7 #define __ARM_ARCH_7A__ 1 echo | ./clang -target armv5te-none-linux-androideabi -dM -E - | grep ARM_ARCH #define __ARM_ARCH 5 #define __ARM_ARCH_5TE__ 1 echo | ./arm-linux-androideabi-gcc -march=armv7-a -dM -E - | grep ARM_ARCH #define __ARM_ARCH 7 #define __ARM_ARCH_7A__ 1 echo | ./arm-linux-androideabi-gcc -dM -E - | grep ARM_ARCH #define __ARM_ARCH_5TE__ 1 #define __ARM_ARCH 5 Python built with clang for the armv5te target crashes as reported in issue 27606. ---------- assignee: -> xdegaye nosy: +doko, haypo, martin.panter stage: -> patch review Added file: http://bugs.python.org/file43868/build-flags_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 12:44:39 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 24 Jul 2016 16:44:39 +0000 Subject: [issue27598] Add SizedIterable to collections.abc and typing In-Reply-To: <1469288809.56.0.543825422436.issue27598@psf.upfronthosting.co.za> Message-ID: <1469378679.23.0.103572212032.issue27598@psf.upfronthosting.co.za> Raymond Hettinger added the comment: In putting together a patch for this, I noticed that the __subclasshook__ classmethods don't compose well. I'm unclear about the semantics about what these hooks are supposed to mean for subclasses and whether there is a bug in the existing code for Set, Sequence, and Mapping. Each of those inherits from Sized, Iterable, and Container, but only the Sized.__subclasshook__ is visible to the subclass. Also, the code for Sized.__subclasshook__ has an identity check for Sized which doesn't seem correct from the point-of-view of the subclasses. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 12:46:42 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 24 Jul 2016 16:46:42 +0000 Subject: [issue26944] android: test_posix fails In-Reply-To: <1462348873.26.0.373017977506.issue26944@psf.upfronthosting.co.za> Message-ID: <1469378802.47.0.365898201031.issue26944@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- nosy: +haypo stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 12:46:51 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 24 Jul 2016 16:46:51 +0000 Subject: [issue25170] 3.4.4, 3.4.5, 3.5.0, 3.5.1, 3.5.2 documentation archives missing In-Reply-To: <1442601694.39.0.291720811899.issue25170@psf.upfronthosting.co.za> Message-ID: <1469378811.8.0.46849761371.issue25170@psf.upfronthosting.co.za> Ned Deily added the comment: "Perhaps related is that the list at only goes up to 3.4.3." That page is manually updated by the release managers. Note that there are entries on the page for the most recent 2.7.x releases, 2.7.11 and 2.7.12, and the corresponding doc archives are available in /ftp/python/doc. It looks like 3.5.x is the odd duck here and should be updated. Larry? ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 12:57:06 2016 From: report at bugs.python.org (Larry Hastings) Date: Sun, 24 Jul 2016 16:57:06 +0000 Subject: [issue25170] 3.4.4, 3.4.5, 3.5.0, 3.5.1, 3.5.2 documentation archives missing In-Reply-To: <1442601694.39.0.291720811899.issue25170@psf.upfronthosting.co.za> Message-ID: <1469379426.61.0.772605744835.issue25170@psf.upfronthosting.co.za> Larry Hastings added the comment: I can fix it. Are instructions on how to update that in PEP 101 and I missed it? (Do you know where it is in the Django maze of twisty little passages?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 12:57:09 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 Jul 2016 16:57:09 +0000 Subject: [issue22557] Local import is too slow In-Reply-To: <1412512141.77.0.0512115045124.issue22557@psf.upfronthosting.co.za> Message-ID: <1469379429.05.0.250315733995.issue22557@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Seems not all such easy. Looking in sys.module is not enough, we should check __spec__._initializing. Following patch moves optimizations to PyImport_ImportModuleLevelObject (C implementation of standard __import__). Main optimizations: 1. PyImport_ImportModuleLevelObject is called directly if builtins.__import__ is standard __import__. 2. Import lock is not acquired for looking up in sys.modules and other operations. Some of these operations are atomic in C (guarded by GIL), others are used only for optimization and race condition can cause only insignificant slow down. 3. Avoided creating empty dict for globals, looking up __package__ and __spec__ if they are not needed. 4. Saving standard __import__ in interpreter state. Microbenchmarking results: $ ./python -m timeit 'import os' Unpatched: 1000000 loops, best of 3: 0.845 usec per loop Patched: 1000000 loops, best of 3: 0.338 usec per loop $ ./python -m timeit 'import os.path' Unpatched: 100000 loops, best of 3: 2.07 usec per loop Patched: 1000000 loops, best of 3: 0.884 usec per loop $ ./python -m timeit 'from os import path' Unpatched: 100000 loops, best of 3: 3.7 usec per loop Patched: 100000 loops, best of 3: 2.77 usec per loop ---------- Added file: http://bugs.python.org/file43869/faster_import_6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 13:37:20 2016 From: report at bugs.python.org (Aleksandr Koshkin) Date: Sun, 24 Jul 2016 17:37:20 +0000 Subject: [issue27608] Something wrong with str.upper().lower() chain? Message-ID: <1469381840.71.0.0990195629245.issue27608@psf.upfronthosting.co.za> New submission from Aleksandr Koshkin: For some reason >>> '?'.upper().lower() == '?' False ---------- components: Unicode messages: 271174 nosy: ezio.melotti, haypo, magniff priority: normal severity: normal status: open title: Something wrong with str.upper().lower() chain? type: behavior versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 13:46:27 2016 From: report at bugs.python.org (Aleksandr Koshkin) Date: Sun, 24 Jul 2016 17:46:27 +0000 Subject: [issue27608] Something wrong with str.upper().lower() chain? In-Reply-To: <1469381840.71.0.0990195629245.issue27608@psf.upfronthosting.co.za> Message-ID: <1469382387.65.0.521483795878.issue27608@psf.upfronthosting.co.za> Aleksandr Koshkin added the comment: Note, that >>> ord('?') 181 there is another Mu like symbol chr(956), on which this code passes ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 14:14:35 2016 From: report at bugs.python.org (Aleksandr Koshkin) Date: Sun, 24 Jul 2016 18:14:35 +0000 Subject: [issue27608] Something wrong with str.upper().lower() chain? In-Reply-To: <1469381840.71.0.0990195629245.issue27608@psf.upfronthosting.co.za> Message-ID: <1469384075.3.0.28286023677.issue27608@psf.upfronthosting.co.za> Aleksandr Koshkin added the comment: So, yes, unicode table seems to be a bit inconsistent. In str documentation it worth to emphasize that something.upper().lower() in general not equals to something. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 14:25:07 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 24 Jul 2016 18:25:07 +0000 Subject: [issue27608] Something wrong with str.upper().lower() chain? In-Reply-To: <1469381840.71.0.0990195629245.issue27608@psf.upfronthosting.co.za> Message-ID: <1469384707.76.0.138360593175.issue27608@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Here is a little more detail on what is occurring: >>> from unicodedata import * >>> c = '?' >>> for s in (c, c.lower(), c.upper(), c.lower().upper(), c.upper().lower()): print(s, ord(s), name(s), category(s)) ? 181 MICRO SIGN Ll ? 181 MICRO SIGN Ll ? 924 GREEK CAPITAL LETTER MU Lu ? 924 GREEK CAPITAL LETTER MU Lu ? 956 GREEK SMALL LETTER MU Ll ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 14:41:19 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 Jul 2016 18:41:19 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <20160724184116.19893.25272.AE8E76B8@psf.io> Roundup Robot added the comment: New changeset ae19ea7c36e6 by Alexander Belopolsky in branch 'default': Issue #24773: Made ZoneInfoCompleteTest a TestSuit. https://hg.python.org/cpython/rev/ae19ea7c36e6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 15:03:33 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 24 Jul 2016 19:03:33 +0000 Subject: [issue25170] 3.4.4, 3.4.5, 3.5.0, 3.5.1, 3.5.2 documentation archives missing In-Reply-To: <1442601694.39.0.291720811899.issue25170@psf.upfronthosting.co.za> Message-ID: <1469387013.98.0.512257202657.issue25170@psf.upfronthosting.co.za> Ned Deily added the comment: Larry, I updated PEP 101 to reflect I think are the steps required for this with the new website; the doc upload instructions are already in PEP 101. I'm sure it is still missing some steps. Feel free to improve! https://github.com/python/peps/commit/5903b6afd4e658482d382f635a8bb60339668ef1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 15:13:20 2016 From: report at bugs.python.org (Ram Rachum) Date: Sun, 24 Jul 2016 19:13:20 +0000 Subject: [issue27604] More details about `-O` flag In-Reply-To: <1469353581.38.0.811049911305.issue27604@psf.upfronthosting.co.za> Message-ID: <1469387600.69.0.639362779813.issue27604@psf.upfronthosting.co.za> Ram Rachum added the comment: So... The reasoning is that if someone adds optimizations to Python's `-O` mode (Something that hasn't happened in the last decade or two, right?) we want to save them from going to the trouble of writing two or three sentences in the docs describing the optimizations? Isn't it standard practice to require people who contribute code to Python to add documentation for their changes? Anyway, I think that it'll be a good idea to add two or three sentences that document it. Would you like a patch? If so against which version? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 16:31:55 2016 From: report at bugs.python.org (Brett Cannon) Date: Sun, 24 Jul 2016 20:31:55 +0000 Subject: [issue27604] More details about `-O` flag In-Reply-To: <1469353581.38.0.811049911305.issue27604@psf.upfronthosting.co.za> Message-ID: <1469392315.93.0.300298234529.issue27604@psf.upfronthosting.co.za> Brett Cannon added the comment: Two things. One, I don't know if you meant for your comment to come off as antagonistic, but it did. Two, a patch is fine as long as it makes it clear that what optimizations are activated by the flag could change with no backwards-compatibility guarantees. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 17:20:29 2016 From: report at bugs.python.org (Aleksandr Koshkin) Date: Sun, 24 Jul 2016 21:20:29 +0000 Subject: [issue27608] Something wrong with str.upper().lower() chain? In-Reply-To: <1469381840.71.0.0990195629245.issue27608@psf.upfronthosting.co.za> Message-ID: <1469395229.96.0.56302665364.issue27608@psf.upfronthosting.co.za> Aleksandr Koshkin added the comment: Conclusion made: not a bug (not a python bug at least). ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 19:54:55 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 24 Jul 2016 23:54:55 +0000 Subject: [issue22554] Idle: optionally auto-pop-up completion window for names In-Reply-To: <1412455740.59.0.488205604563.issue22554@psf.upfronthosting.co.za> Message-ID: <1469404495.08.0.0960243596461.issue22554@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The extension configuration was added a couple weeks after this was opened. The idea of the second message is that new popup should be optional even when completions are enabled. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 19:58:37 2016 From: report at bugs.python.org (R. David Murray) Date: Sun, 24 Jul 2016 23:58:37 +0000 Subject: [issue27607] Enums never match if imported from another file In-Reply-To: <1469375177.67.0.287991264427.issue27607@psf.upfronthosting.co.za> Message-ID: <1469404717.76.0.355808207471.issue27607@psf.upfronthosting.co.za> R. David Murray added the comment: This is a consequence of the way __main__ works. You actually have two separate instances of the Enum class. If there is a fix for this it would be that PEP, so I'm not sure there is any point in keeping this issue open. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 20:02:45 2016 From: report at bugs.python.org (Sylvia van Os) Date: Mon, 25 Jul 2016 00:02:45 +0000 Subject: [issue27607] Enums never match if imported from another file In-Reply-To: <1469375177.67.0.287991264427.issue27607@psf.upfronthosting.co.za> Message-ID: <1469404965.36.0.433687224901.issue27607@psf.upfronthosting.co.za> Sylvia van Os added the comment: For what it's worth, I am not opposed to having this issue closed. As I am new to reporting anything on the Python issue tracker and was uncertain on how relevant the PEP in question was, I figured it would be better to report this anyway just in case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 20:03:08 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 25 Jul 2016 00:03:08 +0000 Subject: [issue27609] IDLE completions: format, factor, and fix Message-ID: <1469404988.71.0.674184496094.issue27609@psf.upfronthosting.co.za> New submission from Terry J. Reedy: IDLE completions are currently implemented in two files: autocomplete.py and autocomplete_w.py. (Before 3.6, these were AutoComplete.py and AutoCompleteWindow.py.) The first handles 'open' events, decideds whether to open a window, and gathers possible completions. The second open a popup and works with the sorted list of possible completions. There are several tracker issues already. #15786 Code completion problems with mouse and . These lead to freezes on on Mac. Severity: bad; prioriy: high. #16198 Tabbing in string brings up completion when it should not. #17238 Enhance import statement completion. #18766 Add completions for un-imported modules (by importing). #18903 File completions are case sensitive, should not be on Windows. #21261 Complete dictionary keys. #22554 Popup window for names also. #27099 Convert autocomplete to normal feature, along with other 'extensions'. Add delay to current tab. Negative delay should disable auto-popups. #27534 Move objects needed by run to run.py and import from there. There are more that are not on the tracker. Patches may be attached here or to new issues. A. Use PEP8 style. 1.'return None' when there are non-None returns. 2. Docstrings for all functions. B. Merge autocomplete_w into autocomplete. This was anticipated in the renaming. #27534 should be done first if possible, or soon after. C. Refactor. 1 #27534. 2. Put list and scrollbar in Frame? For future single-window IDLE? This might make testing easier. 3. Anything else making tests easier. D. Make completions work for number literals ("1 .") as well a string literals ("'a'."). E?. Make completions work with Entry as well as Multicall wrapping text? Need use case first. Load Modules may need own code. Question: Why does 'dooneevent' appear in 2.x code and not 3.x code? Tests: The currently only for a subset of autocomplete methods. There are none for the buggy window. First, a patch for A.1, return None. ---------- assignee: terry.reedy messages: 271186 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: IDLE completions: format, factor, and fix type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 20:08:07 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 25 Jul 2016 00:08:07 +0000 Subject: [issue27609] IDLE completions: format, factor, and fix In-Reply-To: <1469404988.71.0.674184496094.issue27609@psf.upfronthosting.co.za> Message-ID: <1469405287.79.0.581646731342.issue27609@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Add dependencies. Last two, #27099 and #27534 involve multiple files and should be removed from this autocomplete list when autocomplete part is done. ---------- dependencies: +IDLE - tabbing in a string always brings up file completion window, IDLE code completion window can hang or misbehave with mouse, IDLE: Autocomplete in editor doesn't work for un-imported modules, IDLE: Enhance import statement completion, IDLE: Reduce number and time for user process imports, IDLE: turn builting extensions into regular modules, Idle: optionally auto-pop-up completion window for names, Teach IDLE to Autocomplete dictionary keys _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 20:09:21 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 25 Jul 2016 00:09:21 +0000 Subject: [issue27607] Enums never match if imported from another file In-Reply-To: <1469375177.67.0.287991264427.issue27607@psf.upfronthosting.co.za> Message-ID: <1469405361.85.0.331699518779.issue27607@psf.upfronthosting.co.za> R. David Murray added the comment: Certainly reporting it is fine, if nothing else it gives a record for someone else searching for the same problem. I'm not certain why Raymond left the issue open, so I'm not closing it myself :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 20:16:08 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 25 Jul 2016 00:16:08 +0000 Subject: [issue27607] Enums never match if imported from another file In-Reply-To: <1469375177.67.0.287991264427.issue27607@psf.upfronthosting.co.za> Message-ID: <1469405768.11.0.111538310704.issue27607@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I left it open so that Ethan would get a chance to see anything related to Enum. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 20:35:59 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 25 Jul 2016 00:35:59 +0000 Subject: [issue27609] IDLE completions: format, factor, and fix In-Reply-To: <1469404988.71.0.674184496094.issue27609@psf.upfronthosting.co.za> Message-ID: <20160725003555.60020.70651.4EC315E5@psf.io> Roundup Robot added the comment: New changeset 1ec47de72538 by Terry Jan Reedy in branch 'default': Issue #27609: Explicitly return None when there are other returns. https://hg.python.org/cpython/rev/1ec47de72538 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 20:36:23 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 25 Jul 2016 00:36:23 +0000 Subject: [issue27598] Add SizedIterable to collections.abc and typing In-Reply-To: <1469288809.56.0.543825422436.issue27598@psf.upfronthosting.co.za> Message-ID: <1469406983.21.0.53798762066.issue27598@psf.upfronthosting.co.za> Guido van Rossum added the comment: Regarding the design of __subclasshook__, these two flaws kind of cancel each other out. The idea is that if you have a "one-trick pony" class whose issubclass() check must verify that the purported sublass implements a specific method (e.g. __hash__), you don't want that subclass check to be inherited by a subclass. I suppose perhaps this ought to have been done by making ABCMeta.__subclasscheck__ check for the __subclasshook__ in the class dict, but (for reasons I've forgotten) it's not doing it that way, instead just calling cls.__subclasscheck__. All known __subclasshook__ implementations (those in collections.abc anyway :-) compensate for this by returning NotImplemented if the class for which they are being called isn't exactly the class in which they are defined. The final piece of the puzzle is object.__subclasshook__(), which always returns NotImplemented. (NOTE: When reading the above paragraph, be careful to distinguish between __subclasscheck__, which is invoked by issubclass() and isinstance(), and __subclasshook__, which is only invoked by ABCMeta.__subclasscheck__().) Here's an example showing why we don't want __subclasshook__ to be inherited. Suppose we have a class SupportsInt, like this: class SupportsInt(ABC): @classmethod def __subclasshook__(cls, C): return hasattr(C, '__int__') Now suppose we had a concrete class inheriting from this: class MyInteger(SupportsInt): def __int__(self): return 0 Now, alas, everything with an __int__ method is considered to be a MyInteger, for example isinstance(0, MyInteger) returns True. So what should Collection.__subclasshook__ do? It could do something like this: class Collection(Set, Iterable, Container): @classmethod def __subclasshook__(cls, C): if cls is not Collection: return NotImplemented for base in Set, Iterable, Container: ok = base.__subclasshook__(C) if ok != True: return False return True (Untested, hopefully you get the idea. Hope this helps.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 20:37:00 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 25 Jul 2016 00:37:00 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <20160725003657.58650.28763.5ECF12D2@psf.io> Roundup Robot added the comment: New changeset dca143512f6e by Alexander Belopolsky in branch 'default': Issue 24773: Make zoneinfo tests more robust. (reapply) https://hg.python.org/cpython/rev/dca143512f6e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 20:44:50 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 25 Jul 2016 00:44:50 +0000 Subject: [issue26851] android compilation and link flags In-Reply-To: <1461673211.54.0.945034926098.issue26851@psf.upfronthosting.co.za> Message-ID: <1469407490.48.0.890857486624.issue26851@psf.upfronthosting.co.za> Martin Panter added the comment: I left some suggestions and questions on the code review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 20:48:09 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 25 Jul 2016 00:48:09 +0000 Subject: [issue27546] Integrate tkinter and asyncio (and async) In-Reply-To: <1469324859.8.0.825341124356.issue27546@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: On what platform did you measure that? On a Mac, with Python 3.5.2, I get very different numbers: tkloop: 9000/sec asloop: 90000/sec (about 10x!) tkasyncloop: 2500/sec ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 20:49:50 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 25 Jul 2016 00:49:50 +0000 Subject: [issue27607] Enums never match if imported from another file In-Reply-To: <1469375177.67.0.287991264427.issue27607@psf.upfronthosting.co.za> Message-ID: <1469407790.7.0.895664812074.issue27607@psf.upfronthosting.co.za> Martin Panter added the comment: I would expect isintance() to fail like this for any class, not just Enum. I haven?t looked in your zip file, but a workaround may be to import the Enum class from a third module into both main.py and the other file. The third module should only get executed once, thus only defining one copy of the Enum class. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 20:51:16 2016 From: report at bugs.python.org (Sylvia van Os) Date: Mon, 25 Jul 2016 00:51:16 +0000 Subject: [issue27607] Enums never match if imported from another file In-Reply-To: <1469375177.67.0.287991264427.issue27607@psf.upfronthosting.co.za> Message-ID: <1469407876.9.0.782604522465.issue27607@psf.upfronthosting.co.za> Sylvia van Os added the comment: Importing it from a third module indeed works without issues and makes both isinstance() calls return True, yes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 21:06:05 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 25 Jul 2016 01:06:05 +0000 Subject: [issue27610] Add PEP 514 metadata to Windows installer Message-ID: <1469408765.5.0.0268555752017.issue27610@psf.upfronthosting.co.za> New submission from Steve Dower: Now PEP 514 is accepted, we need to set more information when installing Python 3.6. ---------- assignee: steve.dower components: Windows messages: 271197 nosy: paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Add PEP 514 metadata to Windows installer type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 21:07:17 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 25 Jul 2016 01:07:17 +0000 Subject: [issue27610] Add PEP 514 metadata to Windows installer In-Reply-To: <1469408765.5.0.0268555752017.issue27610@psf.upfronthosting.co.za> Message-ID: <20160725010713.6924.40353.0A8A1689@psf.io> Roundup Robot added the comment: New changeset c6ce1958cebb by Steve Dower in branch 'default': Issue #27610: Adds PEP 514 metadata to Windows installer https://hg.python.org/cpython/rev/c6ce1958cebb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 21:08:06 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 25 Jul 2016 01:08:06 +0000 Subject: [issue27610] Add PEP 514 metadata to Windows installer In-Reply-To: <1469408765.5.0.0268555752017.issue27610@psf.upfronthosting.co.za> Message-ID: <1469408886.79.0.3454913133.issue27610@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 21:23:33 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 25 Jul 2016 01:23:33 +0000 Subject: [issue17238] IDLE: Enhance import statement completion In-Reply-To: <1361287971.25.0.643782901011.issue17238@psf.upfronthosting.co.za> Message-ID: <1469409813.83.0.681425093053.issue17238@psf.upfronthosting.co.za> Martin Panter added the comment: Even if your patch isn?t quite ready, it may (have been) better than nothing :) I had the idea to share stuff between Idle completion and Readline completion, but after looking at the Idle code, it did not seem very practical in general. But maybe you can at least use some ideas, test cases, or share the low level code from Issue 25419. E.g. my patch there has method _import_matches() that takes a path of packages and yields (sub)module names, and method _from_import_matches() that also yields module attribute names. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 21:40:35 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 25 Jul 2016 01:40:35 +0000 Subject: [issue27454] PyUnicode_InternInPlace can use PyDict_SetDefault In-Reply-To: <1467723696.2.0.276855964684.issue27454@psf.upfronthosting.co.za> Message-ID: <20160725014032.58814.21420.67239149@psf.io> Roundup Robot added the comment: New changeset f3187a157204 by Berker Peksag in branch 'default': Issue #27454: Use PyDict_SetDefault in PyUnicode_InternInPlace https://hg.python.org/cpython/rev/f3187a157204 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 21:41:04 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 25 Jul 2016 01:41:04 +0000 Subject: [issue27454] PyUnicode_InternInPlace can use PyDict_SetDefault In-Reply-To: <1467723696.2.0.276855964684.issue27454@psf.upfronthosting.co.za> Message-ID: <1469410864.7.0.526571955912.issue27454@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks! ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 21:45:10 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 25 Jul 2016 01:45:10 +0000 Subject: [issue25966] Bug in asyncio.corotuines._format_coroutine In-Reply-To: <1451321916.38.0.909641421844.issue25966@psf.upfronthosting.co.za> Message-ID: <1469411110.43.0.636536269661.issue25966@psf.upfronthosting.co.za> Berker Peksag added the comment: Merged in f4fe55dd5659. ---------- nosy: +berker.peksag stage: -> resolved status: open -> closed type: -> behavior versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 21:56:17 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 25 Jul 2016 01:56:17 +0000 Subject: [issue27601] Minor inaccuracy in hash documentation In-Reply-To: <1469297872.54.0.246840894647.issue27601@psf.upfronthosting.co.za> Message-ID: <20160725015614.20112.55681.6ECC9497@psf.io> Roundup Robot added the comment: New changeset a6be689eacf8 by Berker Peksag in branch '3.5': Issue #27601: Improve example in the "Hashing of numeric types" section https://hg.python.org/cpython/rev/a6be689eacf8 New changeset 06bbcbaeeb18 by Berker Peksag in branch 'default': Issue #27601: Merge from 3.5 https://hg.python.org/cpython/rev/06bbcbaeeb18 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 21:58:16 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 25 Jul 2016 01:58:16 +0000 Subject: [issue27601] Minor inaccuracy in hash documentation In-Reply-To: <1469297872.54.0.246840894647.issue27601@psf.upfronthosting.co.za> Message-ID: <1469411896.36.0.25069057311.issue27601@psf.upfronthosting.co.za> Berker Peksag added the comment: Looks good to me too. 'hash_value' looks more readable to me, thanks! ---------- nosy: +berker.peksag resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> behavior versions: -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 22:03:42 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 25 Jul 2016 02:03:42 +0000 Subject: [issue27587] Issues, reported by PVS-Studio static analyzer In-Reply-To: <1469172132.31.0.293406285451.issue27587@psf.upfronthosting.co.za> Message-ID: <1469412222.75.0.0361618526929.issue27587@psf.upfronthosting.co.za> Berker Peksag added the comment: I'm attaching Christian's patch at https://marc.info/?l=python-dev&m=146922730716425&w=2 as issue27587_pystate_addmodule.diff to make code reviewing easier. ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 22:03:54 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 25 Jul 2016 02:03:54 +0000 Subject: [issue27587] Issues, reported by PVS-Studio static analyzer In-Reply-To: <1469172132.31.0.293406285451.issue27587@psf.upfronthosting.co.za> Message-ID: <1469412234.16.0.253222801483.issue27587@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- keywords: +patch Added file: http://bugs.python.org/file43870/issue27587_pystate_addmodule.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 22:07:16 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 25 Jul 2016 02:07:16 +0000 Subject: [issue27611] test_tix cannot import _default_root after test_idle Message-ID: <1469412436.77.0.964864196793.issue27611@psf.upfronthosting.co.za> New submission from Martin Panter: $ ./python -m unittest -v test.test_{idle,tix} . . . test_tix (unittest.loader._FailedTest) ... ERROR ====================================================================== ERROR: test_tix (unittest.loader._FailedTest) ---------------------------------------------------------------------- ImportError: Failed to import test module: test_tix Traceback (most recent call last): File "/media/disk/home/proj/python/cpython/Lib/unittest/loader.py", line 153, in loadTestsFromName module = __import__(module_name) File "/media/disk/home/proj/python/cpython/Lib/test/test_tix.py", line 11, in from tkinter import tix, TclError File "/media/disk/home/proj/python/cpython/Lib/tkinter/tix.py", line 30, in from tkinter import _cnfmerge, _default_root ImportError: cannot import name '_default_root' Without test_idle, test_tix is skipped for me: $ ./python -m unittest -v test.test_tix test_tix_available (test.test_tix.TestTix) ... skipped 'Tix not available' Reverting to before revision 064b29dde096 (Issue 24137) also fixes the failure. ---------- components: Tests messages: 271206 nosy: martin.panter, serhiy.storchaka, terry.reedy priority: normal severity: normal status: open title: test_tix cannot import _default_root after test_idle type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 22:07:48 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 25 Jul 2016 02:07:48 +0000 Subject: [issue24137] Force not using _default_root in IDLE In-Reply-To: <1430925977.27.0.721479362057.issue24137@psf.upfronthosting.co.za> Message-ID: <1469412468.25.0.910160914177.issue24137@psf.upfronthosting.co.za> Martin Panter added the comment: It seems this change causes test_tix to fail for me; see Issue 27611 ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 22:22:00 2016 From: report at bugs.python.org (Aleksandr Koshkin) Date: Mon, 25 Jul 2016 02:22:00 +0000 Subject: [issue27601] Minor inaccuracy in hash documentation In-Reply-To: <1469297872.54.0.246840894647.issue27601@psf.upfronthosting.co.za> Message-ID: <1469413320.95.0.518009406498.issue27601@psf.upfronthosting.co.za> Aleksandr Koshkin added the comment: Originally I emphasized that this bug occurs at every py3k version since 3.2. For some reason version list somehow shrinked to only tow of them - 3.5 and 3.6. I am very sorry, this is probably my fault. ---------- resolution: fixed -> status: closed -> open versions: +Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 22:22:33 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 25 Jul 2016 02:22:33 +0000 Subject: [issue7063] Memory errors in array.array In-Reply-To: <1254730349.27.0.71088310024.issue7063@psf.upfronthosting.co.za> Message-ID: <20160725022226.24149.35625.F5DA3355@psf.io> Roundup Robot added the comment: New changeset ab28676df655 by Martin Panter in branch 'default': Issue #7063: Remove dead code from array slice handling https://hg.python.org/cpython/rev/ab28676df655 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 22:23:55 2016 From: report at bugs.python.org (Ethan Furman) Date: Mon, 25 Jul 2016 02:23:55 +0000 Subject: [issue27607] Enums never match if imported from another file In-Reply-To: <1469375177.67.0.287991264427.issue27607@psf.upfronthosting.co.za> Message-ID: <1469413435.57.0.85531458839.issue27607@psf.upfronthosting.co.za> Ethan Furman added the comment: Sylvia, if you have any control over the name of your zip files, please use something shorter. ;) The files inside are a 'main.py' and a 'module.py' -- notice there is no '__main__.py'. So it can't be executed as 'python3 -m blahblah'. I tried renaming 'main.py' to '__main__.py' but then I get either ImportError: cannot import name 'Module' or ImportError: No module named 'module' I'm happy to check for strange Enum interactions, but I need a working test case first. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 22:25:20 2016 From: report at bugs.python.org (Emanuel Barry) Date: Mon, 25 Jul 2016 02:25:20 +0000 Subject: [issue27608] Something wrong with str.upper().lower() chain? In-Reply-To: <1469381840.71.0.0990195629245.issue27608@psf.upfronthosting.co.za> Message-ID: <1469413520.03.0.114600954969.issue27608@psf.upfronthosting.co.za> Changes by Emanuel Barry : ---------- resolution: -> not a bug stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 22:25:25 2016 From: report at bugs.python.org (Ethan Furman) Date: Mon, 25 Jul 2016 02:25:25 +0000 Subject: [issue27607] Enums never match if imported from another file In-Reply-To: <1469375177.67.0.287991264427.issue27607@psf.upfronthosting.co.za> Message-ID: <1469413525.88.0.330381966233.issue27607@psf.upfronthosting.co.za> Ethan Furman added the comment: Oh, forgot to mention I also tried testing as just 'main.py' from inside the test directory (that's what accounted for one of the two error messages). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 22:31:44 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 25 Jul 2016 02:31:44 +0000 Subject: [issue27601] Minor inaccuracy in hash documentation In-Reply-To: <1469297872.54.0.246840894647.issue27601@psf.upfronthosting.co.za> Message-ID: <1469413904.09.0.607547622594.issue27601@psf.upfronthosting.co.za> Berker Peksag added the comment: > I am very sorry, this is probably my fault. It's not your fault :) I removed them. 3.2, 3.3 and 3.4 are in security-fix-only mode so they won't get any documentation updates. You can read https://docs.python.org/devguide/devcycle.html#secbranch for details about security branches. Thanks for the report! ---------- resolution: -> fixed status: open -> closed versions: -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 22:35:42 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 25 Jul 2016 02:35:42 +0000 Subject: [issue18766] IDLE: Autocomplete in editor doesn't work for un-imported modules In-Reply-To: <1376703586.47.0.0617094548794.issue18766@psf.upfronthosting.co.za> Message-ID: <1469414142.52.0.890234668826.issue18766@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I opened #27609 to keep track of multiple completion issues. Some additions to what I said above. 1. I would like to move the actual fetch code to run.py, since it is normally executed in the user process. See #27534, but also below. 2. Idle currently differentiates between completion invocation by or '.' and by <>, which defaults to Cntl-space. I believe a main difference is that it will only call functions in the object expression, as in "f().", in the latter case. I believe the distinction operates by calling for completions or not. (I need to check.) That distinction can be used here by only importing with <>, and then it should. With that limitation, I think I am now in favor of adding this. Importing a module is roughly equivalent to calling a function. Either can do anything. But the distinction has be known within the fetch code. This could be done with a wrapper function. ---------- versions: +Python 3.6 -Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 22:41:24 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 25 Jul 2016 02:41:24 +0000 Subject: [issue27609] IDLE completions: format, factor, and fix In-Reply-To: <1469404988.71.0.674184496094.issue27609@psf.upfronthosting.co.za> Message-ID: <1469414484.44.0.144885935652.issue27609@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I just partly fixed #16198. Anything more depends on a careful definition of desired behavior that turns out to be different from current behavior. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 22:42:32 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 25 Jul 2016 02:42:32 +0000 Subject: [issue18766] IDLE: Autocomplete in editor doesn't work for un-imported modules In-Reply-To: <1376703586.47.0.0617094548794.issue18766@psf.upfronthosting.co.za> Message-ID: <1469414552.39.0.061442205267.issue18766@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The concern about adding bugs could be alleviated by checking whether the name is in an import statement. But it still might not be in the proper form. I am trying to reduce the run.py import to those actually needed in run.py. I already reduced sys.modules by 37. The side effect is that fewer modules will autocomplete before running the code in the editor. Hence, there is more need for this change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 22:45:10 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 25 Jul 2016 02:45:10 +0000 Subject: [issue7063] Memory errors in array.array In-Reply-To: <1254730349.27.0.71088310024.issue7063@psf.upfronthosting.co.za> Message-ID: <1469414710.84.0.263545343057.issue7063@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 Jul 24 22:51:20 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 25 Jul 2016 02:51:20 +0000 Subject: [issue17238] IDLE: Add import statement completion In-Reply-To: <1361287971.25.0.643782901011.issue17238@psf.upfronthosting.co.za> Message-ID: <1469415080.61.0.480972183658.issue17238@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I change 'enhance' to 'add' because there is no 'import completion' now. Ramchandra, when replying by email, delete the quoted email. But do submit a patch even is less than perfect. The idea of autoimporting a name to complete an attribute is separate from the idea of doing something special in import statements. Autoimport is the subject of #18766, which has a patch and my thoughts so far. So this issue is only about import statements. Martin, I just opened #27609 as an umbrella issue for multiple completion issues. I am not happy with the current IDLE completion code. Does any of the readline completion code depend on function provided by readline, or is it all an extension of readline, using logic in Python? ---------- title: IDLE: Enhance import statement completion -> IDLE: Add import statement completion versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 22:56:20 2016 From: report at bugs.python.org (Emanuel Barry) Date: Mon, 25 Jul 2016 02:56:20 +0000 Subject: [issue27607] Importing the main module twice leads to two incompatible instances In-Reply-To: <1469375177.67.0.287991264427.issue27607@psf.upfronthosting.co.za> Message-ID: <1469415380.09.0.106079789099.issue27607@psf.upfronthosting.co.za> Emanuel Barry added the comment: I'm fairly sure enums aren't related to this issue, so I'm unassigning Ethan (but feel free to self-assign back if you so desire :). As I said on IRC (I'm Vgr), I think that importing a module twice is the problem here, and that PEP 499 is the way to properly solve this and related issues. Thanks for opening this issue! I added Cameron Simpson (PEP 499's author) to the nosy list, hoping he still wants to work on this (and let us know otherwise). I would personally like to see the PEP accepted and implemented for 3.6. ---------- assignee: ethan.furman -> nosy: +cameron, ebarry title: Enums never match if imported from another file -> Importing the main module twice leads to two incompatible instances versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 23:01:51 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 25 Jul 2016 03:01:51 +0000 Subject: [issue19198] Improve cross-references in cgi documentation In-Reply-To: <1381266335.84.0.645626523869.issue19198@psf.upfronthosting.co.za> Message-ID: <20160725030148.20197.75596.61784CE8@psf.io> Roundup Robot added the comment: New changeset 128ad410c776 by Terry Jan Reedy in branch 'default': Issue #19198: IDLE: tab after initial whitespace should tab, not autocomplete. https://hg.python.org/cpython/rev/128ad410c776 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 23:02:43 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 Jul 2016 03:02:43 +0000 Subject: [issue27611] test_tix cannot import _default_root after test_idle In-Reply-To: <1469412436.77.0.964864196793.issue27611@psf.upfronthosting.co.za> Message-ID: <1469415763.36.0.0703121564902.issue27611@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There is a bug in tix. _default_root shouldn't be imported, since this is modifiable attribute. ---------- keywords: +patch stage: -> patch review versions: +Python 2.7, Python 3.5 Added file: http://bugs.python.org/file43871/tix_default_root.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 23:10:06 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 25 Jul 2016 03:10:06 +0000 Subject: [issue27611] test_tix cannot import _default_root after test_idle In-Reply-To: <1469412436.77.0.964864196793.issue27611@psf.upfronthosting.co.za> Message-ID: <1469416206.08.0.426744405479.issue27611@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I could reverse the effect of test_idle calling tk.NoDefaultRoot by adding tk._support_default_root = 1 tk._default_root = None at the very end, but I take Serhiy's comment as suggesting that there should be no need. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 23:34:54 2016 From: report at bugs.python.org (Zachary Ware) Date: Mon, 25 Jul 2016 03:34:54 +0000 Subject: [issue27611] test_tix cannot import _default_root after test_idle In-Reply-To: <1469412436.77.0.964864196793.issue27611@psf.upfronthosting.co.za> Message-ID: <1469417694.71.0.735377854554.issue27611@psf.upfronthosting.co.za> Zachary Ware added the comment: I think there are two bugs to be fixed here: 1) as Serhiy said, if tix needs _default_root, it should use it as tkinter._default_root instead of importing it directly 2) test_idle should not permanently modify the tkinter namespace ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 23:44:28 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 25 Jul 2016 03:44:28 +0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <20160725034425.11288.28456.6F084F65@psf.io> Roundup Robot added the comment: New changeset db93af6080e7 by Martin Panter in branch 'default': Issue #1621: Avoid signed overflow in list and tuple operations https://hg.python.org/cpython/rev/db93af6080e7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 23:44:28 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 25 Jul 2016 03:44:28 +0000 Subject: [issue27581] Fix overflow check in PySequence_Tuple In-Reply-To: <1469079408.21.0.622161481276.issue27581@psf.upfronthosting.co.za> Message-ID: <20160725034425.11288.66371.C65CBFB6@psf.io> Roundup Robot added the comment: New changeset ad3762227655 by Martin Panter in branch '3.5': Issue #27581: Don?t rely on overflow wrapping in PySequence_Tuple() https://hg.python.org/cpython/rev/ad3762227655 New changeset 8f84942a0e40 by Martin Panter in branch 'default': Issue #27581: Merge overflow fix from 3.5 https://hg.python.org/cpython/rev/8f84942a0e40 New changeset 55b6e51b878b by Martin Panter in branch '2.7': Issue #27581: Don?t rely on overflow wrapping in PySequence_Tuple() https://hg.python.org/cpython/rev/55b6e51b878b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 23:48:27 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 25 Jul 2016 03:48:27 +0000 Subject: [issue26462] Patch to enhance literal block language declaration In-Reply-To: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za> Message-ID: <1469418507.4.0.806961910634.issue26462@psf.upfronthosting.co.za> Changes by Martin Panter : Added file: http://bugs.python.org/file43872/issue26462.v3_regen.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 00:32:09 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 25 Jul 2016 04:32: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: <20160725043206.21334.32119.EEEF3493@psf.io> Roundup Robot added the comment: New changeset 5c76f787e695 by Terry Jan Reedy in branch 'default': Issue #24137, issue #27611: Restore tkinter after test_idle. https://hg.python.org/cpython/rev/5c76f787e695 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 00:32:09 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 25 Jul 2016 04:32:09 +0000 Subject: [issue27611] test_tix cannot import _default_root after test_idle In-Reply-To: <1469412436.77.0.964864196793.issue27611@psf.upfronthosting.co.za> Message-ID: <20160725043206.21334.7232.137D4056@psf.io> Roundup Robot added the comment: New changeset 5c76f787e695 by Terry Jan Reedy in branch 'default': Issue #24137, issue #27611: Restore tkinter after test_idle. https://hg.python.org/cpython/rev/5c76f787e695 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 00:37:35 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 25 Jul 2016 04:37:35 +0000 Subject: [issue27611] test_tix cannot import _default_root after test_idle In-Reply-To: <1469412436.77.0.964864196793.issue27611@psf.upfronthosting.co.za> Message-ID: <1469421455.64.0.31875179631.issue27611@psf.upfronthosting.co.za> Terry J. Reedy added the comment: #24137 only patched default, so either too many versions were selected or there is another bug in test_tix. Martin and Serhiy can sort that out. The restore patch I pushed is based on this from tkinter.__init__ ----- _support_default_root = 1 _default_root = None def NoDefaultRoot(): """Inhibit setting of default root window. Call this function to inhibit that the first instance of Tk is used for windows without an explicit parent window. """ global _support_default_root _support_default_root = 0 global _default_root _default_root = None del _default_root ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 00:46:18 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 25 Jul 2016 04:46:18 +0000 Subject: [issue27546] Integrate tkinter and asyncio (and async) In-Reply-To: <1468815010.57.0.709565417017.issue27546@psf.upfronthosting.co.za> Message-ID: <1469421978.53.0.494810829711.issue27546@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Windows 10, repository default (3.6), with tcl/tk 8.6.4. I am not sure what to make of your results. I have an impression that tk on Mac was considerably rewritten for 8.6. Ned would know more about that. Which were you using? "print(tkinter.TkVersion)" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 00:47:34 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 25 Jul 2016 04:47:34 +0000 Subject: [issue27546] Integrate tkinter and asyncio (and async) In-Reply-To: <1468815010.57.0.709565417017.issue27546@psf.upfronthosting.co.za> Message-ID: <1469422054.46.0.387164218032.issue27546@psf.upfronthosting.co.za> Guido van Rossum added the comment: OK, I'm playing with this too. I merged your loop_tk.py example with crawl.py and am attaching the result as tkcrawl.py. I don't like global state so I added root and loop as parameters to a few places. Hopefully you have the asyncio repo checked out so you can compare this with the original crawl.py -- it basically has your code (with globals replaced by locals or instance variables) and these three lines in main() once loop is set: + root = tk.Tk() + t = asyncio.Task(display_date(root, loop, 100, 1)) + tk_update(root, loop) and a loop.run_forever() call just before the loop.close() call, to keep the app running once it's done. There are also two imports near the top (datetime and tkinter as tk). (Oh, and I just realized I made some changes to crawl.py to suppress displaying the URL of every HTML page retrieved when -q is given. I will commit that.) Running this will display the widget with the hello label and the button to change the color, *and* update the date every second, and it's totally responsive, all *while* it is fetching contents from e.g. xkcd.com. ---------- Added file: http://bugs.python.org/file43873/tkcrawl.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 00:58:20 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 25 Jul 2016 04:58:20 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <1469422700.84.0.248770822781.issue24773@psf.upfronthosting.co.za> Martin Panter added the comment: Without blocking the C implementation _datetime, I get both extremes causing OverflowError: >>> import datetime, time, os >>> os.environ["TZ"] = "EST+05EDT,M3.2.0,M11.1.0" >>> time.tzset() >>> t = datetime.datetime(2,1,1) >>> s = t.timestamp() >>> s -122233584944.0 >>> datetime.datetime.fromtimestamp(s) OverflowError: timestamp out of range for platform time_t >>> t = datetime.datetime(9998,12,12) >>> s = t.timestamp() >>> s 760175195728.0 >>> datetime.datetime.fromtimestamp(s) OverflowError: timestamp out of range for platform time_t When I repeated the test with sys["_datetime"] = None, both t.timestamp() calls raised OverflowError, which I assume is expected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 01:03:45 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 25 Jul 2016 05:03:45 +0000 Subject: [issue27546] Integrate tkinter and asyncio (and async) In-Reply-To: <1468815010.57.0.709565417017.issue27546@psf.upfronthosting.co.za> Message-ID: <1469423025.49.0.0847903995065.issue27546@psf.upfronthosting.co.za> Guido van Rossum added the comment: PS. I recommend this command line to play with tkcrawl.py: python3 tkcrawl.py xkcd.com -q The fetching process takes about 6.8 seconds to fetch 1765 URLs on my machine. The original crawl.py takes 6.2 seconds. I guess the next step would be to hook up the logger to a Tk text widget. It would also be nice to have a set of Tk widgets keep track of the state of the connections in the ConnectionPool, showing for each connection what its state it. It's a little tricky because connections get opened and closed at random; I would recommend using a table assigning connections slots in the widget. The number of lines in the widget is limited by max_pool. (I would code up more of this myself except my Tkinter is rusty!) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 01:04:41 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 25 Jul 2016 05:04:41 +0000 Subject: [issue27546] Integrate tkinter and asyncio (and async) In-Reply-To: <1468815010.57.0.709565417017.issue27546@psf.upfronthosting.co.za> Message-ID: <1469423081.44.0.777755859089.issue27546@psf.upfronthosting.co.za> Guido van Rossum added the comment: Oh, my tkinter.TkVersion is 8.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 01:05:42 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 25 Jul 2016 05:05:42 +0000 Subject: [issue26462] Patch to enhance literal block language declaration In-Reply-To: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za> Message-ID: <1469423142.12.0.460352943356.issue26462@psf.upfronthosting.co.za> Martin Panter added the comment: With Julien?s patch applied, these are the remaining warnings: /media/disk/home/proj/python/cpython/Doc/library/configparser.rst:240: WARNING: Could not lex literal_block as "ini". Highlighting skipped. /media/disk/home/proj/python/cpython/Doc/library/configparser.rst:301: WARNING: Could not lex literal_block as "ini". Highlighting skipped. /media/disk/home/proj/python/cpython/Doc/library/configparser.rst:332: WARNING: Could not lex literal_block as "ini". Highlighting skipped. /media/disk/home/proj/python/cpython/Doc/library/configparser.rst:341: WARNING: Could not lex literal_block as "ini". Highlighting skipped. /media/disk/home/proj/python/cpython/Doc/reference/lexical_analysis.rst:799: WARNING: Could not lex literal_block as "python3". Highlighting skipped. /media/disk/home/proj/python/cpython/Doc/reference/lexical_analysis.rst:813: WARNING: Could not lex literal_block as "python3". Highlighting skipped. /media/disk/home/proj/python/cpython/Doc/whatsnew/2.4.rst:1430: WARNING: Could not lex literal_block as "python3". Highlighting skipped. /media/disk/home/proj/python/cpython/Doc/whatsnew/3.5.rst:285: WARNING: Could not lex literal_block as "python3". Highlighting skipped. /media/disk/home/proj/python/cpython/Doc/whatsnew/3.5.rst:294: WARNING: Could not lex literal_block as "python3". Highlighting skipped. Also, perhaps you didn?t see Georg?s comment in some unpatched code: ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 01:09:37 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 25 Jul 2016 05:09:37 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <1469423377.54.0.0268153762411.issue24773@psf.upfronthosting.co.za> Martin Panter added the comment: I _think_ the system_transitions failure only happens for 32 bit (have to test more to be sure). (My 32-bit environment is lacking many libraries compared to main 64-bit environment, but still uses the same filesystem etc.) First system_transitions failure with today?s new code: FAIL: test_system_transitions (test.datetimetester.ZoneInfoTest[posix/Africa/Casablanca]) ---------------------------------------------------------------------- Traceback (most recent call last): File "/media/disk/home/proj/python/cpython/Lib/test/datetimetester.py", line 4760, in test_system_transitions self.assertEquivDatetimes(sdt, tzdt) File "/media/disk/home/proj/python/cpython/Lib/test/datetimetester.py", line 4687, in assertEquivDatetimes (b.replace(tzinfo=None), b.fold, id(b.tzinfo))) AssertionError: Tuples differ: (datetime.datetime(2037, 10, 11, 3, 0), 0, 140273296) != (datetime.datetime(2037, 10, 11, 2, 0, fold=1), 1, 140273296) First differing element 0: datetime.datetime(2037, 10, 11, 3, 0) datetime.datetime(2037, 10, 11, 2, 0, fold=1) - (datetime.datetime(2037, 10, 11, 3, 0), 0, 140273296) ? ^ ^ + (datetime.datetime(2037, 10, 11, 2, 0, fold=1), 1, 140273296) ? ^ ++++++++ ^ Your CasablancaTest gave the same failure: ====================================================================== FAIL: test_system_transitions (test.datetimetester.CasablancaTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/media/disk/home/proj/python/cpython/Lib/test/datetimetester.py", line 4760, in test_system_transitions self.assertEquivDatetimes(sdt, tzdt) File "/media/disk/home/proj/python/cpython/Lib/test/datetimetester.py", line 4687, in assertEquivDatetimes (b.replace(tzinfo=None), b.fold, id(b.tzinfo))) AssertionError: Tuples differ: (datetime.datetime(2037, 10, 11, 3, 0), 0, 140273296) != (datetime.datetime(2037, 10, 11, 2, 0, fold=1), 1, 140273296) First differing element 0: datetime.datetime(2037, 10, 11, 3, 0) datetime.datetime(2037, 10, 11, 2, 0, fold=1) - (datetime.datetime(2037, 10, 11, 3, 0), 0, 140273296) ? ^ ^ + (datetime.datetime(2037, 10, 11, 2, 0, fold=1), 1, 140273296) ? ^ ++++++++ ^ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 01:12:42 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 25 Jul 2016 05:12:42 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1469422700.84.0.248770822781.issue24773@psf.upfronthosting.co.za> Message-ID: <7D54FF16-DF58-4233-B03D-E1D8FD05F9DA@gmail.com> Alexander Belopolsky added the comment: That's very helpful. It looks like on a Mac 32-bit build has 64-bit time_t. I'll build a 32-bit Python on Linux tomorrow and try to get to the bottom of this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 01:25:38 2016 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Mon, 25 Jul 2016 05:25:38 +0000 Subject: [issue27590] tarfile module next() method hides exceptions In-Reply-To: <1469200266.16.0.443973453456.issue27590@psf.upfronthosting.co.za> Message-ID: <1469424338.41.0.905872850115.issue27590@psf.upfronthosting.co.za> Lars Gust?bel added the comment: The question is what you're trying to accomplish. If you just want to prevent tarfile from stopping at the first invalid header in order to extract everything following it, you may use the ignore_zeros=True keyword argument. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 02:22:06 2016 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Jul 2016 06:22:06 +0000 Subject: [issue25170] 3.4.4, 3.4.5, 3.5.0, 3.5.1, 3.5.2 documentation archives missing In-Reply-To: <1442601694.39.0.291720811899.issue25170@psf.upfronthosting.co.za> Message-ID: <1469427726.43.0.23774015237.issue25170@psf.upfronthosting.co.za> Larry Hastings added the comment: Okay, I've updated the doc, and verified that the links work. The releases/3.5.0 directory had problems; it had bad permissions, and was stuck on 3.5.0a3 or something. I blew it away and installed the 3.5.0 final docs from the tarball and set the permissions by hand. Is this bug fixed now? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 02:27:54 2016 From: report at bugs.python.org (Matt Robenolt) Date: Mon, 25 Jul 2016 06:27:54 +0000 Subject: [issue27612] socket.gethostbyname resolving octal IP addresses incorrectly Message-ID: <1469428074.1.0.701366093272.issue27612@psf.upfronthosting.co.za> New submission from Matt Robenolt: This also affects socket.getaddrinfo on macOS only, but is fine on Linux. I've not tested on Windows to see behavior there. Given the IP address `0177.0000.0000.0001`, which is a valid octal format representing `127.0.0.1`, we can see varying results. Confirmed in both python 2.7 and 3.5. First, socket.gethostbyname is always wrong, and always returns `177.0.0.1`: ``` >>> socket.gethostbyname('0177.0000.0000.0001') '177.0.0.1' ``` This can be seen on both Linux and macOS. With `socket.getaddrinfo`, resolution is correct on Linux, but the bad 177.0.0.1 on macOS. Linux: ``` >>> socket.getaddrinfo('0177.0000.0000.0001', None)[0] (2, 1, 6, '', ('127.0.0.1', 0)) ``` macOS: ``` >>> socket.getaddrinfo('0177.0000.0000.0001', None)[0] (2, 2, 17, '', ('177.0.0.1', 0)) ``` This behavior exists in both 2.7.12 and 3.5.2 at least. I haven't tested many others, but I assume pretty universal. ---------- components: Library (Lib) messages: 271237 nosy: mattrobenolt priority: normal severity: normal status: open title: socket.gethostbyname resolving octal IP addresses incorrectly type: behavior versions: Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 02:44:30 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 25 Jul 2016 06:44:30 +0000 Subject: [issue27546] Integrate tkinter and asyncio (and async) In-Reply-To: <1468815010.57.0.709565417017.issue27546@psf.upfronthosting.co.za> Message-ID: <1469429070.22.0.950650094212.issue27546@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I was thinking of starting (Mon. afternoon/evening, its now 2:40 am) with updating done stats with every done fetcher, updating stat display every second, and listing urls with html body, with a way to view the body. Log to text easy too. Table of connections will require experiments with ttk.Treeview, which I want to do anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 02:47:50 2016 From: report at bugs.python.org (koobs) Date: Mon, 25 Jul 2016 06:47:50 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <1469429270.56.0.652633488131.issue24773@psf.upfronthosting.co.za> koobs added the comment: koobs-freebsd-* 3.x builds are now passing, but I'd like to make an additional (trivial) proposal, and that is: If the tests that were previously failling, aren't *specifically* testing for 'backward compatible' timezone definitions, that the tests that currently use $ROOT/Iran timezone file, instead use a timezone file that is *not* contained within the 'backwards' (backwards compatible) timezone file in the zoneinfo distribution, which may or may not be installed in various environments. For example, the tests could instead use Asia/Tehran ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 03:29:08 2016 From: report at bugs.python.org (Ram Rachum) Date: Mon, 25 Jul 2016 07:29:08 +0000 Subject: [issue27604] More details about `-O` flag In-Reply-To: <1469353581.38.0.811049911305.issue27604@psf.upfronthosting.co.za> Message-ID: <1469431748.38.0.124802756756.issue27604@psf.upfronthosting.co.za> Ram Rachum added the comment: Yes, my comment was antagonistic. I'm baffled that the first response to someone who wants to contribute to Python is an esoteric argument against the contribution. I understand that sometimes not all contributions can be accepted because they break existing assumptions, but since that's not the case here, I think that this kind of responses just put people off contributing. How about "Great idea, lots of people have been asking about Python's optimization mode on Stack Overflow and it'll be much nicer if they could see this information officially in the docs where they have more confidence that this information is correct. Except one thing, could you please mention that this behavior could change in future versions? This is important." Anyway, I'll send a patch later. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 04:02:40 2016 From: report at bugs.python.org (Julien) Date: Mon, 25 Jul 2016 08:02:40 +0000 Subject: [issue26462] Patch to enhance literal block language declaration In-Reply-To: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za> Message-ID: <1469433760.29.0.120950408829.issue26462@psf.upfronthosting.co.za> Julien added the comment: Upladed a new patch, I was working on 3.5 branch so I did not get all errors. I'm still having: WARNING: Could not parse literal_block as "ini". highlighting skipped. But it may be considered another bug: pygments ini parser can't parse ini syntax used in configparser doc (probably due to the columns usage instead of equals signs): I prefer having an "can't parse ini" on an ini paragraph than "can't parse python3". ---------- Added file: http://bugs.python.org/file43874/issue26462.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 04:04:14 2016 From: report at bugs.python.org (Julien) Date: Mon, 25 Jul 2016 08:04:14 +0000 Subject: [issue26462] Patch to enhance literal block language declaration In-Reply-To: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za> Message-ID: <1469433854.64.0.907202516533.issue26462@psf.upfronthosting.co.za> Julien added the comment: Oh and, is there a proper way for me to generate a diff that rietveld can eat without someone regeneratig it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 04:08:47 2016 From: report at bugs.python.org (SilentGhost) Date: Mon, 25 Jul 2016 08:08:47 +0000 Subject: [issue27612] socket.gethostbyname resolving octal IP addresses incorrectly In-Reply-To: <1469428074.1.0.701366093272.issue27612@psf.upfronthosting.co.za> Message-ID: <1469434127.25.0.704649657845.issue27612@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- components: +Macintosh nosy: +ned.deily, ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 05:05:40 2016 From: report at bugs.python.org (Cameron Simpson) Date: Mon, 25 Jul 2016 09:05:40 +0000 Subject: [issue27607] Importing the main module twice leads to two incompatible instances In-Reply-To: <1469415380.09.0.106079789099.issue27607@psf.upfronthosting.co.za> Message-ID: <20160725090535.GA69079@cskk.homeip.net> Cameron Simpson added the comment: On 25Jul2016 02:56, Python Bug Reports wrote: > >Emanuel Barry added the comment: > >I'm fairly sure enums aren't related to this issue, so I'm unassigning Ethan (but feel free to self-assign back if you so desire :). As I said on IRC (I'm Vgr), I think that importing a module twice is the problem here, and that PEP 499 is the way to properly solve this and related issues. Thanks for opening this issue! > >I added Cameron Simpson (PEP 499's author) to the nosy list, hoping he still >wants to work on this (and let us know otherwise). I would personally like to >see the PEP accepted and implemented for 3.6. Thank you; I do want to finish off PEP 499 and get it accepted. I have been very remiss in pursuing that. What can I do to assist here? Cheers, Cameron Simpson ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 05:09:12 2016 From: report at bugs.python.org (Ludovic Gasc) Date: Mon, 25 Jul 2016 09:09:12 +0000 Subject: [issue27579] Add a tutorial for AsyncIO in the documentation In-Reply-To: <1469025749.21.0.829921979586.issue27579@psf.upfronthosting.co.za> Message-ID: <1469437752.25.0.0443965635319.issue27579@psf.upfronthosting.co.za> Ludovic Gasc added the comment: Hi Terry, > I don't yet know how to work with git and github. I don't yet know how to work with tkinter and TK. I propose to combine our respective knowledge to improve the documentation together. If you give an all in one python file example with tkinter, I'll add that in the documentation via git and Github. Thanks for your help. Have a nice day. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 05:29:37 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 Jul 2016 09:29:37 +0000 Subject: [issue27579] Add a tutorial for AsyncIO in the documentation In-Reply-To: <1469025749.21.0.829921979586.issue27579@psf.upfronthosting.co.za> Message-ID: <1469438977.41.0.319518548886.issue27579@psf.upfronthosting.co.za> STINNER Victor added the comment: "I would like the tutorial to include something like the following: Adding Tkinter GUI to Asyncio Program" Please open an issue in the asyncio-doc project: https://github.com/asyncio-doc/asyncio-doc There is now a small community working on this documentation project, so I don't think that it's worth to keep this issue open. But today, Tkinter is not really fully integrated with asyncio. So I'm not sure that it's only a matter of *documentation*, it's more a matter of code that should be written and/or completed no? Or maybe open a thread on the new async-sig mailing list? http://asyncio.readthedocs.io/en/latest/getting_help.html ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 05:31:27 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 25 Jul 2016 09:31:27 +0000 Subject: [issue26851] android compilation and link flags In-Reply-To: <1461673211.54.0.945034926098.issue26851@psf.upfronthosting.co.za> Message-ID: <1469439087.31.0.0144701061295.issue26851@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Thanks for the review and the suggestions Martin :) New patch. ---------- Added file: http://bugs.python.org/file43875/build-flags_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 05:37:50 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 25 Jul 2016 09:37:50 +0000 Subject: [issue27576] An unexpected difference between dict and OrderedDict In-Reply-To: <1468962090.7.0.636707577928.issue27576@psf.upfronthosting.co.za> Message-ID: <1469439470.28.0.0143087377586.issue27576@psf.upfronthosting.co.za> Xiang Zhang added the comment: Submit a patch to fix this. Hope it helps. ---------- keywords: +patch nosy: +xiang.zhang Added file: http://bugs.python.org/file43876/odict_update.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 06:56:40 2016 From: report at bugs.python.org (Sylvia van Os) Date: Mon, 25 Jul 2016 10:56:40 +0000 Subject: [issue27607] Importing the main module twice leads to two incompatible instances In-Reply-To: <1469375177.67.0.287991264427.issue27607@psf.upfronthosting.co.za> Message-ID: <1469444200.8.0.810422128482.issue27607@psf.upfronthosting.co.za> Changes by Sylvia van Os : Removed file: http://bugs.python.org/file43867/a040de8b978dcc4c272c0571d456a382-ea6d8fb8acc988a1f060c94070f70a6ed8439069.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 06:58:12 2016 From: report at bugs.python.org (Sylvia van Os) Date: Mon, 25 Jul 2016 10:58:12 +0000 Subject: [issue27607] Importing the main module twice leads to two incompatible instances In-Reply-To: <1469375177.67.0.287991264427.issue27607@psf.upfronthosting.co.za> Message-ID: <1469444292.03.0.752132952471.issue27607@psf.upfronthosting.co.za> Sylvia van Os added the comment: My apologies, I can't get that test case to run here either. Here is a slightly older one that does reproduce the issue too. I specifically run it with python3 main.py. ---------- Added file: http://bugs.python.org/file43877/issue27607.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 07:42:11 2016 From: report at bugs.python.org (Grigory Statsenko) Date: Mon, 25 Jul 2016 11:42:11 +0000 Subject: [issue27613] Empty iterator is rendered as a single bracket ] when using json's iterencode Message-ID: <1469446931.7.0.792781039481.issue27613@psf.upfronthosting.co.za> New submission from Grigory Statsenko: JSONEncoder.iterencode doesn't work with empty iterators correctly. Steps: 1. Define an iterator that is recognized by json as a list (inherit from list and define nonzero __len__). 2. Use json.dump with data containing an empty iterator defined as described in step#1 (but doesn't generate any items) Expected result: it should be rendered as an empty list: '[]' Actual result: it is rendered as ']' (only the closing bracket) interestingly enough this behavior is not reproduced when using the dumps function. I tried other alternatives to the standard json module: simplejson, ujson, hjson All of them work as expected in this case (both brackets are rendered). Here is an example of the code that demonstrates this error (compares the results of the dump and dumps functions): import json as json import io class EmptyIterator(list): def __iter__(self): while False: yield 1 def __len__(self): return 1 def dump_to_str(data): return json.dumps(data) def dump_to_file(data): stream = io.StringIO() json.dump(data, stream) return stream.getvalue() data = {'it': EmptyIterator()} print('to str: {0}'.format(dump_to_str(data))) print('to file: {0}'.format(dump_to_file(data))) This prints: to str: {"it": []} to file: {"it": ]} ---------- messages: 271249 nosy: altvod priority: normal severity: normal status: open title: Empty iterator is rendered as a single bracket ] when using json's iterencode type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 07:52:43 2016 From: report at bugs.python.org (SilentGhost) Date: Mon, 25 Jul 2016 11:52:43 +0000 Subject: [issue27613] Empty iterator is rendered as a single bracket ] when using json's iterencode In-Reply-To: <1469446931.7.0.792781039481.issue27613@psf.upfronthosting.co.za> Message-ID: <1469447563.64.0.375925097031.issue27613@psf.upfronthosting.co.za> SilentGhost added the comment: Why does your __len__ method returns 1? Shouldn't it be 0 since this is an empty iterator? Changing it to zero seems to fix the "issue" too. ---------- nosy: +SilentGhost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 08:05:22 2016 From: report at bugs.python.org (Grigory Statsenko) Date: Mon, 25 Jul 2016 12:05:22 +0000 Subject: [issue27613] Empty iterator is rendered as a single bracket ] when using json's iterencode In-Reply-To: <1469446931.7.0.792781039481.issue27613@psf.upfronthosting.co.za> Message-ID: <1469448322.92.0.552774656742.issue27613@psf.upfronthosting.co.za> Grigory Statsenko added the comment: I can't do that if I don't know how many entries there will be ahead of time. In my real-life situation I'm fetching the data from a database not knowing how many entries I'll get before I actually get them (in the iterator). In most cases there are huge amounts of entries that take up too much memory - that's why I need to stream it. But sometimes the result set is empty - and that's when everything fails. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 08:16:28 2016 From: report at bugs.python.org (Grigory Statsenko) Date: Mon, 25 Jul 2016 12:16:28 +0000 Subject: [issue27613] Empty iterator is rendered as a single bracket ] when using json's iterencode In-Reply-To: <1469446931.7.0.792781039481.issue27613@psf.upfronthosting.co.za> Message-ID: <1469448988.76.0.247545935588.issue27613@psf.upfronthosting.co.za> Grigory Statsenko added the comment: Actually, it does work with len = 0 even if the iterator is not empty. So, I guess that is a solution. But still, I think the more correct way would be to make it work with > 0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 08:16:42 2016 From: report at bugs.python.org (Emanuel Barry) Date: Mon, 25 Jul 2016 12:16:42 +0000 Subject: [issue27607] Importing the main module twice leads to two incompatible instances In-Reply-To: <1469375177.67.0.287991264427.issue27607@psf.upfronthosting.co.za> Message-ID: <1469449002.78.0.157249422087.issue27607@psf.upfronthosting.co.za> Emanuel Barry added the comment: @Cameron - I don't think this issue can be solved without the PEP, so possibly that the best move would be to work on the PEP and submit it for another round on Python-Dev, to get it reviewed. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 08:18:13 2016 From: report at bugs.python.org (Grigory Statsenko) Date: Mon, 25 Jul 2016 12:18:13 +0000 Subject: [issue27613] Empty iterator is rendered as a single bracket ] when using json's iterencode In-Reply-To: <1469446931.7.0.792781039481.issue27613@psf.upfronthosting.co.za> Message-ID: <1469449093.07.0.659876217335.issue27613@psf.upfronthosting.co.za> Grigory Statsenko added the comment: My bad - it doesn't work with non-empty iterators if you set len to 0, so not a solution ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 08:20:58 2016 From: report at bugs.python.org (SilentGhost) Date: Mon, 25 Jul 2016 12:20:58 +0000 Subject: [issue27613] Empty iterator is rendered as a single bracket ] when using json's iterencode In-Reply-To: <1469446931.7.0.792781039481.issue27613@psf.upfronthosting.co.za> Message-ID: <1469449258.54.0.0724015414334.issue27613@psf.upfronthosting.co.za> SilentGhost added the comment: The question is why are you defining __len__ if you don't know the size of your final object? Or at least, why are you starting with a potentially wrong initial value? This issue doesn't exist if you either don't define the method or return correct value. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 08:22:29 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 Jul 2016 12:22:29 +0000 Subject: [issue27576] An unexpected difference between dict and OrderedDict In-Reply-To: <1468962090.7.0.636707577928.issue27576@psf.upfronthosting.co.za> Message-ID: <1469449349.59.0.269105611227.issue27576@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think this case (fast path for exact dict) is not needed at all. Exact dict is not ordered, and OrderedDict created from exact dict has nondetermined order (unless a dict has size 0 or 1). ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 08:22:38 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 Jul 2016 12:22:38 +0000 Subject: [issue26944] android: test_posix fails In-Reply-To: <1462348873.26.0.373017977506.issue26944@psf.upfronthosting.co.za> Message-ID: <1469449358.1.0.858318485349.issue26944@psf.upfronthosting.co.za> STINNER Victor added the comment: > ValueError: invalid literal for int() with base 10: 'uid=0(root)' Hum, does the id program supports -G on Android? The output looks like the regular id output (without -G). Example on my Linux (Fedora 24): $ id uid=1000(haypo) gid=1000(haypo) groupes=1000(haypo),10(wheel) contexte=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 $ id -G 1000 10 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 08:35:58 2016 From: report at bugs.python.org (Grigory Statsenko) Date: Mon, 25 Jul 2016 12:35:58 +0000 Subject: [issue27613] Empty iterator is rendered as a single bracket ] when using json's iterencode In-Reply-To: <1469446931.7.0.792781039481.issue27613@psf.upfronthosting.co.za> Message-ID: <1469450158.22.0.71140900549.issue27613@psf.upfronthosting.co.za> Grigory Statsenko added the comment: If __len__ is not defined, then the iterator is considered empty and is always rendered as [] even if it really isn't empty ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 08:44:56 2016 From: report at bugs.python.org (Grigory Statsenko) Date: Mon, 25 Jul 2016 12:44:56 +0000 Subject: [issue27613] Empty iterator is rendered as a single bracket ] when using json's iterencode In-Reply-To: <1469446931.7.0.792781039481.issue27613@psf.upfronthosting.co.za> Message-ID: <1469450696.64.0.962080220579.issue27613@psf.upfronthosting.co.za> Grigory Statsenko added the comment: With streaming you never know the real length before you're done iterating. Anyway, the fix really shouldn't be that complicated: In _iterencode_list just yield the '[' instead of saving it to buf ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 08:46:21 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 25 Jul 2016 12:46:21 +0000 Subject: [issue13963] dev guide has no mention of mechanics of patch review In-Reply-To: <1328631878.8.0.85188160352.issue13963@psf.upfronthosting.co.za> Message-ID: <1469450781.75.0.474146852329.issue13963@psf.upfronthosting.co.za> Martin Panter added the comment: FTR: The Mercurial bug has wandered to . It suggests using ?hg --config diff.git=0 diff?. Also, this 2011 post has some details of how the Git patch format is accepted or not (not sure if anything has changed since then): https://mail.python.org/pipermail/python-dev/2011-March/110163.html ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 08:54:17 2016 From: report at bugs.python.org (Yujie Chen) Date: Mon, 25 Jul 2016 12:54:17 +0000 Subject: [issue27590] tarfile module next() method hides exceptions In-Reply-To: <1469200266.16.0.443973453456.issue27590@psf.upfronthosting.co.za> Message-ID: <1469451257.76.0.561593954152.issue27590@psf.upfronthosting.co.za> Yujie Chen added the comment: I do want tarfile module to stop at the first invalid header. My question is why does tarfile module NOT throw exception about the error in header, instead it just hide it silently. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 08:59:36 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 25 Jul 2016 12:59:36 +0000 Subject: [issue25170] 3.4.4, 3.4.5, 3.5.0, 3.5.1, 3.5.2 documentation archives missing In-Reply-To: <1442601694.39.0.291720811899.issue25170@psf.upfronthosting.co.za> Message-ID: <1469451576.06.0.797903265235.issue25170@psf.upfronthosting.co.za> Martin Panter added the comment: The documentation for recent releases looks nice and functional now, thanks. So at least that aspect is fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 09:02:52 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 25 Jul 2016 13:02:52 +0000 Subject: [issue26462] Patch to enhance literal block language declaration In-Reply-To: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za> Message-ID: <1469451772.21.0.972392350105.issue26462@psf.upfronthosting.co.za> Martin Panter added the comment: I think generating it with Mercurial (and not using Mercurial?s Git patch format) is the best way. I just left some more notes at . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 09:06:57 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 25 Jul 2016 13:06:57 +0000 Subject: [issue27607] Importing the main module twice leads to two incompatible instances In-Reply-To: <1469375177.67.0.287991264427.issue27607@psf.upfronthosting.co.za> Message-ID: <1469452017.87.0.847283435652.issue27607@psf.upfronthosting.co.za> R. David Murray added the comment: If you have any sort of implementation of the pep, proving that it does fix this issue would be informative. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 09:14:49 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 25 Jul 2016 13:14:49 +0000 Subject: [issue27612] socket.gethostbyname resolving octal IP addresses incorrectly In-Reply-To: <1469428074.1.0.701366093272.issue27612@psf.upfronthosting.co.za> Message-ID: <1469452489.2.0.120371346113.issue27612@psf.upfronthosting.co.za> R. David Murray added the comment: This would appear to be a platform OS issue. Is it "broken" also for FreeBSD? (I put broken in quotes because interpreting ocatal isn't part of the posix speck for gethostbyname. It could even be an accident that it works on Linux. I'm not going to close this yet, since it might be worth a doc issue, or at least documenting here what the status of this is on FreeBSD. ---------- nosy: +koobs, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 09:16:38 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 25 Jul 2016 13:16:38 +0000 Subject: [issue27612] socket.gethostbyname resolving octal IP addresses incorrectly In-Reply-To: <1469428074.1.0.701366093272.issue27612@psf.upfronthosting.co.za> Message-ID: <1469452598.79.0.771470535621.issue27612@psf.upfronthosting.co.za> R. David Murray added the comment: To clarify: by platform OS issue, I mean that the octal-conversion-or-not is none of Python's doing, it is done by the C library call that gethostbyname is a thin wrapper around. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 09:22:20 2016 From: report at bugs.python.org (Ned Deily) Date: Mon, 25 Jul 2016 13:22:20 +0000 Subject: [issue25170] 3.4.4, 3.4.5, 3.5.0, 3.5.1, 3.5.2 documentation archives missing In-Reply-To: <1442601694.39.0.291720811899.issue25170@psf.upfronthosting.co.za> Message-ID: <1469452940.06.0.338018803998.issue25170@psf.upfronthosting.co.za> Ned Deily added the comment: The actions in PEP 101 cited by Georg in msg251105 above still need to be done. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 09:33:44 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 25 Jul 2016 13:33:44 +0000 Subject: [issue27604] More details about `-O` flag In-Reply-To: <1469353581.38.0.811049911305.issue27604@psf.upfronthosting.co.za> Message-ID: <1469453624.29.0.0951589927218.issue27604@psf.upfronthosting.co.za> R. David Murray added the comment: Ram: Brett gave you the benefit of the doubt on whether or not your comment was *intended* to be antagonistic. Brett's comment was giving you the historical context for why it isn't documented, but said nothing about what we might do now. In fact, his use of the term "historically" implies that we could re-evaluate things now if we wish to, whether or not he meant that. You could have given him the benefit of the doubt. I know that is often hard, though. I've reacted negatively to a comment often enough myself that these days I try very hard to think two or three times about what the most charitable interpretation could be, and what the best way would be for moving the conversation forward in my response even if the other party really is being antagonistic. I've found that this works well more often than not. But yes, it is good for us to be reminded periodically that we should think about being welcoming any time we respond to a contribution. (On the other hand, you aren't exactly a new contributor, so Brett may have assumed he could take some shortcuts in speaking to you.) Also, you will find in *every* community that there is a tendency to "defend the status quo" (and we're explicit about this), so sometimes you do have to mount an argument for changing it. That's just human nature, but is also something I've been trying to train myself to be aware of (I'm still working on getting better at both of these :) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 09:35:55 2016 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 25 Jul 2016 13:35:55 +0000 Subject: [issue13963] dev guide has no mention of mechanics of patch review In-Reply-To: <1328631878.8.0.85188160352.issue13963@psf.upfronthosting.co.za> Message-ID: <1469453755.98.0.134919411595.issue13963@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 09:36:30 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 25 Jul 2016 13:36:30 +0000 Subject: [issue27604] More details about `-O` flag In-Reply-To: <1469353581.38.0.811049911305.issue27604@psf.upfronthosting.co.za> Message-ID: <1469453790.48.0.813662986545.issue27604@psf.upfronthosting.co.za> R. David Murray added the comment: Heh, clarification on "we're explicit about this". I was referring to Nick's aphorism, "The status quo wins a tie", which means that there has to be a *postive* reason to change the status quo. That's what we're explicit about. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 09:44:27 2016 From: report at bugs.python.org (Ram Rachum) Date: Mon, 25 Jul 2016 13:44:27 +0000 Subject: [issue27604] More details about `-O` flag In-Reply-To: <1469353581.38.0.811049911305.issue27604@psf.upfronthosting.co.za> Message-ID: <1469454267.16.0.259939826047.issue27604@psf.upfronthosting.co.za> Ram Rachum added the comment: Thanks for your understanding David. I'll submit a patch for this issue soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 09:46:56 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 25 Jul 2016 13:46:56 +0000 Subject: [issue27612] socket.gethostbyname resolving octal IP addresses incorrectly In-Reply-To: <1469428074.1.0.701366093272.issue27612@psf.upfronthosting.co.za> Message-ID: <1469454416.13.0.187359458146.issue27612@psf.upfronthosting.co.za> Xiang Zhang added the comment: On Linux, it seems it's not an accident. inet_addr(3) explicitly says it can handle octal or haxadecimal forms. ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 09:48:42 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 25 Jul 2016 13:48:42 +0000 Subject: [issue27613] Empty iterator is rendered as a single bracket ] when using json's iterencode In-Reply-To: <1469446931.7.0.792781039481.issue27613@psf.upfronthosting.co.za> Message-ID: <1469454522.47.0.90440384421.issue27613@psf.upfronthosting.co.za> R. David Murray added the comment: If you break the invariants (in this case: a list has an accurate len) code that expects lists is only going to work by accident. What you really want to do is define your own json encoder for your type. If that isn't possible for a streamed sequence of undefined length, then enhancing json's extension machinery to allow it would be a good feature request. That said, could json's ability to handle this be improved? Possibly. I think we would accept a patch if it doesn't make the code more complicated. Ideally handling certain cases as "don't care" makes the code simpler, but that may or may not be the case here. Or it may come out as a consequence of the enhancement. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 10:01:10 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 25 Jul 2016 14:01:10 +0000 Subject: [issue26944] android: test_posix fails In-Reply-To: <1462348873.26.0.373017977506.issue26944@psf.upfronthosting.co.za> Message-ID: <1469455270.44.0.253298532853.issue26944@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > Hum, does the id program supports -G on Android? It does on Android 6.0 but prints the same result as 'id' (without -G) on previous Android versions. Here is the output of the commands involved in the test for the root user on my archlinux box, the Android 5.0 emulator and the Android 6.0 emulator: archlinux: [root at bilboquet default]# python ... >>> from posix import getegid, getgroups >>> getgroups() [0, 1, 2, 3, 4, 6, 10, 19] >>> getegid() 0 [root at bilboquet default]# id -G 0 1 2 3 4 6 10 19 Android 5.0 (API level 21) root at generic_x86:/data/data/org.bitbucket.pyona # python ... >>> from posix import getegid, getgroups >>> getgroups() [1003, 1004, 1007, 1011, 1015, 1028, 3001, 3002, 3003, 3006] >>> getegid() 0 root at generic_x86:/data/data/org.bitbucket.pyona # id -G uid=0(root) gid=0(root) groups=1003(graphics),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats) Android 6.0 (API level 23) root at generic_x86:/data/data/org.bitbucket.pyona # python ... >>> from posix import getegid, getgroups >>> getgroups() [1004, 1007, 1011, 1015, 1028, 3001, 3002, 3003, 3006] >>> getegid() 0 root at generic_x86:/data/data/org.bitbucket.pyona # id -G 1004 1007 1011 1015 1028 3001 3002 3003 3006 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 10:03:09 2016 From: report at bugs.python.org (Stefan Krah) Date: Mon, 25 Jul 2016 14:03:09 +0000 Subject: [issue27604] More details about `-O` flag In-Reply-To: <1469353581.38.0.811049911305.issue27604@psf.upfronthosting.co.za> Message-ID: <1469455389.25.0.992907809281.issue27604@psf.upfronthosting.co.za> Stefan Krah added the comment: I can see nothing wrong with msg271168. It's polite, informative, not apodictic and does not rule out the possibility of accepting a patch. Also, it answers a direct question from msg271142. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 10:13:46 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 25 Jul 2016 14:13:46 +0000 Subject: [issue26851] android compilation and link flags In-Reply-To: <1461673211.54.0.945034926098.issue26851@psf.upfronthosting.co.za> Message-ID: <1469456026.57.0.553292303384.issue26851@psf.upfronthosting.co.za> Changes by Xavier de Gaye : Added file: http://bugs.python.org/file43878/build-flags_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 10:17:14 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 25 Jul 2016 14:17:14 +0000 Subject: [issue26851] android compilation and link flags In-Reply-To: <1461673211.54.0.945034926098.issue26851@psf.upfronthosting.co.za> Message-ID: <1469456234.71.0.163456603892.issue26851@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The first 'build-flags_3.patch' file that was uploaded did not get a review button because ssh://hg at hg.python.org/cpython was down at that time. The second upload has been successfull ! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 10:21:57 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 25 Jul 2016 14:21:57 +0000 Subject: [issue27576] An unexpected difference between dict and OrderedDict In-Reply-To: <1468962090.7.0.636707577928.issue27576@psf.upfronthosting.co.za> Message-ID: <1469456517.37.0.514161578534.issue27576@psf.upfronthosting.co.za> Xiang Zhang added the comment: I didn't think about order. I just thought using concrete API may be faster. But after your comment, I tested the performance and it seems PyDict_Items makes it much slower (it does more work, eg, make tuples). So I agree it is not needed at all. ---------- Added file: http://bugs.python.org/file43879/odict_update_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 10:41:14 2016 From: report at bugs.python.org (Michael Felt) Date: Mon, 25 Jul 2016 14:41:14 +0000 Subject: [issue11192] test_socket error on AIX In-Reply-To: <1297436751.32.0.492226695457.issue11192@psf.upfronthosting.co.za> Message-ID: <1469457674.69.0.538644921262.issue11192@psf.upfronthosting.co.za> Michael Felt added the comment: FYI: test fails on AIX 5.3 TL7 SP0 (as expected. The IBM document refers to 5.3 TL8) On AIX 6.1 TL9 SP5 (and probably earlier) the test passes. IMHO - can be closed (and README.AIX can be updated). michael at x071:[/data/prj/aixtools/python/python-2.7.11.5/Lib/test]oslevel -q -s | head -5 Known Service Packs ------------------- 6100-09-05-1524 6100-09-04-1441 michael at x071:[/data/prj/aixtools/python/python-2.7.11.5/Lib/test]../../python test_socket.py ... ---------------------------------------------------------------------- Ran 124 tests in 15.860s OK (skipped=7) On AIX 5.3 (the expected fail...) root at x064:[/data/prj/aixtools/python/python-2.7.11.5/Lib/test]oslevel -q -s | head -5 Known Service Packs ------------------- 5300-07-00-0000 5300-06-03-0732 root at x064:[/data/prj/aixtools/python/python-2.7.11.5/Lib/test]../../python test_socket.py ... ====================================================================== FAIL: testGetaddrinfo (__main__.GeneralModuleTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "test_socket.py", line 691, in testGetaddrinfo self.assertEqual(socktype, socket.SOCK_STREAM) AssertionError: 0 != 1 ---------------------------------------------------------------------- Ran 124 tests in 16.765s FAILED (failures=1, skipped=7) Traceback (most recent call last): File "test_socket.py", line 1804, in test_main() File "test_socket.py", line 1800, in test_main test_support.run_unittest(*tests) File "/data/prj/aixtools/python/python-2.7.11.5/Lib/test/test_support.py", line 1428, in run_unittest _run_suite(suite) File "/data/prj/aixtools/python/python-2.7.11.5/Lib/test/test_support.py", line 1411, in _run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "test_socket.py", line 691, in testGetaddrinfo self.assertEqual(socktype, socket.SOCK_STREAM) AssertionError: 0 != 1 ---------- nosy: +Michael.Felt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 10:52:03 2016 From: report at bugs.python.org (Mark) Date: Mon, 25 Jul 2016 14:52:03 +0000 Subject: =?utf-8?q?=5Bissue24875=5D_pyvenv_doesn=C2=B4t_install_PIP_inside_a_new_v?= =?utf-8?q?env_with_--system-site-package?= In-Reply-To: <1439699040.07.0.199956094974.issue24875@psf.upfronthosting.co.za> Message-ID: <1469458323.92.0.777925028879.issue24875@psf.upfronthosting.co.za> Mark added the comment: I have the same problem on a standard installation of Python 3.5 (on OS X via Homebrew). This bug is almost a year old, and it is a doozy: it utterly defeats the purpose of --system-site-packages. In the hope of getting some momentum going, I tried out the option suggested by dstufft: adding --ignore-installed in ensurepip's bootstrap() does seem to fix the problem. I've never contributed a patch to Python before so I've probably screwed this up, but I'm attaching a patch that applies against latest python 3.5 on github (1b279c2). Sorry, I don't know what the equivalent Hg hash is, but this is a pretty minimal patch so it should be easy to apply. ---------- keywords: +patch nosy: +mehaase versions: +Python 3.5 Added file: http://bugs.python.org/file43880/0001-Fix-issue-24875.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 11:05:39 2016 From: report at bugs.python.org (earl.chew) Date: Mon, 25 Jul 2016 15:05:39 +0000 Subject: [issue27614] Race in test_docxmlrpc.py Message-ID: <1469459139.76.0.959920407285.issue27614@psf.upfronthosting.co.za> New submission from earl.chew: The test test_docxmlrpc.py will sometimes hang because of a timing race. I've verified that this code is the same up to version 3.5 and master at https://github.com/python/cpython/blob/master/Lib/test/test_docxmlrpc.py A proposed patch is attached. ---------- components: Library (Lib) files: test_docxmlrpc.py messages: 271279 nosy: earl.chew priority: normal severity: normal status: open title: Race in test_docxmlrpc.py 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/file43881/test_docxmlrpc.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 11:12:47 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 Jul 2016 15:12:47 +0000 Subject: [issue26944] android: test_posix fails In-Reply-To: <1469455270.44.0.253298532853.issue26944@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Sorry but I don't see the point of trying to "fix" the unit test on Android if "id -G" doesn't work as expected. In fact, I don't really understand the point of such functional test. Are we still testing Python? Or are we testing the OS itself? I suggest to remove the whole unit test, or skip the whole unit test on Android (@skipIf(is_android(), "-G option of id -G is ignored"), something like that). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 11:16:07 2016 From: report at bugs.python.org (Michael Felt) Date: Mon, 25 Jul 2016 15:16:07 +0000 Subject: [issue11193] test_subprocess error on AIX In-Reply-To: <1297438101.89.0.389896513062.issue11193@psf.upfronthosting.co.za> Message-ID: <1469459767.31.0.65104033916.issue11193@psf.upfronthosting.co.za> Michael Felt added the comment: Seems to be okay at least with Python 3.6 "test" version - but maybe there is better way to call these tests - just to be sure the one needed is not being skipped. On AIX 5.3 TL7 SP0: root at x064:[/data/prj/aixtools/python/python-3.6.0.162/Lib/test]../../python test_subprocess.py ssss...........................................s.......................................................s.....s.........s...............................................................s.....s.........s.........................................sssssssssssss ---------------------------------------------------------------------- Ran 254 tests in 113.796s OK (skipped=24) On AIX 6.1 TL9 SP4: michael at x071:[/data/prj/aixtools/python/python-3.6.0.162/Lib/test]../../python test_subprocess.py ssss...........................................s.......................................................s.....s.........s...............................................................s.....s.........s.........................................sssssssssssss ---------------------------------------------------------------------- Ran 254 tests in 126.684s OK (skipped=24) michael at x071:[/data/prj/aixtools/python/python-3.6.0.162/Lib/test] Please note that GNU libiconv is used by default (version 1.14) rather than IBM iconv. This may be the key issue (will test 11190 as well) ---------- nosy: +Michael.Felt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 11:19:21 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 Jul 2016 15:19:21 +0000 Subject: [issue26851] android compilation and link flags In-Reply-To: <1461673211.54.0.945034926098.issue26851@psf.upfronthosting.co.za> Message-ID: <1469459961.8.0.140492659346.issue26851@psf.upfronthosting.co.za> STINNER Victor added the comment: Note: build-flags_3.patch includes configure.ac and configure. Usually, we suggest to not included generated files (configure) in patches, but push them when the patch is ready. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 11:22:37 2016 From: report at bugs.python.org (Matt Robenolt) Date: Mon, 25 Jul 2016 15:22:37 +0000 Subject: [issue27612] socket.gethostbyname resolving octal IP addresses incorrectly In-Reply-To: <1469428074.1.0.701366093272.issue27612@psf.upfronthosting.co.za> Message-ID: <1469460157.74.0.151827114957.issue27612@psf.upfronthosting.co.za> Matt Robenolt added the comment: Sorry, to add a data point, in C, `gethostbyname` also does the correct thing on macOS. See: ``` #include #include #include #include #include #include #include int main(int argc, char *argv[]) { int i; struct hostent *lh = gethostbyname("0177.0000.0000.0001"); struct in_addr **addr_list; if (lh) { addr_list = (struct in_addr **)lh->h_addr_list; for (i=0; addr_list[i] != NULL; i++) { printf("%s", inet_ntoa(*addr_list[i])); } printf("\n"); } else { herror("gethostbyname"); } return 0; } ``` So I'm not sure this is platform specific. Either way, `socket.gethostbyname` is wrong on both linux and macOS. I'm a bit lost with what's going on here though, admittedly. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 11:25:09 2016 From: report at bugs.python.org (Matt Robenolt) Date: Mon, 25 Jul 2016 15:25:09 +0000 Subject: [issue27612] socket.gethostbyname resolving octal IP addresses incorrectly In-Reply-To: <1469428074.1.0.701366093272.issue27612@psf.upfronthosting.co.za> Message-ID: <1469460309.01.0.219582895977.issue27612@psf.upfronthosting.co.za> Matt Robenolt added the comment: And lastly, it seems that `socket.gethostbyname_ex` _does_ work correctly on both platforms. ``` >>> socket.gethostbyname_ex('0177.0000.0000.0001') ('0177.0000.0000.0001', [], ['127.0.0.1']) ``` ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 11:25:31 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 Jul 2016 15:25:31 +0000 Subject: [issue26944] android: test_posix fails In-Reply-To: <1462348873.26.0.373017977506.issue26944@psf.upfronthosting.co.za> Message-ID: <1469460331.3.0.150594138754.issue26944@psf.upfronthosting.co.za> STINNER Victor added the comment: Ooops, I missed the part where you say that it works on API level >= 23. So I suggest to only skip the test on Android API level < 23. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 11:27:22 2016 From: report at bugs.python.org (Michael Felt) Date: Mon, 25 Jul 2016 15:27:22 +0000 Subject: [issue11190] test_locale error on AIX In-Reply-To: <1297436341.9.0.505195116072.issue11190@psf.upfronthosting.co.za> Message-ID: <1469460442.57.0.943642327032.issue11190@psf.upfronthosting.co.za> Michael Felt added the comment: FYI: this seems to still be current, although issue11193 seems okay. michael at x071:[/data/prj/aixtools/python/python-3.6.0.162/Lib/test]../../python test_locale.py ..................testing with 'en_US.ISO8859-1'... .testing with 'en_US.ISO8859-1'... Ftesting with 'en_US.ISO8859-1'... .testing with 'en_US.ISO8859-1'... F.....................s....testing with 'en_US.ISO8859-1'... .testing with 'en_US.ISO8859-1'... .testing with 'en_US.ISO8859-1'... .testing with 'en_US.ISO8859-1'... .testing with 'en_US.ISO8859-1'... .testing with 'en_US.ISO8859-1'... .testing with 'en_US.ISO8859-1'... .... ====================================================================== FAIL: test_strcoll_with_diacritic (__main__.TestEnUSCollation) ---------------------------------------------------------------------- Traceback (most recent call last): File "test_locale.py", line 362, in test_strcoll_with_diacritic self.assertLess(locale.strcoll('?', 'b'), 0) AssertionError: 1 not less than 0 ====================================================================== FAIL: test_strxfrm_with_diacritic (__main__.TestEnUSCollation) ---------------------------------------------------------------------- Traceback (most recent call last): File "test_locale.py", line 365, in test_strxfrm_with_diacritic self.assertLess(locale.strxfrm('?'), locale.strxfrm('b')) AssertionError: '\u01e2\u0100' not less than '\u0164\u0100' ---------------------------------------------------------------------- Ran 58 tests in 0.050s FAILED (failures=2, skipped=1) FYI: make check for libiconv-1.14 has exit status 0. ---------- nosy: +Michael.Felt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 11:37:20 2016 From: report at bugs.python.org (Martin Teichmann) Date: Mon, 25 Jul 2016 15:37:20 +0000 Subject: [issue27366] PEP487: Simpler customization of class creation In-Reply-To: <1466579967.76.0.483118833643.issue27366@psf.upfronthosting.co.za> Message-ID: <1469461040.64.0.268664198318.issue27366@psf.upfronthosting.co.za> Martin Teichmann added the comment: I looked over the patch once more and found some places where I didn't follow normal coding standards. I changed that, namely now the code returns -1 meaning an exception happened and 0 on success, which is what many functions in typeobject.c do. So I think this patch should be ready. ---------- Added file: http://bugs.python.org/file43882/pep487.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 11:37:45 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 Jul 2016 15:37:45 +0000 Subject: [issue11190] test_locale error on AIX In-Reply-To: <1297436341.9.0.505195116072.issue11190@psf.upfronthosting.co.za> Message-ID: <1469461065.46.0.209216338871.issue11190@psf.upfronthosting.co.za> STINNER Victor added the comment: I know that test_locale fails on AIX, but I don't think that it's an issue in Python itself. Python exposes OS functions. I suggest to simply skip failing tests on AIX! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 11:40:05 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 25 Jul 2016 15:40:05 +0000 Subject: [issue27366] PEP487: Simpler customization of class creation In-Reply-To: <1466579967.76.0.483118833643.issue27366@psf.upfronthosting.co.za> Message-ID: <1469461205.32.0.137560964342.issue27366@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- nosy: -gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 11:44:54 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 25 Jul 2016 15:44:54 +0000 Subject: [issue27612] socket.gethostbyname resolving octal IP addresses incorrectly In-Reply-To: <1469428074.1.0.701366093272.issue27612@psf.upfronthosting.co.za> Message-ID: <1469461494.63.0.522534377988.issue27612@psf.upfronthosting.co.za> R. David Murray added the comment: Hmm. Since gethostbyname is a deprecated interface, perhaps there is nothing to do here. However, if someone wants to investigate further and finds a fix, we will evaluate it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 11:48:59 2016 From: report at bugs.python.org (Matt Robenolt) Date: Mon, 25 Jul 2016 15:48:59 +0000 Subject: [issue27612] socket.gethostbyname resolving octal IP addresses incorrectly In-Reply-To: <1469428074.1.0.701366093272.issue27612@psf.upfronthosting.co.za> Message-ID: <1469461739.2.0.116170674366.issue27612@psf.upfronthosting.co.za> Matt Robenolt added the comment: Is it worth investigating the different behavior then with `getaddrinfo` between platforms? As far as I know, that's the only method that works with both ipv6 and will tell you "here are all the IP addresses this resolves to". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 12:00:52 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 25 Jul 2016 16:00:52 +0000 Subject: [issue26944] android: test_posix fails In-Reply-To: <1462348873.26.0.373017977506.issue26944@psf.upfronthosting.co.za> Message-ID: <1469462452.72.0.255926372093.issue26944@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The test is already skipped by the patch, for Android API level < 23, with the statement: raise unittest.SkipTest("need working 'id -G'") Do you mean that the test should be skipped instead more explicitly with something like: skiIf(support.android_api_level < 23, "-G option of id -G is ignored by Android") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 12:05:05 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 25 Jul 2016 16:05:05 +0000 Subject: [issue26851] android compilation and link flags In-Reply-To: <1461673211.54.0.945034926098.issue26851@psf.upfronthosting.co.za> Message-ID: <1469462704.99.0.899407612673.issue26851@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Thanks for the suggestion, I won't include them anymore in patches then. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 12:05:07 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 25 Jul 2016 16:05:07 +0000 Subject: [issue27612] socket.gethostbyname resolving octal IP addresses incorrectly In-Reply-To: <1469428074.1.0.701366093272.issue27612@psf.upfronthosting.co.za> Message-ID: <1469462707.8.0.5123689553.issue27612@psf.upfronthosting.co.za> Xiang Zhang added the comment: A similar bug report can be seen at https://github.com/dotnet/corefx/issues/8362. There someone makes a conclusion that getaddrinfo (Python seems to use getaddrinfo to implement gethostbyname) doesn't work correctly with octal form. They finally ignore this inconsistent behaviour. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 12:18:31 2016 From: report at bugs.python.org (Matt Robenolt) Date: Mon, 25 Jul 2016 16:18:31 +0000 Subject: [issue27612] socket.gethostbyname resolving octal IP addresses incorrectly In-Reply-To: <1469428074.1.0.701366093272.issue27612@psf.upfronthosting.co.za> Message-ID: <1469463511.34.0.475846356991.issue27612@psf.upfronthosting.co.za> Matt Robenolt added the comment: Ah, I just confirmed broken behavior in macOS as well using `getaddrinfo()` in C. I guess I'd be ok with python ignoring this as well. Maybe worth a change to documentation to note this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 13:29:19 2016 From: report at bugs.python.org (Al Sweigart) Date: Mon, 25 Jul 2016 17:29:19 +0000 Subject: [issue27615] IDLE's debugger steps into PyShell.py for calls to print() et al Message-ID: <1469467759.18.0.354149143305.issue27615@psf.upfronthosting.co.za> New submission from Al Sweigart: Currently if the user "steps into" a print(), input(), sys.stdout.write() or other stdio-related call with the Source checkbox checked, it brings up PyShell.py. This is often confusing for beginner programmers (the target audience of IDLE) and most often not helpful for experienced developers who are stepping through their program. Comparing the cost/benefit, I'd be much more helpful for IDLE to not bring up PyShell.py and instead just treat every "step into" of a print()/input()/anything-that-goes-to-pyshell as a "step over" instead. ---------- assignee: terry.reedy components: IDLE messages: 271295 nosy: Al.Sweigart, terry.reedy priority: normal severity: normal status: open title: IDLE's debugger steps into PyShell.py for calls to print() et al versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 13:37:18 2016 From: report at bugs.python.org (Grant Hillebrand) Date: Mon, 25 Jul 2016 17:37:18 +0000 Subject: [issue27616] filedialog.askdirectory inconsistent on Windows between returning "C:/" and "C:/users" (no trailing slash) Message-ID: <1469468238.61.0.474363149897.issue27616@psf.upfronthosting.co.za> New submission from Grant Hillebrand: When running the following code on Windows 7 (64bit os), and selecting a root drive letter, eg C:, it returns "C:/", with a slash appended. When selecting any other path below root level, eg "C:/users" it returns "C:/users" - no slash appended. This then introduces an odd edge case in processing the output if the path is to be prepended to directory walk data and other file names. Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:18:55) [MSC v.1900 64 bit (AMD64)] on win32 >>> from tkinter import filedialog >>> SourcePath = filedialog.askdirectory() >>> print(SourcePath) C:/ >>> SourcePath = filedialog.askdirectory() >>> print(SourcePath) C:/NVIDIA >>> ---------- components: Tkinter, Windows messages: 271296 nosy: Grant Hillebrand, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: filedialog.askdirectory inconsistent on Windows between returning "C:/" and "C:/users" (no trailing slash) type: behavior versions: Python 3.3, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 13:40:10 2016 From: report at bugs.python.org (Mark Haase) Date: Mon, 25 Jul 2016 17:40:10 +0000 Subject: =?utf-8?q?=5Bissue24875=5D_pyvenv_doesn=C2=B4t_install_PIP_inside_a_new_v?= =?utf-8?q?env_with_--system-site-package?= In-Reply-To: <1439699040.07.0.199956094974.issue24875@psf.upfronthosting.co.za> Message-ID: <1469468410.96.0.151812034846.issue24875@psf.upfronthosting.co.za> Mark Haase added the comment: Please ignore my previous message and patch. Although it installs a pip script into the virtual environment, the script's shebang points to the global python and not the venv python. I'm trying to figure out why this is, but the pip voodoo is way deeper than I understand. I can only guess that it has to do with sys.executable which appears to point to the normalized path, i.e. the system python instead of the symlink inside the venv. So I tried dstufft's other suggestion: disable system site packages before bootstrapping pip and then re-enable it afterward. This actually does work in an end-to-end test on my system. So I'm attaching another patch that applies to python 3.5 (1b279c2 on github -- I don't know the equivalent mercurial hash) that is smaller than the previous patch. I don't know what the side effects are of monkeying around with system site packages like this, so apologies in advance if this is a stupid thing to do... ---------- Added file: http://bugs.python.org/file43883/0002-Fix-issue-24875.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 13:47:42 2016 From: report at bugs.python.org (Brett Cannon) Date: Mon, 25 Jul 2016 17:47:42 +0000 Subject: [issue27604] More details about `-O` flag In-Reply-To: <1469353581.38.0.811049911305.issue27604@psf.upfronthosting.co.za> Message-ID: <1469468862.89.0.285661142474.issue27604@psf.upfronthosting.co.za> Brett Cannon added the comment: If you had viewed the comment as esoteric, Ram, then you could have politely asked for a more in-depth explanation. To me the explanation seemed clear: the optimizations had not been documented so we could feel free in changing what -O meant without breaking any assumptions people had made. I didn't think about suggesting a doc patch saying as such while still documenting what it currently does until after I explained why the documentation is the way it is. As for discouraging contributions, please stop and think about how your messages read to newcomers to bugs.python.org. If I had never contributed and stumbled upon this issue thinking it was an easy one to help with and I saw an openly antagonistic message, I would think twice about participating if that was the kind of attitude I might be confronted with. And then think about how this discourages me from contributing. I took personal time out of my weekend to give you a prompt reply to your issue instead of making you wait until Monday or until someone else happened to reply so you knew the issue was noticed and you didn't start working on a patch that may not get accepted. And in response to me taking the time to respond to your message I get an antagonistic response. How does that in any way inspire me to want to help you out with this issue? And I certainly don't need this documentation change as I know what -O and -OO do, so if my time to try and help someone with an issue I don't directly benefit from leads to me getting grief for my efforts then why should I bother helping anyone unless it also helps me? It's this sort of tone in communication that is unnecessarily hostile towards project maintainers that leads to burnout and long-term contributors such as myself walking away from a project (and I'm not stating this lightly; this is just one instance in a string of incidents like this where I have been treated poorly that has convinced me to take some time off from helping others in my spare time after Python 3.6b1 is released to prevent me from quitting the Python project entirely). I'm going to remove myself from the nosy list so that I recuse myself from this issue so that my feelings about this whole situation doesn't influence any potential patch review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 13:47:50 2016 From: report at bugs.python.org (Brett Cannon) Date: Mon, 25 Jul 2016 17:47:50 +0000 Subject: [issue27604] More details about `-O` flag In-Reply-To: <1469353581.38.0.811049911305.issue27604@psf.upfronthosting.co.za> Message-ID: <1469468870.54.0.811372659191.issue27604@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: -brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 13:50:26 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 Jul 2016 17:50:26 +0000 Subject: [issue27616] filedialog.askdirectory inconsistent on Windows between returning "C:/" and "C:/users" (no trailing slash) In-Reply-To: <1469468238.61.0.474363149897.issue27616@psf.upfronthosting.co.za> Message-ID: <1469469026.23.0.0720988780945.issue27616@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: "C:" is current directory on drive C, "C:/" is root directory on drive C. This is not related to Python or Tk, this is how paths work. Use os.path or pathlib for processing paths. ---------- nosy: +serhiy.storchaka resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 13:54:56 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 25 Jul 2016 17:54:56 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <20160725175452.107146.90793.B2A5F98C@psf.io> Roundup Robot added the comment: New changeset 8cc06070e98b by Alexander Belopolsky in branch 'default': Issue 24773: Added a time_t overflow check. https://hg.python.org/cpython/rev/8cc06070e98b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 15:28:00 2016 From: report at bugs.python.org (Michael Smith) Date: Mon, 25 Jul 2016 19:28:00 +0000 Subject: [issue27617] Compiled bdist_wininst missing from embedded distribution Message-ID: <1469474880.88.0.362049415558.issue27617@psf.upfronthosting.co.za> New submission from Michael Smith: It seems that the embedded distribution is missing bdist_wininst.pyc from the python35.zip . If you go to distutils\command, you'll notice only 23 compiled python files, where in the regular web based installer for the same Python version there are 24 python files in similar relevant folder. I encountered this while trying to install a library into the python runtime that had this import statement: import distutils.command.bdist_wininst ---------- components: Distutils messages: 271301 nosy: denimpowell, dstufft, eric.araujo priority: normal severity: normal status: open title: Compiled bdist_wininst missing from embedded distribution type: compile error versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 15:30:00 2016 From: report at bugs.python.org (Stefan Krah) Date: Mon, 25 Jul 2016 19:30:00 +0000 Subject: [issue27604] More details about `-O` flag In-Reply-To: <1469353581.38.0.811049911305.issue27604@psf.upfronthosting.co.za> Message-ID: <1469475000.09.0.277753922513.issue27604@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 15:40:57 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 25 Jul 2016 19:40:57 +0000 Subject: [issue15335] IDLE - debugger steps into print and over rpc.py code In-Reply-To: <1342111374.05.0.899363686539.issue15335@psf.upfronthosting.co.za> Message-ID: <1469475657.48.0.549293024764.issue15335@psf.upfronthosting.co.za> Terry J. Reedy added the comment: In #27615, which I will close as a duplicate of this, Al Sweigart wrote "Currently if the user "steps into" a print(), input(), sys.stdout.write() or other stdio-related call with the Source checkbox checked, it brings up PyShell.py. This is often confusing for beginner programmers (the target audience of IDLE) and most often not helpful for experienced developers who are stepping through their program. Comparing the cost/benefit, I'd be much more helpful for IDLE to not bring up PyShell.py and instead just treat every "step into" of a print()/input()/anything-that-goes-to-pyshell as a "step over" instead." I have changed my opinion from what I wrote a couple of years ago and now agree. Print and input are different from stdlib functions, such as, "import asyncio; loop = asyncio.get_event_loop", in that they are used by nearly all beginners, are not imported, and are normally C-coded builtins that cannot be stepped into. If one debugs an import- free program, it is startling to be dropped into foreign code. IDLE should execute and debug user code as transparently as possible. I now think that the debugger should not step into any idlelib file unless this is explicitly requested in a separate check box ('for IDLE maintainers'. I suspect a blanket no-idlelib or yes-idlelib policy will be faster than the current code, and would avoid the current bug of not stepping into user code. I recently moved the Pseudofile definitions from pyshell to run so that run does not need to import pyshell. I did not consider whether or how this would affect debugging and should not have to. I plan other refactorings and movements between files. Whether to worry about stepping in is a different issue, and one not specific to IDLE. ---------- assignee: -> terry.reedy nosy: +Al.Sweigart versions: +Python 3.6 -Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 15:43:10 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 25 Jul 2016 19:43:10 +0000 Subject: [issue27615] IDLE's debugger steps into PyShell.py for calls to print() et al In-Reply-To: <1469467759.18.0.354149143305.issue27615@psf.upfronthosting.co.za> Message-ID: <1469475790.48.0.611945552895.issue27615@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Whether or not to step in idlelib/pyshell.py is part of the general issue of stepping into any idlelib file #15335. I copied the above to that issue. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> IDLE - debugger steps into print and over rpc.py code _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 15:46:59 2016 From: report at bugs.python.org (Ned Deily) Date: Mon, 25 Jul 2016 19:46:59 +0000 Subject: [issue27617] Compiled bdist_wininst missing from embedded distribution In-Reply-To: <1469474880.88.0.362049415558.issue27617@psf.upfronthosting.co.za> Message-ID: <1469476019.84.0.0842147176479.issue27617@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- components: +Windows -Distutils nosy: +paul.moore, steve.dower, tim.golden, zach.ware -dstufft, eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 16:22:47 2016 From: report at bugs.python.org (Eryk Sun) Date: Mon, 25 Jul 2016 20:22:47 +0000 Subject: [issue27612] socket.gethostbyname resolving octal IP addresses incorrectly In-Reply-To: <1469428074.1.0.701366093272.issue27612@psf.upfronthosting.co.za> Message-ID: <1469478167.43.0.462115020372.issue27612@psf.upfronthosting.co.za> Eryk Sun added the comment: socket.gethostbyname calls the internal function setipaddr, which tries to avoid a name resolution by first calling either inet_pton or inet_addr. Otherwise it calls getaddrinfo. Windows ------- setipaddr calls inet_addr, which supports octal [1]. ctypes example: ws2_32 = ctypes.WinDLL('ws2_32') in_addr = ctypes.c_ubyte * 4 ws2_32.inet_addr.restype = in_addr >>> ws2_32.inet_addr(b'0177.0000.0000.0001')[:] [127, 0, 0, 1] 3.5+ could call inet_pton since it was added in Vista. However, it does not support octal: >>> addr = in_addr() >>> ws2_32.inet_pton(socket.AF_INET, b'0177.0000.0000.0001', addr) 0 >>> ws2_32.inet_pton(socket.AF_INET, b'127.0.0.1', addr) 1 >>> addr[:] [127, 0, 0, 1] socket.inet_pton instead calls WSAStringToAddressA, which does support octal: >>> list(socket.inet_pton(socket.AF_INET, '0177.0000.0000.0001')) [127, 0, 0, 1] socket.gethostbyname_ex calls gethostbyname since gethostbyname_r isn't defined. This does not support octal and errors out: >>> socket.gethostbyname_ex('0177.0000.0000.0001') Traceback (most recent call last): File "", line 1, in socket.herror: [Errno 11001] host not found getaddrinfo also does not support octal and errors out: >>> socket.getaddrinfo('0177.0000.0000.0001', None)[0] Traceback (most recent call last): File "", line 1, in File "C:\Program Files\Python35\lib\socket.py", line 732, in getaddrinfo for res in _socket.getaddrinfo(host, port, family, type, proto, flags): socket.gaierror: [Errno 11001] getaddrinfo failed >>> ctypes.FormatError(11001) 'No such host is known.' [1]: https://msdn.microsoft.com/en-us/library/ms738563#internet_addresses ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 16:55:03 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 25 Jul 2016 20:55:03 +0000 Subject: [issue27618] docs for threading.Lock claim it's a class (since 3.3), but it's not (and has never been, apparently) Message-ID: <1469480103.96.0.342423272445.issue27618@psf.upfronthosting.co.za> New submission from Guido van Rossum: The docs for threading.Lock say 79534: .. versionchanged:: 3.3 79534: Changed from a factory function to a class. but the implementation in threading.py doesn't define a class named Lock, and in fact it is an alias for _thread.allocate_lock. Are the docs wrong, or is the source? Or did this get changed back later? ---------- messages: 271305 nosy: gvanrossum priority: normal severity: normal status: open title: docs for threading.Lock claim it's a class (since 3.3), but it's not (and has never been, apparently) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 17:09:11 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 25 Jul 2016 21:09:11 +0000 Subject: [issue27618] docs for threading.Lock claim it's a class (since 3.3), but it's not (and has never been, apparently) In-Reply-To: <1469480103.96.0.342423272445.issue27618@psf.upfronthosting.co.za> Message-ID: <1469480951.49.0.707412500238.issue27618@psf.upfronthosting.co.za> R. David Murray added the comment: The relevant issue is #10968. Apparently while editing the doc changes I caught the fact that RLock wasn't actually converted, but I missed the fact that Lock wasn't converted. So, it is a doc error and should be corrected. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 17:12:04 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 25 Jul 2016 21:12:04 +0000 Subject: [issue27617] Compiled bdist_wininst missing from embedded distribution In-Reply-To: <1469474880.88.0.362049415558.issue27617@psf.upfronthosting.co.za> Message-ID: <1469481124.45.0.90102959393.issue27617@psf.upfronthosting.co.za> Steve Dower added the comment: This is deliberate. You should "vendor" packages into the embedded distro by copying them from an install into a regular one. Your application installer should put the correct files onto the user's machine - don't rely on pip. If that last sentence didn't make sense, then you probably shouldn't be using the embedded distro. If you're just looking for a lightweight install of Python that doesn't have any obvious entry points or registration, see whether https://www.nuget.org/packages/python/ fits your needs. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 17:13:01 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 25 Jul 2016 21:13:01 +0000 Subject: [issue27617] Compiled bdist_wininst missing from embedded distribution In-Reply-To: <1469474880.88.0.362049415558.issue27617@psf.upfronthosting.co.za> Message-ID: <1469481181.65.0.139815720693.issue27617@psf.upfronthosting.co.za> Steve Dower added the comment: Also, the doc page at https://docs.python.org/3.5/using/windows.html describes this in more detail. (Though it doesn't yet refer to the Nuget packages as those are an experiment that I may or may not continue.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 19:00:41 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 25 Jul 2016 23:00:41 +0000 Subject: [issue27618] docs for threading.Lock claim it's a class (since 3.3), but it's not (and has never been, apparently) In-Reply-To: <1469480103.96.0.342423272445.issue27618@psf.upfronthosting.co.za> Message-ID: <1469487641.01.0.681776184632.issue27618@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python versions: +Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 20:17:50 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 26 Jul 2016 00:17:50 +0000 Subject: [issue27614] Race in test_docxmlrpc.py In-Reply-To: <1469459139.76.0.959920407285.issue27614@psf.upfronthosting.co.za> Message-ID: <1469492270.71.0.0462390669055.issue27614@psf.upfronthosting.co.za> Martin Panter added the comment: I don?t understand why we have so many tests that assign the server port in the server thread, and then use some sort of synchronization to get it to the client thread. IMO it would be simpler in this case to do something like: def setUp(self): serv = DOCXMLRPCServer(...) self.addCleanup(serv.server_close) [_, PORT] = serv.server_address # Eliminates ?ready? event # Other server setup here thread = threading.Thread(target=serv.serve_forever) thread.start() self.addCleanup(thread.join) # Instead of self.evt self.addCleanup(serv.shutdown) self.client = httplib.HTTPConnection("localhost:%d" % PORT) self.addCleanup(self.client.close) ---------- components: +Tests -Library (Lib) nosy: +martin.panter stage: -> patch review versions: -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 20:50:17 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Tue, 26 Jul 2016 00:50:17 +0000 Subject: [issue27619] getopt should strip whitespace from long arguments Message-ID: <1469494217.58.0.75154224673.issue27619@psf.upfronthosting.co.za> New submission from Steven D'Aprano: As reported here: https://mail.python.org/pipermail/python-list/2016-July/711333.html there's a possible annoyance with getopt when you accidentally leave whitespace on a long option. On my Centos system, getopt ignores leading and trailing whitespace on long options. [steve at ando ~]$ getopt -o "" -l " spam , eggs " -- --spam --eggs arg --spam --eggs -- 'arg' Python's getopt should do the same. (Patch attached.) ---------- components: Library (Lib) files: getopt.patch keywords: patch messages: 271310 nosy: steven.daprano priority: normal severity: normal status: open title: getopt should strip whitespace from long arguments type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43884/getopt.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 20:54:51 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 26 Jul 2016 00:54:51 +0000 Subject: [issue27620] IDLE: Add keyboard equivalents for mouse actions. Message-ID: <1469494491.39.0.22722488108.issue27620@psf.upfronthosting.co.za> New submission from Terry J. Reedy: Reading https://en.wikipedia.org/wiki/IBM_Common_User_Access and in particular "All operations could be done with either the mouse or the keyboard;", I checked IDLE's dialogs. The Windows dialogs accessed as common dialogs work correctly. I will assume true for other OSes until told otherwise. The new Query widget recogizes for [Ok] but not for [Cancel]. My omission, easily corrected. Search boxes cannot set options with keys. Notepad++ can. The Options dialog has no key equivalents. ---------- assignee: terry.reedy components: IDLE messages: 271311 nosy: terry.reedy priority: normal severity: normal stage: test needed status: open title: IDLE: Add keyboard equivalents for mouse actions. type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 20:58:58 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 26 Jul 2016 00:58:58 +0000 Subject: [issue27620] IDLE: Add keyboard equivalents for mouse actions. In-Reply-To: <1469494491.39.0.22722488108.issue27620@psf.upfronthosting.co.za> Message-ID: <20160726005855.21496.68560.76160D48@psf.io> Roundup Robot added the comment: New changeset 352fc11b9fd2 by Terry Jan Reedy in branch 'default': Issue #27620: Escape key closes Query box as cancelled. https://hg.python.org/cpython/rev/352fc11b9fd2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 21:01:28 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 26 Jul 2016 01:01:28 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <1469494888.53.0.221199625032.issue24773@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: The remaining failures all seems to be related to the Morocco rules: both Africa/El_Aaiun [1] and Africa/Casablanca [2] use those rules. The affected date is October 4, 2037, for which Morocco has a special rule. [3] It looks like the problem is with the system date/time library. The 2037 transition is specified in the tzfile as POSIX time 2138234400 and system date utility produced a value different from that of IANA's date [4]: $ TZ=/usr/share/zoneinfo/Africa/El_Aaiun date -d @2138234400 Sun Oct 4 03:00:00 WEST 2037 $ TZ=/usr/share/zoneinfo/Africa/El_Aaiun ./date -r 2138234400 Sun Oct 4 02:00:00 WET 2037 [1]: https://github.com/eggert/tz/blob/2016f/africa#L917 [2]: https://github.com/eggert/tz/blob/2016f/africa#L901 [3]: https://github.com/eggert/tz/blob/2016f/africa#L898 [4]: https://github.com/eggert/tz/blob/2016f/date.c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 21:04:08 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 26 Jul 2016 01:04:08 +0000 Subject: [issue27614] Race in test_docxmlrpc.py In-Reply-To: <1469459139.76.0.959920407285.issue27614@psf.upfronthosting.co.za> Message-ID: <1469495048.38.0.713049328902.issue27614@psf.upfronthosting.co.za> R. David Murray added the comment: Because the real port number doesn't exist until the server thread starts running and binds the socket using port number 0. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 21:14:55 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 26 Jul 2016 01:14:55 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <1469495695.42.0.802834571946.issue24773@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Could our Morocco issue be similar to Fiji issue? https://github.com/eggert/tz/commit/6d00980f1ff2ac665f3de027c79faacf4f26d1b0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 21:28:53 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 26 Jul 2016 01:28:53 +0000 Subject: [issue27614] Race in test_docxmlrpc.py In-Reply-To: <1469459139.76.0.959920407285.issue27614@psf.upfronthosting.co.za> Message-ID: <1469496533.32.0.423032227577.issue27614@psf.upfronthosting.co.za> Martin Panter added the comment: The whole point of my suggestion was to bind and set the server socket to listing mode before starting the other thread. The socketserver constructor should do this before returning: >>> s = DocXMLRPCServer(("localhost", 0)) # Calls bind() and listen() >>> s.server_address # Non-zero port has been allocated ('127.0.0.1', 49806) >>> c = HTTPConnection(*s.server_address) >>> c.request("OPTIONS", "*") # No connection refused error ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 21:43:21 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 26 Jul 2016 01:43:21 +0000 Subject: [issue27579] Add a tutorial for AsyncIO in the documentation In-Reply-To: <1469025749.21.0.829921979586.issue27579@psf.upfronthosting.co.za> Message-ID: <1469497401.97.0.432259604621.issue27579@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Ludovic: Thank you for the offer. When I post a proposed text with code to #27546, I will nosy you if you have not already done so by then. Viktor: 'full integration' by adding a tk update in the standard _run_once is not possible as tkinter is not always present. I started #27546 by creating a custom subclass, but that requires dealing with the Selector and Proactor subclasses and default loop policy and still will not work with independent implementations. I considered a tk-loop implementation, but speed tests do not make that very inviting. The simple code I then tried is my current best recommendation. It will work with any asyncio compatible implementation. Besides the test with IDLE, Guido tested it with Examples/crawl.py, and I will improve on that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 22:12:13 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 26 Jul 2016 02:12:13 +0000 Subject: [issue27581] Fix overflow check in PySequence_Tuple In-Reply-To: <1469079408.21.0.622161481276.issue27581@psf.upfronthosting.co.za> Message-ID: <1469499133.83.0.956114054846.issue27581@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 22:29:18 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 26 Jul 2016 02:29:18 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <1469500158.86.0.728614647204.issue24773@psf.upfronthosting.co.za> Martin Panter added the comment: Just confirming that my Casablanca failure is restricted to the 32-bit build, though I think you already figured this out. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 23:16:34 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 26 Jul 2016 03:16:34 +0000 Subject: [issue27619] getopt should strip whitespace from long arguments In-Reply-To: <1469494217.58.0.75154224673.issue27619@psf.upfronthosting.co.za> Message-ID: <1469502994.75.0.198572241669.issue27619@psf.upfronthosting.co.za> Berker Peksag added the comment: I left some review comments on Rietveld. I think we can treat this as a bug and fix it in 3.5 too. ---------- nosy: +berker.peksag stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 23:22:15 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 26 Jul 2016 03:22:15 +0000 Subject: [issue26462] Patch to enhance literal block language declaration In-Reply-To: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za> Message-ID: <1469503335.92.0.669368074568.issue26462@psf.upfronthosting.co.za> Changes by Martin Panter : Added file: http://bugs.python.org/file43885/issue26462.v4_regen.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 00:17:35 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Tue, 26 Jul 2016 04:17:35 +0000 Subject: [issue27619] getopt should strip whitespace from long arguments In-Reply-To: <1469494217.58.0.75154224673.issue27619@psf.upfronthosting.co.za> Message-ID: <1469506655.77.0.107568145946.issue27619@psf.upfronthosting.co.za> Steven D'Aprano added the comment: Thanks for the quick review, I've fixed the issues you mentioned. ---------- Added file: http://bugs.python.org/file43886/getopt.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 00:50:33 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Jul 2016 04:50:33 +0000 Subject: [issue27619] getopt should strip whitespace from long arguments In-Reply-To: <1469494217.58.0.75154224673.issue27619@psf.upfronthosting.co.za> Message-ID: <1469508633.22.0.552058071662.issue27619@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > On my Centos system, getopt ignores leading and trailing whitespace on long options. This is not related to how getopt_long in C works with leading and trailing whitespace on long options, but is related to how command-line utility getopt parses a list of long options. My answer: if you don't want a space in your long_option, don't put a space in there. There is no a bug in Python, and the patch just complicates the code in attempt to fix one particular user error. ---------- nosy: +serhiy.storchaka resolution: -> not a bug _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 00:56:37 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Tue, 26 Jul 2016 04:56:37 +0000 Subject: [issue27619] getopt should strip whitespace from long arguments In-Reply-To: <1469508633.22.0.552058071662.issue27619@psf.upfronthosting.co.za> Message-ID: <20160726045631.GT27919@ando.pearwood.info> Steven D'Aprano added the comment: On Tue, Jul 26, 2016 at 04:50:33AM +0000, Serhiy Storchaka wrote: > My answer: if you don't want a space in your long_option, don't put a > space in there. There is no a bug in Python, That's why I listed it as an enhancement, not a bug. > and the patch just complicates the code in attempt to fix one > particular user error. Sure. But the extra complexity is tiny, and the benefit is real, and it makes Python getopt behave more like the shell getopt, which I think is appropriate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 01:01:20 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Jul 2016 05:01:20 +0000 Subject: [issue27619] getopt should strip whitespace from long arguments In-Reply-To: <1469494217.58.0.75154224673.issue27619@psf.upfronthosting.co.za> Message-ID: <1469509280.44.0.443051698875.issue27619@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It makes Python getopt behave less like the C getopt. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 01:41:16 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 26 Jul 2016 05:41:16 +0000 Subject: [issue27546] Integrate tkinter and asyncio (and async) In-Reply-To: <1468815010.57.0.709565417017.issue27546@psf.upfronthosting.co.za> Message-ID: <1469511676.49.0.5271682939.issue27546@psf.upfronthosting.co.za> Terry J. Reedy added the comment: [On #27579, Lodovic Gasc volunteered to open and help with an issue on the github asyncio-doc project.] Ludovic, here is my current suggestion for the asyncio tutorial or how-to. Adding a Tkinter GUI to an Asyncio Program ------------------------------------------- Assume that the tkinter Tk instance is called 'root' and the asyncio loop is called 'loop'. Add a callback loop like the following. def tk_update(): root.update() loop.call_soon(tk_update) # or loop.call_later(delay, tk_update) Call tk_update before each loop.run_forever() or loop.run_until_complete(...) call. Do not call root.mainloop() or root.quit(). Loop.stop() or completion of run_until_complete will stop the tk_update loop. This method is used in the following example. --- Follow this with loop_tk2.py as an example. It is carefully written to be a template that people can build on. Some notes: 0. I REALLY like being able to write tkinter animations with async for. 1. I initially called loop.close immediately after loop.stop in App.close. This is a natural think for a tkinter programmer to do. But it does not work because loop.stop does not *immediately* take effect, and loop.close will typically get called before it does. Now I understand that loop.close() must physically follow loop.run_xxx() to ensure that it temporally follows the actual stopping of the loop. 2. I did not initially make a list of tasks. This worked once, but on the next run I got a "Task was destroyed but it is pending!:" message. Cancelling all 'forever' tasks makes for a clean shutdown. If/when you open a thread, please post url here and I will subscribe. [Guido, I will adapt this example for crawl.py.] ---------- nosy: +Ludovic.Gasc Added file: http://bugs.python.org/file43887/loop_tk2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 01:44:12 2016 From: report at bugs.python.org (Ram Rachum) Date: Tue, 26 Jul 2016 05:44:12 +0000 Subject: [issue27604] More details about `-O` flag In-Reply-To: <1469353581.38.0.811049911305.issue27604@psf.upfronthosting.co.za> Message-ID: <1469511852.34.0.196423197842.issue27604@psf.upfronthosting.co.za> Ram Rachum added the comment: I'm sorry everyone, for being unpleasant on this thread. Rereading the thread from the beginning, I think I misunderstood Brett's message and immediately saw it as someone trying to block my efforts rather than just answering the question I asked. Anyway, I attached my patch. A couple of questions: 1. As you can see in the patch, I also found a spot in `Doc/c-api/veryhigh.rst` where optimization mode was mentioned, so I figured let's add the "this may change in the future" comment there. But I don't know that area of the docs at all, so let me know if that makes sense there. 2. I believe these are the docs for Python 3.4, right? Can this change be merged into the documentation for all versions of Python? ---------- keywords: +patch Added file: http://bugs.python.org/file43888/1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 02:02:46 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Jul 2016 06:02:46 +0000 Subject: [issue27621] incorrectly works in IDLE Query dialogs Message-ID: <1469512966.74.0.594331033204.issue27621@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: When open new Query dialog in IDLE (e.g. "Open Module" dialog), move a focus on the Cancel button and press on keyboard, the OK button is invoked instead of Cancel. ---------- assignee: terry.reedy components: IDLE messages: 271326 nosy: serhiy.storchaka, terry.reedy priority: normal severity: normal status: open title: incorrectly works in IDLE Query dialogs type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 02:20:38 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Tue, 26 Jul 2016 06:20:38 +0000 Subject: [issue27622] int.to_bytes(): docstring is not precise Message-ID: <1469514037.92.0.489318728995.issue27622@psf.upfronthosting.co.za> New submission from ???? ?????????: Docstring says: The signed keyword-only argument determines whether two's complement is used to represent the integer. If signed is False and a negative integer is given, an OverflowError is raised. But actually, (130).to_bytes(1, 'big', signed=True) will also trigger OverflowError ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 271327 nosy: docs at python, mmarkk priority: normal severity: normal status: open title: int.to_bytes(): docstring is not precise type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 02:22:23 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Jul 2016 06:22:23 +0000 Subject: [issue27622] int.to_bytes(): docstring is not precise In-Reply-To: <1469514037.92.0.489318728995.issue27622@psf.upfronthosting.co.za> Message-ID: <1469514143.33.0.956003199141.issue27622@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What is wrong? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 02:26:20 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Tue, 26 Jul 2016 06:26:20 +0000 Subject: [issue27623] int.to_bytes() and int.from_bytes(): raise ValueError when bytes count is zero Message-ID: <1469514380.74.0.642597369558.issue27623@psf.upfronthosting.co.za> New submission from ???? ?????????: As you can see, these conversions are not consistent. What is use case to allow that? =================== In [22]: (-1).to_bytes(0, 'big', signed=True) Out[22]: b'' In [23]: (0).to_bytes(0, 'big', signed=True) Out[23]: b'' As you can see, two different values serialized to same empty bytes sequence. =================== In [28]: int.from_bytes(b'', 'big', signed=True) Out[28]: 0 In [29]: int.from_bytes(b'', 'big', signed=False) Out[29]: 0 Anyway, -1 can not be deserialized. =================== ---------- messages: 271329 nosy: mmarkk priority: normal severity: normal status: open title: int.to_bytes() and int.from_bytes(): raise ValueError when bytes count is zero _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 02:26:56 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Tue, 26 Jul 2016 06:26:56 +0000 Subject: [issue27623] int.to_bytes() and int.from_bytes(): raise ValueError when bytes count is zero In-Reply-To: <1469514380.74.0.642597369558.issue27623@psf.upfronthosting.co.za> Message-ID: <1469514416.65.0.383299618594.issue27623@psf.upfronthosting.co.za> Changes by ???? ????????? : ---------- components: +Library (Lib) type: -> behavior versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 02:28:39 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Tue, 26 Jul 2016 06:28:39 +0000 Subject: [issue27623] int.to_bytes() and int.from_bytes(): raise ValueError when bytes count is zero In-Reply-To: <1469514380.74.0.642597369558.issue27623@psf.upfronthosting.co.za> Message-ID: <1469514519.55.0.894012351311.issue27623@psf.upfronthosting.co.za> ???? ????????? added the comment: So, as I think, it must ValueError when bytes count is zero. This is like division by zero. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 02:35:48 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 26 Jul 2016 06:35:48 +0000 Subject: [issue27620] IDLE: Add keyboard equivalents for mouse actions. In-Reply-To: <1469494491.39.0.22722488108.issue27620@psf.upfronthosting.co.za> Message-ID: <1469514948.23.0.609173104394.issue27620@psf.upfronthosting.co.za> Terry J. Reedy added the comment: #27621 is about invoking [Ok] even when the focus is on [Cancel]. ---------- dependencies: + incorrectly works in IDLE Query dialogs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 02:36:06 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 26 Jul 2016 06:36:06 +0000 Subject: [issue26462] Patch to enhance literal block language declaration In-Reply-To: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za> Message-ID: <1469514966.48.0.558685743999.issue26462@psf.upfronthosting.co.za> Martin Panter added the comment: I?ve finished going over the latest patch. There are a couple of problems; see the review link. Also, why did you add the changes in Doc/library/decimal.rst? In your second patch, you removed one of these changes, but now you have added more. They seem to reduce the number of doctests reported (make -C Doc/ doctest). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 02:50:48 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Tue, 26 Jul 2016 06:50:48 +0000 Subject: [issue27622] int.to_bytes(): docstring is not precise In-Reply-To: <1469514037.92.0.489318728995.issue27622@psf.upfronthosting.co.za> Message-ID: <1469515848.72.0.461629641593.issue27622@psf.upfronthosting.co.za> ???? ????????? added the comment: The docstring does not say, that positive values also may raise OverflowError if it can not fit into `(byte_count * 8) - 1` bits. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 02:51:37 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Tue, 26 Jul 2016 06:51:37 +0000 Subject: [issue27622] int.to_bytes(): docstring is not precise In-Reply-To: <1469514037.92.0.489318728995.issue27622@psf.upfronthosting.co.za> Message-ID: <1469515897.82.0.623134343606.issue27622@psf.upfronthosting.co.za> ???? ????????? added the comment: I mean when signed=True ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 02:53:10 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 26 Jul 2016 06:53:10 +0000 Subject: [issue26638] Avoid warnings about missing CLI options when building documentation In-Reply-To: <1458881380.09.0.599104229044.issue26638@psf.upfronthosting.co.za> Message-ID: <20160726065258.24839.98910.D9F4E64C@psf.io> Roundup Robot added the comment: New changeset 3996dd17ca21 by Martin Panter in branch '3.5': Issue #26638: Don?t link 2to3 -l option to the tarfile -l option https://hg.python.org/cpython/rev/3996dd17ca21 New changeset d7cbaaba59e8 by Martin Panter in branch 'default': Issue #26638: Merge CLI link fix from 3.5 https://hg.python.org/cpython/rev/d7cbaaba59e8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 02:53:53 2016 From: report at bugs.python.org (INADA Naoki) Date: Tue, 26 Jul 2016 06:53:53 +0000 Subject: [issue27622] int.to_bytes(): docstring is not precise In-Reply-To: <1469514037.92.0.489318728995.issue27622@psf.upfronthosting.co.za> Message-ID: <1469516033.56.0.0276958110154.issue27622@psf.upfronthosting.co.za> INADA Naoki added the comment: docstring says: The integer is represented using length bytes. An OverflowError is raised if the integer is not representable with the given number of bytes. (Python 3.5.2) ---------- nosy: +methane _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 02:58:46 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Tue, 26 Jul 2016 06:58:46 +0000 Subject: [issue27622] int.to_bytes(): docstring is not precise In-Reply-To: <1469514037.92.0.489318728995.issue27622@psf.upfronthosting.co.za> Message-ID: <1469516326.77.0.892628168788.issue27622@psf.upfronthosting.co.za> ???? ????????? added the comment: Well. Phrase `If signed is False and a negative integer is given, an OverflowError is raised.` describe onlyhalf of behaviour. It does not explain behaviour when `signed=True` and value is big enough to trigger exception, but not enough to trigger it when signed=False. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 02:59:59 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Tue, 26 Jul 2016 06:59:59 +0000 Subject: [issue27622] int.to_bytes(): docstring is not precise In-Reply-To: <1469514037.92.0.489318728995.issue27622@psf.upfronthosting.co.za> Message-ID: <1469516399.33.0.538855707734.issue27622@psf.upfronthosting.co.za> ???? ????????? added the comment: So, in order to make documentation consistent, either new text should be added, or last phraze removed. That's what I think. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 03:01:36 2016 From: report at bugs.python.org (INADA Naoki) Date: Tue, 26 Jul 2016 07:01:36 +0000 Subject: [issue27622] int.to_bytes(): docstring is not precise In-Reply-To: <1469514037.92.0.489318728995.issue27622@psf.upfronthosting.co.za> Message-ID: <1469516496.97.0.178626740382.issue27622@psf.upfronthosting.co.za> INADA Naoki added the comment: @mmarkk Do you read full docstring? It's documented very clearly. --- int.to_bytes(length, byteorder, *, signed=False) -> bytes Return an array of bytes representing an integer. The integer is represented using length bytes. An OverflowError is raised if the integer is not representable with the given number of bytes. The byteorder argument determines the byte order used to represent the integer. If byteorder is 'big', the most significant byte is at the beginning of the byte array. If byteorder is 'little', the most significant byte is at the end of the byte array. To request the native byte order of the host system, use `sys.byteorder' as the byte order value. The signed keyword-only argument determines whether two's complement is used to represent the integer. If signed is False and a negative integer is given, an OverflowError is raised. --- ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 03:03:45 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 26 Jul 2016 07:03:45 +0000 Subject: [issue26638] Avoid warnings about missing CLI options when building documentation In-Reply-To: <1458881380.09.0.599104229044.issue26638@psf.upfronthosting.co.za> Message-ID: <1469516625.28.0.3155104585.issue26638@psf.upfronthosting.co.za> Changes by Martin Panter : Added file: http://bugs.python.org/file43889/doc-warnings.v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 03:04:52 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Jul 2016 07:04:52 +0000 Subject: [issue27622] int.to_bytes(): docstring is not precise In-Reply-To: <1469514037.92.0.489318728995.issue27622@psf.upfronthosting.co.za> Message-ID: <1469516692.39.0.113287599845.issue27622@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The docstring looks correct to me. The last phrase corresponds to the last paragraph that describes the signed keyword-only argument. Is there anyone else for whom the docstring looks wrong? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 03:11:34 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 26 Jul 2016 07:11:34 +0000 Subject: [issue27621] incorrectly works in IDLE Query dialogs In-Reply-To: <1469512966.74.0.594331033204.issue27621@psf.upfronthosting.co.za> Message-ID: <1469517094.72.0.712200508525.issue27621@psf.upfronthosting.co.za> Terry J. Reedy added the comment: While writing #27620 and adding a binding to Query for , a few hours ago, I realized that this would be the case, that it could be considered a bug, and that the fix will be a 'return' function that looks at the focus before invoking [Ok] (the default) or [Cancel] (when it has the focus). def return_key(self, event): if self.focus_get() == self.button_cancel: self.cancel() else: self.ok() appears to work. I will push tomorrow after writing a test. Something similar is needed for config dialog. I just tested the search dialog and it behaves the same as query does now. If one tabs enough to put the focus on close, does find anyway. Do you agree that Esc should always cancel regardless of where the focus is? I would appreciate your input on #27620 as to the 'right' behavior we should aim at for the different dialogs. While I think of it, the indication of ttk.Entry focus with the default Windows theme is a shift of the 1 pixel black border to a 1 pixel blue border. It is not obvious. I want to look as other Window's theme or possibly a custom style. Now a priority yet. ---------- stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 03:12:55 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 26 Jul 2016 07:12:55 +0000 Subject: [issue27621] incorrectly works in IDLE Query dialogs In-Reply-To: <1469512966.74.0.594331033204.issue27621@psf.upfronthosting.co.za> Message-ID: <1469517175.96.0.577293705809.issue27621@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I made this a dependency of #27620. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 03:15:25 2016 From: report at bugs.python.org (koobs) Date: Tue, 26 Jul 2016 07:15:25 +0000 Subject: [issue27612] socket.gethostbyname resolving octal IP addresses incorrectly In-Reply-To: <1469428074.1.0.701366093272.issue27612@psf.upfronthosting.co.za> Message-ID: <1469517325.59.0.0369669937307.issue27612@psf.upfronthosting.co.za> koobs added the comment: @David The symptoms from FreeBSD look a little different: Only gethostbyname affected only on 2.7 and 3.3 on all freebsd versions (9, 10, 11). Python 3.2 was not tested (freebsd port was deleted), but likely affected as well Feels/Appears like a gethostbyname fix or other change affecting gethostbyname in 3.4, missing merges to 3.3, (likely 3.2) and 2.7. Full test matrix attached ---------- versions: +Python 3.3 Added file: http://bugs.python.org/file43890/socket-test-freebsd-9-10-11-python-27-33-34-35.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 03:26:16 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Jul 2016 07:26:16 +0000 Subject: [issue27621] incorrectly works in IDLE Query dialogs In-Reply-To: <1469512966.74.0.594331033204.issue27621@psf.upfronthosting.co.za> Message-ID: <1469517976.36.0.61547594969.issue27621@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I have wrote similar patch. There are many ways to fix this issue. Tk code for dialog widgets is more complex and general. ---------- keywords: +patch Added file: http://bugs.python.org/file43891/idle_query_press_return.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 03:26:57 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Jul 2016 07:26:57 +0000 Subject: [issue27620] IDLE: Add keyboard equivalents for mouse actions. In-Reply-To: <1469494491.39.0.22722488108.issue27620@psf.upfronthosting.co.za> Message-ID: <1469518017.64.0.851189027081.issue27620@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I agree that Esc should always cancel regardless of where the focus is. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 04:16:26 2016 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 26 Jul 2016 08:16:26 +0000 Subject: [issue27612] socket.gethostbyname resolving octal IP addresses incorrectly In-Reply-To: <1469428074.1.0.701366093272.issue27612@psf.upfronthosting.co.za> Message-ID: <1469520986.39.0.357952887945.issue27612@psf.upfronthosting.co.za> Ronald Oussoren added the comment: For what it is worth: the relevant standard says that octal and hexadecimal addresses should be accepted (POSIX getaddrinfo refers to inet_addr for numeric IP addresses and that says that octal and hexadecimal numbers are valid in IP addresses), see: http://pubs.opengroup.org/onlinepubs/9699919799/functions/inet_addr.html# Adding a implementation note to the documentation might be useful, but it should IMHO only mention that the platform getaddrinfo is used in the implementation for the Python functions and should not mention specific platforms because we don't have the processes to keep such specific notes up-to-date. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 04:31:35 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 26 Jul 2016 08:31:35 +0000 Subject: [issue20948] -Wformat=2 -Wformat-security findings In-Reply-To: <1394991695.88.0.958685925479.issue20948@psf.upfronthosting.co.za> Message-ID: <1469521895.58.0.760972010836.issue20948@psf.upfronthosting.co.za> Martin Panter added the comment: The Modules/main.c cases are not errors. They are just long strings defined as static constants, rather than literals passed in directly. I think we can close this now. Unless people think this warning is worth using, in which case we should find a way to work around the false positives. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 04:53:31 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 26 Jul 2016 08:53:31 +0000 Subject: [issue17238] IDLE: Add import statement completion In-Reply-To: <1361287971.25.0.643782901011.issue17238@psf.upfronthosting.co.za> Message-ID: <1469523210.99.0.730522142169.issue17238@psf.upfronthosting.co.za> Martin Panter added the comment: The readline completion code does not strictly depend on on Readline, although currently it is modelled after its quirky API. But we can change that by adding a more general API. In , I suggested an API ?complete_code(code) -> list of modules, attributes, globals, etc.? In the Readline case, you pass in the line of code up to the cursor, and it would return possible completions. Perhaps Idle might pass in multiple lines of code. There could also be a predefined global namespace, either as another parameter, or preloaded into a completer object. When I briefly looked at the Idle code a while back, it did not seem easy for me to adapt to this sort of API. But maybe you have a better idea of what could be done. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 04:57:31 2016 From: report at bugs.python.org (Jeffrey Walton) Date: Tue, 26 Jul 2016 08:57:31 +0000 Subject: [issue20948] -Wformat=2 -Wformat-security findings In-Reply-To: <1469521895.58.0.760972010836.issue20948@psf.upfronthosting.co.za> Message-ID: Jeffrey Walton added the comment: On Tue, Jul 26, 2016 at 4:31 AM, Martin Panter wrote: > > Martin Panter added the comment: > > The Modules/main.c cases are not errors. They are just long strings defined as static constants, rather than literals passed in directly. > > I think we can close this now. Unless people think this warning is worth using, in which case we should find a way to work around the false positives. > Would it be possible to add some instrumentation to silence the finding? There's no sense in having multiple developers and qa research the issue. I'm guessing a percentage of developers and qa will file bug reports, so it will burn some of the python team's cycles, too. Maybe something like: #if (GCC_VERSION >= 40600) || (LLVM_CLANG_VERSION >= 10700) || (APPLE_CLANG_VERSION >= 20000) # define GCC_DIAGNOSTIC_AVAILABLE 1 #endif #if GCC_DIAGNOSTIC_AVAILABLE # pragma GCC diagnostic ignored "-Wformat-security" #endif If its safe to ignore the warning, then the technique above should be safe for a C/CC/CXX/CPP files. It will not cross-pollinate because its a source file, and not a header file. Jeff ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 05:22:00 2016 From: report at bugs.python.org (Julien) Date: Tue, 26 Jul 2016 09:22:00 +0000 Subject: [issue26462] Patch to enhance literal block language declaration In-Reply-To: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za> Message-ID: <1469524920.06.0.989471691406.issue26462@psf.upfronthosting.co.za> Julien added the comment: Here a new patch after reviewing comments on rietveld. ---------- Added file: http://bugs.python.org/file43892/issue26462.v5.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 05:26:19 2016 From: report at bugs.python.org (Julien) Date: Tue, 26 Jul 2016 09:26:19 +0000 Subject: [issue26462] Patch to enhance literal block language declaration In-Reply-To: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za> Message-ID: <1469525179.89.0.329114905118.issue26462@psf.upfronthosting.co.za> Julien added the comment: @martin I reviewed my changes on `decimal.rst` and I now just fixing the indentation problem, so I don't change anything unrealated to fixing warnings, and don't break doctests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 05:42:27 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Jul 2016 09:42:27 +0000 Subject: [issue20948] -Wformat=2 -Wformat-security findings In-Reply-To: <1394991695.88.0.958685925479.issue20948@psf.upfronthosting.co.za> Message-ID: <1469526147.58.0.563235292295.issue20948@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Seems warnings are gone after adding the const qualifier to static constant arrays (issue25923). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 05:43:19 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 26 Jul 2016 09:43:19 +0000 Subject: [issue26851] android compilation and link flags In-Reply-To: <1461673211.54.0.945034926098.issue26851@psf.upfronthosting.co.za> Message-ID: <1469526199.98.0.883491514143.issue26851@psf.upfronthosting.co.za> Xavier de Gaye added the comment: New patch. The sed commands used to evaluate ANDROID_API_LEVEL and _arm_arch do not need to discard comment lines and empty lines in the output of the preprocessor. ---------- Added file: http://bugs.python.org/file43893/build-flags_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 05:47:38 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 26 Jul 2016 09:47:38 +0000 Subject: [issue20948] -Wformat=2 -Wformat-security findings In-Reply-To: <1394991695.88.0.958685925479.issue20948@psf.upfronthosting.co.za> Message-ID: <1469526458.69.0.577420829967.issue20948@psf.upfronthosting.co.za> Martin Panter added the comment: GCC?s -Wformat options are documented at . We already enable -Wall by default, which implicitly enables -Wformat, but not -Wformat=2. Apparently, -Wformat=2 enables -Wformat-security, so you shouldn?t have to manually enable it. The -Wformat-security option enables warnings for stuff like printf(variable), without any extra arguments. Such a call could easily be changed, even if it is not a genuine problem. So I wouldn?t have a problem enabling this warning by default. (See also Issue 23545 proposing a few other warnings.) However I am not convinced it is worth working around the -Wformat-nonliteral warnings, given that all the warnings given above were false positives, and the general workaround would need six or seven preprocessor lines. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 06:14:33 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Tue, 26 Jul 2016 10:14:33 +0000 Subject: [issue26942] android: test_ctypes crashes on armv7 In-Reply-To: <1462290789.53.0.483745295219.issue26942@psf.upfronthosting.co.za> Message-ID: <1469528073.24.0.592329393095.issue26942@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Found libffi PR240 that fixes closures on Android: shell at ASUS_Z00E_2:/data/local/tmp $ python3.6 -m test.test_ctypes ...................................................................s......s..............s....................ssssssssssssssssssssss..................................ssssssssssssssssssssssssssss.s...sssOpenGL libraries: ('GL', None) ('GLU', None) ('gle', None) sss...........................s.s............s.........libc_name is None ss.sssss...s...s...........s....s..................................................................s.................................sssss..ss..........................s....................ss.sssssss ---------------------------------------------------------------------- Ran 456 tests in 2.090s OK (skipped=92) See https://github.com/yan12125/python3-android/commit/1daebca128e9ca1a9a39ef143ded7090cfa71cc9 for details. By http://comments.gmane.org/gmane.comp.lib.ffi.general/1235, SELinux affects the result, too. PR240 of libffi assumes SELinux is disabled. I have disabled SELinux on my phone for some root applications. I'm not sure whether PR240 works for phones with SELinux or not. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 06:56:36 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 26 Jul 2016 10:56:36 +0000 Subject: [issue26662] configure/Makefile doesn't check if "python" command works, needed to build Objects/typeslots.inc In-Reply-To: <1459247902.98.0.893274525942.issue26662@psf.upfronthosting.co.za> Message-ID: <20160726105631.94294.94088.0B685D55@psf.io> Roundup Robot added the comment: New changeset 5aff28f33b2a by Xavier de Gaye in branch '3.5': Issue #26662: Set PYTHON_FOR_GEN in configure https://hg.python.org/cpython/rev/5aff28f33b2a New changeset a290f992e69a by Xavier de Gaye in branch 'default': (merge from 3.5) Issue #26662: Set PYTHON_FOR_GEN in configure https://hg.python.org/cpython/rev/a290f992e69a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 07:00:01 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 26 Jul 2016 11:00:01 +0000 Subject: [issue26662] configure/Makefile doesn't check if "python" command works, needed to build Objects/typeslots.inc In-Reply-To: <1459247902.98.0.893274525942.issue26662@psf.upfronthosting.co.za> Message-ID: <1469530801.01.0.175654991829.issue26662@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 Tue Jul 26 07:34:34 2016 From: report at bugs.python.org (koobs) Date: Tue, 26 Jul 2016 11:34:34 +0000 Subject: [issue26662] configure/Makefile doesn't check if "python" command works, needed to build Objects/typeslots.inc In-Reply-To: <1459247902.98.0.893274525942.issue26662@psf.upfronthosting.co.za> Message-ID: <1469532874.12.0.322574510987.issue26662@psf.upfronthosting.co.za> Changes by koobs : ---------- nosy: +koobs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 07:43:02 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 26 Jul 2016 11:43:02 +0000 Subject: [issue26942] android: test_ctypes crashes on armv7 In-Reply-To: <1462290789.53.0.483745295219.issue26942@psf.upfronthosting.co.za> Message-ID: <1469533382.39.0.451857269102.issue26942@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Thanks for looking into that problem. Can you provide a patch ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 08:08:40 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Tue, 26 Jul 2016 12:08:40 +0000 Subject: [issue27621] incorrectly works in IDLE Query dialogs In-Reply-To: <1469512966.74.0.594331033204.issue27621@psf.upfronthosting.co.za> Message-ID: <1469534920.05.0.239137232361.issue27621@psf.upfronthosting.co.za> Steven D'Aprano added the comment: I expect that ESC should always cancel, and RETURN/ENTER should always accepts (OK or Save or whatever the "main" button is) regardless of where the focus is. If you want a keyboard shortcut to push the button with focus, use SPACE, not ENTER. ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 08:11:00 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Tue, 26 Jul 2016 12:11:00 +0000 Subject: [issue27619] getopt should strip whitespace from long arguments In-Reply-To: <1469509280.44.0.443051698875.issue27619@psf.upfronthosting.co.za> Message-ID: <20160726121054.GU27919@ando.pearwood.info> Steven D'Aprano added the comment: Serhiy Storchaka added the comment: > It makes Python getopt behave less like the C getopt. Exactly! If C getopt allows whitespace in long options, it's a GOOD thing to avoid such a poor design. Who would want a option --foo (note the trailing space)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 08:32:28 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Jul 2016 12:32:28 +0000 Subject: [issue27621] incorrectly works in IDLE Query dialogs In-Reply-To: <1469512966.74.0.594331033204.issue27621@psf.upfronthosting.co.za> Message-ID: <1469536348.39.0.395433137386.issue27621@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is against the convention. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 08:39:25 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Jul 2016 12:39:25 +0000 Subject: [issue27619] getopt should strip whitespace from long arguments In-Reply-To: <1469494217.58.0.75154224673.issue27619@psf.upfronthosting.co.za> Message-ID: <1469536765.57.0.593406121119.issue27619@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Who would want options --f o o, --f?oo, or --f??? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 09:00:53 2016 From: report at bugs.python.org (Doug Hoskisson) Date: Tue, 26 Jul 2016 13:00:53 +0000 Subject: [issue27624] unclear documentation on Queue.qsize() Message-ID: <1469538053.41.0.353171937214.issue27624@psf.upfronthosting.co.za> New submission from Doug Hoskisson: The documentation for Queue.qsize(): "Return the approximate size of the queue." "approximate" is unclear. It might suggest some strategy used for approximating, or it might be the exact size at an arbitrary time. It should be made more clear. ---------- assignee: docs at python components: Documentation messages: 271362 nosy: Doug Hoskisson, docs at python priority: normal severity: normal status: open title: unclear documentation on Queue.qsize() versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 09:20:30 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 26 Jul 2016 13:20:30 +0000 Subject: [issue27612] socket.gethostbyname resolving octal IP addresses incorrectly In-Reply-To: <1469428074.1.0.701366093272.issue27612@psf.upfronthosting.co.za> Message-ID: <1469539230.34.0.850940677204.issue27612@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't understand the point of the issue. Is it a documentation issue? Python doesn't parse anything: it's a thin wrapper on top of the standard C library. If you want to complain, report the issue to the maintainers of your C library ;-) ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 09:26:31 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 26 Jul 2016 13:26:31 +0000 Subject: [issue27612] socket.gethostbyname resolving octal IP addresses incorrectly In-Reply-To: <1469428074.1.0.701366093272.issue27612@psf.upfronthosting.co.za> Message-ID: <1469539591.02.0.790088196841.issue27612@psf.upfronthosting.co.za> STINNER Victor added the comment: > However, if someone wants to investigate further and finds a fix, we will evaluate it. IMHO the best fix is to document that the exact behaviour depends on the platform, and that only IPv4 decimal and IPv6 hexadecimal are portable. Corner cases like IPv4 octal addresses are not portable, you should write your own parser. Note: I checked ipaddress, it doesn't seem to support the funny octal addresses format. Why do you need octal addresses? What is your use case? :-p ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 09:30:08 2016 From: report at bugs.python.org (Matt Robenolt) Date: Tue, 26 Jul 2016 13:30:08 +0000 Subject: [issue27612] socket.gethostbyname resolving octal IP addresses incorrectly In-Reply-To: <1469428074.1.0.701366093272.issue27612@psf.upfronthosting.co.za> Message-ID: <1469539808.11.0.635862155523.issue27612@psf.upfronthosting.co.za> Matt Robenolt added the comment: > Why do you need octal addresses? What is your use case? :-p I didn't, but an attacker leveraged this to bypass security. We had checks against `127.0.0.1`, but this resolved to `177.0.0.1` incorrectly, bypassing the check. We were using `socket.gethostbyname` which yielded this. See https://github.com/getsentry/sentry/pull/3787 for a little bit more context. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 09:52:00 2016 From: report at bugs.python.org (Palm Kevin) Date: Tue, 26 Jul 2016 13:52:00 +0000 Subject: [issue27625] "make install" fails when no zlib support available Message-ID: <1469541120.27.0.508347520885.issue27625@psf.upfronthosting.co.za> New submission from Palm Kevin: It seems that on linux (red hat), the "make install" fails when no zlib support is available. (I have no zlib installed and I don't want to do so) I reproduced the problem with both python 3.5.1 and python 3.5.2 The command 'configure' and 'make' produced no errors, but the 'make install' failed with this error message: if test "xupgrade" != "xno" ; then \ case upgrade in \ upgrade) ensurepip="--upgrade" ;; \ install|*) ensurepip="" ;; \ esac; \ LD_LIBRARY_PATH=/usr/ls/tmp/py/Python-3.5.2:/usr/ls/app/python35/lib:./ls/lib:./ls/lib:/usr/molis/uniface9606/common/lib:/usr/molis/dlm/Linux/amd64:/usr/oracle/product/11.2.0/lib:/usr/oracle/product/11.2.0/lib: ./python -E -m ensurepip \ $ensurepip --root=/ ; \ fi Traceback (most recent call last): File "/usr/ls/tmp/py/Python-3.5.2/Lib/runpy.py", line 184, in _run_module_as_main "__main__", mod_spec) File "/usr/ls/tmp/py/Python-3.5.2/Lib/runpy.py", line 85, in _run_code exec(code, run_globals) File "/usr/ls/tmp/py/Python-3.5.2/Lib/ensurepip/__main__.py", line 4, in ensurepip._main() File "/usr/ls/tmp/py/Python-3.5.2/Lib/ensurepip/__init__.py", line 209, in _main default_pip=args.default_pip, File "/usr/ls/tmp/py/Python-3.5.2/Lib/ensurepip/__init__.py", line 116, in bootstrap _run_pip(args + [p[0] for p in _PROJECTS], additional_paths) File "/usr/ls/tmp/py/Python-3.5.2/Lib/ensurepip/__init__.py", line 40, in _run_pip import pip zipimport.ZipImportError: can't decompress data; zlib not available make: *** [install] Error 1 zlib is not required to run Python 3.5, it should thus not be required neither for setting up python. ---------- components: Build messages: 271366 nosy: palm.kevin priority: normal severity: normal status: open title: "make install" fails when no zlib support available type: compile error versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 09:56:31 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Tue, 26 Jul 2016 13:56:31 +0000 Subject: [issue26942] android: test_ctypes crashes on armv7 In-Reply-To: <1462290789.53.0.483745295219.issue26942@psf.upfronthosting.co.za> Message-ID: <1469541391.51.0.947982326511.issue26942@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: By msg264746, only ARM fails, so I patch libffi for arm and aarch64 triplets only ---------- keywords: +patch Added file: http://bugs.python.org/file43894/libffi-pr240.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 10:00:32 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Tue, 26 Jul 2016 14:00:32 +0000 Subject: [issue26942] android: test_ctypes crashes on armv7 In-Reply-To: <1462290789.53.0.483745295219.issue26942@psf.upfronthosting.co.za> Message-ID: <1469541632.61.0.668302616511.issue26942@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Test results against patched libffi in Modules/_ctypes: shell at ASUS_Z00E_2:/data/local/tmp $ python3.6 -m test.test_ctypes ...................................................................s......s..............s....................ssssssssssssssssssssss..................................ssssssssssssssssssssssssssss.s...sssOpenGL libraries: ('GL', None) ('GLU', None) ('gle', None) sss...........................s.s............s.........libc_name is None ss.sssss...s...s...........s....s..................................................................s.................................sssss..ss..........................s....................ssFsssssss ====================================================================== FAIL: test_struct_by_value (ctypes.test.test_win32.Structures) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/local/tmp/python3/lib/python3.6/ctypes/test/test_win32.py", line 133, in test_struct_by_value self.assertEqual(ret.left, left.value) AssertionError: -200 != 10 ---------------------------------------------------------------------- Ran 456 tests in 1.970s FAILED (failures=1, skipped=92) A failure occurs with libffi 3.1 while all tests passes with libffi git-master. Issue23085 may be the solution. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 10:01:48 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 26 Jul 2016 14:01:48 +0000 Subject: [issue27612] socket.gethostbyname resolving octal IP addresses incorrectly In-Reply-To: <1469428074.1.0.701366093272.issue27612@psf.upfronthosting.co.za> Message-ID: <1469541708.78.0.888368898572.issue27612@psf.upfronthosting.co.za> STINNER Victor added the comment: > I didn't, but an attacker leveraged this to bypass security. Ah, that's a real use case. Can you please rephrase the issue title to make it more explicit? Because in this issue, it's not obvious to me if octal addressses must be accepted on all platforms, or rejected on all platforms. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 10:02:57 2016 From: report at bugs.python.org (SilentGhost) Date: Tue, 26 Jul 2016 14:02:57 +0000 Subject: [issue27625] "make install" fails when no zlib support available In-Reply-To: <1469541120.27.0.508347520885.issue27625@psf.upfronthosting.co.za> Message-ID: <1469541777.85.0.0778930276224.issue27625@psf.upfronthosting.co.za> SilentGhost added the comment: Seems like the issue is caused by pip installation, so you should be able to fix it using --without-ensurepip switch for configure. ---------- nosy: +SilentGhost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 10:03:27 2016 From: report at bugs.python.org (Denny Weinberg) Date: Tue, 26 Jul 2016 14:03:27 +0000 Subject: [issue27516] Wrong initialization of python path with embeddable distribution In-Reply-To: <1468536614.57.0.563747018021.issue27516@psf.upfronthosting.co.za> Message-ID: <1469541807.27.0.0373049961385.issue27516@psf.upfronthosting.co.za> Changes by Denny Weinberg : ---------- nosy: +Denny Weinberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 10:04:14 2016 From: report at bugs.python.org (Denny Weinberg) Date: Tue, 26 Jul 2016 14:04:14 +0000 Subject: [issue27625] "make install" fails when no zlib support available In-Reply-To: <1469541120.27.0.508347520885.issue27625@psf.upfronthosting.co.za> Message-ID: <1469541854.43.0.883696210637.issue27625@psf.upfronthosting.co.za> Changes by Denny Weinberg : ---------- nosy: +Denny Weinberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 10:16:22 2016 From: report at bugs.python.org (Palm Kevin) Date: Tue, 26 Jul 2016 14:16:22 +0000 Subject: [issue27625] "make install" fails when no zlib support available In-Reply-To: <1469541120.27.0.508347520885.issue27625@psf.upfronthosting.co.za> Message-ID: <1469542582.1.0.544847948294.issue27625@psf.upfronthosting.co.za> Palm Kevin added the comment: Yes. You are right. This solves the problem for me since I don't need pip. Do you think I should close the issue or rename it into '"make install" fails with pip when missing zlib dependency' ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 10:23:41 2016 From: report at bugs.python.org (SilentGhost) Date: Tue, 26 Jul 2016 14:23:41 +0000 Subject: [issue27625] "make install" fails when no zlib support available In-Reply-To: <1469541120.27.0.508347520885.issue27625@psf.upfronthosting.co.za> Message-ID: <1469543021.07.0.776776143563.issue27625@psf.upfronthosting.co.za> SilentGhost added the comment: I wouldn't consider that an issue to be honest, the zlib is a dependency of pip and this failure is not unexpected. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 10:28:06 2016 From: report at bugs.python.org (Palm Kevin) Date: Tue, 26 Jul 2016 14:28:06 +0000 Subject: [issue27625] "make install" fails when no zlib support available In-Reply-To: <1469541120.27.0.508347520885.issue27625@psf.upfronthosting.co.za> Message-ID: <1469543286.41.0.0786765081304.issue27625@psf.upfronthosting.co.za> Palm Kevin added the comment: Ok, but shouldn't it fail earlier? During "configure" or "make", not on "make install"... Perhaps with a message like "Unable to compile with pip because dependency zlib is missing" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 10:35:32 2016 From: report at bugs.python.org (SilentGhost) Date: Tue, 26 Jul 2016 14:35:32 +0000 Subject: [issue27625] "make install" fails when no zlib support available In-Reply-To: <1469541120.27.0.508347520885.issue27625@psf.upfronthosting.co.za> Message-ID: <1469543732.27.0.374755631942.issue27625@psf.upfronthosting.co.za> SilentGhost added the comment: Well, there isn't anything to build in case of pip. I presume that was the decision made during the PEP implementation, so I'm adding the two core developers responsible. ---------- nosy: +dstufft, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 10:43:28 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 26 Jul 2016 14:43:28 +0000 Subject: [issue27625] "make install" fails when no zlib support available In-Reply-To: <1469541120.27.0.508347520885.issue27625@psf.upfronthosting.co.za> Message-ID: <1469544208.21.0.330333028059.issue27625@psf.upfronthosting.co.za> Ned Deily added the comment: Building python without zlib is support is pretty unusual today and certainly not recommended. I agree that it is not worth adding more complexity to the Python configure script or Makefile to cover this edge case dependency in pip. There are other potential ensurepip failures, for instance if ssl support is missing. ---------- nosy: +ned.deily resolution: not a bug -> wont fix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 11:01:35 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 26 Jul 2016 15:01:35 +0000 Subject: [issue27614] Race in test_docxmlrpc.py In-Reply-To: <1469459139.76.0.959920407285.issue27614@psf.upfronthosting.co.za> Message-ID: <1469545295.4.0.58918379448.issue27614@psf.upfronthosting.co.za> R. David Murray added the comment: OK, that's a good point. So I don't know the answer to your question. In some cases it may be mostly that the tests are old and written when the tooling was not as good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 11:05:33 2016 From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=) Date: Tue, 26 Jul 2016 15:05:33 +0000 Subject: [issue27626] Spelling fixes Message-ID: <1469545532.64.0.917176953717.issue27626@psf.upfronthosting.co.za> Changes by Ville Skytt? : ---------- files: spelling.patch keywords: patch nosy: scop priority: normal severity: normal status: open title: Spelling fixes type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43895/spelling.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 11:13:38 2016 From: report at bugs.python.org (SilentGhost) Date: Tue, 26 Jul 2016 15:13:38 +0000 Subject: [issue27626] Spelling fixes Message-ID: <1469546018.54.0.0230580564562.issue27626@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- assignee: -> docs at python components: +Documentation nosy: +SilentGhost, docs at python stage: -> patch review type: enhancement -> behavior versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 11:25:30 2016 From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=) Date: Tue, 26 Jul 2016 15:25:30 +0000 Subject: [issue27461] Optimize PNGs In-Reply-To: <1467894574.39.0.144098385194.issue27461@psf.upfronthosting.co.za> Message-ID: <1469546730.3.0.0342985915132.issue27461@psf.upfronthosting.co.za> Ville Skytt? added the comment: Updated patch against tip. Before: 289426 total After: 194638 total ---------- Added file: http://bugs.python.org/file43896/pngs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 11:25:56 2016 From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=) Date: Tue, 26 Jul 2016 15:25:56 +0000 Subject: [issue27461] Optimize PNGs In-Reply-To: <1467894574.39.0.144098385194.issue27461@psf.upfronthosting.co.za> Message-ID: <1469546756.35.0.0288852882365.issue27461@psf.upfronthosting.co.za> Changes by Ville Skytt? : Removed file: http://bugs.python.org/file43653/pngs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 11:27:29 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 26 Jul 2016 15:27:29 +0000 Subject: [issue27619] getopt should strip whitespace from long arguments In-Reply-To: <1469494217.58.0.75154224673.issue27619@psf.upfronthosting.co.za> Message-ID: <1469546849.42.0.690376448276.issue27619@psf.upfronthosting.co.za> R. David Murray added the comment: I agree with Serhiy. Python is a programming language, not a shell. It seems to me that it should not be second guessing a constant specified by the programmer. If the programmer puts spaces in the specification string, Python should respect that. I have no idea why one would do that, but such an option *can* be specified in the command line invocation, even using the shell. And yes, misspecifying a constant is a common source of program bugs, but I think, as Serhiy pointed out, it would be worse to have some "obvious nonsense" fixed but not others. Now, would we want to enhance getopt to validate the longopts in a more general way and raise an error? I'm not sure it is worth the effort, especially since getopt is explicitly emulating the C getopt, and it does not do so. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 11:34:43 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 26 Jul 2016 15:34:43 +0000 Subject: [issue27604] More details about `-O` flag In-Reply-To: <1469353581.38.0.811049911305.issue27604@psf.upfronthosting.co.za> Message-ID: <1469547283.03.0.658243157378.issue27604@psf.upfronthosting.co.za> R. David Murray added the comment: It might be better to reduce redundancy (ie: minimize the places that would need changing) by creating a cross link from the option description to the technical details in veryhigh.rst. You could make the existing words 'basic optimizations' the link text. Doc changes will be made to 3.5 and 3.6. I've adjusted the versions accordingly. A single patch against 3.5 will be merged into 3.6 by the committer. ---------- versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 11:44:44 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 26 Jul 2016 15:44:44 +0000 Subject: [issue27546] Integrate tkinter and asyncio (and async) In-Reply-To: <1469511676.49.0.5271682939.issue27546@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Isn't this going to busy-wait, esp. with the loop.call_soon() version? Even with loop.call_later(0.1, tk_update) you're wasting battery power even if no network activity and no UI activity is happening. I'm not eager to document this as the right way to do things, even if it unblocks some apps in the short term. A proper solution IMO should somehow merge the selectors so that a single select() or whatever wakes up when either network I/O happens or a UI event comes in (which could be something that Tk transparently handles but it still needs to be given the chance, through root.update()). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 11:46:11 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 26 Jul 2016 15:46:11 +0000 Subject: [issue27622] int.to_bytes(): docstring is not precise In-Reply-To: <1469514037.92.0.489318728995.issue27622@psf.upfronthosting.co.za> Message-ID: <1469547971.83.0.41993920005.issue27622@psf.upfronthosting.co.za> R. David Murray added the comment: Looks correct to me as well. If you can think of a wording that would be clearer, ????, that would be great, but it shouldn't make the docstring much wordier (we strive for conciseness in docstrings). That the last phrase can't be just removed without omitting an important piece of information (an *additional* time OverflowError can be raised). ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 11:47:10 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 26 Jul 2016 15:47:10 +0000 Subject: [issue27622] int.to_bytes(): docstring is not precise In-Reply-To: <1469514037.92.0.489318728995.issue27622@psf.upfronthosting.co.za> Message-ID: <1469548030.63.0.198428820493.issue27622@psf.upfronthosting.co.za> R. David Murray added the comment: Looks correct to me as well. If you can think of a wording that would be clearer, ????, that would be great, but it shouldn't make the docstring much wordier (we strive for conciseness in docstrings). That last phrase can't be just removed without omitting an important piece of information (an *additional* time OverflowError can be raised). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 11:47:18 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 26 Jul 2016 15:47:18 +0000 Subject: [issue27622] int.to_bytes(): docstring is not precise In-Reply-To: <1469514037.92.0.489318728995.issue27622@psf.upfronthosting.co.za> Message-ID: <1469548038.55.0.924585337872.issue27622@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- Removed message: http://bugs.python.org/msg271381 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 11:53:28 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 26 Jul 2016 15:53:28 +0000 Subject: [issue27612] socket.gethostbyname resolving octal IP addresses incorrectly In-Reply-To: <1469428074.1.0.701366093272.issue27612@psf.upfronthosting.co.za> Message-ID: <1469548408.52.0.391120563018.issue27612@psf.upfronthosting.co.za> R. David Murray added the comment: There's also the fact that Eryk pointed out that there are different ways to implement this on Windows, so there might be something we want to "fix" there. It seems like we're not consistent in how we handle addresses in the various socket module functions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 11:53:53 2016 From: report at bugs.python.org (Emanuel Barry) Date: Tue, 26 Jul 2016 15:53:53 +0000 Subject: [issue27626] Spelling fixes Message-ID: <1469548433.15.0.911548060088.issue27626@psf.upfronthosting.co.za> New submission from Emanuel Barry: LGTM. ---------- nosy: +ebarry stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 12:00:04 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 26 Jul 2016 16:00:04 +0000 Subject: [issue27627] clang fails to build ctypes on Android armv7 Message-ID: <1469548804.03.0.253610844682.issue27627@psf.upfronthosting.co.za> New submission from Xavier de Gaye: The build is done with: clang --sysroot=/opt/android-ndk/platforms/android-21/arch-arm -target armv7-none-linux-androideabi -gcc-toolchain /opt/android-ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64 The error message: clang --sysroot=/opt/android-ndk/platforms/android-21/arch-arm -target armv7-none-linux-androideabi -gcc-toolchain /opt/android-ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64 -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Wno-unused-value -Wno-empty-body -Qunused-arguments -Wno-parentheses-equality -Werror=declaration-after-statement -Ibuild/temp.linux-arm-3.6/libffi/include -Ibuild/temp.linux-arm-3.6/libffi -I./Modules/_ctypes/libffi/src -IInclude -I/sdcard/org.bitbucket.pyona/include -I. -I/home/xavier/src/android/pyona/build/python3.6-install-android-21-armv7/org.bitbucket.pyona/include -I/opt/android-ndk/platforms/android-21/arch-arm/usr/include -I./Include -I/home/xavier/src/android/pyona/build/python3.6-android-21-armv7 -c ./Modules/_ctypes/libffi/src/arm/sysv.S -o build/temp.linux-arm-3.6./Modules/_ctypes/libffi/src/arm/sysv.o -Wall -fexceptions ./Modules/_ctypes/libffi/src/arm/sysv.S:399:2: error: invalid instruction stmeqia r2, {r0, r1} ^ ---------- components: Cross-Build messages: 271385 nosy: Alex.Willmer, Chi Hsuan Yen, xdegaye priority: normal severity: normal stage: needs patch status: open title: clang fails to build ctypes on Android armv7 type: compile error versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 12:01:21 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 26 Jul 2016 16:01:21 +0000 Subject: [issue27624] unclear documentation on Queue.qsize() In-Reply-To: <1469538053.41.0.353171937214.issue27624@psf.upfronthosting.co.za> Message-ID: <1469548881.52.0.551640266022.issue27624@psf.upfronthosting.co.za> R. David Murray added the comment: Since we're talking about multi-threaded operations, the concept of "exact size at an arbitrary time" isn't operationally different from "a strategy used for approximating". The subsequent text clarifies what "approximately" means operationally. Specifying it further would be, I think, overspecification. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 12:01:22 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 26 Jul 2016 16:01:22 +0000 Subject: [issue27627] clang fails to build ctypes on Android armv7 In-Reply-To: <1469548804.03.0.253610844682.issue27627@psf.upfronthosting.co.za> Message-ID: <1469548882.74.0.903241955894.issue27627@psf.upfronthosting.co.za> Xavier de Gaye added the comment: See also msg 269907 and msg269908. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 12:03:02 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 26 Jul 2016 16:03:02 +0000 Subject: [issue23085] update internal libffi copy to 3.2.1 In-Reply-To: <1418922803.63.0.55729998299.issue23085@psf.upfronthosting.co.za> Message-ID: <1469548982.43.0.72547088085.issue23085@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > Cross-compile CPython for ARM with clang fails in _ctypes due to https://llvm.org/bugs/show_bug.cgi?id=20595. This bug is already fixed in libffi. I have entered issue 27627 for this problem. ---------- nosy: +xdegaye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 12:05:17 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 26 Jul 2016 16:05:17 +0000 Subject: [issue26865] Meta-issue: support of the android platform In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za> Message-ID: <1469549117.86.0.580400909174.issue26865@psf.upfronthosting.co.za> Xavier de Gaye added the comment: issue #27627: clang fails to build ctypes on Android armv7 ---------- dependencies: +clang fails to build ctypes on Android armv7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 12:06:22 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 26 Jul 2016 16:06:22 +0000 Subject: [issue27612] socket.gethostbyname resolving octal IP addresses incorrectly In-Reply-To: <1469428074.1.0.701366093272.issue27612@psf.upfronthosting.co.za> Message-ID: <1469549182.52.0.215781922854.issue27612@psf.upfronthosting.co.za> R. David Murray added the comment: koobs' results are also interesting, since they indicate that *something* changed on the python side that affected this for freebsd. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 12:09:11 2016 From: report at bugs.python.org (Emanuel Barry) Date: Tue, 26 Jul 2016 16:09:11 +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: <1469549351.67.0.25045642694.issue26226@psf.upfronthosting.co.za> Emanuel Barry added the comment: Since non-ASCII characters are not really supported in hostnames, I changed mine to a saner alternative. This issue can be closed then, since any test failure I encounter can no longer be because of this. One last thing: is it safe to say "Don't use non-ASCII in hostnames" and not bother supporting such edge cases? Whichever way we end up going, I think this should be documented somewhere (although I don't really have an idea of where). I can submit a doc patch for this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 12:17:12 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 26 Jul 2016 16:17:12 +0000 Subject: [issue26942] android: test_ctypes crashes on armv7 In-Reply-To: <1462290789.53.0.483745295219.issue26942@psf.upfronthosting.co.za> Message-ID: <1469549832.01.0.872800831018.issue26942@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Nice, the patch fixes the problem when python is built with gcc :) Running test_ctypes on the Android emulator when python is built for the arm architecture or the armv7 architecture gives in both cases the same successfull result: Ran 456 tests in 30.424s OK (skipped=92) test.test_ctypes passed in 41 sec 1 test OK. Total duration: 0:00:43 I did not try with clang, stopped by the problem in issue 27627 for armv7 and in issue 27606 for arm. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 12:23:25 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 26 Jul 2016 16:23:25 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <20160726162318.10833.27545.C9BE94BE@psf.io> Roundup Robot added the comment: New changeset 95df96aa2f5a by Alexander Belopolsky in branch 'default': Issue #24773: Fixed tests failures on systems with 32-bit time_t. https://hg.python.org/cpython/rev/95df96aa2f5a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 12:59:41 2016 From: report at bugs.python.org (Tomas Gavenciak) Date: Tue, 26 Jul 2016 16:59:41 +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: <1469552381.35.0.726550907442.issue3119@psf.upfronthosting.co.za> Tomas Gavenciak added the comment: The issue is still present in Python 2.7.12 and Python 3.5.2, and the implementation has not been changed in the master branch either. You can test it with the attached program constructing a graph (simplified, but a realistic application), or with the following obviously deep construction: import pickle, _pickle a=() for i in range(1000): a = (a,) pickle.dumps(a) # or _pickle.dumps(a) Any further comments or thoughts on the solution? ---------- versions: +Python 3.6 -Python 3.1 Added file: http://bugs.python.org/file43897/graphtest.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 13:04:49 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Jul 2016 17:04:49 +0000 Subject: [issue27626] Spelling fixes In-Reply-To: <1469548433.15.0.911548060088.issue27626@psf.upfronthosting.co.za> Message-ID: <1469552689.18.0.0804464002382.issue27626@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +martin.panter, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 13:06:27 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Tue, 26 Jul 2016 17:06:27 +0000 Subject: [issue27619] getopt should strip whitespace from long arguments In-Reply-To: <1469546849.42.0.690376448276.issue27619@psf.upfronthosting.co.za> Message-ID: <20160726170614.GV27919@ando.pearwood.info> Steven D'Aprano added the comment: On Tue, Jul 26, 2016 at 03:27:29PM +0000, R. David Murray wrote: [...] > getopt is explicitly emulating the C getopt There are lots of differences between the C getopt and the Python version, and the Python version is described as offering an API "designed to be familiar" to uses of the C version, not to emulate all the idiosyncrasies of the C version. For instance, the Python version raises an exception on errors, rather than returning -1; the C version requires argc ("argument count"), but the Python version doesn't. But most critically, the C version DOES strip whitespace from long arguments. On my Centos box, it only strips *trailing* spaces, not leading spaces, but it does strip them. So if your argument is that we must do what the C getopt does, then we must likewise at least strip trailing spaces. Attached is a demo, adapted from the code given by `man 3 getopt`. [steve at ando ~]$ gcc getopdemo.c [steve at ando ~]$ ./a.out "-- spam" 1 --eggs 2 "-- cheese" 3 option spam with arg 1 option eggs with arg 2 option cheese with arg 3 If Serhiy is going to insist that getopt.py must follow the C getopt precisely, then the failure to strip trailing spaces is certainly a bug. ---------- Added file: http://bugs.python.org/file43898/getopdemo.c _______________________________________ Python tracker _______________________________________ -------------- next part -------------- #include /* for printf */ #include /* for exit */ #include int main (int argc, char **argv) { int c; int digit_optind = 0; while (1) { int this_option_optind = optind ? optind : 1; int option_index = 0; static struct option long_options[] = { {" spam ", 1, 0, 0}, {"eggs ", 1, 0, 0}, {" cheese", 1, 0, 0}, {0, 0, 0, 0} }; c = getopt_long (argc, argv, "", long_options, &option_index); if (c == -1) break; switch (c) { case 0: printf ("option %s", long_options[option_index].name); if (optarg) printf (" with arg %s", optarg); printf ("\n"); break; case '?': break; default: printf ("?? getopt returned character code 0%o ??\n", c); } } exit (0); } From report at bugs.python.org Tue Jul 26 13:13:45 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 26 Jul 2016 17:13:45 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <1469553225.69.0.570756708179.issue24773@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: It looks like PPC64 Fedora 3.x builder [1] also has a problem with a transition in 2037. [1]: http://buildbot.python.org/all/builders/PPC64%20Fedora%203.x ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 13:21:15 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 26 Jul 2016 17:21:15 +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: <1469553675.75.0.94582383299.issue26226@psf.upfronthosting.co.za> STINNER Victor added the comment: Please keep it ok. I don't say that we are going to fix all issues, but it's good to have an issue which collects as much as possible information about the bug and how we can fix it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 13:21:24 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 26 Jul 2016 17:21:24 +0000 Subject: [issue27546] Integrate tkinter and asyncio (and async) In-Reply-To: <1468815010.57.0.709565417017.issue27546@psf.upfronthosting.co.za> Message-ID: <1469553684.43.0.68625221879.issue27546@psf.upfronthosting.co.za> Terry J. Reedy added the comment: This afternoon, I realized that I would replace the async for loops with while loops with await sleep and eliminate the Timer class. I presume the tutorial will have other examples of how to write an async iterator. (If not, I would put is back in.) I also notices that the updater could also be turned into a coroutine, but decided to leave it as it is. ---------- Added file: http://bugs.python.org/file43899/loop_tk3.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 13:34:35 2016 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Tue, 26 Jul 2016 17:34:35 +0000 Subject: [issue27628] ipaddress incompatibility with ipaddr: __contains__ between networks Message-ID: <1469554475.46.0.86096360489.issue27628@psf.upfronthosting.co.za> New submission from ?ukasz Langa: ipaddr historically let users compare if one network is within another network: https://github.com/google/ipaddr-py/blob/master/ipaddr.py#L643 ipaddress specifically prohibits this comparison: https://hg.python.org/cpython/file/tip/Lib/ipaddress.py#l675 What is the reason behind this change? I propose we restore this functionality for 3.6. It's a behavior change but arguably backwards compatible in the sense that between 3.3 and 3.5 this __contains__ comparison always returns False. It's also more on par with what ipaddr did in the past. Thoughts? ---------- assignee: pmoody components: Library (Lib) messages: 271399 nosy: berker.peksag, lukasz.langa, ncoghlan, pmoody priority: normal severity: normal stage: needs patch status: open title: ipaddress incompatibility with ipaddr: __contains__ between networks type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 13:42:56 2016 From: report at bugs.python.org (pmoody) Date: Tue, 26 Jul 2016 17:42:56 +0000 Subject: [issue27628] ipaddress incompatibility with ipaddr: __contains__ between networks In-Reply-To: <1469554475.46.0.86096360489.issue27628@psf.upfronthosting.co.za> Message-ID: <1469554976.34.0.599179993948.issue27628@psf.upfronthosting.co.za> Changes by pmoody : ---------- assignee: pmoody -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 13:49:05 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Jul 2016 17:49:05 +0000 Subject: [issue27619] getopt should strip whitespace from long arguments In-Reply-To: <1469494217.58.0.75154224673.issue27619@psf.upfronthosting.co.za> Message-ID: <1469555345.29.0.627091369485.issue27619@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: C getopt doesn't strip trailing spaces. What you mistook for stripping trailing spaces is actually a feature of GNU getopt that allows you to use shortened variant of long option. $ ./getopdemo "-- sp" 1 --eg 2 "-- ch" 3 option spam with arg 1 option eggs with arg 2 option cheese with arg 3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 13:55:39 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Jul 2016 17:55:39 +0000 Subject: [issue27628] ipaddress incompatibility with ipaddr: __contains__ between networks In-Reply-To: <1469554475.46.0.86096360489.issue27628@psf.upfronthosting.co.za> Message-ID: <1469555739.78.0.994189695659.issue27628@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This issue looks as a duplicate of issue20825. I think that if consider a network as a set of addresses, the operation "address in network" has the same meaning as for sets, but the operation "network in network" doesn't make a sense. Instead you should use the same operation as for testing a subset of a set: "network <= network". But this operation is ambiguous, because "<=" usually is ordering operation. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 14:34:57 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Tue, 26 Jul 2016 18:34:57 +0000 Subject: [issue27622] int.to_bytes(): docstring is not precise In-Reply-To: <1469514037.92.0.489318728995.issue27622@psf.upfronthosting.co.za> Message-ID: <1469558097.0.0.21382960326.issue27622@psf.upfronthosting.co.za> ???? ????????? added the comment: Ok. This is minor fix, I will not fight for my point of view :) ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 14:38:41 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 26 Jul 2016 18:38:41 +0000 Subject: [issue27619] getopt should strip whitespace from long arguments In-Reply-To: <1469494217.58.0.75154224673.issue27619@psf.upfronthosting.co.za> Message-ID: <1469558321.82.0.161704722649.issue27619@psf.upfronthosting.co.za> R. David Murray added the comment: I realized some time after I posted that my comment about it emulating C getopt needed a gloss. What I meant was that C getopt is the model, so there should be a sufficient argument that adding a feature is worthwhile. You are making that argument, but Serhiy and I disagree that it is worthwhile, or consistent with the fact that Python is a programming language and not a shell. We may be in the minority, though, for all we know. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 14:51:45 2016 From: report at bugs.python.org (Doug Hoskisson) Date: Tue, 26 Jul 2016 18:51:45 +0000 Subject: [issue27624] unclear documentation on Queue.qsize() In-Reply-To: <1469538053.41.0.353171937214.issue27624@psf.upfronthosting.co.za> Message-ID: <1469559105.07.0.713899185912.issue27624@psf.upfronthosting.co.za> Doug Hoskisson added the comment: Some strategies for approximating might report a size the the queue has never been and never will be. For example, a strategy could gather data and find the size is increasing at some rate, and approximate based on that rate, but then the rate of increase changes before it reaches the approximated size. That's the kind of thing that "approximate" would suggest to some people. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 14:57:33 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 26 Jul 2016 18:57:33 +0000 Subject: [issue27624] unclear documentation on Queue.qsize() In-Reply-To: <1469538053.41.0.353171937214.issue27624@psf.upfronthosting.co.za> Message-ID: <1469559453.87.0.924370271243.issue27624@psf.upfronthosting.co.za> R. David Murray added the comment: What if we just replaced the period with a colon? That is, the definition of "approximate" is the two rules in the second sentence. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 15:00:29 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 26 Jul 2016 19:00:29 +0000 Subject: [issue25431] implement address in network in ipaddress module In-Reply-To: <1445089092.67.0.311861464579.issue25431@psf.upfronthosting.co.za> Message-ID: <1469559629.7.0.104859437551.issue25431@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report and for the patch, Aleksandr. This is a duplicate of issue 20825. See also issue 27628 for a similar report. ---------- dependencies: -speed up ipaddress __contain__ method nosy: +berker.peksag resolution: -> duplicate stage: patch review -> resolved status: open -> closed superseder: -> containment test for "ip_network in ip_network" _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 15:00:54 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 26 Jul 2016 19:00:54 +0000 Subject: [issue27628] ipaddress incompatibility with ipaddr: __contains__ between networks In-Reply-To: <1469554475.46.0.86096360489.issue27628@psf.upfronthosting.co.za> Message-ID: <1469559654.29.0.395824523595.issue27628@psf.upfronthosting.co.za> Berker Peksag added the comment: See also issue 25431. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 15:13:21 2016 From: report at bugs.python.org (Doug Hoskisson) Date: Tue, 26 Jul 2016 19:13:21 +0000 Subject: [issue27624] unclear documentation on Queue.qsize() In-Reply-To: <1469538053.41.0.353171937214.issue27624@psf.upfronthosting.co.za> Message-ID: <1469560401.36.0.355252323399.issue27624@psf.upfronthosting.co.za> Doug Hoskisson added the comment: The way that this whole page of documentation is written does not suggest that this class is ONLY for use in a multi-threaded setting. This class can be used without multi-threading, right? Wouldn't it be useful to know whether this function does give the exact size of the queue in a single-threaded setting? Right now, it doesn't contain that information. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 15:20:13 2016 From: report at bugs.python.org (Michael Smith) Date: Tue, 26 Jul 2016 19:20:13 +0000 Subject: [issue27617] Compiled bdist_wininst missing from embedded distribution In-Reply-To: <1469474880.88.0.362049415558.issue27617@psf.upfronthosting.co.za> Message-ID: <1469560813.71.0.461287856853.issue27617@psf.upfronthosting.co.za> Michael Smith added the comment: Thanks so much Steve I got it working right away! I peeked into the bdist_wininst.py and saw that it also depended on some local exe files. Copied both of those to the embedded and everything worked like a charm. I did read the documentation previously so I thought the only real dependency was the C Runtime. Working on a network without any net access I have to bring in libraries we version, so basically what you describe "vendoring". If you have time to answer I would like to understand why this particular item is not part of the embedded. Or why is it in the regular install by default? When I look at the distutils documentation there is very little information about this file. Is this particular item a 3rd party not core python or? In any case thanks for the help again. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 15:31:02 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Tue, 26 Jul 2016 19:31:02 +0000 Subject: [issue27346] Implement os.readv() / os.writev() in Windows port In-Reply-To: <1466242793.09.0.103237179238.issue27346@psf.upfronthosting.co.za> Message-ID: <1469561462.08.0.915656018116.issue27346@psf.upfronthosting.co.za> Changes by ???? ????????? : ---------- title: Implement os.readv() / os.writev() -> Implement os.readv() / os.writev() in Windows port _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 16:44:53 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 26 Jul 2016 20:44:53 +0000 Subject: [issue27617] Compiled bdist_wininst missing from embedded distribution In-Reply-To: <1469474880.88.0.362049415558.issue27617@psf.upfronthosting.co.za> Message-ID: <1469565893.1.0.246094033137.issue27617@psf.upfronthosting.co.za> Steve Dower added the comment: It's core Python, but it's specifically intended for producing redistributable installers containing Python packages. This is not something that the embedded distro is meant for, and it neatens things up to omit them. There is very little information because it's considered an internal implementation detail (otherwise it would be thoroughly documented). That said, because of the narrower use case for the embedded distro, omitting even thoroughly documented modules would be okay if it didn't make sense in this context (e.g. the turtledemo module is documented, but also not in the embedded distro). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 16:50:35 2016 From: report at bugs.python.org (RalfM) Date: Tue, 26 Jul 2016 20:50:35 +0000 Subject: [issue24214] Exception with utf-8, surrogatepass and incremental decoding In-Reply-To: <1431816994.33.0.797161516902.issue24214@psf.upfronthosting.co.za> Message-ID: <1469566235.18.0.77127004041.issue24214@psf.upfronthosting.co.za> RalfM added the comment: I just tested Python 3.6.0a3, and that (mis)behaves exactly like 3.4.3. ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 17:15:02 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 26 Jul 2016 21:15:02 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <1469567702.19.0.552110057097.issue24773@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: It looks like th Morocco issue has been reported to CentOS recently but they kicked it upstream. https://sourceware.org/ml/libc-help/2016-04/msg00000.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 17:21:41 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 26 Jul 2016 21:21:41 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <1469568101.4.0.934685964565.issue24773@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Also reported for Ubuntu: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1587128 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 17:29:11 2016 From: report at bugs.python.org (Doug Hoskisson) Date: Tue, 26 Jul 2016 21:29:11 +0000 Subject: [issue27624] unclear documentation on Queue.qsize() In-Reply-To: <1469538053.41.0.353171937214.issue27624@psf.upfronthosting.co.za> Message-ID: <1469568551.04.0.150552325924.issue27624@psf.upfronthosting.co.za> Doug Hoskisson added the comment: One thing that is important to recognize in considering this, is which information is specific to what is being documented, and which information is more general. Some people may think that documentation should only give information specific to what is being documented. Others may think it is useful to also include general information that can help people learn. I don't know whether the writers of Python documentation lean to one of these or the other, but this contains a significant amount of information that has nothing to do with Python specifically, nothing to do with this class specifically, and nothing to do with this function specifically. (Again, I'm not saying this is bad. I just think it's important for people to recognize it.) It's just general multi-threading knowledge. Anyone who knows about multi-threading (in any language) knows that the queue could change between two function calls. But despite that extra general information, there is some specific information missing. Does it return the size of the queue (at the time the memory is accessed by the function call)? or does it use a more complex strategy for approximating the size of the queue? The reason this information is important is that if it is the former, that would be useful in single-threaded situations. I am guessing that it is the former, but I don't know because not enough information is given. Assuming that guess, I think following the model I see in the documentation of the next 2 functions on the page (Queue.empty() and Queue.full()) would be a good idea. That is, that the first sentence should only contain information specific to what is being documented, and more general information (about multi-threading) can be given afterward. The fact that the size returned is approximate would have nothing to do with this function specifically, and it is just general information about how multi-threading works. My suggestion for this documentation (again, assuming that my guess of the missing information is correct) I will put in a separate comment because this comment will be TLDR for many. If my guess is incorrect, then something should be clarified to lessen people guessing thus. (Maybe this is just projecting, but I think most people would make the same guess that I am making.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 17:30:03 2016 From: report at bugs.python.org (Doug Hoskisson) Date: Tue, 26 Jul 2016 21:30:03 +0000 Subject: [issue27624] unclear documentation on Queue.qsize() In-Reply-To: <1469538053.41.0.353171937214.issue27624@psf.upfronthosting.co.za> Message-ID: <1469568603.73.0.304330110175.issue27624@psf.upfronthosting.co.za> Doug Hoskisson added the comment: My suggestion for this documentation: """ Return the number of items in the queue. Note, in multi-threading this mostly just serves as an approximation, and information from this doesn?t guarantee that a subsequent get() or put() will not block. """ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 18:05:54 2016 From: report at bugs.python.org (Michael Felt) Date: Tue, 26 Jul 2016 22:05:54 +0000 Subject: [issue25825] AIX shared library extension modules installation broken In-Reply-To: <1449602974.51.0.754649695687.issue25825@psf.upfronthosting.co.za> Message-ID: <1469570754.81.0.145534745516.issue25825@psf.upfronthosting.co.za> Michael Felt added the comment: hmm. needs patch. For what? One comment says a change will be undone. If a patch is expected for src/builddir issue: a) I sinned - that is a new issue, and should be posted seperately. b) i do not know autotools well enough to solve the srcdir and builddir problem. rather than a patch i can on that is see if the same issue occurs with linux and post a new issue. So, my question would be - was a rollback done - if yes, perhaps a comment to verify and then close this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 18:46:09 2016 From: report at bugs.python.org (Michael Felt) Date: Tue, 26 Jul 2016 22:46:09 +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: <1469573169.63.0.805733940238.issue16353@psf.upfronthosting.co.za> Michael Felt added the comment: An interesting read, but I am lost in what the goal is. e.g., on AIX, which I know well, the system default is /bin/ksh (aka /usr/bin/ksh). However, /bin/sh (/usr/bin/sh) is available as well. My expectation is that on Linux the default shell is /bin/bash, and like AIX /bin/sh is also available. /bin/sh, /bin/ksh, /bin/bash are all (potentially) default shells. However, something every posix system is "sh" aka borne shell. Aside: windows is different, and I expect has a different syntax. So, if the goal is to GET the pathname of the so-called "default" shell -again, interesting - BUT - what does that buy me? For Popen or now subprocess I would want a consistent shell syntax, i.e., borne shell on posix, cmd.exe on windows, and whatever is correct on platforms that do not fit in these two. Hence, on posix platforms where /bin/sh does not exist (hard)code the correct path for that platform. FYI: CS_PATH does not exist on AIX IMHO: (as others have stated) having . in PATH is bad for security, being dependent on PATH opens other security concerns as well. IMHO2: KISS principle. After several years there is still no consenus, so make it simple - the popen and subprocess shell is one of /bin/sh, cmd.exe, or some other "hard-coded" shell. (Although I thought that subprocess called "program" directly. Python is still new, so if not applicable for subprocess - please ignore rereading, direct call would be when shell=False I expect. Anyway, my two cents. ---------- nosy: +Michael.Felt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 19:21:45 2016 From: report at bugs.python.org (nemunaire) Date: Tue, 26 Jul 2016 23:21:45 +0000 Subject: [issue27629] Cannot create raw ssl.SSLSocket Message-ID: <1469575305.76.0.392837082138.issue27629@psf.upfronthosting.co.za> New submission from nemunaire: I got this stacktrace: File "test_ssl.py", line 3, in sock = ssl.SSLSocket(server_hostname="docs.python.org") File "/usr/lib/python3.4/ssl.py", line 536, in __init__ if sock.getsockopt(SOL_SOCKET, SO_TYPE) != SOCK_STREAM: AttributeError: 'NoneType' object has no attribute 'getsockopt' with this minimal code: import ssl sock = ssl.SSLSocket(server_hostname="docs.python.org") sock.connect(("docs.python.org", 443)) sock.sendall(b"GET /3/library/ssl.html HTTP/1.0\r\nHost: docs.python.org\r\n\r\n") print(sock.recv(4096).decode()) Whereas the None socket is correctly handled a few lines later: https://hg.python.org/cpython/file/tip/Lib/ssl.py#l715 All Python >= 3.3 are affected (since https://hg.python.org/cpython/rev/a00842b783cf) and can be patched with the same file, attached to this issue. ---------- components: Library (Lib) files: fix_sslsocket_init_without_socket_3.3-3_6.patch keywords: patch messages: 271419 nosy: nemunaire priority: normal severity: normal status: open title: Cannot create raw ssl.SSLSocket type: behavior versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43900/fix_sslsocket_init_without_socket_3.3-3_6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 19:33:56 2016 From: report at bugs.python.org (nemunaire) Date: Tue, 26 Jul 2016 23:33:56 +0000 Subject: [issue27629] Cannot create ssl.SSLSocket without existing socket In-Reply-To: <1469575305.76.0.392837082138.issue27629@psf.upfronthosting.co.za> Message-ID: <1469576036.76.0.601816619815.issue27629@psf.upfronthosting.co.za> Changes by nemunaire : ---------- title: Cannot create raw ssl.SSLSocket -> Cannot create ssl.SSLSocket without existing socket _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 19:48:06 2016 From: report at bugs.python.org (Emanuel Barry) Date: Tue, 26 Jul 2016 23:48:06 +0000 Subject: [issue27629] Cannot create ssl.SSLSocket without existing socket In-Reply-To: <1469575305.76.0.392837082138.issue27629@psf.upfronthosting.co.za> Message-ID: <1469576886.84.0.773493400818.issue27629@psf.upfronthosting.co.za> Emanuel Barry added the comment: Thank you for the report and the patch! :) This will need a test in Lib/test/test_ssl.py to check for this particular case. I've removed 3.3 and 3.4 from the Versions field, since these versions no longer get regular bugfixes (only security bugfixes may go in these). As a result, only 3.5 and 3.6 will get the fix. ---------- nosy: +alex, christian.heimes, dstufft, ebarry, giampaolo.rodola, janssen, pitrou stage: -> patch review versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 20:36:25 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 27 Jul 2016 00:36:25 +0000 Subject: [issue27546] Integrate tkinter and asyncio (and async) In-Reply-To: <1468815010.57.0.709565417017.issue27546@psf.upfronthosting.co.za> Message-ID: <1469579785.96.0.0405833241709.issue27546@psf.upfronthosting.co.za> Terry J. Reedy added the comment: > wasting battery power ?! We live in slightly different computing universes ;-). But I get the point. The last two files I uploaded use call_later and I should stick with that. I should also add a note that the innermost asyncio loop function sleeps when there is nothing to do and that the tk updater wakes it up, if necessary, to check for gui events even when there are none. Updater is polling rather than interrupt based. Or in other words, it interrupts asyncio to poll tk. I should also say that the update interval is passed in to the class so one can make an instance-specific tradeoff between overhead and responsiveness and display update frequency. A read-only display might be updated just once a minute. If loop.call_later(0.1, tk_update) is actually a problem on a system, then IDLE would likely be twice as bad, as it also has a busy loop in the user process, polling both the socket connection and calling tk update 20 times a second. There are also loops in the IDLE process. I agree on the ideal solution and on the key component, which is to sleep until there is a ready Task or file event. _run_once does this in the select call by adjusting the timeout to the minimum time to the next ready task (possibly 0). Tcl has such a component, with the addition of simultaneously waiting for window events -- but it only only includes file events on unix. (It took a brave and talented group to try to reconcile the Unix and Windows models.) Here is a simplified Python version of Tcl_DoOneEvent. http://www.tcl.tk/man/tcl8.6/TclLib/DoOneEvent.htm Tcl has window, file, timer, and idle events. Window events include user key and mouse events and other from the graphics system. The first three types all go in one ready queue. Idle events are those that affect what the user sees on the screen and go in a separate, lower-priority queue. def do_one_event(sleep_ok): if ready: process(ready.pop()) return True load_ready() if ready: process(ready.pop()) return True if idle: for event in idle: process(event) return True if sleep_ok: sleep_until_event() # the hard part load_ready() process(ready.pop()) return True else: return False def load_ready(): # In some unspecified order ready.extend(get_window_events) # graphics system ready.extend(get_file_events) # select ready.extend(get_timer_events) # priority queue pops Update processes all events available without sleeping. http://www.tcl.tk/man/tcl8.6/TclCmd/update.htm Mainloop continues (with sleeps) while there are toplevels and not stopped. def update(): while(do_one_event(sleep_ok=False)): pass def mainloop(): while toplevels and not stop: do_one_event() Sleep_ok is actually a dont_sleep bit flag. DoOneEvent has other flags to select which types of event to process. Hence def update_idletasks() # all currently ready do_one_event(dont_sleep | idletasks) It is possible for the idle queue to get starved for attention. Hence the existence of update_idletasks and recommendations to call it in certain situations. It would also be possible to call (from Python, via tcl) do_one_event(dont_sleep | gui_events) IF it were known that a gui event was ready to be retrieved. It is knowing that, without polling in a 'busy loop' that is hard to impossible. If it were possible, an extra call to do idletasks would also be needed.. In summary, I see this as a situation where practicality beats a possibly unattainable purity. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 20:50:40 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 27 Jul 2016 00:50:40 +0000 Subject: [issue27546] Integrate tkinter and asyncio (and async) In-Reply-To: <1468815010.57.0.709565417017.issue27546@psf.upfronthosting.co.za> Message-ID: <1469580640.38.0.71762557487.issue27546@psf.upfronthosting.co.za> Yury Selivanov added the comment: > A proper solution IMO should somehow merge the selectors so that a > single select() or whatever wakes up when either network I/O happens > or a UI event comes in (which could be something that Tk transparently > handles but it still needs to be given the chance, through > root.update()). I think we can do something similar to self-pipe trick: have a pipe and a reader for it registered with 'loop.add_reader'. Whenever a UI thread have an event to process, it should write a byte to the pipe. I'm not sure if there's a way to do that with Tk. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 20:58:35 2016 From: report at bugs.python.org (koobs) Date: Wed, 27 Jul 2016 00:58:35 +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: <1469581115.27.0.571556462778.issue19613@psf.upfronthosting.co.za> koobs added the comment: This just failed on 3.x (default) on koobs-freebsd{9,10} bots: ====================================================================== FAIL: test_article_head_body (test.test_nntplib.NetworkedNNTP_SSLTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_nntplib.py", line 240, in wrapped meth(self) File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_nntplib.py", line 185, in test_article_head_body self.check_article_resp(resp, body, art_num) File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_nntplib.py", line 165, in check_article_resp self.assertNotIn(article.lines[-1], (b".", b".\n", b".\r\n")) AssertionError: b'.' unexpectedly found in (b'.', b'.\n', b'.\r\n') ---------------------------------------------------------------------- Full log attached ---------- keywords: +buildbot nosy: +koobs Added file: http://bugs.python.org/file43901/koobs-freebsd-10-python-3x-build-4682.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 21:01:09 2016 From: report at bugs.python.org (koobs) Date: Wed, 27 Jul 2016 01:01:09 +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: <1469581269.79.0.605000107957.issue19613@psf.upfronthosting.co.za> Changes by koobs : ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 21:07:13 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 27 Jul 2016 01:07:13 +0000 Subject: [issue27630] Generator._encoded_EMTPY misspelling in email package Message-ID: <1469581633.21.0.276257861067.issue27630@psf.upfronthosting.co.za> New submission from Martin Panter: In the Generator.flatten() (Lib/email/generator.py), the code sets, among others, the instance attributes _EMPTY (correct spelling) and _encoded_EMTPY (misspelling). Further down in that class, _encoded_EMPTY (correct spelling) is set as a class attribute, and this correctly-spelt version appears to be used in the _handle_message_delivery_status() method. The BytesGenerator class inherits Generator and overrides the correctly-spelt _encoded_EMPTY class attribute. It seems that both _EMPTY and the misspelt _encoded_EMTPY instance attributes are not used. Perhaps they should be removed. Or perhaps they are not doing the job they were intended for and there is a real bug. ---------- components: email messages: 271424 nosy: barry, martin.panter, r.david.murray priority: normal severity: normal status: open title: Generator._encoded_EMTPY misspelling in email package versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 21:14:08 2016 From: report at bugs.python.org (koobs) Date: Wed, 27 Jul 2016 01:14:08 +0000 Subject: [issue23085] update internal libffi copy to 3.2.1 In-Reply-To: <1418922803.63.0.55729998299.issue23085@psf.upfronthosting.co.za> Message-ID: <1469582048.01.0.994760529249.issue23085@psf.upfronthosting.co.za> koobs added the comment: Forgive me for asking a question that may have already been asked, or beaten to death, but what is preventing Python from requiring libffi as an external/required dependency, rather than keeping it and taking on the burden of fixes/backporting in lieu of updates or pending releases from upstream? Historically (at least the last ~2-3 years), libffi in Python has been plagued with, at least: * Inconsistent / incorrect merging of libffi fixes (including regressions) * Unsolved issues in vendored copy that have been fixed/released upstream * Complex, manual and error-prone updates to vendored copy * Lack of regular maintenance, from what largely appears to be a lack of knowledge about, or confidence in updating the vendored copy (fear of breakage) I know at least FreeBSD currently requires --sytem-libffi for i386 systems in certain versions due to issue 22521 (issue 23042) and there are currently 50 open issues matching libffi (granted not all of them will be root-caused by libffi internal). I note that number to highlight the maintenance requirement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 21:31:23 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 27 Jul 2016 01:31:23 +0000 Subject: [issue11048] "import ctypes" causes segfault on read-only filesystem In-Reply-To: <1296234309.62.0.290829997988.issue11048@psf.upfronthosting.co.za> Message-ID: <1469583083.64.0.600238809343.issue11048@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag versions: +Python 3.5, Python 3.6 -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 22:43:20 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 27 Jul 2016 02:43:20 +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: <1469587400.69.0.309253113785.issue19613@psf.upfronthosting.co.za> Martin Panter added the comment: A few other buildbots shared this failure. It would be nice to see what the article is that is causing the failure, but I?m fairly confident we should just remove this part of the test. ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 23:08:07 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 27 Jul 2016 03:08:07 +0000 Subject: [issue27576] An unexpected difference between dict and OrderedDict In-Reply-To: <1468962090.7.0.636707577928.issue27576@psf.upfronthosting.co.za> Message-ID: <1469588887.76.0.0429939373551.issue27576@psf.upfronthosting.co.za> Xiang Zhang added the comment: I write a new version restoring the fast path for dict. It now uses PyDict_Next and seems to be much faster than the path using keys. [cpython]$ ./python -m timeit -s 'from collections import OrderedDict; d = {"a":1,"c":2,"b":3,"d":4}' 'OrderedDict(d)' 1000000 loops, best of 3: 0.639 usec per loop [cpython]$ ./python -m timeit -s 'from collections import OrderedDict; d = {"a":1,"c":2,"b":3,"d":4}' 'OrderedDict(d)' 1000000 loops, best of 3: 0.372 usec per loop ---------- Added file: http://bugs.python.org/file43902/odict_update_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 23:17:04 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 27 Jul 2016 03:17:04 +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: <1469589424.81.0.949068552049.issue19613@psf.upfronthosting.co.za> Martin Panter added the comment: I played with the server and group that is apparently used in the test: >>> server = NNTP_SSL("nntp.aioe.org") >>> [_, _, first, last, _] = server.group("fr.comp.lang.python") >>> first 2900 >>> last 2915 >>> server.body(last)[1].lines[-1] b'' >>> server.body(first)[1].lines[-1] b'Merci' >>> server.body(last - 1)[1].lines[-1] b'Kevin' I tried all articles from 2900?2915, and none of them end with a dot on its own line, so I don?t actually know what caused the failure. However looking again at the _getlongresp() implementation, I cannot imagine how the test failure can occur except for a genuine body that ends with a dot on its own line (encoded as b".." and then converted to b"."). Here is a quick patch to alter the test cases. ---------- keywords: +patch stage: needs patch -> patch review versions: -Python 3.4 Added file: http://bugs.python.org/file43903/ending-dot.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 23:32:13 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 27 Jul 2016 03:32:13 +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: <1469590333.23.0.104356873261.issue19613@psf.upfronthosting.co.za> Martin Panter added the comment: This version actually works :P ---------- Added file: http://bugs.python.org/file43904/ending-dot.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 23:34:14 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 27 Jul 2016 03:34:14 +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: <1469590454.51.0.0818941807683.issue19613@psf.upfronthosting.co.za> Changes by Martin Panter : Removed file: http://bugs.python.org/file43904/ending-dot.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 23:35:15 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 27 Jul 2016 03:35:15 +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: <1469590515.03.0.651064626634.issue19613@psf.upfronthosting.co.za> Changes by Martin Panter : Added file: http://bugs.python.org/file43905/ending-dot.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 23:41:53 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 27 Jul 2016 03:41:53 +0000 Subject: [issue27626] Spelling fixes In-Reply-To: <1469548433.15.0.911548060088.issue27626@psf.upfronthosting.co.za> Message-ID: <1469590913.87.0.078305978556.issue27626@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch that fixes some more related misspellings. This includes some test method names, and one internal C function variable. FWIW nonexistant vs nonexistent may be a bit controversial (and neither look particularly wrong to me), so I didn?t change any other occurrences, but the existing change looks okay to be consistent with the ?self._nonexistent_dir? spelling. ---------- Added file: http://bugs.python.org/file43906/spelling.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 00:12:36 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 27 Jul 2016 04:12:36 +0000 Subject: [issue27626] Spelling fixes In-Reply-To: <1469548433.15.0.911548060088.issue27626@psf.upfronthosting.co.za> Message-ID: <1469592756.73.0.230341114638.issue27626@psf.upfronthosting.co.za> Xiang Zhang added the comment: LGTM. ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 00:18:24 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 27 Jul 2016 04:18:24 +0000 Subject: [issue17599] mingw: detect REPARSE_DATA_BUFFER In-Reply-To: <1364759977.57.0.233975454494.issue17599@psf.upfronthosting.co.za> Message-ID: <1469593104.17.0.743458302011.issue17599@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch implementing my suggestion to unconditionally define everything, prefixed with Py_ instead. Not tested on a normal Windows build. ---------- versions: +Python 3.6 -Python 3.4 Added file: http://bugs.python.org/file43907/Py_REPARSE.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 00:27:21 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 27 Jul 2016 04:27:21 +0000 Subject: [issue27546] Integrate tkinter and asyncio (and async) In-Reply-To: <1469580640.38.0.71762557487.issue27546@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: OK, in the context of IDLE it probably doesn't matter (though I recall that IDLE was given a hard time many years ago by people complaining about that same busy-waiting -- I guess batteries have improved somewhat since then). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 02:16:32 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 27 Jul 2016 06:16:32 +0000 Subject: [issue17594] mingw: preset configure defaults In-Reply-To: <1364759209.12.0.183871965153.issue17594@psf.upfronthosting.co.za> Message-ID: <1469600192.12.0.219133790162.issue17594@psf.upfronthosting.co.za> Martin Panter added the comment: Interesting approach. Why two separate files, for cross-compiling and native compiling? Why not merge them together? Some of the other Min GW patches add stuff like the following to the configure.ac checks. Would it make more sense to add e.g. ac_cv_struct_addrinfo=yes to the config, and avoid the compile check? AC_CACHE_VAL(ac_cv_struct_addrinfo, -AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include ]], [[struct addrinfo a]])], +AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[ +#ifdef HAVE_WS2TCPIP_H +# include +#else +# include +#endif]], + [[struct addrinfo a]])], [ac_cv_struct_addrinfo=yes], [ac_cv_struct_addrinfo=no])) ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 02:16:44 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 27 Jul 2016 06:16:44 +0000 Subject: [issue17594] mingw: preset configure defaults In-Reply-To: <1364759209.12.0.183871965153.issue17594@psf.upfronthosting.co.za> Message-ID: <1469600204.55.0.0439833503111.issue17594@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 02:18:28 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 27 Jul 2016 06:18:28 +0000 Subject: [issue18500] mingw: detect winsock2 and setup _socket module In-Reply-To: <1374179669.42.0.252427857289.issue18500@psf.upfronthosting.co.za> Message-ID: <1469600308.9.0.580303469496.issue18500@psf.upfronthosting.co.za> Martin Panter added the comment: The patch extends Misc/config_mingw, which is added by another patch in Issue 17594. ---------- dependencies: +mingw: preset configure defaults nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 02:41:51 2016 From: report at bugs.python.org (Ammar Askar) Date: Wed, 27 Jul 2016 06:41:51 +0000 Subject: [issue27631] .exe is appended to python executable based on filesystem case insensitivity Message-ID: <1469601711.28.0.541702866764.issue27631@psf.upfronthosting.co.za> New submission from Ammar Askar: I encountered some odd behavior today, I compiled python inside VirtualBox, however, I compiled it inside a shared folder. The OS outside of VirtualBox is Windows, so the shared folder naturally is case-insensitive. The actual virtual OS is Debian Linux. Upon running make, I found that oddly enough the executable created was called `python.exe`. Running `make install` still installs it to the correct python name. I did some digging around and from what I can tell this is the change that makes the built python executable have an exe extension or not depending on file system case insensitivity. https://hg.python.org/cpython/rev/d64dfbdc5f8c It's from way long ago from 2001 and I can't figure out why exactly this change was made. The commit message hints that it has something to do with Mac's file system. I asked a friend who used MacOS back then and he reports that it had no file extensions back then either. As far as I know, the only OS that really requires file extension is windows, and besides, this exact situation is what the https://www.gnu.org/software/automake/manual/html_node/EXEEXT.html variable is for, which is used in the configure.ac file already. It seems a little odd that whether or not to put .exe in the build executable is based on file system case insensitivity. ---------- components: Build messages: 271436 nosy: ammar2 priority: normal severity: normal status: open title: .exe is appended to python executable based on filesystem case insensitivity 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 Jul 27 02:52:57 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 27 Jul 2016 06:52:57 +0000 Subject: [issue27631] .exe is appended to python executable based on filesystem case insensitivity In-Reply-To: <1469601711.28.0.541702866764.issue27631@psf.upfronthosting.co.za> Message-ID: <1469602377.66.0.19081042193.issue27631@psf.upfronthosting.co.za> Martin Panter added the comment: My guess is it was to avoid a conflict between the ?Python/? source directory, and the ?./python? executable that may be built in the same directory. Wouldn?t that be a problem in your case too? ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 02:56:19 2016 From: report at bugs.python.org (Ammar Askar) Date: Wed, 27 Jul 2016 06:56:19 +0000 Subject: [issue27631] .exe is appended to python executable based on filesystem case insensitivity In-Reply-To: <1469601711.28.0.541702866764.issue27631@psf.upfronthosting.co.za> Message-ID: <1469602579.02.0.442888355061.issue27631@psf.upfronthosting.co.za> Ammar Askar added the comment: Aah, you're completely correct. Renaming it to python and doing ./python causes it to confuse it with the directory. Sorry. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 03:33:32 2016 From: report at bugs.python.org (Mark Lawrence) Date: Wed, 27 Jul 2016 07:33:32 +0000 Subject: [issue17594] mingw: preset configure defaults In-Reply-To: <1364759209.12.0.183871965153.issue17594@psf.upfronthosting.co.za> Message-ID: <1469604812.21.0.502960514803.issue17594@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 03:36:39 2016 From: report at bugs.python.org (Eryk Sun) Date: Wed, 27 Jul 2016 07:36:39 +0000 Subject: [issue27631] .exe is appended to python executable based on filesystem case insensitivity In-Reply-To: <1469601711.28.0.541702866764.issue27631@psf.upfronthosting.co.za> Message-ID: <1469604999.79.0.830371869537.issue27631@psf.upfronthosting.co.za> Changes by Eryk Sun : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 03:37:47 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 27 Jul 2016 07:37:47 +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: <1469605067.93.0.15709193088.issue16353@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > After several years there is still no consenus, so make it simple - the popen and subprocess shell is one of /bin/sh, cmd.exe, or some other "hard-coded" shell. I agree, the last patch that is being reviewed in issue 16255 attempts to do that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 04:28:34 2016 From: report at bugs.python.org (Michael Felt) Date: Wed, 27 Jul 2016 08:28:34 +0000 Subject: [issue27632] build on AIX fails when builddir != srcdir, more than bad path to ld_so_aix Message-ID: <1469608112.86.0.803958819971.issue27632@psf.upfronthosting.co.za> New submission from Michael Felt: Note: - Only examined on Python 2.7, but expect the same issue (from Python 3.4.X, 3.5.X and 3.6.X based on earlier attempts to use a separate builddir SUMMARY: * when builddir==srcdir build completes normally, (see DETAILS2:) * when builddir!=srcdir ... ** "configure" completes, no error messages ** "make" completes: some warnings, and I am surprised that make does not stop when message "unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory" appears The ./python executable can be executed (no other tests done yet) root at x064:[/data/prj/aixtools/python/Python-2.7.12]./python Python 2.7.12 (default, Jul 27 2016, 07:26:36) [C] on aix5 Type "help", "copyright", "credits" or "license" for more information. >>> * make install DESTDIR=/some/where/for/packaging - FAILS * in DETAILS3: I show that 'helping' by setting a symbolic link (messages continue), then a hard-link (ld_so_aix messages go away) also fails COMMENTS: * the Bitfield messages are 'known' and occur in all versions of Python (2.7.X, 3.3.X, 3.4.X, 3.5.X and 3.6.X - 3.2.X, (3.1.X and 3.0.X never tried)) * I hae no idea what all the "Skipping" is about, leaving in details as FYI DETAILS (verbatum): root at x064:[/data/prj/aixtools/python/Python-2.7.12]buildaix --without-computed-gotos VRMF 2.7.12.0 xlc is /usr/vacpp/bin/xlc + [[ 0 -eq 0 ]] + CC=xlc_r + export CC + CC=xlc_r CPPFLAGS="-I/opt/include -I/opt/buildaix/include" CFLAGS="-I/opt/include -O2 -qmaxmem=-1 -I/opt/buildaix/includes"\ ../src/Python-2.7.12/configure\ --prefix=/opt \ --sysconfdir=/var/Python/etc\ --sharedstatedir=/var/Python/com\ --localstatedir=/var/Python\ --mandir=/usr/share/man\ --infodir=/opt/share/info/Python --without-computed-gotos\ > .buildaix/configure.out + make > .buildaix/make.out "../src/Python-2.7.12/Objects/typeobject.c", line 6243.26: 1506-068 (W) Operation between types "void*" and "struct _object*(*)(struct _object*)" is not allowed. "../src/Python-2.7.12/Objects/typeobject.c", line 6290.22: 1506-068 (W) Operation between types "void*" and "long(*)(struct _object*)" is not allowed. "../src/Python-2.7.12/Objects/typeobject.c", line 6490.18: 1506-068 (W) Operation between types "void*" and "long(*)(struct _object*)" is not allowed. unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for M is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for N is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for O is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for P is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for Q is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for R is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for S is not valid. Type unsigned assumed. unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory "/data/prj/aixtools/python/src/Python-2.7.12/Modules/pyexpat.c", line 1538.27: 1506-068 (W) Operation between types "void*" and "void(*)(void*,const char*,int)" is not allowed. unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 3406.27: 1506-068 (W) Operation between types "void*" and "int(*)(void)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 3954.31: 1506-280 (W) Function argument assignment between types "int(*)(void)" and "void*" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5695.63: 1506-280 (W) Function argument assignment between types "void*" and "void*(*)(void*,const void*,unsigned long)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5696.62: 1506-280 (W) Function argument assignment between types "void*" and "void*(*)(void*,int,unsigned long)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5697.65: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(const char*,int)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5698.60: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(void*,struct _object*,struct _object*)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5700.66: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(const unsigned short*,int)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/callproc.c", line 837.32: 1506-280 (W) Function argument assignment between types "void(*)(void)" and "void*" is not allowed. Assembler: /tmp/xlcS0JTuaqd.s: line 160: 1252-149 Instruction extsb is not implemented in the current assembly mode COM. unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory + make install DESTDIR=/var/aixtools/python/Python/2.7.12.0 > .buildaix/install.out unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for M is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for N is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for O is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for P is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for Q is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for R is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for S is not valid. Type unsigned assumed. unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory "/data/prj/aixtools/python/src/Python-2.7.12/Modules/pyexpat.c", line 1538.27: 1506-068 (W) Operation between types "void*" and "void(*)(void*,const char*,int)" is not allowed. unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 3406.27: 1506-068 (W) Operation between types "void*" and "int(*)(void)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 3954.31: 1506-280 (W) Function argument assignment between types "int(*)(void)" and "void*" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5695.63: 1506-280 (W) Function argument assignment between types "void*" and "void*(*)(void*,const void*,unsigned long)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5696.62: 1506-280 (W) Function argument assignment between types "void*" and "void*(*)(void*,int,unsigned long)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5697.65: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(const char*,int)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5698.60: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(void*,struct _object*,struct _object*)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5700.66: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(const unsigned short*,int)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/callproc.c", line 837.32: 1506-280 (W) Function argument assignment between types "void(*)(void)" and "void*" is not allowed. Assembler: /tmp/xlcS0dZucqd.s: line 160: 1252-149 Instruction extsb is not implemented in the current assembly mode COM. unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory eval $PYTHON_FOR_BUILD ../../Tools/scripts/h2py.py -i "'(u_long)'" /usr/include/netinet/in.h Skipping: __restrict__ = restrict Skipping: __restrict__ = Skipping: __bool__ = _Bool Skipping: __bool__ = unsigned char Skipping: INT64_MIN = (INT64_C(-9223372036854775807)-1) Skipping: INT64_MAX = (INT64_C(9223372036854775807)) Skipping: UINT8_MAX = (255U) Skipping: UINT16_MAX = (65535U) Skipping: UINT32_MAX = (4294967295U) Skipping: UINT64_MAX = (UINT64_C(18446744073709551615)) Skipping: INT_LEAST64_MIN = INT64_MIN Skipping: INT_LEAST64_MAX = INT64_MAX Skipping: UINT_LEAST8_MAX = UINT8_MAX Skipping: UINT_LEAST16_MAX = UINT16_MAX Skipping: UINT_LEAST32_MAX = UINT32_MAX Skipping: UINT_LEAST64_MAX = UINT64_MAX Skipping: INT_FAST64_MIN = INT64_MIN Skipping: INT_FAST64_MAX = INT64_MAX Skipping: UINT_FAST8_MAX = UINT8_MAX Skipping: UINT_FAST16_MAX = UINT16_MAX Skipping: UINT_FAST32_MAX = UINT32_MAX Skipping: UINT_FAST64_MAX = UINT64_MAX Skipping: INTMAX_MIN = INT64_MIN Skipping: INTMAX_MAX = INT64_MAX Skipping: UINTMAX_MAX = UINT64_MAX Skipping: UINTMAX_MAX = UINT32_MAX Skipping: INTPTR_MIN = INT64_MIN Skipping: INTPTR_MAX = INT64_MAX Skipping: UINTPTR_MAX = UINT64_MAX Skipping: UINTPTR_MAX = UINT32_MAX Skipping: PTRDIFF_MIN = INT64_MIN Skipping: PTRDIFF_MAX = INT64_MAX Skipping: WCHAR_MAX = UINT32_MAX Skipping: WCHAR_MAX = UINT16_MAX Skipping: SIZE_MAX = UINT64_MAX Skipping: SIZE_MAX = UINT32_MAX Skipping: strtoumax = _strtoumax32 Skipping: wcstoimax = _wcstoimax32 Skipping: wcstoumax = _wcstoumax32 Skipping: imaxabs = _imaxabs32 Skipping: imaxdiv = _imaxdiv32 Skipping: UINTFAST_MAX = UINT32_MAX Skipping: def ADSP_MASK(_x): return ((1U << 31) >> (_x)) Skipping: def P64(X): return ( *((ptr64 *)&(X)) ) Skipping: fsid_dev = val[0] Skipping: fsid_type = val[1] Skipping: fh_dev = fh_fsid.fsid_dev Skipping: fh_type = fh_fsid.fsid_type Skipping: fh_len = fh_fid.fid_len Skipping: fh_ino = fh_fid.fid_ino Skipping: fh_gen = fh_fid.fid_gen Skipping: __NFDBITS = (sizeof(long) * 8) Skipping: __NUM_ENTRIES = (FD_SETSIZE/__NFDBITS+1) Skipping: def FD_ZERO(p): return { fd_set *__q=p; \ Skipping: NS_PER_TICK = (NS_PER_SEC/HZ) Skipping: TIMEBASE_SZ = (sizeof (struct timebasestruct)) Skipping: def ntimerisset(tvp): return ((tvp)->tv_sec || (tvp)->tv_nsec) Skipping: def ntimerclear(tvp): return (tvp)->tv_sec = (tvp)->tv_nsec = 0 Skipping: def timerisset(tvp): return ((tvp)->tv_sec || (tvp)->tv_usec) Skipping: def timerclear(tvp): return (tvp)->tv_sec = (tvp)->tv_usec = 0 Skipping: CLOCK_REALTIME = ((clockid_t) 9) Skipping: CLOCK_MONOTONIC = ((clockid_t) 10) Skipping: CLOCK_PROCESS_CPUTIME_ID = ((clockid_t) 11) Skipping: CLOCK_THREAD_CPUTIME_ID = ((clockid_t) 12) Skipping: _H_STDDEF = Skipping: offsetof = __offsetof Skipping: NFDBITS = __NFDBITS Skipping: s6_addr32 = s6_addr.s6_addr32 Skipping: s6_addr64 = s6_addr.s6_addr64 Skipping: s6_addr16 = s6_addr.s6_addr16 Skipping: s6_addr8 = s6_addr.s6_addr8 Skipping: s6_addr = s6_addr.s6_addr8 Skipping: INADDR_ANY = (uint32_t)0x00000000 Skipping: INADDR_BROADCAST = (uint32_t)(-1) Skipping: INADDR_UNSPEC_GROUP = (uint32_t)(-536870912) Skipping: INADDR_ALLHOSTS_GROUP = (uint32_t)(-536870911) Skipping: INADDR_ALLRTRS_GROUP = (uint32_t)(-536870910) Skipping: INADDR_MAX_LOCAL_GROUP = (uint32_t)(-536870657) Skipping: MSR_HYPERVISOR = (1152921500311879680)L Skipping: DSCR_PROP_VER0_SIZE = (offsetof(struct dscr_properties, dscr_res)) Skipping: DSCR_PROP_SIZE = (sizeof(struct dscr_properties)) Skipping: FP_IE_IMPL = (fp_ie_impl != 0) Skipping: ASR_VALID = (1LL) Skipping: SLB_PSIZE_MASK = 0x170UL Skipping: def VALID_HANDLE_SSLB(_handle): return (!((_handle) & 0x0f)) Skipping: HANDLE_CLASS_SSLB = 0x80UL Skipping: def htons(hostshort): return (unsigned short)(hostshort) Skipping: def ntohs(netshort): return (unsigned short)(netshort) Skipping: INADDR_LOOPBACK = (uint32_t)0x7f000001 Skipping: s6_addr32 = u6_addr.u6_addr32 Skipping: s6_addr64 = u6_addr.u6_addr64 Skipping: s6_addr16 = u6_addr.u6_addr16 Skipping: s6_addr8 = u6_addr.u6_addr8 Skipping: s6_addr = u6_addr.u6_addr8 Skipping: def HTONLL(x): return (x) = htonll((x)); Skipping: def HTONL(x): return (x) = htonl((x)); Skipping: def HTONS(x): return (x) = htons((x)); Skipping: def NTOHLL(x): return (x) = ntohll((x)); Skipping: def NTOHL(x): return (x) = ntohl((x)); Skipping: def NTOHS(x): return (x) = ntohs((x)); Skipping: def IPV6_GET_VERSION(x): return ((*((u_char *)&(x)) >> 4) & 0xf) Skipping: def IN6_ADDR_V6_TO_V4(a): return ((struct in_addr *)&(a)->s6_addr[12]) Skipping: def satosin(sa): return ((struct sockaddr_in *)(sa)) Skipping: def sintosa(sin): return ((struct sockaddr *)(sin)) Skipping: def ifatoia(ifa): return ((struct in_ifaddr *)(ifa)) Skipping: def satosin6(sa): return ((struct sockaddr_in6 *)(sa)) Skipping: def sin6tosa(sin6): return ((struct sockaddr *)(sin6)) Skipping: def ifatoia6(ifa): return ((struct in6_ifaddr *)(ifa)) Traceback (most recent call last): File "/var/aixtools/python/Python/2.7.12.0/opt/lib/python2.7/compileall.py", line 16, in import struct File "/var/aixtools/python/Python/2.7.12.0/opt/lib/python2.7/struct.py", line 1, in from _struct import * ImportError: No module named _struct make: 1254-004 The error code from the last command is 1. Stop. make install returned an error root at x064:[/data/prj/aixtools/python/Python-2.7.12] DETAILS2: root at x064:[/data/prj/aixtools/python/python-2.7.12]buildaix --without-computed-gotos VRMF 2.7.12.0 xlc is /usr/vacpp/bin/xlc + [[ 0 -eq 0 ]] + CC=xlc_r + export CC + CC=xlc_r CPPFLAGS="-I/opt/include -I/opt/buildaix/include" CFLAGS="-I/opt/include -O2 -qmaxmem=-1 -I/opt/buildaix/includes"\ ./configure\ --prefix=/opt \ --sysconfdir=/var/python/etc\ --sharedstatedir=/var/python/com\ --localstatedir=/var/python\ --mandir=/usr/share/man\ --infodir=/opt/share/info/python --without-computed-gotos\ > .buildaix/configure.out + make > .buildaix/make.out "Objects/typeobject.c", line 6243.26: 1506-068 (W) Operation between types "void*" and "struct _object*(*)(struct _object*)" is not allowed. "Objects/typeobject.c", line 6290.22: 1506-068 (W) Operation between types "void*" and "long(*)(struct _object*)" is not allowed. "Objects/typeobject.c", line 6490.18: 1506-068 (W) Operation between types "void*" and "long(*)(struct _object*)" is not allowed. "/data/prj/aixtools/python/python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for M is not valid. Type unsigned assumed. "/data/prj/aixtools/python/python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for N is not valid. Type unsigned assumed. "/data/prj/aixtools/python/python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for O is not valid. Type unsigned assumed. "/data/prj/aixtools/python/python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for P is not valid. Type unsigned assumed. "/data/prj/aixtools/python/python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for Q is not valid. Type unsigned assumed. "/data/prj/aixtools/python/python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for R is not valid. Type unsigned assumed. "/data/prj/aixtools/python/python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for S is not valid. Type unsigned assumed. "/data/prj/aixtools/python/python-2.7.12/Modules/pyexpat.c", line 1538.27: 1506-068 (W) Operation between types "void*" and "void(*)(void*,const char*,int)" is not allowed. "/data/prj/aixtools/python/python-2.7.12/Modules/_ctypes/_ctypes.c", line 3406.27: 1506-068 (W) Operation between types "void*" and "int(*)(void)" is not allowed. "/data/prj/aixtools/python/python-2.7.12/Modules/_ctypes/_ctypes.c", line 3954.31: 1506-280 (W) Function argument assignment between types "int(*)(void)" and "void*" is not allowed. "/data/prj/aixtools/python/python-2.7.12/Modules/_ctypes/_ctypes.c", line 5695.63: 1506-280 (W) Function argument assignment between types "void*" and "void*(*)(void*,const void*,unsigned long)" is not allowed. "/data/prj/aixtools/python/python-2.7.12/Modules/_ctypes/_ctypes.c", line 5696.62: 1506-280 (W) Function argument assignment between types "void*" and "void*(*)(void*,int,unsigned long)" is not allowed. "/data/prj/aixtools/python/python-2.7.12/Modules/_ctypes/_ctypes.c", line 5697.65: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(const char*,int)" is not allowed. "/data/prj/aixtools/python/python-2.7.12/Modules/_ctypes/_ctypes.c", line 5698.60: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(void*,struct _object*,struct _object*)" is not allowed. "/data/prj/aixtools/python/python-2.7.12/Modules/_ctypes/_ctypes.c", line 5700.66: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(const unsigned short*,int)" is not allowed. "/data/prj/aixtools/python/python-2.7.12/Modules/_ctypes/callproc.c", line 837.32: 1506-280 (W) Function argument assignment between types "void(*)(void)" and "void*" is not allowed. Assembler: /tmp/xlcS0YSYiqd.s: line 160: 1252-149 Instruction extsb is not implemented in the current assembly mode COM. + make install DESTDIR=/var/aixtools/aixtools/python/2.7.12.0 > .buildaix/install.out + mkinstallp.ksh /var/aixtools/aixtools/python/2.7.12.0 > .buildaix/mkinstallp.out ============================== aixtools.python:aixtools.python.man.en_US:2.7.12.0::I:T:::::N:man pages::::0:: aixtools.python:aixtools.python.rte:2.7.12.0::I:T:::::N:built 27-Jul-2016 0744 UTC::::0:: ============================== root at x064:[/data/prj/aixtools/python/python-2.7.12] DETAILS3: root at x064:[/data/prj/aixtools/python/Python-2.7.12]buildaix --without-computed-gotos VRMF 2.7.12.0 xlc is /usr/vacpp/bin/xlc + [[ 0 -eq 0 ]] + CC=xlc_r + export CC + CC=xlc_r CPPFLAGS="-I/opt/include -I/opt/buildaix/include" CFLAGS="-I/opt/include -O2 -qmaxmem=-1 -I/opt/buildaix/includes"\ ../src/Python-2.7.12/configure\ --prefix=/opt \ --sysconfdir=/var/Python/etc\ --sharedstatedir=/var/Python/com\ --localstatedir=/var/Python\ --mandir=/usr/share/man\ --infodir=/opt/share/info/Python --without-computed-gotos\ > .buildaix/configure.out + make > .buildaix/make.out root at x064:[/data/prj/aixtools/python/Python-2.7.12]find . -name ld_so_aix ./Modules/ld_so_aix root at x064:[/data/prj/aixtools/python/Python-2.7.12]ls ../src/Python-2.7.12/Modules Setup.config.in _heapqmodule.c _ssl_data.h bz2module.c datetimemodule.c gdbmmodule.c main.c posixmodule.h shamodule.c testcapi_long.h yuvconvert.c Setup.dist _hotshot.c _struct.c cPickle.c dbmmodule.c getaddrinfo.c makesetup puremodule.c signalmodule.c threadmodule.c zipimport.c _bisectmodule.c _io _testcapimodule.c cStringIO.c dlmodule.c getbuildinfo.c makexp_aix pwdmodule.c socketmodule.c timemodule.c zlib _bsddb.c _json.c _tkinter.c cdmodule.c errnomodule.c getnameinfo.c mathmodule.c pyexpat.c socketmodule.h timing.h zlibmodule.c _codecsmodule.c _localemodule.c _weakref.c cgen.py expat getpath.c md5.c python.c spwdmodule.c timingmodule.c _collectionsmodule.c _lsprof.c addrinfo.h cgensupport.c fcntlmodule.c glmodule.c md5.h readline.c sre.h tkappinit.c _csv.c _math.c almodule.c cgensupport.h flmodule.c grpmodule.c md5module.c resource.c sre_constants.h tkinter.h _ctypes _math.h ar_beos cjkcodecs fmmodule.c imageop.c mmapmodule.c rotatingtree.c stropmodule.c unicodedata.c _curses_panel.c _multiprocessing arraymodule.c clmodule.c fpectlmodule.c imgfile.c nismodule.c rotatingtree.h sunaudiodev.c unicodedata_db.h _cursesmodule.c _randommodule.c audioop.c cmathmodule.c fpetestmodule.c itertoolsmodule.c operator.c selectmodule.c svmodule.c unicodename_db.h _elementtree.c _sqlite binascii.c config.c.in future_builtins.c ld_so_aix.in ossaudiodev.c sgimodule.c symtablemodule.c xxmodule.c _functoolsmodule.c _sre.c bsddb.h cryptmodule.c gc_weakref.txt ld_so_beos parsermodule.c sha256module.c syslogmodule.c xxsubtype.c _hashopenssl.c _ssl.c bsddbmodule.c cstubs gcmodule.c linuxaudiodev.c posixmodule.c sha512module.c termios.c yuv.h root at x064:[/data/prj/aixtools/python/Python-2.7.12]ln -s ./Modules/ld_so_aix ../src/Python-2.7.12/Modules root at x064:[/data/prj/aixtools/python/Python-2.7.12]ls -l ../src/Python-2.7.12/Modules/ld_so_aix lrwxrwxrwx 1 root system 19 Jul 27 08:00 ../src/Python-2.7.12/Modules/ld_so_aix -> ./Modules/ld_so_aix root at x064:[/data/prj/aixtools/python/Python-2.7.12] This fails as a symbolic link: root at x064:[/data/prj/aixtools/python/Python-2.7.12]buildaix --without-computed-gotos VRMF 2.7.12.0 do_configure: using existing Makefile do_configure: run distclean to get a standard AIX configure -rw-r----- 1 root system 52350 Jul 27 07:57 ./Makefile -rw-r----- 1 root system 732150 Jul 27 07:57 config.log -rwxr-x--x 1 root system 39198 Jul 27 07:57 config.status + > .buildaix/make.out "../src/Python-2.7.12/Objects/typeobject.c", line 6243.26: 1506-068 (W) Operation between types "void*" and "struct _object*(*)(struct _object*)" is not allowed. "../src/Python-2.7.12/Objects/typeobject.c", line 6290.22: 1506-068 (W) Operation between types "void*" and "long(*)(struct _object*)" is not allowed. "../src/Python-2.7.12/Objects/typeobject.c", line 6490.18: 1506-068 (W) Operation between types "void*" and "long(*)(struct _object*)" is not allowed. unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for M is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for N is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for O is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for P is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for Q is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for R is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for S is not valid. Type unsigned assumed. unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory interruptedroot at x064:[/data/prj/aixtools/python/Python-2.7.12] root at x064:[/data/prj/aixtools/python/Python-2.7.12]ln -f ./Modules/ld_so_aix ../src/Python-2.7.12/Modules root at x064:[/data/prj/aixtools/python/Python-2.7.12]ls -l ../src/Python-2.7.12/Modules/ld_so_aix -rwxr-x--x 2 root system 6208 Jul 27 07:57 ../src/Python-2.7.12/Modules/ld_so_aix Trying again as a hard-link - fewer messages, but it still fails. root at x064:[/data/prj/aixtools/python/Python-2.7.12]make clean find ../src/Python-2.7.12 -name '*.py[co]' -exec rm -f {} ';' find . -name '*.[oa]' -exec rm -f {} ';' find . -name '*.s[ol]' -exec rm -f {} ';' find . -name '*.so.[0-9]*.[0-9]*' -exec rm -f {} ';' find build -name 'fficonfig.h' -exec rm -f {} ';' || true find build -name 'fficonfig.py' -exec rm -f {} ';' || true rm -f Lib/lib2to3/*Grammar*.pickle rm -rf build root at x064:[/data/prj/aixtools/python/Python-2.7.12]buildaix --without-computed-gotos VRMF 2.7.12.0 do_configure: using existing Makefile do_configure: run distclean to get a standard AIX configure -rw-r----- 1 root system 52350 Jul 27 07:57 ./Makefile -rw-r----- 1 root system 732150 Jul 27 07:57 config.log -rwxr-x--x 1 root system 39198 Jul 27 07:57 config.status + > .buildaix/make.out "../src/Python-2.7.12/Objects/typeobject.c", line 6243.26: 1506-068 (W) Operation between types "void*" and "struct _object*(*)(struct _object*)" is not allowed. "../src/Python-2.7.12/Objects/typeobject.c", line 6290.22: 1506-068 (W) Operation between types "void*" and "long(*)(struct _object*)" is not allowed. "../src/Python-2.7.12/Objects/typeobject.c", line 6490.18: 1506-068 (W) Operation between types "void*" and "long(*)(struct _object*)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for M is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for N is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for O is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for P is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for Q is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for R is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for S is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/pyexpat.c", line 1538.27: 1506-068 (W) Operation between types "void*" and "void(*)(void*,const char*,int)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 3406.27: 1506-068 (W) Operation between types "void*" and "int(*)(void)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 3954.31: 1506-280 (W) Function argument assignment between types "int(*)(void)" and "void*" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5695.63: 1506-280 (W) Function argument assignment between types "void*" and "void*(*)(void*,const void*,unsigned long)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5696.62: 1506-280 (W) Function argument assignment between types "void*" and "void*(*)(void*,int,unsigned long)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5697.65: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(const char*,int)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5698.60: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(void*,struct _object*,struct _object*)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5700.66: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(const unsigned short*,int)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/callproc.c", line 837.32: 1506-280 (W) Function argument assignment between types "void(*)(void)" and "void*" is not allowed. Assembler: /tmp/xlcS0Jxigid.s: line 160: 1252-149 Instruction extsb is not implemented in the current assembly mode COM. + make install DESTDIR=/var/aixtools/python/Python/2.7.12.0 > .buildaix/install.out "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for M is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for N is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for O is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for P is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for Q is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for R is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for S is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/pyexpat.c", line 1538.27: 1506-068 (W) Operation between types "void*" and "void(*)(void*,const char*,int)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 3406.27: 1506-068 (W) Operation between types "void*" and "int(*)(void)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 3954.31: 1506-280 (W) Function argument assignment between types "int(*)(void)" and "void*" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5695.63: 1506-280 (W) Function argument assignment between types "void*" and "void*(*)(void*,const void*,unsigned long)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5696.62: 1506-280 (W) Function argument assignment between types "void*" and "void*(*)(void*,int,unsigned long)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5697.65: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(const char*,int)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5698.60: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(void*,struct _object*,struct _object*)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5700.66: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(const unsigned short*,int)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/callproc.c", line 837.32: 1506-280 (W) Function argument assignment between types "void(*)(void)" and "void*" is not allowed. Assembler: /tmp/xlcS0hxAmMd.s: line 160: 1252-149 Instruction extsb is not implemented in the current assembly mode COM. Traceback (most recent call last): File "/var/aixtools/python/Python/2.7.12.0/opt/lib/python2.7/compileall.py", line 16, in import struct File "/var/aixtools/python/Python/2.7.12.0/opt/lib/python2.7/struct.py", line 1, in from _struct import * ImportError: No module named _struct make: 1254-004 The error code from the last command is 1. Stop. make install returned an error root at x064:[/data/prj/aixtools/python/Python-2.7.12] ---------- components: Installation messages: 271440 nosy: Michael.Felt priority: normal severity: normal status: open title: build on AIX fails when builddir != srcdir, more than bad path to ld_so_aix type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 04:45:53 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 27 Jul 2016 08:45:53 +0000 Subject: [issue17602] mingw: default sys.path calculations for windows platforms In-Reply-To: <1364760613.75.0.604084743865.issue17602@psf.upfronthosting.co.za> Message-ID: <1469609153.28.0.719082286627.issue17602@psf.upfronthosting.co.za> Martin Panter added the comment: I wonder if the PYTHONPATH preprocessor definition can just be moved from PC/pyconfig.h. It is a shame to duplicate it, and it only seems to be used in PC/getpathp.c (if you ignore Modules/getpath.c which is unused on Windows). ---------- components: +Windows nosy: +martin.panter, paul.moore, steve.dower, tim.golden, zach.ware stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 05:30:33 2016 From: report at bugs.python.org (Florian Preinstorfer) Date: Wed, 27 Jul 2016 09:30:33 +0000 Subject: [issue27633] Doc: Add missing version info to email.parser Message-ID: <1469611833.34.0.859096267207.issue27633@psf.upfronthosting.co.za> New submission from Florian Preinstorfer: The versionchanged field has no version info for message_from_string(). ---------- files: email-parser-add_version_info.patch keywords: patch messages: 271442 nosy: notizblock priority: normal severity: normal status: open title: Doc: Add missing version info to email.parser type: enhancement versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43908/email-parser-add_version_info.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 05:36:51 2016 From: report at bugs.python.org (SilentGhost) Date: Wed, 27 Jul 2016 09:36:51 +0000 Subject: [issue27633] Doc: Add missing version info to email.parser In-Reply-To: <1469611833.34.0.859096267207.issue27633@psf.upfronthosting.co.za> Message-ID: <1469612211.07.0.943868546769.issue27633@psf.upfronthosting.co.za> SilentGhost added the comment: LGTM ---------- assignee: -> docs at python components: +Documentation nosy: +SilentGhost, docs at python stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 06:33:11 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 27 Jul 2016 10:33:11 +0000 Subject: [issue27633] Doc: Add missing version info to email.parser In-Reply-To: <1469611833.34.0.859096267207.issue27633@psf.upfronthosting.co.za> Message-ID: <20160727103308.94294.67642.1D425AA6@psf.io> Roundup Robot added the comment: New changeset 3f2e37e705d3 by Berker Peksag in branch '3.5': Issue #27633: Fix usage of versionchanged directive in email.parser.rst https://hg.python.org/cpython/rev/3f2e37e705d3 New changeset 8224ad99842e by Berker Peksag in branch 'default': Issue #27633: Merge from 3.5 https://hg.python.org/cpython/rev/8224ad99842e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 06:33:52 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 27 Jul 2016 10:33:52 +0000 Subject: [issue27633] Doc: Add missing version info to email.parser In-Reply-To: <1469611833.34.0.859096267207.issue27633@psf.upfronthosting.co.za> Message-ID: <1469615632.93.0.09736169782.issue27633@psf.upfronthosting.co.za> Berker Peksag added the comment: Good catch, thanks! ---------- nosy: +berker.peksag resolution: -> fixed stage: commit review -> resolved status: open -> closed type: enhancement -> behavior versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 07:54:56 2016 From: report at bugs.python.org (Przemyslaw Wegrzyn) Date: Wed, 27 Jul 2016 11:54:56 +0000 Subject: [issue27634] selectors.SelectSelectors fails if select.select was patched Message-ID: <1469620496.01.0.933139136376.issue27634@psf.upfronthosting.co.za> New submission from Przemyslaw Wegrzyn: The SelectSelector makes a local copy of select.select() built-in and calls it via self._select later on. It no longer works if select.select() built-in is replaced with function (something gevent's monkey patching does). Currently gevent employs a workaround - it overwrites SelectSelector._select. It wouldn't be necessary if SelectSelector could cope with select.select() being a regular function. Attached is a file reproducing the issue. ---------- components: Library (Lib) files: t_s.py messages: 271446 nosy: Przemyslaw Wegrzyn priority: normal severity: normal status: open title: selectors.SelectSelectors fails if select.select was patched type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file43909/t_s.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 07:58:54 2016 From: report at bugs.python.org (Przemyslaw Wegrzyn) Date: Wed, 27 Jul 2016 11:58:54 +0000 Subject: [issue27634] selectors.SelectSelectors fails if select.select was patched In-Reply-To: <1469620496.01.0.933139136376.issue27634@psf.upfronthosting.co.za> Message-ID: <1469620734.31.0.0126614233622.issue27634@psf.upfronthosting.co.za> Przemyslaw Wegrzyn added the comment: Possible workaround in the patch attached. ---------- keywords: +patch Added file: http://bugs.python.org/file43910/selectors.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 09:00:50 2016 From: report at bugs.python.org (jonathan miller) Date: Wed, 27 Jul 2016 13:00:50 +0000 Subject: [issue18304] ElementTree -- provide a way to ignore namespace in tags and seaches In-Reply-To: <1372218497.28.0.26294900817.issue18304@psf.upfronthosting.co.za> Message-ID: <1469624450.16.0.71933595696.issue18304@psf.upfronthosting.co.za> jonathan miller added the comment: A flexible and pretty simple way opf loosening up handling namespaces would be to OPTIONALLY change what is done at parse time: 1. Don't handle xmlns declarations specially. Leave them as normal attributes, and the Element.attrib would have a normal entry for each. 2. Leave the abbreviation colon-separated prefix in front of the element tags as they come in. If the using code wants, it can walk the ElementTree contents making dictionaries of the active namespace declarations, tucking a dict reference into each Element. Maybe put in an ElementTree method that does this, why not? I'm interested in this topic because I wish to handle xml from a variety of different tools, some of which had their XML elements defined without namespaces. They can use element names which are really common - like 'project' - and have no namespace definitions. Worse: if you put one in, the tool that originally used the element breaks. Doing things as suggested gives the user the opportunity to look for matches using the colonized names, to shift namespace abbrevs easily, and to write out nicely namespaced code with abbrevs on the elements easily. This would be OPTIONAL: the way etree does it now, full prefixing of URI, is the safe way and should be retained as the default. ---------- nosy: +jjmiller50 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 09:42:00 2016 From: report at bugs.python.org (Steve Dower) Date: Wed, 27 Jul 2016 13:42:00 +0000 Subject: [issue17599] mingw: detect REPARSE_DATA_BUFFER In-Reply-To: <1364759977.57.0.233975454494.issue17599@psf.upfronthosting.co.za> Message-ID: <1469626920.08.0.432811145243.issue17599@psf.upfronthosting.co.za> Steve Dower added the comment: Worth checking if the headers in VC14 have the structure now, as it may simplify the whole thing. If not, I'd add a leading underscore to the name so nobody confuses it for public API in the future. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 09:44:07 2016 From: report at bugs.python.org (Steve Dower) Date: Wed, 27 Jul 2016 13:44:07 +0000 Subject: [issue17602] mingw: default sys.path calculations for windows platforms In-Reply-To: <1364760613.75.0.604084743865.issue17602@psf.upfronthosting.co.za> Message-ID: <1469627047.89.0.439536538061.issue17602@psf.upfronthosting.co.za> Steve Dower added the comment: Can MinGW build against Modules/getpath.c? I'd rather just use the posix implementation than scatter ifdefs throughout the non-posix one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 10:02:00 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 27 Jul 2016 14:02:00 +0000 Subject: [issue27630] Generator._encoded_EMTPY misspelling in email package In-Reply-To: <1469581633.21.0.276257861067.issue27630@psf.upfronthosting.co.za> Message-ID: <1469628120.55.0.398914882389.issue27630@psf.upfronthosting.co.za> R. David Murray added the comment: The former is kept (IIRC) for backward compatibility, the latter should be investigated. Since I wrote that code I'll have to add this to my todo list. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 10:04:53 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 27 Jul 2016 14:04:53 +0000 Subject: [issue27634] selectors.SelectSelectors fails if select.select was patched In-Reply-To: <1469620496.01.0.933139136376.issue27634@psf.upfronthosting.co.za> Message-ID: <1469628293.4.0.521615204036.issue27634@psf.upfronthosting.co.za> STINNER Victor added the comment: Monkey-patching is a bad programming practice. I don't think that Python should promote this... *But* selectors.diff LGTM. I will wait one or two weeks to let others review the patch and give their opinion. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 10:11:47 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 27 Jul 2016 14:11:47 +0000 Subject: [issue23085] update internal libffi copy to 3.2.1 In-Reply-To: <1418922803.63.0.55729998299.issue23085@psf.upfronthosting.co.za> Message-ID: <1469628707.49.0.756776791536.issue23085@psf.upfronthosting.co.za> R. David Murray added the comment: See msg243261, I think. On linux and freebsd we could theoretically leave that to the distros, but on OSX we have to deal with it ourselves. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 10:18:34 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 27 Jul 2016 14:18:34 +0000 Subject: [issue27626] Spelling fixes In-Reply-To: <1469548433.15.0.911548060088.issue27626@psf.upfronthosting.co.za> Message-ID: <1469629114.3.0.592284639477.issue27626@psf.upfronthosting.co.za> R. David Murray added the comment: LGTM as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 10:25:17 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 27 Jul 2016 14:25:17 +0000 Subject: [issue27629] Cannot create ssl.SSLSocket without existing socket In-Reply-To: <1469575305.76.0.392837082138.issue27629@psf.upfronthosting.co.za> Message-ID: <1469629517.16.0.957097167549.issue27629@psf.upfronthosting.co.za> STINNER Victor added the comment: The change introducing the != SOCK_STREAM check (change a00842b783cf) was made in 2013. It looks like the case was not tested since at least 3 years... > This will need a test in Lib/test/test_ssl.py to check for this particular case. Yes, this new test is mandatory to make sure that the feature is not broken again (check for regression). The workaround is to pass an existing socket... ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 10:31:28 2016 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 27 Jul 2016 14:31:28 +0000 Subject: [issue1521950] shlex.split() does not tokenize like the shell Message-ID: <1469629888.09.0.588434865717.issue1521950@psf.upfronthosting.co.za> Vinay Sajip added the comment: Okay, I've updated with a new patch addressing SilentGhost's comments, and addressed the comments on that patch. If I don't hear any objections by Friday, I plan to commit this change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 10:33:00 2016 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 27 Jul 2016 14:33:00 +0000 Subject: [issue1521950] shlex.split() does not tokenize like the shell Message-ID: <1469629980.7.0.38994701101.issue1521950@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- assignee: -> vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 11:00:52 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 27 Jul 2016 15:00:52 +0000 Subject: [issue11048] "import ctypes" causes segfault on read-only filesystem In-Reply-To: <1296234309.62.0.290829997988.issue11048@psf.upfronthosting.co.za> Message-ID: <20160727150038.18174.63410.1A46E660@psf.io> Roundup Robot added the comment: New changeset ab4975520c7d by Victor Stinner in branch '3.5': ctypes: fix CThunkObject_new() https://hg.python.org/cpython/rev/ab4975520c7d New changeset da9898e7e90d by Victor Stinner in branch 'default': Merge 3.5 (issue #11048) https://hg.python.org/cpython/rev/da9898e7e90d New changeset 7d692840c152 by Victor Stinner in branch '2.7': ctypes: fix CThunkObject_new() https://hg.python.org/cpython/rev/7d692840c152 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 11:07:59 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 27 Jul 2016 15:07:59 +0000 Subject: [issue11048] "import ctypes" causes segfault on read-only filesystem In-Reply-To: <1296234309.62.0.290829997988.issue11048@psf.upfronthosting.co.za> Message-ID: <1469632079.63.0.0048836143657.issue11048@psf.upfronthosting.co.za> STINNER Victor added the comment: Sorry, I'm unable to reproduce the crash using the read-only filesystem. But an assertion confirmed me that the restype is not initialized which is an obvious bug. ctypes-erofs-crash.diff: LGTM. By the way, the flags field is not initialized neither, but it's probably less important (at least for the destructor). Alexander Belopolsky: "It would be nice to add a unit test to this patch." I tried to write a short unit test triggering the bug, but it really depends on low-level implementation details for a very specific corner case. I would prefer to avoid such complex unit test and just fix the bug. We waited for an unit test the last 5 years, it's too late now :-) "A nit-pick: it would be easier to verify that all CThunkObject fields are initialized if initialization was done in the same order as declaration:" Right, I rewrote the patch as you suggested. I noticed that flags is not initialized neither (also fixed in my patch). I pushed a fix. Thanks marcin.bachry for the initial patch! Thanks Pavel Labushev for your bug report! ... but sorry for the very long delay :-( It looks like nobody reproduced the bug recently, maybe it was fixed in libffi in the meanwhile? ---------- nosy: +haypo resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 11:10:01 2016 From: report at bugs.python.org (Emanuel Barry) Date: Wed, 27 Jul 2016 15:10:01 +0000 Subject: [issue11048] "import ctypes" causes segfault on read-only filesystem In-Reply-To: <1296234309.62.0.290829997988.issue11048@psf.upfronthosting.co.za> Message-ID: <1469632201.78.0.154562676967.issue11048@psf.upfronthosting.co.za> Changes by Emanuel Barry : ---------- stage: test needed -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 11:12:26 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 27 Jul 2016 15:12:26 +0000 Subject: [issue27624] unclear documentation on Queue.qsize() In-Reply-To: <1469538053.41.0.353171937214.issue27624@psf.upfronthosting.co.za> Message-ID: <1469632346.12.0.782244497586.issue27624@psf.upfronthosting.co.za> STINNER Victor added the comment: """ Return the number of items in the queue. Note, in multi-threading this mostly just serves as an approximation, and information from this doesn?t guarantee that a subsequent get() or put() will not block. """ I dislike this description. If I understand correctly, the issue is that someone must not rely on the size to check if the queue is empty or not. If I'm right, the doc must be more explicit. Something like: "The size must not be used to check if get() or put() will block. Use get_nowait() and put_nowait(), or get() and put() in non-blocking mode (block=False)." There is even a Wikipedia article on the bug :-) https://en.wikipedia.org/wiki/Time_of_check_to_time_of_use (I'm not sure that it's exactly the same class of bug.) ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 12:12:13 2016 From: report at bugs.python.org (Doug Hoskisson) Date: Wed, 27 Jul 2016 16:12:13 +0000 Subject: [issue27624] unclear documentation on Queue.qsize() In-Reply-To: <1469538053.41.0.353171937214.issue27624@psf.upfronthosting.co.za> Message-ID: <1469635933.98.0.888401149317.issue27624@psf.upfronthosting.co.za> Doug Hoskisson added the comment: More explicit is ok, if that's what people want, but just not in the first sentence, because that stuff has nothing to do with what is being documented specifically (as evidenced by referencing a wikipedia article that doesn't even mention python). I don't think more explicit is necessary, but if that's what others want, it's not bad. How much of the python documentation should be dedicated to teaching people stuff that has nothing to do with python specifically? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 12:33:22 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 27 Jul 2016 16:33:22 +0000 Subject: [issue24214] Exception with utf-8, surrogatepass and incremental decoding In-Reply-To: <1431816994.33.0.797161516902.issue24214@psf.upfronthosting.co.za> Message-ID: <1469637202.95.0.161137182252.issue24214@psf.upfronthosting.co.za> STINNER Victor added the comment: Attached patch fixes the UTF-8 decoder to support correctly incremental decoder using surrogatepass error handler. The bug occurs when b'\xed\xa4\x80' is decoded in two parts: the first two bytes (b'\xed\xa4'), and then the last byte (b'\x80'). It works as expected if we decode the first byte (b'\xed') and then the two last bytes (b'\xa4\x80'). My patch tries to keep best performances for the UTF-8/strict decoder. @Serhiy: Would you mind to review my patch since you helped to design the fast UTF-8 decoder? ---------- keywords: +patch Added file: http://bugs.python.org/file43911/surrogatepass.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 12:33:32 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 27 Jul 2016 16:33:32 +0000 Subject: [issue24214] UTF-8 incremental decoder doesn't support surrogatepass correctly In-Reply-To: <1431816994.33.0.797161516902.issue24214@psf.upfronthosting.co.za> Message-ID: <1469637212.34.0.660996808106.issue24214@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: Exception with utf-8, surrogatepass and incremental decoding -> UTF-8 incremental decoder doesn't support surrogatepass correctly _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 12:48:04 2016 From: report at bugs.python.org (Brett Cannon) Date: Wed, 27 Jul 2016 16:48:04 +0000 Subject: [issue27634] selectors.SelectSelectors fails if select.select was patched In-Reply-To: <1469620496.01.0.933139136376.issue27634@psf.upfronthosting.co.za> Message-ID: <1469638084.19.0.292438501485.issue27634@psf.upfronthosting.co.za> Brett Cannon added the comment: I agree with Victor: monkeypatching is the wrong way to deal with this. Since SelectSelector is a class you are better off exposing something in the constructor or some method that can be overridden if this kind of flexibility is really necessary. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 12:48:50 2016 From: report at bugs.python.org (Brett Cannon) Date: Wed, 27 Jul 2016 16:48:50 +0000 Subject: [issue27634] selectors.SelectSelectors fails if select.select was patched In-Reply-To: <1469620496.01.0.933139136376.issue27634@psf.upfronthosting.co.za> Message-ID: <1469638130.59.0.137674949934.issue27634@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks for the patch, Przemyslaw, but I'm going to close this. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 12:59:37 2016 From: report at bugs.python.org (Mark Roseman) Date: Wed, 27 Jul 2016 16:59:37 +0000 Subject: [issue27621] incorrectly works in IDLE Query dialogs In-Reply-To: <1469512966.74.0.594331033204.issue27621@psf.upfronthosting.co.za> Message-ID: <1469638777.76.0.805453826469.issue27621@psf.upfronthosting.co.za> Mark Roseman added the comment: Side note that on Mac OS X, buttons normally don't get the focus, so that this isn't an issue. Well except that buttons are getting the focus here. :-) Also since we're reinventing the wheel, please note that alternative keyboard shortcuts (e.g. command-period) don't work, and there isn't a default button set for the dialog which there should be. Interestingly, you can change things in System Preferences -> Keyboard -> Shortcuts so that buttons can get the focus via tabbing through the interface. If this is enabled and you tab to the Cancel button and his Return, it should still be treated as if you hit the Okay button on Mac. Hitting space while focus is on the Cancel button does treat it as if you clicked on Cancel. ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 13:07:25 2016 From: report at bugs.python.org (July Tikhonov) Date: Wed, 27 Jul 2016 17:07:25 +0000 Subject: [issue27635] pickle documentation says that unpickling may not call __new__ Message-ID: <1469639245.7.0.966654223743.issue27635@psf.upfronthosting.co.za> New submission from July Tikhonov: A note just below object.__setstate__() documentation https://docs.python.org/3.6/library/pickle.html#object.__setstate__ says that """ ? the type should implement __getnewargs__() or __getnewargs_ex__() to establish such an invariant; otherwise, neither __new__() nor __init__() will be called. """ I believe that note about not calling __new__() was relevant in python2. I could not find case in python3 in which __new__() would not be called. And __init__() is not called anyway, as far as I understand (unless explicitly by __setstate__() or something). Python 3.6.0a3+ (default:da9898e7e90d, Jul 27 2016, 19:51:12) [GCC 4.9.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> class C: ... def __getstate__(self): return {'foo' : self.foo} ... def __setstate__(self, state): self.foo = state['foo'] ... def __new__(cls): ... print('__new__ is called'); return super().__new__(cls) ... def __init__(self): ... print('__init__ is called'); self.foo = None; super().__init__() ... >>> c = C(); c.foo = 'bar' __new__ is called __init__ is called >>> import pickle >>> c2 = pickle.loads(pickle.dumps(c)) __new__ is called >>> c2.foo 'bar' ---------- assignee: docs at python components: Documentation messages: 271465 nosy: docs at python, july priority: normal severity: normal status: open title: pickle documentation says that unpickling may not call __new__ versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 13:41:02 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 Jul 2016 17:41:02 +0000 Subject: [issue24214] UTF-8 incremental decoder doesn't support surrogatepass correctly In-Reply-To: <1431816994.33.0.797161516902.issue24214@psf.upfronthosting.co.za> Message-ID: <1469641262.57.0.42113662029.issue24214@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka stage: -> patch review versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 13:59:04 2016 From: report at bugs.python.org (Stefan Behnel) Date: Wed, 27 Jul 2016 17:59:04 +0000 Subject: [issue18304] ElementTree -- provide a way to ignore namespace in tags and seaches In-Reply-To: <1372218497.28.0.26294900817.issue18304@psf.upfronthosting.co.za> Message-ID: <1469642344.58.0.410472937719.issue18304@psf.upfronthosting.co.za> Stefan Behnel added the comment: Here is a proposed patch for a new function "strip_namespaces(tree)" that discards all namespaces from tags and attributes in a (sub-)tree, so that subsequent processing does not have to deal with them. The "__all__" test is failing (have to figure out how to fix that), and docs are missing (it's only a proposal for now). Comments welcome. ---------- keywords: +patch versions: +Python 3.6 -Python 3.4 Added file: http://bugs.python.org/file43912/etree_strip_namespaces.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 14:41:04 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 27 Jul 2016 18:41:04 +0000 Subject: [issue27624] unclear documentation on Queue.qsize() In-Reply-To: <1469538053.41.0.353171937214.issue27624@psf.upfronthosting.co.za> Message-ID: <1469644864.76.0.0917068252597.issue27624@psf.upfronthosting.co.za> R. David Murray added the comment: The current wording is, IMO, better than the suggested wording, especially if you don't want to be "teaching stuff". The current wording is a specification of the method's behavior. I really don't know what you could replace "approximate" with that would improve it without having to get into a description of the behavior of a threaded program. It seems like you are wanting us to document that the function will return an accurate size if the program is single threaded, but I don't think we want to do that, because that is not part of the specification of the method. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 14:55:24 2016 From: report at bugs.python.org (Doug Hoskisson) Date: Wed, 27 Jul 2016 18:55:24 +0000 Subject: [issue27624] unclear documentation on Queue.qsize() In-Reply-To: <1469538053.41.0.353171937214.issue27624@psf.upfronthosting.co.za> Message-ID: <1469645724.67.0.972364911222.issue27624@psf.upfronthosting.co.za> Doug Hoskisson added the comment: It is inconsistent with other documentation right next to it. Should the documentation for empty() say "Return True if the queue is approximately empty, False otherwise."? Should the documentation for full() say "Return True if the queue is approximately full, False otherwise."? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 14:59:45 2016 From: report at bugs.python.org (Doug Hoskisson) Date: Wed, 27 Jul 2016 18:59:45 +0000 Subject: [issue27624] unclear documentation on Queue.qsize() In-Reply-To: <1469538053.41.0.353171937214.issue27624@psf.upfronthosting.co.za> Message-ID: <1469645985.43.0.579953606883.issue27624@psf.upfronthosting.co.za> Doug Hoskisson added the comment: If the specification of the empty method is to return whether the queue is empty, then the programmers have failed to meet that specification, because by the time you get that return value, it might not be empty anymore. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 15:04:53 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 27 Jul 2016 19:04:53 +0000 Subject: [issue27624] unclear documentation on Queue.qsize() In-Reply-To: <1469538053.41.0.353171937214.issue27624@psf.upfronthosting.co.za> Message-ID: <1469646293.76.0.690768085241.issue27624@psf.upfronthosting.co.za> R. David Murray added the comment: The subsequent text specifies the behavior. You *could* delete the 'approximately' from the qsize documentation to be parallel, but I think that would be a disservice to the reader. You could also use the phrase "at the moment of the call" in all three, which might be acceptable. Let's see what Raymond has to say, when he has time to respond. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 15:40:41 2016 From: report at bugs.python.org (Doug Hoskisson) Date: Wed, 27 Jul 2016 19:40:41 +0000 Subject: [issue27624] unclear documentation on Queue.qsize() In-Reply-To: <1469538053.41.0.353171937214.issue27624@psf.upfronthosting.co.za> Message-ID: <1469648441.39.0.554786795426.issue27624@psf.upfronthosting.co.za> Doug Hoskisson added the comment: My suggestion was not to delete the "approximate" entirely. Just move it out of the first sentence to make it more consistent with the other documentation. This is the model I'm seeing in empty() and full(): The first sentence is something simple and direct (without nebulous words that will make people wonder what it means), and then after that, comment on the race-condition stuff. I think that documentation is good, and it would be good to follow the same model for qsize(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 15:47:37 2016 From: report at bugs.python.org (Stefan Behnel) Date: Wed, 27 Jul 2016 19:47:37 +0000 Subject: [issue18304] ElementTree -- provide a way to ignore namespace in tags and seaches In-Reply-To: <1469642344.58.0.410472937719.issue18304@psf.upfronthosting.co.za> Message-ID: Stefan Behnel added the comment: On second thought, I think it should be supported (also?) in the parser. Otherwise, using it with an async parser would be different from (and more involved than) one-shot parsing. That seems wrong. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 15:54:36 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 27 Jul 2016 19:54:36 +0000 Subject: [issue27624] unclear documentation on Queue.qsize() In-Reply-To: <1469538053.41.0.353171937214.issue27624@psf.upfronthosting.co.za> Message-ID: <1469649276.28.0.0562202548688.issue27624@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: docs at python -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 17:26:26 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 27 Jul 2016 21:26:26 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <1469654786.12.0.223220643907.issue24773@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: It looks like Ruby folks encountered the Morocco issue [1] before us. They closed the issue on their bug tracker blaming glibc. This tells us, I guess, that we should skip this transition on the affected systems. Unfortunately, it is not just 32-bit time_t systems - I was able to reproduce the problem on 64-bit Fedora 22. If no one suggests a better way, I will just skip year 2037 transitions unconditionally. [1]: https://github.com/tzinfo/tzinfo-data/issues/10 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 18:28:07 2016 From: report at bugs.python.org (Zachary Ware) Date: Wed, 27 Jul 2016 22:28:07 +0000 Subject: [issue23085] update internal libffi copy to 3.2.1 In-Reply-To: <1418922803.63.0.55729998299.issue23085@psf.upfronthosting.co.za> Message-ID: <1469658487.02.0.0371790673729.issue23085@psf.upfronthosting.co.za> Zachary Ware added the comment: OSX and Windows are both exempt from this discussion. Each has its own private copy of an ancient version of libffi: Modules/_ctypes/libffi_osx/ and Modules/_ctypes/libffy_msvc/. I would be in favor of switching to --with-system-ffi by default for 3.6 and deprecating building with the bundled full copy of libffi (Modules/_ctypes/libffi/), to be removed in 3.7. OSX would also default to --with-system-ffi, but would still fall back to its private copy when a system copy isn't available. It seems like most Linux and BSD distributions would be better off with system-ffi. I'm not sure how cross-builds would have to deal with things in 3.7, but they already have to deal with dependencies like openssl, bz2, and lzma; adding libffi to that mix shouldn't be that big of a deal. Adding Ned to confirm that building OSX installers wouldn't be affected as long as we don't touch Modules/_ctypes/libffi_osx/ and there's not a system copy of libffi available. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 18:28:26 2016 From: report at bugs.python.org (Zachary Ware) Date: Wed, 27 Jul 2016 22:28:26 +0000 Subject: [issue23085] update internal libffi copy to 3.2.1 In-Reply-To: <1418922803.63.0.55729998299.issue23085@psf.upfronthosting.co.za> Message-ID: <1469658506.59.0.880178922058.issue23085@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 19:22:48 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 27 Jul 2016 23:22:48 +0000 Subject: [issue18304] ElementTree -- provide a way to ignore namespace in tags and seaches In-Reply-To: <1372218497.28.0.26294900817.issue18304@psf.upfronthosting.co.za> Message-ID: <1469661768.71.0.474751718682.issue18304@psf.upfronthosting.co.za> Martin Panter added the comment: Perhaps it would make more sense to use rpartition() or rstrip(). It seems possible to have a closing curly bracket in a namespace, but not in a element tag or attribute name. My guess is the __all__ failure is just a sign to add the new function to the __all__ variable at the top of the module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 20:47:55 2016 From: report at bugs.python.org (Lucas Morales) Date: Thu, 28 Jul 2016 00:47:55 +0000 Subject: [issue27623] int.to_bytes() and int.from_bytes(): raise ValueError when bytes count is zero In-Reply-To: <1469514380.74.0.642597369558.issue27623@psf.upfronthosting.co.za> Message-ID: <1469666875.89.0.431049078074.issue27623@psf.upfronthosting.co.za> Lucas Morales added the comment: This is actually a problem in Objects/longobject.c, in the _PyLong_AsByteArray function. It should have given an overflow error, because -1 cannot be encoded in 0 bytes. ---------- nosy: +lucasem _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 21:20:04 2016 From: report at bugs.python.org (Anders Lorentsen) Date: Thu, 28 Jul 2016 01:20:04 +0000 Subject: [issue27623] int.to_bytes() and int.from_bytes(): raise ValueError when bytes count is zero In-Reply-To: <1469514380.74.0.642597369558.issue27623@psf.upfronthosting.co.za> Message-ID: <1469668804.38.0.494910170245.issue27623@psf.upfronthosting.co.za> Changes by Anders Lorentsen : ---------- nosy: +Phaqui _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 21:33:50 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 28 Jul 2016 01:33:50 +0000 Subject: [issue27490] Do not run pgen when it is not going to be used (cross-compiling) In-Reply-To: <1468276938.3.0.370267656827.issue27490@psf.upfronthosting.co.za> Message-ID: <20160728013346.19971.22730.D0EDEF5F@psf.io> Roundup Robot added the comment: New changeset c6476003e67f by Martin Panter in branch '3.5': Issue #27490: Do not build pgen when cross-compiling https://hg.python.org/cpython/rev/c6476003e67f New changeset 98df00834c58 by Martin Panter in branch 'default': Issue #27490: Merge pgen cross-compile logic from 3.5 https://hg.python.org/cpython/rev/98df00834c58 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 21:33:50 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 28 Jul 2016 01:33:50 +0000 Subject: [issue27626] Spelling fixes In-Reply-To: <1469548433.15.0.911548060088.issue27626@psf.upfronthosting.co.za> Message-ID: <20160728013346.19971.31345.19F13E72@psf.io> Roundup Robot added the comment: New changeset 6080d720cbf5 by Martin Panter in branch '3.5': Issue #27626: Spelling fixes in docs, comments and internal names https://hg.python.org/cpython/rev/6080d720cbf5 New changeset 3f337cce758c by Martin Panter in branch 'default': Issue #27626: Merge spelling fixes from 3.5 https://hg.python.org/cpython/rev/3f337cce758c New changeset e12dee34deae by Martin Panter in branch 'default': Issue #27626: Further spelling fixes for 3.6 https://hg.python.org/cpython/rev/e12dee34deae ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 21:36:35 2016 From: report at bugs.python.org (Anders Lorentsen) Date: Thu, 28 Jul 2016 01:36:35 +0000 Subject: [issue27623] int.to_bytes() and int.from_bytes(): raise ValueError when bytes count is zero In-Reply-To: <1469514380.74.0.642597369558.issue27623@psf.upfronthosting.co.za> Message-ID: <1469669795.83.0.234898683854.issue27623@psf.upfronthosting.co.za> Anders Lorentsen added the comment: Isn't it possible to just add a small line of code that checks if length is less than or equal to 0, and if it is, call the necessary c functions to have python raise a valueerror...? Sorry if this is giving a solution without actually submitting the patch - but this is all very new to me. I have never contributed to anything yet (fourth year CS-student), and I am as fresh to the process as can be. I registered here just now. This seems like an issue I could handle.. I just need to take the time to learn about the process of how things are done around here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 21:43:18 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 28 Jul 2016 01:43:18 +0000 Subject: [issue27620] IDLE: Add keyboard equivalents for mouse actions. In-Reply-To: <1469494491.39.0.22722488108.issue27620@psf.upfronthosting.co.za> Message-ID: <20160728014315.79547.32170.40306D09@psf.io> Roundup Robot added the comment: New changeset 2468581846da by Terry Jan Reedy in branch 'default': Issue #27620: Mark the default action button as the default. https://hg.python.org/cpython/rev/2468581846da ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 21:46:17 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 28 Jul 2016 01:46:17 +0000 Subject: [issue27621] Finish IDLE Query dialog appearance and behavior. In-Reply-To: <1469512966.74.0.594331033204.issue27621@psf.upfronthosting.co.za> Message-ID: <1469670377.85.0.959624889121.issue27621@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I am not trying to re-invent the wheel. I am trying to bring IDLE up to uniform standards. In particular, make all dialogs usable from the keyboard. The config dialog is the worst. See #27620, the master issue. For a two button messagebox, I went back to 3.5.2, which still uses the commondialog box. It has the default button marked as such. always does the default action. always cancels. moves the focus, but does not affect the above. enters ' ' in text entry and 'clicks' buttons. So this is at least 'a' Windows standard, as well as 'a' Mac standard. The search dialogs act the same. The space behavior built-in to the TK widgets, at least on Windows. I presume this is a class binding. The dialogs have no platform specific code, so they are also the defacto IDLE standard. Serhiy, it is definitely a tk convention, and I presume more universal than that, that the 'default ring' always indicate what button/action is invoked by . If the default moved with the focus, the default ring should move also. I am not inclined to do that without a strong reason. The button default ring is controlled by the 'default' option" 'active' = visible, 'normal' = possible, 'disabled' = not possible. (From the tk docs. The NMT reference is useless here.) I will add "default='active'" for the Ok button. (Mark: "default=1", suggested on http://www.tkdocs.com/widgets/button.html, is a nasty bug. "_tkinter.TclError: bad default "1": must be normal, active, or disabled".) ---------- title: incorrectly works in IDLE Query dialogs -> Finish IDLE Query dialog appearance and behavior. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 21:49:56 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 28 Jul 2016 01:49:56 +0000 Subject: [issue27621] Finish IDLE Query dialog appearance and behavior. In-Reply-To: <1469512966.74.0.594331033204.issue27621@psf.upfronthosting.co.za> Message-ID: <1469670596.23.0.294842705736.issue27621@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I meant to direct the focus ring fix here instead #27620. To me, this issue is done, at least for now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 22:17:30 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 28 Jul 2016 02:17:30 +0000 Subject: [issue27620] IDLE: Add keyboard equivalents for mouse actions. In-Reply-To: <1469494491.39.0.22722488108.issue27620@psf.upfronthosting.co.za> Message-ID: <20160728021727.94891.52358.AC90FEB7@psf.io> Roundup Robot added the comment: New changeset e4a2d78aa6cc by Terry Jan Reedy in branch 'default': Issue #27620: Make htest box respond to and . https://hg.python.org/cpython/rev/e4a2d78aa6cc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 22:28:38 2016 From: report at bugs.python.org (Emanuel Barry) Date: Thu, 28 Jul 2016 02:28:38 +0000 Subject: [issue27623] int.to_bytes() and int.from_bytes(): raise ValueError when bytes count is zero In-Reply-To: <1469514380.74.0.642597369558.issue27623@psf.upfronthosting.co.za> Message-ID: <1469672918.06.0.454432037055.issue27623@psf.upfronthosting.co.za> Emanuel Barry added the comment: Here's a patch that fixes this. ---------- components: +Interpreter Core -Library (Lib) keywords: +patch nosy: +ebarry stage: -> patch review Added file: http://bugs.python.org/file43913/int_to_bytes_overflow_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 22:30:45 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Thu, 28 Jul 2016 02:30:45 +0000 Subject: [issue26942] android: test_ctypes crashes on armv7 and aarch64 In-Reply-To: <1462290789.53.0.483745295219.issue26942@psf.upfronthosting.co.za> Message-ID: <1469673045.72.0.64645104958.issue26942@psf.upfronthosting.co.za> Changes by Chi Hsuan Yen : ---------- title: android: test_ctypes crashes on armv7 -> android: test_ctypes crashes on armv7 and aarch64 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 23:03:24 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Thu, 28 Jul 2016 03:03:24 +0000 Subject: [issue27623] int.to_bytes() and int.from_bytes(): raise ValueError when bytes count is zero In-Reply-To: <1469514380.74.0.642597369558.issue27623@psf.upfronthosting.co.za> Message-ID: <1469675004.5.0.723838387862.issue27623@psf.upfronthosting.co.za> ???? ????????? added the comment: I think, we should deny: * Passing `0` to `to_bytes` (even if integer is equal to zero) * Passing empty string to `from_bytes` I do not see any use cases for this to work. It was never guaranteed to work earlier. Everyone pass constant to `to_bytes` that is > 0. And passing empty buffer to `from_bytes` just indicate error in logic (i.e. something was not read correctly from file/socket e.t.c). `struct.pack`/`unpack` does not support zero-byte types. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 23:04:28 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 28 Jul 2016 03:04:28 +0000 Subject: [issue27636] Refactor IDLE htest Message-ID: <1469675068.09.0.412407912627.issue27636@psf.upfronthosting.co.za> New submission from Terry J. Reedy: idlelib.idle_test.htest Extract a App(Tk) subclass from run function and nested function. Pass that as master instead of bare root. Extract HTest(Toplevel) class with the common code in files with an htest function. Attach HTest to App as an attribute so htest functions can instantiate or subclass. ---------- assignee: terry.reedy components: IDLE messages: 271486 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: Refactor IDLE htest type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 23:13:12 2016 From: report at bugs.python.org (Emanuel Barry) Date: Thu, 28 Jul 2016 03:13:12 +0000 Subject: [issue27623] int.to_bytes() and int.from_bytes(): raise ValueError when bytes count is zero In-Reply-To: <1469514380.74.0.642597369558.issue27623@psf.upfronthosting.co.za> Message-ID: <1469675592.73.0.380097556694.issue27623@psf.upfronthosting.co.za> Emanuel Barry added the comment: I don't use this feature enough to have a clear opinion, however it's specifically accounted for in the code and has a test for it. It might be a good idea to bring this up on Python-ideas. It's very likely to break some code, but I wonder if said code wasn't already broken to begin with :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 23:15:12 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Thu, 28 Jul 2016 03:15:12 +0000 Subject: [issue27637] int.to_bytes(-1, ...) should automatically choose required count of bytes Message-ID: <1469675712.56.0.174576481029.issue27637@psf.upfronthosting.co.za> New submission from ???? ?????????: It will be nice if `int.to_bytes` be able to automatically choose number of bytes to serialize. If so, I could write serialisation code: def serialize(value: int, signed=True) -> bytes: x = value.to_bytes(-1, 'big', signed=signed) l = value.to_bytes(4, 'big', signed=False) return l + x assert len(serialize(0)) == 4 + 0 # see Issue27623 assert len(serialize(120)) == 4 + 1 assert len(serialize(130)) == 4 + 2 assert len(serialize(130), False) == 4 + 1 ---------- components: Library (Lib) messages: 271488 nosy: mmarkk priority: normal severity: normal status: open title: int.to_bytes(-1, ...) should automatically choose required count of bytes type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 23:16:34 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Thu, 28 Jul 2016 03:16:34 +0000 Subject: [issue27637] int.to_bytes(-1, ...) should automatically choose required count of bytes In-Reply-To: <1469675712.56.0.174576481029.issue27637@psf.upfronthosting.co.za> Message-ID: <1469675794.03.0.670594202487.issue27637@psf.upfronthosting.co.za> ???? ????????? added the comment: Oops. def serialize(value: int, signed=True) -> bytes: x = value.to_bytes(-1, 'big', signed=signed) l = len(x).to_bytes(4, 'big', signed=False) return l + x assert len(serialize(0)) == 4 + 0 # see Issue27623 assert len(serialize(120)) == 4 + 1 assert len(serialize(130)) == 4 + 2 assert len(serialize(130), False) == 4 + 1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 23:32:33 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Thu, 28 Jul 2016 03:32:33 +0000 Subject: [issue27638] int.to_bytes() and int.from_bytes() should support 'net' and 'host' byte orders Message-ID: <1469676753.14.0.293041836709.issue27638@psf.upfronthosting.co.za> New submission from ???? ?????????: int.to_bytes() and int.from_bytes() should support 'net' and 'host' byte orders. I will provide a patch. ---------- messages: 271490 nosy: mmarkk priority: normal severity: normal status: open title: int.to_bytes() and int.from_bytes() should support 'net' and 'host' byte orders _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 23:32:51 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Thu, 28 Jul 2016 03:32:51 +0000 Subject: [issue27638] int.to_bytes() and int.from_bytes() should support 'net' and 'host' byte orders In-Reply-To: <1469676753.14.0.293041836709.issue27638@psf.upfronthosting.co.za> Message-ID: <1469676771.14.0.585902623485.issue27638@psf.upfronthosting.co.za> Changes by ???? ????????? : ---------- components: +Library (Lib) type: -> enhancement versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 00:12:57 2016 From: report at bugs.python.org (Emanuel Barry) Date: Thu, 28 Jul 2016 04:12:57 +0000 Subject: [issue27638] int.to_bytes() and int.from_bytes() should support 'net' and 'host' byte orders In-Reply-To: <1469676753.14.0.293041836709.issue27638@psf.upfronthosting.co.za> Message-ID: <1469679176.99.0.570701488758.issue27638@psf.upfronthosting.co.za> Emanuel Barry added the comment: Since this is a new feature addition, this should first go through Python-ideas. However, I don't think that network-related features should go into builtin types, -1 from me. ---------- nosy: +ebarry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 00:20:04 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 28 Jul 2016 04:20:04 +0000 Subject: [issue27490] Do not run pgen when it is not going to be used (cross-compiling) In-Reply-To: <1468276938.3.0.370267656827.issue27490@psf.upfronthosting.co.za> Message-ID: <20160728042002.21097.74837.0ED66D2F@psf.io> Roundup Robot added the comment: New changeset ec27886f675f by Martin Panter in branch '2.7': Issue #27490: Do not build pgen when cross-compiling https://hg.python.org/cpython/rev/ec27886f675f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 00:20:05 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 28 Jul 2016 04:20:05 +0000 Subject: [issue23943] Misspellings in a few files In-Reply-To: <1428975576.21.0.663921788116.issue23943@psf.upfronthosting.co.za> Message-ID: <20160728042002.21097.53589.76741335@psf.io> Roundup Robot added the comment: New changeset b0addbbc7671 by Martin Panter in branch '2.7': Issue #23943: Fix typos. Patch by Piotr Kasprzyk. https://hg.python.org/cpython/rev/b0addbbc7671 New changeset 48f074e2afcf by Martin Panter in branch '3.5': Issue #23943: Restore extra fixes lost in merge 4fb2075952a4 https://hg.python.org/cpython/rev/48f074e2afcf New changeset 0026d94d45e6 by Martin Panter in branch 'default': Issue #23943: Merge spelling fixes from 3.5 https://hg.python.org/cpython/rev/0026d94d45e6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 00:20:06 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 28 Jul 2016 04:20:06 +0000 Subject: [issue27626] Spelling fixes In-Reply-To: <1469548433.15.0.911548060088.issue27626@psf.upfronthosting.co.za> Message-ID: <20160728042002.21097.47357.4A1FFB41@psf.io> Roundup Robot added the comment: New changeset c8c1ea94379a by Martin Panter in branch '2.7': Issue #27626: Spelling fixes in docs, comments and internal names https://hg.python.org/cpython/rev/c8c1ea94379a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 00:32:55 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 28 Jul 2016 04:32:55 +0000 Subject: [issue27490] Do not run pgen when it is not going to be used (cross-compiling) In-Reply-To: <1468276938.3.0.370267656827.issue27490@psf.upfronthosting.co.za> Message-ID: <1469680375.34.0.634981998481.issue27490@psf.upfronthosting.co.za> Martin Panter added the comment: FWIW I suspect this technique could be expanded to prevent Programs/_freeze_importlib from being cross-compiled, if anyone was interested. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 00:37:21 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 28 Jul 2016 04:37:21 +0000 Subject: [issue18304] ElementTree -- provide a way to ignore namespace in tags and searches In-Reply-To: <1372218497.28.0.26294900817.issue18304@psf.upfronthosting.co.za> Message-ID: <1469680641.09.0.827889578623.issue18304@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- title: ElementTree -- provide a way to ignore namespace in tags and seaches -> ElementTree -- provide a way to ignore namespace in tags and searches _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 00:50:39 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 28 Jul 2016 04:50:39 +0000 Subject: [issue27638] int.to_bytes() and int.from_bytes() should support 'net' and 'host' byte orders In-Reply-To: <1469676753.14.0.293041836709.issue27638@psf.upfronthosting.co.za> Message-ID: <1469681439.32.0.536283281317.issue27638@psf.upfronthosting.co.za> Martin Panter added the comment: I wouldn?t mind the ?host? byte order, assuming it just means use sys.byteorder. I think I have done this a few times, both when I really wanted the native byte order, and when I didn?t care, but assumed the native order might be slightly more efficient (e.g. bitwise arithmetic on 512-byte blocks). But I don?t understand the point of ?net? byte order. Wouldn?t it be the same as ?big?? ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 00:52:39 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 28 Jul 2016 04:52:39 +0000 Subject: [issue27638] int.to_bytes() and int.from_bytes() should support 'net' and 'host' byte orders In-Reply-To: <1469676753.14.0.293041836709.issue27638@psf.upfronthosting.co.za> Message-ID: <1469681559.37.0.616672619555.issue27638@psf.upfronthosting.co.za> Berker Peksag added the comment: There is no need to go to python-ideas for this. Adding domain experts to nosy list is enough. ---------- nosy: +berker.peksag, mark.dickinson, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 00:59:08 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 28 Jul 2016 04:59:08 +0000 Subject: [issue27637] int.to_bytes(-1, ...) should automatically choose required count of bytes In-Reply-To: <1469675712.56.0.174576481029.issue27637@psf.upfronthosting.co.za> Message-ID: <1469681948.79.0.826041534656.issue27637@psf.upfronthosting.co.za> Martin Panter added the comment: I don?t like special values. A length of minus one makes no sense, so should trigger an exception, not some unexpected behaviour. A different data type like None would be a bit better. But I?m not sure this would be widely used. If you really need it you could calculate the number of bytes needed via value.bit_length(). ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 01:11:25 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 28 Jul 2016 05:11:25 +0000 Subject: [issue27623] int.to_bytes() and int.from_bytes(): raise ValueError when bytes count is zero In-Reply-To: <1469514380.74.0.642597369558.issue27623@psf.upfronthosting.co.za> Message-ID: <1469682685.65.0.838583059329.issue27623@psf.upfronthosting.co.za> Martin Panter added the comment: I agree that the signed conversion cases should be an error. However the unsigned case would break working code that I have written for bijective numeration. See _bytes_to_int() and _int_to_bytes() in Issue 20132, inc-codecs.diff, for example. Since non-zero unsigned conversions work by converting N bytes <-> 0 <= value < 2^N For N = 0, there is only one possible value, 0. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 01:13:42 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 28 Jul 2016 05:13:42 +0000 Subject: [issue27626] Spelling fixes In-Reply-To: <1469548433.15.0.911548060088.issue27626@psf.upfronthosting.co.za> Message-ID: <1469682822.1.0.35009093264.issue27626@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for the patch ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 01:51:53 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 28 Jul 2016 05:51:53 +0000 Subject: [issue17605] mingw-meta: build interpeter core In-Reply-To: <1364762524.12.0.901415822586.issue17605@psf.upfronthosting.co.za> Message-ID: <1469685113.16.0.752808629311.issue17605@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- dependencies: +mingw: use main() to start execution _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 02:03:36 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Jul 2016 06:03:36 +0000 Subject: [issue27638] int.to_bytes() and int.from_bytes() should support 'net' and 'host' byte orders In-Reply-To: <1469676753.14.0.293041836709.issue27638@psf.upfronthosting.co.za> Message-ID: <1469685816.35.0.90778274358.issue27638@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I agreed with Martin. The "host" byte order is sys.byteorder, and the "net" byteorder is just "big". There is one obvious way to specify this, and there is not need to add yet one way. Adding support of new values for byteorder would complicate and slow down the code. int.to_bytes() and int.from_bytes() already are slower then struct.pack() and struct.unpack(), and parsing the byteorder argument is the main culprit here (see also issue27574). I'm for rejecting this idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 02:14:51 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Jul 2016 06:14:51 +0000 Subject: [issue27637] int.to_bytes(-1, ...) should automatically choose required count of bytes In-Reply-To: <1469675712.56.0.174576481029.issue27637@psf.upfronthosting.co.za> Message-ID: <1469686491.03.0.951776641782.issue27637@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is rarely needed, mainly in general serializers like pickle. The code for determining the minimal number of bytes is not trivial, but it depends on the serializer. If you always serialize unsigned values and saves the sign separately, or use one's complement represenatation, or if the serializer supports only fixed set of integer sizes, the code is absolutely different. I don't think that we need this feature in the stdlib. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 02:15:07 2016 From: report at bugs.python.org (Anton Backer) Date: Thu, 28 Jul 2016 06:15:07 +0000 Subject: [issue27639] UserList.__getitem__ doesn't account for slices Message-ID: <1469686507.89.0.362648270021.issue27639@psf.upfronthosting.co.za> New submission from Anton Backer: The docs for UserList say: > List operations which return a new sequence attempt to create an instance of the actual implementation class. However, UserList([])[:] returns a list, not a UserList. ---------- components: Library (Lib) files: patch messages: 271503 nosy: staticshock priority: normal severity: normal status: open title: UserList.__getitem__ doesn't account for slices type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file43914/patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 02:17:34 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Jul 2016 06:17:34 +0000 Subject: [issue27623] int.to_bytes() and int.from_bytes(): raise ValueError when bytes count is zero In-Reply-To: <1469514380.74.0.642597369558.issue27623@psf.upfronthosting.co.za> Message-ID: <1469686654.75.0.932627369106.issue27623@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I agree with Martin. The ambiguous signed conversion cases should be an error, the unambiguous unsigned conversion case should be supported (especially if there are tests for this). ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 02:18:32 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Jul 2016 06:18:32 +0000 Subject: [issue27639] UserList.__getitem__ doesn't account for slices In-Reply-To: <1469686507.89.0.362648270021.issue27639@psf.upfronthosting.co.za> Message-ID: <1469686712.72.0.652279122803.issue27639@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> rhettinger nosy: +rhettinger, serhiy.storchaka priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 02:22:51 2016 From: report at bugs.python.org (Anton Backer) Date: Thu, 28 Jul 2016 06:22:51 +0000 Subject: [issue27639] UserList.__getitem__ doesn't account for slices In-Reply-To: <1469686507.89.0.362648270021.issue27639@psf.upfronthosting.co.za> Message-ID: <1469686971.27.0.367990630666.issue27639@psf.upfronthosting.co.za> Changes by Anton Backer : ---------- hgrepos: +351 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 02:42:54 2016 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Thu, 28 Jul 2016 06:42:54 +0000 Subject: [issue27590] tarfile module next() method hides exceptions In-Reply-To: <1469200266.16.0.443973453456.issue27590@psf.upfronthosting.co.za> Message-ID: <1469688174.66.0.558714821416.issue27590@psf.upfronthosting.co.za> Lars Gust?bel added the comment: After all these years, it is not that easy to say why the decision to swallow this exception was made. One part surely was a lack of experience with the tar format itself and all of its implementations. The other part I guess was that it was supposed to avoid problems in case users did not use TarFile as an iterator. tarfile was developed on Python 2.2 which was the first release to feature iterators. The problem if you do random access on a tarfile or call TarFile.getmembers() is that first of all all the headers must be collected. If this fails somewhere in the middle, there is no way to resume the current operation and you get nothing out of the archive. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 03:27:09 2016 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 28 Jul 2016 07:27:09 +0000 Subject: [issue27623] int.to_bytes() and int.from_bytes(): raise ValueError when bytes count is zero In-Reply-To: <1469514380.74.0.642597369558.issue27623@psf.upfronthosting.co.za> Message-ID: <1469690829.6.0.24748907959.issue27623@psf.upfronthosting.co.za> Mark Dickinson added the comment: > The ambiguous signed conversion cases should be an error, the unambiguous unsigned conversion case should be supported +1. A signed representation *requires* 1 bit for the sign (regardless of whether the number being represented is negative or nonnegative), so it should be an error to encode into zero bytes. But there's nothing wrong with trying to encode 0 in zero bytes when using an unsigned representation. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 03:39:57 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 28 Jul 2016 07:39:57 +0000 Subject: [issue26462] Patch to enhance literal block language declaration In-Reply-To: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za> Message-ID: <1469691597.15.0.900909638168.issue26462@psf.upfronthosting.co.za> Changes by Martin Panter : Added file: http://bugs.python.org/file43915/issue26462.v5_regen.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 03:54:38 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Thu, 28 Jul 2016 07:54:38 +0000 Subject: [issue27637] int.to_bytes(-1, ...) should automatically choose required count of bytes In-Reply-To: <1469675712.56.0.174576481029.issue27637@psf.upfronthosting.co.za> Message-ID: <1469692478.71.0.600740710907.issue27637@psf.upfronthosting.co.za> ???? ????????? added the comment: https://github.com/pyca/cryptography/issues/3064 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 04:07:51 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 28 Jul 2016 08:07:51 +0000 Subject: [issue20947] -Wstrict-overflow findings In-Reply-To: <1394991597.86.0.942219538296.issue20947@psf.upfronthosting.co.za> Message-ID: <1469693271.58.0.582970017472.issue20947@psf.upfronthosting.co.za> Martin Panter added the comment: Regarding the warning in Modules/_posixsubprocess.c, I don?t see any problem. I?m not sure exactly what it is warning about. Maybe if the cur pointer ever gets _before_ the start of hex_errno, that could be a problem, but the loop should stop when it reaches the start. The warnings in Modules/sha512module.c refer to the first line of the sha512_transform() function. I cannot see any pointer comparisons in that function. The closest is pointer and array indexing, but it all seems to be in order. I propose to ignore these warnings. ---------- nosy: +martin.panter resolution: -> wont fix type: -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 04:30:12 2016 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 28 Jul 2016 08:30:12 +0000 Subject: [issue20947] -Wstrict-overflow findings In-Reply-To: <1394991597.86.0.942219538296.issue20947@psf.upfronthosting.co.za> Message-ID: <1469694612.0.0.515415928694.issue20947@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 04:31:45 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 28 Jul 2016 08:31:45 +0000 Subject: [issue26462] Patch to enhance literal block language declaration In-Reply-To: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za> Message-ID: <1469694705.14.0.252257810125.issue26462@psf.upfronthosting.co.za> Martin Panter added the comment: V5 looks pretty good to me. With your blessing of restoring the python -q example from v4 (see review), I think it is ready to commit. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 04:33:49 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Thu, 28 Jul 2016 08:33:49 +0000 Subject: [issue27638] int.to_bytes() and int.from_bytes() should support 'net' and 'host' byte orders In-Reply-To: <1469676753.14.0.293041836709.issue27638@psf.upfronthosting.co.za> Message-ID: <1469694829.2.0.432536596922.issue27638@psf.upfronthosting.co.za> ???? ????????? added the comment: 1. Yes 'host' is the same as sys.buteorder 2. Yes, 'net' is the same as 'big' 3. See `struct` module: it have '!' for those who forgot which order is `network`. In most cases (i.e. some protocols or formats) 'network' order is used. 4. Support of new values will actually slightly complicate code. I will say just change, not complicte. 5. This patch will add two extra string comparings. This should not slowdown current implementation significantly. I can benchmark it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 05:27:23 2016 From: report at bugs.python.org (Julien) Date: Thu, 28 Jul 2016 09:27:23 +0000 Subject: [issue26462] Patch to enhance literal block language declaration In-Reply-To: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za> Message-ID: <1469698043.6.0.168902689051.issue26462@psf.upfronthosting.co.za> Julien added the comment: Hi, You're right, nice catch! Removing `python -q` from the code block demonstrating it was a bad idea. I fixed it in the v6. Thanks! ---------- Added file: http://bugs.python.org/file43916/issue26462.v6.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 05:44:39 2016 From: report at bugs.python.org (Michael Felt) Date: Thu, 28 Jul 2016 09:44:39 +0000 Subject: [issue9998] ctypes find_library should search LD_LIBRARY_PATH on linux In-Reply-To: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za> Message-ID: <1469699079.01.0.618280158072.issue9998@psf.upfronthosting.co.za> Michael Felt added the comment: Getting back to this summary: Windows: {name} and {name}.dll, via %PATH% OS X: lib{name}.dylib, {name}.dylib and {name}.framework/{name}, via dyld_find() BSD: lib{name}.* via ldconfig (choose highest ABI version) and cc Solaris: lib{name}.so via crle, and lib{name}.* via cc Gnu: lib{name}.* via ldconfig and cc The "Gnu" selection is what is used for "None of the above", so also for AIX - which generally has neither ldconfig nor cc installed. Having worked on a patch for AIX so that something that is (aka should) always there (dump) for examining archives for dlopen() openable objects. In another issue I have had the benefit of lots of feedback from Martin Panter - most of which I agree with. As this issue is about enhancement my feedback re: AIX behavior of dlopen() is that dlopen() takes LD_LIBRARY_PATH (when LIBPATH is not defined) into account. In general find_library() is used as: CDLL(find_library("xxx")) - as in I do not care if the result is None or libxxx.so.y.z - just do it. However, if find_library() and CDLL() are written so that they "find" the same library object then it does become possible for a programmer to verify that a supported version is what will be loaded. The return value from find_library() should be related to it's argument - just as dlopen() would 'react' (better, search *PATH*). If no path element ("./*" | "../*", or "/*") then no path element should be in the return value. The case for using path elements is because find_library() could be used to verity it's existence before calling CDLL() - what I did not know initially, but consider vital for proper behavior is that CDLL(NULL) just returns 'python' itself. To underline that there are many issues that have been left unaddressed for years (this discussion here is nearly 6 years old) I mention: "The case of python calling find_library("uuid") - on AIX this is probably NULL, as libuuid.so(.X) is not native to AIX - and even if it is present will not be found via a non-existent ldconfig or cc (only thing the "Gnu" option even considers). IMHO: find_library should reflect dlopen() - with find_library being, as documented. >From the Python2.6 documentation (when introduced?) """The purpose of the find_library() function is to locate a library in a way similar to what the compiler does (on platforms with several versions of a shared library the most recent should be loaded), while the ctypes library loaders act like when a program is run, and call the runtime loader directly. The ctypes.util module provides a function which can help to determine the library to load. ctypes.util.find_library(name) Try to find a library and return a pathname. name is the library name without any prefix like lib, suffix like .so, .dylib or version number (this is the form used for the posix linker option -l). If no library can be found, returns None. The exact functionality is system dependent.""" This pre-dates my experience with python, so if I inaccurate in assumptions - correct me, but please be patient with me. What I miss is a PEP on this topic. From the limited reads of other PEPs I have read I think (rather hope) that inconsistencies in documentation could have been caught. While (as Martin mentioned earlier in this discussion) find_library() behaves as "build" aka cc/gcc and CDLL follows "run-time" loader. imho, this is inconsistent - and the inconsistency is also in that short bit of documentation: a) """The purpose of the find_library() function is to locate a library in a way similar to what the compiler does (on platforms with several versions of a shared library the most recent should be loaded) (i.e., always find the latest version)""" and b)"""The ctypes.util module provides a function which can help to determine the library to load.""" IMHO: how it is expected to be used because I (i.e., the python programmer) cannot provide additional specification to locate a specific version - find_library() is meant to find the latest always As the Python3.5.2 documentation is nearly verbatim - this is still the documented condition. So - I am very happy about Martin's (partial) comment: maybe changing towards run-time would not be such a problem as I first thought. CDLL() does a search, by definition. Maybe I do not care what it finds - but the argument to it is expected to platform dependent. The "remaining" limitation of find_library(), even with searching *PATH* included is that it MUST also return the latest version (as a request for a specific version may not be made, or any other "extension"). An additional weakness is that what it "finds" must always be prefixed by "lib", while dlopen() has not such requirement. (FYI: I ran into these 'unusual' shared libraries while packaging sudo. While it is unlikely that python would ever load these sudo libraries it does show that there can be shared libraries that can accessed by not "found") Hoping this helps the discussion - would be good to have at least a definition/documentation change so that decisions can be made. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 05:51:41 2016 From: report at bugs.python.org (Michael Felt) Date: Thu, 28 Jul 2016 09:51:41 +0000 Subject: [issue27435] ctypes and AIX - also for 2.7.X (and later) In-Reply-To: <1467383699.63.0.495142233463.issue27435@psf.upfronthosting.co.za> Message-ID: <1469699501.28.0.576674831643.issue27435@psf.upfronthosting.co.za> Michael Felt added the comment: Adding "type behavior" as I have now read that that is actually the python friendly way of talking about a 'bug'. Testing my proposed patch for 2.7 with python2.7.12 - will update with patch when finished. ---------- nosy: +Michael.Felt type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 06:05:18 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 28 Jul 2016 10:05:18 +0000 Subject: [issue27640] add the '--disable-test-suite' option to configure Message-ID: <1469700317.99.0.84265252625.issue27640@psf.upfronthosting.co.za> New submission from Xavier de Gaye: Do not install the Python test suite when configure is run with '--disable-test-suite'. This about divides by two the size of the installed standard library. Related to issue 26852: add the '--enable-legacy-pyc-files' option to configure. The attached listdirs.py script may be used to check that the set of sub-directories in the std library is not changed by the patch. ---------- assignee: xdegaye components: Build files: disable-test-suite.patch keywords: patch messages: 271514 nosy: doko, martin.panter, xdegaye priority: normal severity: normal stage: patch review status: open title: add the '--disable-test-suite' option to configure type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43917/disable-test-suite.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 06:05:29 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 28 Jul 2016 10:05:29 +0000 Subject: [issue27640] add the '--disable-test-suite' option to configure In-Reply-To: <1469700317.99.0.84265252625.issue27640@psf.upfronthosting.co.za> Message-ID: <1469700329.43.0.361091256876.issue27640@psf.upfronthosting.co.za> Changes by Xavier de Gaye : Added file: http://bugs.python.org/file43918/listdirs.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 06:15:32 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 28 Jul 2016 10:15:32 +0000 Subject: [issue27640] add the '--disable-test-suite' option to configure In-Reply-To: <1469700317.99.0.84265252625.issue27640@psf.upfronthosting.co.za> Message-ID: <1469700932.94.0.0178699442204.issue27640@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- components: +Cross-Build nosy: +Alex.Willmer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 06:31:17 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 28 Jul 2016 10:31:17 +0000 Subject: [issue26852] add the '--enable-legacy-pyc-files' option to configure In-Reply-To: <1461674611.23.0.732409522866.issue26852@psf.upfronthosting.co.za> Message-ID: <1469701877.75.0.304423316153.issue26852@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Install byte-code files to their legacy locations and names to save space (default are the PEP 3147 locations and names) when configure is run with '--enable-legacy-pyc-files'. The patch does not prevent ensurepip to use PEP 3147 locations and names when it is run at the end of the installation. As many tests use the linecache module, it makes sense to skip the installation of the test suite aas well since the patch removes all *.py files (except those installed by ensurepip in site-packages). This can be done when issue 27640 is resolved by using '--disable-test-suite'. The size of the standard library [1] [2]: plain install: 111M --disable-test-suite: 53M --enable-legacy-pyc-files --disable-test-suite: 23M --enable-legacy-pyc-files --disable-test-suite --with-ensurepip=no: 14M [1] without the extension modules [2] excluding the LIBPL directory that is installed at --prefix instead of --exec-prefix for some reason and that contains miscellaneous stuff needed for extending/embedding. This is not needed on a mobile device that does not have any build tool. ---------- components: +Build nosy: +doko, martin.panter stage: -> patch review title: android: add a COMPILEALL_FLAGS Makefile variable -> add the '--enable-legacy-pyc-files' option to configure Added file: http://bugs.python.org/file43919/legacy-pyc-files.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 06:34:30 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 28 Jul 2016 10:34:30 +0000 Subject: [issue26865] Meta-issue: support of the android platform In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za> Message-ID: <1469702070.31.0.159416537033.issue26865@psf.upfronthosting.co.za> Xavier de Gaye added the comment: issue #27640: add the '--disable-test-suite' option to configure ---------- dependencies: +add the '--disable-test-suite' option to configure _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 06:47:19 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 28 Jul 2016 10:47:19 +0000 Subject: [issue27640] add the '--disable-test-suite' option to configure In-Reply-To: <1469700317.99.0.84265252625.issue27640@psf.upfronthosting.co.za> Message-ID: <1469702839.4.0.0954566459328.issue27640@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- nosy: +haypo, thomas-petazzoni _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 06:47:45 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 28 Jul 2016 10:47:45 +0000 Subject: [issue26852] add the '--enable-legacy-pyc-files' option to configure In-Reply-To: <1461674611.23.0.732409522866.issue26852@psf.upfronthosting.co.za> Message-ID: <1469702865.3.0.551506205897.issue26852@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- nosy: +haypo, thomas-petazzoni _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 06:48:14 2016 From: report at bugs.python.org (Matthias Klose) Date: Thu, 28 Jul 2016 10:48:14 +0000 Subject: [issue26852] add the '--enable-legacy-pyc-files' option to configure In-Reply-To: <1461674611.23.0.732409522866.issue26852@psf.upfronthosting.co.za> Message-ID: <1469702894.73.0.887128153063.issue26852@psf.upfronthosting.co.za> Matthias Klose added the comment: hmm, I really don't buy the space-saving argument. you are saving some space with shorter path names, nothing more. so why do you introduce this option? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 06:48:26 2016 From: report at bugs.python.org (Matthias Klose) Date: Thu, 28 Jul 2016 10:48:26 +0000 Subject: [issue26852] add the '--enable-legacy-pyc-files' option to configure In-Reply-To: <1461674611.23.0.732409522866.issue26852@psf.upfronthosting.co.za> Message-ID: <1469702906.81.0.782917750746.issue26852@psf.upfronthosting.co.za> Changes by Matthias Klose : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 07:01:26 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 28 Jul 2016 11:01:26 +0000 Subject: [issue26851] android compilation and link flags In-Reply-To: <1461673211.54.0.945034926098.issue26851@psf.upfronthosting.co.za> Message-ID: <1469703686.87.0.711314483681.issue26851@psf.upfronthosting.co.za> Martin Panter added the comment: All the bits that I understand look okay now. :) I am still curious what configures the preprocessor to set __ARM_ARCH to 7 (I guess the clang -target argument?), and why we can?t set LDFLAGS at the same time or place. Is it just more convenient this way? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 07:04:44 2016 From: report at bugs.python.org (Thomas Perl) Date: Thu, 28 Jul 2016 11:04:44 +0000 Subject: [issue27641] Do not build Programs/_freeze_importlib when cross-compiling Message-ID: <1469703884.83.0.465404999691.issue27641@psf.upfronthosting.co.za> New submission from Thomas Perl: Based on http://bugs.python.org/issue27490 and http://bugs.python.org/msg271495, here is a patch that makes sure Programs/_freeze_importlib is only built when not cross-compiling. ---------- components: Cross-Build files: python-freeze-importlib-cross-compiling.patch keywords: patch messages: 271519 nosy: Alex.Willmer, Thomas Perl, martin.panter priority: normal severity: normal status: open title: Do not build Programs/_freeze_importlib when cross-compiling type: behavior versions: Python 2.7, Python 3.6 Added file: http://bugs.python.org/file43920/python-freeze-importlib-cross-compiling.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 07:12:53 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 28 Jul 2016 11:12:53 +0000 Subject: [issue26852] add the '--enable-legacy-pyc-files' option to configure In-Reply-To: <1461674611.23.0.732409522866.issue26852@psf.upfronthosting.co.za> Message-ID: <1469704373.79.0.737809258322.issue26852@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > hmm, I really don't buy the space-saving argument. you are saving some space with shorter path names, nothing more. so why do you introduce this option? No, compileall is run with '-b', so there are no PEP 3147 __pycache__ directories, and with an installation of 53M where the test suite is excluded, that saves 30M (see my previous msg). IMHO this option is very useful on mobile devices and embedded systems where space is sparse. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 07:13:27 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 28 Jul 2016 11:13:27 +0000 Subject: [issue26462] Patch to enhance literal block language declaration In-Reply-To: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za> Message-ID: <1469704407.42.0.882099581211.issue26462@psf.upfronthosting.co.za> Martin Panter added the comment: One last change I think needs making to the same demo, the ?code-block? needs indenting under the bullet point: * The interpreter can now be started with a quiet option, ``-q``, to prevent the copyright and version information from being displayed in the interactive mode. The option can be introspected using the :attr:`sys.flags` attribute: .. code-block:: shell-session <== Indented $ python -q Otherwise, it seems to include extra text in the code block. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 07:14:42 2016 From: report at bugs.python.org (Roman Evstifeev) Date: Thu, 28 Jul 2016 11:14: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: <1469704482.08.0.972641169498.issue26865@psf.upfronthosting.co.za> Roman Evstifeev added the comment: While not only android issue, there is a problem with dumbdbm module: it internally tries to do os.chmod() on a FAT-formatted sdcard and fails, because FAT does not support chmod. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 07:16:18 2016 From: report at bugs.python.org (Ned Deily) Date: Thu, 28 Jul 2016 11:16:18 +0000 Subject: [issue23085] update internal libffi copy to 3.2.1 In-Reply-To: <1418922803.63.0.55729998299.issue23085@psf.upfronthosting.co.za> Message-ID: <1469704578.56.0.627361819237.issue23085@psf.upfronthosting.co.za> Ned Deily added the comment: We should be able to make things work for OS X installer builds one way or another so don't let that be a factor. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 07:18:08 2016 From: report at bugs.python.org (Thomas Petazzoni) Date: Thu, 28 Jul 2016 11:18:08 +0000 Subject: [issue26852] add the '--enable-legacy-pyc-files' option to configure In-Reply-To: <1461674611.23.0.732409522866.issue26852@psf.upfronthosting.co.za> Message-ID: <1469704688.83.0.77687319636.issue26852@psf.upfronthosting.co.za> Thomas Petazzoni added the comment: I can also say that in the Buildroot project, we have patches to get rid of the PEP3147 stuff. Indeed, the PEP3147 forces one to have both the .py *and* the .pyc file for a given module. If you have only the .pyc file, Python does not recognize it and it cannot be imported. By removing the PEP3147 functionality, we are able to keep only the .pyc files on the target, therefore dividing roughly by two the size of the Python installation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 07:18:44 2016 From: report at bugs.python.org (Thomas Petazzoni) Date: Thu, 28 Jul 2016 11:18:44 +0000 Subject: [issue26852] add the '--enable-legacy-pyc-files' option to configure In-Reply-To: <1461674611.23.0.732409522866.issue26852@psf.upfronthosting.co.za> Message-ID: <1469704724.18.0.374823010717.issue26852@psf.upfronthosting.co.za> Thomas Petazzoni added the comment: See https://git.buildroot.org/buildroot/tree/package/python3/0016-Add-importlib-fix-for-PEP-3147-issue.patch ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 07:20:24 2016 From: report at bugs.python.org (koobs) Date: Thu, 28 Jul 2016 11:20:24 +0000 Subject: [issue26852] add the '--enable-legacy-pyc-files' option to configure In-Reply-To: <1461674611.23.0.732409522866.issue26852@psf.upfronthosting.co.za> Message-ID: <1469704824.58.0.57975655188.issue26852@psf.upfronthosting.co.za> Changes by koobs : ---------- nosy: +koobs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 07:21:44 2016 From: report at bugs.python.org (Thomas Petazzoni) Date: Thu, 28 Jul 2016 11:21:44 +0000 Subject: [issue27640] add the '--disable-test-suite' option to configure In-Reply-To: <1469700317.99.0.84265252625.issue27640@psf.upfronthosting.co.za> Message-ID: <1469704904.71.0.623818644006.issue27640@psf.upfronthosting.co.za> Thomas Petazzoni added the comment: We have a similar patch in Buildroot (see https://git.buildroot.org/buildroot/tree/package/python3/0017-Add-an-option-to-disable-installation-of-test-module.patch) so we would be very happy to see this patch merged. Note that we also have many more patches to disable various parts of the Python standard installation (https://git.buildroot.org/buildroot/tree/package/python3/). So either we have one option for each feature (like we have implemented), or a more general config option --disable-feature=test,this,that. See also bug http://bugs.python.org/issue20210 which is related, and was also proposing a patch to disable the test suite. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 07:23:21 2016 From: report at bugs.python.org (Ned Deily) Date: Thu, 28 Jul 2016 11:23:21 +0000 Subject: [issue26852] add the '--enable-legacy-pyc-files' option to configure In-Reply-To: <1461674611.23.0.732409522866.issue26852@psf.upfronthosting.co.za> Message-ID: <1469705001.52.0.90627465415.issue26852@psf.upfronthosting.co.za> Ned Deily added the comment: I think a proposal to add an option like this requires more discussion, probably a PEP. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 07:24:19 2016 From: report at bugs.python.org (Matthias Klose) Date: Thu, 28 Jul 2016 11:24:19 +0000 Subject: [issue26852] add the '--enable-legacy-pyc-files' option to configure In-Reply-To: <1461674611.23.0.732409522866.issue26852@psf.upfronthosting.co.za> Message-ID: <1469705059.89.0.518344275454.issue26852@psf.upfronthosting.co.za> Matthias Klose added the comment: but these are rebuilt when you start the interpreter, aren't they? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 07:28:39 2016 From: report at bugs.python.org (Thomas Petazzoni) Date: Thu, 28 Jul 2016 11:28:39 +0000 Subject: [issue26852] add the '--enable-legacy-pyc-files' option to configure In-Reply-To: <1461674611.23.0.732409522866.issue26852@psf.upfronthosting.co.za> Message-ID: <1469705319.57.0.924595474232.issue26852@psf.upfronthosting.co.za> Thomas Petazzoni added the comment: No, if you remove PEP3147 (like the Buildroot patch does), and install only the .pyc files, you have a smaller Python installation, and nothing gets "re-generated", since what you already have are the .pyc files. The .py files are not even installed on the target system. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 07:37:30 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 28 Jul 2016 11:37:30 +0000 Subject: [issue26851] android compilation and link flags In-Reply-To: <1461673211.54.0.945034926098.issue26851@psf.upfronthosting.co.za> Message-ID: <1469705850.51.0.904652055052.issue26851@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > I am still curious what configures the preprocessor to set __ARM_ARCH to 7 (I guess the clang -target argument?) Yes, the -target clang argument or the -march gcc argument. > and why we can?t set LDFLAGS at the same time or place. Is it just more convenient this way? I don't understand the question. LDFLAGS is set at the time we know that __ARM_ARCH is 7, just after the preprocessing is done. Would you set it elsewhere ? LDFLAGS is set in configure.ac with always this same idiom: LDFLAGS="$LDFLAGS new_options..." and this setting is done in what seems to be random places in configure.ac. CCSHARED is set in one case statement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 07:52:18 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 28 Jul 2016 11:52:18 +0000 Subject: [issue26852] add the '--enable-legacy-pyc-files' option to configure In-Reply-To: <1461674611.23.0.732409522866.issue26852@psf.upfronthosting.co.za> Message-ID: <1469706738.19.0.385641488769.issue26852@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > but these are rebuilt when you start the interpreter, aren't they? No. Quoting PEP 3147: Case 4: legacy pyc files and source-less imports Python will ignore all legacy pyc files when a source file exists next to it. In other words, if a foo.pyc file exists next to the foo.py file, the pyc file will be ignored in all cases In order to continue to support source-less distributions though, if the source file is missing, Python will import a lone pyc file if it lives where the source file would have been. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 07:58:06 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 28 Jul 2016 11:58:06 +0000 Subject: [issue27639] UserList.__getitem__ doesn't account for slices In-Reply-To: <1469686507.89.0.362648270021.issue27639@psf.upfronthosting.co.za> Message-ID: <1469707086.77.0.553475845608.issue27639@psf.upfronthosting.co.za> R. David Murray added the comment: LGTM, but this is change we should probably only make in a feature release, with a note in the What's New porting section. ---------- nosy: +r.david.murray stage: -> needs patch versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 07:58:25 2016 From: report at bugs.python.org (Decorater) Date: Thu, 28 Jul 2016 11:58:25 +0000 Subject: [issue27642] import and __import__() fails silently without a ImportError and does not add the module to the file's namespace. Message-ID: <1469707105.59.0.0648357664764.issue27642@psf.upfronthosting.co.za> New submission from Decorater: So, I have some code. I tried to make a 'plugin' for my bot I made in python. However it seems to not be able to import it which it should be able to. The code I used is here: https://bpaste.net/show/e4445c47490d I dont even know why it is not addign it to the file's namespace or even adding it to sys.modules either. ---------- messages: 271533 nosy: Decorater priority: normal severity: normal status: open title: import and __import__() fails silently without a ImportError and does not add the module to the file's namespace. versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 08:07:24 2016 From: report at bugs.python.org (Emanuel Barry) Date: Thu, 28 Jul 2016 12:07:24 +0000 Subject: [issue27642] import and __import__() fails silently without a ImportError and does not add the module to the file's namespace. In-Reply-To: <1469707105.59.0.0648357664764.issue27642@psf.upfronthosting.co.za> Message-ID: <1469707644.19.0.483953884834.issue27642@psf.upfronthosting.co.za> Emanuel Barry added the comment: `import` merely adds the imported module to the current namespace which, in your code, is some local (non-global) namespace. It is successfully imported but never used, and quickly falls out of scope. You also check for `testplugin in sys.modules`, but you want `'testplugin' in sys.modules`. Closing this as not a bug, please reopen if there's indeed a bug I didn't spot. ---------- nosy: +ebarry resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 08:13:23 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 28 Jul 2016 12:13:23 +0000 Subject: [issue26852] add the '--enable-legacy-pyc-files' option to configure In-Reply-To: <1461674611.23.0.732409522866.issue26852@psf.upfronthosting.co.za> Message-ID: <1469708003.69.0.112569051178.issue26852@psf.upfronthosting.co.za> R. David Murray added the comment: Our official position (so far, mobile is a new use case since the last time it was discussed) is that we don't go out of our way to support sourceless distribution, and in general we discourage it. That is, it is left to the packager of a sourceless program to deal with removing the source and putting the .pyc files in the right place for python to find them. So, yes, this requires at *least* a discussion on python-ideas, and possibly a PEP. If this is adopted '--enable-legacy-pyc' would be the wrong name for the option, since it is in fact forcing legacy pyc...and if the only reason is to reduce space by omitting the source, then it should also not install the source so the name is wrong :) But, this conversation should continue on python-ideas. I'm -1 myself, for the record. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 08:16:01 2016 From: report at bugs.python.org (Decorater) Date: Thu, 28 Jul 2016 12:16:01 +0000 Subject: [issue27642] import and __import__() fails silently without a ImportError and does not add the module to the file's namespace. In-Reply-To: <1469707105.59.0.0648357664764.issue27642@psf.upfronthosting.co.za> Message-ID: <1469708161.1.0.722733808377.issue27642@psf.upfronthosting.co.za> Decorater added the comment: yeah I just noticed it is in sys.modules but does not get defined globally. Bug maybe there is a hack to make it global? ---------- resolution: not a bug -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 08:16:31 2016 From: report at bugs.python.org (Decorater) Date: Thu, 28 Jul 2016 12:16:31 +0000 Subject: [issue27642] import and __import__() fails silently without a ImportError and does not add the module to the file's namespace. In-Reply-To: <1469707105.59.0.0648357664764.issue27642@psf.upfronthosting.co.za> Message-ID: <1469708191.72.0.136573059443.issue27642@psf.upfronthosting.co.za> Decorater added the comment: But* ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 08:20:20 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 28 Jul 2016 12:20:20 +0000 Subject: [issue26852] add the '--enable-legacy-pyc-files' option to configure In-Reply-To: <1461674611.23.0.732409522866.issue26852@psf.upfronthosting.co.za> Message-ID: <1469708420.45.0.699731933712.issue26852@psf.upfronthosting.co.za> R. David Murray added the comment: About doko's note and your response: unless this patch does not install the source (I haven't looked), the __pycache__ files *will* be rebuilt at interpreter start, according to the text you quoted. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 08:21:04 2016 From: report at bugs.python.org (Emanuel Barry) Date: Thu, 28 Jul 2016 12:21:04 +0000 Subject: [issue27642] import and __import__() fails silently without a ImportError and does not add the module to the file's namespace. In-Reply-To: <1469707105.59.0.0648357664764.issue27642@psf.upfronthosting.co.za> Message-ID: <1469708464.13.0.739971617613.issue27642@psf.upfronthosting.co.za> Emanuel Barry added the comment: Yeah, just add 'global testplugin' at the top of your function, before your import it (you'll also need a global statement if you want to delete/re-import it). You might want to take a look at importlib if you wish to dynamically load modules (especially reloading them, which is a pain). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 08:24:50 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 28 Jul 2016 12:24:50 +0000 Subject: [issue27642] import and __import__() fails silently without a ImportError and does not add the module to the file's namespace. In-Reply-To: <1469707105.59.0.0648357664764.issue27642@psf.upfronthosting.co.za> Message-ID: <1469708690.2.0.329245521546.issue27642@psf.upfronthosting.co.za> R. David Murray added the comment: Questions like this are more appropriate for the python-list mailing list, or even python-tutor. ---------- nosy: +r.david.murray resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 08:35:18 2016 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 28 Jul 2016 12:35:18 +0000 Subject: [issue27638] int.to_bytes() and int.from_bytes() should support 'net' and 'host' byte orders In-Reply-To: <1469676753.14.0.293041836709.issue27638@psf.upfronthosting.co.za> Message-ID: <1469709318.02.0.898063352308.issue27638@psf.upfronthosting.co.za> Mark Dickinson added the comment: -1 from me; it feels like a needless expansion of the API. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 08:47:31 2016 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 28 Jul 2016 12:47:31 +0000 Subject: [issue27637] int.to_bytes(-1, ...) should automatically choose required count of bytes In-Reply-To: <1469675712.56.0.174576481029.issue27637@psf.upfronthosting.co.za> Message-ID: <1469710051.56.0.215931262176.issue27637@psf.upfronthosting.co.za> Mark Dickinson added the comment: [Martin] > I don?t like special values. Agreed. If we wanted to add this, the obvious API would be to simply make the size optional (which would force passing the endianness by name or explicitly passing a default value of `None`, but that doesn't seem like a big deal to me). I'm -0 on the feature itself. On the plus side, the fact that it's not completely trivial to compute the size with errors is an argument for including that calculation within the Python code. I'd suggest formulas of: (x.bit_length() + 7) // 8 for the unsigned case, and (~x if x < 0 else x).bit_length() // 8 + 1 for the signed case, these giving the minimal number of bytes necessary for encoding x in each case. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 09:03:52 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 28 Jul 2016 13:03:52 +0000 Subject: [issue26851] android compilation and link flags In-Reply-To: <1461673211.54.0.945034926098.issue26851@psf.upfronthosting.co.za> Message-ID: <1469711032.24.0.139072227917.issue26851@psf.upfronthosting.co.za> Martin Panter added the comment: Where is the code that sets the clang -target argument, or gcc -march? Is it hidden away somewhere in the autoconf code? Do you manually set it with ?./configure CFLAGS="-target . . ." ?? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 09:15:56 2016 From: report at bugs.python.org (Ned Deily) Date: Thu, 28 Jul 2016 13:15:56 +0000 Subject: [issue26852] add the '--enable-legacy-pyc-files' option to configure In-Reply-To: <1461674611.23.0.732409522866.issue26852@psf.upfronthosting.co.za> Message-ID: <1469711756.2.0.833268127881.issue26852@psf.upfronthosting.co.za> Ned Deily added the comment: Also, has anyone tried bundling the std lib into a zlib? I know that option has been around for a long time but I don't know if it still works or is even being used. Presumably, that would be another way to save space and file system entries. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 09:22:50 2016 From: report at bugs.python.org (Jami Lindh) Date: Thu, 28 Jul 2016 13:22:50 +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: <1469712170.37.0.0914680969795.issue27397@psf.upfronthosting.co.za> Jami Lindh added the comment: I stumbled upon this bug as well while fuzzing with AFL. The curious thing is that email.message_from_string still accepts that garbled message as a valid email. ---------- nosy: +CryptidVulpes versions: +Python 3.4 Added file: http://bugs.python.org/file43921/issue27397_poc.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 09:23:41 2016 From: report at bugs.python.org (Jami Lindh) Date: Thu, 28 Jul 2016 13:23:41 +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: <1469712221.8.0.398090697267.issue27397@psf.upfronthosting.co.za> Jami Lindh added the comment: I also attached a minimal script containing only the decode call and the garbage payload. ---------- Added file: http://bugs.python.org/file43922/issue27397_poc_minimal.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 09:42:35 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Thu, 28 Jul 2016 13:42:35 +0000 Subject: [issue26865] Meta-issue: support of the android platform In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za> Message-ID: <1469713355.95.0.763669732896.issue26865@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Some dependent issues, like issue26852, issue26859 and issue27640, are for reducing the size of an installation. How about moving them to another meta-issue? First they are not critical for normal usages on Android. Second they are not limited to Android - other platforms may benefit as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 09:48:41 2016 From: report at bugs.python.org (Julien) Date: Thu, 28 Jul 2016 13:48:41 +0000 Subject: [issue26462] Patch to enhance literal block language declaration In-Reply-To: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za> Message-ID: <1469713721.42.0.904401265098.issue26462@psf.upfronthosting.co.za> Julien added the comment: Hi, Indentation in whatsnew/3.2 fixed. Colors in this block are clearly not perfect, but I think that's another subject. ---------- Added file: http://bugs.python.org/file43923/issue26462.v7.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 09:58:52 2016 From: report at bugs.python.org (Julien) Date: Thu, 28 Jul 2016 13:58:52 +0000 Subject: [issue26462] Patch to enhance literal block language declaration In-Reply-To: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za> Message-ID: <1469714332.67.0.310098471319.issue26462@psf.upfronthosting.co.za> Julien added the comment: Hi, Would you like me to also provide patches for different versions? I only provided patches for the default branch, but I'll gladly see this applied on other branches, as I often build them all. Also is a documented policy about maintaining the documentation? I have some questions like: - Should we maintain bugfix/security/end-of-life branches? - Are we even allowed to push a documentation change to them? - I'm seeing that the 3.x documentation are converging by using the "New in version 3.xx." marks, but they still different, is this effort documented? - Is this a goal to merge them on the long term? - Is there a team on this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 10:09:08 2016 From: report at bugs.python.org (Decorater) Date: Thu, 28 Jul 2016 14:09:08 +0000 Subject: [issue26462] Patch to enhance literal block language declaration In-Reply-To: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za> Message-ID: <1469714948.91.0.11036858409.issue26462@psf.upfronthosting.co.za> Decorater added the comment: tbh it would be nice if the entire documentation was recolored to look more 'interesting' to read. And to also have it in a way that people who lean visually can learn the info easier instead of them trying to read a giant wall of text that they may or may not understand. (got to hate reading giant walls) But yeah all versions on it should be good. ---------- nosy: +Decorater _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 10:10:37 2016 From: report at bugs.python.org (Decorater) Date: Thu, 28 Jul 2016 14:10:37 +0000 Subject: [issue26462] Patch to enhance literal block language declaration In-Reply-To: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za> Message-ID: <1469715037.92.0.133110587143.issue26462@psf.upfronthosting.co.za> Decorater added the comment: Also I was thinking maybe I could figure out how to Add in asyncio to 2.7 anyway (well latest one that is) because why not. With as many things using asyncio now days it would be cake for those python 2 users. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 10:21:57 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 28 Jul 2016 14:21:57 +0000 Subject: [issue26851] android compilation and link flags In-Reply-To: <1461673211.54.0.945034926098.issue26851@psf.upfronthosting.co.za> Message-ID: <1469715717.47.0.336037401544.issue26851@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Yes, the packager must use appropriately either CFLAGS CPPFLAGS [1] and LDFLAGS, or CC. I am using: CC="clang --sysroot=$(SYSROOT) -target $(TARGET) -gcc-toolchain $(GCC_TOOLCHAIN)". [1] See issue 27453, for the remaining problem upon using CPPFLAGS. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 10:23:26 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 28 Jul 2016 14:23:26 +0000 Subject: [issue26462] Patch to enhance literal block language declaration In-Reply-To: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za> Message-ID: <1469715806.52.0.22301178157.issue26462@psf.upfronthosting.co.za> Martin Panter added the comment: Usually my technique is to apply the 3.6 patch to 3.5, fix up any conflicts, and leave the 3.6-only bits out (which get rejected by the patch process anyway). But dedicated patch(es) may be useful. Especially for 2.7, where there are probably independent changes to be made (e.g. modules that were removed in Python 3). I think the policy on documentation in each branch should be in the devguide. My understanding: In general, bug fix branches (3.5, 2.7) have the documentation maintained, but generally not the older security-only branches. My view is if a feature is added to (say) 3.6, then it gets a new-in-3.6 notice in the 3.6 documentation, but nothing gets added to 3.5. The Python 3 documentation rarely mentions features of Python 2, so every feature is treated as being new in 3.0 by default. For Python 2, it won?t document new features of Python 3, but is updated with changes relevant to porting to 3. So in theory the latest Python 3.6+ documentation should also be usable with 3.5, but not with Python 2. That?s about all I know :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 10:32:31 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 28 Jul 2016 14:32:31 +0000 Subject: [issue26462] Patch to enhance literal block language declaration In-Reply-To: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za> Message-ID: <1469716351.72.0.0162267676523.issue26462@psf.upfronthosting.co.za> R. David Murray added the comment: Martin: your summary is correct. A new feature should also have a What's New entry, of course; I think that's the only essential you left out. Decorator: general comments (eg: color of docs, etc) aren't really useful comments on a specific bug report, and the asyncio comment is totally irrelevant. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 11:01:29 2016 From: report at bugs.python.org (Michael Felt) Date: Thu, 28 Jul 2016 15:01:29 +0000 Subject: [issue27643] test_ctypes fails on AIX with xlc Message-ID: <1469718089.88.0.404760174195.issue27643@psf.upfronthosting.co.za> New submission from Michael Felt: I am preparing a system with gcc to see if it is compiler related, i.e., goes away with gcc. On the one hand, fingers crossed - but on the other, having bitfields working regardless of the compiler should be preferred. This issue is similar to a Solaris (C compiler) http://bugs.python.org/issue16275 During the build using clc _ get these messages - which make me hope it is an unexpected compiler issue. "/data/prj/aixtools/python/python-2.7.12.1/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for M is not valid. Type unsigned assumed. "/data/prj/aixtools/python/python-2.7.12.1/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for N is not valid. Type unsigned assumed. "/data/prj/aixtools/python/python-2.7.12.1/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for O is not valid. Type unsigned assumed. "/data/prj/aixtools/python/python-2.7.12.1/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for P is not valid. Type unsigned assumed. "/data/prj/aixtools/python/python-2.7.12.1/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for Q is not valid. Type unsigned assumed. "/data/prj/aixtools/python/python-2.7.12.1/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for R is not valid. Type unsigned assumed. "/data/prj/aixtools/python/python-2.7.12.1/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for S is not valid. Type unsigned assumed. Note: I modified test_bitfields to do an additional print. Maybe this gives an idea about what the issue is (when considering the compiler messages) root at x064:[/data/prj/aixtools/python/python-2.7.12.1/Lib/ctypes/test]../../../python ./runtests.py A 0x1001f 0 B 0x2001d 0 C 0x3001a 0 D 0x40016 0 E 0x50011 0 F 0x6000b 0 G 0x70004 0 H 0x80018 4 I 0x9000f 4 M 0x1000e 6 N 0x2000c 6 O 0x30009 6 P 0x40005 6 Q 0x50000 6 R 0x6000a 8 S 0x70003 8 .............s....................ssss............................ssssssssssssssssssssssssssss...s.......s.....................sssssssssssssssssssss......s...........s....s.....................FF...s...............................................s.............sssss.ss....s.......ss..sss...................s......s.....................s..................................................s...........ss.sssss................s.s.............s. ====================================================================== FAIL: test_ints (ctypes.test.test_bitfields.C_Test) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/prj/aixtools/python/python-2.7.12.1/Lib/ctypes/test/test_bitfields.py", line 41, in test_ints self.assertEqual((name, i, getattr(b, name)), (name, i, func(byref(b), name))) AssertionError: Tuples differ: ('A', 1, -1) != ('A', 1, 1) First differing element 2: -1 1 - ('A', 1, -1) ? - + ('A', 1, 1) ====================================================================== FAIL: test_shorts (ctypes.test.test_bitfields.C_Test) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/prj/aixtools/python/python-2.7.12.1/Lib/ctypes/test/test_bitfields.py", line 48, in test_shorts self.assertEqual((name, i, getattr(b, name)), (name, i, func(byref(b), name))) AssertionError: Tuples differ: ('M', 1, -1) != ('M', 1, 1) First differing element 2: -1 1 - ('M', 1, -1) ? - + ('M', 1, 1) ---------------------------------------------------------------------- Ran 440 tests in 0.883s (0 modules skipped) Unavailable resources: printing, refcount FAILED (failures=2) root at x064:[/data/prj/aixtools/python/python-2.7.12.1/Lib/ctypes/test] ---------- messages: 271555 nosy: Michael.Felt priority: normal severity: normal status: open title: test_ctypes fails on AIX with xlc versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 11:09:27 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 28 Jul 2016 15:09:27 +0000 Subject: [issue27404] Misc/NEWS: add [Security] prefix to Python 3.5.2 changelog In-Reply-To: <1467062077.67.0.144801873004.issue27404@psf.upfronthosting.co.za> Message-ID: <20160728150910.21454.46234.81E0BA24@psf.io> Roundup Robot added the comment: New changeset a576a34f5386 by Victor Stinner in branch '3.5': NEWS: tag security related changes with [Security] prefix https://hg.python.org/cpython/rev/a576a34f5386 New changeset 6a2de662eeb7 by Victor Stinner in branch 'default': Merge 3.5 (issue #27404) https://hg.python.org/cpython/rev/6a2de662eeb7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 11:10:28 2016 From: report at bugs.python.org (Jonathan Kross) Date: Thu, 28 Jul 2016 15:10:28 +0000 Subject: [issue27131] Unit test random shuffle In-Reply-To: <1464277146.71.0.570096870767.issue27131@psf.upfronthosting.co.za> Message-ID: <1469718628.27.0.232175854387.issue27131@psf.upfronthosting.co.za> Jonathan Kross added the comment: Just giving this one a bump to see if it can be applied soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 11:11:40 2016 From: report at bugs.python.org (Michael Felt) Date: Thu, 28 Jul 2016 15:11:40 +0000 Subject: [issue27643] test_ctypes fails on AIX with xlc In-Reply-To: <1469718089.88.0.404760174195.issue27643@psf.upfronthosting.co.za> Message-ID: <1469718700.45.0.085398982724.issue27643@psf.upfronthosting.co.za> Michael Felt added the comment: FYI: similar (exact) results when 64-bit mode: root at x064:[/data/prj/aixtools/python/python-2.7.12.1/Lib/ctypes/test]../../../python ./runtests.py A 0x1001f 0 B 0x2001d 0 C 0x3001a 0 D 0x40016 0 E 0x50011 0 F 0x6000b 0 G 0x70004 0 H 0x80018 4 I 0x9000f 4 M 0x1000e 6 N 0x2000c 6 O 0x30009 6 P 0x40005 6 Q 0x50000 6 R 0x6000a 8 S 0x70003 8 .............s....................ssss............................ssssssssssssssssssssssssssss...s.......s.....................sssssssssssssssssssss......s...........s....s.....................FF...s...............................................s.............sssss.ss....s.......ss..sss...................s......s.....................s..................................................s...........ss.sssss................s.s.............s. ====================================================================== FAIL: test_ints (ctypes.test.test_bitfields.C_Test) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/prj/aixtools/python/python-2.7.12.1/Lib/ctypes/test/test_bitfields.py", line 41, in test_ints self.assertEqual((name, i, getattr(b, name)), (name, i, func(byref(b), name))) AssertionError: Tuples differ: ('A', 1, -1) != ('A', 1, 1) First differing element 2: -1 1 - ('A', 1, -1) ? - + ('A', 1, 1) ====================================================================== FAIL: test_shorts (ctypes.test.test_bitfields.C_Test) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/prj/aixtools/python/python-2.7.12.1/Lib/ctypes/test/test_bitfields.py", line 48, in test_shorts self.assertEqual((name, i, getattr(b, name)), (name, i, func(byref(b), name))) AssertionError: Tuples differ: ('M', 1, -1) != ('M', 1, 1) First differing element 2: -1 1 - ('M', 1, -1) ? - + ('M', 1, 1) ---------------------------------------------------------------------- Ran 440 tests in 0.870s (0 modules skipped) Unavailable resources: printing, refcount FAILED (failures=2) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 11:29:01 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 28 Jul 2016 15:29:01 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <1469719741.2.0.444453256339.issue24773@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: It looks like the tzdata folks have agreed [1] that there is a problem with the Morocco rules in the Africa file and will likely fix it in the next release. This is an interesting situation where a bug in tzcode masks a bug in tzdata while glibc implements the documented behavior faithfully but as a result suffers from the data bug. I will wait for the conclusion of the discussion on the TZ list because there is a chance that we should fix the ZoneInfo logic to match glibc. [1]: http://mm.icann.org/pipermail/tz/2016-July/023896.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 11:49:59 2016 From: report at bugs.python.org (Julien) Date: Thu, 28 Jul 2016 15:49:59 +0000 Subject: [issue26462] Patch to enhance literal block language declaration In-Reply-To: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za> Message-ID: <1469720999.01.0.140482359774.issue26462@psf.upfronthosting.co.za> Julien added the comment: Martin: OK, let's apply this to 3.6 / 3.5 with this one, and I'll provide independent patch for 2.7 if needed (long time without building 2.7 doc). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 11:58:13 2016 From: report at bugs.python.org (Michael Felt) Date: Thu, 28 Jul 2016 15:58:13 +0000 Subject: [issue27643] test_ctypes fails on AIX with xlc In-Reply-To: <1469718089.88.0.404760174195.issue27643@psf.upfronthosting.co.za> Message-ID: <1469721493.59.0.470577292028.issue27643@psf.upfronthosting.co.za> Michael Felt added the comment: So, it seems to be a compiler issue - when built using gcc (v4.7.4) the tests take a bit longer, but no failures. root at x065:[/data/prj/aixtools/python/python-2.7.12.1/Lib/ctypes/test]../../../python runtests.py A 0x1001f 0 B 0x2001d 0 C 0x3001a 0 D 0x40016 0 E 0x50011 0 F 0x6000b 0 G 0x70004 0 H 0x80018 4 I 0x9000f 4 M 0x1000e 6 N 0x2000c 6 O 0x30009 6 P 0x40005 6 Q 0x50000 6 R 0x6000a 8 S 0x70003 8 .............s....................ssss............................ssssssssssssssssssssssssssss...s.......s.....................sssssssssssssssssssss......s...........s....s..........................s...............................................s.............sssss.ss....s.......ss..sss...................s......s.....................s..................................................s...........ss.sssss................s.s.............s. ---------------------------------------------------------------------- Ran 440 tests in 1.028s (0 modules skipped) Unavailable resources: printing, refcount OK ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 12:01:24 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 28 Jul 2016 16:01:24 +0000 Subject: [issue26852] add the '--enable-sourceless-distribution' option to configure In-Reply-To: <1461674611.23.0.732409522866.issue26852@psf.upfronthosting.co.za> Message-ID: <1469721684.65.0.841641575816.issue26852@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > and if the only reason is to reduce space by omitting the source, then it should also not install the source so the name is wrong :) I miss your point, msg271515 said earlier "the patch removes all *.py files". The patch does a sourceless distribution: no source and no __pycache__ files (with the exception mentionned in msg271515). Changing the issue title with '--enable-sourceless-distribution' which is a better name and would have maybe avoided this confusion :) ---------- title: add the '--enable-legacy-pyc-files' option to configure -> add the '--enable-sourceless-distribution' option to configure _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 12:05:00 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 28 Jul 2016 16:05:00 +0000 Subject: [issue26852] add the '--enable-sourceless-distribution' option to configure In-Reply-To: <1461674611.23.0.732409522866.issue26852@psf.upfronthosting.co.za> Message-ID: <1469721900.27.0.289961167792.issue26852@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > About doko's note and your response: unless this patch does not install the source (I haven't looked), the __pycache__ files *will* be rebuilt at interpreter start, according to the text you quoted. Right, and since the source files are removed, the __pycache__ files are *not* built. Hence my negative answer to Matthias. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 12:12:39 2016 From: report at bugs.python.org (Anton Backer) Date: Thu, 28 Jul 2016 16:12:39 +0000 Subject: [issue27639] UserList.__getitem__ doesn't account for slices In-Reply-To: <1469686507.89.0.362648270021.issue27639@psf.upfronthosting.co.za> Message-ID: <1469722359.45.0.490542066878.issue27639@psf.upfronthosting.co.za> Changes by Anton Backer : ---------- keywords: +patch Added file: http://bugs.python.org/file43924/581663cb2d4d.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 12:15:47 2016 From: report at bugs.python.org (Anton Backer) Date: Thu, 28 Jul 2016 16:15:47 +0000 Subject: [issue27639] UserList.__getitem__ doesn't account for slices In-Reply-To: <1469686507.89.0.362648270021.issue27639@psf.upfronthosting.co.za> Message-ID: <1469722547.35.0.908323116085.issue27639@psf.upfronthosting.co.za> Changes by Anton Backer : Removed file: http://bugs.python.org/file43924/581663cb2d4d.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 12:17:27 2016 From: report at bugs.python.org (Anders Lorentsen) Date: Thu, 28 Jul 2016 16:17:27 +0000 Subject: [issue27623] int.to_bytes() and int.from_bytes(): raise ValueError when bytes count is zero In-Reply-To: <1469514380.74.0.642597369558.issue27623@psf.upfronthosting.co.za> Message-ID: <1469722647.49.0.665426564443.issue27623@psf.upfronthosting.co.za> Anders Lorentsen added the comment: So, am I to understand that the only corner case we should fix is that >>> (-1).to_bytes(0, 'big', signed=True) should raise an overflow error (currently it returns b'') ? ---------- Added file: http://bugs.python.org/file43925/int_to_bytes_overflow_cornercase.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 12:29:11 2016 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 28 Jul 2016 16:29:11 +0000 Subject: [issue27623] int.to_bytes() and int.from_bytes(): raise ValueError when bytes count is zero In-Reply-To: <1469514380.74.0.642597369558.issue27623@psf.upfronthosting.co.za> Message-ID: <1469723351.61.0.699348790236.issue27623@psf.upfronthosting.co.za> Mark Dickinson added the comment: I guess that would be the minimal change necessary to remove ambiguity. But I tend to think that >>> (0).to_bytes(0, 'big', signed=True) should also be an error. (And of course both these should still be errors with 'big' replaced with 'little'.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 12:41:22 2016 From: report at bugs.python.org (Julien) Date: Thu, 28 Jul 2016 16:41:22 +0000 Subject: [issue26462] Patch to enhance literal block language declaration In-Reply-To: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za> Message-ID: <1469724082.81.0.156733582003.issue26462@psf.upfronthosting.co.za> Julien added the comment: Decorater: Colors used by the documentation are defined here: https://github.com/sphinx-doc/sphinx/blob/master/sphinx/pygments_styles.py#L22 you can easily modify it and rebuild the doc ``(cd Doc; make html)``. Take a look at existing themes (https://help.farbox.com/pygments.html), sphinx uses a vaiarion of "friendly". But, in general, please open a new issue to speak on different subjects, typically about asyncio which is not related to this issue. Have a nice day. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 12:44:51 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 28 Jul 2016 16:44:51 +0000 Subject: [issue26865] Meta-issue: support of the android platform In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za> Message-ID: <1469724291.72.0.736408280176.issue26865@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Roman, can you please enter a new issue for that problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 13:02:32 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 28 Jul 2016 17:02:32 +0000 Subject: [issue26865] Meta-issue: support of the android platform In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za> Message-ID: <1469725352.7.0.155925440156.issue26865@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > Some dependent issues, like issue26852, issue26859 and issue27640, are for reducing the size of an installation. How about moving them to another meta-issue? First they are not critical for normal usages on Android. Second they are not limited to Android - other platforms may benefit as well. Many issues that deal with failed tests are also not critical for normal usages on Android, but they must be fixed to run a buildbot and to support Android. Issue #22724 (byte-compile fails for cross-builds) is also not specific to Android. IMHO this meta-issue collects (1) the issues that must be fixed for the support of Android and (2) the issues that should possibly be fixed. The issues you are naming and issue 22724 are in the second category. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 13:04:41 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 28 Jul 2016 17:04:41 +0000 Subject: [issue27404] Misc/NEWS: add [Security] prefix to Python 3.5.2 changelog In-Reply-To: <1467062077.67.0.144801873004.issue27404@psf.upfronthosting.co.za> Message-ID: <1469725481.5.0.0497193968761.issue27404@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 13:06:28 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 28 Jul 2016 17:06:28 +0000 Subject: [issue27250] Add os.urandom_block() In-Reply-To: <1465302067.94.0.484576804121.issue27250@psf.upfronthosting.co.za> Message-ID: <1469725588.15.0.731920015943.issue27250@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't support this idea anymore, so I close the issue. I wrote the PEP 524 to propose to make os.urandom() blocking on Linux. The discussion moved to the security-sig mailing list. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 13:07:55 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 28 Jul 2016 17:07: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: <1469725675.48.0.482617018641.issue27266@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't like this idea anymore ("add block=False parameter to os.urandom()"), so I close this issue. I wrote the PEP 524 to propose to make os.urandom() blocking on Linux. The discussion moved to the security-sig mailing list. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 13:25:11 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Thu, 28 Jul 2016 17:25:11 +0000 Subject: [issue26865] Meta-issue: support of the android platform In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za> Message-ID: <1469726711.38.0.0312638916148.issue26865@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Maybe the term "normal usages" is not accurate. I was trying to refer all possible Python usages on Android, and the test suite is a subset of them, so they should be fixed, too. I propose the aforementioned change (creating another meta-issue) because there are already many issues in this meta-issue, and I'm afraid new issues in the second category lead to complexity in tracking CPython's Android support. Currently things are still under control, so you can ignore my request until the number of issues goes crazy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 13:29:04 2016 From: report at bugs.python.org (Michael Lee) Date: Thu, 28 Jul 2016 17:29:04 +0000 Subject: [issue27644] Expand documentation about type aliases and NewType in the typing module Message-ID: <1469726944.72.0.582694680461.issue27644@psf.upfronthosting.co.za> New submission from Michael Lee: This is a patch to update the documentation on the typing module. It expands the section on type aliases and adds a section on [NewType][0]. Since support for NewType was [recently added][1] to mypy, it seemed like a prudent time to update the docs to describe this new feature. The section on type aliases was mainly expanded because the distinction between type aliases and NewType could be potentially confusing, so adding extra clarification seemed like a good idea. [0]: https://www.python.org/dev/peps/pep-0484/#newtype-helper-function [1]: https://github.com/python/mypy/pull/1939 ---------- assignee: docs at python components: Documentation files: document_newtype.patch keywords: patch messages: 271572 nosy: docs at python, michael0x2a priority: normal severity: normal status: open title: Expand documentation about type aliases and NewType in the typing module versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43926/document_newtype.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 13:34:23 2016 From: report at bugs.python.org (nemunaire) Date: Thu, 28 Jul 2016 17:34:23 +0000 Subject: [issue27629] Cannot create ssl.SSLSocket without existing socket In-Reply-To: <1469575305.76.0.392837082138.issue27629@psf.upfronthosting.co.za> Message-ID: <1469727263.3.0.760638749708.issue27629@psf.upfronthosting.co.za> nemunaire added the comment: Here is a new patch with tests on constructor. The patch on the feature is quite different: instead of testing for None socket, I choose to delay the != SOCK_STREAM check in the later condition, when we know we treat a socket. Tests include different constructor forms: with a given socket, with a fileno (didn't work either, before this patch) and without socket nor file descriptor (as in my original test). I don't have sufficient background to judge if tests will work on all platform (eg. fileno and windows, ...). Here is the interesting diff of the tests on SSL (before/after applying the patch on the feature): 32c32 < test_constructor (__main__.BasicSocketTests) ... ERROR --- > test_constructor (__main__.BasicSocketTests) ... ok 519,528d518 < ERROR: test_constructor (__main__.BasicSocketTests) < ---------------------------------------------------------------------- < Traceback (most recent call last): < File "test_ssl.py", line 149, in test_constructor < ss = ssl.SSLSocket() < File "/usr/lib/python3.4/ssl.py", line 545, in __init__ < if sock.getsockopt(SOL_SOCKET, SO_TYPE) != SOCK_STREAM: < AttributeError: 'NoneType' object has no attribute 'getsockopt' < < ====================================================================== ---------- Added file: http://bugs.python.org/file43927/fix_sslsocket_init_without_socket_3_3-3_6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 13:34:33 2016 From: report at bugs.python.org (nemunaire) Date: Thu, 28 Jul 2016 17:34:33 +0000 Subject: [issue27629] Cannot create ssl.SSLSocket without existing socket In-Reply-To: <1469575305.76.0.392837082138.issue27629@psf.upfronthosting.co.za> Message-ID: <1469727273.07.0.206949802881.issue27629@psf.upfronthosting.co.za> Changes by nemunaire : Removed file: http://bugs.python.org/file43900/fix_sslsocket_init_without_socket_3.3-3_6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 13:48:18 2016 From: report at bugs.python.org (Lele Gaifax) Date: Thu, 28 Jul 2016 17:48:18 +0000 Subject: [issue27645] Supporting native backup facility of SQLite Message-ID: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za> New submission from Lele Gaifax: It would be nice if the sqlite3 stdlib module could expose the SQLite Online Backup API. I'm willing to implement it, as encouraged by Paul Moore. See also: https://mail.python.org/pipermail/python-dev/2016-July/145570.html ---------- components: Extension Modules messages: 271574 nosy: lelit priority: normal severity: normal status: open title: Supporting native backup facility of SQLite type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 13:56:36 2016 From: report at bugs.python.org (Lele Gaifax) Date: Thu, 28 Jul 2016 17:56:36 +0000 Subject: [issue27645] Supporting native backup facility of SQLite In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za> Message-ID: <1469728596.23.0.152161148313.issue27645@psf.upfronthosting.co.za> Lele Gaifax added the comment: Here is a preliminary implementation: https://github.com/lelit/cpython/commit/b7456eb6a55568639a41efb5d88ab4d9b3c20337 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 14:12:29 2016 From: report at bugs.python.org (Emanuel Barry) Date: Thu, 28 Jul 2016 18:12:29 +0000 Subject: [issue27645] Supporting native backup facility of SQLite In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za> Message-ID: <1469729549.07.0.728689708538.issue27645@psf.upfronthosting.co.za> Emanuel Barry added the comment: That's really nice, thank you for doing this! To get your code reviewed, though, you should upload a patch here. With git, you can do 'git diff > my_patch_file_name.patch' in your local repo, then you can upload the resulting file here. If you haven't done so yet, you'll need to sign a contributor agreement as well: https://www.python.org/psf/contrib/contrib-form/ :) (Also, you might want to remove the 'index ...' lines in the patch file that git generates for each modified file; since there are three files, there should be three lines to remove. I'm not sure if you really have to, but I always do it just to be sure :) ---------- nosy: +ebarry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 14:30:50 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 28 Jul 2016 18:30:50 +0000 Subject: [issue27646] yield from expression can be any iterable Message-ID: <1469730650.89.0.176012351897.issue27646@psf.upfronthosting.co.za> New submission from Terry J. Reedy: https://docs.python.org/3/reference/expressions.html#yield-expressions says "When yield from is used, it treats the supplied expression as a subiterator. All values produced by that subiterator ...". To me "treats..expression as a subiterator" means that the expression must *be* an iterator, such as returned by iter or calling a generator function. Hence I was surprised upon reading "yield from " in stdlib code. I confirmed that this usage is correct by trying >>> def g(): yield from (1,2) >>> i = g() >>> next(i), next(i) (1, 2) and then reading the PEP380 Formal Semantics, which begins with "_i = iter(EXPR)". Hence I suggest the following replacement for the quote above: "When yield from is used, the expression must be an iterable. A subiterator is obtained with iter(). All values produced by that subiterator ...". Note that 'subiterator' is spelled in the following sentences 'underlying iterable' (which I am not sure I like) and 'sub-iterator' (and 'sub-generator'). I think we should be consistent for at least the two short 'yield from' paragraphs. ---------- assignee: docs at python components: Documentation messages: 271577 nosy: docs at python, terry.reedy priority: normal severity: normal stage: patch review status: open title: yield from expression can be any iterable type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 14:37:30 2016 From: report at bugs.python.org (Lele Gaifax) Date: Thu, 28 Jul 2016 18:37:30 +0000 Subject: [issue27645] Supporting native backup facility of SQLite In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za> Message-ID: <1469731050.27.0.289079484245.issue27645@psf.upfronthosting.co.za> Changes by Lele Gaifax : ---------- keywords: +patch Added file: http://bugs.python.org/file43928/issue27645.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 14:41:39 2016 From: report at bugs.python.org (=?utf-8?q?Mihai_Capot=C4=83?=) Date: Thu, 28 Jul 2016 18:41:39 +0000 Subject: [issue10910] pyport.h FreeBSD/Mac OS X "fix" causes errors in C++ compilation In-Reply-To: <1295040100.28.0.0907494738582.issue10910@psf.upfronthosting.co.za> Message-ID: <1469731299.45.0.361191688286.issue10910@psf.upfronthosting.co.za> Changes by Mihai Capot? : ---------- nosy: +mihaic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 14:44:10 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 28 Jul 2016 18:44:10 +0000 Subject: [issue27645] Supporting native backup facility of SQLite In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za> Message-ID: <1469731450.8.0.744157489468.issue27645@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch! I haven't had a chance to review the patch yet, but we also need documentation updates to Doc/library/sqlite3.rst. ---------- nosy: +berker.peksag stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 15:29:31 2016 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 28 Jul 2016 19:29:31 +0000 Subject: [issue9998] ctypes find_library should search LD_LIBRARY_PATH on Linux In-Reply-To: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za> Message-ID: <1469734171.73.0.953938611469.issue9998@psf.upfronthosting.co.za> Vinay Sajip added the comment: I have updated the patch to apply against 3.6, and changed it to be more conservative: it only uses ld and LD_LIBRARY_PATH when trying to find a library if the existing gcc-based method fails. Seeing that this issue has been around for so long, I would really like to get this patch committed in the short window we have before 3.6 goes into beta. Please review! ---------- assignee: theller -> vinay.sajip title: ctypes find_library should search LD_LIBRARY_PATH on linux -> ctypes find_library should search LD_LIBRARY_PATH on Linux versions: +Python 3.6 -Python 3.5 Added file: http://bugs.python.org/file43929/refresh-2016.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 15:32:06 2016 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 28 Jul 2016 19:32:06 +0000 Subject: [issue9998] ctypes find_library should search LD_LIBRARY_PATH on Linux In-Reply-To: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za> Message-ID: <1469734326.09.0.1675069162.issue9998@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- hgrepos: -130 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 16:18:55 2016 From: report at bugs.python.org (Lele Gaifax) Date: Thu, 28 Jul 2016 20:18:55 +0000 Subject: [issue27645] Supporting native backup facility of SQLite In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za> Message-ID: <1469737135.91.0.215473565758.issue27645@psf.upfronthosting.co.za> Lele Gaifax added the comment: For the documentation see https://github.com/lelit/cpython/commit/bd82f8de9800ae40b33ddf1e4b7d72f10bc9c10e or the attached patch. ---------- Added file: http://bugs.python.org/file43930/issue27645-doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 16:19:54 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Jul 2016 20:19:54 +0000 Subject: [issue27647] Update Windows build to Tcl/Tk 8.6.6 Message-ID: <1469737194.88.0.144648917966.issue27647@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Current Tcl/Tk version in Windows build is 8.6.4.2. Tcl/Tk 8.6.6 was released yesterday. https://sourceforge.net/p/tcl/mailman/message/35246302/ ---------- components: Tkinter, Windows messages: 271581 nosy: paul.moore, serhiy.storchaka, steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: needs patch status: open title: Update Windows build to Tcl/Tk 8.6.6 versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 16:20:55 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Jul 2016 20:20:55 +0000 Subject: [issue27647] Update Windows build to Tcl/Tk 8.6.6 In-Reply-To: <1469737194.88.0.144648917966.issue27647@psf.upfronthosting.co.za> Message-ID: <1469737255.32.0.396623766588.issue27647@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 16:24:12 2016 From: report at bugs.python.org (Lele Gaifax) Date: Thu, 28 Jul 2016 20:24:12 +0000 Subject: [issue27645] Supporting native backup facility of SQLite In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za> Message-ID: <1469737452.35.0.0673461391291.issue27645@psf.upfronthosting.co.za> Lele Gaifax added the comment: WRT to the agreement form, I guess I'll have to compile it even if I already contributed to Python decades ago (ObjC, readline, NeXT support...), right? Will try to do whatever is needed in the next days... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 16:25:09 2016 From: report at bugs.python.org (Michael Felt) Date: Thu, 28 Jul 2016 20:25:09 +0000 Subject: [issue9998] ctypes find_library should search LD_LIBRARY_PATH on Linux In-Reply-To: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za> Message-ID: <1469737509.62.0.112485830432.issue9998@psf.upfronthosting.co.za> Michael Felt added the comment: imho - it is not correct to only make a modification of this nature for a single platform. To be realistic, if the "design" goal is to 'find' what dlopen() will find when given a argument without a pathname component - then gcc should not be used, and perhaps only your 'ld' based solution (which I have not read). >From linux man pages: both the justification to consider *PATH* for all platforms (i.e., LD_LIBRARY_PATH is a GNU/Linux construct, not the default for all platforms.) """ dlopen() The function dlopen() loads the dynamic library file named by the null-terminated string filename and returns an opaque "handle" for the dynamic library. If filename is NULL, then the returned handle is for the main program. If filename contains a slash ("/"), then it is interpreted as a (relative or absolute) pathname. Otherwise, the dynamic linker searches for the library as follows (see ld.so(8) for further details): o (ELF only) If the executable file for the calling program contains a DT_RPATH tag, and does not contain a DT_RUNPATH tag, then the directories listed in the DT_RPATH tag are searched. o If, at the time that the program was started, the environment variable LD_LIBRARY_PATH was defined to contain a colon-separated list of directories, then these are searched. (As a security measure this variable is ignored for set-user-ID and set-group-ID programs.) """ end of excerpt In short, this is more than just LD_LIBRARY_PATH. And my preference is that *PATH*, if predefined, should be taken into consideration by find_library. In other words, the purpose of find_library is to resolve platform naming conventions of shared libraries given a 'generic' argument, e.g., find_library("c") on Linux returns libc.so.6 while for AIX it (should return) libc.a(shr4.o). As such, I would oppose a patch that only addresses the specifics of one platform. What is needed is a "design" clarification of the purpose of find_library. If we can agree on that "implementation" can follow. IMHO - trying to get a patch in for the convenience of one platform is not an architectural enhancement. Again, I would like to see the documented behavior to be that find_library returns what dlopen() would open - when given an argument is the correct platform syntax. A patch for Linux does not - formally - guarantee that documented change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 16:26:54 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 28 Jul 2016 20:26:54 +0000 Subject: [issue27645] Supporting native backup facility of SQLite In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za> Message-ID: <1469737614.48.0.613149100576.issue27645@psf.upfronthosting.co.za> R. David Murray added the comment: If you have a copy of your original agreement you could fax it to the PSF, but it is probably easier to just to sign the electronic one. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 17:13:02 2016 From: report at bugs.python.org (Zachary Ware) Date: Thu, 28 Jul 2016 21:13:02 +0000 Subject: [issue27647] Update Windows build to Tcl/Tk 8.6.6 In-Reply-To: <1469737194.88.0.144648917966.issue27647@psf.upfronthosting.co.za> Message-ID: <1469740382.89.0.534529941595.issue27647@psf.upfronthosting.co.za> Zachary Ware added the comment: I've done a test build (32-bit Release) and everything went fine. It looks like we get to drop our patches, which is enough for me to want to do this for 3.6. We historically haven't kept our Tcl/Tk sources extremely up to date on Windows, though; is there anything compelling in 8.6.[56] to warrant updating for 3.5? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 17:34:59 2016 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 28 Jul 2016 21:34:59 +0000 Subject: [issue9998] ctypes find_library should search LD_LIBRARY_PATH on Linux In-Reply-To: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za> Message-ID: <1469741699.06.0.313980620533.issue9998@psf.upfronthosting.co.za> Vinay Sajip added the comment: In my view, the best should not be the enemy of the good, and pragmatism beats purity. I don't have the resources to test this functionality on all platforms - just Windows and Linux - and am not familiar with other platforms like AIX, Solaris or the BSDs. The documentation makes clear that the behaviour of find_library is system-dependent and makes no promises of a particular level of consistency, either with dlopen() or across platforms. Nor can we guarantee in the documentation that find_library() will exactly emulate dlopen(), since that may not hold on all platforms - and in fact, since Windows is in the mix, there is little point in trying to tie find_library() behaviour to that of dlopen() directly. My documentation update makes clear that for Linux only, LD_LIBRARY_PATH will be searched if the existing mechanisms give no joy. This request has been around since 2010, and in my view implementing this long-overdue patch will improve matters for Linux users and IIUC meet the goals of the issue creator and other commenters who concurred with his sentiment. This does not preclude improving the functionality on other platforms later, but I think we should implement this patch unless someone can point out that it makes things worse in some way. If anyone can improve it, that is also to be welcomed, of course. > As such, I would oppose a patch that only addresses the specifics of one platform. Why would improving behaviour on one platform, without any API changes or needing additional work by users, be worthy of opposition? > What is needed is a "design" clarification of the purpose of find_library. > If we can agree on that "implementation" can follow. The purpose of find_library as currently documented seems adequately described, and the documentation update in my latest patch clarifies things further. IMO this is an area where the underlying platform features which find_library() relies on, as well as the run-time dynamic linking facilities available, are quite different across platforms. I'm not sure the agreement you seek will come any time soon, as it has not come in the last five years; it doesn't seem possible to aim for e.g. exact behaviour of dlopen(), because (a) it's not the same on Windows and (b) potentially varies too widely across POSIX platforms. Can you propose some change to the find_library() contract which you can assure will be implementable across all platforms? Certainly, fidelity with dlopen() isn't it. > IMHO - trying to get a patch in for the convenience of one platform is not an architectural enhancement. We're not trying for an architectural enhancement here, AFAIK. I would welcome some input from others! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 17:42:01 2016 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 28 Jul 2016 21:42:01 +0000 Subject: [issue9998] ctypes find_library should search LD_LIBRARY_PATH on Linux In-Reply-To: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za> Message-ID: <1469742121.01.0.184803891677.issue9998@psf.upfronthosting.co.za> Vinay Sajip added the comment: Added belopolsky and meador.inge to nosy as they are listed as ctypes experts in the experts index (Amaury was already there). ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 17:55:29 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 28 Jul 2016 21:55:29 +0000 Subject: [issue27598] Add SizedIterable to collections.abc and typing In-Reply-To: <1469288809.56.0.543825422436.issue27598@psf.upfronthosting.co.za> Message-ID: <1469742929.13.0.421888753201.issue27598@psf.upfronthosting.co.za> Changes by Ivan Levkivskyi : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 18:12:17 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 28 Jul 2016 22:12:17 +0000 Subject: [issue27644] Expand documentation about type aliases and NewType in the typing module In-Reply-To: <1469726944.72.0.582694680461.issue27644@psf.upfronthosting.co.za> Message-ID: <1469743937.18.0.10123252127.issue27644@psf.upfronthosting.co.za> Changes by Ivan Levkivskyi : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 18:14:08 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 28 Jul 2016 22:14:08 +0000 Subject: [issue27644] Expand documentation about type aliases and NewType in the typing module In-Reply-To: <1469726944.72.0.582694680461.issue27644@psf.upfronthosting.co.za> Message-ID: <1469744048.7.0.82350642766.issue27644@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: Added two small comments to the review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 19:57:56 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 28 Jul 2016 23:57:56 +0000 Subject: [issue27647] Update Windows build to Tcl/Tk 8.6.6 In-Reply-To: <1469737194.88.0.144648917966.issue27647@psf.upfronthosting.co.za> Message-ID: <20160728235752.24848.47353.9EAC5319@psf.io> Roundup Robot added the comment: New changeset abfda075eb37 by Zachary Ware in branch 'default': Issue #27647: Update Windows build to Tcl/Tk 8.6.6 https://hg.python.org/cpython/rev/abfda075eb37 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 20:29:40 2016 From: report at bugs.python.org (Zachary Ware) Date: Fri, 29 Jul 2016 00:29:40 +0000 Subject: [issue27647] Update Windows build to Tcl/Tk 8.6.6 In-Reply-To: <1469737194.88.0.144648917966.issue27647@psf.upfronthosting.co.za> Message-ID: <1469752180.17.0.814290786786.issue27647@psf.upfronthosting.co.za> Zachary Ware added the comment: There have also been a few updates to 8.5 since we last updated the version we ship with 2.7; has there been anything in 8.5.15-19 that we should pick up? ---------- versions: +Python 2.7 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 20:33:32 2016 From: report at bugs.python.org (Zachary Ware) Date: Fri, 29 Jul 2016 00:33:32 +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: <1469752412.64.0.28150810927.issue27355@psf.upfronthosting.co.za> Zachary Ware added the comment: See #23085 for more about our libffi situation. For this issue, with silence from Tim and Mark I say commit at will (and kill Modules/_ctypes/libffi_arm_wince/ as well). ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 20:47:45 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 29 Jul 2016 00:47:45 +0000 Subject: [issue27643] test_ctypes fails on AIX with xlc In-Reply-To: <1469718089.88.0.404760174195.issue27643@psf.upfronthosting.co.za> Message-ID: <1469753265.92.0.822905714365.issue27643@psf.upfronthosting.co.za> Martin Panter added the comment: The test seems to be comparing ctypes and native C bit-field structures, c_int and c_short versus native int and short. In general in C, if a bit-field has type ?int? without a signed or unsigned qualifier, it is up to the implementation which mode is chosen. This is different from normal, where int always means signed int. Since ctypes documents c_int as both meaning ?int? and ?signed int?, I would say that a ctypes bit-field using c_int should always behave as ?signed int?. So perhaps we should just change the test structure to use ?signed int? and ?signed short?. That should also help avoid the warnings, and may help the Solaris situation (if that is still relevant). I presume this also affects Python 3. ---------- components: +ctypes nosy: +martin.panter type: -> behavior versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 20:51:22 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 29 Jul 2016 00:51:22 +0000 Subject: [issue22645] Unable to install Python 3.4.2 amd64 on Windows 8.1 Update 1 In-Reply-To: <1413387856.31.0.878649422025.issue22645@psf.upfronthosting.co.za> Message-ID: <1469753482.23.0.135457093552.issue22645@psf.upfronthosting.co.za> Berker Peksag added the comment: This was marked as 'fixed' almost two years ago. I tried to install 3.4.3, uninstall 3.4.3 and install 3.4.4 again in Win 10 and it worked fine for me. I guess this was left open accidentally. ---------- nosy: +berker.peksag status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 21:46:40 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 29 Jul 2016 01:46:40 +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: <1469756800.08.0.804912972331.issue27397@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for narrowing this down. There are two problems: the first is that the base64 module is raising "Incorrect padding" when the issue is actually that the input string cannot be decoded using the base64 algorithm no matter what padding might be supplied. The second is that the else clause in _encoded_words *can* happen, in this circumstance. The circumstance is that the input string contains n*4+1 characters. No encoding of source text will ever produce that number of output characters. (I also seem to have used an index one greater than needed for the loop; the maximum number of padding characters is 2.) The interesting question is what we want to do for error recovery in the n*4+1 case. Do we declare the part invalid and return an empty string? Do we try chopping off the last character and see if we can decode it? The latter is complicated by the possible presence of invalid alphabet characters, but it is what I lean toward. I'm open to alternate suggestions. And to a patch if someone wants to write one :) ---------- stage: -> needs patch type: crash -> behavior versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 21:53:47 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 29 Jul 2016 01:53:47 +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: <1469757227.48.0.382609773053.issue27397@psf.upfronthosting.co.za> R. David Murray added the comment: It might be better to add a character: that will produce garbage as the last byte, but that could serve as an alert that something is wrong...and we don't know if the extra character is at the end or at the beginning of the base64 encoded string, or if, as in this case, it is multiple extra characters which will produce trailing garbage anyway. The example in hand is, I would guess, by far the most likely scenario. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 22:34:42 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 29 Jul 2016 02:34:42 +0000 Subject: [issue26462] Patch to enhance literal block language declaration In-Reply-To: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za> Message-ID: <20160729023439.71450.4844.05CAA03F@psf.io> Roundup Robot added the comment: New changeset 8ba0000c90be by Martin Panter in branch '3.5': Issue #26462: Doc: reduce literal_block warnings, fix syntax highlighting. https://hg.python.org/cpython/rev/8ba0000c90be New changeset 6fbb7c9d77c6 by Martin Panter in branch 'default': Issue #26462: Merge code block fixes from 3.5 https://hg.python.org/cpython/rev/6fbb7c9d77c6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 23:28:09 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 29 Jul 2016 03:28:09 +0000 Subject: [issue26462] Patch to enhance literal block language declaration In-Reply-To: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za> Message-ID: <1469762889.83.0.670551640096.issue26462@psf.upfronthosting.co.za> Martin Panter added the comment: Okay, leaving this open for a 2.7 patch. BTW thanks for your work; I tried to tackle these warnings a while ago, but I didn?t know enough about Sphix/RST/etc. The 2.7 change should be fairly easy; I can give it a crack if you?re not that interested in 2.7. ---------- stage: commit review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 23:28:28 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 29 Jul 2016 03:28:28 +0000 Subject: [issue26462] Patch to enhance literal block language declaration In-Reply-To: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za> Message-ID: <1469762908.81.0.535500790296.issue26462@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 23:46:09 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 29 Jul 2016 03:46:09 +0000 Subject: [issue27647] Update Windows build to Tcl/Tk 8.6.6 In-Reply-To: <1469737194.88.0.144648917966.issue27647@psf.upfronthosting.co.za> Message-ID: <1469763969.86.0.0347484295114.issue27647@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I think 3.4 and 3.5 were pretty current as of .0 release, or certainly as of .0b1. Have we updated to new unicode (9.0), like tcl? Martin used to do that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 23:53:16 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 29 Jul 2016 03:53:16 +0000 Subject: [issue17596] mingw: add wincrypt.h in Python/random.c In-Reply-To: <1364759550.1.0.784816138904.issue17596@psf.upfronthosting.co.za> Message-ID: <1469764396.26.0.244999224744.issue17596@psf.upfronthosting.co.za> Martin Panter added the comment: I think this one should be fairly safe; any breakage should be pretty obvious by watching the buildbots. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 00:05:14 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 29 Jul 2016 04:05:14 +0000 Subject: [issue17596] mingw: add wincrypt.h in Python/random.c In-Reply-To: <1364759550.1.0.784816138904.issue17596@psf.upfronthosting.co.za> Message-ID: <20160729040504.23559.56742.3BB72A59@psf.io> Roundup Robot added the comment: New changeset 11ed7c49f5df by Martin Panter in branch 'default': Issue #17596: MINGW: add wincrypt.h in Python/random.c https://hg.python.org/cpython/rev/11ed7c49f5df ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 00:13:30 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 29 Jul 2016 04:13:30 +0000 Subject: [issue17596] mingw: add wincrypt.h in Python/random.c In-Reply-To: <1364759550.1.0.784816138904.issue17596@psf.upfronthosting.co.za> Message-ID: <1469765610.14.0.843137036063.issue17596@psf.upfronthosting.co.za> Martin Panter added the comment: For the record, the first error without this patch is ../Python/random.c:26:1: error: unknown type name 'HCRYPTPROV' According to , the header to use is , but we use lowercase to avoid a problem with case sensitivity. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 00:28:41 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 29 Jul 2016 04:28:41 +0000 Subject: [issue17599] mingw: detect REPARSE_DATA_BUFFER In-Reply-To: <1364759977.57.0.233975454494.issue17599@psf.upfronthosting.co.za> Message-ID: <1469766521.0.0.257340696383.issue17599@psf.upfronthosting.co.za> Martin Panter added the comment: Leading underscore is a good idea. I have no idea if VC14 includes the structure, but I suspect if it was added with this name, we would know because it would cause the same conflict that Min GW caused. ---------- Added file: http://bugs.python.org/file43931/Py_REPARSE.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 00:54:43 2016 From: report at bugs.python.org (=?utf-8?b?6rmA7YOc7ZmY?=) Date: Fri, 29 Jul 2016 04:54:43 +0000 Subject: [issue27648] Message of webbrowser.py something wrong. Message-ID: <1469768083.59.0.550605115431.issue27648@psf.upfronthosting.co.za> New submission from ???: I'm using Python 3.5.1+ and Ubuntu 16.04. When I open new tab to Chrome using 'webbrowser.open()'. Some message prints next to shell prompt like below. ``` asd ???? ???????... ? ?? ???? ??? ?? Save Page ??? ?????! ['asd'] (Shell prompt) $ ?? ???? ??? ? ?? ??????. ``` First three line is my program's message, please don't care about them. Problem happened at final line. '?? ???? ??? ? ?? ??????.' means Program created new window to existing browser session. I think that message is for webbrowser.py and it prints with shell prompt. So, I was reading webbrowser.py simply but I cannot find where it prints message. Thanks. ---------- components: Library (Lib) messages: 271603 nosy: ??? priority: normal severity: normal status: open title: Message of webbrowser.py something wrong. type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 00:55:11 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 29 Jul 2016 04:55:11 +0000 Subject: [issue17600] mingw: build-in windows modules (winreg) In-Reply-To: <1364760067.55.0.47312643971.issue17600@psf.upfronthosting.co.za> Message-ID: <1469768111.16.0.242771885395.issue17600@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a quick merge with the current code. First concern: The patch adds special support if KEY_WOW64_64KEY is not defined, claiming to be for _WIN32_WINNT < 0x502, however these days I think Python dropped support for Windows XP etc, so we can probably drop this part. ---------- components: +Windows -Cross-Build nosy: +martin.panter, paul.moore, steve.dower, tim.golden, zach.ware stage: -> patch review versions: +Python 3.6 -Python 3.4 Added file: http://bugs.python.org/file43932/MINGW-winreg.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 01:46:55 2016 From: report at bugs.python.org (Eryk Sun) Date: Fri, 29 Jul 2016 05:46:55 +0000 Subject: [issue17599] mingw: detect REPARSE_DATA_BUFFER In-Reply-To: <1364759977.57.0.233975454494.issue17599@psf.upfronthosting.co.za> Message-ID: <1469771215.85.0.451141177941.issue17599@psf.upfronthosting.co.za> Eryk Sun added the comment: REPARSE_DATA_BUFFER is defined in the WDK filesystem header, km\ntifs.h. It's not defined in the user-mode SDK. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 01:54:55 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 29 Jul 2016 05:54:55 +0000 Subject: [issue27641] Do not build Programs/_freeze_importlib when cross-compiling In-Reply-To: <1469703884.83.0.465404999691.issue27641@psf.upfronthosting.co.za> Message-ID: <1469771695.51.0.72831568208.issue27641@psf.upfronthosting.co.za> Martin Panter added the comment: Here is another possible option. It is still a bit of a hack, because the configure script inserts comments into the makefile, but this is already done e.g. with @EXPORT_MACOSX_DEPLOYMENT_TARGET at . The advantage is we get to keep the filenames of the dependencies in the makefile, so it should be easier to read and maintain. And we get to eliminate the $(cross_compiling) check as well. In native compiling mode, everything should be as normal. When cross-compiling, the rules for regenerating files should read like Python/importlib.h: # $(srcdir)/Lib/importlib/_bootstrap.py Programs/_freeze_importlib ./Programs/_freeze_importlib \ $(srcdir)/Lib/importlib/_bootstrap.py Python/importlib.h Since the Python/importlib.h should already exist, the rule in this form (dependencies commented out) won?t be run, and Make won?t need to build Programs/_freeze_importlib either. ---------- stage: -> patch review versions: +Python 3.5 Added file: http://bugs.python.org/file43933/comment-out-regen.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 01:55:18 2016 From: report at bugs.python.org (Jami Lindh) Date: Fri, 29 Jul 2016 05:55:18 +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: <1469771718.04.0.120616976371.issue27397@psf.upfronthosting.co.za> Jami Lindh added the comment: In my opinion, this is still a clear case of "invalid input, raise an error", but I don't think AssertionError is the right one. Maybe just don't catch the unexpected binascii.Error and let it fly towards the user? I might go even one step further and just let base64 library handle and raise all the necessary errors here, similarly to how your "encode_b" function works. If you want more error resilience (meaning: email lib would not crash with invalid inputs), I would think returning an empty string is okay, since that base64 input is clearly not a valid base64 that is going to decode into anything. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 01:57:14 2016 From: report at bugs.python.org (Jami Lindh) Date: Fri, 29 Jul 2016 05:57:14 +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: <1469771834.7.0.951398293437.issue27397@psf.upfronthosting.co.za> Jami Lindh added the comment: Also, I'm not sure what is the development status in Python 3.4 but in my case this bug happened using the Debian Jessie Python version 3.4.2-2 ---------- versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 02:09:15 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 29 Jul 2016 06:09:15 +0000 Subject: [issue27131] Unit test random shuffle In-Reply-To: <1464277146.71.0.570096870767.issue27131@psf.upfronthosting.co.za> Message-ID: <1469772555.7.0.957324282668.issue27131@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I've just looked at the existing tests for random.shuffle() and found that they already cover this case and do a much more thorough job. The suggested patch doesn't add anything. Sorry, I'm going to close this one -- there isn't any problem being solved. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 02:22:11 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 29 Jul 2016 06:22:11 +0000 Subject: [issue27624] unclear documentation on Queue.qsize() In-Reply-To: <1469538053.41.0.353171937214.issue27624@psf.upfronthosting.co.za> Message-ID: <1469773331.06.0.43909440524.issue27624@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Sorry Doug, I don't find any of the suggestions to be an improvement and I concur with David Murray that the docstring for qsize() isn't the place for a tutorial on race conditions and LBYL vs EAPF which are general threading topics rather than a queue specific topics. Also, I'm reluctant to change Guido's original wording which has served well for a decade. While I'm sure you can invent ways to misread the word "approximate", it does communicate that this method cannot relied upon to return the exact size. If we were seeing recurring source of confusion, there might be a basis for a change, but that is not the case. Sorry, but I'm going to close this one. Every person might find a different way to wordsmith this one, but I think we should favor Guido's choice. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 02:33:37 2016 From: report at bugs.python.org (Jami Lindh) Date: Fri, 29 Jul 2016 06:33:37 +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: <1469774017.22.0.274413743809.issue27397@psf.upfronthosting.co.za> Jami Lindh added the comment: It might also make sense to return the payload undecoded. The documentation for get_payload() function says: "[...] the payload will be decoded if this header?s value is quoted-printable or base64. If some other encoding is used, or Content-Transfer-Encoding header is missing, the payload is returned as-is (undecoded)." Even though the header's value tries to convince you "base64" is the encoding, it is - in this case - either broken base64 or not. Hence it might fall into the category "some other encoding is used", justifying the "payload is returned as-is (undecoded)". As to the original payload Claudiu posted, in that the mailserver has truncated the email. This already provides the user with non-base64 string that they try to convince you to decode as base64. My argument is still valid in this case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 02:33:47 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 29 Jul 2016 06:33:47 +0000 Subject: [issue27639] UserList.__getitem__ doesn't account for slices In-Reply-To: <1469686507.89.0.362648270021.issue27639@psf.upfronthosting.co.za> Message-ID: <1469774027.07.0.650526231261.issue27639@psf.upfronthosting.co.za> Raymond Hettinger added the comment: As far as I can tell, there has never been a need or request for UserList slice support in its 17 year history. And since the collections ABCs were added, this class has mostly fallen into disuse and probably doesn't warrant API expansion (the module only narrowly missed being omitted from Python 3 all together). Aside from the question of whether this should be done (I am -0 on it), this patch looks correct as far as it goes. If slice support does get added to __getitem__, it should also be conferred on __setitem__ and __delitem__ as well. Besides the question of whether anyone would ever need this, there is also a minor performance consideration in that it will mildly degrade the performance of any existing code that uses UserList. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 02:44:18 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 29 Jul 2016 06:44:18 +0000 Subject: [issue27577] Make implementation and doc of tuple and list more compliant In-Reply-To: <1469002642.37.0.996165914529.issue27577@psf.upfronthosting.co.za> Message-ID: <1469774658.4.0.313277068354.issue27577@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Can you limit the doc change to just a single occurrence for list and tuple. I'm averse to filling docs with redundant, noisy notes over a very minor nuance that is more of a curiosity than an actual issue. Also, can you inline the text rather than using the ..note directive which adds more visual clutter than is warranted for something so minor. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 02:59:45 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 29 Jul 2016 06:59:45 +0000 Subject: [issue27577] Make implementation and doc of tuple and list more compliant In-Reply-To: <1469002642.37.0.996165914529.issue27577@psf.upfronthosting.co.za> Message-ID: <1469775585.76.0.40543218772.issue27577@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I agree with Raymond's comments. No 'note', and once in each doc. Perhaps 'for __ and __, the actual name of parameter 'iterable' is still 'sequence'. ('Still' would be appropriate if the functions predate iterables.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 03:01:29 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 29 Jul 2016 07:01:29 +0000 Subject: [issue27639] UserList.__getitem__ doesn't account for slices In-Reply-To: <1469686507.89.0.362648270021.issue27639@psf.upfronthosting.co.za> Message-ID: <1469775689.37.0.646772105805.issue27639@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- Removed message: http://bugs.python.org/msg271612 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 03:06:35 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 29 Jul 2016 07:06:35 +0000 Subject: [issue27639] UserList.__getitem__ doesn't account for slices In-Reply-To: <1469686507.89.0.362648270021.issue27639@psf.upfronthosting.co.za> Message-ID: <1469775995.54.0.526023673915.issue27639@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Take a look at the following code from UserList.py in Python2.7 to get an idea of how this was implemented previously: def __getslice__(self, i, j): i = max(i, 0); j = max(j, 0) return self.__class__(self.data[i:j]) def __setslice__(self, i, j, other): i = max(i, 0); j = max(j, 0) if isinstance(other, UserList): self.data[i:j] = other.data elif isinstance(other, type(self.data)): self.data[i:j] = other else: self.data[i:j] = list(other) def __delslice__(self, i, j): i = max(i, 0); j = max(j, 0) del self.data[i:j] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 03:30:50 2016 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 29 Jul 2016 07:30:50 +0000 Subject: [issue27577] Make implementation and doc of tuple and list more compliant In-Reply-To: <1469002642.37.0.996165914529.issue27577@psf.upfronthosting.co.za> Message-ID: <1469777450.58.0.430960225899.issue27577@psf.upfronthosting.co.za> Xiang Zhang added the comment: Nice to know your opinions. :) Adjust the patch to use Terry's sentence. ---------- components: +Documentation -Interpreter Core Added file: http://bugs.python.org/file43934/tuple_and_list_parameter_name_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 06:07:39 2016 From: report at bugs.python.org (Petr Viktorin) Date: Fri, 29 Jul 2016 10:07:39 +0000 Subject: [issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts In-Reply-To: <1468881013.81.0.152859673137.issue27568@psf.upfronthosting.co.za> Message-ID: <1469786859.65.0.520865262361.issue27568@psf.upfronthosting.co.za> Petr Viktorin added the comment: The conversation seems to have stalled. R?mi, are you still working on the patch? Should someone take over? ---------- nosy: +encukou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 06:26:08 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 29 Jul 2016 10:26:08 +0000 Subject: [issue27453] $CPP invocation in configure must use $CPPFLAGS In-Reply-To: <1467717523.35.0.850577639812.issue27453@psf.upfronthosting.co.za> Message-ID: <1469787968.84.0.669690063565.issue27453@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- nosy: +thomas-petazzoni _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 06:27:13 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 29 Jul 2016 10:27:13 +0000 Subject: [issue22724] byte-compile fails for cross-builds In-Reply-To: <1414194759.57.0.515625475535.issue22724@psf.upfronthosting.co.za> Message-ID: <1469788033.09.0.678900065957.issue22724@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- nosy: +thomas-petazzoni _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 06:28:10 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 29 Jul 2016 10:28:10 +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: <1469788090.68.0.146206449107.issue23968@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- nosy: +thomas-petazzoni _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 06:30:05 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 29 Jul 2016 10:30:05 +0000 Subject: [issue27606] Android cross-built for armv5te with clang and '-mthumb' crashes with SIGSEGV or SIGILL In-Reply-To: <1469363263.55.0.186080490257.issue27606@psf.upfronthosting.co.za> Message-ID: <1469788205.93.0.66609413861.issue27606@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- nosy: +thomas-petazzoni _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 06:31:09 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 29 Jul 2016 10:31:09 +0000 Subject: [issue27627] clang fails to build ctypes on Android armv7 In-Reply-To: <1469548804.03.0.253610844682.issue27627@psf.upfronthosting.co.za> Message-ID: <1469788269.96.0.667594935725.issue27627@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- nosy: +thomas-petazzoni _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 06:43:44 2016 From: report at bugs.python.org (Ian Cordasco) Date: Fri, 29 Jul 2016 10:43:44 +0000 Subject: [issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts In-Reply-To: <1468881013.81.0.152859673137.issue27568@psf.upfronthosting.co.za> Message-ID: <1469789024.8.0.828567920143.issue27568@psf.upfronthosting.co.za> Changes by Ian Cordasco : ---------- nosy: +icordasc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 06:54:15 2016 From: report at bugs.python.org (Ian Cordasco) Date: Fri, 29 Jul 2016 10:54:15 +0000 Subject: [issue27649] multiprocessing on Windows does not properly manage class attributes Message-ID: <1469789655.87.0.612290090536.issue27649@psf.upfronthosting.co.za> New submission from Ian Cordasco: In trying to add support for multiprocessing on Windows in Flake8, I found that the behaviour of the module is significantly different than on Unix. If you have a class that has class-level attributes on Unix, and you change them, put the class into a Queue (or have it attached to an object that moves through a Queue) then the values you set will be preserved [1]. On Windows [2], the attributes are reset. As a minimal reproduction, I've thrown together this project: https://github.com/sigmavirus24/windows-multiprocessing-bug which is running tox on AppVeyor (https://ci.appveyor.com/project/sigmavirus24/windows-multiprocessing-bug) and Travis CI (https://travis-ci.org/sigmavirus24/windows-multiprocessing-bug) so the behaviours can be compared. For application developers, it would be wonderful if we could rely on the standard library behaving the same way in this case across both operating systems. [1] https://travis-ci.org/sigmavirus24/windows-multiprocessing-bug/jobs/148276925#L158 https://travis-ci.org/sigmavirus24/windows-multiprocessing-bug/jobs/148276926#L158 https://travis-ci.org/sigmavirus24/windows-multiprocessing-bug/jobs/148276927#L157 [2] https://ci.appveyor.com/project/sigmavirus24/windows-multiprocessing-bug/build/1.0.2#L24 ---------- components: Windows messages: 271618 nosy: icordasc, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: multiprocessing on Windows does not properly manage class attributes type: behavior versions: Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 07:21:36 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Fri, 29 Jul 2016 11:21:36 +0000 Subject: [issue26851] android compilation and link flags In-Reply-To: <1461673211.54.0.945034926098.issue26851@psf.upfronthosting.co.za> Message-ID: <1469791296.85.0.762659072505.issue26851@psf.upfronthosting.co.za> Changes by Chi Hsuan Yen : ---------- nosy: +Chi Hsuan Yen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 07:57:42 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 29 Jul 2016 11:57:42 +0000 Subject: [issue27640] add the '--disable-test-suite' option to configure In-Reply-To: <1469700317.99.0.84265252625.issue27640@psf.upfronthosting.co.za> Message-ID: <1469793462.94.0.7074226499.issue27640@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Thanks for the review Martin. I will update the patch accordingly later. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 09:18:21 2016 From: report at bugs.python.org (Kim Randell) Date: Fri, 29 Jul 2016 13:18:21 +0000 Subject: [issue8797] urllib2 basicauth broken in 2.6.5: RuntimeError: maximum recursion depth exceeded in cmp In-Reply-To: <1274665334.09.0.561782804312.issue8797@psf.upfronthosting.co.za> Message-ID: <1469798301.09.0.360651755347.issue8797@psf.upfronthosting.co.za> Kim Randell added the comment: I don't have an example case, but from reading the code it looks as though the AbstractDigestAuthHandler has exactly the same faults as the old version of AbstractBasicAuthHandler (i.e. using req.headers.get instead of req.get_header, and corresponding retry workarounds). Should it be updated to match? ---------- nosy: +Kim Randell _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 09:28:37 2016 From: report at bugs.python.org (Michael Felt) Date: Fri, 29 Jul 2016 13:28:37 +0000 Subject: [issue9998] ctypes find_library should search LD_LIBRARY_PATH on Linux In-Reply-To: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za> Message-ID: <1469798917.41.0.807731153932.issue9998@psf.upfronthosting.co.za> Michael Felt added the comment: Vinay - I am in favor, but if the root cause of the holdup is unclear documentation then let's address the root cause. Stronger, I am in agreement. The first patch I submitted for AIX included using LIBPATH (and could have added LD_LIBRARY_PATH) - but that was rejected. > In my view, the best should not be the enemy of the good, and pragmatism beats purity. I don't have the resources to test this functionality on all platforms - just Windows and Linux - and am not familiar with other platforms like AIX, Solaris or the BSDs. The documentation makes clear that the behaviour of find_library is system-dependent and makes no promises of a particular level of consistency, either with dlopen() or across platforms. * Again, basically I agree with the principles. I do not have the resources for all linux platforms, Solaris, BSD, Windows, etc.. * As far as "other platforms" and dlopen() behavior - from the man pages I have referenced I see more similarity than difference. * behaviour of find_library is system-dependent - exactly - but unfortunately, for now AIX is whatever is in the else: box. That it works at all is a statement of the flexibility of AIX - and the sweat and tears of AIX admins to get the pieces to fit. > Nor can we guarantee in the documentation that find_library() will exactly emulate dlopen(), since that may not hold on all platforms - and in fact, since Windows is in the mix, there is little point in trying to tie find_library() behaviour to that of dlopen() directly. Good points. However, while it cannot be guaranteed - upfront - (although I would say that I could make them mimic each other on AIX given the leeway, better directive) - it can be stated as an objective for "posix". :) Windows is windows - maybe someone who knows windows well enough could make something very close. > The purpose of find_library as currently documented seems adequately described, and the documentation update in my latest patch clarifies things further. Obviously, here is where we disagree. If it was 'adequately' described you could have used the documentation as a justification years ago. Your change touches on it, but still leaves a great deal to discuss - and especially - convince those who may actually commit. > I'm not sure the agreement you seek will come any time soon, as it has not come in the last five years; it doesn't seem possible to aim for e.g. exact behaviour of dlopen(), because (a) it's not the same on Windows and (b) potentially varies too widely across POSIX platforms. Can you propose some change to the find_library() contract which you can assure will be implementable across all platforms? Certainly, fidelity with dlopen() isn't it. As you mentioned earlier - the implementations are system-dependent - so yes, we could argue for find_library search behavior that emulates dlopen() (better perhaps "LoadLibrary()") - but not define any particular behavior - precisely because it may be different on different platforms. Again, the objective is to replicate that platform's LoadLibrary search behavior - whatever that may be. Once we have established what is needed/desired as a goal, over time implementations will catch up. Linux will be leading the way because you have, presumably, already implemented it. Michael ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 09:51:42 2016 From: report at bugs.python.org (Eryk Sun) Date: Fri, 29 Jul 2016 13:51:42 +0000 Subject: [issue27649] multiprocessing on Windows does not properly manage class attributes In-Reply-To: <1469789655.87.0.612290090536.issue27649@psf.upfronthosting.co.za> Message-ID: <1469800302.41.0.2413935932.issue27649@psf.upfronthosting.co.za> Eryk Sun added the comment: Queuing the class doesn't do anything here. It gets pickled as a module attribute; the queue isn't marshaling the class dict. For example: >>> pickletools.dis(pickle.dumps(mccabe.McCabeChecker)) 0: \x80 PROTO 3 2: c GLOBAL 'mccabe McCabeChecker' 24: q BINPUT 0 26: . STOP highest protocol among opcodes = 2 Unpickling this is basically getattr(sys.modules['mccabe'], 'McCabeChecker'). So you'll see the same result if you only put ('max_complexity', 10) in the queue and hard code the class in the _target function. Of course for a system that uses fork() the class attribute is the same in the child process. In 3.4+ you can force spawning by initially calling multiprocessing.set_start_method('spawn'). Then you'll see the same result as in Windows. ---------- nosy: +eryksun versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 09:58:13 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 29 Jul 2016 13:58:13 +0000 Subject: [issue27648] Message of webbrowser.py something wrong. In-Reply-To: <1469768083.59.0.550605115431.issue27648@psf.upfronthosting.co.za> Message-ID: <1469800693.75.0.398761996558.issue27648@psf.upfronthosting.co.za> R. David Murray added the comment: Since python isn't internationalized, or even set up for someone else to do it (other than getopt/optparse/argparse, and webbrowser doesn't use those outside of __main__), I don't see how that message could be coming from Python. Most likely the message is coming from chrome itself. I'm going to close this as third party. If it turns out I'm wrong we can reopen. ---------- nosy: +r.david.murray resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 10:02:44 2016 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Rampin?=) Date: Fri, 29 Jul 2016 14:02:44 +0000 Subject: [issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts In-Reply-To: <1468881013.81.0.152859673137.issue27568@psf.upfronthosting.co.za> Message-ID: <1469800964.35.0.44569985902.issue27568@psf.upfronthosting.co.za> R?mi Rampin added the comment: I was away for a bit, I will make the requested changes tonight. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 10:09:16 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 29 Jul 2016 14:09:16 +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: <1469801355.99.0.830819385938.issue27397@psf.upfronthosting.co.za> R. David Murray added the comment: Returning the undecoded payload is a good idea. Let's go with that. The email module, unlike most stdlib packages, has a mandate that the parser should never raise an error. Instead we do our best to guess (very unlike everything else in python!) and note 'defects' in the message. The reason this is the case is Postel's Law, which has become one of the guiding principles in dealing with email over the years: "be conservative in what you do, and generous in what you accept". So, the generator will raise errors (if the original input didn't come from the parser), but the parser will not, if at all possible. (For those who want aggressive error checking, python3 the 'raise_on_defect' policy setting.) For the versions, we use that field to indicate which versions the bug will get fixed in, which is why I removed 3.4. ---------- versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 10:13:06 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 29 Jul 2016 14:13:06 +0000 Subject: [issue27624] unclear documentation on Queue.qsize() In-Reply-To: <1469538053.41.0.353171937214.issue27624@psf.upfronthosting.co.za> Message-ID: <1469801586.81.0.208939420044.issue27624@psf.upfronthosting.co.za> R. David Murray added the comment: Doug: side note. Raymond teaches Python, and makes a study of what works and doesn't work in communicating it to students, so he isn't rejecting this lightly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 10:20:47 2016 From: report at bugs.python.org (Ian Cordasco) Date: Fri, 29 Jul 2016 14:20:47 +0000 Subject: [issue27649] multiprocessing on Windows does not properly manage class attributes In-Reply-To: <1469789655.87.0.612290090536.issue27649@psf.upfronthosting.co.za> Message-ID: <1469802047.87.0.550685600304.issue27649@psf.upfronthosting.co.za> Ian Cordasco added the comment: Why did you remove Python 3.3? It's still affected by this behaviour. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 10:23:49 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 29 Jul 2016 14:23:49 +0000 Subject: [issue27649] multiprocessing on Windows does not properly manage class attributes In-Reply-To: <1469789655.87.0.612290090536.issue27649@psf.upfronthosting.co.za> Message-ID: <1469802229.79.0.235579555648.issue27649@psf.upfronthosting.co.za> R. David Murray added the comment: Right this is a fork vs spawn issue, not a bug. I don't know why Eryk changed the versions the way he did, but FYI we use that field to indicate which version we will apply a patch to, so it is pretty much irrelevant when there isn't actually a bug :) ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 10:27:07 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 29 Jul 2016 14:27:07 +0000 Subject: [issue8797] urllib2 basicauth broken in 2.6.5: RuntimeError: maximum recursion depth exceeded in cmp In-Reply-To: <1274665334.09.0.561782804312.issue8797@psf.upfronthosting.co.za> Message-ID: <1469802427.43.0.966938410569.issue8797@psf.upfronthosting.co.za> R. David Murray added the comment: Kim: if you can prove it is broken, please open a new issue, this one is closed (you can reference it by just typing # followed by the issue number, and the tracker will automatically make a link). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 10:27:49 2016 From: report at bugs.python.org (=?utf-8?b?6rmA7YOc7ZmY?=) Date: Fri, 29 Jul 2016 14:27:49 +0000 Subject: [issue27648] Message of webbrowser.py something wrong. In-Reply-To: <1469800693.75.0.398761996558.issue27648@psf.upfronthosting.co.za> Message-ID: <579b66c3358d1d0001c400ad@polymail.io> ??? added the comment: I think you?re right. I also think that Korean message(final line) prints by chrome. (Another lines printed by my own codes, please don?t care) But I used webbrowser.open() code to outside of __main__. I will test my codes from other web browser (like Firefox) Thank you for replying!? On 2016? 7? 29? (?) at ?? 10:58 "R. David Murray" < mailto: > wrote: R. David Murray added the comment: Since python isn't internationalized, or even set up for someone else to do it (other than getopt/optparse/argparse, and webbrowser doesn't use those outside of __main__), I don't see how that message could be coming from Python. Most likely the message is coming from chrome itself. I'm going to close this as third party. If it turns out I'm wrong we can reopen. ---------- nosy: +r.david.murray resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker < mailto:report at bugs.python.org > < http://bugs.python.org/issue27648 > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 10:50:44 2016 From: report at bugs.python.org (Michael Felt) Date: Fri, 29 Jul 2016 14:50:44 +0000 Subject: [issue27435] ctypes and AIX - also for 2.7.X (and later) In-Reply-To: <1467383699.63.0.495142233463.issue27435@psf.upfronthosting.co.za> Message-ID: <1469803844.4.0.802084217824.issue27435@psf.upfronthosting.co.za> Michael Felt added the comment: """ Lib/ctype support for LoadLibrary interface to dlopen() for AIX Similar kind of support (i.e., as a separate file) as has been done for Darwin support ctype.macholib.* rather than as been done with for "ce", "nt", "solaris", and "bsd" with separate, detailed if: sections in utils.py Author: M Felt, aixtools.net, July 2016 """ ---------- keywords: +patch Added file: http://bugs.python.org/file43935/issue27435_ctypes_aix_support.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 10:54:41 2016 From: report at bugs.python.org (Steve Dower) Date: Fri, 29 Jul 2016 14:54:41 +0000 Subject: [issue17599] mingw: detect REPARSE_DATA_BUFFER In-Reply-To: <1364759977.57.0.233975454494.issue17599@psf.upfronthosting.co.za> Message-ID: <1469804081.67.0.26545040358.issue17599@psf.upfronthosting.co.za> Steve Dower added the comment: I think the WDK is still separate from the Windows SDK, so probably best to keep the custom definition with a comment specifying which file it came from (so whoever diagnoses an obscure issue in the future can find it quickly). With the comment, I'm fine with the patch. If you haven't built on MSVC then keep an eye on the build bots until it goes through in case something unpredictable happens. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 11:24:01 2016 From: report at bugs.python.org (Ram Rachum) Date: Fri, 29 Jul 2016 15:24:01 +0000 Subject: [issue27604] More details about `-O` flag In-Reply-To: <1469353581.38.0.811049911305.issue27604@psf.upfronthosting.co.za> Message-ID: <1469805841.55.0.47685701088.issue27604@psf.upfronthosting.co.za> Ram Rachum added the comment: I uploaded a new patch. I added another thing: Mentioning explicitly that no other optimizations are currently being made. I think this is important because it's often the question that the user is asking themselves. (At least my boss and team members have asked that, and people on Stack Overflow.) I disagree with your suggestion to limit the change only to veryhigh.rst and link to there from cmdline.rst. I think this is an important piece of information so it should be available in cmdline.rst which is more visible than the technical veryhigh.rst. If you feel strongly about this issue let me know and I'll do it your way. ---------- Added file: http://bugs.python.org/file43936/2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 11:41:33 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 29 Jul 2016 15:41:33 +0000 Subject: [issue27453] $CPP invocation in configure must use $CPPFLAGS In-Reply-To: <1467717523.35.0.850577639812.issue27453@psf.upfronthosting.co.za> Message-ID: <1469806893.32.0.837180448991.issue27453@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- nosy: +haypo stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 11:43:17 2016 From: report at bugs.python.org (Michael Felt) Date: Fri, 29 Jul 2016 15:43:17 +0000 Subject: [issue27643] test_ctypes fails on AIX with xlc In-Reply-To: <1469718089.88.0.404760174195.issue27643@psf.upfronthosting.co.za> Message-ID: <1469806997.37.0.474504957387.issue27643@psf.upfronthosting.co.za> Michael Felt added the comment: > I presume this also affects Python 3. I presume this as well - however, harder to verify... michael at x071:[/data/prj/aixtools/python/python-3.6.0.162/Lib/ctypes/test]../../../python test_bitfield.py Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] Failed to import the site module Traceback (most recent call last): File "/data/prj/aixtools/python/python-3.6.0.162/Lib/ctypes/test/../../../Lib/site.py", line 571, in main() File "/data/prj/aixtools/python/python-3.6.0.162/Lib/ctypes/test/../../../Lib/site.py", line 557, in main known_paths = addusersitepackages(known_paths) File "/data/prj/aixtools/python/python-3.6.0.162/Lib/ctypes/test/../../../Lib/site.py", line 281, in addusersitepackages user_site = getusersitepackages() File "/data/prj/aixtools/python/python-3.6.0.162/Lib/ctypes/test/../../../Lib/site.py", line 257, in getusersitepackages user_base = getuserbase() # this will also set USER_BASE File "/data/prj/aixtools/python/python-3.6.0.162/Lib/ctypes/test/../../../Lib/site.py", line 247, in getuserbase USER_BASE = get_config_var('userbase') File "/data/prj/aixtools/python/python-3.6.0.162/Lib/sysconfig.py", line 587, in get_config_var return get_config_vars().get(name) File "/data/prj/aixtools/python/python-3.6.0.162/Lib/sysconfig.py", line 536, in get_config_vars _init_posix(_CONFIG_VARS) File "/data/prj/aixtools/python/python-3.6.0.162/Lib/sysconfig.py", line 408, in _init_posix from _sysconfigdata import build_time_vars ImportError: No module named '_sysconfigdata' I guess I will have to install it, rather than only work from a test directory. > The test seems to be comparing ctypes and native C bit-field structures, c_int and c_short versus native int and short. ... int always means signed int. I believe int means signed on AIX as well - as the comment from the compiler is that type "unsigned" is assumed for a bitfield. Note: the single line of code is: +382 short M: 1, N: 2, O: 3, P: 4, Q: 5, R: 6, S: 7; And from your comments I am wondering if the fix is 'simple' - to: +382 unsigned short M: 1, N: 2, O: 3, P: 4, Q: 5, R: 6, S: 7; I can at least try that. Looking at Python-3.6.0.0a2: the line concerned is identical - so that is the verification (for now) that it is also in Python3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 11:55:35 2016 From: report at bugs.python.org (Michael Felt) Date: Fri, 29 Jul 2016 15:55:35 +0000 Subject: [issue27643] test_ctypes fails on AIX with xlc In-Reply-To: <1469718089.88.0.404760174195.issue27643@psf.upfronthosting.co.za> Message-ID: <1469807735.57.0.532942329448.issue27643@psf.upfronthosting.co.za> Michael Felt added the comment: FYI - after a couple of test compiles, it seems that IBM XLC does not report a message when the size specified is int, unsigned or long (i.e., does not like short). Are you interested in the results using a size other than short - or would that break something else I cannot forsee? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 12:26:50 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 29 Jul 2016 16:26:50 +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: <1469809610.11.0.175852371984.issue23968@psf.upfronthosting.co.za> Xavier de Gaye added the comment: To reproduce the problem on any system where Python is built with configure: $ mkdir -p tmp/build tmp/install $ cd tmp $ hg clone https://hg.python.org/cpython cpython $ cd build $ $(cd ../cpython && pwd)/configure --prefix=$(cd ../install && pwd) && make install $ ../install/bin/python3 -m test -v test_sysconfig [snip] ====================================================================== FAIL: test_srcdir (test.test_sysconfig.TestSysConfig) ---------------------------------------------------------------------- Traceback (most recent call last): File "/path_to/tmp/install/lib/python3.6/test/test_sysconfig.py", line 346, in test _srcdir self.assertTrue(os.path.isdir(srcdir), srcdir) AssertionError: False is not true : /path_to/tmp/install/lib/python3.6/config-3.6m ====================================================================== FAIL: test_get_makefile_filename (test.test_sysconfig.MakefileTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/path_to/tmp/install/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 : /path_to/tmp/install/lib/python3.6/config-3.6m/Makefile ---------------------------------------------------------------------- Ran 21 tests in 0.063s FAILED (failures=2, skipped=2) test test_sysconfig failed test_sysconfig failed 1 test failed: test_sysconfig Total duration: 0:00:01 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 12:36:34 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 29 Jul 2016 16:36:34 +0000 Subject: [issue27641] Do not build Programs/_freeze_importlib when cross-compiling In-Reply-To: <1469703884.83.0.465404999691.issue27641@psf.upfronthosting.co.za> Message-ID: <1469810194.21.0.420677645004.issue27641@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- nosy: +xdegaye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 13:04:48 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 29 Jul 2016 17:04:48 +0000 Subject: [issue27453] $CPP invocation in configure must use $CPPFLAGS In-Reply-To: <1467717523.35.0.850577639812.issue27453@psf.upfronthosting.co.za> Message-ID: <1469811888.24.0.24589748534.issue27453@psf.upfronthosting.co.za> STINNER Victor added the comment: ndk-clang-preprocessor.patch LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 13:21:40 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 29 Jul 2016 17:21:40 +0000 Subject: [issue27604] More details about `-O` flag In-Reply-To: <1469353581.38.0.811049911305.issue27604@psf.upfronthosting.co.za> Message-ID: <1469812900.81.0.854473931404.issue27604@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Ram > (At least my boss and team members have asked that, and people on Stack Overflow.) Ram, to me it would have been helpful if you had said this initially. It gives a doc change request a bit more force. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 13:47:03 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 29 Jul 2016 17:47:03 +0000 Subject: [issue27604] More details about `-O` flag In-Reply-To: <1469353581.38.0.811049911305.issue27604@psf.upfronthosting.co.za> Message-ID: <1469814423.16.0.00253134235527.issue27604@psf.upfronthosting.co.za> R. David Murray added the comment: I think the cmdline ref telling you that optimizations are enabled or disabled is enough. If someone wants technical information they can click on the link. For comparison, the gcc man page lists what optimizations the -O levels enable, but does not explain them. To understand what it does you must follow the "links" to the referenced optimization options. If python had separate options for the individual optimizations we could do likewise, but we don't, so linking to the technical explanation seems like the logical thing to do instead. Perhaps we can get the opinion of some other devs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 13:56:25 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 29 Jul 2016 17:56:25 +0000 Subject: [issue27605] Inconsistent calls to __eq__ from built-in __contains__ In-Reply-To: <1469362395.06.0.246923750082.issue27605@psf.upfronthosting.co.za> Message-ID: <1469814985.95.0.332912967763.issue27605@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Here is a more accurate 'equivalent': "any(x is e or for e in )" where 'candidate members' is "members with the same hash as x" for built-in hash-based collections and 'all members' for built-in unsorted sequences". I am sure that built-in range does a direct calculation. Instead of the above, I suggest this. "For general collections, such as list, tuple, collections.deque, and most iterables, the expression `x in y` is usually equivalent to `any(x is e or x == e for e in y)`." Hash-based collections should not be mentioned in such a sentence as the equivalency is completely wrong, as Steven noted. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 14:03:20 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 29 Jul 2016 18:03:20 +0000 Subject: [issue27613] Empty iterator is rendered as a single bracket ] when using json's iterencode In-Reply-To: <1469446931.7.0.792781039481.issue27613@psf.upfronthosting.co.za> Message-ID: <1469815400.47.0.754476985128.issue27613@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I am surprised that dumping to a string and to a file give different answers. This strikes me as a bug in any case. I would expect the the main difference would be file.write(chunk) versus temlist.append(chunk). ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 14:41:25 2016 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 29 Jul 2016 18:41:25 +0000 Subject: [issue9998] ctypes find_library should search LD_LIBRARY_PATH on Linux In-Reply-To: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za> Message-ID: <1469817685.49.0.45514672.issue9998@psf.upfronthosting.co.za> Changes by Vinay Sajip : Added file: http://bugs.python.org/file43937/refresh-2016-07-29.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 15:40:40 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Fri, 29 Jul 2016 19:40:40 +0000 Subject: [issue27644] Expand documentation about type aliases and NewType in the typing module In-Reply-To: <1469726944.72.0.582694680461.issue27644@psf.upfronthosting.co.za> Message-ID: <1469821240.02.0.0671812470687.issue27644@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: > Should I edit the patch to include a sentence or two describing this > distinction, just remove the word "almost", or do something else? I think the best way is to remove the "almost" and briefly explain that you cannot subclass types returned by NewType. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 15:58:17 2016 From: report at bugs.python.org (Ram Rachum) Date: Fri, 29 Jul 2016 19:58:17 +0000 Subject: [issue27604] More details about `-O` flag In-Reply-To: <1469353581.38.0.811049911305.issue27604@psf.upfronthosting.co.za> Message-ID: <1469822297.59.0.640744489981.issue27604@psf.upfronthosting.co.za> Ram Rachum added the comment: Hi David, I attached a patch that follows your instructions, but to be honest, if I wasn't the person writing this patch and I wanted to find the information "Does Python do any optimization besides dumping asserts when I do -O?" I'm not sure I'd be able to understand the information from the docs with 3.patch applied. The documentation doesn't clearly state that `-O` causes an `optimize` value of 1. If it did it'll be a bit easier to understand. Still too difficult in my opinion (which is why I would personally put this information directly in cmdline.rst) but maybe a bit easier. ---------- Added file: http://bugs.python.org/file43938/3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 15:59:52 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 29 Jul 2016 19:59:52 +0000 Subject: [issue27604] More details about `-O` flag In-Reply-To: <1469353581.38.0.811049911305.issue27604@psf.upfronthosting.co.za> Message-ID: <1469822392.94.0.187731652479.issue27604@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The -O entry is unchanged from when the Using doc was added in 2007. I believe there has been discussion about being more specific and that Guido said something, but that is the most I will say. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 16:04:40 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 29 Jul 2016 20:04:40 +0000 Subject: [issue27524] Update os.path for PEP 519/__fspath__() In-Reply-To: <1468616792.91.0.199248434704.issue27524@psf.upfronthosting.co.za> Message-ID: <1469822680.75.0.0434922582006.issue27524@psf.upfronthosting.co.za> Brett Cannon added the comment: Ran into the first nasty snag: people are abusing os.path.commonprefix() and it's extremely generic approach. Instead of passing in a list of file paths they are passing a list of lists of file path *parts*, e.g. instead of ["a/b", "a/c"] they are passing in [["a", "b"], ["a", "c"]]. I have special-cased when the list contains another list or tuple, but I still feel dirty doing it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 16:09:25 2016 From: report at bugs.python.org (Ram Rachum) Date: Fri, 29 Jul 2016 20:09:25 +0000 Subject: [issue27650] Implement `__repr__` methods for logging.Logger and others Message-ID: <1469822965.14.0.109412472968.issue27650@psf.upfronthosting.co.za> New submission from Ram Rachum: A while ago I was debugging through code that uses the `logging` module, and I was looking at `Logger` objects and possibly other kinds of objects (maybe handlers? It was a while ago.) I was frustrated because I was trying to figure out what a particular logger was, but typing `logger` in the shell just showed the opaque ``. I would like to know the name of the logger without bothering to do `logger.name`. I suggest that we do a run over the `logging` module and see which classes could have a helpful `__repr__` added to them. I might have time to do this, but first I want to know whether there is a general agreement that such a patch would be welcome. ---------- components: Library (Lib) messages: 271646 nosy: cool-RR, vinay.sajip priority: normal severity: normal status: open title: Implement `__repr__` methods for logging.Logger and others type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 16:41:46 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 29 Jul 2016 20:41:46 +0000 Subject: [issue27641] Do not build Programs/_freeze_importlib when cross-compiling In-Reply-To: <1469703884.83.0.465404999691.issue27641@psf.upfronthosting.co.za> Message-ID: <1469824906.12.0.552376798207.issue27641@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Nice. FWIW cross-compilation for Android works fine with comment-out-regen.patch. > In native compiling mode, everything should be as normal. When cross-compiling, the rules for regenerating files should read like > > Python/importlib.h: # $(srcdir)/Lib/importlib/_bootstrap.py Programs/_freeze_importlib > ./Programs/_freeze_importlib \ > $(srcdir)/Lib/importlib/_bootstrap.py Python/importlib.h They do read like this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 17:09:27 2016 From: report at bugs.python.org (Michael Lee) Date: Fri, 29 Jul 2016 21:09:27 +0000 Subject: [issue27644] Expand documentation about type aliases and NewType in the typing module In-Reply-To: <1469726944.72.0.582694680461.issue27644@psf.upfronthosting.co.za> Message-ID: <1469826567.44.0.583185500314.issue27644@psf.upfronthosting.co.za> Michael Lee added the comment: Ok, here's revision 2 of my patch, after applying the changes from the last round of feedback. ---------- Added file: http://bugs.python.org/file43939/document_newtype_rev2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 17:16:05 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 29 Jul 2016 21:16:05 +0000 Subject: [issue26942] android: test_ctypes crashes on armv7 and aarch64 In-Reply-To: <1462290789.53.0.483745295219.issue26942@psf.upfronthosting.co.za> Message-ID: <1469826965.62.0.366862948398.issue26942@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > By msg264746, only ARM fails, so I patch libffi for arm and aarch64 triplets only Why not for all Android architectures (*-linux-android*) as it is done in PR120 ? ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 17:25:54 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Fri, 29 Jul 2016 21:25:54 +0000 Subject: [issue27644] Expand documentation about type aliases and NewType in the typing module In-Reply-To: <1469726944.72.0.582694680461.issue27644@psf.upfronthosting.co.za> Message-ID: <1469827554.16.0.413969072539.issue27644@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: I have only one optional comment on the second revision. ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 17:31:20 2016 From: report at bugs.python.org (ppperry) Date: Fri, 29 Jul 2016 21:31:20 +0000 Subject: [issue27613] Empty iterator with fake __len__ is rendered as a single bracket ] when using json's iterencode In-Reply-To: <1469446931.7.0.792781039481.issue27613@psf.upfronthosting.co.za> Message-ID: <1469827880.42.0.734032900193.issue27613@psf.upfronthosting.co.za> Changes by ppperry : ---------- title: Empty iterator is rendered as a single bracket ] when using json's iterencode -> Empty iterator with fake __len__ is rendered as a single bracket ] when using json's iterencode _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 17:35:50 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 29 Jul 2016 21:35:50 +0000 Subject: [issue1521950] shlex.split() does not tokenize like the shell Message-ID: <20160729213547.26562.41790.1DE83271@psf.io> Roundup Robot added the comment: New changeset ea99e2f0b829 by Vinay Sajip in branch 'default': Closes #1521950: Made shlex parsing more shell-like. https://hg.python.org/cpython/rev/ea99e2f0b829 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 17:45:31 2016 From: report at bugs.python.org (Kevin Dwyer) Date: Fri, 29 Jul 2016 21:45:31 +0000 Subject: [issue19837] Wire protocol encoding for the JSON module In-Reply-To: <1385778645.87.0.0800898315059.issue19837@psf.upfronthosting.co.za> Message-ID: <1469828731.83.0.465127593286.issue19837@psf.upfronthosting.co.za> Changes by Kevin Dwyer : ---------- nosy: +kdwyer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 17:46:58 2016 From: report at bugs.python.org (Mark Roseman) Date: Fri, 29 Jul 2016 21:46:58 +0000 Subject: [issue27621] Finish IDLE Query dialog appearance and behavior. In-Reply-To: <1469512966.74.0.594331033204.issue27621@psf.upfronthosting.co.za> Message-ID: <1469828818.06.0.287495142331.issue27621@psf.upfronthosting.co.za> Mark Roseman added the comment: Terry, thanks for the TkDocs correction. As you'll note from the attached dlgonmac.png, there's a bit of tweaking needed with regard to geometry management etc. to get the background right. Now that ttk is ok (so to speak), would you be open to some patches that fix this up, a bit more akin to what you see in the 'query dialog' subsection if you scroll down a bit in http://www.tkdocs.com/tutorial/idle.html#idledialogs Separately, would you be open to a patch changing things to use the "inline" error handling illustrated on the goto line dialog on that page (i.e. showing error message in query dialog in red vs. popping up an alert)? Older code for that can be found here btw: https://github.com/roseman/idle/blob/master/querydialog.py ---------- Added file: http://bugs.python.org/file43940/dlgonmac.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 17:53:40 2016 From: report at bugs.python.org (Mark Roseman) Date: Fri, 29 Jul 2016 21:53:40 +0000 Subject: [issue27477] IDLE: Switch dialogs to ttk widgets. In-Reply-To: <1468181977.57.0.555586182066.issue27477@psf.upfronthosting.co.za> Message-ID: <1469829220.41.0.228432439051.issue27477@psf.upfronthosting.co.za> Mark Roseman added the comment: Great start. Needs to have a ttk.Frame directly inside the toplevel window to avoid whitespace showing around grey widgets (like in query dialog shot). I'd also like to see the spacing adjusted (all platforms) and button positions changed on Mac to go at the bottom, as per http://www.tkdocs.com/tutorial/idle.html#idledialogs Open to a patch that does that? ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 18:29:23 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 29 Jul 2016 22:29:23 +0000 Subject: [issue27524] Update os.path for PEP 519/__fspath__() In-Reply-To: <1468616792.91.0.199248434704.issue27524@psf.upfronthosting.co.za> Message-ID: <1469831363.07.0.165702895295.issue27524@psf.upfronthosting.co.za> Brett Cannon added the comment: Here is a patch that includes the previous tests as long with fixes which don't involve stat or lstat (once those functions are updated themselves then os.path will be ported). ---------- Added file: http://bugs.python.org/file43941/os_path.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 18:40:21 2016 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 29 Jul 2016 22:40:21 +0000 Subject: [issue27644] Expand documentation about type aliases and NewType in the typing module In-Reply-To: <1469726944.72.0.582694680461.issue27644@psf.upfronthosting.co.za> Message-ID: <1469832021.64.0.975278174979.issue27644@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks! Should go live later today. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 18:42:45 2016 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 29 Jul 2016 22:42:45 +0000 Subject: [issue27644] Expand documentation about type aliases and NewType in the typing module In-Reply-To: <1469726944.72.0.582694680461.issue27644@psf.upfronthosting.co.za> Message-ID: <1469832165.16.0.432162580363.issue27644@psf.upfronthosting.co.za> Guido van Rossum added the comment: Mercurial revs: fd0dce6d33e7, 15a35a8da24b, 4ecea1ea11bf, 4ecea1ea11bf. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 20:01:18 2016 From: report at bugs.python.org (Anders Lorentsen) Date: Sat, 30 Jul 2016 00:01:18 +0000 Subject: [issue27623] int.to_bytes() and int.from_bytes(): raise ValueError when bytes count is zero In-Reply-To: <1469514380.74.0.642597369558.issue27623@psf.upfronthosting.co.za> Message-ID: <1469836878.16.0.209353682817.issue27623@psf.upfronthosting.co.za> Anders Lorentsen added the comment: I updated my patch to account for that second corner case. But ideally, shouldn't it rather be accounted for in the function that does the actual conversion, that is, in _PyLong_AsByteArray? ---------- Added file: http://bugs.python.org/file43942/int_to_bytes_overflow_cornercase2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 20:11:48 2016 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Rampin?=) Date: Sat, 30 Jul 2016 00:11:48 +0000 Subject: [issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts In-Reply-To: <1468881013.81.0.152859673137.issue27568@psf.upfronthosting.co.za> Message-ID: <1469837508.47.0.340497489406.issue27568@psf.upfronthosting.co.za> Changes by R?mi Rampin : Removed file: http://bugs.python.org/file43800/python-2.7-httpoxy.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 20:11:49 2016 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Rampin?=) Date: Sat, 30 Jul 2016 00:11:49 +0000 Subject: [issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts In-Reply-To: <1468881013.81.0.152859673137.issue27568@psf.upfronthosting.co.za> Message-ID: <1469837509.43.0.976109046686.issue27568@psf.upfronthosting.co.za> Changes by R?mi Rampin : Removed file: http://bugs.python.org/file43801/python-3.5-httpoxy.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 20:12:14 2016 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Rampin?=) Date: Sat, 30 Jul 2016 00:12:14 +0000 Subject: [issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts In-Reply-To: <1468881013.81.0.152859673137.issue27568@psf.upfronthosting.co.za> Message-ID: <1469837534.58.0.0849353366931.issue27568@psf.upfronthosting.co.za> Changes by R?mi Rampin : Added file: http://bugs.python.org/file43943/python-2.7-httpoxy.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 20:13:03 2016 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Rampin?=) Date: Sat, 30 Jul 2016 00:13:03 +0000 Subject: [issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts In-Reply-To: <1468881013.81.0.152859673137.issue27568@psf.upfronthosting.co.za> Message-ID: <1469837583.8.0.0842653793184.issue27568@psf.upfronthosting.co.za> R?mi Rampin added the comment: Here it goes - Clarified that _proxy suffix should be lowercase - Indented ..note: blocks under function/class ---------- Added file: http://bugs.python.org/file43944/python-3.5-httpoxy.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 20:51:55 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 30 Jul 2016 00:51:55 +0000 Subject: [issue27643] test_ctypes fails on AIX with xlc In-Reply-To: <1469718089.88.0.404760174195.issue27643@psf.upfronthosting.co.za> Message-ID: <1469839915.17.0.167633993095.issue27643@psf.upfronthosting.co.za> Martin Panter added the comment: Looks like your Python 3 build is messed up. Maybe it doesn?t like running from a different directory. I would try from the main build directory, and note the test_bitfields has an S: ./python -m unittest -v ctypes.test.test_bitfields What I am suggesting as a fix is to change line 381 from plain ?int? to ?signed int?, and 382 to ?signed short?. I can make a patch later if that will help. Hopefully with these changes the C compiler will use signed integer logic, matching what I believe the ctypes library uses for c_int and c_short. Using a type other than short is not right, because the Python test is explicitly trying to test c_short behaviour. If your compiler does not support ?signed short? bitfields, maybe we just have to accept that ctypes supports it even though the compiler doesn?t, and skip the test. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 21:21:55 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 30 Jul 2016 01:21:55 +0000 Subject: [issue27623] int.to_bytes() and int.from_bytes(): raise ValueError when bytes count is zero In-Reply-To: <1469514380.74.0.642597369558.issue27623@psf.upfronthosting.co.za> Message-ID: <1469841715.79.0.66368354338.issue27623@psf.upfronthosting.co.za> Martin Panter added the comment: I?m not familiar with the implementation, but it does seem like this should be fixed within _PyLong_AsByteArray(). Also, what about int.from_bytes(b"", ..., signed=True)? There are existing tests for this case, but it seems like it should be an error, rather than returning zero. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 23:46:24 2016 From: report at bugs.python.org (Jason R. Coombs) Date: Sat, 30 Jul 2016 03:46:24 +0000 Subject: [issue24672] shutil.rmtree fails on non ascii filenames In-Reply-To: <1437381607.37.0.102405626215.issue24672@psf.upfronthosting.co.za> Message-ID: <1469850384.71.0.956677672537.issue24672@psf.upfronthosting.co.za> Jason R. Coombs added the comment: I've confirmed the issue. It does indeed only occur if the string passed to rmtree is bytes. I discovered this during my investigation of https://github.com/cherrypy/cherrypy/issues/1467. The following script will replicate the failure on Windows systems on Python 2 and Python 3, but not on other operating systems: --- # encoding: utf-8 from __future__ import unicode_literals import os import shutil os.mkdir('temp') with open('temp/????? ???????.html', 'w'): pass print(os.listdir(b'temp')[0]) shutil.rmtree(b'temp') --- The error on Python 2.7 is this: ????? ???????.html Traceback (most recent call last): File "C:\Users\jaraco\p\cherrypy\issue-1467.py", line 15, in shutil.rmtree(b'temp') File "C:\Program Files\Python27\lib\shutil.py", line 252, in rmtree onerror(os.remove, fullname, sys.exc_info()) File "C:\Program Files\Python27\lib\shutil.py", line 250, in rmtree os.remove(fullname) WindowsError: [Error 123] The filename, directory name, or volume label syntax is incorrect: 'temp\\????? ???????.html' This issue might be related to issue25911 or issue24230 or issue18713 or issue16656 or issue9820 and probably others. It's not obvious to me browsing through those tickets why Windows should behave differently when a bytestring is passed to listdir. Perhaps I'll delve into those tickets in more depth. ---------- nosy: +jason.coombs title: shutil.rmtree failes on non ascii filenames -> shutil.rmtree fails on non ascii filenames versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 00:03:28 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sat, 30 Jul 2016 04:03:28 +0000 Subject: [issue26942] android: test_ctypes crashes on armv7 and aarch64 In-Reply-To: <1462290789.53.0.483745295219.issue26942@psf.upfronthosting.co.za> Message-ID: <1469851408.53.0.0400797762907.issue26942@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: You're right. I thought the default malloc() implementation is better, and now I think a unified implementation on Android brings less surprises. ---------- Added file: http://bugs.python.org/file43945/libffi-pr240.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 00:15:40 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 30 Jul 2016 04:15:40 +0000 Subject: [issue27621] Finish IDLE Query dialog appearance and behavior. In-Reply-To: <1469512966.74.0.594331033204.issue27621@psf.upfronthosting.co.za> Message-ID: <1469852140.69.0.702938949004.issue27621@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In Tk widgets tk_dialog and tk_messageBox (corresponding Tkinter widgets dialog.Dialog and messagebox.Message) pressing Return invokes focused button. The comment in tk_dialog implementation: # 4. Create a binding for on the dialog if there is a # default button. # Convention also dictates that if the keyboard focus moves among the # the buttons that the binding affects the button with the focus. I expected the same behavior in IDLE Query dialog. If this behavior considered outdated, I'm nice to close this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 00:55:52 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 30 Jul 2016 04:55:52 +0000 Subject: [issue24672] shutil.rmtree fails on non ascii filenames In-Reply-To: <1437381607.37.0.102405626215.issue24672@psf.upfronthosting.co.za> Message-ID: <1469854552.06.0.373693637864.issue24672@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issue16700. On Windows there are two sets of API: Unicode and bytes. File names are stored in Unicode (UTF-16) in modern filesystems and encoded to bytes by system for bytes API. Unfortunately this encoding is lossfull. Windows try to find the closest equivalent if the character is not encodable with current codepage (for example drops diacritics) and silently replaces it with "?" if can't find anything appropriate. We can't do anything with this from Python side except using Unicode API. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 01:05:25 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 30 Jul 2016 05:05:25 +0000 Subject: [issue27366] PEP487: Simpler customization of class creation In-Reply-To: <1466579967.76.0.483118833643.issue27366@psf.upfronthosting.co.za> Message-ID: <1469855125.48.0.190949940268.issue27366@psf.upfronthosting.co.za> Nick Coghlan added the comment: Martin's latest patch looks good to me, so I'm applying it now and will push it once a local run of the test suite gives it the thumbs up :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 02:22:00 2016 From: report at bugs.python.org (STINNER Victor) Date: Sat, 30 Jul 2016 06:22:00 +0000 Subject: [issue24672] shutil.rmtree fails on non ascii filenames In-Reply-To: <1469850384.71.0.956677672537.issue24672@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Use Unicode on Python 3, it will work on all platforms. Problem solved :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 02:26:27 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 Jul 2016 06:26:27 +0000 Subject: [issue27366] PEP487: Simpler customization of class creation In-Reply-To: <1466579967.76.0.483118833643.issue27366@psf.upfronthosting.co.za> Message-ID: <20160730062622.31274.66023.CF07F4A4@psf.io> Roundup Robot added the comment: New changeset ecc7bff738e0 by Nick Coghlan in branch 'default': Issue #27366: Implement PEP 487 https://hg.python.org/cpython/rev/ecc7bff738e0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 02:41:30 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 30 Jul 2016 06:41:30 +0000 Subject: [issue27366] PEP487: Simpler customization of class creation In-Reply-To: <1466579967.76.0.483118833643.issue27366@psf.upfronthosting.co.za> Message-ID: <1469860890.65.0.837673301625.issue27366@psf.upfronthosting.co.za> Nick Coghlan added the comment: Thanks once again Martin, especially for your patience with the long process in getting this proposal all the way through to resolution :) I mostly applied your patch as-is, but tweaked a few aspects of the documentation before committing it (mainly expanding the What's New entry, and showing a few more of the moving parts in the __init_subclass__ example). ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 04:01:32 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 30 Jul 2016 08:01:32 +0000 Subject: [issue16632] Enable DEP and ASLR In-Reply-To: <1354875781.46.0.686705865065.issue16632@psf.upfronthosting.co.za> Message-ID: <1469865692.83.0.65223197355.issue16632@psf.upfronthosting.co.za> Berker Peksag added the comment: This has already been backported to 2.7 in issue 24508. ---------- nosy: +berker.peksag resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 05:40:05 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 Jul 2016 09:40:05 +0000 Subject: [issue27453] $CPP invocation in configure must use $CPPFLAGS In-Reply-To: <1467717523.35.0.850577639812.issue27453@psf.upfronthosting.co.za> Message-ID: <20160730094001.1556.93299.23BBA772@psf.io> Roundup Robot added the comment: New changeset 4cb94e561e2d by Xavier de Gaye in branch '3.5': Issue #27453: CPP invocation in configure must use CPPFLAGS. https://hg.python.org/cpython/rev/4cb94e561e2d New changeset 92b3ce7ca95c by Xavier de Gaye in branch 'default': (merge from 3.5) Issue #27453: CPP invocation in configure must use CPPFLAGS. https://hg.python.org/cpython/rev/92b3ce7ca95c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 05:43:22 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 30 Jul 2016 09:43:22 +0000 Subject: [issue27453] $CPP invocation in configure must use $CPPFLAGS In-Reply-To: <1467717523.35.0.850577639812.issue27453@psf.upfronthosting.co.za> Message-ID: <1469871802.38.0.554396501502.issue27453@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Thanks for the patch Chi Hsuan Yen! ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 05:46:08 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 30 Jul 2016 09:46:08 +0000 Subject: [issue27366] PEP487: Simpler customization of class creation In-Reply-To: <1466579967.76.0.483118833643.issue27366@psf.upfronthosting.co.za> Message-ID: <1469871968.84.0.305761106375.issue27366@psf.upfronthosting.co.za> Berker Peksag added the comment: Sorry, I'm a bit late to the party. Here are some tweaks to ecc7bff738e0. I've added versionadded directives, updated the tests to use new style classes and removed a duplicate sentence from the __init_subclass__ docstring. ---------- Added file: http://bugs.python.org/file43946/issue27366_tweaks.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 05:50:38 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 30 Jul 2016 09:50:38 +0000 Subject: [issue27366] PEP487: Simpler customization of class creation In-Reply-To: <1466579967.76.0.483118833643.issue27366@psf.upfronthosting.co.za> Message-ID: <1469872238.35.0.610910740976.issue27366@psf.upfronthosting.co.za> Nick Coghlan added the comment: Good catches Berker - go ahead and apply the improvements whenever's convenient :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 05:54:42 2016 From: report at bugs.python.org (eatrawmeat391) Date: Sat, 30 Jul 2016 09:54:42 +0000 Subject: [issue27651] About bytearray Message-ID: <1469872482.04.0.0838783144311.issue27651@psf.upfronthosting.co.za> New submission from eatrawmeat391: I converted a function name yuke_bpe from C and ran into an unknown issue after running it.The code works but it emptied all of my bytearray. You can reproduce the problem by doing it in the command line from unbpe import yuke_bpe a = bytearray("This is a byte array") b = yuke_bpe(a, 100 ,1) You'll see that bytearray a is empty after the yuke_bpe function calling but the function never touches that variable ---------- components: Windows files: unbpe.py messages: 271674 nosy: eatrawmeat391, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: About bytearray versions: Python 2.7 Added file: http://bugs.python.org/file43947/unbpe.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 06:13:00 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 30 Jul 2016 10:13:00 +0000 Subject: [issue26942] android: test_ctypes crashes on armv7 and aarch64 In-Reply-To: <1462290789.53.0.483745295219.issue26942@psf.upfronthosting.co.za> Message-ID: <1469873580.68.0.0310437501521.issue26942@psf.upfronthosting.co.za> Xavier de Gaye added the comment: We should wait for the pull request to be merged in the libffi development repo before committing the patch. The PR is at https://github.com/libffi/libffi/pull/265. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 06:14:10 2016 From: report at bugs.python.org (Lele Gaifax) Date: Sat, 30 Jul 2016 10:14:10 +0000 Subject: [issue27645] Supporting native backup facility of SQLite In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za> Message-ID: <1469873650.24.0.422622636027.issue27645@psf.upfronthosting.co.za> Lele Gaifax added the comment: Ok, the agreement is fullfilled. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 06:20:15 2016 From: report at bugs.python.org (SilentGhost) Date: Sat, 30 Jul 2016 10:20:15 +0000 Subject: [issue27651] bytearray changes when function mutates it In-Reply-To: <1469872482.04.0.0838783144311.issue27651@psf.upfronthosting.co.za> Message-ID: <1469874015.15.0.199608484591.issue27651@psf.upfronthosting.co.za> SilentGhost added the comment: bytearray is a mutable object and the behaviour is compatible with behaviour of any mutable object in Python. You're passing a into the yuke_bpe function and the original object is being modified (emptied) there. To work around this you could copy the object within the functioin and carry out transformations on the copied object. ---------- nosy: +SilentGhost resolution: -> not a bug stage: -> resolved status: open -> closed title: About bytearray -> bytearray changes when function mutates it type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 06:43:39 2016 From: report at bugs.python.org (Ed Schouten) Date: Sat, 30 Jul 2016 10:43:39 +0000 Subject: [issue27652] [Patch] Make use of non-standard error number ESHUTDOWN optional Message-ID: <1469875419.81.0.269942843817.issue27652@psf.upfronthosting.co.za> New submission from Ed Schouten: While porting Python over to CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html), we noticed that the core Python code maps ESHUTDOWN over to BrokenPipeError. This is fine, except for the fact that ESHUTDOWN is used unconditionally. It's not part of POSIX. Attached is a patch to make its use optional. ---------- components: Interpreter Core files: patch-no-eshutdown messages: 271678 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Make use of non-standard error number ESHUTDOWN optional versions: Python 3.6 Added file: http://bugs.python.org/file43948/patch-no-eshutdown _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 06:50:24 2016 From: report at bugs.python.org (Ed Schouten) Date: Sat, 30 Jul 2016 10:50:24 +0000 Subject: [issue27653] [Patch] Also disable the use of on CloudABI Message-ID: <1469875824.89.0.74501910418.issue27653@psf.upfronthosting.co.za> New submission from Ed Schouten: While porting Python over to CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html), we stumbled upon a small issue that caused the build to fail. As CloudABI is a sandboxed environment, there currently isn't any support for modifying low-level network properties, such as TCP socket attributes. For this reason is missing, just like on a couple of other platforms (Symbian, Cygwin, etc). The attached patch extends the current '#ifndef' to also take CloudABI into consideration. ---------- components: Extension Modules files: patch-no-netinet-tcp_h messages: 271679 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Also disable the use of on CloudABI versions: Python 3.6 Added file: http://bugs.python.org/file43949/patch-no-netinet-tcp_h _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 06:56:14 2016 From: report at bugs.python.org (Ed Schouten) Date: Sat, 30 Jul 2016 10:56:14 +0000 Subject: [issue27654] [Patch] Use arc4random_buf() on CloudABI Message-ID: <1469876174.92.0.881098138709.issue27654@psf.upfronthosting.co.za> New submission from Ed Schouten: While porting Python over to CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html), we stumbled upon a small issue that caused the build to fail. As CloudABI is a sandboxed runtime environment, there is no support for accessing the global filesystem namespace. This means that dev_urandom_noraise()/dev_urandom_python() are not capable of accessing /dev/urandom. The attached change extends these functions to use CloudABI's arc4random_buf() function, which is also present on a lot of other operating systems (the BSDs, Mac OS X, etc). I'm not enabling the use of arc4random_buf() on those operating systems yet, as that should likely be decided by the people responsible for those ports. Alternatively, if we do think arc4random_buf() should be used on all operating systems that support it, we can extend Autoconf to test for its presence. Be sure to let me know and I'll update the patch accordingly. ---------- components: Interpreter Core files: patch-arc4random messages: 271680 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Use arc4random_buf() on CloudABI versions: Python 3.6 Added file: http://bugs.python.org/file43950/patch-arc4random _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 06:57:41 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 30 Jul 2016 10:57:41 +0000 Subject: [issue27652] Make use of non-standard error number ESHUTDOWN optional In-Reply-To: <1469875419.81.0.269942843817.issue27652@psf.upfronthosting.co.za> Message-ID: <1469876261.45.0.762630017415.issue27652@psf.upfronthosting.co.za> Berker Peksag added the comment: Looks good to me, thanks! ---------- nosy: +berker.peksag stage: -> commit review title: [Patch] Make use of non-standard error number ESHUTDOWN optional -> Make use of non-standard error number ESHUTDOWN optional type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 07:05:42 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 Jul 2016 11:05:42 +0000 Subject: [issue27366] PEP487: Simpler customization of class creation In-Reply-To: <1466579967.76.0.483118833643.issue27366@psf.upfronthosting.co.za> Message-ID: <20160730110537.128731.11655.9F8AB5E2@psf.io> Roundup Robot added the comment: New changeset 8747e3455ecb by Berker Peksag in branch 'default': Issue #27366: Tweak PEP 487 documentation https://hg.python.org/cpython/rev/8747e3455ecb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 07:08:12 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 30 Jul 2016 11:08:12 +0000 Subject: [issue27366] PEP487: Simpler customization of class creation In-Reply-To: <1466579967.76.0.483118833643.issue27366@psf.upfronthosting.co.za> Message-ID: <1469876892.93.0.957115173031.issue27366@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the review, Nick! (and also thanks to Martin for the great PEP!) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 07:13:39 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 Jul 2016 11:13:39 +0000 Subject: [issue27652] Make use of non-standard error number ESHUTDOWN optional In-Reply-To: <1469875419.81.0.269942843817.issue27652@psf.upfronthosting.co.za> Message-ID: <20160730111335.128731.22952.FC4E4F1E@psf.io> Roundup Robot added the comment: New changeset 77d16a5dc779 by Berker Peksag in branch 'default': Issue #27652: Expose ESHUTDOWN conditionally https://hg.python.org/cpython/rev/77d16a5dc779 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 07:21:55 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 30 Jul 2016 11:21:55 +0000 Subject: [issue27652] Make use of non-standard error number ESHUTDOWN optional In-Reply-To: <1469875419.81.0.269942843817.issue27652@psf.upfronthosting.co.za> Message-ID: <1469877715.52.0.14482414696.issue27652@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks again, Ed! Could you please sign the PSF contributor agreement at https://www.python.org/psf/contrib/contrib-form/ ? Also, you don't need to strip out the header part of the patch file (Mercurial didn't recognize it as a valid patch file). You may want to check https://docs.python.org/devguide/patch.html ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 07:54:03 2016 From: report at bugs.python.org (Ed Schouten) Date: Sat, 30 Jul 2016 11:54:03 +0000 Subject: [issue27652] Make use of non-standard error number ESHUTDOWN optional In-Reply-To: <1469875419.81.0.269942843817.issue27652@psf.upfronthosting.co.za> Message-ID: <1469879643.18.0.778701773494.issue27652@psf.upfronthosting.co.za> Ed Schouten added the comment: I've filed the contributor form earlier today, but I suspect it still takes some time to get processed. The reason why the Mercurial headers were missing from the patch was because I generated this patch from the Python 3.6.0a3 source tarball. I'll make sure to switch over to the Mercurial sources from now on. Thanks for the quick response! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 08:37:50 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Sat, 30 Jul 2016 12:37:50 +0000 Subject: [issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts In-Reply-To: <1468881013.81.0.152859673137.issue27568@psf.upfronthosting.co.za> Message-ID: <1469882270.39.0.607287603922.issue27568@psf.upfronthosting.co.za> Senthil Kumaran added the comment: The patch looks good to me. I am checking this in. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 09:14:09 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Sat, 30 Jul 2016 13:14:09 +0000 Subject: [issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts In-Reply-To: <1468881013.81.0.152859673137.issue27568@psf.upfronthosting.co.za> Message-ID: <1469884449.12.0.0064725882744.issue27568@psf.upfronthosting.co.za> Senthil Kumaran added the comment: For 3.3, 3.4 it seems reasonable to backport changes from issue26804 and then apply this patch. I will do this today. ---------- assignee: -> orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 10:30:54 2016 From: report at bugs.python.org (Ed Schouten) Date: Sat, 30 Jul 2016 14:30:54 +0000 Subject: [issue27655] [Patch] Don't require presence of POLLPRI Message-ID: <1469889054.78.0.928788503913.issue27655@psf.upfronthosting.co.za> New submission from Ed Schouten: RFC 6093 states that applications "SHOULD NOT" make use of TCP's out-of-band data. For this reason, CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html) does not provide support for it. This means that its poll() function does provide support for POLLIN and POLLOUT, but not for POLLPRI. Attached is a patch that patches up the selectmodule to not define POLLPRI in case the host environment does not support it. ---------- components: Extension Modules files: pollpri.diff keywords: patch messages: 271689 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Don't require presence of POLLPRI versions: Python 3.6 Added file: http://bugs.python.org/file43951/pollpri.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 10:50:42 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 30 Jul 2016 14:50:42 +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: <1469890242.23.0.858609087211.issue23968@psf.upfronthosting.co.za> Xavier de Gaye added the comment: This problem occured for the first time on the "installed Python" buildbot (setup by Zachary) at http://buildbot.python.org/all/builders/x86%20Gentoo%20Installed%20with%20X%203.x/builds/747 on the day changeset 78d2cb7f66b6 has been commited (see msg268528). Those "installed Python" buildbot are very helpful, thanks Zachary. ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 10:54:43 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 30 Jul 2016 14:54:43 +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: <1469890483.97.0.648457750794.issue23968@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The reason I would like this problem fixed is that the test suite is run on an installed Python when cross-compiling, obviously you cannot run the test suite with the cross-compiled Python on the source tree of the build system. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 11:00:46 2016 From: report at bugs.python.org (Ned Deily) Date: Sat, 30 Jul 2016 15:00:46 +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: <1469890846.86.0.218730049178.issue23968@psf.upfronthosting.co.za> Ned Deily added the comment: It's not just broken for cross-compiling. As I noted earlier, it's broken when using other than gcc, such as is the case with current OS X systems. This needs to be fixed before release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 11:06:00 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 30 Jul 2016 15:06:00 +0000 Subject: [issue27576] An unexpected difference between dict and OrderedDict In-Reply-To: <1468962090.7.0.636707577928.issue27576@psf.upfronthosting.co.za> Message-ID: <1469891160.74.0.275672576597.issue27576@psf.upfronthosting.co.za> Changes by Xiang Zhang : Removed file: http://bugs.python.org/file43902/odict_update_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 11:06:02 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 30 Jul 2016 15:06:02 +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: <1469891162.84.0.173047277865.issue23968@psf.upfronthosting.co.za> Xavier de Gaye added the comment: It is also broken for gcc, see the buildbot 'compile' output. It seems broken for all non windows builds whatever the compiler. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 11:07:39 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 30 Jul 2016 15:07:39 +0000 Subject: [issue27576] An unexpected difference between dict and OrderedDict In-Reply-To: <1468962090.7.0.636707577928.issue27576@psf.upfronthosting.co.za> Message-ID: <1469891259.54.0.110916362687.issue27576@psf.upfronthosting.co.za> Xiang Zhang added the comment: After totally studying OrderedDict, I get a better understanding of what Serhiy means. So although we can get a better performance for dict, it's not needed at all. Remove the v3 patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 11:08:49 2016 From: report at bugs.python.org (koobs) Date: Sat, 30 Jul 2016 15:08:49 +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: <1469891329.02.0.815698386775.issue23968@psf.upfronthosting.co.za> Changes by koobs : ---------- nosy: +koobs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 11:37:44 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 30 Jul 2016 15:37:44 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <1469893064.35.0.300728261395.issue24773@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > I don't know to what extent these links are considered standard (koobs) The links like Iran are non-standard. they are specified in the "backward" file in the IANA tzdata distribution which has the following preamble: # This file provides links between current names for time zones # and their old names. Many names changed in late 1993. I'll change "Iran" to "Asia/Tehran" in the test. $ grep Iran Work/tz/backward Link Asia/Tehran Iran ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 11:41:08 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 Jul 2016 15:41:08 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <20160730154104.19319.92298.AD277A11@psf.io> Roundup Robot added the comment: New changeset eed3a5b9239f by Alexander Belopolsky in branch 'default': Issue 24773: Use the standard Asia/Tehran name in the Iran test. https://hg.python.org/cpython/rev/eed3a5b9239f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 11:49:07 2016 From: report at bugs.python.org (Ed Schouten) Date: Sat, 30 Jul 2016 15:49:07 +0000 Subject: [issue27656] [Patch] Make presence of SCHED_* optional Message-ID: <1469893747.69.0.209169490868.issue27656@psf.upfronthosting.co.za> New submission from Ed Schouten: The SCHED_* constants that are part of POSIX's are all optional: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sched.h.html Python already declares the SCHED_SPORADIC constant as part of the POSIX module optionally, depending on whether it is present in C, but doesn't do this for the other SCHED_* constants. This is problematic for CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html), which doesn't support any scheduler interaction at all. Attached is a patch to only define these if present. ---------- components: Extension Modules files: sched.diff keywords: patch messages: 271697 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Make presence of SCHED_* optional versions: Python 3.6 Added file: http://bugs.python.org/file43952/sched.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 12:09:48 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 30 Jul 2016 16:09:48 +0000 Subject: [issue22724] byte-compile fails for cross-builds In-Reply-To: <1414194759.57.0.515625475535.issue22724@psf.upfronthosting.co.za> Message-ID: <1469894988.0.0.0544930973559.issue22724@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Patch rebased to current tip. To summarize: * The root cause of the problem reported by Benedikt still exists. * The problem is hidden now that the shared libraries names include the PLATFORM_TRIPLET. * But byte-compilation still fails for cross-builds when the 'host' and 'build' PLATFORM_TRIPLET are the same and this occurs for the x86_64 Android build on a x86_64 'build' system. Matthias, do you have any comment on this patch? ---------- Added file: http://bugs.python.org/file43953/py_build_environ_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 13:09:15 2016 From: report at bugs.python.org (Jason R. Coombs) Date: Sat, 30 Jul 2016 17:09:15 +0000 Subject: [issue24672] shutil.rmtree fails on non ascii filenames In-Reply-To: <1437381607.37.0.102405626215.issue24672@psf.upfronthosting.co.za> Message-ID: <1469898555.87.0.798058842544.issue24672@psf.upfronthosting.co.za> Jason R. Coombs added the comment: I agree. I was able to apply a fairly simple fix to setuptools to address the failure (https://github.com/pypa/setuptools/commit/857949575022946cc60c7cd1d0d088246d3f7540). I suggest closing this ticket as won't fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 14:12:50 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Sat, 30 Jul 2016 18:12:50 +0000 Subject: [issue19837] Wire protocol encoding for the JSON module In-Reply-To: <1385778645.87.0.0800898315059.issue19837@psf.upfronthosting.co.za> Message-ID: <1469902370.5.0.900174247441.issue19837@psf.upfronthosting.co.za> ???? ????????? added the comment: One of the problem, that decodeing JSON is FSM, where input is one symbol rather than one byte. AFAIK, Python still does not have FSM for decoding UTF-8 sequence, so iterative decoding of JSON will require more changes than expected. ---------- nosy: +mmarkk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 14:32:41 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Sat, 30 Jul 2016 18:32:41 +0000 Subject: [issue19837] Wire protocol encoding for the JSON module In-Reply-To: <1385778645.87.0.0800898315059.issue19837@psf.upfronthosting.co.za> Message-ID: <1469903561.46.0.821790693967.issue19837@psf.upfronthosting.co.za> ???? ????????? added the comment: In real life, I can confirm, that porting from Python2 to Python3 is almost automatic except JSON-related fixes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 15:46:23 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 30 Jul 2016 19:46:23 +0000 Subject: [issue24672] shutil.rmtree fails on non ascii filenames In-Reply-To: <1437381607.37.0.102405626215.issue24672@psf.upfronthosting.co.za> Message-ID: <1469907983.28.0.180406227398.issue24672@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> wont fix stage: -> resolved status: open -> closed versions: -Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 15:57:17 2016 From: report at bugs.python.org (=?utf-8?q?Bj=C3=B6rn_Lindqvist?=) Date: Sat, 30 Jul 2016 19:57:17 +0000 Subject: [issue27657] urlparse fails if the path is numeric Message-ID: <1469908637.82.0.696114480311.issue27657@psf.upfronthosting.co.za> New submission from Bj?rn Lindqvist: This affects both Python 2 and 3. This is as expected: >>> urlparse('abc:123.html') ParseResult(scheme='abc', netloc='', path='123.html', params='', query='', fragment='') >>> urlparse('123.html:abc') ParseResult(scheme='123.html', netloc='', path='abc', params='', query='', fragment='') >>> urlparse('abc:123/') ParseResult(scheme='abc', netloc='', path='123/', params='', query='', fragment='') This is NOT: >>> urlparse('abc:123') ParseResult(scheme='', netloc='', path='abc:123', params='', query='', fragment='') Expected is path='123' and scheme='abc'. At least according to my reading of the rfc (https://tools.ietf.org/html/rfc1808.html) that is what should happen. ---------- components: Library (Lib) messages: 271702 nosy: Bj?rn.Lindqvist priority: normal severity: normal status: open title: urlparse fails if the path is numeric type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 17:12:06 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 30 Jul 2016 21:12:06 +0000 Subject: [issue27657] urlparse fails if the path is numeric In-Reply-To: <1469908637.82.0.696114480311.issue27657@psf.upfronthosting.co.za> Message-ID: <1469913126.83.0.812045319671.issue27657@psf.upfronthosting.co.za> R. David Murray added the comment: See issue 14072. It may be time to look at this again, but we may still be constrained by backward compatibility. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 17:19:42 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 30 Jul 2016 21:19:42 +0000 Subject: [issue27604] More details about `-O` flag In-Reply-To: <1469353581.38.0.811049911305.issue27604@psf.upfronthosting.co.za> Message-ID: <1469913582.82.0.205385204051.issue27604@psf.upfronthosting.co.za> R. David Murray added the comment: You know, it's actually more complicated than this now. We recently changed the way optimization levels are handled in pyc files in such a way that it is possible for other optimization 'levels" to be added by third parties. So the reference information is no longer complete. We may need to revise that section further. And yes, there needs to be a mapping from O values to the optimization levels discussed in the reference, in one location or the other. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 17:27:36 2016 From: report at bugs.python.org (Ram Rachum) Date: Sat, 30 Jul 2016 21:27:36 +0000 Subject: [issue27604] More details about `-O` flag In-Reply-To: <1469353581.38.0.811049911305.issue27604@psf.upfronthosting.co.za> Message-ID: <1469914056.45.0.630210578596.issue27604@psf.upfronthosting.co.za> Ram Rachum added the comment: Hmm. What do you think about merging 3.patch now, and then possibly adding more information later? (Or asking the people who are designing the complex behvior you describe to write those docs.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 17:35:01 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 30 Jul 2016 21:35:01 +0000 Subject: [issue27604] More details about `-O` flag In-Reply-To: <1469353581.38.0.811049911305.issue27604@psf.upfronthosting.co.za> Message-ID: <1469914501.96.0.187297745432.issue27604@psf.upfronthosting.co.za> R. David Murray added the comment: I wouldn't object, but if I started to do it I'd wind up doing the research to "do it right" instead, so it would have to be someone else doing the intermediate commit :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 17:47:04 2016 From: report at bugs.python.org (Ram Rachum) Date: Sat, 30 Jul 2016 21:47:04 +0000 Subject: [issue27604] More details about `-O` flag In-Reply-To: <1469353581.38.0.811049911305.issue27604@psf.upfronthosting.co.za> Message-ID: <1469915224.14.0.987848273699.issue27604@psf.upfronthosting.co.za> Ram Rachum added the comment: Well, I guess we had a fun week exchanging a couple thousand words about a two-line change to the docs that's now never going to happen ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 17:49:26 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 30 Jul 2016 21:49:26 +0000 Subject: [issue27604] More details about `-O` flag In-Reply-To: <1469353581.38.0.811049911305.issue27604@psf.upfronthosting.co.za> Message-ID: <1469915366.5.0.756214609227.issue27604@psf.upfronthosting.co.za> R. David Murray added the comment: Oh, don't say never. Berker seems to like these kind of small commits, and it won't get lost. Who knows, I may even decide to tackle it. Or someone else will decide to do the research and update your patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 17:51:47 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 30 Jul 2016 21:51:47 +0000 Subject: [issue27604] More details about `-O` flag In-Reply-To: <1469353581.38.0.811049911305.issue27604@psf.upfronthosting.co.za> Message-ID: <1469915507.67.0.693239781465.issue27604@psf.upfronthosting.co.za> R. David Murray added the comment: Heh, that comment about Berker came out wrong. I meant, he seems willing to do, and make time for, the small doc commits that some of the rest of us don't seem to get around to, which is great. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 18:19:49 2016 From: report at bugs.python.org (Mario Grgic) Date: Sat, 30 Jul 2016 22:19:49 +0000 Subject: [issue27658] python 3.5.2 built from source fails to install completely on Mac OS X 10.11.6. Crashes subsequently. Message-ID: <1469917189.39.0.985531249644.issue27658@psf.upfronthosting.co.za> New submission from Mario Grgic: I am on Mac OS X 10.11.6 trying to build and install Python 3.5.2 from source. I only have system Python 2.7.10 , and no other instances of Python 3.x. I configure the build as follows: ./configure --prefix=/Volumes/ramdisk/python3.5.2 The code is built without errors, but when I issue make install I get: cd /Volumes/ramdisk/python3.5.2/share/man/man1; ln -s python3.5.1 python3.1) if test "xupgrade" != "xno" ; then \ case upgrade in \ upgrade) ensurepip="--upgrade" ;; \ install|*) ensurepip="" ;; \ esac; \ ./python.exe -E -m ensurepip \ $ensurepip --root=/ ; \ fi Ignoring indexes: https://pypi.python.org/simple Collecting setuptools Collecting pip Installing collected packages: setuptools, pip /bin/sh: line 7: 15831 Segmentation fault: 11 ./python.exe -E -m ensurepip $ensurepip --root=/ Makefile:1059: recipe for target 'install' failed make: *** [install] Error 139 which crashes the system Python 2.7.10: Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: EXC_I386_GPFLT Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libcrypto.1.0.0.dylib 0x0000000108c82d51 EVP_PKEY_CTX_free + 17 1 libcrypto.1.0.0.dylib 0x0000000108c77742 EVP_MD_CTX_cleanup + 130 2 libcrypto.1.0.0.dylib 0x0000000108c77a9d EVP_DigestFinal + 29 3 _hashlib.cpython-35m-darwin.so 0x0000000108c05d6b EVP_digest + 155 (_hashopenssl.c:148) 4 python.exe 0x000000010835493e PyEval_EvalFrameEx + 24110 (ceval.c:4684) 5 python.exe 0x00000001083596f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 6 python.exe 0x0000000108359f60 fast_function + 464 (ceval.c:4818) 7 python.exe 0x000000010835484f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 8 python.exe 0x00000001083596f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 9 python.exe 0x0000000108359f60 fast_function + 464 (ceval.c:4818) 10 python.exe 0x000000010835484f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 11 python.exe 0x00000001083596f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 12 python.exe 0x0000000108359f60 fast_function + 464 (ceval.c:4818) 13 python.exe 0x000000010835484f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 14 python.exe 0x00000001083596f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 15 python.exe 0x000000010834eaee PyEval_EvalCodeEx + 78 (ceval.c:4039) 16 python.exe 0x00000001082b743d function_call + 381 (funcobject.c:627) 17 python.exe 0x000000010828ddd5 PyObject_Call + 101 (abstract.c:2162) 18 python.exe 0x00000001083556a0 PyEval_EvalFrameEx + 27536 (ceval.c:5034) 19 python.exe 0x00000001083596f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 20 python.exe 0x0000000108359f60 fast_function + 464 (ceval.c:4818) 21 python.exe 0x000000010835484f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 22 python.exe 0x0000000108359ee2 fast_function + 338 (ceval.c:4803) 23 python.exe 0x000000010835484f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 24 python.exe 0x00000001083596f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 25 python.exe 0x0000000108359f60 fast_function + 464 (ceval.c:4818) 26 python.exe 0x000000010835484f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 27 python.exe 0x00000001083596f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 28 python.exe 0x0000000108359f60 fast_function + 464 (ceval.c:4818) 29 python.exe 0x000000010835484f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 30 python.exe 0x00000001083596f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 31 python.exe 0x0000000108359f60 fast_function + 464 (ceval.c:4818) 32 python.exe 0x000000010835484f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 33 python.exe 0x00000001083596f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 34 python.exe 0x0000000108359f60 fast_function + 464 (ceval.c:4818) 35 python.exe 0x000000010835484f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 36 python.exe 0x00000001083596f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 37 python.exe 0x0000000108359f60 fast_function + 464 (ceval.c:4818) 38 python.exe 0x000000010835484f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 39 python.exe 0x00000001083596f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 40 python.exe 0x000000010834ea91 PyEval_EvalCode + 81 (ceval.c:777) 41 python.exe 0x000000010834c2e0 builtin_exec + 528 (bltinmodule.c:957) 42 python.exe 0x00000001082d6ea5 PyCFunction_Call + 165 (methodobject.c:121) 43 python.exe 0x0000000108354f00 PyEval_EvalFrameEx + 25584 (ceval.c:4705) 44 python.exe 0x00000001083596f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 45 python.exe 0x0000000108359f60 fast_function + 464 (ceval.c:4818) 46 python.exe 0x000000010835484f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 47 python.exe 0x00000001083596f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 48 python.exe 0x000000010834eaee PyEval_EvalCodeEx + 78 (ceval.c:4039) 49 python.exe 0x00000001082b743d function_call + 381 (funcobject.c:627) 50 python.exe 0x000000010828ddd5 PyObject_Call + 101 (abstract.c:2162) 51 python.exe 0x00000001083976e3 RunModule + 147 (main.c:208) 52 python.exe 0x00000001083970fe Py_Main + 2526 (main.c:709) 53 python.exe 0x00000001082831cd main + 237 (python.c:65) 54 libdyld.dylib 0x00007fff9523b5ad start + 1 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x0000000000000000 rbx: 0x149dd2af96bf4325 rcx: 0x00000000000fc080 rdx: 0x0000000000031db0 rdi: 0x149dd2af96bf4325 rsi: 0x000000010856be00 rbp: 0x00007fff5797b130 rsp: 0x00007fff5797b120 r8: 0x0000000000000003 r9: 0x00007fb96b5ba1f0 r10: 0x00000000072e2888 r11: 0x00007fb96b500000 r12: 0x0a0061d3943a3792 r13: 0x0000000109a59fc0 r14: 0x0000000000000001 r15: 0x00007fff5797b1a0 rip: 0x0000000108c82d51 rfl: 0x0000000000010202 cr2: 0x0000000108c82d40 Logical CPU: 2 Error Code: 0x00000000 Trap Number: 13 -------------------------------------------------------- If I add partially installed python 3.5.2 on the system PATH and add alias python=python3 so the makefile calls python3 instead, then installation completes successfully. However, if I now try running pip3 from python3.5.2/bin installation I get another crash in python3 now Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000011 VM Regions Near 0x11: --> __TEXT 00000001025cd000-0000000102778000 [ 1708K] r-x/rwx SM=COW /Volumes/VOLUME/*/*.5 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libcrypto.1.0.0.dylib 0x0000000103301f79 EVP_PKEY_CTX_dup + 25 1 libcrypto.1.0.0.dylib 0x00000001032f692a EVP_MD_CTX_copy_ex + 282 2 _hashlib.cpython-35m-darwin.so 0x0000000103284e03 EVP_hexdigest + 99 (_hashopenssl.c:113) 3 python3.5 0x000000010269f93e PyEval_EvalFrameEx + 24110 (ceval.c:4684) 4 python3.5 0x00000001026a4ee2 fast_function + 338 (ceval.c:4803) 5 python3.5 0x000000010269f84f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 6 python3.5 0x00000001026a46f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 7 python3.5 0x00000001026a4f60 fast_function + 464 (ceval.c:4818) 8 python3.5 0x000000010269f84f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 9 python3.5 0x00000001026a4ee2 fast_function + 338 (ceval.c:4803) 10 python3.5 0x000000010269f84f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 11 python3.5 0x00000001026a46f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 12 python3.5 0x00000001026a4f60 fast_function + 464 (ceval.c:4818) 13 python3.5 0x000000010269f84f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 14 python3.5 0x00000001026a46f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 15 python3.5 0x00000001026a4f60 fast_function + 464 (ceval.c:4818) 16 python3.5 0x000000010269f84f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 17 python3.5 0x00000001026a46f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 18 python3.5 0x00000001026a4f60 fast_function + 464 (ceval.c:4818) 19 python3.5 0x000000010269f84f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 20 python3.5 0x00000001026a4ee2 fast_function + 338 (ceval.c:4803) 21 python3.5 0x000000010269f84f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 22 python3.5 0x00000001026a4ee2 fast_function + 338 (ceval.c:4803) 23 python3.5 0x000000010269f84f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 24 python3.5 0x00000001026a46f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 25 python3.5 0x00000001026a4f60 fast_function + 464 (ceval.c:4818) 26 python3.5 0x000000010269f84f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 27 python3.5 0x00000001026a46f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 28 python3.5 0x00000001026a4f60 fast_function + 464 (ceval.c:4818) 29 python3.5 0x000000010269f84f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 30 python3.5 0x00000001026a46f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 31 python3.5 0x0000000102699a91 PyEval_EvalCode + 81 (ceval.c:777) 32 python3.5 0x00000001026ca581 PyRun_FileExFlags + 209 (pythonrun.c:976) 33 python3.5 0x00000001026c9c7c PyRun_SimpleFileExFlags + 668 (pythonrun.c:396) 34 python3.5 0x00000001026e23f4 Py_Main + 3284 (main.c:318) 35 python3.5 0x00000001025ce1cd main + 237 (python.c:65) 36 libdyld.dylib 0x00007fff9523b5ad start + 1 Thread 1: 0 libsystem_kernel.dylib 0x00007fff83afb5e2 __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff95a85578 _pthread_wqthread + 1283 2 libsystem_pthread.dylib 0x00007fff95a83341 start_wqthread + 13 Thread 2:: Dispatch queue: com.apple.libdispatch-manager 0 libsystem_kernel.dylib 0x00007fff83afbefa kevent_qos + 10 1 libdispatch.dylib 0x00007fff956af165 _dispatch_mgr_invoke + 216 2 libdispatch.dylib 0x00007fff956aedcd _dispatch_mgr_thread + 52 Thread 3: 0 libsystem_kernel.dylib 0x00007fff83afb5e2 __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff95a85578 _pthread_wqthread + 1283 2 libsystem_pthread.dylib 0x00007fff95a83341 start_wqthread + 13 Thread 4: 0 libsystem_kernel.dylib 0x00007fff83afb5e2 __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff95a85578 _pthread_wqthread + 1283 2 libsystem_pthread.dylib 0x00007fff95a83341 start_wqthread + 13 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x0000000000000001 rbx: 0x0000000103b75f48 rcx: 0x0000000000000010 rdx: 0xffffffffffffffd4 rdi: 0x00007fdb83c51140 rsi: 0x00007fdb83ca1410 rbp: 0x00007fff5d630c40 rsp: 0x00007fff5d630c30 r8: 0x0000000000000006 r9: 0x0000000000000000 r10: 0x00000000ffffffff r11: 0x00000000000027c0 r12: 0x990018d2e679ec80 r13: 0x0000000103c78288 r14: 0x00007fff5d630c80 r15: 0x00007fdb83ca3b80 rip: 0x0000000103301f79 rfl: 0x0000000000010202 cr2: 0x0000000000000011 Logical CPU: 2 Error Code: 0x00000004 Trap Number: 14 ---------- components: Installation messages: 271710 nosy: Mario Grgic priority: normal severity: normal status: open title: python 3.5.2 built from source fails to install completely on Mac OS X 10.11.6. Crashes subsequently. type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 19:15:16 2016 From: report at bugs.python.org (Ned Deily) Date: Sat, 30 Jul 2016 23:15:16 +0000 Subject: [issue27658] python 3.5.2 built from source fails to install completely on Mac OS X 10.11.6. Crashes subsequently. In-Reply-To: <1469917189.39.0.985531249644.issue27658@psf.upfronthosting.co.za> Message-ID: <1469920516.07.0.00734600901647.issue27658@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 19:27:00 2016 From: report at bugs.python.org (Ned Deily) Date: Sat, 30 Jul 2016 23:27:00 +0000 Subject: [issue27658] python 3.5.2 built from source fails to install completely on Mac OS X 10.11.6. Crashes subsequently. In-Reply-To: <1469917189.39.0.985531249644.issue27658@psf.upfronthosting.co.za> Message-ID: <1469921220.41.0.135653547164.issue27658@psf.upfronthosting.co.za> Ned Deily added the comment: The crash is in libcrypto but Apple doesn't supply a libcrypto.1.0.0 with OS X 10.11, only 0.9.7 and 0.9.8. Check the rest of the crash log to see where you're picking it up from and make sure you have an up-to-date version. If you have a version from MacPorts or Homebrew, see the Developer's Guide for more information on how to configure a build to use libraries from them. https://docs.python.org/devguide/setup.html#build-dependencies ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 19:52:19 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 30 Jul 2016 23:52:19 +0000 Subject: [issue22891] code removal from urllib.parse.urlsplit() In-Reply-To: <1416220944.83.0.361625539874.issue22891@psf.upfronthosting.co.za> Message-ID: <1469922739.47.0.26103372308.issue22891@psf.upfronthosting.co.za> Martin Panter added the comment: Issue 27657 has been opened about the quirk with numeric URLs ---------- dependencies: +urlparse fails if the path is numeric _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 19:54:43 2016 From: report at bugs.python.org (Mario Grgic) Date: Sat, 30 Jul 2016 23:54:43 +0000 Subject: [issue27658] python 3.5.2 built from source fails to install completely on Mac OS X 10.11.6. Crashes subsequently. In-Reply-To: <1469917189.39.0.985531249644.issue27658@psf.upfronthosting.co.za> Message-ID: <1469922883.71.0.466924158707.issue27658@psf.upfronthosting.co.za> Mario Grgic added the comment: It looks like it is picking up libcrypto.1.0.0.dylib from /usr/local/lib which I installed there as dependency for other binaries. Is there a minimal version of libcrypto that Python 3.5.2 needs? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 20:06:32 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 31 Jul 2016 00:06:32 +0000 Subject: [issue23150] urllib parse incorrect handing of params In-Reply-To: <1420208027.4.0.951710161178.issue23150@psf.upfronthosting.co.za> Message-ID: <1469923592.9.0.795818982842.issue23150@psf.upfronthosting.co.za> Martin Panter added the comment: If the problem was just Julian not being aware of urlsplit(), there is not much to be done for this bug. ---------- resolution: -> not a bug status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 20:38:52 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 31 Jul 2016 00:38:52 +0000 Subject: [issue27658] python 3.5.2 built from source fails to install completely on Mac OS X 10.11.6. Crashes subsequently. In-Reply-To: <1469917189.39.0.985531249644.issue27658@psf.upfronthosting.co.za> Message-ID: <1469925532.79.0.123756449071.issue27658@psf.upfronthosting.co.za> Ned Deily added the comment: libcrypto is part of OpenSSL which is famous for not maintaining ABI compatibility across versions and generally you should be using the most recent version of OpenSSL. Depending what and where you have your copy installed, it's also possible the build picked up the wrong set of include files for that version of libcrypto and libssl. You may be able to see that in the output of the build of _ssl.so. Python's top-level setup.py file contains the code that tries to find the include files and lib files for various extension modules; for _ssl.so, see setup.py:810 and beyond. Apple has deprecated the use of the system-supplied OpenSSL libraries and, in 10.11, the include files for OpenSSL are no longer included in Xcode or the Command Line Tools so you need to use a third-party copy of OpenSSL anyway. If you aren't using a MacPorts or Homebrew, you can adapt the recipes in the Developer's Guide as necessary. (Or you could use a pre-built Python 3.5, like that downloadable from python.org or MacPorts or Homebrew). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 21:31:19 2016 From: report at bugs.python.org (Mario Grgic) Date: Sun, 31 Jul 2016 01:31:19 +0000 Subject: [issue27658] python 3.5.2 built from source fails to install completely on Mac OS X 10.11.6. Crashes subsequently. In-Reply-To: <1469917189.39.0.985531249644.issue27658@psf.upfronthosting.co.za> Message-ID: <1469928679.3.0.978406831438.issue27658@psf.upfronthosting.co.za> Mario Grgic added the comment: OK, after installing OpenSSL in /usr/local/ssl and even after copying libssl.pc, libcrypt.pc and openssl.pc over to /usr/local/lib/pkgconfig (which is where my pkg-config is looking or *.pc files) the configure script is still not finding the correct libcrypto. Only when I explicitly set CLFLAGS=-I/usr/local/ssl/include and LDFLAGS=-L/usr/local/ssl/lib does the configure script pick the correct libcrypto, notwithstanding the logic in top level setup.py which does have /usr/local/ssl/include on line 812 and /usr/local/ssl/lib on line 824? Not sure at what point is setup.py used, but it doesn't seem to pick up the include and lib directories for ssl correctly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 21:35:10 2016 From: report at bugs.python.org (Emanuel Barry) Date: Sun, 31 Jul 2016 01:35:10 +0000 Subject: [issue27366] PEP487: Simpler customization of class creation In-Reply-To: <1466579967.76.0.483118833643.issue27366@psf.upfronthosting.co.za> Message-ID: <1469928910.88.0.550563806293.issue27366@psf.upfronthosting.co.za> Emanuel Barry added the comment: Hello Martin, and thank you for your patch! However, this patch removed the ability to pass keyword arguments to `type`, and it's not documented anywhere. I believe it should be documented at least in e.g. the "Changes in the Python API" of the What's New in Python 3.6 document. Anyone cares to submit a patch? ---------- nosy: +ebarry resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 22:28:11 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 31 Jul 2016 02:28:11 +0000 Subject: [issue27366] PEP487: Simpler customization of class creation In-Reply-To: <1466579967.76.0.483118833643.issue27366@psf.upfronthosting.co.za> Message-ID: <1469932091.65.0.273292347301.issue27366@psf.upfronthosting.co.za> Nick Coghlan added the comment: D'oh, another good catch Emanuel - and I'm even the one that raised the need to mention that in the Porting notes during the python-dev discussion :P I'll post an update to the What's New shortly. ---------- stage: resolved -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 22:37:12 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 31 Jul 2016 02:37:12 +0000 Subject: [issue27657] urlparse fails if the path is numeric In-Reply-To: <1469908637.82.0.696114480311.issue27657@psf.upfronthosting.co.za> Message-ID: <1469932632.75.0.192070134574.issue27657@psf.upfronthosting.co.za> Martin Panter added the comment: The main backward compatibility consideration would be Issue 754016, but don?t agree with the changes made, and would support reverting them. The original bug reporter wanted urlparse("1.2.3.4:80", "http") to be treated as the URL http://1.2.3.4:80, but the IP address was being parsed as a scheme, so the default ?http? scheme was ignored. The original fix (r83701) affected any URL that had a digit 0?9 immediately after the ?scheme:? prefix. In such URLs, the scheme component was no longer parsed. A test case for ?path:80? was added, and a demonstration of not parsing any scheme from www.cwi.nl:80/%7Eguido/Python.html was added in the documentation. Later, the logic was altered to test if the URL looked like an integer (revision 495d12196487, Issue 11467). This restored proper parsing of clsid:85bbd92o-42a0-1o69-a2e4-08002b30309d and mailto:1337 at example.org, although another URL given, javascript:123, remains misparsed. The documentation was subsequently adjusted in Issue 16932 to just demonstrate www.cwi.nl/%7Eguido/Python.html being parsed as a path. The logic was watered down to its current form by revision 9f6b7576c08c, Issue 14072. Now it tests for a non-digit anywhere after the scheme, so that tel:+31641044153 is again parsed properly. But it was pointed out that tel:1234 remains misparsed. What?s the next step in the watering-down process? All the attempts so far break valid URLs in favour of special-casing inputs that are not valid URLs. ---------- nosy: +martin.panter, orsenthil versions: +Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 22:43:06 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 31 Jul 2016 02:43:06 +0000 Subject: [issue27366] PEP487: Simpler customization of class creation In-Reply-To: <1466579967.76.0.483118833643.issue27366@psf.upfronthosting.co.za> Message-ID: <20160731024303.71348.99585.7FAD2EF1@psf.io> Roundup Robot added the comment: New changeset 313e8fdb0d0c by Nick Coghlan in branch 'default': Issue 27366: PEP 487 docs updates https://hg.python.org/cpython/rev/313e8fdb0d0c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 22:46:45 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 31 Jul 2016 02:46:45 +0000 Subject: [issue27366] PEP487: Simpler customization of class creation In-Reply-To: <1466579967.76.0.483118833643.issue27366@psf.upfronthosting.co.za> Message-ID: <1469933205.79.0.893952610015.issue27366@psf.upfronthosting.co.za> Nick Coghlan added the comment: The new porting note doesn't quite capture all the subtleties of the situation, but should be sufficient for folks to get any affected custom metaclasses working again (since the key is to avoid passing those parameters up to type.__new__). I also added a note about the fact that __init_subclass__ implementations don't have access to the metaclass hint, but can retrieve the actual metaclass based on the passed in class object. ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 23:10:19 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 31 Jul 2016 03:10:19 +0000 Subject: [issue25895] urllib.parse.urljoin does not handle WebSocket URLs In-Reply-To: <1450331933.69.0.301225840177.issue25895@psf.upfronthosting.co.za> Message-ID: <1469934619.53.0.078867942096.issue25895@psf.upfronthosting.co.za> Martin Panter added the comment: My view is that because the schemes are not in the documented list of supported schemes, this is a new feature, and any documentation update should include a ?versionadded? or similar notice. ---------- components: +Library (Lib) stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 23:38:24 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 31 Jul 2016 03:38:24 +0000 Subject: [issue13651] Improve redirection in urllib In-Reply-To: <1324577379.51.0.5468672041.issue13651@psf.upfronthosting.co.za> Message-ID: <1469936304.27.0.132840994424.issue13651@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> [urllib.request.HTTPRedirectHandler.http_error_302] Relative Redirect issue _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 02:18:41 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 31 Jul 2016 06:18:41 +0000 Subject: [issue19660] decorator syntax: allow testlist instead of just dotted_name In-Reply-To: <1384910825.18.0.00604679093295.issue19660@psf.upfronthosting.co.za> Message-ID: <1469945921.56.0.600587962063.issue19660@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 02:22:40 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 31 Jul 2016 06:22:40 +0000 Subject: [issue27656] [Patch] Make presence of SCHED_* optional In-Reply-To: <1469893747.69.0.209169490868.issue27656@psf.upfronthosting.co.za> Message-ID: <20160731062234.328.19488.7290DC49@psf.io> Roundup Robot added the comment: New changeset 095b424127e7 by Benjamin Peterson in branch '3.5': all SCHED_ constants are optional (closes #27656) https://hg.python.org/cpython/rev/095b424127e7 New changeset 64b763290da9 by Benjamin Peterson in branch 'default': merge 3.5 (#27656) https://hg.python.org/cpython/rev/64b763290da9 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 02:32:37 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 31 Jul 2016 06:32:37 +0000 Subject: [issue10673] multiprocess.Process join method - timeout indistinguishable from success In-Reply-To: <1291991778.63.0.145134143934.issue10673@psf.upfronthosting.co.za> Message-ID: <1469946757.07.0.751915476325.issue10673@psf.upfronthosting.co.za> Berker Peksag added the comment: Thread.join() also returns None in all cases so +1 for documenting the current behavior. ---------- keywords: +easy nosy: +berker.peksag stage: -> needs patch versions: +Python 3.5, Python 3.6 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 02:51:52 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 31 Jul 2016 06:51:52 +0000 Subject: [issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts In-Reply-To: <1468881013.81.0.152859673137.issue27568@psf.upfronthosting.co.za> Message-ID: <20160731065149.25102.15616.86420F8E@psf.io> Roundup Robot added the comment: New changeset 95b09ccc8a3e by Senthil Kumaran in branch '3.3': Prevent HTTPoxy attack (CVE-2016-1000110) https://hg.python.org/cpython/rev/95b09ccc8a3e New changeset 3c19023c9fec by Senthil Kumaran in branch '3.4': [merge from 3.3] Prevent HTTPoxy attack (CVE-2016-1000110) https://hg.python.org/cpython/rev/3c19023c9fec New changeset a0ac52ed8f79 by Senthil Kumaran in branch '3.5': [merge from 3.4] - Prevent HTTPoxy attack (CVE-2016-1000110) https://hg.python.org/cpython/rev/a0ac52ed8f79 New changeset 6c2e2de5ab8e by Senthil Kumaran in branch 'default': [merge from 3.5] - Prevent HTTPoxy attack (CVE-2016-1000110) https://hg.python.org/cpython/rev/6c2e2de5ab8e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 02:57:15 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 31 Jul 2016 06:57:15 +0000 Subject: [issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts In-Reply-To: <1468881013.81.0.152859673137.issue27568@psf.upfronthosting.co.za> Message-ID: <1469948235.36.0.527951765083.issue27568@psf.upfronthosting.co.za> Senthil Kumaran added the comment: This is also committed in 2.7 branch in ba915d561667. This is committed in all active versions(2.7, 3.5, 3.6) and also versions which receive security updates (3.3 and 3.4). This issue is resolved. Thank you for the patch, R?mi. (In msg271688, I pondered if I need to backport a behavior change from issue26804 which will allow lower cased proxies, but then, I decided against it as it will introduce unnecessary changes to this security fix releases). ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 03:04:38 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sun, 31 Jul 2016 07:04:38 +0000 Subject: [issue27659] Check for the existence of crypt() Message-ID: <1469948678.43.0.816389049938.issue27659@psf.upfronthosting.co.za> New submission from Chi Hsuan Yen: On Android the crypt() function is missing, causing ugly linking errors when compiling the _crypt module. This patch handles it elegantly. A question: should I include changes to configure and pyconfig.h.in in the patch? ---------- components: Cross-Build files: check-crypt.patch keywords: patch messages: 271727 nosy: Alex.Willmer, Chi Hsuan Yen, xdegaye priority: normal severity: normal status: open title: Check for the existence of crypt() type: compile error versions: Python 3.6 Added file: http://bugs.python.org/file43954/check-crypt.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 03:09:52 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sun, 31 Jul 2016 07:09:52 +0000 Subject: [issue27659] Check for the existence of crypt() In-Reply-To: <1469948678.43.0.816389049938.issue27659@psf.upfronthosting.co.za> Message-ID: <1469948992.78.0.60212593797.issue27659@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Version 2: correct the name added to `missing` ---------- Added file: http://bugs.python.org/file43955/check-crypt.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 03:12:39 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sun, 31 Jul 2016 07:12:39 +0000 Subject: [issue27659] Check for the existence of crypt() In-Reply-To: <1469948678.43.0.816389049938.issue27659@psf.upfronthosting.co.za> Message-ID: <1469949159.6.0.146526016082.issue27659@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Some references for crypt(): POSIX standard: http://pubs.opengroup.org/onlinepubs/9699919799/functions/crypt.html Linux man page: http://man7.org/linux/man-pages/man3/crypt.3.html FreeBSD man page: https://www.freebsd.org/cgi/man.cgi?crypt(3) Mac OS X man page: https://developer.apple.com/library/ios/documentation/System/Conceptual/ManPages_iPhoneOS/man3/crypt.3.html All requires . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 03:50:45 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 31 Jul 2016 07:50:45 +0000 Subject: [issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts In-Reply-To: <1468881013.81.0.152859673137.issue27568@psf.upfronthosting.co.za> Message-ID: <1469951445.51.0.301406083394.issue27568@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 04:18:29 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 31 Jul 2016 08:18:29 +0000 Subject: [issue27659] Check for the existence of crypt() In-Reply-To: <1469948678.43.0.816389049938.issue27659@psf.upfronthosting.co.za> Message-ID: <1469953109.17.0.691336679453.issue27659@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > A question: should I include changes to configure and pyconfig.h.in in the patch? You just need to mention that one should run autoreconf. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 04:22:55 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 31 Jul 2016 08:22:55 +0000 Subject: [issue26865] Meta-issue: support of the android platform In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za> Message-ID: <1469953375.55.0.252414108313.issue26865@psf.upfronthosting.co.za> Xavier de Gaye added the comment: issue #27659: Check for the existence of crypt() ---------- dependencies: +Check for the existence of crypt() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 04:28:00 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sun, 31 Jul 2016 08:28:00 +0000 Subject: [issue27659] Check for the existence of crypt() In-Reply-To: <1469948678.43.0.816389049938.issue27659@psf.upfronthosting.co.za> Message-ID: <1469953680.94.0.955340427257.issue27659@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Thanks, added to the patch description ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 05:20:56 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 31 Jul 2016 09:20:56 +0000 Subject: [issue27275] KeyError thrown by optimised collections.OrderedDict.popitem() In-Reply-To: <1465446835.8.0.930561202137.issue27275@psf.upfronthosting.co.za> Message-ID: <1469956856.94.0.673986759238.issue27275@psf.upfronthosting.co.za> Xiang Zhang added the comment: There seems to be some difference behaviours between C version and pure Python version when it comes to subclass. Except popitem, the constructor also goes different code path. There may be more. Should these differences be eliminated or they are accepted? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 06:53:20 2016 From: report at bugs.python.org (koobs) Date: Sun, 31 Jul 2016 10:53:20 +0000 Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation) In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <1469962400.71.0.252040767533.issue24773@psf.upfronthosting.co.za> koobs added the comment: Thank you Alexander, consider me satisfied :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 07:26:39 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 31 Jul 2016 11:26:39 +0000 Subject: [issue23746] sysconfg.is_python_build() is buggy In-Reply-To: <1427101982.73.0.589713060591.issue23746@psf.upfronthosting.co.za> Message-ID: <1469964399.33.0.615673093122.issue23746@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- components: -Library (Lib) keywords: +easy stage: -> needs patch type: -> enhancement versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 08:19:43 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 31 Jul 2016 12:19:43 +0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1469967583.77.0.743980166609.issue1621@psf.upfronthosting.co.za> Xiang Zhang added the comment: Martin, I upload a patch to fix another possible overflow in listextend. ---------- Added file: http://bugs.python.org/file43956/overflow_fix_in_listextend.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 09:02:46 2016 From: report at bugs.python.org (George King) Date: Sun, 31 Jul 2016 13:02:46 +0000 Subject: [issue27035] Cannot set exit code in atexit callback In-Reply-To: <1463385428.15.0.762354704325.issue27035@psf.upfronthosting.co.za> Message-ID: <1469970166.03.0.158432961874.issue27035@psf.upfronthosting.co.za> George King added the comment: The documentation for atexit.register clearly states that a SystemExit raised inside of the registered function is a special case: ''' If an exception is raised during execution of the exit handlers, a traceback is printed (unless SystemExit is raised) and the exception information is saved. After all exit handlers have had a chance to run the last exception to be raised is re-raised. ''' Python 2.7.11 behaves as described; Python 3.5.2 does not. I believe there is a clear argument for allowing atexit functions to set an exit status code: Ultimately, it is the responsibility of the application programmer to return an appropriate code for all execution paths, and it is up to the programmer to decide what is appropriate. I can easily imagine cases where the atexit function encounters a critical error and the appropriate behavior is to return an error status to the parent process. In many large systems, returning the correct code is the most critical behavior of a process, and so if atexit prevents the programmer from doing so then its utility is greatly diminished. I disagree that calling _exit is "equally broken". Calling _exit completely breaks the atexit unwinding contract, and if an error code is necessary, then this is exactly what I am forced to do! In my mind the correct behavior would be that the process exit code is determined from the last exception that occurs in the exit process. - If the program begins exiting with 0, and then an atexit handler raises SystemExit(1), then code 1 should be returned. - If the program begins exiting with 1, and then an atexit handler raises SystemExit(0), then code 0 should be returned (this may seem strange, but handlers can do all manner of strange things!). - If successive handlers raise multiple exceptions, the last one determines the code. - If the program is exiting with any code, and an exception other than SystemExit is raised, then we should return the code that would result from raising that exception in normal execution (usually 1). I expect this last case to be most contentious, because it changes behavior for both python2 and python3. However I think it is desirable because it gives the handlers precise capabilities (and responsibilities) regarding process status. The point of atexit is to allow modules to execute code in a deferred manner; the design already specifies a 'last exception wins' policy, and the problem is that we are unnecessarily suppressing the exit code that would result from that last exception. ---------- nosy: +George.King _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 09:54:45 2016 From: report at bugs.python.org (Thomas Perl) Date: Sun, 31 Jul 2016 13:54:45 +0000 Subject: [issue27641] Do not build Programs/_freeze_importlib when cross-compiling In-Reply-To: <1469703884.83.0.465404999691.issue27641@psf.upfronthosting.co.za> Message-ID: <1469973285.37.0.471471512829.issue27641@psf.upfronthosting.co.za> Thomas Perl added the comment: +1 on comment-out-regen.patch, makes things much cleaner and removes the shell "if" in the rule body. Just a small bikeshed issue: Instead of COMMENT_REGEN, maybe call it "CROSS_COMPILE_COMMENT" or "GENERATED_COMMENT" or "COMMENT_IF_CROSS" or somesuch? This way, might be easier to read/understand the makefile rules ("COMMENT_IF_CROSS" -> "a comment character will be inserted here if cross-compiling")? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 10:02:56 2016 From: report at bugs.python.org (R. David Murray) Date: Sun, 31 Jul 2016 14:02:56 +0000 Subject: [issue27657] urlparse fails if the path is numeric In-Reply-To: <1469908637.82.0.696114480311.issue27657@psf.upfronthosting.co.za> Message-ID: <1469973776.77.0.369073037387.issue27657@psf.upfronthosting.co.za> R. David Murray added the comment: I hate to say it, but this may require a python-dev discussion. We probably ought to be parsing valid urls correctly as our top priority, but if that breaks our parsing of "reasonable" non-valid URLs (that existing code is depending on), it's going to be a backward compatibility problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 10:04:36 2016 From: report at bugs.python.org (R. David Murray) Date: Sun, 31 Jul 2016 14:04:36 +0000 Subject: [issue27657] urlparse fails if the path is numeric In-Reply-To: <1469908637.82.0.696114480311.issue27657@psf.upfronthosting.co.za> Message-ID: <1469973876.26.0.0325353074367.issue27657@psf.upfronthosting.co.za> R. David Murray added the comment: On second thought, what are the chances that special casing something that looks like an IP address in the scheme position would maintain backward compatibility? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 10:12:47 2016 From: report at bugs.python.org (R. David Murray) Date: Sun, 31 Jul 2016 14:12:47 +0000 Subject: [issue27035] Cannot set exit code in atexit callback In-Reply-To: <1463385428.15.0.762354704325.issue27035@psf.upfronthosting.co.za> Message-ID: <1469974367.57.0.048381256851.issue27035@psf.upfronthosting.co.za> R. David Murray added the comment: Well, changing something like this in 2.7 is off the table in any case. This would be a "feature release only" type of change if there is agreement that it is a good idea. ---------- components: +Interpreter Core versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 10:13:10 2016 From: report at bugs.python.org (R. David Murray) Date: Sun, 31 Jul 2016 14:13:10 +0000 Subject: [issue27035] Cannot set exit code in atexit callback In-Reply-To: <1463385428.15.0.762354704325.issue27035@psf.upfronthosting.co.za> Message-ID: <1469974390.97.0.60380948062.issue27035@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 10:25:03 2016 From: report at bugs.python.org (Michael Felt) Date: Sun, 31 Jul 2016 14:25:03 +0000 Subject: [issue27435] ctypes and AIX - also for 2.7.X (and later) In-Reply-To: <1467383699.63.0.495142233463.issue27435@psf.upfronthosting.co.za> Message-ID: <1469975103.61.0.707821205765.issue27435@psf.upfronthosting.co.za> Michael Felt added the comment: > FYI: I tried to pip install Mercurial - but got an error message from an include file so the last bit did not compile. Problem for a later date - could be a user error on my part, or an AIX version dependency. (during discussion issue26439) I have mercurial "installed", but not (yet) any idea on how to use it to submit a patch. Again: going back to comments in issue26439 - and my 'new' responses as far as the patch submitted (but not yet using Mercurial) > Here is a summary of what I would be comfortable adding to Python: > 1. Add ctypes.RTLD_MEMBER constant (new API, so 3.6+ only) Not included. RTLD_MEMBER is a well documented constant needed for AIX dlopen. It is hard-coded in __init__.py > 2. Basic ctypes.util.find_library("crypto") implementation for AIX. But cases like find_library("libintl.so") should fail. I think your earlier patches were closer to this implementation than the later ones. Months further, I understand that is a variant behavior, and has been removed. find_library("c"), find_library("crypto") are supported, an argument suchas find_library("libintl.so") will return None (or something like /usr/lib/liblibintl.so will need to exist). > I am a bit hesitant about the automatic behaviour of CDLL("libcrypto.a(libcrypto.so.1.0.0)") using RTLD_MEMBER. IMO it may be better to let the caller specify RTLD_MEMBER explicitly. If a shared library file literally called ?/usr/lib/libcrypto.a(libcrypto.so.1.0.0)? existed, i.e. not inside an archive, would dlopen("libcrypto.a(libcrypto.so.1.0.0)", RTLD_NOW) succeed? I admit this is an unlikely scenario, but it seems bad to reduce the domain of a low-level API. >I hope this is now acceptable (see http://bugs.python.org/issue26439#msg267254) >> ## 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, > I understand it would be good to have the return value of find_library() consistent with the name accepted by CDLL(). Perhaps a new parameter format would help, such as a tuple (archive, member). > I am not comfortable with other aspects. I think I would have to see more discussion with other people to change my opinion: > 1. CDLL("libintl.so") should not load ?libintl.a(libintl.so.1)?. I understand you want this to help code written for Gnu or Linux automatically work on AIX, but it doesn?t feel correct and robust to me. Perhaps moving this sort of thing to a separate function or package would be better. > 2. find_library("libintl.so") -> "libintl.a(libintl.so.1)". I would expect it to look for a shared library installed in something like "/usr/lib/liblibintl.so.a", unless I have misunderstood how compile-time linking (cc -llibintl.so) works. Again, my misunderstanding of how this function is intended - python newbie. arguments starting with "lib" are not likely to work - and it is not on find_library to strip "lib" to make the argument more -l like. > 3. find_library() should not set the LIBPATH environment variable. As before, and as is the status in issue9998 - no use of LIBPATH or LD_LIBRARY_PATH - even though dlopen() does use them. Although, if your objection is primarily on 'set' (i.e., a get could be accepted) - that is easy to put back in. Thanks again for your help. Note: the reason for the new issue# is because too much of what I was submitting before was "extension" and not "correction". Hopefully, this makes the discussion more clear. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 10:26:27 2016 From: report at bugs.python.org (Michael Felt) Date: Sun, 31 Jul 2016 14:26:27 +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: <1469975187.26.0.188817401756.issue26439@psf.upfronthosting.co.za> Michael Felt added the comment: Thanks again for your help. Note: I started a issue# is because too much of what I was submitting here was "extension" and not "correction". Hopefully, the new issue# will be cleaner. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 10:33:09 2016 From: report at bugs.python.org (Antti Haapala) Date: Sun, 31 Jul 2016 14:33:09 +0000 Subject: [issue27078] Make f'' strings faster than .format: BUILD_STRING opcode? In-Reply-To: <1463858316.54.0.292581402272.issue27078@psf.upfronthosting.co.za> Message-ID: <1469975589.44.0.719099258298.issue27078@psf.upfronthosting.co.za> Antti Haapala added the comment: I would very much like to see this in 3.6. Who could review it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 11:41:42 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 31 Jul 2016 15:41:42 +0000 Subject: [issue19660] decorator syntax: allow testlist instead of just dotted_name In-Reply-To: <1469945921.61.0.82047600109.issue19660@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Nobody has posted a real use case. All the examples are toys. What are the real use cases that are blocked by this? Readability counts! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 12:04:34 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 31 Jul 2016 16:04:34 +0000 Subject: [issue27466] [Copy from github user macartur] time2netscape missing comma In-Reply-To: <1467948260.35.0.112204143726.issue27466@psf.upfronthosting.co.za> Message-ID: <1469981074.88.0.107958534677.issue27466@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 13:22:05 2016 From: report at bugs.python.org (Eric V. Smith) Date: Sun, 31 Jul 2016 17:22:05 +0000 Subject: [issue27078] Make f'' strings faster than .format: BUILD_STRING opcode? In-Reply-To: <1463858316.54.0.292581402272.issue27078@psf.upfronthosting.co.za> Message-ID: <1469985725.42.0.697398137221.issue27078@psf.upfronthosting.co.za> Eric V. Smith added the comment: I intend to review this. As this is not a new feature, it doesn't need to be completed by beta 1. I'm focusing my energies on new features, then I'll look at this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 13:40:09 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 31 Jul 2016 17:40:09 +0000 Subject: [issue27660] Replace size_t with Py_ssize_t as the type of local variable in list_resize Message-ID: <1469986809.78.0.371731130003.issue27660@psf.upfronthosting.co.za> New submission from Xiang Zhang: In list_resize, new_allocated is of type size_t but I think don't have to be now since it finally have to assign back to self->allocated which is of type Py_ssize_t. With Py_ssize_t, we can check some overflows in the first overflow check and don't need the second overflow check. ---------- components: Interpreter Core files: list_resize.patch keywords: patch messages: 271746 nosy: martin.panter, xiang.zhang priority: normal severity: normal status: open title: Replace size_t with Py_ssize_t as the type of local variable in list_resize type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43957/list_resize.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 13:59:17 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 31 Jul 2016 17:59:17 +0000 Subject: [issue27078] Make f'' strings faster than .format: BUILD_STRING opcode? In-Reply-To: <1463858316.54.0.292581402272.issue27078@psf.upfronthosting.co.za> Message-ID: <1469987957.91.0.388817737975.issue27078@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Since this introduces a new opcode, this is a new feature. Seems opcodes never were added at beta stage before 3.5b1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 15:12:12 2016 From: report at bugs.python.org (R. David Murray) Date: Sun, 31 Jul 2016 19:12:12 +0000 Subject: [issue27660] Replace size_t with Py_ssize_t as the type of local variable in list_resize In-Reply-To: <1469986809.78.0.371731130003.issue27660@psf.upfronthosting.co.za> Message-ID: <1469992332.73.0.0335133452664.issue27660@psf.upfronthosting.co.za> R. David Murray added the comment: ob->allocated is temporarily set to -1 by list.sort to detect mutations, so the restriction of new_allocated to size_t is probably intentional. If so, though, there ought to be a comment making that clear. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 15:14:30 2016 From: report at bugs.python.org (R. David Murray) Date: Sun, 31 Jul 2016 19:14:30 +0000 Subject: [issue27660] Replace size_t with Py_ssize_t as the type of local variable in list_resize In-Reply-To: <1469986809.78.0.371731130003.issue27660@psf.upfronthosting.co.za> Message-ID: <1469992470.83.0.00853711436089.issue27660@psf.upfronthosting.co.za> R. David Murray added the comment: Oh, I got that backward didn't I. My rusty C skills :( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 17:32:32 2016 From: report at bugs.python.org (Emanuel Barry) Date: Sun, 31 Jul 2016 21:32:32 +0000 Subject: [issue19660] decorator syntax: allow testlist instead of just dotted_name In-Reply-To: <1384910825.18.0.00604679093295.issue19660@psf.upfronthosting.co.za> Message-ID: <1470000752.12.0.592837176995.issue19660@psf.upfronthosting.co.za> Emanuel Barry added the comment: TL;DR - Use case is dynamic decorators. Not all of the syntax would make sense, see below. The main benefit of this feature would be for dynamic decorators (as was evidenced from others in this issue). In a project I contribute to, we use dynamic decorators to set a function as being a command, and we use the object (a wrapper around the function) directly, so we need a bit more boilerplate around the place. Ultimately, we would definitely use such a feature (just the '@spam().eggs()' part; we'd have no use for the other ones) , but we probably won't notice its absence either; we've worked around it for years, after all. As far as readability goes, I think allowing only the '@spam().eggs()' version would actually improve readability quite a bit, by reducing the need to separate the decorator assignment in two (or more) parts. I can see the desire to have a '@spam[eggs]' kind of syntax though, again for the dynamic decorators case. I see no reason to allow creating lambdas or conditional expressions inside decorators expressions. If anything, that'll encourage anti-patterns, whereas e.g. '@spam(value=eggs)' would be more readable, and would let the decorator decide what it wants to do with the value. And if your decorator can be expressed as a lambda, why don't you put that in/below the function? Surely it's less work than writing the lambda everytime ;) ---------- nosy: +ebarry versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 18:12:21 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 31 Jul 2016 22:12:21 +0000 Subject: [issue27661] Add tzinfo= argument to datetime.combine Message-ID: <1470003141.22.0.331878271067.issue27661@psf.upfronthosting.co.za> New submission from Alexander Belopolsky: Add an optional tzinfo argument to datetime.combine() so that datetime.combine(d, t, info) returns the same object as datetime.combine(d, t).replace(tzinfo=info) but without creating an intermediate naive instance. Guido's LGTM: https://mail.python.org/pipermail/datetime-sig/2016-July/000993.html ---------- assignee: belopolsky messages: 271751 nosy: belopolsky priority: normal severity: normal status: open title: Add tzinfo= argument to datetime.combine type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 18:58:07 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 31 Jul 2016 22:58:07 +0000 Subject: [issue27661] Add tzinfo= argument to datetime.combine In-Reply-To: <1470003141.22.0.331878271067.issue27661@psf.upfronthosting.co.za> Message-ID: <1470005887.37.0.0775252340045.issue27661@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file43958/issue27661.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 19:11:31 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 31 Jul 2016 23:11:31 +0000 Subject: [issue27477] IDLE: Switch search dialogs to ttk widgets, and other refinement In-Reply-To: <1468181977.57.0.555586182066.issue27477@psf.upfronthosting.co.za> Message-ID: <1470006691.87.0.934405124048.issue27477@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I debated whether to open a new search style issue and copy a message or defer ttk for config to another issue and re-title this. I went with widget group rather than aspect (style) this time. There are multiple search behavior issues. I added Notepad, Workpad, Libre Office Write, Tortoise Hg, and browsers to Notepad++ for Find/Search and Replace dialog box comparisons. From top to bottom. 0.1 De-modalize: The others are not modal and it is a nuisance. #24760 is about same for Config dialog. #24813 for Help stuff. I should look at your patches now. 0.2 List under Windows menu so easier to bring to top to use or close. Currently, cannot access Windows menu or anything else do to modality. Fortunately, Windows does list on popup expansion of taskbar icon. 1.0 Title: delete obvious "Dialog", add file base name. I sometime forget which file Search box is attached to and waste time searching wrong file. Will get worse with multiple boxes. 1.1 With tk, can we delete [-] min and [[]] max buttons and leave [X] close button? They are not present for 4 apps with floating boxes. #24039 is about inconsistent behavior of these buttons. If deleting them is a possible solution, I want to consider it. 2. I do not see 'whitespace around gray widgets', but I don't think I need to. I do see widgets jammed against edges and agree space is needed. Framing will also be wanted, I expect, as a pane for future single big window version of IDLE. I just noticed that TortoiseHg has 4 options for its main pane, Search being one of them. The 'tabs' are icons in a vertical strip to the right. Search is a magnifying glass. Each has a mouse hover popup word. 3. Regular expression, Match case, and Whole word modify What to search for, and belong together. Wraparound, Up, and Down modify How to search, and I think also belong together on a line. Grid would be 4 columns for these. 4.1 Close button should be at bottom or to the right. L.O.Write has [Help] and [Close] to bottom left and right respectively. I want to consider this. We could add a new parameter 'start_at' to help.py classes, defaulting to the top. "if start_at: " Then [Help] would display a new section "Search and Replace" added to the idle.rst and hence help.html. 'Find' is non-overlapping. 'Relational expression' uses patterns as defined in re doc. I have found 'whole word' not as obvious as I expected. It should have an explicit definition and behavior to match. Ditto for 'Match case' in a unicode world. 4.2 Putting the 4 F & R buttons across the bottom on platforms where that is the norm is OK with me. I only see down the side so far on Windows. Search could (should?) have [Find all] in addition to [Find next]. The 4 F & R buttons could be Find, Find all, Replace, Replace all (L.O.Write). But behavior change should be different issue. ---------- assignee: -> terry.reedy title: IDLE: Switch dialogs to ttk widgets. -> IDLE: Switch search dialogs to ttk widgets, and other refinement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 19:15:49 2016 From: report at bugs.python.org (Mark Roseman) Date: Sun, 31 Jul 2016 23:15:49 +0000 Subject: [issue27621] Finish IDLE Query dialog appearance and behavior. In-Reply-To: <1469512966.74.0.594331033204.issue27621@psf.upfronthosting.co.za> Message-ID: <1470006949.9.0.818426388049.issue27621@psf.upfronthosting.co.za> Mark Roseman added the comment: Serhiy, the tk_dialog has been superseded by tk_messageBox, and does not reflect current platform standards. I just tried tk_messageBox on the Mac, which always activates the default button if you press 'return', even if another button has the focus. I expect Windows and X11 are different, and will check that out when I get a chance. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 20:01:33 2016 From: report at bugs.python.org (Ned Deily) Date: Mon, 01 Aug 2016 00:01:33 +0000 Subject: [issue27632] build on AIX fails when builddir != srcdir, more than bad path to ld_so_aix In-Reply-To: <1469608112.86.0.803958819971.issue27632@psf.upfronthosting.co.za> Message-ID: <1470009693.27.0.203414264999.issue27632@psf.upfronthosting.co.za> Ned Deily added the comment: Possible duplicate of Issue10656 (see also Issue16189) ---------- nosy: +David.Edelsohn, ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 20:01:44 2016 From: report at bugs.python.org (Ned Deily) Date: Mon, 01 Aug 2016 00:01:44 +0000 Subject: [issue27632] build on AIX fails when builddir != srcdir, more than bad path to ld_so_aix In-Reply-To: <1469608112.86.0.803958819971.issue27632@psf.upfronthosting.co.za> Message-ID: <1470009704.02.0.230265348426.issue27632@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: -ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 20:39:34 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 01 Aug 2016 00:39:34 +0000 Subject: [issue19660] decorator syntax: allow testlist instead of just dotted_name In-Reply-To: <1470000752.12.0.592837176995.issue19660@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Could you link to an example decorator definition and its call site(s) that would benefit? I'm lacking the imagination to understand what a "dynamic decorator" might be. @spam().eggs() is not enough to help me understand -- I understand quite well what syntax people are requesting, but I am unclear on what they actually want to do with it. I worry there's some extreme use of higher-order functions here that would just get in the way of readability, but a real-world example might dispell my fear. (That's what I meant when I said "use case".) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 20:51:10 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 01 Aug 2016 00:51:10 +0000 Subject: [issue27621] Finish IDLE Query dialog appearance and behavior. In-Reply-To: <1469512966.74.0.594331033204.issue27621@psf.upfronthosting.co.za> Message-ID: <1470012670.93.0.417956382957.issue27621@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Background: For Open Module, the old commondialog did not have the asymmetrical drop shadow. That is an unintentional addition (from a frame?) and I don't like it. Perhaps we should use grid instead. Rows 0 and 1 for the initial label and entry, with columnspan 2, rows 8 and 9 for error message and buttons. This leaves room for insertion of path message, path entry, and browse button. Patch welcome. A definite yes for error label in widget. I dislike the popup. Begone! Should a blank label reserve space or should it be inserted as needed, making box expand. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 20:54:45 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 01 Aug 2016 00:54:45 +0000 Subject: [issue27621] Finish IDLE Query dialog appearance and behavior. In-Reply-To: <1469512966.74.0.594331033204.issue27621@psf.upfronthosting.co.za> Message-ID: <1470012885.82.0.397485278927.issue27621@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Serhiy: I believe Notepad, Wordpad, Libre Office Write behave as you describe. But there are differences in details. So I don't consider issue closed, but it is low priority to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 21:16:12 2016 From: report at bugs.python.org (Emanuel Barry) Date: Mon, 01 Aug 2016 01:16:12 +0000 Subject: [issue19660] decorator syntax: allow testlist instead of just dotted_name In-Reply-To: <1384910825.18.0.00604679093295.issue19660@psf.upfronthosting.co.za> Message-ID: <1470014172.0.0.143172132823.issue19660@psf.upfronthosting.co.za> Emanuel Barry added the comment: Sure, here goes; this is an IRC game bot which I contribute to. Apologies for the long links, it's the only way to make sure this consistently points to the same place regardless of future commits. The 'cmd' decorator we use is defined at https://github.com/lykoss/lykos/blob/1852bf2c442d707ba0cbc16e8c9e012bcbc4fcc5/src/decorators.py#L67 - we use its __call__ method to add the function to it; see next link. How it's used: https://github.com/lykoss/lykos/blob/1852bf2c442d707ba0cbc16e8c9e012bcbc4fcc5/src/wolfgame.py#L9113 - ideally, a syntax such as the following would be nice for these definitions: ?@cmd("myrole", ).set def myrole(cli, nick, chan, rest): # ... do stuff here ... Historically (we used an arcane closure-based version that no one understood), we could call that function after directly, like any normal function. Now, though, we have to call it like this: https://github.com/lykoss/lykos/blob/1852bf2c442d707ba0cbc16e8c9e012bcbc4fcc5/src/wolfgame.py#L764 I'd like to state again that, while we'd use this new syntax, we've already worked around this lack of syntax. Whatever comes out of this, we won't be negatively affected, but decorators are meant to bring whatever alters the function right where it starts, so having syntax that eases that would make sense (to me, anyway). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 21:26:13 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 01 Aug 2016 01:26:13 +0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1470014773.69.0.35715884641.issue1621@psf.upfronthosting.co.za> Martin Panter added the comment: overflow_fix_in_listextend.patch: I doubt Python supports the kinds of platform where this overflow would be possible. It may require pointers smaller than 32 bits, or char objects larger than 8 bits. Perhaps we could just add a comment explaining we assume the overflow cannot happen. It seems list objects will hold one pointer for each element, but the overflow involves the number of elements. Python defines PY_SSIZE_T_MAX as PY_SIZE_MAX // 2. For the overflow to happen we would need m + n > PY_SSIZE_T_MAX Assuming a ?flat? address space that can allocate up to PY_SIZE_MAX bytes _in total_, the total number of elements cannot exceed m + n == PY_SIZE_MAX // sizeof (PyObject *) So in this scenario, the overflow cannot happen unless sizeof (PyObject *) == 1. Considering things like the 16-bit segmented Intel ?large? memory model (which I doubt Python is compatible with), each list could _independently_ be up to PY_SIZE_MAX bytes. Therefore the total number of elements may reach m + n == PY_SIZE_MAX // sizeof (PyObject *) * 2 So even in this case, sizeof (PyObject *) == 4 (large model) is fine, but anything less (e.g. 16-bit char, or 1-byte segment + 2-byte offset) might overflow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 21:32:33 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 01 Aug 2016 01:32:33 +0000 Subject: [issue27641] Do not build Programs/_freeze_importlib when cross-compiling In-Reply-To: <1469703884.83.0.465404999691.issue27641@psf.upfronthosting.co.za> Message-ID: <1470015153.88.0.0530340311066.issue27641@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for the feedback. I did wonder about the name. Perhaps I will go with GENERATED_COMMENT: GENERATED_COMMENT='#' Python/importlib_external.h: @GENERATED_COMMENT@ $(srcdir)/Lib/importlib/_bootstrap_external.py Programs/_freeze_importlib ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 21:57:47 2016 From: report at bugs.python.org (Mark Roseman) Date: Mon, 01 Aug 2016 01:57:47 +0000 Subject: [issue27621] Finish IDLE Query dialog appearance and behavior. In-Reply-To: <1469512966.74.0.594331033204.issue27621@psf.upfronthosting.co.za> Message-ID: <1470016667.72.0.742034559739.issue27621@psf.upfronthosting.co.za> Mark Roseman added the comment: Just to follow up, both Windows and Linux the 'correct' behaviour seems to be that space or return activates the button with the current focus. Mac behaves differently in that return key always activates default button even if focus is on another button (and normally on Mac, buttons don't get focus). I'll put together a patch that cleans up the layout and does the error label in dialog thing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 22:23:09 2016 From: report at bugs.python.org (Ned Deily) Date: Mon, 01 Aug 2016 02:23:09 +0000 Subject: [issue10673] multiprocess.Process join method - timeout indistinguishable from success In-Reply-To: <1291991778.63.0.145134143934.issue10673@psf.upfronthosting.co.za> Message-ID: <1470018189.58.0.511831264678.issue10673@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 22:31:27 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 01 Aug 2016 02:31:27 +0000 Subject: [issue19660] decorator syntax: allow testlist instead of just dotted_name In-Reply-To: <1470014172.0.0.143172132823.issue19660@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: OK, so if you wanted to be able to call myrole(...) instead of myrole.caller, why doesn't cmd.__call__ return self.caller rather than just self? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 22:51:50 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 01 Aug 2016 02:51:50 +0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1470019910.1.0.696396771282.issue1621@psf.upfronthosting.co.za> Xiang Zhang added the comment: Hmm, I don't tend to infer platform characteristics. IMHO, it's a simple problem: sum up two lists' length which may overflow in logic. With your argument, does it means it seems somewhat meaningless to have a List a Py_ssize_t length since it can never reach it? Checks against PY_SSIZE_T_MAX have already existed (for example, in ins1). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 22:52:07 2016 From: report at bugs.python.org (Emanuel Barry) Date: Mon, 01 Aug 2016 02:52:07 +0000 Subject: [issue19660] decorator syntax: allow testlist instead of just dotted_name In-Reply-To: <1384910825.18.0.00604679093295.issue19660@psf.upfronthosting.co.za> Message-ID: <1470019927.02.0.784663436616.issue19660@psf.upfronthosting.co.za> Emanuel Barry added the comment: We want to be able to access the instance attributes (as is done e.g. here: https://github.com/lykoss/lykos/blob/1852bf2c442d707ba0cbc16e8c9e012bcbc4fcc5/src/wolfgame.py#L9761 ). I realize we can set the attributes directly on the functions, but we've decided to not do that (it's a style thing, really). Although I guess a class method which then returns our desired method could work out for us. While I still think that this kind of syntax might be useful for dynamic decorators (I know I'd use that when playing with decorators), I'm afraid I'm out of concrete examples to send your way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 22:57:42 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 01 Aug 2016 02:57:42 +0000 Subject: [issue27660] Replace size_t with Py_ssize_t as the type of local variable in list_resize In-Reply-To: <1469986809.78.0.371731130003.issue27660@psf.upfronthosting.co.za> Message-ID: <1470020262.51.0.163474513728.issue27660@psf.upfronthosting.co.za> Xiang Zhang added the comment: :( Sorry David, my poor English doesn't enable me understand your message totally. Is list.sort related to this problem? Do I miss something? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 23:22:57 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 01 Aug 2016 03:22:57 +0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1470021777.24.0.903130320615.issue1621@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- nosy: -gregory.p.smith _______________________________________ Python tracker _______________________________________