From report at bugs.python.org Fri Feb 1 00:21:32 2019 From: report at bugs.python.org (Jayanth Raman) Date: Fri, 01 Feb 2019 05:21:32 +0000 Subject: [issue35871] Pdb NameError in generator param and list comprehension In-Reply-To: <1548980749.75.0.843445055452.issue35871@roundup.psfhosted.org> Message-ID: <1548998492.91.0.442311015756.issue35871@roundup.psfhosted.org> Jayanth Raman added the comment: Thanks for the "interact" tip. FWIW, I see this issue in 2.7.10 as well. Although the list comprehension works. $ python Python 2.7.10 (default, Oct 6 2017, 22:29:07) [GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.31)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> ^D $ python /tmp/test2.py > /tmp/test2.py(5)main() -> for ii in range(nn): (Pdb) n > /tmp/test2.py(6)main() -> num = sum(xx[jj] for jj in range(nn)) (Pdb) sum(xx[jj] for jj in range(nn)) *** NameError: global name 'xx' is not defined (Pdb) [xx[jj] for jj in range(nn)] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] (Pdb) c ('xx', [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]) # test2.py def main(nn=10): xx = list(range(nn)) import pdb; pdb.set_trace() for ii in range(nn): num = sum(xx[jj] for jj in range(nn)) print('xx', xx) if __name__ == '__main__': main() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 00:22:29 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Fri, 01 Feb 2019 05:22:29 +0000 Subject: [issue35866] concurrent.futures deadlock In-Reply-To: <1548929111.09.0.517798780255.issue35866@roundup.psfhosted.org> Message-ID: <1548998549.87.0.799320169715.issue35866@roundup.psfhosted.org> Josh Rosenberg added the comment: I've only got 3.7.1 Ubuntu bash on Windows (also amd64) immediately available, but I'm not seeing a hang, nor is there any obvious memory leak that might eventually lead to problems (memory regularly drops back to under 10 MB shared, 24 KB private working set). I modified your code to add a sys.stdout.flush() after the write so it would actually echo the dots as they were written instead of waiting for a few thousand of them to build up in the buffer, but otherwise it's the same code. Are you sure you're actually hanging, and it's not just the output getting buffered? ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 00:25:00 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Fri, 01 Feb 2019 05:25:00 +0000 Subject: [issue35862] Change the environment for a new process In-Reply-To: <1548877516.06.0.747468813802.issue35862@roundup.psfhosted.org> Message-ID: <1548998700.31.0.43292525533.issue35862@roundup.psfhosted.org> Change by Josh Rosenberg : Removed file: https://bugs.python.org/file48089/bq-nix.manifest _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 00:25:24 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Fri, 01 Feb 2019 05:25:24 +0000 Subject: [issue35862] Change the environment for a new process In-Reply-To: <1548877516.06.0.747468813802.issue35862@roundup.psfhosted.org> Message-ID: <1548998724.34.0.33896608462.issue35862@roundup.psfhosted.org> Change by Josh Rosenberg : Removed file: https://bugs.python.org/file48088/bq-nix.snapshot.json _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 00:25:34 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Fri, 01 Feb 2019 05:25:34 +0000 Subject: [issue35862] Change the environment for a new process In-Reply-To: <1548877516.06.0.747468813802.issue35862@roundup.psfhosted.org> Message-ID: <1548998734.16.0.498225642272.issue35862@roundup.psfhosted.org> Change by Josh Rosenberg : Removed file: https://bugs.python.org/file48087/core-nix.snapshot.json _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 00:26:20 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Fri, 01 Feb 2019 05:26:20 +0000 Subject: [issue35862] Change the environment for a new process In-Reply-To: <1548877516.06.0.747468813802.issue35862@roundup.psfhosted.org> Message-ID: <1548998780.8.0.58988885556.issue35862@roundup.psfhosted.org> Change by Josh Rosenberg : ---------- Removed message: https://bugs.python.org/msg334593 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 00:31:18 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Fri, 01 Feb 2019 05:31:18 +0000 Subject: [issue35862] Change the environment for a new process In-Reply-To: <1548877516.06.0.747468813802.issue35862@roundup.psfhosted.org> Message-ID: <1548999078.23.0.981327123108.issue35862@roundup.psfhosted.org> Josh Rosenberg added the comment: Why is not having the target assign to the relevant os.environ keys before doing whatever depends on the environment not an option? ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 01:00:32 2019 From: report at bugs.python.org (=?utf-8?q?Tobias_D=C3=A4ullary?=) Date: Fri, 01 Feb 2019 06:00:32 +0000 Subject: [issue35862] Change the environment for a new process In-Reply-To: <1548877516.06.0.747468813802.issue35862@roundup.psfhosted.org> Message-ID: <1549000832.85.0.347675801664.issue35862@roundup.psfhosted.org> Tobias D?ullary added the comment: Because sometimes when a process is implicitly started by some 3rd party library (i.e. COM via pythonwin here) the "old", unchanged environment is retained as the process itself doesn't care if os.environ was changed or not, the original environment cannot be modified. This solution would give a lot of flexibility in that regard. I think pythonwin is actually a special case as the problem here lies somewhere in the dispatch(.) call. The process creation should be handled somewhere within the COM interface, pywin does nothing there. But this solution effectively circumvents that issue. ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 01:07:37 2019 From: report at bugs.python.org (Matt Joiner) Date: Fri, 01 Feb 2019 06:07:37 +0000 Subject: [issue12822] NewGIL should use CLOCK_MONOTONIC if possible. In-Reply-To: <1314085416.99.0.752578807259.issue12822@psf.upfronthosting.co.za> Message-ID: <1549001257.06.0.230905043159.issue12822@roundup.psfhosted.org> Change by Matt Joiner : ---------- nosy: -anacrolix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 01:51:35 2019 From: report at bugs.python.org (Jakub Wilk) Date: Fri, 01 Feb 2019 06:51:35 +0000 Subject: [issue35866] concurrent.futures deadlock In-Reply-To: <1548929111.09.0.517798780255.issue35866@roundup.psfhosted.org> Message-ID: <1549003895.54.0.15429208006.issue35866@roundup.psfhosted.org> Jakub Wilk added the comment: You're right that sys.stdout.flush() is missing in my code; but on Linux it doesn't make a big difference, because multiprocessing flushes stdout before fork()ing. And yes, it really hangs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 02:21:31 2019 From: report at bugs.python.org (SilentGhost) Date: Fri, 01 Feb 2019 07:21:31 +0000 Subject: [issue35868] Support ALL_PROXY environment variable in urllib In-Reply-To: <1548941734.95.0.137679013052.issue35868@roundup.psfhosted.org> Message-ID: <1549005691.8.0.104991889743.issue35868@roundup.psfhosted.org> SilentGhost added the comment: This sounds like an extension of existing functionality and fairly minor at that, that's why we have "enhancement" type of issue, not everything needs to be a bug. ---------- nosy: +SilentGhost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 03:19:52 2019 From: report at bugs.python.org (jcrmatos) Date: Fri, 01 Feb 2019 08:19:52 +0000 Subject: [issue35858] Consider adding the option of running shell/console commands inside the REPL In-Reply-To: <1548856317.43.0.990558066571.issue35858@roundup.psfhosted.org> Message-ID: <1549009192.52.0.988589509112.issue35858@roundup.psfhosted.org> jcrmatos added the comment: I will, thanks. ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 03:36:11 2019 From: report at bugs.python.org (Martin Panter) Date: Fri, 01 Feb 2019 08:36:11 +0000 Subject: [issue35869] io.BufferReader.read() returns None In-Reply-To: <1548948110.23.0.999331035986.issue35869@roundup.psfhosted.org> Message-ID: <1549010171.14.0.306231721234.issue35869@roundup.psfhosted.org> Martin Panter added the comment: This is covered by Issue 13322. There are a few other BufferedReader methods that contradict the documentation for non-blocking mode. A while ago I posted a patch to change the implementation to match the documentation, but nobody reviewed it or gave their opinion. These days I would prefer to just documentat the reality: the methods might raise an exception rather than returning None, or perhaps no particular behaviour at all is expected in general in the non-blocking case. But I don?t spend much time on Python now, so you might have to find someone else to move this forward. Regarding the entry for ?BufferedReader.read?, it would make more sense to remove the last ?if?: ?if ?size? is not given . . ., until EOF, or the ?read? call would block?. But I don?t think even that is complete, because it should also say the read stops and returns short in the non-blocking case even when ?size? is positive. ---------- assignee: -> docs at python components: +Documentation, IO nosy: +docs at python, martin.panter superseder: -> buffered read() and write() does not raise BlockingIOError _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 03:42:44 2019 From: report at bugs.python.org (Eryk Sun) Date: Fri, 01 Feb 2019 08:42:44 +0000 Subject: [issue35862] Change the environment for a new process In-Reply-To: <1548877516.06.0.747468813802.issue35862@roundup.psfhosted.org> Message-ID: <1549010564.82.0.103961572056.issue35862@roundup.psfhosted.org> Eryk Sun added the comment: > Because sometimes when a process is implicitly started by some 3rd > party library (i.e. COM via pythonwin here) the "old", unchanged > environment is retained as the process itself doesn't care if > os.environ was changed or not, the original environment cannot > be modified. What "old" environment are we talking about? The os.environ mapping is implemented to immediately modify the process environment block. For example: Python: >>> os.environ['SPAM'] = 'EGGS' Debugger: Breakpoint 0 hit KERNELBASE!SetEnvironmentVariableW: 00007fff`8ae3ee30 4053 push rbx 0:000> kc 6 Call Site KERNELBASE!SetEnvironmentVariableW ucrtbase!common_set_variable_in_environment_nolock ucrtbase!common_putenv_nolock ucrtbase!common_putenv python37!os_putenv_impl python37!os_putenv 0:000> du @rcx 00000215`70dd57c0 "SPAM" 0:000> du @rdx 00000215`70dd57ca "EGGS" ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 03:46:38 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 01 Feb 2019 08:46:38 +0000 Subject: [issue35868] Support ALL_PROXY environment variable in urllib In-Reply-To: <1548941734.95.0.137679013052.issue35868@roundup.psfhosted.org> Message-ID: <1549010798.06.0.570598614815.issue35868@roundup.psfhosted.org> Ronald Oussoren added the comment: The all_proxy setting is used by other software as well, see for example the manpage for curl and this feature request for requests . Adding support for all_proxy to urllib sounds like a useful feature to me. ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 03:49:14 2019 From: report at bugs.python.org (Marc Schlaich) Date: Fri, 01 Feb 2019 08:49:14 +0000 Subject: [issue35872] Creating venv from venv no longer works in 3.7.2 Message-ID: <1549010953.4.0.913686801166.issue35872@roundup.psfhosted.org> New submission from Marc Schlaich : Creating a venv from the python.exe from another venv does not work since 3.7.2 on Windows. This is probably related to the change bpo-34977: venv on Windows will now use a python.exe redirector rather than copying the actual binaries from the base environment. For example running c:\users\$USER\.local\pipx\venvs\pipx-app\scripts\python.exe -m venv C:\Users\$USER\.local\pipx\venvs\tox C:\Users\$USER\.local\pipx\venvs\tox\Scripts\python.exe -m pip install --upgrade pip results in pip installing to venvs\pipx-app and not in venvs\tox. Downstream bugreport in pipx is https://github.com/pipxproject/pipx-app/issues/81. ---------- components: Library (Lib), Windows messages: 334658 nosy: paul.moore, schlamar, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Creating venv from venv no longer works in 3.7.2 type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 04:03:06 2019 From: report at bugs.python.org (Marc Schlaich) Date: Fri, 01 Feb 2019 09:03:06 +0000 Subject: [issue35873] Controlling venv from venv no longer works in 3.7.2 Message-ID: <1549011784.82.0.296319027076.issue35873@roundup.psfhosted.org> New submission from Marc Schlaich : Controlling a venv from the python.exe from another venv does not work since 3.7.2 on Windows. This is probably related to the change bpo-34977: venv on Windows will now use a python.exe redirector rather than copying the actual binaries from the base environment. This is obviously related to bpo-35872, but this could be a different bug. When a Python script in a venv wants to control another venv by running commands like `another-venv\python.exe -m pip` with subprocess, python.exe is not referencing the other venv. It is referencing to the venv the script currently running from. This is probably because os.environ contains a '__PYVENV_LAUNCHER__' which is pointing to the venv from the script. This can be reproduced with pipx (https://github.com/pipxproject/pipx-app) by running pipx install --python "C:\Program Files (x86)\Python37-32\python.exe" --verbose tox This results in pip installing to venvs\pipx-app and not in venvs\tox. I assume a simpler reproduction might be (but I cannot check this anymore as I'm back on 3.7.1 right now): C:\Program Files (x86)\Python37-32\python.exe -m venv C:\Users\$USER\.local\pipx\venvs\tox c:\users\$USER\.local\pipx\venvs\pipx-app\scripts\python.exe -c "import subprocess; subprocess.run(['C:\Users\$USER\.local\pipx\venvs\tox\Scripts\python.exe', '-m', 'pip', 'install', 'tox'])" Downstream bugreport in pipx is https://github.com/pipxproject/pipx-app/issues/81. ---------- components: Library (Lib), Windows messages: 334659 nosy: paul.moore, schlamar, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Controlling venv from venv no longer works in 3.7.2 type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 04:03:31 2019 From: report at bugs.python.org (Antony Lee) Date: Fri, 01 Feb 2019 09:03:31 +0000 Subject: [issue35874] Clarify that the (...) convertor to PyArg_ParseTuple... accepts any sequence. Message-ID: <1549011809.83.0.066679441781.issue35874@roundup.psfhosted.org> New submission from Antony Lee : The documentation for the accepted types for each format unit in PyArg_ParseTuple (and its variants) is usually quite detailed; compare for example y* (bytes-like object) [Py_buffer] This variant on s* doesn?t accept Unicode objects, only bytes-like objects. This is the recommended way to accept binary data. and S (bytes) [PyBytesObject *] Requires that the Python object is a bytes object, without attempting any conversion. Raises TypeError if the object is not a bytes object. The C variable may also be declared as PyObject*. There, the type in parenthesis (which is explained as "the entry in (round) parentheses is the Python object type that matches the format unit") differentiates between "bytes-like object" and "bytes". However, the documentation for "(...)" is a bit more confusing: (items) (tuple) [matching-items] The object must be a Python sequence whose length is the number of format units in items. The C arguments must correspond to the individual format units in items. Format units for sequences may be nested. The type in parenthesis is "tuple" (exactly), but the paragraph says "sequence". The actual behavior appears indeed to be that any sequence (e.g., list, numpy array) is accepted, so I'd suggest changing the type in the parenthesis to "sequence". ---------- assignee: docs at python components: Documentation messages: 334660 nosy: Antony.Lee, docs at python priority: normal severity: normal status: open title: Clarify that the (...) convertor to PyArg_ParseTuple... accepts any sequence. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 05:05:35 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Feb 2019 10:05:35 +0000 Subject: [issue35537] use os.posix_spawn in subprocess In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za> Message-ID: <1549015535.07.0.751184987054.issue35537@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 80c5dfe74b4402d0a220c9227f262ec6fde1d7fc by Victor Stinner (Joannah Nanjekye) in branch 'master': bpo-35537: Add setsid parameter to os.posix_spawn() and os.posix_spawnp() (GH-11608) https://github.com/python/cpython/commit/80c5dfe74b4402d0a220c9227f262ec6fde1d7fc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 05:23:53 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Feb 2019 10:23:53 +0000 Subject: [issue35537] use os.posix_spawn in subprocess In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za> Message-ID: <1549016633.75.0.602537418254.issue35537@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +11583 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 05:24:10 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Feb 2019 10:24:10 +0000 Subject: [issue35537] use os.posix_spawn in subprocess In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za> Message-ID: <1549016650.82.0.0383284791953.issue35537@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +11583, 11584 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 05:24:26 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Feb 2019 10:24:26 +0000 Subject: [issue35537] use os.posix_spawn in subprocess In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za> Message-ID: <1549016666.79.0.554991717634.issue35537@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +11583, 11584, 11585 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 05:25:22 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Feb 2019 10:25:22 +0000 Subject: [issue35537] use os.posix_spawn in subprocess In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za> Message-ID: <1549016722.2.0.127264136592.issue35537@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +11586 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 05:25:37 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Feb 2019 10:25:37 +0000 Subject: [issue35537] use os.posix_spawn in subprocess In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za> Message-ID: <1549016737.04.0.996139234671.issue35537@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +11586, 11587 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 05:25:51 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Feb 2019 10:25:51 +0000 Subject: [issue35537] use os.posix_spawn in subprocess In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za> Message-ID: <1549016751.42.0.496134268815.issue35537@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +11586, 11587, 11588 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 05:40:29 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Feb 2019 10:40:29 +0000 Subject: [issue35537] use os.posix_spawn in subprocess In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za> Message-ID: <1549017629.35.0.9012024749.issue35537@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 1e39b83f24ffade3e0ca1a8004b461354f64ae08 by Victor Stinner in branch 'master': bpo-35537: Skip test_start_new_session() of posix_spawn (GH-11718) https://github.com/python/cpython/commit/1e39b83f24ffade3e0ca1a8004b461354f64ae08 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 05:52:28 2019 From: report at bugs.python.org (Bangert) Date: Fri, 01 Feb 2019 10:52:28 +0000 Subject: [issue35875] Crash - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd Message-ID: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> New submission from Bangert : Windows 7 x64 Visual Studio 2017 15.9.6 netframework 4.7 conda 3.6 x64 On project load both extensions algos and joint crash. ---------- components: Extension Modules files: Conda-Algos-Joint-Crash.jpg messages: 334663 nosy: AxelArnoldBangert priority: normal severity: normal status: open title: Crash - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd type: crash versions: Python 3.6 Added file: https://bugs.python.org/file48092/Conda-Algos-Joint-Crash.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 05:53:21 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Fri, 01 Feb 2019 10:53:21 +0000 Subject: [issue35876] test_start_new_session for posix_spawnp fails Message-ID: <1549018399.45.0.971138800303.issue35876@roundup.psfhosted.org> New submission from Pablo Galindo Salgado : Example failure: https://buildbot.python.org/all/#/builders/141/builds/1142/steps/4/logs/stdio ===================================================================== ERROR: test_start_new_session (test.test_posix.TestPosixSpawn) ---------------------------------------------------------------------- Traceback (most recent call last): File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_posix.py", line 1640, in test_start_new_session child_pgid = int(output) NameError: name 'output' is not defined ====================================================================== ERROR: test_start_new_session (test.test_posix.TestPosixSpawnP) ---------------------------------------------------------------------- Traceback (most recent call last): File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_posix.py", line 1640, in test_start_new_session child_pgid = int(output) NameError: name 'output' is not defined ---------------------------------------------------------------------- Victor made a PR to ignore the test for now: https://github.com/python/cpython/pull/11718 This WIP PR intends to fix this bug: https://github.com/python/cpython/pull/11719 ---------- components: Tests messages: 334664 nosy: pablogsal priority: normal severity: normal status: open title: test_start_new_session for posix_spawnp fails versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 05:55:56 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Fri, 01 Feb 2019 10:55:56 +0000 Subject: [issue35877] parenthesis is mandatory for named expressions in while statement Message-ID: <1549018555.29.0.231525655805.issue35877@roundup.psfhosted.org> New submission from Karthikeyan Singaravelan : I thought to open a separate report itself in order to keep the original issue not cluttered with questions since it could be used for other docs. Sorry for my report there. Original report as per msg334341 . It seems parens are mandatory while using named expressions in while statement which makes some of the examples invalid like https://www.python.org/dev/peps/pep-0572/#sysconfig-py . From my limited knowledge while statement Grammar was not modified at https://github.com/python/cpython/pull/10497/files#diff-cb0b9d6312c0d67f6d4aa1966766ceddR73 and no tests for while statement which made me assume it's intentional. I haven't followed the full discussion about PEP 572 so feel free to correct me if it's a conscious decision and in that case the PEP 572 can be updated. # python info ? cpython git:(master) ./python.exe Python 3.8.0a0 (heads/bpo35113-dirty:49329a217e, Jan 25 2019, 09:57:53) [Clang 7.0.2 (clang-700.1.81)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> # Example as in PEP 572 to create a simple file that reads itself and prints lines that matches "foo" ? cpython git:(master) cat /tmp/foo.py import re with open("/tmp/foo.py") as f: while line := f.readline(): if match := re.search(r"foo", line): print(match.string.strip("\n")) ? cpython git:(master) ./python.exe /tmp/foo.py File "/tmp/foo.py", line 4 while line := f.readline(): ^ SyntaxError: invalid syntax # Wrapping named expression with parens for while makes this valid ? cpython git:(master) cat /tmp/foo.py import re with open("/tmp/foo.py") as f: while (line := f.readline()): if match := re.search(r"foo", line): print(match.string.strip("\n")) ? cpython git:(master) ./python.exe /tmp/foo.py with open("/tmp/foo.py") as f: if match := re.search(r"foo", line): As a user I think parens shouldn't be mandatory in while statement since if statement works fine. Parens can cause while statement to be superfluous in some cases and an extra case to remember while teaching. ---------- components: Interpreter Core messages: 334665 nosy: emilyemorehouse, gvanrossum, xtreak priority: normal severity: normal status: open title: parenthesis is mandatory for named expressions in while statement type: behavior versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 05:56:54 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Feb 2019 10:56:54 +0000 Subject: [issue35876] test_start_new_session for posix_spawnp fails In-Reply-To: <1549018399.45.0.971138800303.issue35876@roundup.psfhosted.org> Message-ID: <1549018614.04.0.814576080528.issue35876@roundup.psfhosted.org> STINNER Victor added the comment: I skipped the test with commit 1e39b83f24ffade3e0ca1a8004b461354f64ae08. But the test still needs to be fixed. Joannah Nanjekye wrote the new test and I'm mentoring her, so I would prefer that she fix the test. ---------- nosy: +nanjekyejoannah, vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 06:03:40 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Fri, 01 Feb 2019 11:03:40 +0000 Subject: [issue35875] Crash - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd In-Reply-To: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> Message-ID: <1549019020.21.0.486144076451.issue35875@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Can you please add a minimal reproducer for this without any external dependencies? I couldn't see any references to the extensions you have mentioned in the title in CPython repo. Please add in a description over how this is a problem with CPython and not with external dependencies/extensions if any. Thanks ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 06:05:53 2019 From: report at bugs.python.org (Roundup Robot) Date: Fri, 01 Feb 2019 11:05:53 +0000 Subject: [issue35864] Replace OrderedDict with regular dict in namedtuple's _asdict() method. In-Reply-To: <1548901211.98.0.0872539907535.issue35864@roundup.psfhosted.org> Message-ID: <1549019153.64.0.909091031792.issue35864@roundup.psfhosted.org> Change by Roundup Robot : ---------- pull_requests: +11589 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 06:05:57 2019 From: report at bugs.python.org (Roundup Robot) Date: Fri, 01 Feb 2019 11:05:57 +0000 Subject: [issue35864] Replace OrderedDict with regular dict in namedtuple's _asdict() method. In-Reply-To: <1548901211.98.0.0872539907535.issue35864@roundup.psfhosted.org> Message-ID: <1549019157.46.0.15604845383.issue35864@roundup.psfhosted.org> Change by Roundup Robot : ---------- pull_requests: +11589, 11590 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 06:06:01 2019 From: report at bugs.python.org (Roundup Robot) Date: Fri, 01 Feb 2019 11:06:01 +0000 Subject: [issue35864] Replace OrderedDict with regular dict in namedtuple's _asdict() method. In-Reply-To: <1548901211.98.0.0872539907535.issue35864@roundup.psfhosted.org> Message-ID: <1549019161.16.0.533597162668.issue35864@roundup.psfhosted.org> Change by Roundup Robot : ---------- pull_requests: +11589, 11590, 11592 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 06:06:04 2019 From: report at bugs.python.org (Roundup Robot) Date: Fri, 01 Feb 2019 11:06:04 +0000 Subject: [issue35864] Replace OrderedDict with regular dict in namedtuple's _asdict() method. In-Reply-To: <1548901211.98.0.0872539907535.issue35864@roundup.psfhosted.org> Message-ID: <1549019164.22.0.409109531556.issue35864@roundup.psfhosted.org> Change by Roundup Robot : ---------- pull_requests: +11589, 11590, 11591, 11592 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 06:16:44 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Feb 2019 11:16:44 +0000 Subject: [issue35537] use os.posix_spawn in subprocess In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za> Message-ID: <1549019804.81.0.642016939576.issue35537@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +11593 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 06:17:02 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Feb 2019 11:17:02 +0000 Subject: [issue35537] use os.posix_spawn in subprocess In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za> Message-ID: <1549019822.19.0.00839481732194.issue35537@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +11593, 11594 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 06:17:02 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Feb 2019 11:17:02 +0000 Subject: [issue35876] test_start_new_session for posix_spawnp fails In-Reply-To: <1549018399.45.0.971138800303.issue35876@roundup.psfhosted.org> Message-ID: <1549019822.24.0.484079071242.issue35876@roundup.psfhosted.org> Change by STINNER Victor : ---------- keywords: +patch pull_requests: +11597 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 06:17:17 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Feb 2019 11:17:17 +0000 Subject: [issue35537] use os.posix_spawn in subprocess In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za> Message-ID: <1549019837.11.0.225775144649.issue35537@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +11593, 11594, 11595 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 06:17:30 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Feb 2019 11:17:30 +0000 Subject: [issue35876] test_start_new_session for posix_spawnp fails In-Reply-To: <1549018399.45.0.971138800303.issue35876@roundup.psfhosted.org> Message-ID: <1549019850.16.0.859804766964.issue35876@roundup.psfhosted.org> STINNER Victor added the comment: > Joannah Nanjekye wrote the new test and I'm mentoring her, so I would prefer that she fix the test. Oh wait, when I looked at the test, it's way more complex to implement that what I expected! So I decided to rewrite the test myself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 06:17:31 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Feb 2019 11:17:31 +0000 Subject: [issue35537] use os.posix_spawn in subprocess In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za> Message-ID: <1549019851.05.0.258228711259.issue35537@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +11593, 11594, 11595, 11596 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 06:20:03 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Feb 2019 11:20:03 +0000 Subject: [issue35875] Crash - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd In-Reply-To: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> Message-ID: <1549020003.95.0.80067683102.issue35875@roundup.psfhosted.org> STINNER Victor added the comment: You should try to get a traceback where the crash occurs using faulthandler: https://pythondev.readthedocs.io/debug_tools.html#faulthandler Other ways to get more info in case of a crash: https://pythondev.readthedocs.io/crash.html ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 06:22:42 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Feb 2019 11:22:42 +0000 Subject: [issue35878] ast.c: end_col_offset may be used uninitialized in this function Message-ID: <1549020161.52.0.11493245766.issue35878@roundup.psfhosted.org> New submission from STINNER Victor : https://buildbot.python.org/all/#builders/103/builds/2023 There are many "end_col_offset may be used uninitialized in this function" warnings. Example: In file included from Python/ast.c:7:0: Python/ast.c: In function ?ast_for_funcdef_impl?: ./Include/Python-ast.h:484:66: warning: ?end_col_offset? may be used uninitialized in this function [-Wmaybe-uninitialized] #define FunctionDef(a0, a1, a2, a3, a4, a5, a6, a7, a8, a9, a10) _Py_FunctionDef(a0, a1, a2, a3, a4, a5, a6, a7, a8, a9, a10) ^~~~~~~~~~~~~~~ Python/ast.c:1738:21: note: ?end_col_offset? was declared here int end_lineno, end_col_offset; ^~~~~~~~~~~~~~ ---------- components: Interpreter Core messages: 334670 nosy: emilyemorehouse, levkivskyi, vstinner priority: normal severity: normal status: open title: ast.c: end_col_offset may be used uninitialized in this function type: compile error versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 06:30:06 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Feb 2019 11:30:06 +0000 Subject: [issue35879] test_type_comments leaks references Message-ID: <1549020604.51.0.835471496217.issue35879@roundup.psfhosted.org> New submission from STINNER Victor : https://buildbot.python.org/all/#/builders/1/builds/490 https://buildbot.python.org/all/#/builders/80/builds/499 test_type_comments leaked [37, 37, 37] references, sum=111 test_type_comments leaked [11, 12, 11] memory blocks, sum=34 Example: vstinner at apu$ ./python -m test -R 3:3 test_type_comments -m test.test_type_comments.TypeCommentTests.test_asyncdef Run tests sequentially 0:00:00 load avg: 0.56 [1/1] test_type_comments beginning 6 repetitions 123456 ...... test_type_comments leaked [2, 2, 2] references, sum=6 test_type_comments leaked [2, 3, 2] memory blocks, sum=7 test_type_comments failed == Tests result: FAILURE == 1 test failed: test_type_comments Total duration: 129 ms Tests result: FAILURE I bet that the regression comes from: commit dcfcd146f8e6fc5c2fc16a4c192a0c5f5ca8c53c Author: Guido van Rossum Date: Thu Jan 31 03:40:27 2019 -0800 bpo-35766: Merge typed_ast back into CPython (GH-11645) See also bpo-35878. ---------- components: Library (Lib) messages: 334671 nosy: lukasz.langa, vstinner priority: normal severity: normal status: open title: test_type_comments leaks references versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 06:30:23 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Feb 2019 11:30:23 +0000 Subject: [issue35879] test_type_comments leaks references In-Reply-To: <1549020604.51.0.835471496217.issue35879@roundup.psfhosted.org> Message-ID: <1549020623.75.0.175200898356.issue35879@roundup.psfhosted.org> Change by STINNER Victor : ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 06:47:38 2019 From: report at bugs.python.org (Jurjen N.E. Bos) Date: Fri, 01 Feb 2019 11:47:38 +0000 Subject: [issue35880] math.sin has no backward error; this isn't documented Message-ID: <1549021657.57.0.382503652198.issue35880@roundup.psfhosted.org> New submission from Jurjen N.E. Bos : The documentation of math.sin (and related trig functions) doesn't speak about backward error. In cPython, as far as I can see, there is no backward error at all, which is quite uncommon. This may vary between implementations; many math libraries of other languages have a backward error, resulting in large errors for large arguments. e.g. sin(1<<500) is correctly computed as 0.42925739234242827, where a backward error as small as 1e-150 can give a completely wrong result. Some text could be added (which I am happy to produce) that explains what backward error means, and under which circumstances you can expect an accurate result. ---------- assignee: docs at python components: Documentation messages: 334672 nosy: docs at python, jneb priority: normal severity: normal status: open title: math.sin has no backward error; this isn't documented versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 07:41:07 2019 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 01 Feb 2019 12:41:07 +0000 Subject: [issue35880] math.sin has no backward error; this isn't documented In-Reply-To: <1549021657.57.0.382503652198.issue35880@roundup.psfhosted.org> Message-ID: <1549024867.87.0.654314965426.issue35880@roundup.psfhosted.org> Mark Dickinson added the comment: There's not a whole lot that we can usefully say about the accuracy of `math.sin`, since CPython just wraps C's sin function. So we just inherit the behaviour of the platform libm. I don't think I understand what you mean by "backward error" in this context. What do you mean by: "as far as I can see, there is no backward error at all"? It may indeed be the case that math.sin is correctly rounded, or at least close to correctly rounded (e.g., errors consistently within 0.503 ulp or some such) on some platforms, but that's entirely platform dependent. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 07:42:50 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Fri, 01 Feb 2019 12:42:50 +0000 Subject: [issue35861] test_named_expressions raises SyntaxWarning In-Reply-To: <1548875131.95.0.280347289465.issue35861@roundup.psfhosted.org> Message-ID: <1549024970.68.0.667646885885.issue35861@roundup.psfhosted.org> Change by Joannah Nanjekye : ---------- keywords: +patch pull_requests: +11598 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 07:42:58 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Fri, 01 Feb 2019 12:42:58 +0000 Subject: [issue35861] test_named_expressions raises SyntaxWarning In-Reply-To: <1548875131.95.0.280347289465.issue35861@roundup.psfhosted.org> Message-ID: <1549024978.22.0.852612088992.issue35861@roundup.psfhosted.org> Change by Joannah Nanjekye : ---------- keywords: +patch, patch pull_requests: +11598, 11599 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 07:43:06 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Fri, 01 Feb 2019 12:43:06 +0000 Subject: [issue35861] test_named_expressions raises SyntaxWarning In-Reply-To: <1548875131.95.0.280347289465.issue35861@roundup.psfhosted.org> Message-ID: <1549024986.14.0.874234142191.issue35861@roundup.psfhosted.org> Change by Joannah Nanjekye : ---------- keywords: +patch, patch, patch pull_requests: +11598, 11599, 11600 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 08:17:23 2019 From: report at bugs.python.org (Eryk Sun) Date: Fri, 01 Feb 2019 13:17:23 +0000 Subject: [issue35872] Creating venv from venv no longer works in 3.7.2 In-Reply-To: <1549010953.4.0.913686801166.issue35872@roundup.psfhosted.org> Message-ID: <1549027043.96.0.928833655768.issue35872@roundup.psfhosted.org> Eryk Sun added the comment: The __PYVENV_LAUNCHER__ variable gets set by each launcher instance. We get one launcher process for every level of nesting, and the last launcher to run sets the final value that will be seen by the real python.exe. Possibly the launcher could resolve the home values until it reaches a solid python.exe (i.e. no pyvenv.cfg file), and thus avoid the nested chain of launcher processes and ensure that the real python.exe sees the correct value of __PYVENV_LAUNCHER__. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 08:22:32 2019 From: report at bugs.python.org (Jon Ribbens) Date: Fri, 01 Feb 2019 13:22:32 +0000 Subject: [issue35863] email.headers wraps headers badly In-Reply-To: <1548883437.25.0.0584466696793.issue35863@roundup.psfhosted.org> Message-ID: <1549027352.39.0.0269598158488.issue35863@roundup.psfhosted.org> Jon Ribbens added the comment: I did read the RFCs. I suspect the [CFWS] in the msg-id is for the benefit of the references production which contains a list of msg-ids. The 78-character suggested line length limit is explicitly noted as being for display purposes, and therefore is of little application to headers which are not displayed in user interfaces. Also consider that the Python wrapping code produces "\n ..." when given a header that is 80 indivisible characters long, when there is no possibility of avoiding a line over 78 characters. Outlook seems to cope alright with other headers (I tried From and Subject) being wrapped like this; I shudder to think what their code must be like in order to produce this bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 09:02:47 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Fri, 01 Feb 2019 14:02:47 +0000 Subject: [issue35881] test_type_comments leaks references and memory blocks Message-ID: <1549029765.83.0.257385728664.issue35881@roundup.psfhosted.org> New submission from Pablo Galindo Salgado : The refleak buildbots have detected that test_type_comments is leaking references. Example failure: https://buildbot.python.org/all/#/builders/1/builds/490/steps/4/logs/stdio test_type_comments leaked [37, 37, 37] references, sum=111 test_type_comments leaked [11, 12, 11] memory blocks, sum=34 1 test failed again: test_type_comments Bisecting shows that PR11645 is the one that introduced the refleaks: https://github.com/python/cpython/pull/11645/files# After some hours of debugging, I have identified the (possible) cause of the majority of the refleaks. The type_comments created in ast.c with new_type_comment() never reaches 0 reference counts. This **seems** to be because the cleanup for the stmt_ty elements where the type_comments are included never call DECREF on these elements when destroyed unless I am missing something fundamental. ---------- components: Interpreter Core, Tests messages: 334676 nosy: gvanrossum, lukasz.langa, pablogsal priority: normal severity: normal status: open title: test_type_comments leaks references and memory blocks versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 09:02:52 2019 From: report at bugs.python.org (Bangert) Date: Fri, 01 Feb 2019 14:02:52 +0000 Subject: [issue35875] Crash - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd In-Reply-To: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> Message-ID: <1549029772.09.0.141407222918.issue35875@roundup.psfhosted.org> Bangert added the comment: 1. This behaviour has no effect to/on my project. All works fine. 2. I removed only #algos.cp36-win_amd64.pyd C:\Users\SabrinaBangert\AppData\Local\conda\conda\envs\conda\Lib\site-packages\pandas\_libs #algos.cp36-win_amd64.pyd C:\Users\SabrinaBangert\AppData\Local\conda\conda\pkgs\pandas-0.24.0-py36ha925a31_0\Lib\site-packages\pandas\_libs 3. After that the error is gone though joint is still loading #join.cp36-win_amd64.pyd C:\Users\SabrinaBangert\AppData\Local\conda\conda\envs\conda\Lib\site-packages\pandas\_libs #join.cp36-win_amd64.pyd C:\Users\SabrinaBangert\AppData\Local\conda\conda\pkgs\pandas-0.24.0-py36ha925a31_0\Lib\site-packages\pandas\_libs 4. I restored algos again 5. I made an empty project using conda 3.6 environment with only one directive import pandas as pd 6. the two crashes algos and joint are reproduced 7. so it depends on pandas in conjucttion with my conda 3.6 environment which is very large 8. post the packages in the next comment ---------- Added file: https://bugs.python.org/file48093/Conda-Algos-Joint-Crash-02.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 09:07:14 2019 From: report at bugs.python.org (Bangert) Date: Fri, 01 Feb 2019 14:07:14 +0000 Subject: [issue35875] Crash - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd In-Reply-To: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> Message-ID: <1549030034.94.0.134374890506.issue35875@roundup.psfhosted.org> Bangert added the comment: here is requirements.txt as a screenshot and the second half of the packages in conda 3.6 ---------- Added file: https://bugs.python.org/file48094/Conda-Algos-Joint-Crash-03.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 09:07:19 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Fri, 01 Feb 2019 14:07:19 +0000 Subject: [issue35881] test_type_comments leaks references and memory blocks In-Reply-To: <1549029765.83.0.257385728664.issue35881@roundup.psfhosted.org> Message-ID: <1549030039.64.0.196859321525.issue35881@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: This looks like the same as https://bugs.python.org/issue35879 ---------- nosy: +vstinner, xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 09:08:33 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Feb 2019 14:08:33 +0000 Subject: [issue35881] test_type_comments leaks references and memory blocks In-Reply-To: <1549029765.83.0.257385728664.issue35881@roundup.psfhosted.org> Message-ID: <1549030113.8.0.299126975616.issue35881@roundup.psfhosted.org> STINNER Victor added the comment: > This looks like the same as https://bugs.python.org/issue35879 Yeah, as usual Pablo is way too slow: he posted the same bug 1h30 after me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 09:09:03 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Feb 2019 14:09:03 +0000 Subject: [issue35881] test_type_comments leaks references and memory blocks In-Reply-To: <1549029765.83.0.257385728664.issue35881@roundup.psfhosted.org> Message-ID: <1549030143.83.0.978002526546.issue35881@roundup.psfhosted.org> Change by STINNER Victor : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> test_type_comments leaks references _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 09:10:04 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Fri, 01 Feb 2019 14:10:04 +0000 Subject: [issue35879] test_type_comments leaks references In-Reply-To: <1549020604.51.0.835471496217.issue35879@roundup.psfhosted.org> Message-ID: <1549030204.37.0.451950189836.issue35879@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +pablogsal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 09:11:08 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Fri, 01 Feb 2019 14:11:08 +0000 Subject: [issue35881] test_type_comments leaks references and memory blocks In-Reply-To: <1549029765.83.0.257385728664.issue35881@roundup.psfhosted.org> Message-ID: <1549030268.16.0.102411072695.issue35881@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: > Yeah, as usual, Pablo is way too slow: he posted the same bug 1h30 after me. :( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 09:12:24 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Fri, 01 Feb 2019 14:12:24 +0000 Subject: [issue35879] test_type_comments leaks references In-Reply-To: <1549020604.51.0.835471496217.issue35879@roundup.psfhosted.org> Message-ID: <1549030344.79.0.832169722363.issue35879@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: >From the duplicate (https://bugs.python.org/issue35881) : After some hours of debugging, I have identified the (possible) cause of the majority of the refleaks. The type_comments created in ast.c with new_type_comment() never reaches 0 reference counts. This **seems** to be because the cleanup for the stmt_ty elements where the type_comments are included never call DECREF on these elements when destroyed unless I am missing something fundamental. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 09:39:04 2019 From: report at bugs.python.org (kellerfuchs) Date: Fri, 01 Feb 2019 14:39:04 +0000 Subject: [issue35431] Add a function for computing binomial coefficients to the math module In-Reply-To: <1544131082.09.0.788709270274.issue35431@psf.upfronthosting.co.za> Message-ID: <1549031944.25.0.0155629687127.issue35431@roundup.psfhosted.org> kellerfuchs added the comment: @Steven > > This involved a few changes, which seem to reflect the consensus here: > > - raise ValueError if k>n ; > > - rename the function to math.combinations. > [...] > > As far as I can tell from the discussions here, Steven and you stated a preference for the shortened names, and that's it. > > There was also no reply to my comment about `comb` being confusing (due to the collision with an English word). > > > > Since there was, however, pretty clear agreement on calling it after combinations (shortened or not) rather than binomial(), I went with this. > > I see at least four people (myself, Raymond, Mark and Tim) giving comb as first choice, and I didn't see anyone give combinations as their first choice. > > I don't object to you taking it upon yourself to go with the longer name > (which is my second choice), but I do object to you claiming concensus I wasn't claiming consensus on the short-vs.-long name issue, but on the binomial-vs-combinations one. I thought that would have been clear considering the context quoted above (which was missing from your reply) Given that people clarified they prefer comb(), and that people conspicuously didn't comment on it being entirely-opaque to people who do not elready know what it is, I guess there is indeed consensus. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 09:44:13 2019 From: report at bugs.python.org (kellerfuchs) Date: Fri, 01 Feb 2019 14:44:13 +0000 Subject: [issue35431] Add a function for computing binomial coefficients to the math module In-Reply-To: <1544131082.09.0.788709270274.issue35431@psf.upfronthosting.co.za> Message-ID: <1549032253.2.0.299347520881.issue35431@roundup.psfhosted.org> kellerfuchs added the comment: > Given that people clarified they prefer comb(), and that people conspicuously didn't comment on it being entirely-opaque to people who do not elready know what it is, I guess there is indeed consensus. commit afb3d36e82b8d690a410fa9dca8029a8fad42984 Author: The Fox in the Shell Date: Fri Feb 1 15:42:11 2019 +0100 Rename math.combinations to math.comb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 09:47:29 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Feb 2019 14:47:29 +0000 Subject: [issue35537] use os.posix_spawn in subprocess In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za> Message-ID: <1549032449.01.0.571999649005.issue35537@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 325e4bac5ab49f47ec60242d3242647605193a2e by Victor Stinner in branch 'master': bpo-35537: Fix function name in os.posix_spawnp() errors (GH-11719) https://github.com/python/cpython/commit/325e4bac5ab49f47ec60242d3242647605193a2e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 10:14:41 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Feb 2019 15:14:41 +0000 Subject: [issue35881] test_type_comments leaks references and memory blocks In-Reply-To: <1549029765.83.0.257385728664.issue35881@roundup.psfhosted.org> Message-ID: <1549034081.47.0.732516415168.issue35881@roundup.psfhosted.org> STINNER Victor added the comment: > :( I'm kidding :-) Sorry for not reviewing emails from buildbot-status. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 10:24:53 2019 From: report at bugs.python.org (Jody McIntyre) Date: Fri, 01 Feb 2019 15:24:53 +0000 Subject: [issue35882] distutils fails with UnicodeEncodeError with strange filename in package_data Message-ID: <1549034691.01.0.592197242815.issue35882@roundup.psfhosted.org> New submission from Jody McIntyre : I encountered an error while installing savReaderWriter using pip from a Dockerfile, reported as https://bitbucket.org/fomcl/savreaderwriter/issues/73/pip-install-fails-for-non-utf-8-encoding This is actually an issue with distutils. Steps to reproduce: 1. Create the following tree. setup.py is as attached. The .sav file is empty. ./setup.py ./savReaderWriter ./savReaderWriter/test_data ./savReaderWriter/test_data/schei? Encoding.sav 2. Run LANG=C python setup.py install --record=/tmp/install-record.txt --single-version-externally-managed Actual output: running install running build running build_py package init file 'savReaderWriter/__init__.py' not found (or not a regular file) creating build creating build/lib creating build/lib/savReaderWriter creating build/lib/savReaderWriter/test_data copying savReaderWriter/test_data/schei? Encoding.sav -> build/lib/savReaderWriter/test_data running install_lib running install_egg_info running egg_info creating savReaderWriter.egg-info writing savReaderWriter.egg-info/PKG-INFO writing dependency_links to savReaderWriter.egg-info/dependency_links.txt writing top-level names to savReaderWriter.egg-info/top_level.txt writing manifest file 'savReaderWriter.egg-info/SOURCES.txt' 'savReaderWriter/test_data/schei\udcc3\udc9f Encoding.sav' not utf-8 encodable -- skipping reading manifest file 'savReaderWriter.egg-info/SOURCES.txt' writing manifest file 'savReaderWriter.egg-info/SOURCES.txt' removing '/home/scjody/.pyenv/versions/3.6.5/lib/python3.6/site-packages/savReaderWriter-1.2.3-py3.6.egg-info' (and everything under it) Copying savReaderWriter.egg-info to /home/scjody/.pyenv/versions/3.6.5/lib/python3.6/site-packages/savReaderWriter-1.2.3-py3.6.egg-info running install_scripts writing list of installed files to '/tmp/install-record.txt' Traceback (most recent call last): File "setup.py", line 9, in version='1.2.3', File "/home/scjody/.pyenv/versions/3.6.5/lib/python3.6/site-packages/setuptools/__init__.py", line 129, in setup return distutils.core.setup(**attrs) File "/home/scjody/.pyenv/versions/3.6.5/lib/python3.6/distutils/core.py", line 148, in setup dist.run_commands() File "/home/scjody/.pyenv/versions/3.6.5/lib/python3.6/distutils/dist.py", line 955, in run_commands self.run_command(cmd) File "/home/scjody/.pyenv/versions/3.6.5/lib/python3.6/distutils/dist.py", line 974, in run_command cmd_obj.run() File "/home/scjody/.pyenv/versions/3.6.5/lib/python3.6/site-packages/setuptools/command/install.py", line 61, in run return orig.install.run(self) File "/home/scjody/.pyenv/versions/3.6.5/lib/python3.6/distutils/command/install.py", line 572, in run self.record) File "/home/scjody/.pyenv/versions/3.6.5/lib/python3.6/distutils/cmd.py", line 335, in execute util.execute(func, args, msg, dry_run=self.dry_run) File "/home/scjody/.pyenv/versions/3.6.5/lib/python3.6/distutils/util.py", line 301, in execute func(*args) File "/home/scjody/.pyenv/versions/3.6.5/lib/python3.6/distutils/file_util.py", line 236, in write_file f.write(line + "\n") UnicodeEncodeError: 'ascii' codec can't encode characters in position 94-95: ordinal not in range(128) Expected results: The package is installed and install-record.txt is created. Related: https://bugs.python.org/issue9561 ---------- components: Distutils files: setup.py messages: 334687 nosy: dstufft, eric.araujo, scjody priority: normal severity: normal status: open title: distutils fails with UnicodeEncodeError with strange filename in package_data type: crash versions: Python 3.6 Added file: https://bugs.python.org/file48095/setup.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 10:28:25 2019 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 01 Feb 2019 15:28:25 +0000 Subject: [issue35877] parenthesis is mandatory for named expressions in while statement In-Reply-To: <1549018555.29.0.231525655805.issue35877@roundup.psfhosted.org> Message-ID: <1549034905.48.0.693562300493.issue35877@roundup.psfhosted.org> Guido van Rossum added the comment: Emily, I think this would be as simple as making a tiny change to Grammar/Grammar and running make regen-grammar. Can you take care of that? ---------- assignee: -> emilyemorehouse stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 10:34:17 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Fri, 01 Feb 2019 15:34:17 +0000 Subject: [issue30670] pprint for dict in sorted order or insert order? In-Reply-To: <1497492955.33.0.313949068523.issue30670@psf.upfronthosting.co.za> Message-ID: <1549035257.31.0.516071272133.issue30670@roundup.psfhosted.org> R?mi Lapeyre added the comment: Hi josephsmeng, dict order preservation is now used in a lot of place in Python. I will post a patch to make pprint use insertion order in a few hours. ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 10:40:20 2019 From: report at bugs.python.org (Tobias Pleyer) Date: Fri, 01 Feb 2019 15:40:20 +0000 Subject: [issue35853] Extend the functools module with more higher order function combinators In-Reply-To: <1548799718.5.0.603490291.issue35853@roundup.psfhosted.org> Message-ID: <1549035620.18.0.352776126293.issue35853@roundup.psfhosted.org> Tobias Pleyer added the comment: Thank you for your quick and detailed answer. It appears I slightly misunderstood the purpose of the functools module. However kudos for your great effort to push the Python language forward. Best regards Tobias ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 10:47:50 2019 From: report at bugs.python.org (R. David Murray) Date: Fri, 01 Feb 2019 15:47:50 +0000 Subject: [issue35863] email.headers wraps headers badly In-Reply-To: <1548883437.25.0.0584466696793.issue35863@roundup.psfhosted.org> Message-ID: <1549036070.49.0.0686498418659.issue35863@roundup.psfhosted.org> R. David Murray added the comment: Well, "display" in the context of email includes looking at the raw email serialized as a text file. This is something one can do in most mailers. I use nmh as my mailer, which only shows raw headers, so I myself would be personally affected if headers were not normally wrapped at 78 characters when possible :) The >80 characters issue you mention is fixed by the folder used by the new API. That folder will use encoded words to wrap overlong tokens in text portions of headers, which may or may not have been the best decision (jury is still out on that one), and for non-text headers it does not put in that /n if the word won't fit on the next line if wrapped. (Or at least its not supposed to, so if you find a case where it does, please submit a bug report.) email.Header is a legacy module and no longer maintained. And yes, I realize it is used by default. There should be an open issue about going through a deprecation cycle to make the new API the default, but I've lost track and have no time to push for it myself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 10:49:32 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Fri, 01 Feb 2019 15:49:32 +0000 Subject: [issue35877] parenthesis is mandatory for named expressions in while statement In-Reply-To: <1549018555.29.0.231525655805.issue35877@roundup.psfhosted.org> Message-ID: <1549036172.73.0.150719344025.issue35877@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: > Emily, I think this would be as simple as making a tiny change to Grammar/Grammar and running make regen-grammar. Can you take care of that? Thanks, can confirm that this fixes the issue. I changed test to namedexpr_test for while statement in grammar and ran `make regen-grammar` and `make`. The reported program runs fine and Lib/test/test_named_expressions.py also passes. ? cpython git:(master) ? cat /tmp/foo.py import re with open("/tmp/foo.py") as f: while line := f.readline(): if match := re.search(r"foo", line): print(match.string.strip("\n")) ? cpython git:(master) ? ./python.exe /tmp/foo.py with open("/tmp/foo.py") as f: if match := re.search(r"foo", line): Patch : ? cpython git:(master) ? git diff | cat diff --git a/Grammar/Grammar b/Grammar/Grammar index e65a688e4c..a425978059 100644 --- a/Grammar/Grammar +++ b/Grammar/Grammar @@ -72,7 +72,7 @@ assert_stmt: 'assert' test [',' test] compound_stmt: if_stmt | while_stmt | for_stmt | try_stmt | with_stmt | funcdef | classdef | decorated | async_stmt async_stmt: 'async' (funcdef | with_stmt | for_stmt) if_stmt: 'if' namedexpr_test ':' suite ('elif' namedexpr_test ':' suite)* ['else' ':' suite] -while_stmt: 'while' test ':' suite ['else' ':' suite] +while_stmt: 'while' namedexpr_test ':' suite ['else' ':' suite] for_stmt: 'for' exprlist 'in' testlist ':' [TYPE_COMMENT] suite ['else' ':' suite] try_stmt: ('try' ':' suite ((except_clause ':' suite)+ diff --git a/Python/graminit.c b/Python/graminit.c index 6e0f19891b..5cdde2789c 100644 --- a/Python/graminit.c +++ b/Python/graminit.c @@ -971,7 +971,7 @@ static arc arcs_42_0[1] = { {103, 1}, }; static arc arcs_42_1[1] = { - {26, 2}, + {99, 2}, }; static arc arcs_42_2[1] = { {27, 3}, ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 11:02:26 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Fri, 01 Feb 2019 16:02:26 +0000 Subject: [issue30670] pprint for dict in sorted order or insert order? In-Reply-To: <1497492955.33.0.313949068523.issue30670@psf.upfronthosting.co.za> Message-ID: <1549036946.67.0.908601000443.issue30670@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: https://docs.python.org/3/library/pprint.html > Dictionaries are sorted by key before the display is computed. https://mail.python.org/pipermail/python-dev/2017-December/151369.html . There was some discussion in the thread about this being a breaking change and the behavior of pprint. @remi.lapeyre I would suggest waiting for a core dev on approving this change before proceeding with a patch to avoid work being wasted. ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 11:09:09 2019 From: report at bugs.python.org (Eric Snow) Date: Fri, 01 Feb 2019 16:09:09 +0000 Subject: [issue35864] Replace OrderedDict with regular dict in namedtuple's _asdict() method. In-Reply-To: <1548901211.98.0.0872539907535.issue35864@roundup.psfhosted.org> Message-ID: <1549037349.05.0.536013396841.issue35864@roundup.psfhosted.org> Eric Snow added the comment: Thanks for doing this, Raymond! FYI, I found a couple of places where it still refers to OrderedDict: 1. in the doc entry in collections.rst [1] 2. in the docstring [2] [1] https://github.com/python/cpython/commit/0bb4bdf0d93b301407774c4ffd6df54cff947df8#diff-a2f0632ea84b755c7ef5b9bd291c7fdfR890 [2] https://github.com/python/cpython/commit/0bb4bdf0d93b301407774c4ffd6df54cff947df8#diff-8a750c700ae5ac1d0a14922de83e99ccR432 ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 11:24:42 2019 From: report at bugs.python.org (Eric Snow) Date: Fri, 01 Feb 2019 16:24:42 +0000 Subject: [issue35864] Replace OrderedDict with regular dict in namedtuple's _asdict() method. In-Reply-To: <1548901211.98.0.0872539907535.issue35864@roundup.psfhosted.org> Message-ID: <1549038282.52.0.139401064667.issue35864@roundup.psfhosted.org> Eric Snow added the comment: Also, there's a potentially misleading detail that you might consider correcting in the text. However, making it correct might make it slightly less clear, so it's a bit of a judgement call on how important it is to be explicit here. (FWIW, I think it's worth it to some extent.) The language reference doesn't guarantee that dictionaries are order-preserving (yet). [1] Therefore there can be (are?) Python implementations where dict isn't ordered. Users of those implementations may be confused by the docs (and docstring) saying the method returns a dict. This could be addressed by changing those places to say something like it returns an insertion-ordered mapping. The docs entry would also have an "CPython implementation detail" part saying it's actually a dict in CPython. Since "insertion-ordered mapping" isn't nearly as clear as "dict" (even if more correct), it may make more sense to simply say "dict". However, in that case I'd recommend at the very least to add a "CPython implementation detail" part to the docs entry which says in CPython it returns a dict, but in other implementations it may be some other order-preserving mapping. Honestly, after having written that the latter option seems more sensible. :) [1] https://docs.python.org/3.8/reference/datamodel.html#index-29 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 11:25:24 2019 From: report at bugs.python.org (Eric Snow) Date: Fri, 01 Feb 2019 16:25:24 +0000 Subject: [issue35864] Replace OrderedDict with regular dict in namedtuple's _asdict() method. In-Reply-To: <1548901211.98.0.0872539907535.issue35864@roundup.psfhosted.org> Message-ID: <1549038324.45.0.293981246705.issue35864@roundup.psfhosted.org> Eric Snow added the comment: If you prefer, I'd be glad to open separate issues for either thing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 11:28:26 2019 From: report at bugs.python.org (Eric Snow) Date: Fri, 01 Feb 2019 16:28:26 +0000 Subject: [issue35864] Replace OrderedDict with regular dict in namedtuple's _asdict() method. In-Reply-To: <1548901211.98.0.0872539907535.issue35864@roundup.psfhosted.org> Message-ID: <1549038506.01.0.609708044327.issue35864@roundup.psfhosted.org> Eric Snow added the comment: FWIW, both PEP 468 (kwargs order) and PEP 520 (class definition order) specify order-preserving mapping rather than dict. The main difference is that they are about language features rather than something out of the stdlib. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 11:29:15 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Fri, 01 Feb 2019 16:29:15 +0000 Subject: [issue25592] distutils docs: data_files always uses sys.prefix In-Reply-To: <1447135572.7.0.138478279434.issue25592@psf.upfronthosting.co.za> Message-ID: <1549038555.42.0.4480452097.issue25592@roundup.psfhosted.org> Jeroen Demeyer added the comment: > Could you still give it a quick check? I did just that. For reference, these are the steps: - Checkout the "2.7" branch of the cpython git repo - ./configure --prefix=/tmp/prefix --exec-prefix=/tmp/eprefix && make && make install - Install pip (https://pip.pypa.io/en/stable/installing/#installing-with-get-pip-py) - /tmp/prefix/pip install --no-deps --verbose pari_jupyter # This requires the PARI/GP library to be installed - Note that all Jupyter stuff is installed in /tmp/prefix/share/jupyter while the directory /tmp/eprefix/share does not exist ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 11:29:47 2019 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 01 Feb 2019 16:29:47 +0000 Subject: [issue35877] parenthesis is mandatory for named expressions in while statement In-Reply-To: <1549036172.73.0.150719344025.issue35877@roundup.psfhosted.org> Message-ID: Guido van Rossum added the comment: Thanks, Karthikeyan! Can you submit that as a PR? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 11:30:45 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Fri, 01 Feb 2019 16:30:45 +0000 Subject: [issue25592] distutils docs: data_files always uses sys.prefix In-Reply-To: <1447135572.7.0.138478279434.issue25592@psf.upfronthosting.co.za> Message-ID: <1549038645.28.0.506223239879.issue25592@roundup.psfhosted.org> Jeroen Demeyer added the comment: (note typo in the above: /tmp/prefix/pip should be /tmp/prefix/bin/pip) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 11:34:48 2019 From: report at bugs.python.org (Kent Scheidegger) Date: Fri, 01 Feb 2019 16:34:48 +0000 Subject: [issue34028] Python 3.7.0 wont compile with SSL Support 1.1.0 > alledged missing X509_VERIFY_PARAM_set1_host() support In-Reply-To: <1530609211.5.0.56676864532.issue34028@psf.upfronthosting.co.za> Message-ID: <1549038888.34.0.284261069357.issue34028@roundup.psfhosted.org> Kent Scheidegger added the comment: I was unable to get it working even with all the suggestions in this thread. I have a shared account on a system with only Python 2.7 and an old version of openssl. I have write access only to my user directory. I installed a new openssl in a local directory and pointed to it with both --with-openssl and LDFLAGS, as suggested. The configure step seems to work, but on make the libssl.so.1.1 still isn't found. I fell back to Python 3.6. Same result. I fell back to 3.4. It finally worked. ---------- nosy: +kscheidegger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 11:42:32 2019 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 01 Feb 2019 16:42:32 +0000 Subject: [issue35879] test_type_comments leaks references In-Reply-To: <1549020604.51.0.835471496217.issue35879@roundup.psfhosted.org> Message-ID: <1549039352.62.0.172943319581.issue35879@roundup.psfhosted.org> Guido van Rossum added the comment: I can confirm it, but I don't understand it yet. Somehow the type_comment fields get an extra reference count and are never freed. How are other string fields handled? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 11:43:16 2019 From: report at bugs.python.org (INADA Naoki) Date: Fri, 01 Feb 2019 16:43:16 +0000 Subject: [issue12822] NewGIL should use CLOCK_MONOTONIC if possible. In-Reply-To: <1314085416.99.0.752578807259.issue12822@psf.upfronthosting.co.za> Message-ID: <1549039396.1.0.0488494459816.issue12822@roundup.psfhosted.org> Change by INADA Naoki : ---------- pull_requests: +11601 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 11:43:27 2019 From: report at bugs.python.org (INADA Naoki) Date: Fri, 01 Feb 2019 16:43:27 +0000 Subject: [issue12822] NewGIL should use CLOCK_MONOTONIC if possible. In-Reply-To: <1314085416.99.0.752578807259.issue12822@psf.upfronthosting.co.za> Message-ID: <1549039407.04.0.101383580934.issue12822@roundup.psfhosted.org> Change by INADA Naoki : ---------- pull_requests: +11601, 11602 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 11:43:46 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Feb 2019 16:43:46 +0000 Subject: [issue35879] test_type_comments leaks references In-Reply-To: <1549020604.51.0.835471496217.issue35879@roundup.psfhosted.org> Message-ID: <1549039426.49.0.509613887521.issue35879@roundup.psfhosted.org> Change by STINNER Victor : ---------- nosy: -vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 11:55:39 2019 From: report at bugs.python.org (Neui) Date: Fri, 01 Feb 2019 16:55:39 +0000 Subject: [issue35883] Change invalid unicode characters to replacement characters in argv Message-ID: <1549040138.25.0.646545491344.issue35883@roundup.psfhosted.org> New submission from Neui : When an invalid unicode character is given to argv (cli arguments), then python abort()s with an fatal error about an character not in range (ValueError: character U+7fffbeba is not in range [U+0000; U+10ffff]). I am wondering if this behaviour should change to replace those with U+FFFD REPLACEMENT CHARACTER (like .decode(..., 'replace')) or even with something similar/better (see https://docs.python.org/3/library/codecs.html#error-handlers ) The reason for this is that other applications can use the invalid character since it is just some data (like GDB for use as an argument to the program to be debugged), where in python this becomes an limitation, since the script (if specified) never runs. The main motivation for me is that there is an command-not-found debian package that gets the wrongly-typed command as a command argument. If that then contains an invalid unicode character, it then just fails rather saying it couldn't find the/a similar command. If this doesn't get changed, it either then has to accept that this is a limitation, use an other way of passing the command or re-write it in not python. # Requires bash 4.2+ # Specifying a script omits the first two lines $ python3.6 $'\U7fffbeba' Failed checking if argv[0] is an import path entry ValueError: character U+7fffbeba is not in range [U+0000; U+10ffff] Fatal Python error: no mem for sys.argv ValueError: character U+7fffbeba is not in range [U+0000; U+10ffff] Current thread 0x00007fd212eaf740 (most recent call first): Aborted (core dumped) $ python3.6 --version Python 3.6.7 $ uname -a Linux nopea 4.15.0-39-generic #42-Ubuntu SMP Tue Oct 23 15:48:01 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 18.04.1 LTS Release: 18.04 Codename: bionic GDB backtrace just before throwing the error: (note that it's argc=2 since first argument is a script) #0 find_maxchar_surrogates (begin=begin at entry=0xa847a0 L'\x7fffbeba' , end=end at entry=0xa847d0 L"", maxchar=maxchar at entry=0x7fffffffde94, num_surrogates=num_surrogates at entry=0x7fffffffde98) at ../Objects/unicodeobject.c:1626 #1 0x00000000004cee4b in PyUnicode_FromUnicode (u=u at entry=0xa847a0 L'\x7fffbeba' , size=12) at ../Objects/unicodeobject.c:2017 #2 0x00000000004db856 in PyUnicode_FromWideChar (w=0xa847a0 L'\x7fffbeba' , size=, size at entry=-1) at ../Objects/unicodeobject.c:2502 #3 0x000000000043253d in makeargvobject (argc=argc at entry=2, argv=argv at entry=0xa82268) at ../Python/sysmodule.c:2145 #4 0x0000000000433228 in PySys_SetArgvEx (argc=2, argv=0xa82268, updatepath=1) at ../Python/sysmodule.c:2264 #5 0x00000000004332c1 in PySys_SetArgv (argc=, argv=) at ../Python/sysmodule.c:2277 #6 0x000000000043a5bd in Py_Main (argc=argc at entry=3, argv=argv at entry=0xa82260) at ../Modules/main.c:733 #7 0x0000000000421149 in main (argc=3, argv=0x7fffffffe178) at ../Programs/python.c:69 Similar issues: https://bugs.python.org/issue25631 "Segmentation fault with invalid Unicode command-line arguments in embedded Python" (actually 'fixed' since it now abort()s) https://bugs.python.org/issue2128 "sys.argv is wrong for unicode strings" ---------- components: Interpreter Core messages: 334703 nosy: Neui priority: normal severity: normal status: open title: Change invalid unicode characters to replacement characters in argv type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 11:56:25 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Fri, 01 Feb 2019 16:56:25 +0000 Subject: [issue35877] parenthesis is mandatory for named expressions in while statement In-Reply-To: <1549018555.29.0.231525655805.issue35877@roundup.psfhosted.org> Message-ID: <1549040185.2.0.940764743229.issue35877@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: > Thanks, Karthikeyan! Can you submit that as a PR? Sure, I will submit the patch with tests for the same. Thanks ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 12:10:26 2019 From: report at bugs.python.org (SilentGhost) Date: Fri, 01 Feb 2019 17:10:26 +0000 Subject: [issue35883] Change invalid unicode characters to replacement characters in argv In-Reply-To: <1549040138.25.0.646545491344.issue35883@roundup.psfhosted.org> Message-ID: <1549041026.31.0.268559786876.issue35883@roundup.psfhosted.org> SilentGhost added the comment: I'm on 4.15.0-44-generic and I cannot reproduce the crash. I get "python3: can't open file '??????': [Errno 2] No such file or directory" Could you try this on a different machine / installation? ---------- nosy: +SilentGhost type: behavior -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 12:20:17 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Fri, 01 Feb 2019 17:20:17 +0000 Subject: [issue35880] math.sin has no backward error; this isn't documented In-Reply-To: <1549021657.57.0.382503652198.issue35880@roundup.psfhosted.org> Message-ID: <1549041617.21.0.32978280942.issue35880@roundup.psfhosted.org> Steven D'Aprano added the comment: > sin(1<<500) is correctly computed as 0.42925739234242827 py> math.sin(1<<500) 0.9996230490249484 Wolfram Alpha says it is 0.429257392342428277735329299112473759079115476327819897... https://www.wolframalpha.com/input/?i=sin%282^500%29&assumption=%22TrigRD%22+-%3E+%22R%22 > Some text could be added (which I am happy to produce) that explains what backward error means You could start by telling us here what you mean by backward error. Are you talking about this? https://en.wikipedia.org/wiki/Numerical_stability#Stability_in_numerical_linear_algebra ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 12:20:19 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Fri, 01 Feb 2019 17:20:19 +0000 Subject: [issue35877] parenthesis is mandatory for named expressions in while statement In-Reply-To: <1549018555.29.0.231525655805.issue35877@roundup.psfhosted.org> Message-ID: <1549041619.75.0.958123156105.issue35877@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- keywords: +patch pull_requests: +11603 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 12:20:26 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Fri, 01 Feb 2019 17:20:26 +0000 Subject: [issue35877] parenthesis is mandatory for named expressions in while statement In-Reply-To: <1549018555.29.0.231525655805.issue35877@roundup.psfhosted.org> Message-ID: <1549041626.45.0.14445162297.issue35877@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- keywords: +patch, patch pull_requests: +11603, 11604 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 12:20:34 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Fri, 01 Feb 2019 17:20:34 +0000 Subject: [issue35877] parenthesis is mandatory for named expressions in while statement In-Reply-To: <1549018555.29.0.231525655805.issue35877@roundup.psfhosted.org> Message-ID: <1549041634.41.0.36758397653.issue35877@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- keywords: +patch, patch, patch pull_requests: +11603, 11604, 11605 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 12:22:34 2019 From: report at bugs.python.org (SilentGhost) Date: Fri, 01 Feb 2019 17:22:34 +0000 Subject: [issue35883] Change invalid unicode characters to replacement characters in argv In-Reply-To: <1549040138.25.0.646545491344.issue35883@roundup.psfhosted.org> Message-ID: <1549041754.33.0.803926534257.issue35883@roundup.psfhosted.org> SilentGhost added the comment: Hm, this seems to be due to how the terminal emulator handles those special characters, actually. I can reproduce in another terminal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 12:22:50 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Fri, 01 Feb 2019 17:22:50 +0000 Subject: [issue35879] test_type_comments leaks references In-Reply-To: <1549020604.51.0.835471496217.issue35879@roundup.psfhosted.org> Message-ID: <1549041770.94.0.819559735173.issue35879@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: The extra referenced happen here in Python-ast.c : value = ast2obj_string(o->type_comment); if (!value) goto failed; if (_PyObject_SetAttrId(result, &PyId_type_comment, value) == -1) goto failed; Py_DECREF(value); ast2obj_string increments it once and the setattr does it again and then there is only one Py_DECREF. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 12:35:35 2019 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 01 Feb 2019 17:35:35 +0000 Subject: [issue35879] test_type_comments leaks references In-Reply-To: <1549041770.94.0.819559735173.issue35879@roundup.psfhosted.org> Message-ID: Guido van Rossum added the comment: OK, let me make a PR, I found another leak for type:ignore. On Fri, Feb 1, 2019 at 9:22 AM Pablo Galindo Salgado wrote: > > Pablo Galindo Salgado added the comment: > > The extra referenced happen here in Python-ast.c : > > value = ast2obj_string(o->type_comment); > if (!value) goto failed; > if (_PyObject_SetAttrId(result, &PyId_type_comment, value) == -1) > goto failed; > Py_DECREF(value); > > ast2obj_string increments it once and the setattr does it again and then > there is only one Py_DECREF. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 12:35:42 2019 From: report at bugs.python.org (Tim Peters) Date: Fri, 01 Feb 2019 17:35:42 +0000 Subject: [issue35880] math.sin has no backward error; this isn't documented In-Reply-To: <1549021657.57.0.382503652198.issue35880@roundup.psfhosted.org> Message-ID: <1549042542.94.0.331089618823.issue35880@roundup.psfhosted.org> Tim Peters added the comment: As Mark said, the behavior of Python's floating-point math functions (not just trig, but also log, pow, exp, ...) is inherited almost entirely from the platform C's math libraries. Python itself guarantees nothing about what `math.sin(x)` returns for any `x` - and it can, & does, vary across platforms. ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 13:26:16 2019 From: report at bugs.python.org (Jakub Wilk) Date: Fri, 01 Feb 2019 18:26:16 +0000 Subject: [issue35829] datetime: parse "Z" timezone suffix in fromisoformat() In-Reply-To: <1548445007.56.0.14925163397.issue35829@roundup.psfhosted.org> Message-ID: <1549045576.99.0.619526988094.issue35829@roundup.psfhosted.org> Change by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 14:05:00 2019 From: report at bugs.python.org (Eric Snow) Date: Fri, 01 Feb 2019 19:05:00 +0000 Subject: [issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details In-Reply-To: <1541076409.33.0.788709270274.issue35134@psf.upfronthosting.co.za> Message-ID: <1549047900.41.0.591659858293.issue35134@roundup.psfhosted.org> Change by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 14:20:21 2019 From: report at bugs.python.org (Michael Felt) Date: Fri, 01 Feb 2019 19:20:21 +0000 Subject: [issue35773] test_bdb fails on AIX bot (regression) In-Reply-To: <1547812678.96.0.834885366728.issue35773@roundup.psfhosted.org> Message-ID: <1549048821.4.0.541936273764.issue35773@roundup.psfhosted.org> Michael Felt added the comment: OK. New info. Back in the time of issue 34347 I installed some extra filesets to support UTF-8 on the virtual machine (aka partition) that I have the bot on. On systems where this fileset is not installed this test does not fail. Shall dig further - in a bout a week - but I expect it is something very different than whatever bdb is testing. fyi - the additional fileset (not normally installed afaik) is/are: bos.loc.com.utf 7.1.4.30 C F Common Locale Support - UTF-8 bos.loc.utf.EN_US 7.1.4.30 C F Base System Locale UTF Code ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 14:33:53 2019 From: report at bugs.python.org (Neui) Date: Fri, 01 Feb 2019 19:33:53 +0000 Subject: [issue35883] Change invalid unicode characters to replacement characters in argv In-Reply-To: <1549040138.25.0.646545491344.issue35883@roundup.psfhosted.org> Message-ID: <1549049633.06.0.570022887332.issue35883@roundup.psfhosted.org> Neui added the comment: I'd say that the terminal is not really relevant here, but rather the locale settings because it uses wide string functions. Prefixing it with LC_ALL=C produces the same output as you had on my Ubuntu machine. I also get that output when running it in Cygwin (and MSYS2), although it seems setting LC_ALL has no effect. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 14:36:11 2019 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 01 Feb 2019 19:36:11 +0000 Subject: [issue35879] test_type_comments leaks references In-Reply-To: <1549020604.51.0.835471496217.issue35879@roundup.psfhosted.org> Message-ID: <1549049771.73.0.042476634749.issue35879@roundup.psfhosted.org> Guido van Rossum added the comment: > ast2obj_string increments it once and the setattr does it again and then there is only one Py_DECREF. Actually I don't understand how this is the leak. Adding another Py_DECREF(value) causes an immediate crash. I've been trying to follow other paths but haven't found the root yet. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 14:37:48 2019 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 01 Feb 2019 19:37:48 +0000 Subject: [issue35766] Merge typed_ast back into CPython In-Reply-To: <1547771581.08.0.389360423635.issue35766@roundup.psfhosted.org> Message-ID: <1549049868.09.0.853302050317.issue35766@roundup.psfhosted.org> Guido van Rossum added the comment: New changeset 3a32e3bf880f0842ac73d18285f5a1caa902a2ca by Guido van Rossum in branch 'master': bpo-35766 follow-up: Kill half-support for FunctionType in PyAST_obj2mod (#11714) https://github.com/python/cpython/commit/3a32e3bf880f0842ac73d18285f5a1caa902a2ca ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 14:39:03 2019 From: report at bugs.python.org (Eric Snow) Date: Fri, 01 Feb 2019 19:39:03 +0000 Subject: [issue35258] Consider enabling -Wmissing-prototypes In-Reply-To: <1542303223.2.0.788709270274.issue35258@psf.upfronthosting.co.za> Message-ID: <1549049943.92.0.381760594279.issue35258@roundup.psfhosted.org> Change by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 14:48:23 2019 From: report at bugs.python.org (SilentGhost) Date: Fri, 01 Feb 2019 19:48:23 +0000 Subject: [issue35883] Change invalid unicode characters to replacement characters in argv In-Reply-To: <1549040138.25.0.646545491344.issue35883@roundup.psfhosted.org> Message-ID: <1549050503.6.0.760894661948.issue35883@roundup.psfhosted.org> Change by SilentGhost : ---------- nosy: +ncoghlan versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 14:58:47 2019 From: report at bugs.python.org (Emily Morehouse) Date: Fri, 01 Feb 2019 19:58:47 +0000 Subject: [issue35861] test_named_expressions raises SyntaxWarning In-Reply-To: <1548875131.95.0.280347289465.issue35861@roundup.psfhosted.org> Message-ID: <1549051127.38.0.9381556412.issue35861@roundup.psfhosted.org> Emily Morehouse added the comment: New changeset 075de6cf6cb0f5f4d3711fc07f023a9a7a0a816b by Emily Morehouse (Joannah Nanjekye) in branch 'master': bpo-35861: Fix SyntaxWarning in test_named_expressions.py (GH-11722) https://github.com/python/cpython/commit/075de6cf6cb0f5f4d3711fc07f023a9a7a0a816b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 15:19:42 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 01 Feb 2019 20:19:42 +0000 Subject: [issue35884] Add variable access benchmark to Tools/Scripts Message-ID: <1549052380.12.0.716539002961.issue35884@roundup.psfhosted.org> New submission from Raymond Hettinger : Adding a short script that I've found useful many times over the past decade. It has allowed my to quickly notice performance regressions and has helped identify places in need of optimization work. It is also useful for building a empirical mental model of the relative cost of various kinds of variable access -- this is useful in writing high performance code. ---------- components: Demos and Tools messages: 334716 nosy: rhettinger priority: normal severity: normal status: open title: Add variable access benchmark to Tools/Scripts type: performance versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 15:21:21 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Fri, 01 Feb 2019 20:21:21 +0000 Subject: [issue35879] test_type_comments leaks references In-Reply-To: <1549020604.51.0.835471496217.issue35879@roundup.psfhosted.org> Message-ID: <1549052481.79.0.274596395553.issue35879@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: Hummmm.... I may be missing something but these is what I am seeing: BASELINE -------- ? ./python.exe -m test test_type_comments -R 10:10 Run tests sequentially 0:00:00 load avg: 2.30 [1/1] test_type_comments beginning 20 repetitions 12345678901234567890 .................... test_type_comments leaked [37, 37, 37, 37, 37, 37, 37, 37, 37, 37] references, sum=370 test_type_comments leaked [11, 12, 11, 11, 11, 11, 11, 11, 11, 11] memory blocks, sum=111 test_type_comments failed == Tests result: FAILURE == 1 test failed: test_type_comments Total duration: 1 sec 28 ms Tests result: FAILURE EXTRA_DECREF ------------ ? git --no-pager diff diff --git a/Python/Python-ast.c b/Python/Python-ast.c index 1a56e90bca..cb3036dbba 100644 --- a/Python/Python-ast.c +++ b/Python/Python-ast.c @@ -2791,6 +2791,7 @@ ast2obj_stmt(void* _o) if (_PyObject_SetAttrId(result, &PyId_type_comment, value) == -1) goto failed; Py_DECREF(value); + Py_DECREF(value); break; case AsyncFunctionDef_kind: result = PyType_GenericNew(AsyncFunctionDef_type, NULL, NULL); ~/github/cpython master ? ? ./python.exe -m test test_type_comments -R 10:10 Run tests sequentially 0:00:00 load avg: 2.12 [1/1] test_type_comments beginning 20 repetitions 12345678901234567890 .................... test_type_comments leaked [8, 9, 8, 8, 8, 8, 8, 8, 8, 8] memory blocks, sum=81 test_type_comments failed == Tests result: FAILURE == 1 test failed: test_type_comments Total duration: 976 ms Tests result: FAILURE So my interpretation is that there are still leaks somewhere or, but the extra-decref resolves the reference leaks somehow. Probably the extra DECREF here is not the proper fix, but is as far as I went when I started debugging this morning. Also, if you change one test to do the parsing in a loop: def test_funcdef(self): - tree = self.parse(funcdef) + for _ in range(100000): + tree = self.parse(funcdef) self.assertEqual(tree.body[0].type_comment, "() -> int") And you ran test_type_comments.py with PYTHONDUMPREFS=1: WITHOUT EXTRA DECREF -------------------- 65 wrapper_descriptor 75 str 82 str 85 str 86 str 92 str 110 str 416 str 200015 str WITH EXTRA DECREF ----------------- PYTHONDUMPREFS=1 ./python.exe -m test test_type_comments |& cut -d " " -f 3 | uniq -c | sort -n .... 85 str 86 str 92 str 110 str 416 str ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 15:24:22 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Fri, 01 Feb 2019 20:24:22 +0000 Subject: [issue35879] test_type_comments leaks references In-Reply-To: <1549020604.51.0.835471496217.issue35879@roundup.psfhosted.org> Message-ID: <1549052662.33.0.512863981588.issue35879@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: Note: the extra DECREF will fail in other tests because it will deallocate None if ast2obj_object returns Py_None because the comment is NULL. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 15:24:50 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 01 Feb 2019 20:24:50 +0000 Subject: [issue35884] Add variable access benchmark to Tools/Scripts In-Reply-To: <1549052380.12.0.716539002961.issue35884@roundup.psfhosted.org> Message-ID: <1549052690.21.0.915518847947.issue35884@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- keywords: +patch pull_requests: +11606 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 15:24:54 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 01 Feb 2019 20:24:54 +0000 Subject: [issue35884] Add variable access benchmark to Tools/Scripts In-Reply-To: <1549052380.12.0.716539002961.issue35884@roundup.psfhosted.org> Message-ID: <1549052694.08.0.364065071087.issue35884@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- keywords: +patch, patch pull_requests: +11606, 11607 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 15:34:35 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 01 Feb 2019 20:34:35 +0000 Subject: [issue35884] Add variable access benchmark to Tools/Scripts In-Reply-To: <1549052380.12.0.716539002961.issue35884@roundup.psfhosted.org> Message-ID: <1549053275.55.0.741963003925.issue35884@roundup.psfhosted.org> Raymond Hettinger added the comment: Here's what the output looks like (here am comparing a fresh Py3.8 with Clang versus the same build with GCC-8): $ make distclean && ./configure && make $ py Tools/scripts/var_access_benchmark.py Speed of different kinds of variable accesses: 4.2 ?s read_local 4.7 ?s read_nonlocal 13.7 ?s read_global 18.5 ?s read_builtin 18.2 ?s read_classvar 26.8 ?s read_instancevar 20.3 ?s read_instancevar_slots 19.1 ?s read_namedtuple 26.9 ?s read_boundmethod 4.5 ?s write_local 4.8 ?s write_nonlocal 18.8 ?s write_global 89.9 ?s write_classvar 37.1 ?s write_instancevar 25.7 ?s write_instancevar_slots 0.3 ?s loop_overhead $ make distclean && ./configure CC=gcc-8 && make $ py Tools/scripts/var_access_benchmark.py Speed of different kinds of variable accesses: 4.0 ?s read_local 4.2 ?s read_nonlocal 11.4 ?s read_global 16.3 ?s read_builtin 16.4 ?s read_classvar 24.8 ?s read_instancevar 20.1 ?s read_instancevar_slots 16.8 ?s read_namedtuple 23.2 ?s read_boundmethod 4.3 ?s write_local 4.5 ?s write_nonlocal 15.4 ?s write_global 89.4 ?s write_classvar 33.5 ?s write_instancevar 24.5 ?s write_instancevar_slots 0.3 ?s loop_overhead ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 15:39:00 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 01 Feb 2019 20:39:00 +0000 Subject: [issue35864] Replace OrderedDict with regular dict in namedtuple's _asdict() method. In-Reply-To: <1548901211.98.0.0872539907535.issue35864@roundup.psfhosted.org> Message-ID: <1549053540.28.0.108934040192.issue35864@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 85d83ec7c99727476c79feb5c34c65264a99144e by Raymond Hettinger (Amador Pahim) in branch 'master': bpo-35864: fix namedtuple._asdict() docstring (GH-11720) https://github.com/python/cpython/commit/85d83ec7c99727476c79feb5c34c65264a99144e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 15:43:17 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Fri, 01 Feb 2019 20:43:17 +0000 Subject: [issue35879] test_type_comments leaks references In-Reply-To: <1549020604.51.0.835471496217.issue35879@roundup.psfhosted.org> Message-ID: <1549053797.65.0.685487810908.issue35879@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: I'm almost sure this is not the correct fix, but I think these findings point to that object as the one being leaked. I do not understand how this object should be deallocated and where, I am trying to follow how the other PyObject* (name) is deallocated but I am not finding anything :( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 16:26:37 2019 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 01 Feb 2019 21:26:37 +0000 Subject: [issue35879] test_type_comments leaks references In-Reply-To: <1549020604.51.0.835471496217.issue35879@roundup.psfhosted.org> Message-ID: <1549056397.5.0.784029210535.issue35879@roundup.psfhosted.org> Guido van Rossum added the comment: I have been trying to do the same thing and likewise, no luck understanding yet how type comments are different here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 16:33:29 2019 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 01 Feb 2019 21:33:29 +0000 Subject: [issue35879] test_type_comments leaks references In-Reply-To: <1549020604.51.0.835471496217.issue35879@roundup.psfhosted.org> Message-ID: <1549056809.41.0.377299258303.issue35879@roundup.psfhosted.org> Guido van Rossum added the comment: In the meantime here's the fix for the '# type: ignore' leak. https://github.com/gvanrossum/cpython/commit/ef3b9e952906aab8f5452ebcf3b9e359d35615b4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 16:40:26 2019 From: report at bugs.python.org (Emily Morehouse) Date: Fri, 01 Feb 2019 21:40:26 +0000 Subject: [issue35877] parenthesis is mandatory for named expressions in while statement In-Reply-To: <1549018555.29.0.231525655805.issue35877@roundup.psfhosted.org> Message-ID: <1549057226.59.0.596744344595.issue35877@roundup.psfhosted.org> Emily Morehouse added the comment: New changeset d4fceaafb8e3f8700d9ec6ab37a51e903392f74f by Emily Morehouse (Xtreak) in branch 'master': bpo-35877: Make parenthesis optional for named expression in while statement (GH-11724) https://github.com/python/cpython/commit/d4fceaafb8e3f8700d9ec6ab37a51e903392f74f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 16:49:30 2019 From: report at bugs.python.org (Emily Morehouse) Date: Fri, 01 Feb 2019 21:49:30 +0000 Subject: [issue35877] parenthesis is mandatory for named expressions in while statement In-Reply-To: <1549018555.29.0.231525655805.issue35877@roundup.psfhosted.org> Message-ID: <1549057770.42.0.545892833015.issue35877@roundup.psfhosted.org> Change by Emily Morehouse : ---------- pull_requests: +11608 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 16:49:35 2019 From: report at bugs.python.org (Emily Morehouse) Date: Fri, 01 Feb 2019 21:49:35 +0000 Subject: [issue35877] parenthesis is mandatory for named expressions in while statement In-Reply-To: <1549018555.29.0.231525655805.issue35877@roundup.psfhosted.org> Message-ID: <1549057775.67.0.784255683871.issue35877@roundup.psfhosted.org> Change by Emily Morehouse : ---------- pull_requests: +11608, 11609 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 16:49:41 2019 From: report at bugs.python.org (Emily Morehouse) Date: Fri, 01 Feb 2019 21:49:41 +0000 Subject: [issue35877] parenthesis is mandatory for named expressions in while statement In-Reply-To: <1549018555.29.0.231525655805.issue35877@roundup.psfhosted.org> Message-ID: <1549057781.91.0.755177723335.issue35877@roundup.psfhosted.org> Change by Emily Morehouse : ---------- pull_requests: +11608, 11609, 11610 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 16:53:20 2019 From: report at bugs.python.org (Emily Morehouse) Date: Fri, 01 Feb 2019 21:53:20 +0000 Subject: [issue35877] parenthesis is mandatory for named expressions in while statement In-Reply-To: <1549018555.29.0.231525655805.issue35877@roundup.psfhosted.org> Message-ID: <1549058000.67.0.409889125563.issue35877@roundup.psfhosted.org> Emily Morehouse added the comment: Thanks, Karthikeyan! I added an additional test to make sure this gets coverage. I'll close out this issue once tests pass and I can merge that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 16:54:26 2019 From: report at bugs.python.org (Emily Morehouse) Date: Fri, 01 Feb 2019 21:54:26 +0000 Subject: [issue35861] test_named_expressions raises SyntaxWarning In-Reply-To: <1548875131.95.0.280347289465.issue35861@roundup.psfhosted.org> Message-ID: <1549058066.38.0.749872798871.issue35861@roundup.psfhosted.org> Change by Emily Morehouse : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 17:27:45 2019 From: report at bugs.python.org (Emily Morehouse) Date: Fri, 01 Feb 2019 22:27:45 +0000 Subject: [issue35877] parenthesis is mandatory for named expressions in while statement In-Reply-To: <1549018555.29.0.231525655805.issue35877@roundup.psfhosted.org> Message-ID: <1549060065.13.0.402232597919.issue35877@roundup.psfhosted.org> Emily Morehouse added the comment: New changeset ac19081c26eaa7de3e6aabeb789ddc2e7cdd5b24 by Emily Morehouse in branch 'master': bpo-35877: Add test for while loop named expression without parentheses (GH-11726) https://github.com/python/cpython/commit/ac19081c26eaa7de3e6aabeb789ddc2e7cdd5b24 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 17:28:36 2019 From: report at bugs.python.org (Emily Morehouse) Date: Fri, 01 Feb 2019 22:28:36 +0000 Subject: [issue35877] parenthesis is mandatory for named expressions in while statement In-Reply-To: <1549018555.29.0.231525655805.issue35877@roundup.psfhosted.org> Message-ID: <1549060116.41.0.781410441395.issue35877@roundup.psfhosted.org> Change by Emily Morehouse : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 17:39:54 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Fri, 01 Feb 2019 22:39:54 +0000 Subject: [issue35877] parenthesis is mandatory for named expressions in while statement In-Reply-To: <1549018555.29.0.231525655805.issue35877@roundup.psfhosted.org> Message-ID: <1549060794.86.0.919922736325.issue35877@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Thanks a lot Guido and Emily for guidance on this issue. Happy to see this for alpha release :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 17:49:00 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Fri, 01 Feb 2019 22:49:00 +0000 Subject: [issue34886] subprocess.run throws exception when input and stdin are passed as kwargs In-Reply-To: <1538592638.37.0.545547206417.issue34886@psf.upfronthosting.co.za> Message-ID: <1549061340.24.0.569447324622.issue34886@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- keywords: +patch pull_requests: +11611 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 17:49:07 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Fri, 01 Feb 2019 22:49:07 +0000 Subject: [issue34886] subprocess.run throws exception when input and stdin are passed as kwargs In-Reply-To: <1538592638.37.0.545547206417.issue34886@psf.upfronthosting.co.za> Message-ID: <1549061347.9.0.974084943231.issue34886@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- keywords: +patch, patch pull_requests: +11611, 11612 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 17:49:14 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Fri, 01 Feb 2019 22:49:14 +0000 Subject: [issue34886] subprocess.run throws exception when input and stdin are passed as kwargs In-Reply-To: <1538592638.37.0.545547206417.issue34886@psf.upfronthosting.co.za> Message-ID: <1549061354.11.0.275770072105.issue34886@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- keywords: +patch, patch, patch pull_requests: +11611, 11612, 11613 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 17:50:04 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Fri, 01 Feb 2019 22:50:04 +0000 Subject: [issue34886] subprocess.run throws exception when input and stdin are passed as kwargs In-Reply-To: <1538592638.37.0.545547206417.issue34886@psf.upfronthosting.co.za> Message-ID: <1549061404.52.0.420713188985.issue34886@roundup.psfhosted.org> R?mi Lapeyre added the comment: I opened a PR with @josh.r proposed change. ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 17:59:16 2019 From: report at bugs.python.org (mrs.red) Date: Fri, 01 Feb 2019 22:59:16 +0000 Subject: [issue35885] configparser: indentation Message-ID: <1549061954.1.0.734541407213.issue35885@roundup.psfhosted.org> New submission from mrs.red : The configparser module does not have an option for indentation. I would like to indent the keys by tabs. Maybe we could implement an option for that? I already have some example code for it. ---------- components: Library (Lib) messages: 334729 nosy: mrs.red priority: normal severity: normal status: open title: configparser: indentation type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 18:03:52 2019 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 01 Feb 2019 23:03:52 +0000 Subject: [issue35879] test_type_comments leaks references In-Reply-To: <1549020604.51.0.835471496217.issue35879@roundup.psfhosted.org> Message-ID: <1549062232.38.0.828177912405.issue35879@roundup.psfhosted.org> Change by Guido van Rossum : ---------- keywords: +patch pull_requests: +11614 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 18:04:00 2019 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 01 Feb 2019 23:04:00 +0000 Subject: [issue35879] test_type_comments leaks references In-Reply-To: <1549020604.51.0.835471496217.issue35879@roundup.psfhosted.org> Message-ID: <1549062240.01.0.804823569235.issue35879@roundup.psfhosted.org> Change by Guido van Rossum : ---------- keywords: +patch, patch pull_requests: +11614, 11615 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 18:04:07 2019 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 01 Feb 2019 23:04:07 +0000 Subject: [issue35879] test_type_comments leaks references In-Reply-To: <1549020604.51.0.835471496217.issue35879@roundup.psfhosted.org> Message-ID: <1549062247.68.0.739599442849.issue35879@roundup.psfhosted.org> Change by Guido van Rossum : ---------- keywords: +patch, patch, patch pull_requests: +11614, 11615, 11616 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 18:09:48 2019 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 01 Feb 2019 23:09:48 +0000 Subject: [issue35879] test_type_comments leaks references In-Reply-To: <1549020604.51.0.835471496217.issue35879@roundup.psfhosted.org> Message-ID: <1549062588.43.0.018689547399.issue35879@roundup.psfhosted.org> Guido van Rossum added the comment: Found it! You need to call PyArena_AddPyObject(). I racked my brain and finally found the example code I needed at the end of new_identifier(). Please review quickly so we won't ship 3.8.0a1 with a memory leak. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 18:28:22 2019 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 01 Feb 2019 23:28:22 +0000 Subject: [issue35879] test_type_comments leaks references In-Reply-To: <1549020604.51.0.835471496217.issue35879@roundup.psfhosted.org> Message-ID: <1549063702.0.0.613628184823.issue35879@roundup.psfhosted.org> Guido van Rossum added the comment: New changeset d2b4c19d53f5f021fb1c7c32d48033a92ac4fe49 by Guido van Rossum in branch 'master': bpo-35879: Fix type comment leaks (GH-11728) https://github.com/python/cpython/commit/d2b4c19d53f5f021fb1c7c32d48033a92ac4fe49 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 18:31:43 2019 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 01 Feb 2019 23:31:43 +0000 Subject: [issue35879] test_type_comments leaks references In-Reply-To: <1549020604.51.0.835471496217.issue35879@roundup.psfhosted.org> Message-ID: <1549063903.78.0.294680954161.issue35879@roundup.psfhosted.org> Change by Guido van Rossum : ---------- assignee: -> gvanrossum resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 18:34:01 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 01 Feb 2019 23:34:01 +0000 Subject: [issue35880] math.sin has no backward error; this isn't documented In-Reply-To: <1549021657.57.0.382503652198.issue35880@roundup.psfhosted.org> Message-ID: <1549064041.41.0.743265686809.issue35880@roundup.psfhosted.org> Change by Terry J. Reedy : ---------- stage: -> needs patch versions: -Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 18:37:17 2019 From: report at bugs.python.org (kernc) Date: Fri, 01 Feb 2019 23:37:17 +0000 Subject: [issue17972] inspect module docs omits many functions In-Reply-To: <1368501068.91.0.677640111487.issue17972@psf.upfronthosting.co.za> Message-ID: <1549064237.18.0.838689626457.issue17972@roundup.psfhosted.org> Change by kernc : ---------- nosy: +kernc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 18:49:22 2019 From: report at bugs.python.org (Eryk Sun) Date: Fri, 01 Feb 2019 23:49:22 +0000 Subject: [issue35883] Change invalid unicode characters to replacement characters in argv In-Reply-To: <1549040138.25.0.646545491344.issue35883@roundup.psfhosted.org> Message-ID: <1549064962.38.0.0212201261109.issue35883@roundup.psfhosted.org> Eryk Sun added the comment: In Unix, Python 3.6 decodes the char * command line arguments via mbstowcs. In Linux, I see the following misbehavior of mbstowcs when decoding an overlong UTF-8 sequence: >>> mbstowcs = ctypes.CDLL(None, use_errno=True).mbstowcs >>> arg = bytes(x + 128 for x in [1 + 124, 63, 63, 59, 58, 58]) >>> mbstowcs(None, arg, 0) 1 >>> buf = (ctypes.c_int * 2)() >>> mbstowcs(buf, arg, 2) 1 >>> hex(buf[0]) '0x7fffbeba' This shouldn't be an issue in 3.7, at least not with the default UTF-8 mode configuration. With this mode, Py_DecodeLocale calls _Py_DecodeUTF8Ex using the surrogateescape error handler [1]. [1]: https://github.com/python/cpython/blob/v3.7.2/Python/fileutils.c#L456 ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 19:17:15 2019 From: report at bugs.python.org (Demian Brecht) Date: Sat, 02 Feb 2019 00:17:15 +0000 Subject: [issue24177] Add https?_proxy support to http.client In-Reply-To: <1431533065.95.0.88567271375.issue24177@psf.upfronthosting.co.za> Message-ID: <1549066635.22.0.662895578886.issue24177@roundup.psfhosted.org> Change by Demian Brecht : ---------- keywords: +patch pull_requests: +11617 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 19:17:21 2019 From: report at bugs.python.org (Demian Brecht) Date: Sat, 02 Feb 2019 00:17:21 +0000 Subject: [issue24177] Add https?_proxy support to http.client In-Reply-To: <1431533065.95.0.88567271375.issue24177@psf.upfronthosting.co.za> Message-ID: <1549066641.77.0.4510371183.issue24177@roundup.psfhosted.org> Change by Demian Brecht : ---------- keywords: +patch, patch pull_requests: +11617, 11618 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 19:17:28 2019 From: report at bugs.python.org (Demian Brecht) Date: Sat, 02 Feb 2019 00:17:28 +0000 Subject: [issue24177] Add https?_proxy support to http.client In-Reply-To: <1431533065.95.0.88567271375.issue24177@psf.upfronthosting.co.za> Message-ID: <1549066648.23.0.479198597743.issue24177@roundup.psfhosted.org> Change by Demian Brecht : ---------- keywords: +patch, patch, patch pull_requests: +11617, 11618, 11619 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 19:26:24 2019 From: report at bugs.python.org (Stefan Krah) Date: Sat, 02 Feb 2019 00:26:24 +0000 Subject: [issue35845] Can't read a F-contiguous memoryview in physical order In-Reply-To: <1548708697.36.0.695790780311.issue35845@roundup.psfhosted.org> Message-ID: <1549067184.38.0.857994230832.issue35845@roundup.psfhosted.org> Change by Stefan Krah : ---------- keywords: +patch pull_requests: +11620 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 19:26:30 2019 From: report at bugs.python.org (Stefan Krah) Date: Sat, 02 Feb 2019 00:26:30 +0000 Subject: [issue35845] Can't read a F-contiguous memoryview in physical order In-Reply-To: <1548708697.36.0.695790780311.issue35845@roundup.psfhosted.org> Message-ID: <1549067190.28.0.507312297008.issue35845@roundup.psfhosted.org> Change by Stefan Krah : ---------- keywords: +patch, patch pull_requests: +11620, 11621 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 19:26:35 2019 From: report at bugs.python.org (Stefan Krah) Date: Sat, 02 Feb 2019 00:26:35 +0000 Subject: [issue35845] Can't read a F-contiguous memoryview in physical order In-Reply-To: <1548708697.36.0.695790780311.issue35845@roundup.psfhosted.org> Message-ID: <1549067195.93.0.649870385941.issue35845@roundup.psfhosted.org> Change by Stefan Krah : ---------- keywords: +patch, patch, patch pull_requests: +11620, 11621, 11622 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 19:48:17 2019 From: report at bugs.python.org (Barry A. Warsaw) Date: Sat, 02 Feb 2019 00:48:17 +0000 Subject: [issue35321] None _frozen_importlib.__spec__.origin attribute In-Reply-To: <1543274371.24.0.788709270274.issue35321@psf.upfronthosting.co.za> Message-ID: <1549068497.21.0.913890137923.issue35321@roundup.psfhosted.org> Change by Barry A. Warsaw : ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 20:07:10 2019 From: report at bugs.python.org (Eric Snow) Date: Sat, 02 Feb 2019 01:07:10 +0000 Subject: [issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h Message-ID: <1549069628.87.0.454232469964.issue35886@roundup.psfhosted.org> New submission from Eric Snow : In November Victor created the Include/cpython directory and moved a decent amount of public (but not limited) API there. This included the PyInterpreterState struct. I'd like to move it into the "internal" headers since it is somewhat coupled to the internal runtime implementation. The alternative is extra complexity. I ran into this while working on another issue. Note that the docs indicate that all of the struct's fields are private (and I am not aware of any macros leaking fields into the stable ABI). So moving it should not break anything (yeah, right!), and certainly not the stable ABI (Victor's move would have done that already). ---------- assignee: eric.snow messages: 334733 nosy: eric.snow, vstinner priority: normal severity: normal stage: needs patch status: open title: Move PyInterpreterState into Include/internal/pycore_pystate.h versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 20:13:43 2019 From: report at bugs.python.org (Barry A. Warsaw) Date: Sat, 02 Feb 2019 01:13:43 +0000 Subject: [issue35839] Suggestion: Ignore sys.modules entries with no __spec__ attribute in find_spec In-Reply-To: <1548658454.23.0.545832854699.issue35839@roundup.psfhosted.org> Message-ID: <1549070023.45.0.714762972709.issue35839@roundup.psfhosted.org> Change by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 20:24:52 2019 From: report at bugs.python.org (Eric Snow) Date: Sat, 02 Feb 2019 01:24:52 +0000 Subject: [issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h In-Reply-To: <1549069628.87.0.454232469964.issue35886@roundup.psfhosted.org> Message-ID: <1549070692.26.0.448674340444.issue35886@roundup.psfhosted.org> Change by Eric Snow : ---------- keywords: +patch pull_requests: +11623 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 20:24:58 2019 From: report at bugs.python.org (Eric Snow) Date: Sat, 02 Feb 2019 01:24:58 +0000 Subject: [issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h In-Reply-To: <1549069628.87.0.454232469964.issue35886@roundup.psfhosted.org> Message-ID: <1549070698.08.0.574102799549.issue35886@roundup.psfhosted.org> Change by Eric Snow : ---------- keywords: +patch, patch pull_requests: +11623, 11624 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 20:25:03 2019 From: report at bugs.python.org (Eric Snow) Date: Sat, 02 Feb 2019 01:25:03 +0000 Subject: [issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h In-Reply-To: <1549069628.87.0.454232469964.issue35886@roundup.psfhosted.org> Message-ID: <1549070703.21.0.792903203538.issue35886@roundup.psfhosted.org> Change by Eric Snow : ---------- keywords: +patch, patch, patch pull_requests: +11623, 11624, 11625 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 20:32:46 2019 From: report at bugs.python.org (Eric Snow) Date: Sat, 02 Feb 2019 01:32:46 +0000 Subject: [issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h In-Reply-To: <1549069628.87.0.454232469964.issue35886@roundup.psfhosted.org> Message-ID: <1549071166.33.0.722526577548.issue35886@roundup.psfhosted.org> Eric Snow added the comment: FWIW, I was hoping to the same for PyThreadState but it looks like 6 of its fields are exposed in "stable" header files via the following macros: # Include/object.h Py_TRASHCAN_SAFE_BEGIN Py_TRASHCAN_SAFE_END Include.ceval.h Py_EnterRecursiveCall Py_LeaveRecursiveCall _Py_MakeRecCheck Py_ALLOW_RECURSION Py_END_ALLOW_RECURSION I'm not sure how that factors into the stable ABI (PyThreadState wasn't ever guarded by Py_LIMITED_API). However, I didn't need to deal with it right now so I'm not going to go there. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 20:42:17 2019 From: report at bugs.python.org (Nina Zakharenko) Date: Sat, 02 Feb 2019 01:42:17 +0000 Subject: [issue35887] Doc string for updating the frozen version of importlib in _bootstrap.py incorrect Message-ID: <1549071736.85.0.965218389814.issue35887@roundup.psfhosted.org> New submission from Nina Zakharenko : In the process of creating a fix for issue #35321, I noticed what I believe to be a documentation omission. In Lib/importlib/_bootstrap.py the top level comment states that: # IMPORTANT: Whenever making changes to this module, be sure to run # a top-level make in order to get the frozen version of the module # updated. >From my testing, it appears that the header file will only be updated when running `make regen-importlib` To repo: - make a code change in Lib/importlib/_bootstrap_external.py - run a top-level `make` - see that Python/importlib.h does not change - run `make regen-importlib` - see that Python/importlib.h has now been updated The documentation in Lib/importlib/_bootstrap_external.py does in fact mention this. I propose amending the documentation to include the correct instructions. If this is deemed necessary, I will write the patch over the weekend. ---------- assignee: nnja components: Library (Lib) messages: 334735 nosy: barry, nnja priority: low severity: normal status: open title: Doc string for updating the frozen version of importlib in _bootstrap.py incorrect versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 20:49:02 2019 From: report at bugs.python.org (Nina Zakharenko) Date: Sat, 02 Feb 2019 01:49:02 +0000 Subject: [issue35537] use os.posix_spawn in subprocess In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za> Message-ID: <1549072142.25.0.781340813847.issue35537@roundup.psfhosted.org> Change by Nina Zakharenko : ---------- pull_requests: +11626 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 20:49:17 2019 From: report at bugs.python.org (Nina Zakharenko) Date: Sat, 02 Feb 2019 01:49:17 +0000 Subject: [issue35537] use os.posix_spawn in subprocess In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za> Message-ID: <1549072157.76.0.955672345961.issue35537@roundup.psfhosted.org> Change by Nina Zakharenko : ---------- pull_requests: +11626, 11627 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 20:49:32 2019 From: report at bugs.python.org (Nina Zakharenko) Date: Sat, 02 Feb 2019 01:49:32 +0000 Subject: [issue35537] use os.posix_spawn in subprocess In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za> Message-ID: <1549072172.47.0.897009280503.issue35537@roundup.psfhosted.org> Change by Nina Zakharenko : ---------- pull_requests: +11626, 11627, 11628 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 20:54:30 2019 From: report at bugs.python.org (Nina Zakharenko) Date: Sat, 02 Feb 2019 01:54:30 +0000 Subject: [issue35321] None _frozen_importlib.__spec__.origin attribute In-Reply-To: <1543274371.24.0.788709270274.issue35321@psf.upfronthosting.co.za> Message-ID: <1549072470.5.0.813722978022.issue35321@roundup.psfhosted.org> Change by Nina Zakharenko : ---------- keywords: +patch pull_requests: +11629 stage: test needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 22:54:24 2019 From: report at bugs.python.org (Michael Sullivan) Date: Sat, 02 Feb 2019 03:54:24 +0000 Subject: [issue34235] PyArg_ParseTupleAndKeywords: support required keyword arguments In-Reply-To: <1532610257.0.0.56676864532.issue34235@psf.upfronthosting.co.za> Message-ID: <1549079664.74.0.433191137698.issue34235@roundup.psfhosted.org> Michael Sullivan added the comment: How about adding another sigil that indicates that subsequent keyword-only arguments are required? So then your example becomes (using ` as a totally strawman option): PyArg_ParseTupleAndKeywords(args, kwds, "O|O$O`O", kwlist, &a, &b, &d, &c) It's a little complicated but so is Python argument processing, so maybe that makes sense. I can submit a PR for this. ---------- nosy: +msullivan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 23:18:02 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 02 Feb 2019 04:18:02 +0000 Subject: [issue35780] Recheck logic in the C version of the lru_cache() In-Reply-To: <1547871578.67.0.302934084247.issue35780@roundup.psfhosted.org> Message-ID: <1549081082.64.0.174612047622.issue35780@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- pull_requests: +11630 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 23:18:07 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 02 Feb 2019 04:18:07 +0000 Subject: [issue35780] Recheck logic in the C version of the lru_cache() In-Reply-To: <1547871578.67.0.302934084247.issue35780@roundup.psfhosted.org> Message-ID: <1549081087.72.0.13054461288.issue35780@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- pull_requests: +11630, 11631 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 23:18:12 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 02 Feb 2019 04:18:12 +0000 Subject: [issue35780] Recheck logic in the C version of the lru_cache() In-Reply-To: <1547871578.67.0.302934084247.issue35780@roundup.psfhosted.org> Message-ID: <1549081092.77.0.239531679261.issue35780@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- pull_requests: +11630, 11631, 11632 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 1 23:52:25 2019 From: report at bugs.python.org (Davin Potts) Date: Sat, 02 Feb 2019 04:52:25 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1549083145.83.0.91731581388.issue35813@roundup.psfhosted.org> Davin Potts added the comment: New changeset e5ef45b8f519a9be9965590e1a0a587ff584c180 by Davin Potts in branch 'master': bpo-35813: Added shared_memory submodule of multiprocessing. (#11664) https://github.com/python/cpython/commit/e5ef45b8f519a9be9965590e1a0a587ff584c180 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 01:09:57 2019 From: report at bugs.python.org (Lee Eric) Date: Sat, 02 Feb 2019 06:09:57 +0000 Subject: [issue35888] ssl module - could not get the server certificate w/o completed handshake Message-ID: <1549087795.05.0.177157894622.issue35888@roundup.psfhosted.org> New submission from Lee Eric : Hi, I'm not sure if this is the right place to ask after I exhausted several communication ways. I'm trying to use standard ssl module to get the server certificate details. If I understand correctly, the certificate I can get only when the TLS/SSL handshake is done. Which means, if the server uses mTLS to authenticate client and I use ssl module to try to get the peer certificate w/o client certificate, I would not get the result due to the handshake is not complete. I would like to know if there's any method that I can get the certificate even the handshake is not complete. Also, as the very initial handshake stage, in Server Hello the service side has sent out the server certificate already. If the standard ssl module is designed in this behavior, is there any other module I can use to bypass the completed handshake to get the server certificate? Thanks. Eric ---------- assignee: christian.heimes components: SSL messages: 334738 nosy: Lee Eric, christian.heimes priority: normal severity: normal status: open title: ssl module - could not get the server certificate w/o completed handshake type: behavior versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 03:46:14 2019 From: report at bugs.python.org (SilentGhost) Date: Sat, 02 Feb 2019 08:46:14 +0000 Subject: [issue35885] configparser: indentation In-Reply-To: <1549061954.1.0.734541407213.issue35885@roundup.psfhosted.org> Message-ID: <1549097174.97.0.912701773288.issue35885@roundup.psfhosted.org> Change by SilentGhost : ---------- nosy: +lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 04:59:25 2019 From: report at bugs.python.org (Stefan Krah) Date: Sat, 02 Feb 2019 09:59:25 +0000 Subject: [issue35845] Can't read a F-contiguous memoryview in physical order In-Reply-To: <1548708697.36.0.695790780311.issue35845@roundup.psfhosted.org> Message-ID: <1549101565.98.0.339852204821.issue35845@roundup.psfhosted.org> Stefan Krah added the comment: Yes, following NumPy looks like the sanest option for tobytes(), so I went ahead and implemented that signature. memory.raw() is of course complicated by the fact that things like m[::-1] move buf.ptr to the end of the buffer. So we'd need to restrict to contiguous views anyway, which makes the method less appealing (IOW, it doesn't offer more than an augmented memoryview.cast()). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 05:01:05 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 02 Feb 2019 10:01:05 +0000 Subject: [issue25592] distutils docs: data_files always uses sys.prefix In-Reply-To: <1447135572.7.0.138478279434.issue25592@psf.upfronthosting.co.za> Message-ID: <1549101665.52.0.731488963826.issue25592@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11633 stage: resolved -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 05:01:17 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 02 Feb 2019 10:01:17 +0000 Subject: [issue25592] distutils docs: data_files always uses sys.prefix In-Reply-To: <1447135572.7.0.138478279434.issue25592@psf.upfronthosting.co.za> Message-ID: <1549101677.15.0.222224003799.issue25592@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11633, 11634 stage: resolved -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 05:01:30 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 02 Feb 2019 10:01:30 +0000 Subject: [issue25592] distutils docs: data_files always uses sys.prefix In-Reply-To: <1447135572.7.0.138478279434.issue25592@psf.upfronthosting.co.za> Message-ID: <1549101690.04.0.312611971339.issue25592@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11633, 11634, 11635 stage: resolved -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 05:16:14 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 02 Feb 2019 10:16:14 +0000 Subject: [issue25592] distutils docs: data_files always uses sys.prefix In-Reply-To: <1447135572.7.0.138478279434.issue25592@psf.upfronthosting.co.za> Message-ID: <1549102574.39.0.577591484271.issue25592@roundup.psfhosted.org> Antoine Pitrou added the comment: New changeset 40a101df8c64a1e55cca2780248d7a92bdcccd57 by Antoine Pitrou (Miss Islington (bot)) in branch '2.7': bpo-25592: Improve documentation of distutils data_files (GH-9767) (GH-11734) https://github.com/python/cpython/commit/40a101df8c64a1e55cca2780248d7a92bdcccd57 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 05:16:29 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 02 Feb 2019 10:16:29 +0000 Subject: [issue25592] distutils docs: data_files always uses sys.prefix In-Reply-To: <1447135572.7.0.138478279434.issue25592@psf.upfronthosting.co.za> Message-ID: <1549102589.29.0.297236661457.issue25592@roundup.psfhosted.org> Change by Antoine Pitrou : ---------- stage: patch review -> resolved status: open -> closed versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 05:17:12 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 02 Feb 2019 10:17:12 +0000 Subject: [issue25592] distutils docs: data_files always uses sys.prefix In-Reply-To: <1447135572.7.0.138478279434.issue25592@psf.upfronthosting.co.za> Message-ID: <1549102632.83.0.211483575689.issue25592@roundup.psfhosted.org> Antoine Pitrou added the comment: Ok, this is now pushed to 2.7 as well. Thank you Jeroen! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 05:23:55 2019 From: report at bugs.python.org (Stefan Krah) Date: Sat, 02 Feb 2019 10:23:55 +0000 Subject: [issue34778] Memoryview for column-major (f_contiguous) arrays from bytes impossible to achieve In-Reply-To: <1537725098.47.0.956365154283.issue34778@psf.upfronthosting.co.za> Message-ID: <1549103035.72.0.161097989982.issue34778@roundup.psfhosted.org> Stefan Krah added the comment: It seems reasonable to support f-contiguous for cast() and tobytes(). For tobytes() it's implemented in the issue that Antoine linked to. General support for strides in cast(), i.e. a zero-copy view for non-contiguous arrays does not seem possible because buf.ptr is moved around. Even NumPy does not support that: >>> x = np.array([1,2,3]) >>> x.view('B') array([1, 0, 0, 0, 0, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 3, 0, 0, 0, 0, 0, 0, 0], dtype=uint8) >>> >>> x[::-1].view('B') Traceback (most recent call last): File "", line 1, in ValueError: To change to a dtype of a different size, the array must be C-contiguous >>> >>> y = x.astype('B') >>> y.flags['OWNDATA'] # It's a copy. True ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 05:31:35 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 02 Feb 2019 10:31:35 +0000 Subject: [issue35845] Can't read a F-contiguous memoryview in physical order In-Reply-To: <1548708697.36.0.695790780311.issue35845@roundup.psfhosted.org> Message-ID: <1549103495.52.0.0457542246619.issue35845@roundup.psfhosted.org> Antoine Pitrou added the comment: > So we'd need to restrict to contiguous views anyway, which makes the method less appealing (IOW, it doesn't offer more than an augmented memoryview.cast()). Yes, it would probably be a simpler way of writing `.cast('B', shape=(...), order='A')`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 06:50:37 2019 From: report at bugs.python.org (=?utf-8?q?Tobias_D=C3=A4ullary?=) Date: Sat, 02 Feb 2019 11:50:37 +0000 Subject: [issue35862] Change the environment for a new process In-Reply-To: <1548877516.06.0.747468813802.issue35862@roundup.psfhosted.org> Message-ID: <1549108237.81.0.0397386219312.issue35862@roundup.psfhosted.org> Tobias D?ullary added the comment: Alright, thanks for pointing me in the right direction. I have to conclude that this issue is not present on a current operating system, as I now tried to reproduce with Windows 10 (I came across it on an ancient Windows XP (sic) system - I can just imagine putenv didn't do its job as requested). I suppose this can be closed then! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 07:25:33 2019 From: report at bugs.python.org (PyScripter) Date: Sat, 02 Feb 2019 12:25:33 +0000 Subject: [issue35706] Make it easier to use a venv with an embedded Python interpreter In-Reply-To: <1547129099.62.0.924394155356.issue35706@roundup.psfhosted.org> Message-ID: <1549110333.52.0.739239412462.issue35706@roundup.psfhosted.org> PyScripter added the comment: Similar experience. I have found no way to get to use a venv as embedded Python in PyScripter. Tried Py_SetPythonhome, Py_SetPythonName, combinations... Nothing worked. ---------- nosy: +pyscripter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 08:02:18 2019 From: report at bugs.python.org (Vlad Shcherbina) Date: Sat, 02 Feb 2019 13:02:18 +0000 Subject: [issue35889] sqlite3.Row doesn't have useful repr Message-ID: <1549112536.04.0.744689521798.issue35889@roundup.psfhosted.org> New submission from Vlad Shcherbina : To reproduce, run the following program: import sqlite3 conn = sqlite3.connect(':memory:') conn.row_factory = sqlite3.Row print(conn.execute("SELECT 'John' AS name, 42 AS salary").fetchone()) It prints ''. It would be nice if it printed something like "sqlite3.Row(name='Smith', saraly=42)" instead. It wouldn't satisfy the 'eval(repr(x)) == x' property, but it's still better than nothing. If the maintainers agree this is useful, I'll implement. ---------- components: Library (Lib) messages: 334746 nosy: vlad priority: normal severity: normal status: open title: sqlite3.Row doesn't have useful repr type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 08:23:13 2019 From: report at bugs.python.org (Ivan Levkivskyi) Date: Sat, 02 Feb 2019 13:23:13 +0000 Subject: [issue35878] ast.c: end_col_offset may be used uninitialized in this function In-Reply-To: <1549020161.52.0.11493245766.issue35878@roundup.psfhosted.org> Message-ID: <1549113793.95.0.146068494651.issue35878@roundup.psfhosted.org> Change by Ivan Levkivskyi : ---------- keywords: +patch pull_requests: +11636 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 08:23:20 2019 From: report at bugs.python.org (Ivan Levkivskyi) Date: Sat, 02 Feb 2019 13:23:20 +0000 Subject: [issue35878] ast.c: end_col_offset may be used uninitialized in this function In-Reply-To: <1549020161.52.0.11493245766.issue35878@roundup.psfhosted.org> Message-ID: <1549113800.02.0.340948225035.issue35878@roundup.psfhosted.org> Change by Ivan Levkivskyi : ---------- keywords: +patch, patch pull_requests: +11636, 11637 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 08:23:24 2019 From: report at bugs.python.org (Ivan Levkivskyi) Date: Sat, 02 Feb 2019 13:23:24 +0000 Subject: [issue35878] ast.c: end_col_offset may be used uninitialized in this function In-Reply-To: <1549020161.52.0.11493245766.issue35878@roundup.psfhosted.org> Message-ID: <1549113804.77.0.351735368748.issue35878@roundup.psfhosted.org> Change by Ivan Levkivskyi : ---------- keywords: +patch, patch, patch pull_requests: +11636, 11637, 11638 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 09:37:43 2019 From: report at bugs.python.org (Stefan Krah) Date: Sat, 02 Feb 2019 14:37:43 +0000 Subject: [issue26256] Fast decimalisation and conversion to other bases In-Reply-To: <1454322513.41.0.794136944555.issue26256@psf.upfronthosting.co.za> Message-ID: <1549118263.22.0.890356610827.issue26256@roundup.psfhosted.org> Stefan Krah added the comment: New changeset 00e9c55d27aff3e445ab4c8629cf4d59f46ff945 by Stefan Krah (Cheryl Sabella) in branch 'master': bpo-26256: Document algorithm speed for the Decimal module. (#4808) https://github.com/python/cpython/commit/00e9c55d27aff3e445ab4c8629cf4d59f46ff945 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 09:40:22 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 02 Feb 2019 14:40:22 +0000 Subject: [issue26256] Fast decimalisation and conversion to other bases In-Reply-To: <1454322513.41.0.794136944555.issue26256@psf.upfronthosting.co.za> Message-ID: <1549118422.83.0.599140730922.issue26256@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11639 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 09:40:34 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 02 Feb 2019 14:40:34 +0000 Subject: [issue26256] Fast decimalisation and conversion to other bases In-Reply-To: <1454322513.41.0.794136944555.issue26256@psf.upfronthosting.co.za> Message-ID: <1549118434.13.0.432371448897.issue26256@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11639, 11640 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 09:40:45 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 02 Feb 2019 14:40:45 +0000 Subject: [issue26256] Fast decimalisation and conversion to other bases In-Reply-To: <1454322513.41.0.794136944555.issue26256@psf.upfronthosting.co.za> Message-ID: <1549118445.72.0.846171337363.issue26256@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11639, 11640, 11641 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 09:46:11 2019 From: report at bugs.python.org (Stefan Krah) Date: Sat, 02 Feb 2019 14:46:11 +0000 Subject: [issue26256] Fast decimalisation and conversion to other bases In-Reply-To: <1454322513.41.0.794136944555.issue26256@psf.upfronthosting.co.za> Message-ID: <1549118771.3.0.577770188694.issue26256@roundup.psfhosted.org> Stefan Krah added the comment: New changeset a2f4c4023314f69333d2e8cee68e316619f3d68e by Stefan Krah (Miss Islington (bot)) in branch '3.7': bpo-26256: Document algorithm speed for the Decimal module. (GH-4808) (#11736) https://github.com/python/cpython/commit/a2f4c4023314f69333d2e8cee68e316619f3d68e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 09:49:57 2019 From: report at bugs.python.org (Stefan Krah) Date: Sat, 02 Feb 2019 14:49:57 +0000 Subject: [issue26256] Fast decimalisation and conversion to other bases In-Reply-To: <1454322513.41.0.794136944555.issue26256@psf.upfronthosting.co.za> Message-ID: <1549118997.03.0.605411465839.issue26256@roundup.psfhosted.org> Change by Stefan Krah : ---------- assignee: docs at python -> skrah resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 11:13:54 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 16:13:54 +0000 Subject: [issue32560] [EASY C] inherit the py launcher's STARTUPINFO In-Reply-To: <1516051515.58.0.467229070634.issue32560@psf.upfronthosting.co.za> Message-ID: <1549124034.11.0.101001932527.issue32560@roundup.psfhosted.org> Steve Dower added the comment: Hi Shiva, sorry for not noticing your PR earlier. I have one question for Eryk, who may be able to answer more easily than I can: do we need to initialize cbSize before calling GetStartupInfoW()? The docs[1] don't seem to suggest it, and I can't look at the implementation of that API until Monday, but perhaps you know? 1: https://docs.microsoft.com/en-us/windows/desktop/api/processthreadsapi/nf-processthreadsapi-getstartupinfow ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 11:19:31 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 16:19:31 +0000 Subject: [issue33895] LoadLibraryExW called with GIL held can cause deadlock In-Reply-To: <1529318701.15.0.56676864532.issue33895@psf.upfronthosting.co.za> Message-ID: <1549124371.07.0.655943363082.issue33895@roundup.psfhosted.org> Steve Dower added the comment: Sorry for the delay on this. I've approved the PR and restarted the CI systems to make sure it's all okay. I agree that many of these cases no longer have to dynamically load the functions, but that should be fixed separately. ---------- versions: -Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 11:22:57 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 16:22:57 +0000 Subject: [issue33316] Windows: PyThread_release_lock always fails In-Reply-To: <1524183536.18.0.682650639539.issue33316@psf.upfronthosting.co.za> Message-ID: <1549124577.99.0.703212490554.issue33316@roundup.psfhosted.org> Steve Dower added the comment: New changeset 05e922136a3286893bd489a8f2ecfa0dba4da368 by Steve Dower (native-api) in branch 'master': bpo-33316: PyThread_release_lock always fails (GH-6541) https://github.com/python/cpython/commit/05e922136a3286893bd489a8f2ecfa0dba4da368 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 11:23:12 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 02 Feb 2019 16:23:12 +0000 Subject: [issue33316] Windows: PyThread_release_lock always fails In-Reply-To: <1524183536.18.0.682650639539.issue33316@psf.upfronthosting.co.za> Message-ID: <1549124592.39.0.849870220462.issue33316@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11642 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 11:23:20 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 02 Feb 2019 16:23:20 +0000 Subject: [issue33316] Windows: PyThread_release_lock always fails In-Reply-To: <1524183536.18.0.682650639539.issue33316@psf.upfronthosting.co.za> Message-ID: <1549124600.02.0.4864568455.issue33316@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11642, 11643 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 11:23:26 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 02 Feb 2019 16:23:26 +0000 Subject: [issue33316] Windows: PyThread_release_lock always fails In-Reply-To: <1524183536.18.0.682650639539.issue33316@psf.upfronthosting.co.za> Message-ID: <1549124606.76.0.641637967931.issue33316@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11642, 11643, 11644 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 11:26:41 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 16:26:41 +0000 Subject: [issue33316] Windows: PyThread_release_lock always fails In-Reply-To: <1524183536.18.0.682650639539.issue33316@psf.upfronthosting.co.za> Message-ID: <1549124801.48.0.0423122875051.issue33316@roundup.psfhosted.org> Change by Steve Dower : ---------- stage: patch review -> backport needed versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 11:33:43 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 16:33:43 +0000 Subject: [issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character In-Reply-To: <1188943421.22.0.776458935296.issue1104@psf.upfronthosting.co.za> Message-ID: <1549125223.14.0.384670967555.issue1104@roundup.psfhosted.org> Steve Dower added the comment: I resolved some conflicts and will merge this once CI completes. If the backport to 2.7 isn't automatic then it may wait until someone else comes in to do it. ---------- assignee: loewis -> steve.dower versions: +Python 3.7, Python 3.8 -Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 11:35:33 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 16:35:33 +0000 Subject: [issue35862] Change the environment for a new process In-Reply-To: <1548877516.06.0.747468813802.issue35862@roundup.psfhosted.org> Message-ID: <1549125333.79.0.298205815726.issue35862@roundup.psfhosted.org> Steve Dower added the comment: Among other things, the version of the C runtime you were using on that old system probably has its own set of bugs that have since been resolved. Thanks for reporting the issue, though! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 11:45:52 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 02 Feb 2019 16:45:52 +0000 Subject: [issue33316] Windows: PyThread_release_lock always fails In-Reply-To: <1524183536.18.0.682650639539.issue33316@psf.upfronthosting.co.za> Message-ID: <1549125952.99.0.908617464605.issue33316@roundup.psfhosted.org> miss-islington added the comment: New changeset c851dfc99b28c7335d42abd8250bb77c11ce23c0 by Miss Islington (bot) in branch '3.7': bpo-33316: PyThread_release_lock always fails (GH-6541) https://github.com/python/cpython/commit/c851dfc99b28c7335d42abd8250bb77c11ce23c0 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 12:13:25 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 17:13:25 +0000 Subject: [issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character In-Reply-To: <1188943421.22.0.776458935296.issue1104@psf.upfronthosting.co.za> Message-ID: <1549127605.89.0.445284921714.issue1104@roundup.psfhosted.org> Steve Dower added the comment: New changeset 2de576e16d42ce43698d384d0dd46ba6cf165424 by Steve Dower (Tzu-ping Chung) in branch 'master': bpo-1104: msilib.SummaryInfo.GetProperty() truncates the string by one character (GH-4517) https://github.com/python/cpython/commit/2de576e16d42ce43698d384d0dd46ba6cf165424 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 12:13:44 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 17:13:44 +0000 Subject: [issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character In-Reply-To: <1188943421.22.0.776458935296.issue1104@psf.upfronthosting.co.za> Message-ID: <1549127605.89.0.445284921714.issue1104@roundup.psfhosted.org> Steve Dower added the comment: New changeset 2de576e16d42ce43698d384d0dd46ba6cf165424 by Steve Dower (Tzu-ping Chung) in branch 'master': bpo-1104: msilib.SummaryInfo.GetProperty() truncates the string by one character (GH-4517) https://github.com/python/cpython/commit/2de576e16d42ce43698d384d0dd46ba6cf165424 ---------- pull_requests: +11645 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 12:13:45 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 17:13:45 +0000 Subject: [issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character In-Reply-To: <1188943421.22.0.776458935296.issue1104@psf.upfronthosting.co.za> Message-ID: <1549127605.89.0.445284921714.issue1104@roundup.psfhosted.org> Steve Dower added the comment: New changeset 2de576e16d42ce43698d384d0dd46ba6cf165424 by Steve Dower (Tzu-ping Chung) in branch 'master': bpo-1104: msilib.SummaryInfo.GetProperty() truncates the string by one character (GH-4517) https://github.com/python/cpython/commit/2de576e16d42ce43698d384d0dd46ba6cf165424 ---------- pull_requests: +11645, 11646 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 12:13:49 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 17:13:49 +0000 Subject: [issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character In-Reply-To: <1188943421.22.0.776458935296.issue1104@psf.upfronthosting.co.za> Message-ID: <1549127605.89.0.445284921714.issue1104@roundup.psfhosted.org> Steve Dower added the comment: New changeset 2de576e16d42ce43698d384d0dd46ba6cf165424 by Steve Dower (Tzu-ping Chung) in branch 'master': bpo-1104: msilib.SummaryInfo.GetProperty() truncates the string by one character (GH-4517) https://github.com/python/cpython/commit/2de576e16d42ce43698d384d0dd46ba6cf165424 ---------- pull_requests: +11645, 11646, 11647, 11648 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 12:13:47 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 17:13:47 +0000 Subject: [issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character In-Reply-To: <1188943421.22.0.776458935296.issue1104@psf.upfronthosting.co.za> Message-ID: <1549127605.89.0.445284921714.issue1104@roundup.psfhosted.org> Steve Dower added the comment: New changeset 2de576e16d42ce43698d384d0dd46ba6cf165424 by Steve Dower (Tzu-ping Chung) in branch 'master': bpo-1104: msilib.SummaryInfo.GetProperty() truncates the string by one character (GH-4517) https://github.com/python/cpython/commit/2de576e16d42ce43698d384d0dd46ba6cf165424 ---------- pull_requests: +11645, 11646, 11647 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 12:14:56 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 17:14:56 +0000 Subject: [issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character In-Reply-To: <1188943421.22.0.776458935296.issue1104@psf.upfronthosting.co.za> Message-ID: <1549127696.21.0.195293096755.issue1104@roundup.psfhosted.org> Steve Dower added the comment: As expected, the 2.7 backport needs more work. Leaving this open for anyone who wants to handle it. I'll happily click merge for you if CI passes. ---------- stage: patch review -> backport needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 12:15:27 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 17:15:27 +0000 Subject: [issue33316] Windows: PyThread_release_lock always fails In-Reply-To: <1524183536.18.0.682650639539.issue33316@psf.upfronthosting.co.za> Message-ID: <1549127727.78.0.564408730095.issue33316@roundup.psfhosted.org> Change by Steve Dower : ---------- assignee: -> steve.dower resolution: -> fixed stage: backport needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 12:16:44 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 17:16:44 +0000 Subject: [issue33895] LoadLibraryExW called with GIL held can cause deadlock In-Reply-To: <1529318701.15.0.56676864532.issue33895@psf.upfronthosting.co.za> Message-ID: <1549127804.97.0.563269600916.issue33895@roundup.psfhosted.org> Steve Dower added the comment: New changeset 4860f01ac0f07cdc8fc0cc27c33f5a64e5cfec9f by Steve Dower (Tony Roberts) in branch 'master': bpo-33895: Relase GIL while calling functions that acquire Windows loader lock (GH-7789) https://github.com/python/cpython/commit/4860f01ac0f07cdc8fc0cc27c33f5a64e5cfec9f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 12:36:52 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 02 Feb 2019 17:36:52 +0000 Subject: [issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character In-Reply-To: <1188943421.22.0.776458935296.issue1104@psf.upfronthosting.co.za> Message-ID: <1549129012.7.0.778523519316.issue1104@roundup.psfhosted.org> miss-islington added the comment: New changeset 56f84117a766d21045349f0217ce740831aef0dc by Miss Islington (bot) in branch '3.7': bpo-1104: msilib.SummaryInfo.GetProperty() truncates the string by one character (GH-4517) https://github.com/python/cpython/commit/56f84117a766d21045349f0217ce740831aef0dc ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 12:57:43 2019 From: report at bugs.python.org (Stefan Krah) Date: Sat, 02 Feb 2019 17:57:43 +0000 Subject: [issue35845] Can't read a F-contiguous memoryview in physical order In-Reply-To: <1548708697.36.0.695790780311.issue35845@roundup.psfhosted.org> Message-ID: <1549130263.45.0.679618619761.issue35845@roundup.psfhosted.org> Stefan Krah added the comment: New changeset d08ea70464cb8a1f86134dcb4a5c2eac1a02bf1a by Stefan Krah in branch 'master': bpo-35845: Add order={'C', 'F', 'A'} parameter to memoryview.tobytes(). (#11730) https://github.com/python/cpython/commit/d08ea70464cb8a1f86134dcb4a5c2eac1a02bf1a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 13:05:49 2019 From: report at bugs.python.org (Eryk Sun) Date: Sat, 02 Feb 2019 18:05:49 +0000 Subject: [issue32560] [EASY C] inherit the py launcher's STARTUPINFO In-Reply-To: <1516051515.58.0.467229070634.issue32560@psf.upfronthosting.co.za> Message-ID: <1549130749.25.0.475719799788.issue32560@roundup.psfhosted.org> Eryk Sun added the comment: It should be fine. If the docs don't require initializing cb, we can assume it's done for us. For example, msvcrt.dll calls GetStartupInfo without initializing this field: 0:000> kc 3 Call Site KERNELBASE!GetStartupInfoW msvcrt!ioinit msvcrt!__CRTDLL_INIT In x64, the first argument (lpStartupInfo) is in rcx. We see the DWORD (dd) value of cb is initially 0: 0:000> dd @rcx l1 00000094`25ddefd0 00000000 Continue to the ret[urn] instruction via pt and check that the returned value of cb is sizeof(*lpStartupInfo): 0:000> pt KERNELBASE!GetStartupInfoW+0xb2: 00007fff`8ae41282 c3 ret 0:000> dd 94`25ddefd0 l1 00000094`25ddefd0 00000068 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 13:17:33 2019 From: report at bugs.python.org (Eryk Sun) Date: Sat, 02 Feb 2019 18:17:33 +0000 Subject: [issue32560] [EASY C] inherit the py launcher's STARTUPINFO In-Reply-To: <1516051515.58.0.467229070634.issue32560@psf.upfronthosting.co.za> Message-ID: <1549131453.11.0.777643369504.issue32560@roundup.psfhosted.org> Eryk Sun added the comment: Oops, I forgot the check: 0:000> ?? sizeof(test!_STARTUPINFOW) unsigned int64 0x68 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 13:19:24 2019 From: report at bugs.python.org (Stefan Krah) Date: Sat, 02 Feb 2019 18:19:24 +0000 Subject: [issue35686] BufferError with memory.release() In-Reply-To: <1546967000.66.0.594887800159.issue35686@roundup.psfhosted.org> Message-ID: <1549131564.22.0.912417736911.issue35686@roundup.psfhosted.org> Stefan Krah added the comment: Eryk Sun: Yes, the behavior is technically not guaranteed. I'm not sure about memoryview(x, start, stop, step) but I'll keep it in mind. Thomas Waldmann: > do you think this is as good as it gets for this kind of code? I guess so, there's a lot going on in that code fragment. ---------- components: +Interpreter Core resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 13:53:57 2019 From: report at bugs.python.org (Steven Winfield) Date: Sat, 02 Feb 2019 18:53:57 +0000 Subject: [issue34691] _contextvars missing in xmaster branch Windows build? In-Reply-To: <1536980580.92.0.956365154283.issue34691@psf.upfronthosting.co.za> Message-ID: <1549133637.88.0.877711749735.issue34691@roundup.psfhosted.org> Steven Winfield added the comment: (Just updating the issue to note that Python 3.7 is similarly affected) ---------- nosy: +steven.winfield versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 13:59:06 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 18:59:06 +0000 Subject: [issue33895] LoadLibraryExW called with GIL held can cause deadlock In-Reply-To: <1529318701.15.0.56676864532.issue33895@psf.upfronthosting.co.za> Message-ID: <1549133946.95.0.488370180801.issue33895@roundup.psfhosted.org> Change by Steve Dower : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 13:59:58 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 18:59:58 +0000 Subject: [issue32560] [EASY C] inherit the py launcher's STARTUPINFO In-Reply-To: <1516051515.58.0.467229070634.issue32560@psf.upfronthosting.co.za> Message-ID: <1549133998.09.0.166721758537.issue32560@roundup.psfhosted.org> Steve Dower added the comment: Great, thanks. I'll go ahead and merge. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 14:21:09 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 02 Feb 2019 19:21:09 +0000 Subject: [issue32560] [EASY C] inherit the py launcher's STARTUPINFO In-Reply-To: <1516051515.58.0.467229070634.issue32560@psf.upfronthosting.co.za> Message-ID: <1549135269.07.0.0460376648785.issue32560@roundup.psfhosted.org> miss-islington added the comment: New changeset cb0904762681031edc50f9d7d7ef48cffcf96d9a by Miss Islington (bot) (Shiva Saxena) in branch 'master': bpo-32560: inherit the py launcher's STARTUPINFO (GH-9000) https://github.com/python/cpython/commit/cb0904762681031edc50f9d7d7ef48cffcf96d9a ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 14:21:20 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 02 Feb 2019 19:21:20 +0000 Subject: [issue32560] [EASY C] inherit the py launcher's STARTUPINFO In-Reply-To: <1516051515.58.0.467229070634.issue32560@psf.upfronthosting.co.za> Message-ID: <1549135280.12.0.289278090023.issue32560@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11649 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 14:21:30 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 02 Feb 2019 19:21:30 +0000 Subject: [issue32560] [EASY C] inherit the py launcher's STARTUPINFO In-Reply-To: <1516051515.58.0.467229070634.issue32560@psf.upfronthosting.co.za> Message-ID: <1549135290.74.0.0311849999983.issue32560@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11649, 11650 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 14:21:41 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 02 Feb 2019 19:21:41 +0000 Subject: [issue32560] [EASY C] inherit the py launcher's STARTUPINFO In-Reply-To: <1516051515.58.0.467229070634.issue32560@psf.upfronthosting.co.za> Message-ID: <1549135301.61.0.778509085638.issue32560@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11649, 11650, 11651 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 14:22:37 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 19:22:37 +0000 Subject: [issue32560] [EASY C] inherit the py launcher's STARTUPINFO In-Reply-To: <1516051515.58.0.467229070634.issue32560@psf.upfronthosting.co.za> Message-ID: <1549135357.82.0.500762683809.issue32560@roundup.psfhosted.org> Change by Steve Dower : ---------- nosy: -miss-islington resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 14:38:18 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 02 Feb 2019 19:38:18 +0000 Subject: [issue32560] [EASY C] inherit the py launcher's STARTUPINFO In-Reply-To: <1516051515.58.0.467229070634.issue32560@psf.upfronthosting.co.za> Message-ID: <1549136298.87.0.334966763624.issue32560@roundup.psfhosted.org> miss-islington added the comment: New changeset 04b2a5eedac7ac0fecdafce1bda1028ee55e2aac by Miss Islington (bot) in branch '3.7': bpo-32560: inherit the py launcher's STARTUPINFO (GH-9000) https://github.com/python/cpython/commit/04b2a5eedac7ac0fecdafce1bda1028ee55e2aac ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 15:51:47 2019 From: report at bugs.python.org (Eryk Sun) Date: Sat, 02 Feb 2019 20:51:47 +0000 Subject: [issue29734] os.stat handle leak In-Reply-To: <1488799617.7.0.144245331277.issue29734@psf.upfronthosting.co.za> Message-ID: <1549140707.32.0.841007676022.issue29734@roundup.psfhosted.org> Eryk Sun added the comment: Steve, can you review and merge PR 740? Mark updated it to fix the handle leaks in win32_xstat_impl as mentioned in my previous message. They're unlikely but still should be fixed. In particular, iIt's unlikely that win32_get_reparse_tag (i.e. FSCTL_GET_REPARSE_POINT) will fail, but not quite as unlikely that get_target_path (i.e. GetFinalPathNameByHandleW) will fail (e.g. it will fail if the target is on an ImDisk ramdisk). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 16:07:58 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 21:07:58 +0000 Subject: [issue29734] os.stat handle leak In-Reply-To: <1488799617.7.0.144245331277.issue29734@psf.upfronthosting.co.za> Message-ID: <1549141678.96.0.166095424472.issue29734@roundup.psfhosted.org> Steve Dower added the comment: We certainly shouldn't be calling CloseHandle on a parameter like this anyway, so the change looks good to me. However, I notice that we don't necessarily preserve GetLastError() throughout here, so perhaps we ought to consider changing the return value interpretation at some point? (e.g. CloseHandle() may change it, and so we lose the actual error) That can be a future task though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 16:08:25 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 21:08:25 +0000 Subject: [issue29734] os.stat handle leak In-Reply-To: <1488799617.7.0.144245331277.issue29734@psf.upfronthosting.co.za> Message-ID: <1549141705.83.0.691971718482.issue29734@roundup.psfhosted.org> Steve Dower added the comment: New changeset b82bfac4369c0429e562a834b3752e66c4821eab by Steve Dower (Mark Becwar) in branch 'master': bpo-29734: nt._getfinalpathname handle leak (GH-740) https://github.com/python/cpython/commit/b82bfac4369c0429e562a834b3752e66c4821eab ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 16:08:35 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 21:08:35 +0000 Subject: [issue29734] os.stat handle leak In-Reply-To: <1488799617.7.0.144245331277.issue29734@psf.upfronthosting.co.za> Message-ID: <1549141705.83.0.691971718482.issue29734@roundup.psfhosted.org> Steve Dower added the comment: New changeset b82bfac4369c0429e562a834b3752e66c4821eab by Steve Dower (Mark Becwar) in branch 'master': bpo-29734: nt._getfinalpathname handle leak (GH-740) https://github.com/python/cpython/commit/b82bfac4369c0429e562a834b3752e66c4821eab ---------- keywords: +patch pull_requests: +11652 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 16:08:37 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 02 Feb 2019 21:08:37 +0000 Subject: [issue29734] os.stat handle leak In-Reply-To: <1488799617.7.0.144245331277.issue29734@psf.upfronthosting.co.za> Message-ID: <1549141717.39.0.637363181124.issue29734@roundup.psfhosted.org> Change by miss-islington : ---------- keywords: +patch, patch pull_requests: +11652, 11653 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 16:17:48 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 21:17:48 +0000 Subject: [issue29734] os.stat handle leak In-Reply-To: <1488799617.7.0.144245331277.issue29734@psf.upfronthosting.co.za> Message-ID: <1549142268.94.0.936917476264.issue29734@roundup.psfhosted.org> Change by Steve Dower : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 16:29:10 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 02 Feb 2019 21:29:10 +0000 Subject: [issue29734] os.stat handle leak In-Reply-To: <1488799617.7.0.144245331277.issue29734@psf.upfronthosting.co.za> Message-ID: <1549142950.23.0.160361687648.issue29734@roundup.psfhosted.org> miss-islington added the comment: New changeset 63a69ef4a2390cea3e102498ac7eeeb5546e82b6 by Miss Islington (bot) in branch '3.7': bpo-29734: nt._getfinalpathname handle leak (GH-740) https://github.com/python/cpython/commit/63a69ef4a2390cea3e102498ac7eeeb5546e82b6 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 16:33:04 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 21:33:04 +0000 Subject: [issue34691] _contextvars missing in xmaster branch Windows build? In-Reply-To: <1536980580.92.0.956365154283.issue34691@psf.upfronthosting.co.za> Message-ID: <1549143184.07.0.603388038356.issue34691@roundup.psfhosted.org> Change by Steve Dower : ---------- assignee: -> steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 16:33:23 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 21:33:23 +0000 Subject: [issue34691] _contextvars missing in xmaster branch Windows build? In-Reply-To: <1536980580.92.0.956365154283.issue34691@psf.upfronthosting.co.za> Message-ID: <1549143203.62.0.0425237317141.issue34691@roundup.psfhosted.org> Change by Steve Dower : ---------- keywords: +patch pull_requests: +11654 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 16:33:39 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 21:33:39 +0000 Subject: [issue34691] _contextvars missing in xmaster branch Windows build? In-Reply-To: <1536980580.92.0.956365154283.issue34691@psf.upfronthosting.co.za> Message-ID: <1549143219.04.0.812097332942.issue34691@roundup.psfhosted.org> Change by Steve Dower : ---------- keywords: +patch, patch pull_requests: +11654, 11655 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 16:33:55 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 21:33:55 +0000 Subject: [issue34691] _contextvars missing in xmaster branch Windows build? In-Reply-To: <1536980580.92.0.956365154283.issue34691@psf.upfronthosting.co.za> Message-ID: <1549143235.38.0.472357470621.issue34691@roundup.psfhosted.org> Change by Steve Dower : ---------- keywords: +patch, patch, patch pull_requests: +11654, 11655, 11656 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 17:05:49 2019 From: report at bugs.python.org (Minmin Gong) Date: Sat, 02 Feb 2019 22:05:49 +0000 Subject: [issue35758] Disable x87 control word for MSVC ARM compiler In-Reply-To: <1547702162.77.0.571505556494.issue35758@roundup.psfhosted.org> Message-ID: <1549145149.77.0.115988933877.issue35758@roundup.psfhosted.org> Change by Minmin Gong : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 17:08:37 2019 From: report at bugs.python.org (Minmin Gong) Date: Sat, 02 Feb 2019 22:08:37 +0000 Subject: [issue35890] Cleanup some non-consistent API callings Message-ID: <1549145315.91.0.561945747798.issue35890@roundup.psfhosted.org> New submission from Minmin Gong : 1. Unicode version of Windows APIs are used in places, but not for GetVersionEx in Python/sysmodule.c 2. The wcstok_s is called on Windows in Modules/main.c and PC/launcher.c, but not in Python/pathconfig.c ---------- components: Windows messages: 334771 nosy: Minmin.Gong, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Cleanup some non-consistent API callings type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 17:09:45 2019 From: report at bugs.python.org (Minmin Gong) Date: Sat, 02 Feb 2019 22:09:45 +0000 Subject: [issue35890] Cleanup some non-consistent API callings In-Reply-To: <1549145315.91.0.561945747798.issue35890@roundup.psfhosted.org> Message-ID: <1549145385.37.0.727565986719.issue35890@roundup.psfhosted.org> Change by Minmin Gong : ---------- keywords: +patch pull_requests: +11658 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 17:09:54 2019 From: report at bugs.python.org (Minmin Gong) Date: Sat, 02 Feb 2019 22:09:54 +0000 Subject: [issue35890] Cleanup some non-consistent API callings In-Reply-To: <1549145315.91.0.561945747798.issue35890@roundup.psfhosted.org> Message-ID: <1549145394.76.0.859525215749.issue35890@roundup.psfhosted.org> Change by Minmin Gong : ---------- keywords: +patch, patch pull_requests: +11658, 11659 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 17:10:03 2019 From: report at bugs.python.org (Minmin Gong) Date: Sat, 02 Feb 2019 22:10:03 +0000 Subject: [issue35890] Cleanup some non-consistent API callings In-Reply-To: <1549145315.91.0.561945747798.issue35890@roundup.psfhosted.org> Message-ID: <1549145403.33.0.244030697422.issue35890@roundup.psfhosted.org> Change by Minmin Gong : ---------- keywords: +patch, patch, patch pull_requests: +11658, 11659, 11660 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 17:36:27 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 22:36:27 +0000 Subject: [issue34691] _contextvars missing in xmaster branch Windows build? In-Reply-To: <1536980580.92.0.956365154283.issue34691@psf.upfronthosting.co.za> Message-ID: <1549146987.05.0.162257187521.issue34691@roundup.psfhosted.org> Steve Dower added the comment: New changeset 4c70d9f79c9b371990c8e054ccde53f7ff15946b by Steve Dower in branch 'master': bpo-34691: Compile _contextvars module into main Python library (GH-11741) https://github.com/python/cpython/commit/4c70d9f79c9b371990c8e054ccde53f7ff15946b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 17:36:48 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 22:36:48 +0000 Subject: [issue34691] _contextvars missing in xmaster branch Windows build? In-Reply-To: <1536980580.92.0.956365154283.issue34691@psf.upfronthosting.co.za> Message-ID: <1549146987.05.0.162257187521.issue34691@roundup.psfhosted.org> Steve Dower added the comment: New changeset 4c70d9f79c9b371990c8e054ccde53f7ff15946b by Steve Dower in branch 'master': bpo-34691: Compile _contextvars module into main Python library (GH-11741) https://github.com/python/cpython/commit/4c70d9f79c9b371990c8e054ccde53f7ff15946b ---------- pull_requests: +11661 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 17:36:50 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 22:36:50 +0000 Subject: [issue34691] _contextvars missing in xmaster branch Windows build? In-Reply-To: <1536980580.92.0.956365154283.issue34691@psf.upfronthosting.co.za> Message-ID: <1549146987.05.0.162257187521.issue34691@roundup.psfhosted.org> Steve Dower added the comment: New changeset 4c70d9f79c9b371990c8e054ccde53f7ff15946b by Steve Dower in branch 'master': bpo-34691: Compile _contextvars module into main Python library (GH-11741) https://github.com/python/cpython/commit/4c70d9f79c9b371990c8e054ccde53f7ff15946b ---------- pull_requests: +11661, 11663 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 17:36:52 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 22:36:52 +0000 Subject: [issue34691] _contextvars missing in xmaster branch Windows build? In-Reply-To: <1536980580.92.0.956365154283.issue34691@psf.upfronthosting.co.za> Message-ID: <1549146987.05.0.162257187521.issue34691@roundup.psfhosted.org> Steve Dower added the comment: New changeset 4c70d9f79c9b371990c8e054ccde53f7ff15946b by Steve Dower in branch 'master': bpo-34691: Compile _contextvars module into main Python library (GH-11741) https://github.com/python/cpython/commit/4c70d9f79c9b371990c8e054ccde53f7ff15946b ---------- pull_requests: +11661, 11662, 11663 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 17:44:09 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 22:44:09 +0000 Subject: [issue35872] Creating venv from venv no longer works in 3.7.2 In-Reply-To: <1549010953.4.0.913686801166.issue35872@roundup.psfhosted.org> Message-ID: <1549147449.22.0.543328776639.issue35872@roundup.psfhosted.org> Steve Dower added the comment: This scenario should work, as running the other venv's redirector will update the variable. The nearly identical report in issue35873 is apparently launching "default" Python, but presumably without clearing the variable. Since I can't tell what's going wrong with the report in this bug, I'm going to focus on the other one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 17:48:41 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 22:48:41 +0000 Subject: [issue35299] LGHT0091: Duplicate symbol 'File:include_pyconfig.h' found In-Reply-To: <1542954685.4.0.788709270274.issue35299@psf.upfronthosting.co.za> Message-ID: <1549147721.31.0.18052687179.issue35299@roundup.psfhosted.org> Change by Steve Dower : ---------- keywords: +patch pull_requests: +11664 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 17:48:50 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 22:48:50 +0000 Subject: [issue35299] LGHT0091: Duplicate symbol 'File:include_pyconfig.h' found In-Reply-To: <1542954685.4.0.788709270274.issue35299@psf.upfronthosting.co.za> Message-ID: <1549147730.34.0.444944627114.issue35299@roundup.psfhosted.org> Change by Steve Dower : ---------- keywords: +patch, patch pull_requests: +11664, 11665 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 17:48:59 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 22:48:59 +0000 Subject: [issue35299] LGHT0091: Duplicate symbol 'File:include_pyconfig.h' found In-Reply-To: <1542954685.4.0.788709270274.issue35299@psf.upfronthosting.co.za> Message-ID: <1549147739.29.0.551074761146.issue35299@roundup.psfhosted.org> Change by Steve Dower : ---------- keywords: +patch, patch, patch pull_requests: +11664, 11665, 11666 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 17:49:23 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 22:49:23 +0000 Subject: [issue35873] Controlling venv from venv no longer works in 3.7.2 In-Reply-To: <1549011784.82.0.296319027076.issue35873@roundup.psfhosted.org> Message-ID: <1549147763.3.0.955710681128.issue35873@roundup.psfhosted.org> Steve Dower added the comment: So with the fix for multiprocessing, we currently rely on __PYVENV_LAUNCHER__ remaining set throughout the process. However, it may be better to add a "sys.base_executable" property instead and clear the __PYVENV_LAUNCHER__ variable once we've read it. Then we can set it again in multiprocessing and launch the base executable, and otherwise default to launching the redirector. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 17:54:44 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 02 Feb 2019 22:54:44 +0000 Subject: [issue34691] _contextvars missing in xmaster branch Windows build? In-Reply-To: <1536980580.92.0.956365154283.issue34691@psf.upfronthosting.co.za> Message-ID: <1549148084.76.0.797950892822.issue34691@roundup.psfhosted.org> miss-islington added the comment: New changeset 81eda28382168bfea48bb1a352954ea90aadd4ca by Miss Islington (bot) in branch '3.7': bpo-34691: Compile _contextvars module into main Python library (GH-11741) https://github.com/python/cpython/commit/81eda28382168bfea48bb1a352954ea90aadd4ca ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 18:04:11 2019 From: report at bugs.python.org (Eryk Sun) Date: Sat, 02 Feb 2019 23:04:11 +0000 Subject: [issue35872] Creating venv from venv no longer works in 3.7.2 In-Reply-To: <1549010953.4.0.913686801166.issue35872@roundup.psfhosted.org> Message-ID: <1549148651.27.0.133420291746.issue35872@roundup.psfhosted.org> Eryk Sun added the comment: > This scenario should work, as running the other venv's redirector > will update the variable. The order gets reversed. In the simple case where we have two launchers, the launcher for the nested virtual environment executes the launcher for the outer (creator) virtual environment, which executes the real python.exe. So Python sees the wrong value for __PYVENV_LAUNCHER__. For example, if I create env37_2 from env37_1, here's the result in env37_2: C:\>C:\Temp\test\env37_2\scripts\python.exe Python 3.7.2 (tags/v3.7.2:9a3ffc0492, Dec 23 2018, 23:09:28) [MSC v.1916 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, os >>> print(sys.executable) C:\Temp\Test\env37_1\scripts\python.exe >>> print(*sys.path, sep='\n') C:\Program Files\Python37\python37.zip C:\Program Files\Python37\DLLs C:\Program Files\Python37\lib C:\Program Files\Python37 C:\Temp\Test\env37_1 C:\Temp\Test\env37_1\lib\site-packages >>> print(os.environ['__PYVENV_LAUNCHER__']) C:\Temp\Test\env37_1\scripts\python.exe ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 18:07:23 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 23:07:23 +0000 Subject: [issue35872] Creating venv from venv no longer works in 3.7.2 In-Reply-To: <1549010953.4.0.913686801166.issue35872@roundup.psfhosted.org> Message-ID: <1549148843.08.0.0421280226056.issue35872@roundup.psfhosted.org> Steve Dower added the comment: You can't actually nest virtual environments, at least with venv - it ought to be configuring it all against the original environment. What is in your pyvenv.cfg files here? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 18:37:56 2019 From: report at bugs.python.org (Eryk Sun) Date: Sat, 02 Feb 2019 23:37:56 +0000 Subject: [issue35872] Creating venv from venv no longer works in 3.7.2 In-Reply-To: <1549010953.4.0.913686801166.issue35872@roundup.psfhosted.org> Message-ID: <1549150676.15.0.74097370328.issue35872@roundup.psfhosted.org> Eryk Sun added the comment: > You can't actually nest virtual environments, at least with venv Yes, they can't be nested in terms of inheriting site-packages. But the "home" value in this case references the creating environment, which hasn't changed from previous versions. It's the same in Linux. In my first message I suggested having the launcher resolve pyvenv.cfg files until it finds the real python.exe to execute (the first one with no pyvenv.cfg file), thus bypassing the intervening launchers. > What is in your pyvenv.cfg files here? They're as expected: C:\>type C:\Temp\test\env37_1\pyvenv.cfg home = C:\Program Files\Python37 include-system-site-packages = false version = 3.7.2 C:\>type C:\Temp\test\env37_2\pyvenv.cfg home = C:\Temp\Test\env37_1\scripts include-system-site-packages = false version = 3.7.2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 18:44:14 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 23:44:14 +0000 Subject: [issue35872] Creating venv from venv no longer works in 3.7.2 In-Reply-To: <1549010953.4.0.913686801166.issue35872@roundup.psfhosted.org> Message-ID: <1549151054.2.0.0782100729262.issue35872@roundup.psfhosted.org> Steve Dower added the comment: Is there any reason to not resolve the base executable on creation and make it relative to that? So the second pyvenv.cfg would have the same home directory as the first? My proposed fix for issue35873 (PR soon) is going to make this trivial. ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 18:55:09 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Feb 2019 23:55:09 +0000 Subject: [issue35299] LGHT0091: Duplicate symbol 'File:include_pyconfig.h' found In-Reply-To: <1542954685.4.0.788709270274.issue35299@psf.upfronthosting.co.za> Message-ID: <1549151709.24.0.13490288836.issue35299@roundup.psfhosted.org> Steve Dower added the comment: My PR fixes both issues properly, but adds a minor "feature" to distutils by making distutils.sysconfig.get_python_inc() potentially return a set of include paths (with os.path.pathsep separators). This is fully internal, so right now we know it'll only occur when building in the source tree on Windows, so I'm not concerned about it. It'd also work on any platform through an environment variable, which it is, but it looks like most people simply attach "-I" at the start and pass it to gcc (which again, since they're not on Windows, they're not going to hit the one case we know about). I'd rather do it properly than have a one-time hack just for this build scenario, and I certainly don't want to be copying files within the source tree. So I'm intending to go ahead with this design, but wanted to allow any interested parties to push back if they know of some reason that I don't. ---------- versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 19:00:44 2019 From: report at bugs.python.org (Steve Dower) Date: Sun, 03 Feb 2019 00:00:44 +0000 Subject: [issue35872] Creating venv from venv no longer works in 3.7.2 In-Reply-To: <1549010953.4.0.913686801166.issue35872@roundup.psfhosted.org> Message-ID: <1549152044.29.0.669610526728.issue35872@roundup.psfhosted.org> Change by Steve Dower : ---------- keywords: +patch pull_requests: +11667 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 19:00:57 2019 From: report at bugs.python.org (Steve Dower) Date: Sun, 03 Feb 2019 00:00:57 +0000 Subject: [issue35872] Creating venv from venv no longer works in 3.7.2 In-Reply-To: <1549010953.4.0.913686801166.issue35872@roundup.psfhosted.org> Message-ID: <1549152057.98.0.925870614309.issue35872@roundup.psfhosted.org> Change by Steve Dower : ---------- keywords: +patch, patch pull_requests: +11667, 11668 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 19:00:58 2019 From: report at bugs.python.org (Steve Dower) Date: Sun, 03 Feb 2019 00:00:58 +0000 Subject: [issue35873] Controlling venv from venv no longer works in 3.7.2 In-Reply-To: <1549011784.82.0.296319027076.issue35873@roundup.psfhosted.org> Message-ID: <1549152058.0.0.729768181019.issue35873@roundup.psfhosted.org> Change by Steve Dower : ---------- keywords: +patch pull_requests: +11670 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 19:01:07 2019 From: report at bugs.python.org (Steve Dower) Date: Sun, 03 Feb 2019 00:01:07 +0000 Subject: [issue35873] Controlling venv from venv no longer works in 3.7.2 In-Reply-To: <1549011784.82.0.296319027076.issue35873@roundup.psfhosted.org> Message-ID: <1549152067.8.0.477680241466.issue35873@roundup.psfhosted.org> Change by Steve Dower : ---------- keywords: +patch, patch pull_requests: +11670, 11671 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 19:01:11 2019 From: report at bugs.python.org (Steve Dower) Date: Sun, 03 Feb 2019 00:01:11 +0000 Subject: [issue35872] Creating venv from venv no longer works in 3.7.2 In-Reply-To: <1549010953.4.0.913686801166.issue35872@roundup.psfhosted.org> Message-ID: <1549152071.33.0.733951494446.issue35872@roundup.psfhosted.org> Change by Steve Dower : ---------- keywords: +patch, patch, patch pull_requests: +11667, 11668, 11669 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 19:06:06 2019 From: report at bugs.python.org (Steve Dower) Date: Sun, 03 Feb 2019 00:06:06 +0000 Subject: [issue34691] _contextvars missing in xmaster branch Windows build? In-Reply-To: <1536980580.92.0.956365154283.issue34691@psf.upfronthosting.co.za> Message-ID: <1549152366.18.0.822775704397.issue34691@roundup.psfhosted.org> Change by Steve Dower : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 19:07:20 2019 From: report at bugs.python.org (Steve Dower) Date: Sun, 03 Feb 2019 00:07:20 +0000 Subject: [issue35841] Datetime strftime() does not return correct week numbers for 2019 In-Reply-To: <1548678729.34.0.0402959484409.issue35841@roundup.psfhosted.org> Message-ID: <1549152440.53.0.381640145094.issue35841@roundup.psfhosted.org> Change by Steve Dower : ---------- nosy: -steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 19:25:31 2019 From: report at bugs.python.org (Steve Dower) Date: Sun, 03 Feb 2019 00:25:31 +0000 Subject: [issue35692] pathlib.Path.exists() on non-existent drive raises WinError instead of returning False In-Reply-To: <1547002815.07.0.33405132487.issue35692@roundup.psfhosted.org> Message-ID: <1549153531.8.0.378242494175.issue35692@roundup.psfhosted.org> Change by Steve Dower : ---------- keywords: +patch pull_requests: +11672 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 19:25:44 2019 From: report at bugs.python.org (Steve Dower) Date: Sun, 03 Feb 2019 00:25:44 +0000 Subject: [issue35692] pathlib.Path.exists() on non-existent drive raises WinError instead of returning False In-Reply-To: <1547002815.07.0.33405132487.issue35692@roundup.psfhosted.org> Message-ID: <1549153544.97.0.450865732907.issue35692@roundup.psfhosted.org> Change by Steve Dower : ---------- keywords: +patch, patch pull_requests: +11672, 11673 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 19:25:58 2019 From: report at bugs.python.org (Steve Dower) Date: Sun, 03 Feb 2019 00:25:58 +0000 Subject: [issue35692] pathlib.Path.exists() on non-existent drive raises WinError instead of returning False In-Reply-To: <1547002815.07.0.33405132487.issue35692@roundup.psfhosted.org> Message-ID: <1549153558.32.0.825786342554.issue35692@roundup.psfhosted.org> Change by Steve Dower : ---------- keywords: +patch, patch, patch pull_requests: +11672, 11673, 11674 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 19:26:12 2019 From: report at bugs.python.org (Steve Dower) Date: Sun, 03 Feb 2019 00:26:12 +0000 Subject: [issue35692] pathlib.Path.exists() on non-existent drive raises WinError instead of returning False In-Reply-To: <1547002815.07.0.33405132487.issue35692@roundup.psfhosted.org> Message-ID: <1549153572.09.0.322389840294.issue35692@roundup.psfhosted.org> Change by Steve Dower : ---------- assignee: -> steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 19:27:26 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 03 Feb 2019 00:27:26 +0000 Subject: [issue35642] _asynciomodule.c compiled in both pythoncore.vcxproj and _asyncio.vcxproj In-Reply-To: <1546452351.49.0.287032771837.issue35642@roundup.psfhosted.org> Message-ID: <1549153646.39.0.665770604507.issue35642@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11675 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 19:27:31 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 03 Feb 2019 00:27:31 +0000 Subject: [issue35642] _asynciomodule.c compiled in both pythoncore.vcxproj and _asyncio.vcxproj In-Reply-To: <1546452351.49.0.287032771837.issue35642@roundup.psfhosted.org> Message-ID: <1549153651.4.0.366798755803.issue35642@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11675, 11676 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 19:27:36 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 03 Feb 2019 00:27:36 +0000 Subject: [issue35642] _asynciomodule.c compiled in both pythoncore.vcxproj and _asyncio.vcxproj In-Reply-To: <1546452351.49.0.287032771837.issue35642@roundup.psfhosted.org> Message-ID: <1549153656.96.0.0748598551088.issue35642@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11675, 11676, 11677 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 19:28:18 2019 From: report at bugs.python.org (Steve Dower) Date: Sun, 03 Feb 2019 00:28:18 +0000 Subject: [issue35642] _asynciomodule.c compiled in both pythoncore.vcxproj and _asyncio.vcxproj In-Reply-To: <1546452351.49.0.287032771837.issue35642@roundup.psfhosted.org> Message-ID: <1549153698.31.0.690404398881.issue35642@roundup.psfhosted.org> Change by Steve Dower : ---------- versions: -Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 19:46:14 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 03 Feb 2019 00:46:14 +0000 Subject: [issue35642] _asynciomodule.c compiled in both pythoncore.vcxproj and _asyncio.vcxproj In-Reply-To: <1546452351.49.0.287032771837.issue35642@roundup.psfhosted.org> Message-ID: <1549154774.62.0.486342882138.issue35642@roundup.psfhosted.org> miss-islington added the comment: New changeset cba16b748c286261b5bc45e6ff3c26aea2373f43 by Miss Islington (bot) in branch '3.7': bpo-35642: Remove asynciomodule.c from pythoncore.vcxproj (GH-11410) https://github.com/python/cpython/commit/cba16b748c286261b5bc45e6ff3c26aea2373f43 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 20:02:25 2019 From: report at bugs.python.org (Steve Dower) Date: Sun, 03 Feb 2019 01:02:25 +0000 Subject: [issue35642] _asynciomodule.c compiled in both pythoncore.vcxproj and _asyncio.vcxproj In-Reply-To: <1546452351.49.0.287032771837.issue35642@roundup.psfhosted.org> Message-ID: <1549155745.99.0.127154834592.issue35642@roundup.psfhosted.org> Change by Steve Dower : ---------- assignee: -> steve.dower resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 21:16:00 2019 From: report at bugs.python.org (Eryk Sun) Date: Sun, 03 Feb 2019 02:16:00 +0000 Subject: [issue35872] Creating venv from venv no longer works in 3.7.2 In-Reply-To: <1549010953.4.0.913686801166.issue35872@roundup.psfhosted.org> Message-ID: <1549160160.44.0.8299835693.issue35872@roundup.psfhosted.org> Eryk Sun added the comment: > Is there any reason to not resolve the base executable on creation and > make it relative to that? So the second pyvenv.cfg would have the same > home directory as the first? I was trying to avoid changing the existing behavior of `home` from how it works in 3.6. Your solution will introduce a (probably minor) change, which may be for the best anyway. The computed argv0_path gets added to sys.path, which in the normal case is the installation directory, but it gets overridden by `home`. In 3.6, in the nested-create case, the argv0_path is the creating environment's Scripts directory. For example: C:\>type C:\Temp\test\env36_2\pyvenv.cfg home = C:\Temp\Test\env36_1\scripts include-system-site-packages = false version = 3.6.4 C:\>C:\Temp\test\env36_2\Scripts\python.exe -S Python 3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:54:40) [MSC v.1900 64 bit (AMD64)] on win32 >>> import sys >>> print(*sys.path, sep='\n') C:\Temp\test\env36_2\Scripts\python36.zip C:\Program Files\Python36\Lib\ C:\Program Files\Python36\DLLs\ C:\Temp\Test\env36_1\scripts I don't know why we add argv0_path to sys.path. If it's meant to be the directory of the (not necessarily real) executable, then the last path in the above example should be "C:\Temp\Test\env36_2\Scripts" instead of "env36_1\Scripts". If the argv0_path is meant to be the installation directory, as part of the standard library, then it should be "C:\Program Files\Python36". PR 11745 will make it consistently the latter for all virtual environments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 22:28:45 2019 From: report at bugs.python.org (Laurent Gautier) Date: Sun, 03 Feb 2019 03:28:45 +0000 Subject: [issue34778] Memoryview for column-major (f_contiguous) arrays from bytes impossible to achieve In-Reply-To: <1537725098.47.0.956365154283.issue34778@psf.upfronthosting.co.za> Message-ID: <1549164525.65.0.398566215949.issue34778@roundup.psfhosted.org> Laurent Gautier added the comment: > General support for strides in cast(), i.e. a zero-copy view for > non-contiguous arrays does not seem possible because buf.ptr is > moved around. Even NumPy does not support that: I'd be happy enough with zero-copy `cast()` of f-continguous arrays along with the parameter `shape`, as this makes interfacing with orginally-in-FORTRAN C libraries through ctypes or cffi possible (without having to write a C-extension). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 23:26:58 2019 From: report at bugs.python.org (Steve Dower) Date: Sun, 03 Feb 2019 04:26:58 +0000 Subject: [issue35890] Cleanup some non-consistent API callings In-Reply-To: <1549145315.91.0.561945747798.issue35890@roundup.psfhosted.org> Message-ID: <1549168018.08.0.766279090026.issue35890@roundup.psfhosted.org> Steve Dower added the comment: New changeset 8ebc6451f36fa213130c316199dbec5ad8a02163 by Steve Dower (Minmin Gong) in branch 'master': bpo-35890 : Fix some API calling consistency (GH-11742) https://github.com/python/cpython/commit/8ebc6451f36fa213130c316199dbec5ad8a02163 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 23:27:23 2019 From: report at bugs.python.org (Steve Dower) Date: Sun, 03 Feb 2019 04:27:23 +0000 Subject: [issue35890] Cleanup some non-consistent API callings In-Reply-To: <1549145315.91.0.561945747798.issue35890@roundup.psfhosted.org> Message-ID: <1549168043.45.0.541487688255.issue35890@roundup.psfhosted.org> Steve Dower added the comment: Thanks for the contribution! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 2 23:29:59 2019 From: report at bugs.python.org (Steve Dower) Date: Sun, 03 Feb 2019 04:29:59 +0000 Subject: [issue35872] Creating venv from venv no longer works in 3.7.2 In-Reply-To: <1549010953.4.0.913686801166.issue35872@roundup.psfhosted.org> Message-ID: <1549168199.78.0.938584128835.issue35872@roundup.psfhosted.org> Steve Dower added the comment: > I don't know why we add argv0_path to sys.path. My guess is that the idea was to be able to load the .pyd files we used to put alongside it, though we found out they weren't being loaded anyway. One potential side effect is that manually created .pth files may no longer have an effect, as those likely chain together just fine. But I don't think that's a likely scenario. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 00:58:57 2019 From: report at bugs.python.org (Ned Deily) Date: Sun, 03 Feb 2019 05:58:57 +0000 Subject: [issue35485] tkinter windows turn black while resized using Tk 8.6.9.1 on macOS In-Reply-To: <1544732559.26.0.788709270274.issue35485@psf.upfronthosting.co.za> Message-ID: <1549173537.93.0.683364607046.issue35485@roundup.psfhosted.org> Ned Deily added the comment: Since this isn't a Python issue and since the specific problems seen using python.org macOS Pythons have gone away by reverting to using Tk 8.6.8, there doesn't seem to be a good reason to leave this issue open, certainly not as a "deferred blocker". Keven Walzer is CCed on this so the Tk project is aware of the issues we saw with 8.6.9.1 and with core-8-6-branch as of 2018-12-24. At this point, I'm not inclined to do any more testing of Tk until there is a new release but anyone else is welcome to go at it. ---------- priority: deferred blocker -> resolution: -> third party stage: needs patch -> resolved status: open -> closed title: Mac: tkinter windows turn black while resized -> tkinter windows turn black while resized using Tk 8.6.9.1 on macOS _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 01:09:37 2019 From: report at bugs.python.org (Tzu-ping Chung) Date: Sun, 03 Feb 2019 06:09:37 +0000 Subject: [issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character In-Reply-To: <1188943421.22.0.776458935296.issue1104@psf.upfronthosting.co.za> Message-ID: <1549174177.21.0.338769346254.issue1104@roundup.psfhosted.org> Change by Tzu-ping Chung : ---------- pull_requests: +11678 stage: backport needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 01:09:56 2019 From: report at bugs.python.org (Tzu-ping Chung) Date: Sun, 03 Feb 2019 06:09:56 +0000 Subject: [issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character In-Reply-To: <1188943421.22.0.776458935296.issue1104@psf.upfronthosting.co.za> Message-ID: <1549174196.79.0.550324939104.issue1104@roundup.psfhosted.org> Change by Tzu-ping Chung : ---------- pull_requests: +11678, 11679 stage: backport needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 01:10:15 2019 From: report at bugs.python.org (Tzu-ping Chung) Date: Sun, 03 Feb 2019 06:10:15 +0000 Subject: [issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character In-Reply-To: <1188943421.22.0.776458935296.issue1104@psf.upfronthosting.co.za> Message-ID: <1549174215.97.0.458077409689.issue1104@roundup.psfhosted.org> Change by Tzu-ping Chung : ---------- pull_requests: +11678, 11679, 11680 stage: backport needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 01:10:37 2019 From: report at bugs.python.org (Tzu-ping Chung) Date: Sun, 03 Feb 2019 06:10:37 +0000 Subject: [issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character In-Reply-To: <1188943421.22.0.776458935296.issue1104@psf.upfronthosting.co.za> Message-ID: <1549174237.58.0.466706734112.issue1104@roundup.psfhosted.org> Change by Tzu-ping Chung : ---------- pull_requests: +11678, 11679, 11680, 11681 stage: backport needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 01:54:58 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 03 Feb 2019 06:54:58 +0000 Subject: [issue35884] Add variable access benchmark to Tools/Scripts In-Reply-To: <1549052380.12.0.716539002961.issue35884@roundup.psfhosted.org> Message-ID: <1549176898.59.0.633255514073.issue35884@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset f75d59e1a896115bd52f543a417c665d6edc331f by Raymond Hettinger in branch 'master': bpo-35884: Add variable access benchmarking script (GH-11725) https://github.com/python/cpython/commit/f75d59e1a896115bd52f543a417c665d6edc331f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 01:55:59 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 03 Feb 2019 06:55:59 +0000 Subject: [issue35884] Add variable access benchmark to Tools/Scripts In-Reply-To: <1549052380.12.0.716539002961.issue35884@roundup.psfhosted.org> Message-ID: <1549176959.16.0.236891583059.issue35884@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 05:02:45 2019 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 Feb 2019 10:02:45 +0000 Subject: [issue32627] Header dependent _uuid build failure on Fedora 27 In-Reply-To: <1516672443.95.0.467229070634.issue32627@psf.upfronthosting.co.za> Message-ID: <1549188165.93.0.539484448074.issue32627@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch pull_requests: +11682 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 05:02:56 2019 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 Feb 2019 10:02:56 +0000 Subject: [issue32627] Header dependent _uuid build failure on Fedora 27 In-Reply-To: <1516672443.95.0.467229070634.issue32627@psf.upfronthosting.co.za> Message-ID: <1549188176.1.0.656068829994.issue32627@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch, patch pull_requests: +11682, 11683 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 05:03:06 2019 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 Feb 2019 10:03:06 +0000 Subject: [issue32627] Header dependent _uuid build failure on Fedora 27 In-Reply-To: <1516672443.95.0.467229070634.issue32627@psf.upfronthosting.co.za> Message-ID: <1549188186.72.0.732404418036.issue32627@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch, patch, patch pull_requests: +11682, 11683, 11684 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 05:03:18 2019 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 Feb 2019 10:03:18 +0000 Subject: [issue32627] Header dependent _uuid build failure on Fedora 27 In-Reply-To: <1516672443.95.0.467229070634.issue32627@psf.upfronthosting.co.za> Message-ID: <1549188198.29.0.814612531112.issue32627@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch, patch, patch, patch pull_requests: +11682, 11683, 11684, 11685 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 05:40:24 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Sun, 03 Feb 2019 10:40:24 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1549190424.5.0.139160198618.issue35813@roundup.psfhosted.org> Ronald Oussoren added the comment: Was this merged too soon? This is new functionality without any docs and tests. I've also left review comments on the pull request. ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 07:46:46 2019 From: report at bugs.python.org (Wolfgang Langner) Date: Sun, 03 Feb 2019 12:46:46 +0000 Subject: [issue35706] Make it easier to use a venv with an embedded Python interpreter In-Reply-To: <1547129099.62.0.924394155356.issue35706@roundup.psfhosted.org> Message-ID: <1549198006.08.0.0155618819793.issue35706@roundup.psfhosted.org> Wolfgang Langner added the comment: I think this pep is related to the issue and could be a solution: https://www.python.org/dev/peps/pep-0582/ ---------- nosy: +tds333 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 08:59:57 2019 From: report at bugs.python.org (Julien Palard) Date: Sun, 03 Feb 2019 13:59:57 +0000 Subject: [issue35851] Make search result in online docs keep their position when search finishes In-Reply-To: <1548772807.63.0.497905321537.issue35851@roundup.psfhosted.org> Message-ID: <1549202397.3.0.764481995049.issue35851@roundup.psfhosted.org> Julien Palard added the comment: Hi Roel, I like the idea, but as xtreak told, it's a sphinx issue we cannot easy fix on our side, better fix it sphinx side. Would you please repoen it on the sphinx bug tracker at https://github.com/sphinx-doc/sphinx/issues? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 09:30:04 2019 From: report at bugs.python.org (PyScripter) Date: Sun, 03 Feb 2019 14:30:04 +0000 Subject: [issue35706] Make it easier to use a venv with an embedded Python interpreter In-Reply-To: <1547129099.62.0.924394155356.issue35706@roundup.psfhosted.org> Message-ID: <1549204204.02.0.244944870241.issue35706@roundup.psfhosted.org> PyScripter added the comment: I don't see how pep-0582 is related to embedded python. The solution is to check for the presence of pyvenv.cfg in PYTHONHOME and set up the system.path accordingly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 10:11:01 2019 From: report at bugs.python.org (Jason R. Coombs) Date: Sun, 03 Feb 2019 15:11:01 +0000 Subject: [issue35891] urllib.parse.splituser has no suitable replacement Message-ID: <1549206660.03.0.379337447594.issue35891@roundup.psfhosted.org> New submission from Jason R. Coombs : The removal of splituser (issue27485) has the undesirable effect of leaving the programmer without a suitable alternative. The deprecation warning states to use `urlparse` instead, but `urlparse` doesn't provide the access to the `credential` or `address` components of a URL. Consider for example: >>> import urllib.parse >>> url = 'https://user:password at host:port/path' >>> parsed = urllib.parse.urlparse(url) >>> urllib.parse.splituser(parsed.netloc) ('user:password', 'host:port') It's not readily obvious how one might get those two values, the credential and the address, from `parsed`. Sure, you can get `username` and `password`. You can get `hostname` and `port`. But if what you want is to remove the credential and keep the address, or extract the credential and pass it unchanged as a single string to something like an `_encode_auth` handler, that's no longer possible without some careful handling--because of possible None values, re-assembling a username/password into a colon-separated string is more complicated than simply doing a ':'.join. This recommendation and limitation led to issues in production code and ultimately the inline adoption of the deprecated function, [summarized here](https://github.com/pypa/setuptools/pull/1670). I believe if splituser is to be deprecated, the netloc should provide a suitable alternative - namely that a `urlparse` result should supply `address` and `userinfo`. Such functionality would make it easier to transition code that currently relies on splituser for more than to parse out the username and password. Even better would be for the urlparse result to support `_replace` operations on these attributes... so that one wouldn't have to construct a netloc just to construct a URL that replaces only some portion of the netloc, so one could do something like: >>> parsed = urllib.parse.urlparse(url) >>> without_userinfo = parsed._replace(userinfo=None).geturl() >>> alt_port = parsed._replace(port=443).geturl() I realize that because of the nesting of abstractions (namedtuple for the main parts), that maybe this technique doesn't extend nicely, so maybe the netloc itself should provide this extensibility for a usage something like this: >>> parsed = urllib.parse.urlparse(url) >>> without_userinfo = parsed._replace(netloc=parsed.netloc._replace(userinfo=None)).geturl() >>> alt_port = parsed._replace(netloc=parsed.netloc._replace(port=443)).geturl() It's not as elegant, but likely simpler to implement, with netloc being extended with a _replace method to support replacing segments of itself (and still immutable)... and is dramatically less error-prone than the status quo without splituser. In any case, I don't think it's suitable to leave it to the programmer to have to muddle around with their own URL parsing logic. urllib.parse should provide some help here. ---------- components: Library (Lib) messages: 334793 nosy: jason.coombs priority: normal severity: normal status: open title: urllib.parse.splituser has no suitable replacement type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 10:11:09 2019 From: report at bugs.python.org (Jason R. Coombs) Date: Sun, 03 Feb 2019 15:11:09 +0000 Subject: [issue35891] urllib.parse.splituser has no suitable replacement In-Reply-To: <1549206660.03.0.379337447594.issue35891@roundup.psfhosted.org> Message-ID: <1549206669.52.0.96247758158.issue35891@roundup.psfhosted.org> Change by Jason R. Coombs : ---------- versions: +Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 10:12:17 2019 From: report at bugs.python.org (Jason R. Coombs) Date: Sun, 03 Feb 2019 15:12:17 +0000 Subject: [issue27485] urllib.splitport -- is it official or not? In-Reply-To: <1468260123.51.0.000787877209911.issue27485@psf.upfronthosting.co.za> Message-ID: <1549206737.64.0.637743388672.issue27485@roundup.psfhosted.org> Jason R. Coombs added the comment: Please refer to issue35891 for a description of an important use-case broken by the planned removal of splituser. ---------- nosy: +jason.coombs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 10:33:34 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Sun, 03 Feb 2019 15:33:34 +0000 Subject: [issue12374] Execution model should explain compile vs definition vs execution time In-Reply-To: <1308582911.55.0.701954968644.issue12374@psf.upfronthosting.co.za> Message-ID: <1549208014.6.0.219535646164.issue12374@roundup.psfhosted.org> Cheryl Sabella added the comment: Hi Nick, Would you be able to update the link as http://svn.python.org/view/sandbox/trunk/userref/ODF/ isn't valid anymore? Have things changed even more since you created this issue or are you still interested in pursuing this? Thanks! ---------- nosy: +cheryl.sabella _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 13:51:27 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 03 Feb 2019 18:51:27 +0000 Subject: [issue35892] Fix awkwardness of statistics.mode() for multimodal datasets Message-ID: <1549219885.57.0.86866159357.issue35892@roundup.psfhosted.org> New submission from Raymond Hettinger : The current code for mode() does a good deal of extra work to support its two error outcomes (empty input and multimodal input). That latter case is informative but doesn't provide any reasonable way to find just one of those modes, where any of the most popular would suffice. This arises in nearest neighbor algorithms for example. I suggest adding an option to the API: def mode(seq, *, first_tie=False): if tie_goes_to_first: # CHOOSE FIRST x ? S | ? y ? S : x ? y ? count(y) > count(x) return return Counter(seq).most_common(1)[0][0] ... Use it like this: >>> data = 'ABBAC' >>> assert mode(data, first_tie=True) == 'A' With the current API, there is no reasonable way to get to 'A' from 'ABBAC'. Also, the new code path is much faster than the existing code path because it extracts only the 1 most common using min() rather than the n most common which has to sort the whole items() list. New path: O(n). Existing path: O(n log n). Note, the current API is somewhat awkward to use. In general, a user can't know in advance that the data only contains a single mode. Accordingly, every call to mode() has to be wrapped in a try-except. And if the user just wants one of those modal values, there is no way to get to it. See https://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.mode.html for comparison. There may be better names for the flag. "tie_goes_to_first_encountered" seemed a bit long though ;-) ---------- assignee: steven.daprano components: Library (Lib) messages: 334796 nosy: rhettinger, steven.daprano priority: normal severity: normal status: open title: Fix awkwardness of statistics.mode() for multimodal datasets type: behavior versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 14:18:19 2019 From: report at bugs.python.org (Ned Deily) Date: Sun, 03 Feb 2019 19:18:19 +0000 Subject: [issue35706] Make it easier to use a venv with an embedded Python interpreter In-Reply-To: <1547129099.62.0.924394155356.issue35706@roundup.psfhosted.org> Message-ID: <1549221499.07.0.0156122643604.issue35706@roundup.psfhosted.org> Change by Ned Deily : ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 15:19:18 2019 From: report at bugs.python.org (paul j3) Date: Sun, 03 Feb 2019 20:19:18 +0000 Subject: [issue35533] argparse standard error usage for exit / error In-Reply-To: <1545220030.92.0.788709270274.issue35533@psf.upfronthosting.co.za> Message-ID: <1549225158.5.0.487038068297.issue35533@roundup.psfhosted.org> Change by paul j3 : ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 15:51:17 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 03 Feb 2019 20:51:17 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1549227077.49.0.456534643874.issue35813@roundup.psfhosted.org> Antoine Pitrou added the comment: Yes, I think this was merged too soon. Davin, the convention is that we only merge completed work, not some work-in-progress. You already did this once in https://bugs.python.org/issue28053 . You still haven't completed that piece of work. I'm going to ask for this to be reverted. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 15:56:12 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Sun, 03 Feb 2019 20:56:12 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1549227372.92.0.380667759012.issue35813@roundup.psfhosted.org> Ronald Oussoren added the comment: FWIW I agree with reverting this pull request, the work is clearly not finished yet. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 16:04:44 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 03 Feb 2019 21:04:44 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1549227884.08.0.131788796619.issue35813@roundup.psfhosted.org> Antoine Pitrou added the comment: And to make things clear, I'm not saying anything about the functionality. Easier shared memory + multiprocessing is definitely an interesting endeavour (and a non-trivial one). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 16:10:13 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Sun, 03 Feb 2019 21:10:13 +0000 Subject: [issue35893] distutils fails to build extension on windows when it is a package.__init__ Message-ID: <1549228211.63.0.529262209714.issue35893@roundup.psfhosted.org> New submission from Ronald Oussoren : Python supports having a C extension for the the __init__ of a package (instead of having __init__.py). This works fine on Linux, but on Windows distutils fails to build the C extension because it assumes the entry point is named PyInit___init__ while importlib expects PyInit_*package* (for a package named *package*). When building the extension I get the following error: LINK : error LNK2001: unresolved external symbol PyInit___init__ build\temp.win32-3.7\Release\__init__.cp37-win32.lib : fatal error LNK1120: 1 unresolved externals The code below can be used to reproduce the issue. Setup.py (extracted from a larger setup.py, but should work...): from setuptools import setup, Extension extension3 = Extension("ext_package.__init__", sources=["init.c"]) setup( ext_modules=[extension3], ) Source code for the module (init.c): #include "Python.h" static PyModuleDef mod_def = { PyModuleDef_HEAD_INIT, "ext_package.__init__", NULL, 0, NULL, NULL, NULL, NULL, NULL }; PyObject* PyInit_ext_package(void) { return PyModule_Create(&mod_def); } P.S. I cannot easily debug this, I ran into this when testing one of my projects on AppVeyor and don't have a local Windows machine. ---------- components: Distutils, Windows messages: 334800 nosy: dstufft, eric.araujo, paul.moore, ronaldoussoren, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: distutils fails to build extension on windows when it is a package.__init__ type: behavior versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 16:18:54 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Sun, 03 Feb 2019 21:18:54 +0000 Subject: [issue35893] distutils fails to build extension on windows when it is a package.__init__ In-Reply-To: <1549228211.63.0.529262209714.issue35893@roundup.psfhosted.org> Message-ID: <1549228734.41.0.82224163032.issue35893@roundup.psfhosted.org> Ronald Oussoren added the comment: FWIW the project in question is modulegraph2 , which almost works on Windows, except for this issue and some incorrect code on my side that assumes virtualenv on Windows behaves the same as on POSIX w.r.t. the structure of virtual environments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 17:34:30 2019 From: report at bugs.python.org (Ned Deily) Date: Sun, 03 Feb 2019 22:34:30 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1549233270.48.0.114988399985.issue35813@roundup.psfhosted.org> Change by Ned Deily : ---------- nosy: -ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 18:22:56 2019 From: report at bugs.python.org (Ned Deily) Date: Sun, 03 Feb 2019 23:22:56 +0000 Subject: [issue35605] backported patch requires new sphinx, minimum sphinx version was not bumped In-Reply-To: <1546016436.32.0.942702382011.issue35605@roundup.psfhosted.org> Message-ID: <1549236176.57.0.535708865804.issue35605@roundup.psfhosted.org> Ned Deily added the comment: New changeset 9bacdce451618a5f0bf62cb1b6f966ebde0492c6 by Ned Deily (Anthony Sottile) in branch '3.6': [3.6] bpo-35605: Fix documentation build for sphinx<1.6 (GH-11368) https://github.com/python/cpython/commit/9bacdce451618a5f0bf62cb1b6f966ebde0492c6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 18:26:51 2019 From: report at bugs.python.org (Ned Deily) Date: Sun, 03 Feb 2019 23:26:51 +0000 Subject: [issue35605] backported patch requires new sphinx, minimum sphinx version was not bumped In-Reply-To: <1546016436.32.0.942702382011.issue35605@roundup.psfhosted.org> Message-ID: <1549236411.68.0.270934144897.issue35605@roundup.psfhosted.org> Ned Deily added the comment: I agree that this can go into 3.6. Thanks, everyone! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 19:20:20 2019 From: report at bugs.python.org (Ned Deily) Date: Mon, 04 Feb 2019 00:20:20 +0000 Subject: =?utf-8?q?=5Bissue35586=5D_Open_pyexpat_compilation=2C_Make_shows_error?= =?utf-8?b?77yIbWlzc2luZyBzZXBhcmF0b3LvvIk=?= In-Reply-To: <1545796783.34.0.712150888896.issue35586@roundup.psfhosted.org> Message-ID: <1549239620.54.0.137625706684.issue35586@roundup.psfhosted.org> Ned Deily added the comment: Sorry about the delay in responding. I am unable to reproduce the problem but I may be missing some important details. What platform were you attempting to build on? What was the exact path to the source directory? And, if you can still reproduce, could you attach a copy of the generated Makefile and the output from running it? ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 19:26:06 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 04 Feb 2019 00:26:06 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1549239966.21.0.449008928484.issue35813@roundup.psfhosted.org> Terry J. Reedy added the comment: I think there is also a license problem. posixshmem.c contains "Copyright 2012 Philip Semanchuk, 2018-2019 Davin Potts" Ronald commented "The only other files with a copyright attribute are parser, optparse and platform. I'd prefer to avoid adding new copyright attributes to stdlib modules." (turtle.py has a problematic copyright notice in the docstring.) I think we definitely should not add new copyright notices. Copyright notices are redundant: all contributors retain copyright in their contributions. Copyright notices are deceptive: 1. since they are rare, they imply that there is something special about a particular module and the listed authors; 2. even if a module were special, the notice becomes obsolete as soon as anyone else contributes to the module. Copyright notices are not needed: contributors authorize PSF to distribute the collective work under a rather liberal license. If anyone want to make a use of Python code not covered by that license, and wants to bypass PSF, they would have to look at git log and and git blame to find the relevant contributors. In this case, part of the work is attributed to Philip Semanchuk as a current copyright owner. According to https://bugs.python.org/user2567, he has not signed the contributor agreement, so his work should not have been merged until he has. Even if he had, he would have to specifically agree to his work being contributed. Sorry to be a grinch, but aside from anything else, I think this should be reverted until the legal question is clarified. Some of this might need discussion on pydev. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 3 21:16:11 2019 From: report at bugs.python.org (Davin Potts) Date: Mon, 04 Feb 2019 02:16:11 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1549246571.64.0.958220693868.issue35813@roundup.psfhosted.org> Davin Potts added the comment: This work is the result of ~1.5 years of development effort, much of it accomplished at the last two core dev sprints. The code behind it has been stable since September 2018 and tested as an independently installable package by multiple people. I was encouraged by Lukasz, Yury, and others to check in this code early, not waiting for tests and docs, in order to both solicit more feedback and provide for broader testing. I understand that doing such a thing is not at all a novelty. Thankfully it is doing that -- I hope that feedback remains constructive and supportive. There are some tests to be found in a branch (enh-tests-shmem) of github.com/applio/cpython which I think should become more comprehensive before inclusion. Temporarily deferring and not including them as part of the first alpha should reduce the complexity of that release. Regarding the BSD license on the C code being adopted, my conversations with Brett and subsequently Van have not raised concerns, far from it -- there is a process which is being followed to the letter. If there are other reasons to object to the thoughtful adoption of code licensed like this one, that deserves a decoupled and larger discussion first. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 00:05:49 2019 From: report at bugs.python.org (Nathaniel Smith) Date: Mon, 04 Feb 2019 05:05:49 +0000 Subject: [issue35894] Apparent regression in 3.8-dev: 'TypeError: required field "type_ignores" missing from Module' Message-ID: <1549256747.48.0.424452103214.issue35894@roundup.psfhosted.org> New submission from Nathaniel Smith : Travis provides a "3.8-dev" python, which is updated regularly to track cpython master. When running our tests on this Python, specifically version python: 3.8.0a0 (heads/master:f75d59e, Feb 3 2019, 07:27:24) we just started getting tracebacks: TypeError Traceback (most recent call last) /opt/python/3.8-dev/lib/python3.8/codeop.py in __call__(self, source, filename, symbol) 131 132 def __call__(self, source, filename, symbol): --> 133 codeob = compile(source, filename, symbol, self.flags, 1) 134 for feature in _features: 135 if codeob.co_flags & feature.compiler_flag: TypeError: required field "type_ignores" missing from Module (Full log: https://travis-ci.org/python-trio/trio/jobs/488312057) Grepping through git diffs for 'type_ignores' suggests that this is probably related to bpo-35766. I haven't dug into this in detail, but it seems to be happening on tests using IPython. The lack of further traceback suggests to me that the exception is happening inside IPython's guts (it has some hacks to try to figure out which parts of the traceback are in user-defined code versus its own internal code, and tries to hide the latter when printing tracebacks). The crash is in codeop.Compile.__call__, and IPython does create ast.Module objects and pass them to codeop.Compile.__call__: https://github.com/ipython/ipython/blob/512d47340c09d184e20811ca46aaa2f862bcbafe/IPython/core/interactiveshell.py#L3199-L3200 Maybe ast.Module needs to default-initialize the new type_ignores field, or compile() needs to be tolerant of it being missing? ---------- messages: 334807 nosy: benjamin.peterson, brett.cannon, gvanrossum, njs, yselivanov priority: normal severity: normal status: open title: Apparent regression in 3.8-dev: 'TypeError: required field "type_ignores" missing from Module' type: behavior versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 00:32:42 2019 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 04 Feb 2019 05:32:42 +0000 Subject: [issue35894] Apparent regression in 3.8-dev: 'TypeError: required field "type_ignores" missing from Module' In-Reply-To: <1549256747.48.0.424452103214.issue35894@roundup.psfhosted.org> Message-ID: <1549258362.75.0.95656763056.issue35894@roundup.psfhosted.org> Guido van Rossum added the comment: Yeah, this definitely changed. When we updated typed_ast to Python 3.7 recently, the mypy project looked into making certain arguments to AST certain nodes optional, but the code responsible for those arguments is too weird to easily make that work (it's all generated), so we decided to leave it alone. IMO the AST in general can't be considered a stable API like other stdlib APIs, since when the syntax changes, well, the AST changes, and sometimes that means that nodes change. For *consumers* of the AST we generally manage to keep things backwards compatible, but for producers, there just is no guarantee. I think the best way forward is for your code to check the Python version and if it's >= 3.8, pass an empty list as the second argument to Module(). If you look at the changes to Python.asdl in the PR you found, you'll see what other nodes have changed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 01:44:35 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 04 Feb 2019 06:44:35 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1549262675.77.0.60167907323.issue35813@roundup.psfhosted.org> Ronald Oussoren added the comment: David, I don't agree with merging at this point. The lack of documentation makes it hard to ask for more feedback and broader testing, because people won't know how to use the library and provide constructive feedback (that's why my review comments on GitHub are mostly nitpicking). Furthermore, distributing this as a package on PyPI is much better way to solicit further testing and feedback, because then it can be used right now instead of having to wait for a release. Releasing on PyPI is feasible for this new functionality because it is a standalone library. It would be better to revert this changeset until it is much closer to finished and there has been time for better code review. BTW. My comment about copyright on the pull request was about the __copyright__ attribute of the C extension, that is rarely used in the stdlib and is IMHO something to avoid. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 02:06:27 2019 From: report at bugs.python.org (Nathaniel Smith) Date: Mon, 04 Feb 2019 07:06:27 +0000 Subject: [issue35894] Apparent regression in 3.8-dev: 'TypeError: required field "type_ignores" missing from Module' In-Reply-To: <1549256747.48.0.424452103214.issue35894@roundup.psfhosted.org> Message-ID: <1549263987.88.0.766281841448.issue35894@roundup.psfhosted.org> Nathaniel Smith added the comment: Oh, that's not my code, it's the core of IPython's REPL :-). I just filed a bug with them, referencing this one: https://github.com/ipython/ipython/issues/11590 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 02:08:22 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 04 Feb 2019 07:08:22 +0000 Subject: [issue35692] pathlib.Path.exists() on non-existent drive raises WinError instead of returning False In-Reply-To: <1547002815.07.0.33405132487.issue35692@roundup.psfhosted.org> Message-ID: <1549264102.98.0.445911509376.issue35692@roundup.psfhosted.org> Steve Dower added the comment: New changeset 2f6fae6e510dba653391cb510a2aca8322eec03b by Steve Dower in branch 'master': bpo-35692: pathlib no longer raises when checking file and directory existence on drives that are not ready (GH-11746) https://github.com/python/cpython/commit/2f6fae6e510dba653391cb510a2aca8322eec03b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 02:08:47 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 04 Feb 2019 07:08:47 +0000 Subject: [issue35692] pathlib.Path.exists() on non-existent drive raises WinError instead of returning False In-Reply-To: <1547002815.07.0.33405132487.issue35692@roundup.psfhosted.org> Message-ID: <1549264127.65.0.759842930194.issue35692@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11686 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 02:09:01 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 04 Feb 2019 07:09:01 +0000 Subject: [issue35692] pathlib.Path.exists() on non-existent drive raises WinError instead of returning False In-Reply-To: <1547002815.07.0.33405132487.issue35692@roundup.psfhosted.org> Message-ID: <1549264141.59.0.781155902772.issue35692@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11686, 11687 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 02:09:14 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 04 Feb 2019 07:09:14 +0000 Subject: [issue35692] pathlib.Path.exists() on non-existent drive raises WinError instead of returning False In-Reply-To: <1547002815.07.0.33405132487.issue35692@roundup.psfhosted.org> Message-ID: <1549264154.34.0.909085589486.issue35692@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11686, 11687, 11688 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 02:19:40 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 04 Feb 2019 07:19:40 +0000 Subject: [issue35872] Creating venv from venv no longer works in 3.7.2 In-Reply-To: <1549010953.4.0.913686801166.issue35872@roundup.psfhosted.org> Message-ID: <1549264780.78.0.737017767965.issue35872@roundup.psfhosted.org> Steve Dower added the comment: New changeset a8474d025cab794257d2fd0bea67840779b9351f by Steve Dower in branch 'master': bpo-35872 and bpo-35873: Clears __PYVENV_LAUNCHER__ variable (GH-11745) https://github.com/python/cpython/commit/a8474d025cab794257d2fd0bea67840779b9351f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 02:19:56 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 04 Feb 2019 07:19:56 +0000 Subject: [issue35873] Controlling venv from venv no longer works in 3.7.2 In-Reply-To: <1549011784.82.0.296319027076.issue35873@roundup.psfhosted.org> Message-ID: <1549264796.1.0.969986465675.issue35873@roundup.psfhosted.org> Steve Dower added the comment: New changeset a8474d025cab794257d2fd0bea67840779b9351f by Steve Dower in branch 'master': bpo-35872 and bpo-35873: Clears __PYVENV_LAUNCHER__ variable (GH-11745) https://github.com/python/cpython/commit/a8474d025cab794257d2fd0bea67840779b9351f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 02:22:33 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 04 Feb 2019 07:22:33 +0000 Subject: [issue35872] Creating venv from venv no longer works in 3.7.2 In-Reply-To: <1549010953.4.0.913686801166.issue35872@roundup.psfhosted.org> Message-ID: <1549264953.16.0.899442618196.issue35872@roundup.psfhosted.org> Change by Steve Dower : ---------- pull_requests: +11689 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 02:22:45 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 04 Feb 2019 07:22:45 +0000 Subject: [issue35872] Creating venv from venv no longer works in 3.7.2 In-Reply-To: <1549010953.4.0.913686801166.issue35872@roundup.psfhosted.org> Message-ID: <1549264965.96.0.150530067555.issue35872@roundup.psfhosted.org> Change by Steve Dower : ---------- pull_requests: +11689, 11690 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 02:22:45 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 04 Feb 2019 07:22:45 +0000 Subject: [issue35873] Controlling venv from venv no longer works in 3.7.2 In-Reply-To: <1549011784.82.0.296319027076.issue35873@roundup.psfhosted.org> Message-ID: <1549264965.97.0.811370783515.issue35873@roundup.psfhosted.org> Change by Steve Dower : ---------- pull_requests: +11692 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 02:22:57 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 04 Feb 2019 07:22:57 +0000 Subject: [issue35872] Creating venv from venv no longer works in 3.7.2 In-Reply-To: <1549010953.4.0.913686801166.issue35872@roundup.psfhosted.org> Message-ID: <1549264977.29.0.58988162428.issue35872@roundup.psfhosted.org> Change by Steve Dower : ---------- pull_requests: +11689, 11690, 11691 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 02:27:39 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 04 Feb 2019 07:27:39 +0000 Subject: [issue35692] pathlib.Path.exists() on non-existent drive raises WinError instead of returning False In-Reply-To: <1547002815.07.0.33405132487.issue35692@roundup.psfhosted.org> Message-ID: <1549265259.98.0.0294392552692.issue35692@roundup.psfhosted.org> miss-islington added the comment: New changeset 69af4395a25481e9de4009c816b6d1f032a2d8eb by Miss Islington (bot) in branch '3.7': bpo-35692: pathlib no longer raises when checking file and directory existence on drives that are not ready (GH-11746) https://github.com/python/cpython/commit/69af4395a25481e9de4009c816b6d1f032a2d8eb ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 02:33:01 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 04 Feb 2019 07:33:01 +0000 Subject: [issue35706] Make it easier to use a venv with an embedded Python interpreter In-Reply-To: <1547129099.62.0.924394155356.issue35706@roundup.psfhosted.org> Message-ID: <1549265581.65.0.0700615572437.issue35706@roundup.psfhosted.org> Steve Dower added the comment: Py_Initialize() is not supposed to set it up. If you are embedding Python, you have to be responsible for configuring the paths that it uses - pyvenv.cfg is configuration for Python interactive, not the shared lib (using Windows terminology, it's configuration for python.exe but not python36.dll). Personally, I am 100% against letting an embedded runtime automatically pick up any settings from the environment. You don't know where they came from. That said, I'm also in favor of making it easy for embedders to imitate the interactive shell's configuration. Victor (nosied) and others are in the long process of updating embedded interpreter configuration to be easier to use, so adding him here as feedback, but I don't believe there is going to be a specific fix for this. Consider calling Py_SetPath before Py_Initialize to configure the search paths you want to use. ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 02:33:25 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 04 Feb 2019 07:33:25 +0000 Subject: [issue35692] pathlib.Path.exists() on non-existent drive raises WinError instead of returning False In-Reply-To: <1547002815.07.0.33405132487.issue35692@roundup.psfhosted.org> Message-ID: <1549265605.55.0.928892838969.issue35692@roundup.psfhosted.org> Change by Steve Dower : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 05:23:13 2019 From: report at bugs.python.org (Roel Schroeven) Date: Mon, 04 Feb 2019 10:23:13 +0000 Subject: [issue35851] Make search result in online docs keep their position when search finishes In-Reply-To: <1548772807.63.0.497905321537.issue35851@roundup.psfhosted.org> Message-ID: <1549275793.9.0.651940886806.issue35851@roundup.psfhosted.org> Roel Schroeven added the comment: Issue opened on the Sphinx bug tracker: https://github.com/sphinx-doc/sphinx/issues/6016 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 05:28:12 2019 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Mon, 04 Feb 2019 10:28:12 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1549276092.84.0.00538975633893.issue35813@roundup.psfhosted.org> ?ukasz Langa added the comment: @Davin, in what time can you fill in the missing tests and documentation? If this is something you finish do before alpha2, I'm inclined to leave the change in. As it stands, I missed the controversy yesterday as I was busy making my first release. So the merge *got released* in alpha1. I would prefer to fix the missing pieces forward instead of reverting and re-submitting which will only thrash blame and history at this point. FTR, I do agree with Antoine, Ronald and others that in the future such big changes should be as close to their ready state at merge time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 05:36:26 2019 From: report at bugs.python.org (Petr Viktorin) Date: Mon, 04 Feb 2019 10:36:26 +0000 Subject: [issue35810] Object Initialization Bug with Heap-allocated Types In-Reply-To: <1548275752.94.0.463880453345.issue35810@roundup.psfhosted.org> Message-ID: <1549276586.31.0.437366272792.issue35810@roundup.psfhosted.org> Petr Viktorin added the comment: I'll allocate time this week for the review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 07:13:53 2019 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 04 Feb 2019 12:13:53 +0000 Subject: [issue12374] Execution model should explain compile vs definition vs execution time In-Reply-To: <1308582911.55.0.701954968644.issue12374@psf.upfronthosting.co.za> Message-ID: <1549282433.31.0.452195836181.issue12374@roundup.psfhosted.org> Nick Coghlan added the comment: https://github.com/ncoghlan/python-userref/blob/master/ODF/Chapter01_EssentialConcepts.odt is the Chapter 1 userref link now that the PSF SVN server has shut down. Depending on what you mean by "Pursuing this...": 1. I'd definitely still love to see the content from the user reference converted into a collaborative documentation project and brought up to speed with modern Python - it's just a large enough task that I've shied away from doing it myself. 2. For this ticket itself, I'm thinking this kind of explanatory material might find a better home in the Developer's Guide these days, as there it could also provide pointers to the different parts of CPython that implement each phase. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 07:59:32 2019 From: report at bugs.python.org (Davin Potts) Date: Mon, 04 Feb 2019 12:59:32 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1549285172.25.0.793848388753.issue35813@roundup.psfhosted.org> Davin Potts added the comment: @lukasz.langa: Missing tests and documentation will be in by alpha2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 08:45:15 2019 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Mon, 04 Feb 2019 13:45:15 +0000 Subject: [issue26243] zlib.compress level as keyword argument In-Reply-To: <1454179267.96.0.292283649228.issue26243@psf.upfronthosting.co.za> Message-ID: <1549287915.19.0.285619319792.issue26243@roundup.psfhosted.org> Change by ?ukasz Langa : ---------- pull_requests: +11693 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 08:45:27 2019 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Mon, 04 Feb 2019 13:45:27 +0000 Subject: [issue26243] zlib.compress level as keyword argument In-Reply-To: <1454179267.96.0.292283649228.issue26243@psf.upfronthosting.co.za> Message-ID: <1549287927.33.0.204053944439.issue26243@roundup.psfhosted.org> Change by ?ukasz Langa : ---------- pull_requests: +11693, 11694 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 08:45:39 2019 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Mon, 04 Feb 2019 13:45:39 +0000 Subject: [issue26243] zlib.compress level as keyword argument In-Reply-To: <1454179267.96.0.292283649228.issue26243@psf.upfronthosting.co.za> Message-ID: <1549287939.23.0.193831779265.issue26243@roundup.psfhosted.org> Change by ?ukasz Langa : ---------- pull_requests: +11693, 11694, 11695 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 08:57:23 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 04 Feb 2019 13:57:23 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1549288643.25.0.344253123258.issue35813@roundup.psfhosted.org> Ronald Oussoren added the comment: Please also address my review comments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 09:00:11 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 04 Feb 2019 14:00:11 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1549288811.01.0.814678457364.issue35813@roundup.psfhosted.org> Antoine Pitrou added the comment: Also, I will want to review this as well. Since Alpha 2 is scheduled for 2019-02-24, and this is a sizable piece of work, I would prefer if a full PR was available, say, before 2019-02-15. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 09:22:29 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 04 Feb 2019 14:22:29 +0000 Subject: [issue35895] the test suite of pytest failed with 3.8.0a1 Message-ID: <1549290147.76.0.914127082694.issue35895@roundup.psfhosted.org> New submission from St?phane Wirtel : I have execute the tests of pytest with 3.8.0a1 and I get some issues, it's not the case with 3.7.x (see the travis logs of pytest, https://travis-ci.org/pytest-dev/pytest/branches) I am going to create the same issue for pytest. ---------- files: tox-pytest-38-stdout.log messages: 334823 nosy: matrixise priority: normal severity: normal status: open title: the test suite of pytest failed with 3.8.0a1 versions: Python 3.8 Added file: https://bugs.python.org/file48096/tox-pytest-38-stdout.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 09:23:59 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 04 Feb 2019 14:23:59 +0000 Subject: [issue35895] the test suite of pytest failed with 3.8.0a1 In-Reply-To: <1549290147.76.0.914127082694.issue35895@roundup.psfhosted.org> Message-ID: <1549290239.33.0.673424338994.issue35895@roundup.psfhosted.org> St?phane Wirtel added the comment: Here is the issue in the bug tracker of pytest https://github.com/pytest-dev/pytest/issues/4716 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 09:57:17 2019 From: report at bugs.python.org (Paul Moore) Date: Mon, 04 Feb 2019 14:57:17 +0000 Subject: [issue35895] the test suite of pytest failed with 3.8.0a1 In-Reply-To: <1549290147.76.0.914127082694.issue35895@roundup.psfhosted.org> Message-ID: <1549292237.74.0.912681467033.issue35895@roundup.psfhosted.org> Paul Moore added the comment: Is this relevant? https://bugs.python.org/issue33416 It's a backward incompatible change to the AST in 3.8 (according to the 3.8 changelog). ---------- nosy: +paul.moore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 10:03:10 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 04 Feb 2019 15:03:10 +0000 Subject: [issue35895] the test suite of pytest failed with 3.8.0a1 In-Reply-To: <1549290147.76.0.914127082694.issue35895@roundup.psfhosted.org> Message-ID: <1549292590.07.0.850405998776.issue35895@roundup.psfhosted.org> St?phane Wirtel added the comment: maybe, I don't know but I have tested with pytest because the tests with requests did not work. I prefered to create this issue and the same issue on the bug tracker of pytest. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 10:08:10 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Mon, 04 Feb 2019 15:08:10 +0000 Subject: [issue35887] Doc string for updating the frozen version of importlib in _bootstrap.py incorrect In-Reply-To: <1549071736.85.0.965218389814.issue35887@roundup.psfhosted.org> Message-ID: <1549292890.94.0.610280865781.issue35887@roundup.psfhosted.org> R?mi Lapeyre added the comment: I believe this is why Travis does a `make regen-all` to be sure everything is up to date. A patch to keep instructions up-to-date would be nice, newcomers are not familiar with all `make regen-*` commands. ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 10:09:53 2019 From: report at bugs.python.org (Charalampos Stratakis) Date: Mon, 04 Feb 2019 15:09:53 +0000 Subject: [issue1294959] Problems with /usr/lib64 builds. Message-ID: <1549292993.62.0.297857977315.issue1294959@roundup.psfhosted.org> Change by Charalampos Stratakis : ---------- pull_requests: +11696 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 10:10:34 2019 From: report at bugs.python.org (Charalampos Stratakis) Date: Mon, 04 Feb 2019 15:10:34 +0000 Subject: [issue1294959] Problems with /usr/lib64 builds. Message-ID: <1549293034.65.0.548058713398.issue1294959@roundup.psfhosted.org> Change by Charalampos Stratakis : ---------- pull_requests: +11696, 11697 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 10:10:55 2019 From: report at bugs.python.org (Charalampos Stratakis) Date: Mon, 04 Feb 2019 15:10:55 +0000 Subject: [issue1294959] Problems with /usr/lib64 builds. Message-ID: <1549293055.51.0.370740347813.issue1294959@roundup.psfhosted.org> Change by Charalampos Stratakis : ---------- pull_requests: +11696, 11698 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 10:20:23 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 04 Feb 2019 15:20:23 +0000 Subject: [issue35872] Creating venv from venv no longer works in 3.7.2 In-Reply-To: <1549010953.4.0.913686801166.issue35872@roundup.psfhosted.org> Message-ID: <1549293623.05.0.993587493546.issue35872@roundup.psfhosted.org> Steve Dower added the comment: New changeset 44467e8ea4cea390b0718702291b4cfe8ddd67ed by Steve Dower in branch '3.7': bpo-35872 and bpo-35873: Clears __PYVENV_LAUNCHER__ variable (GH-11745) https://github.com/python/cpython/commit/44467e8ea4cea390b0718702291b4cfe8ddd67ed ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 10:20:38 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 04 Feb 2019 15:20:38 +0000 Subject: [issue35873] Controlling venv from venv no longer works in 3.7.2 In-Reply-To: <1549011784.82.0.296319027076.issue35873@roundup.psfhosted.org> Message-ID: <1549293638.84.0.445043917657.issue35873@roundup.psfhosted.org> Steve Dower added the comment: New changeset 44467e8ea4cea390b0718702291b4cfe8ddd67ed by Steve Dower in branch '3.7': bpo-35872 and bpo-35873: Clears __PYVENV_LAUNCHER__ variable (GH-11745) https://github.com/python/cpython/commit/44467e8ea4cea390b0718702291b4cfe8ddd67ed ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 10:23:13 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 04 Feb 2019 15:23:13 +0000 Subject: [issue35873] Controlling venv from venv no longer works in 3.7.2 In-Reply-To: <1549011784.82.0.296319027076.issue35873@roundup.psfhosted.org> Message-ID: <1549293793.38.0.573419606545.issue35873@roundup.psfhosted.org> Change by Steve Dower : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 10:23:21 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 04 Feb 2019 15:23:21 +0000 Subject: [issue35872] Creating venv from venv no longer works in 3.7.2 In-Reply-To: <1549010953.4.0.913686801166.issue35872@roundup.psfhosted.org> Message-ID: <1549293801.61.0.567306890325.issue35872@roundup.psfhosted.org> Change by Steve Dower : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 10:55:30 2019 From: report at bugs.python.org (Ma Lin) Date: Mon, 04 Feb 2019 15:55:30 +0000 Subject: [issue35859] Capture behavior depends on the order of an alternation In-Reply-To: <1548857774.3.0.1614070954.issue35859@roundup.psfhosted.org> Message-ID: <1549295730.1.0.802344003236.issue35859@roundup.psfhosted.org> Change by Ma Lin : ---------- keywords: +patch pull_requests: +11699 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 10:55:40 2019 From: report at bugs.python.org (Ma Lin) Date: Mon, 04 Feb 2019 15:55:40 +0000 Subject: [issue35859] Capture behavior depends on the order of an alternation In-Reply-To: <1548857774.3.0.1614070954.issue35859@roundup.psfhosted.org> Message-ID: <1549295740.28.0.288054329709.issue35859@roundup.psfhosted.org> Change by Ma Lin : ---------- keywords: +patch, patch pull_requests: +11699, 11700 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 10:55:50 2019 From: report at bugs.python.org (Ma Lin) Date: Mon, 04 Feb 2019 15:55:50 +0000 Subject: [issue35859] Capture behavior depends on the order of an alternation In-Reply-To: <1548857774.3.0.1614070954.issue35859@roundup.psfhosted.org> Message-ID: <1549295750.74.0.889638851605.issue35859@roundup.psfhosted.org> Change by Ma Lin : ---------- keywords: +patch, patch, patch pull_requests: +11699, 11700, 11701 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 11:38:01 2019 From: report at bugs.python.org (Pradyun Gedam) Date: Mon, 04 Feb 2019 16:38:01 +0000 Subject: [issue35807] Update bundled pip to 19.0 In-Reply-To: <1548185823.13.0.177750416451.issue35807@roundup.psfhosted.org> Message-ID: <1549298281.23.0.536559391737.issue35807@roundup.psfhosted.org> Pradyun Gedam added the comment: Update: I'll do this after 19.0.2 is released. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 12:01:26 2019 From: report at bugs.python.org (PyScripter) Date: Mon, 04 Feb 2019 17:01:26 +0000 Subject: [issue35706] Make it easier to use a venv with an embedded Python interpreter In-Reply-To: <1547129099.62.0.924394155356.issue35706@roundup.psfhosted.org> Message-ID: <1549299686.55.0.0192354602274.issue35706@roundup.psfhosted.org> PyScripter added the comment: "Personally, I am 100% against letting an embedded runtime automatically pick up any settings from the environment. You don't know where they came from." Why is that? When the embedding application is using Py_SetPythonHome there is clear intent to use a specific python setup. This is no different to using any other Python setup. Why venvs should be treated differently that standard installations? As to manually setting the path, why pass the burden to the embedding application. The idea is that python, in the embedding application, should work as in the python executable. Trying to match the complex and evolving algorithms that python uses to setup the path, is a huge and unnecessary burden on the embedding application. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 12:29:41 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 04 Feb 2019 17:29:41 +0000 Subject: [issue35706] Make it easier to use a venv with an embedded Python interpreter In-Reply-To: <1547129099.62.0.924394155356.issue35706@roundup.psfhosted.org> Message-ID: <1549301381.94.0.323813730576.issue35706@roundup.psfhosted.org> Steve Dower added the comment: > The idea is that python, in the embedding application, should work as in the python executable. I disagree that this is the idea. Python in the embedding application should work as in the embedding application, not the standalone one. The embedding application should be able to easily opt-in to "standalone-like configuration", which is also what I said above, but right now that doesn't exist (it's under development). Now, I'd be very much in favour of being able to embed Python without having to load any encodings. That ought to get us to the point where you can call "site.main()" in your embedding app, which does most of the work of what you consider the "default" behavior. But right now you just have to provide enough search path to initialize before doing that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 12:33:35 2019 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 04 Feb 2019 17:33:35 +0000 Subject: [issue35895] the test suite of pytest failed with 3.8.0a1 In-Reply-To: <1549290147.76.0.914127082694.issue35895@roundup.psfhosted.org> Message-ID: <1549301615.09.0.000734505879139.issue35895@roundup.psfhosted.org> Guido van Rossum added the comment: Looks like pytest needs to be adjusted to some new AST features. ---------- nosy: +gvanrossum resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 12:47:39 2019 From: report at bugs.python.org (PyScripter) Date: Mon, 04 Feb 2019 17:47:39 +0000 Subject: [issue35706] Make it easier to use a venv with an embedded Python interpreter In-Reply-To: <1547129099.62.0.924394155356.issue35706@roundup.psfhosted.org> Message-ID: <1549302459.49.0.374785948914.issue35706@roundup.psfhosted.org> PyScripter added the comment: This issue is related (duplicate) to https://bugs.python.org/issue22213. It appears that there is a workaround but only for Linux using Py_SetProgramName. I wish that there was some similar way for Windows. ---------- nosy: +ncoghlan, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 13:19:57 2019 From: report at bugs.python.org (Eric Snow) Date: Mon, 04 Feb 2019 18:19:57 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1549304397.28.0.566802537321.issue35813@roundup.psfhosted.org> Eric Snow added the comment: FTR, I've had a number of extensive conversations with Davin (over the last year and a half) about this feature. His choices seemed reasonable (caveat: I'm not an expert on multiprocessing) and the feature seemed desirable. I did not review his PR. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 14:02:40 2019 From: report at bugs.python.org (pmpp) Date: Mon, 04 Feb 2019 19:02:40 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1549306960.62.0.0683276960135.issue35813@roundup.psfhosted.org> Change by pmpp : ---------- nosy: +pmpp _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 14:08:28 2019 From: report at bugs.python.org (Paul Ganssle) Date: Mon, 04 Feb 2019 19:08:28 +0000 Subject: [issue35893] distutils fails to build extension on windows when it is a package.__init__ In-Reply-To: <1549228211.63.0.529262209714.issue35893@roundup.psfhosted.org> Message-ID: <1549307308.42.0.177480791325.issue35893@roundup.psfhosted.org> Change by Paul Ganssle : ---------- nosy: +p-ganssle _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 14:12:23 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 Feb 2019 19:12:23 +0000 Subject: [issue15248] Better explain "TypeError: 'tuple' object is not callable" In-Reply-To: <1341379722.78.0.0866285571225.issue15248@psf.upfronthosting.co.za> Message-ID: <1549307543.33.0.491098822982.issue15248@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- pull_requests: +11702 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 14:12:40 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 Feb 2019 19:12:40 +0000 Subject: [issue15248] Better explain "TypeError: 'tuple' object is not callable" In-Reply-To: <1341379722.78.0.0866285571225.issue15248@psf.upfronthosting.co.za> Message-ID: <1549307560.44.0.341692034456.issue15248@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- pull_requests: +11702, 11703 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 14:16:18 2019 From: report at bugs.python.org (Paul Ganssle) Date: Mon, 04 Feb 2019 19:16:18 +0000 Subject: [issue35893] distutils fails to build extension on windows when it is a package.__init__ In-Reply-To: <1549228211.63.0.529262209714.issue35893@roundup.psfhosted.org> Message-ID: <1549307778.19.0.196463471083.issue35893@roundup.psfhosted.org> Paul Ganssle added the comment: @Ronald The module you've linked to seems to be using flit and doesn't have any C extensions. Did you change over the build process, or am I missing something? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 14:42:09 2019 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 04 Feb 2019 19:42:09 +0000 Subject: [issue32417] fromutc does not respect datetime subclasses In-Reply-To: <1514052939.19.0.213398074469.issue32417@psf.upfronthosting.co.za> Message-ID: <1549309329.56.0.271379806215.issue32417@roundup.psfhosted.org> Alexander Belopolsky added the comment: New changeset 89427cd0feae25bbc8693abdccfa6a8c81a2689c by Alexander Belopolsky (Paul Ganssle) in branch 'master': bpo-32417: Make timedelta arithmetic respect subclasses (#10902) https://github.com/python/cpython/commit/89427cd0feae25bbc8693abdccfa6a8c81a2689c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 14:42:17 2019 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 04 Feb 2019 19:42:17 +0000 Subject: =?utf-8?b?W2lzc3VlMzUzNjRdIERhdGV0aW1lIOKAnGZyb210aW1lc3RhbXAoKeKAnSBp?= =?utf-8?q?gnores_inheritance_if_timezone_is_not_None?= In-Reply-To: <1543598741.31.0.788709270274.issue35364@psf.upfronthosting.co.za> Message-ID: <1549309337.41.0.454561221384.issue35364@roundup.psfhosted.org> Alexander Belopolsky added the comment: New changeset 89427cd0feae25bbc8693abdccfa6a8c81a2689c by Alexander Belopolsky (Paul Ganssle) in branch 'master': bpo-32417: Make timedelta arithmetic respect subclasses (#10902) https://github.com/python/cpython/commit/89427cd0feae25bbc8693abdccfa6a8c81a2689c ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 15:08:01 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 04 Feb 2019 20:08:01 +0000 Subject: [issue35224] PEP 572: Assignment Expressions In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za> Message-ID: <1549310881.49.0.290005288728.issue35224@roundup.psfhosted.org> Raymond Hettinger added the comment: FYI, we need a prominent Whatsnew entry for this. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 15:42:34 2019 From: report at bugs.python.org (Emily Morehouse) Date: Mon, 04 Feb 2019 20:42:34 +0000 Subject: [issue35224] PEP 572: Assignment Expressions In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za> Message-ID: <1549312954.63.0.474303492055.issue35224@roundup.psfhosted.org> Emily Morehouse added the comment: @rhettinger absolutely, I'm going to include that in my documentation PR which is currently in progress. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 16:33:46 2019 From: report at bugs.python.org (jcrmatos) Date: Mon, 04 Feb 2019 21:33:46 +0000 Subject: [issue35896] sysconfig.get_platform returns wrong value when Python 32b is running under Windows 64b Message-ID: <1549316025.61.0.403140167175.issue35896@roundup.psfhosted.org> New submission from jcrmatos : sysconfig.get_platform returns wrong value when Python 32b is running under Windows 64b. It should return win-amd64 and returns win32. ---------- messages: 334841 nosy: jcrmatos priority: normal severity: normal status: open title: sysconfig.get_platform returns wrong value when Python 32b is running under Windows 64b versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 16:37:47 2019 From: report at bugs.python.org (pmpp) Date: Mon, 04 Feb 2019 21:37:47 +0000 Subject: [issue35896] sysconfig.get_platform returns wrong value when Python 32b is running under Windows 64b In-Reply-To: <1549316025.61.0.403140167175.issue35896@roundup.psfhosted.org> Message-ID: <1549316267.06.0.844129111811.issue35896@roundup.psfhosted.org> pmpp added the comment: i think that platform is called SysWoW64 and is more or less win32. https://en.wikipedia.org/wiki/WoW64 ---------- nosy: +pmpp _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 16:41:07 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 04 Feb 2019 21:41:07 +0000 Subject: [issue35893] distutils fails to build extension on windows when it is a package.__init__ In-Reply-To: <1549228211.63.0.529262209714.issue35893@roundup.psfhosted.org> Message-ID: <1549316467.76.0.633492468415.issue35893@roundup.psfhosted.org> Ronald Oussoren added the comment: @Paul, modulegraph2 uses flit, but I do use setuptools to build extensions in the test suite. The problematic setup.py file is in testsuite/nodebuilder-tree. I do have a workaround in that setup.py: # START def get_export_symbols(self, ext): parts = ext.name.split(".") if parts[-1] == "__init__": initfunc_name = "PyInit_" + parts[-2] else: initfunc_name = "PyInit_" + parts[-1] build_ext.build_ext.get_export_symbols = get_export_symbols # END Creating a PR from this would be easy, but IMHO there should be a new test case as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 16:45:24 2019 From: report at bugs.python.org (jcrmatos) Date: Mon, 04 Feb 2019 21:45:24 +0000 Subject: [issue35896] sysconfig.get_platform returns wrong value when Python 32b is running under Windows 64b In-Reply-To: <1549316025.61.0.403140167175.issue35896@roundup.psfhosted.org> Message-ID: <1549316724.04.0.694917119499.issue35896@roundup.psfhosted.org> jcrmatos added the comment: That's the name of the subsystem, not the platform. Check the article you indicated "In computing on Microsoft platforms, SysWoW64 (Windows 32-bit on Windows 64-bit) is a subsystem..." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 16:53:35 2019 From: report at bugs.python.org (Paul Ganssle) Date: Mon, 04 Feb 2019 21:53:35 +0000 Subject: [issue35893] distutils fails to build extension on windows when it is a package.__init__ In-Reply-To: <1549228211.63.0.529262209714.issue35893@roundup.psfhosted.org> Message-ID: <1549317215.84.0.0146136941975.issue35893@roundup.psfhosted.org> Paul Ganssle added the comment: @Ronald Ah, interesting, I missed that. In my experience, distutils is pretty static and it's not particularly common to merge changes into it. Whether or not this is in scope for distutils, it's definitely in scope for setuptools - do you mind opening an issue on the setuptools tracker? https://github.com/pypa/setuptools ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 16:57:48 2019 From: report at bugs.python.org (Joachim Jablon) Date: Mon, 04 Feb 2019 21:57:48 +0000 Subject: [issue30670] pprint for dict in sorted order or insert order? In-Reply-To: <1497492955.33.0.313949068523.issue30670@psf.upfronthosting.co.za> Message-ID: <1549317468.58.0.921446743849.issue30670@roundup.psfhosted.org> Joachim Jablon added the comment: If you stop sorting keys in pprint, then unittest.TestCase.assertDictEquals() (and pytest and such) won't be able to generate a meaningful diff when 2 dicts aren't equal, and it will be much more complicated to understand why a test fails. https://github.com/python/cpython/blob/89427cd0feae25bbc8693abdccfa6a8c81a2689c/Lib/unittest/case.py#L1172-L1175 (well except if we fix unittest, but then external test runners will need fixing too, and it might not be the only place diff is used on the result of pprint to see how two objects differ) ---------- nosy: +ewjoachim _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 17:17:45 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 04 Feb 2019 22:17:45 +0000 Subject: [issue35893] distutils fails to build extension on windows when it is a package.__init__ In-Reply-To: <1549228211.63.0.529262209714.issue35893@roundup.psfhosted.org> Message-ID: <1549318665.49.0.0323576646931.issue35893@roundup.psfhosted.org> Ronald Oussoren added the comment: The bug is the stdlib, and I've checked that setuptools just calls the code in distutils in this case. IMHO it would be better to fix this in the stdlib. (Unselecting python 3.6 because that's in security-only mode by now) ---------- versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 17:23:48 2019 From: report at bugs.python.org (Paul Ganssle) Date: Mon, 04 Feb 2019 22:23:48 +0000 Subject: [issue35893] distutils fails to build extension on windows when it is a package.__init__ In-Reply-To: <1549228211.63.0.529262209714.issue35893@roundup.psfhosted.org> Message-ID: <1549319028.1.0.287125160381.issue35893@roundup.psfhosted.org> Paul Ganssle added the comment: Well, there's some tentative plan for `setuptools` to completely adopt distutils, so in some sense all distutils bugs are setuptools bugs as well. That said, the reason to report it in setuptools as well is that setuptools still supports Python 2.7, 3.5 and 3.6, so even if this bug is fixed in the standard library, it still needs to be fixed in setuptools. Of course it may not be easy or feasible to fix it in setuptools until *after* we fully adopt distutils, but ?\_(?)_/? might as well still report it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 17:44:28 2019 From: report at bugs.python.org (pmpp) Date: Mon, 04 Feb 2019 22:44:28 +0000 Subject: [issue35896] sysconfig.get_platform returns wrong value when Python 32b is running under Windows 64b In-Reply-To: <1549316025.61.0.403140167175.issue35896@roundup.psfhosted.org> Message-ID: <1549320268.21.0.184335198669.issue35896@roundup.psfhosted.org> pmpp added the comment: from what I remember it's a platform-vm where you can't call (host) 64bits abi or access (host) 64 bits registry. registry calls are overlaid under a "WoW64" branch in host registry. Nothing like aarch64 or Darwin ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 17:45:37 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 04 Feb 2019 22:45:37 +0000 Subject: [issue35893] distutils fails to build extension on windows when it is a package.__init__ In-Reply-To: <1549228211.63.0.529262209714.issue35893@roundup.psfhosted.org> Message-ID: <1549320337.68.0.774477168623.issue35893@roundup.psfhosted.org> Steve Dower added the comment: Agreed that it should go to setuptools in order to support third-party packages. In general, those of us who ever touch distutils these days (basically just me?) are only really maintaining those parts necessary to build Python and its own modules. Since this doesn't impact that scenario, it's not going to get much attention until there's at least a PR and tests to review. ---------- versions: +Python 2.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 18:01:31 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Mon, 04 Feb 2019 23:01:31 +0000 Subject: [issue18765] unittest needs a way to launch pdb.post_mortem or other debug hooks In-Reply-To: <1376696752.64.0.473845221037.issue18765@psf.upfronthosting.co.za> Message-ID: <1549321291.58.0.0869698519346.issue18765@roundup.psfhosted.org> R?mi Lapeyre added the comment: Hi, this is the only reason I still use pytest, I would love to be able to use only unittest and the constant copy-paste is not a great solution and is not very user friendly. I would like to wotk on this issue. StackOverflow has many example on how to override testRunner or to create decorators to call pm() on failure but there is no clean solution to do this yet. It's especially a problem when using a project developped by another team that did not set up such utilities, but a default debugHook that calls pgb if a flag is given would be very useful. ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 19:56:40 2019 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 05 Feb 2019 00:56:40 +0000 Subject: [issue35321] None _frozen_importlib.__spec__.origin attribute In-Reply-To: <1543274371.24.0.788709270274.issue35321@psf.upfronthosting.co.za> Message-ID: <1549328200.33.0.830725092529.issue35321@roundup.psfhosted.org> Barry A. Warsaw added the comment: New changeset 69091cb497b2f0fe7e2789b30b43cf78caf9de9b by Barry Warsaw (Nina Zakharenko) in branch 'master': bpo-35321: Set the spec origin to frozen in frozen modules (#11732) https://github.com/python/cpython/commit/69091cb497b2f0fe7e2789b30b43cf78caf9de9b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 20:15:17 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 05 Feb 2019 01:15:17 +0000 Subject: [issue35299] LGHT0091: Duplicate symbol 'File:include_pyconfig.h' found In-Reply-To: <1542954685.4.0.788709270274.issue35299@psf.upfronthosting.co.za> Message-ID: <1549329317.93.0.838964012288.issue35299@roundup.psfhosted.org> Steve Dower added the comment: New changeset 85e102a2b090dd693d0801ae2edb9660cfa0f281 by Steve Dower in branch 'master': bpo-35299: Fixed sysconfig and distutils during PGO profiling (GH-11744) https://github.com/python/cpython/commit/85e102a2b090dd693d0801ae2edb9660cfa0f281 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 20:15:32 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 05 Feb 2019 01:15:32 +0000 Subject: [issue35299] LGHT0091: Duplicate symbol 'File:include_pyconfig.h' found In-Reply-To: <1542954685.4.0.788709270274.issue35299@psf.upfronthosting.co.za> Message-ID: <1549329317.93.0.838964012288.issue35299@roundup.psfhosted.org> Steve Dower added the comment: New changeset 85e102a2b090dd693d0801ae2edb9660cfa0f281 by Steve Dower in branch 'master': bpo-35299: Fixed sysconfig and distutils during PGO profiling (GH-11744) https://github.com/python/cpython/commit/85e102a2b090dd693d0801ae2edb9660cfa0f281 ---------- pull_requests: +11704 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 20:15:34 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 05 Feb 2019 01:15:34 +0000 Subject: [issue35299] LGHT0091: Duplicate symbol 'File:include_pyconfig.h' found In-Reply-To: <1542954685.4.0.788709270274.issue35299@psf.upfronthosting.co.za> Message-ID: <1549329317.93.0.838964012288.issue35299@roundup.psfhosted.org> Steve Dower added the comment: New changeset 85e102a2b090dd693d0801ae2edb9660cfa0f281 by Steve Dower in branch 'master': bpo-35299: Fixed sysconfig and distutils during PGO profiling (GH-11744) https://github.com/python/cpython/commit/85e102a2b090dd693d0801ae2edb9660cfa0f281 ---------- pull_requests: +11704, 11706 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 20:15:36 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 05 Feb 2019 01:15:36 +0000 Subject: [issue35299] LGHT0091: Duplicate symbol 'File:include_pyconfig.h' found In-Reply-To: <1542954685.4.0.788709270274.issue35299@psf.upfronthosting.co.za> Message-ID: <1549329317.93.0.838964012288.issue35299@roundup.psfhosted.org> Steve Dower added the comment: New changeset 85e102a2b090dd693d0801ae2edb9660cfa0f281 by Steve Dower in branch 'master': bpo-35299: Fixed sysconfig and distutils during PGO profiling (GH-11744) https://github.com/python/cpython/commit/85e102a2b090dd693d0801ae2edb9660cfa0f281 ---------- pull_requests: +11704, 11705, 11706 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 20:15:46 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 05 Feb 2019 01:15:46 +0000 Subject: [issue35299] LGHT0091: Duplicate symbol 'File:include_pyconfig.h' found In-Reply-To: <1542954685.4.0.788709270274.issue35299@psf.upfronthosting.co.za> Message-ID: <1549329346.79.0.47676717027.issue35299@roundup.psfhosted.org> Change by Steve Dower : ---------- assignee: -> steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 20:27:30 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 05 Feb 2019 01:27:30 +0000 Subject: [issue18765] unittest needs a way to launch pdb.post_mortem or other debug hooks In-Reply-To: <1376696752.64.0.473845221037.issue18765@psf.upfronthosting.co.za> Message-ID: <1549330050.63.0.37755714789.issue18765@roundup.psfhosted.org> Change by Gregory P. Smith : ---------- keywords: +easy versions: +Python 3.8 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 20:52:27 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 05 Feb 2019 01:52:27 +0000 Subject: [issue30670] pprint for dict in sorted order or insert order? In-Reply-To: <1497492955.33.0.313949068523.issue30670@psf.upfronthosting.co.za> Message-ID: <1549331547.08.0.293109549816.issue30670@roundup.psfhosted.org> Raymond Hettinger added the comment: Consider adding a flag to switch between sorted order and insertion order (defaulting to the current behavior). For convenience, add a short-cut function to call pprint() with the flag set to False. def pprint(data, *, sort_dicts=True): ... def pp(data, *args, **kwds): pprint(data, *args, sort_dicts=False, **kwds) ---------- resolution: later -> versions: -Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 20:55:03 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 05 Feb 2019 01:55:03 +0000 Subject: [issue35299] LGHT0091: Duplicate symbol 'File:include_pyconfig.h' found In-Reply-To: <1542954685.4.0.788709270274.issue35299@psf.upfronthosting.co.za> Message-ID: <1549331703.27.0.828617890237.issue35299@roundup.psfhosted.org> miss-islington added the comment: New changeset 4f6854a690e95ab5159687794652c639a020d6fd by Miss Islington (bot) in branch '3.7': bpo-35299: Fixed sysconfig and distutils during PGO profiling (GH-11744) https://github.com/python/cpython/commit/4f6854a690e95ab5159687794652c639a020d6fd ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 20:55:19 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 05 Feb 2019 01:55:19 +0000 Subject: [issue35299] LGHT0091: Duplicate symbol 'File:include_pyconfig.h' found In-Reply-To: <1542954685.4.0.788709270274.issue35299@psf.upfronthosting.co.za> Message-ID: <1549331703.27.0.828617890237.issue35299@roundup.psfhosted.org> miss-islington added the comment: New changeset 4f6854a690e95ab5159687794652c639a020d6fd by Miss Islington (bot) in branch '3.7': bpo-35299: Fixed sysconfig and distutils during PGO profiling (GH-11744) https://github.com/python/cpython/commit/4f6854a690e95ab5159687794652c639a020d6fd ---------- nosy: +miss-islington resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 21:14:39 2019 From: report at bugs.python.org (Ned Deily) Date: Tue, 05 Feb 2019 02:14:39 +0000 Subject: [issue35321] None _frozen_importlib.__spec__.origin attribute In-Reply-To: <1543274371.24.0.788709270274.issue35321@psf.upfronthosting.co.za> Message-ID: <1549332879.0.0.375643879906.issue35321@roundup.psfhosted.org> Change by Ned Deily : ---------- versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 4 22:22:15 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 05 Feb 2019 03:22:15 +0000 Subject: [issue30670] pprint for dict in sorted order or insert order? In-Reply-To: <1497492955.33.0.313949068523.issue30670@psf.upfronthosting.co.za> Message-ID: <1549336935.68.0.790836254982.issue30670@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- stage: resolved -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 03:36:20 2019 From: report at bugs.python.org (Fred .Flintstone) Date: Tue, 05 Feb 2019 08:36:20 +0000 Subject: [issue35897] Support list as argument to .startswith() Message-ID: <1549355778.94.0.606894132692.issue35897@roundup.psfhosted.org> New submission from Fred .Flintstone : The "".startswith() method accepts a string or a tuple as a parameter. Consider adding support for list as parameter. Example: "foo".startswith(["food", "for", "fast"]) ---------- components: Interpreter Core messages: 334856 nosy: Fred .Flintstone priority: normal severity: normal status: open title: Support list as argument to .startswith() type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 03:46:33 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 05 Feb 2019 08:46:33 +0000 Subject: [issue35897] Support list as argument to .startswith() In-Reply-To: <1549355778.94.0.606894132692.issue35897@roundup.psfhosted.org> Message-ID: <1549356393.09.0.352112663381.issue35897@roundup.psfhosted.org> Raymond Hettinger added the comment: For subtle reasons, that would make us worse off. Tuple of constants get precomputed but lists of constants have to be rebuilt. Thank for the suggestion, but I think we should stick with the original design. ---------- nosy: +rhettinger resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 03:47:33 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 05 Feb 2019 08:47:33 +0000 Subject: [issue35897] Support list as argument to .startswith() In-Reply-To: <1549355778.94.0.606894132692.issue35897@roundup.psfhosted.org> Message-ID: <1549356453.36.0.920311819633.issue35897@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Related discussion : issue34312 ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 04:38:53 2019 From: report at bugs.python.org (Fred .Flintstone) Date: Tue, 05 Feb 2019 09:38:53 +0000 Subject: [issue35897] Support list as argument to .startswith() In-Reply-To: <1549355778.94.0.606894132692.issue35897@roundup.psfhosted.org> Message-ID: <1549359533.5.0.566162394443.issue35897@roundup.psfhosted.org> Fred .Flintstone added the comment: A programmer want to instruct the computer to do something, without having to care about how it works. Maybe the library could in the background convert the list to a tuple. Like: "foo".startswith(tuple(["food", "for", "fast"])) But the programmer shouldn't have to worry about this. I have a list, I want to use the list. I shouldn't have to care about interpreter internals that have nothing to do with the intent of my code. My code should clearly represent intent, not have boilerplate code or constructs to workaround interpreter internals. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 05:06:14 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 05 Feb 2019 10:06:14 +0000 Subject: [issue35838] ConfigParser calls optionxform twice when assigning dict In-Reply-To: <1548628021.95.0.834258344082.issue35838@roundup.psfhosted.org> Message-ID: <1549361174.54.0.560122974518.issue35838@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- keywords: +patch pull_requests: +11707 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 05:06:21 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 05 Feb 2019 10:06:21 +0000 Subject: [issue35838] ConfigParser calls optionxform twice when assigning dict In-Reply-To: <1548628021.95.0.834258344082.issue35838@roundup.psfhosted.org> Message-ID: <1549361181.24.0.927365198658.issue35838@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- keywords: +patch, patch pull_requests: +11707, 11708 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 05:06:27 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 05 Feb 2019 10:06:27 +0000 Subject: [issue35838] ConfigParser calls optionxform twice when assigning dict In-Reply-To: <1548628021.95.0.834258344082.issue35838@roundup.psfhosted.org> Message-ID: <1549361187.39.0.18377871462.issue35838@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- keywords: +patch, patch, patch pull_requests: +11707, 11708, 11709 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 05:16:18 2019 From: report at bugs.python.org (INADA Naoki) Date: Tue, 05 Feb 2019 10:16:18 +0000 Subject: [issue20001] pathlib inheritance diagram too large In-Reply-To: <1387221538.52.0.488414928183.issue20001@psf.upfronthosting.co.za> Message-ID: <1549361778.53.0.0997432962862.issue20001@roundup.psfhosted.org> INADA Naoki added the comment: New changeset cd90f6a3692e0f7ef0a13aae651e19a08d1f9b31 by Inada Naoki (Harmandeep Singh) in branch 'master': bpo-20001: update pathlib landing image (GH-11304) https://github.com/python/cpython/commit/cd90f6a3692e0f7ef0a13aae651e19a08d1f9b31 ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 05:17:03 2019 From: report at bugs.python.org (INADA Naoki) Date: Tue, 05 Feb 2019 10:17:03 +0000 Subject: [issue20001] pathlib inheritance diagram too large In-Reply-To: <1387221538.52.0.488414928183.issue20001@psf.upfronthosting.co.za> Message-ID: <1549361823.69.0.908249901632.issue20001@roundup.psfhosted.org> Change by INADA Naoki : ---------- nosy: -inada.naoki versions: +Python 3.7, Python 3.8 -Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 05:30:21 2019 From: report at bugs.python.org (INADA Naoki) Date: Tue, 05 Feb 2019 10:30:21 +0000 Subject: [issue20001] pathlib inheritance diagram too large In-Reply-To: <1387221538.52.0.488414928183.issue20001@psf.upfronthosting.co.za> Message-ID: <1549362621.45.0.444342072228.issue20001@roundup.psfhosted.org> Change by INADA Naoki : ---------- pull_requests: +11710 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 05:30:35 2019 From: report at bugs.python.org (INADA Naoki) Date: Tue, 05 Feb 2019 10:30:35 +0000 Subject: [issue20001] pathlib inheritance diagram too large In-Reply-To: <1387221538.52.0.488414928183.issue20001@psf.upfronthosting.co.za> Message-ID: <1549362635.11.0.100446544128.issue20001@roundup.psfhosted.org> Change by INADA Naoki : ---------- pull_requests: +11710, 11711 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 05:30:48 2019 From: report at bugs.python.org (INADA Naoki) Date: Tue, 05 Feb 2019 10:30:48 +0000 Subject: [issue20001] pathlib inheritance diagram too large In-Reply-To: <1387221538.52.0.488414928183.issue20001@psf.upfronthosting.co.za> Message-ID: <1549362648.46.0.640080045228.issue20001@roundup.psfhosted.org> Change by INADA Naoki : ---------- pull_requests: +11710, 11711, 11712 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 05:39:46 2019 From: report at bugs.python.org (INADA Naoki) Date: Tue, 05 Feb 2019 10:39:46 +0000 Subject: [issue20001] pathlib inheritance diagram too large In-Reply-To: <1387221538.52.0.488414928183.issue20001@psf.upfronthosting.co.za> Message-ID: <1549363186.74.0.704609267425.issue20001@roundup.psfhosted.org> INADA Naoki added the comment: New changeset 21ab7744ae30bff24bcc9e075a96e98137b90a37 by Inada Naoki in branch '3.7': bpo-20001: update pathlib landing image (GH-11304) https://github.com/python/cpython/commit/21ab7744ae30bff24bcc9e075a96e98137b90a37 ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 05:40:02 2019 From: report at bugs.python.org (INADA Naoki) Date: Tue, 05 Feb 2019 10:40:02 +0000 Subject: [issue20001] pathlib inheritance diagram too large In-Reply-To: <1387221538.52.0.488414928183.issue20001@psf.upfronthosting.co.za> Message-ID: <1549363186.74.0.704609267425.issue20001@roundup.psfhosted.org> INADA Naoki added the comment: New changeset 21ab7744ae30bff24bcc9e075a96e98137b90a37 by Inada Naoki in branch '3.7': bpo-20001: update pathlib landing image (GH-11304) https://github.com/python/cpython/commit/21ab7744ae30bff24bcc9e075a96e98137b90a37 ---------- nosy: +inada.naoki resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 06:26:45 2019 From: report at bugs.python.org (Stefan Krah) Date: Tue, 05 Feb 2019 11:26:45 +0000 Subject: [issue34778] Memoryview for column-major (f_contiguous) arrays from bytes impossible to achieve In-Reply-To: <1537725098.47.0.956365154283.issue34778@psf.upfronthosting.co.za> Message-ID: <1549366005.95.0.94680556681.issue34778@roundup.psfhosted.org> Change by Stefan Krah : ---------- assignee: -> skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 06:51:55 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 05 Feb 2019 11:51:55 +0000 Subject: [issue35895] the test suite of pytest failed with 3.8.0a1 In-Reply-To: <1549290147.76.0.914127082694.issue35895@roundup.psfhosted.org> Message-ID: <1549367515.92.0.717026290414.issue35895@roundup.psfhosted.org> St?phane Wirtel added the comment: Hi Guido, The team of Pytest has been informed and after a small discussion, it seems it's a problem with the way they use the AST for the assert keyword. They know the issue, I hope they will fix it asap. I would like to test pytest with 3.8 ;-) Thank you to closing this one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 06:55:39 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 05 Feb 2019 11:55:39 +0000 Subject: [issue35358] Document that importlib.import_module accepts names that are not valid Python syntax In-Reply-To: <1543566651.92.0.788709270274.issue35358@psf.upfronthosting.co.za> Message-ID: <1549367739.4.0.853489865234.issue35358@roundup.psfhosted.org> St?phane Wirtel added the comment: I close this issue, thank you for your feedback. ---------- resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 06:56:32 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 05 Feb 2019 11:56:32 +0000 Subject: [issue35055] Error when we try to download the epub archive In-Reply-To: <1540322085.68.0.788709270274.issue35055@psf.upfronthosting.co.za> Message-ID: <1549367792.09.0.600228556576.issue35055@roundup.psfhosted.org> St?phane Wirtel added the comment: ping ned, do we have a solution for this issue? Thank you, St?phane ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 07:19:09 2019 From: report at bugs.python.org (Thomas Trummer) Date: Tue, 05 Feb 2019 12:19:09 +0000 Subject: [issue35898] The TARGETDIR variable must be provided when invoking this installer Message-ID: <1549369147.85.0.114900737559.issue35898@roundup.psfhosted.org> New submission from Thomas Trummer : The installer for Python 3.8.0a1 doesn't work under Windows 7. It shows the aforementioned error message. ---------- components: Installation files: Python 3.8.0a1 (64-bit)_20190205130936.log messages: 334865 nosy: Thomas Trummer priority: normal severity: normal status: open title: The TARGETDIR variable must be provided when invoking this installer type: behavior versions: Python 3.8 Added file: https://bugs.python.org/file48097/Python 3.8.0a1 (64-bit)_20190205130936.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 07:19:41 2019 From: report at bugs.python.org (Thomas Trummer) Date: Tue, 05 Feb 2019 12:19:41 +0000 Subject: [issue35898] The TARGETDIR variable must be provided when invoking this installer In-Reply-To: <1549369147.85.0.114900737559.issue35898@roundup.psfhosted.org> Message-ID: <1549369181.23.0.771621086487.issue35898@roundup.psfhosted.org> Change by Thomas Trummer : Added file: https://bugs.python.org/file48098/Python 3.8.0a1 (64-bit)_20190205130936_000_core_JustForMe.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 07:19:51 2019 From: report at bugs.python.org (Thomas Trummer) Date: Tue, 05 Feb 2019 12:19:51 +0000 Subject: [issue35898] The TARGETDIR variable must be provided when invoking this installer In-Reply-To: <1549369147.85.0.114900737559.issue35898@roundup.psfhosted.org> Message-ID: <1549369191.65.0.447054686535.issue35898@roundup.psfhosted.org> Change by Thomas Trummer : Added file: https://bugs.python.org/file48099/Python 3.8.0a1 (64-bit)_20190205131106.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 07:20:00 2019 From: report at bugs.python.org (Thomas Trummer) Date: Tue, 05 Feb 2019 12:20:00 +0000 Subject: [issue35898] The TARGETDIR variable must be provided when invoking this installer In-Reply-To: <1549369147.85.0.114900737559.issue35898@roundup.psfhosted.org> Message-ID: <1549369200.82.0.902824899423.issue35898@roundup.psfhosted.org> Change by Thomas Trummer : Added file: https://bugs.python.org/file48100/Python 3.8.0a1 (64-bit)_20190205131106_000_core_JustForMe.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 07:26:07 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 05 Feb 2019 12:26:07 +0000 Subject: [issue35898] The TARGETDIR variable must be provided when invoking this installer In-Reply-To: <1549369147.85.0.114900737559.issue35898@roundup.psfhosted.org> Message-ID: <1549369567.47.0.620558386173.issue35898@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 07:57:35 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 05 Feb 2019 12:57:35 +0000 Subject: [issue35896] sysconfig.get_platform returns wrong value when Python 32b is running under Windows 64b In-Reply-To: <1549316025.61.0.403140167175.issue35896@roundup.psfhosted.org> Message-ID: <1549371455.22.0.385045760683.issue35896@roundup.psfhosted.org> Change by Ronald Oussoren : ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 08:10:12 2019 From: report at bugs.python.org (SilentGhost) Date: Tue, 05 Feb 2019 13:10:12 +0000 Subject: [issue34572] C unpickling bypasses import thread safety In-Reply-To: <1535990001.55.0.56676864532.issue34572@psf.upfronthosting.co.za> Message-ID: <1549372212.89.0.515329669018.issue34572@roundup.psfhosted.org> Change by SilentGhost : ---------- keywords: +needs review nosy: +alexandre.vassalotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 09:08:28 2019 From: report at bugs.python.org (Stefan Krah) Date: Tue, 05 Feb 2019 14:08:28 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1549375708.27.0.0275610706099.issue35813@roundup.psfhosted.org> Change by Stefan Krah : ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 09:27:40 2019 From: report at bugs.python.org (Maxwell) Date: Tue, 05 Feb 2019 14:27:40 +0000 Subject: [issue35899] '_is_sunder' function in 'enum' module fails on empty string Message-ID: <1549376859.01.0.998806898699.issue35899@roundup.psfhosted.org> New submission from Maxwell : This is a really minor bug. In enum.py the function _is_sunder(name) fails on empty string with an IndexError. As a result, attempting to create an Enum with an empty string fails. >>> from enum import Enum >>> Yay = Enum('Yay', ('', 'B', 'C')) Traceback (most recent call last): File "", line 1, in File "C:\Program Files\Python37\lib\enum.py", line 311, in __call__ return cls._create_(value, names, module=module, qualname=qualname, type=type, start=start) File "C:\Program Files\Python37\lib\enum.py", line 422, in _create_ classdict[member_name] = member_value File "C:\Program Files\Python37\lib\enum.py", line 78, in __setitem__ if _is_sunder(key): File "C:\Program Files\Python37\lib\enum.py", line 36, in _is_sunder return (name[0] == name[-1] == '_' and IndexError: string index out of range >>> Expected behavior is for it to not fail, as Enum accepts wierd strings. Example: >>> from enum import Enum >>> Yay = Enum('Yay', ('!', 'B', 'C')) >>> getattr(Yay, '!') >>> Transcript of lines 26 to 39 of enum.py: def _is_dunder(name): """Returns True if a __dunder__ name, False otherwise.""" return (name[:2] == name[-2:] == '__' and name[2:3] != '_' and name[-3:-2] != '_' and len(name) > 4) def _is_sunder(name): """Returns True if a _sunder_ name, False otherwise.""" return (name[0] == name[-1] == '_' and name[1:2] != '_' and name[-2:-1] != '_' and len(name) > 2) Solution 1: Replace with: def _is_dunder(name): """Returns True if a __dunder__ name, False otherwise.""" return (len(name) > 4 and name[:2] == name[-2:] == '__' and name[2] != '_' and name[-3] != '_') def _is_sunder(name): """Returns True if a _sunder_ name, False otherwise.""" return (len(name) > 2 and name[0] == name[-1] == '_' and name[1:2] != '_' and name[-2:-1] != '_') In this solution, function '_is_dunder' was also altered for consistency. Altering '_is_dunder' is not necessary, though. Solution 2: Replace with: def _is_dunder(name): """Returns True if a __dunder__ name, False otherwise.""" return (name[:2] == name[-2:] == '__' and name[2:3] != '_' and name[-3:-2] != '_' and len(name) > 4) def _is_sunder(name): """Returns True if a _sunder_ name, False otherwise.""" return (name[:0] == name[-1:] == '_' and name[1:2] != '_' and name[-2:-1] != '_' and len(name) > 2) In this solution, function '_is_sunder' was altered to follow the style used in function '_is_dunder'. ---------- components: Library (Lib) messages: 334866 nosy: Maxpxt priority: normal severity: normal status: open title: '_is_sunder' function in 'enum' module fails on empty string type: crash versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 09:32:26 2019 From: report at bugs.python.org (Maxwell) Date: Tue, 05 Feb 2019 14:32:26 +0000 Subject: [issue35899] '_is_sunder' function in 'enum' module fails on empty string In-Reply-To: <1549376859.01.0.998806898699.issue35899@roundup.psfhosted.org> Message-ID: <1549377146.69.0.493478907421.issue35899@roundup.psfhosted.org> Maxwell added the comment: Typo fix on solution 2: def _is_sunder(name): """Returns True if a _sunder_ name, False otherwise.""" return (name[:1] == name[-1:] == '_' and name[1:2] != '_' and name[-2:-1] != '_' and len(name) > 2) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 09:37:20 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Tue, 05 Feb 2019 14:37:20 +0000 Subject: [issue18765] unittest needs a way to launch pdb.post_mortem or other debug hooks In-Reply-To: <1376696752.64.0.473845221037.issue18765@psf.upfronthosting.co.za> Message-ID: <1549377440.41.0.792493576995.issue18765@roundup.psfhosted.org> R?mi Lapeyre added the comment: @gregory.p.smith Do you think the debugHook should be added to the test case or the test runner? If we add it to the test case, how do you think the runner should tell the test case what flags have been given on the command line? I feel like adding a new class variable to TestCase could break some user code but no other option seems better to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 09:39:37 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Tue, 05 Feb 2019 14:39:37 +0000 Subject: [issue35899] '_is_sunder' function in 'enum' module fails on empty string In-Reply-To: <1549376859.01.0.998806898699.issue35899@roundup.psfhosted.org> Message-ID: <1549377577.29.0.733311188655.issue35899@roundup.psfhosted.org> R?mi Lapeyre added the comment: Hi @Maxpxt, I think your first solution is appropriate, do you want to open a new pull request with your solution and an appropriate test case? ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 09:40:24 2019 From: report at bugs.python.org (Pierre Glaser) Date: Tue, 05 Feb 2019 14:40:24 +0000 Subject: [issue35900] Add pickler hoor for the user to customize the serialization of user defined functions and types. Message-ID: <1549377622.96.0.737929222958.issue35900@roundup.psfhosted.org> New submission from Pierre Glaser : Pickler objects provide a dispatch_table attribute, where the user can specify custom saving functions depending on the object-to-be-saved type. However, for performance purposes, this table is predated (in the C implementation only) by a hardcoded switch that will take care of the saving for many built-in types, without a lookup in the dispatch_table. Especially, it is not possible to define custom saving methods for functions and classes, although the current default (save_global, that saves an object using its module attribute path) is likely to fail at pickling or unpickling time in many cases. The aforementioned failures exist on purpose in the standard library (as a way to allow for the serialization of functions accessible from non-dynamic (*) modules only). However, there exist cases where serializing functions from dynamic modules matter. These cases are currently handled thanks the cloudpickle module (https://github.com/cloudpipe/cloudpickle), that is used by many distributed data-science frameworks such as pyspark, ray and dask. For the reasons explained above, cloudpickle's Pickler subclass derives from the python Pickler class instead of its C class, which severely harms its performance. While prototyping with Antoine Pitrou, we came to the conclusion that a hook could be added to the C Pickler class, in which an optional user-defined callback would be invoked (if defined) when saving functions and classes instead of the traditional save_global. Here is a patch so that we can have something concrete of which to discuss. (*) dynamic module are modules that cannot be imported by name as traditional python file backed module. Examples include the __main__ module that can be populated dynamically by running a script or by a, user writing code in a python shell / jupyter notebook. ---------- files: test_hook.py messages: 334870 nosy: alexandre.vassalotti, pierreglaser, pitrou priority: normal severity: normal status: open title: Add pickler hoor for the user to customize the serialization of user defined functions and types. type: enhancement versions: Python 3.8 Added file: https://bugs.python.org/file48101/test_hook.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 09:42:21 2019 From: report at bugs.python.org (Pierre Glaser) Date: Tue, 05 Feb 2019 14:42:21 +0000 Subject: [issue35900] Add pickler hoor for the user to customize the serialization of user defined functions and types. In-Reply-To: <1549377622.96.0.737929222958.issue35900@roundup.psfhosted.org> Message-ID: <1549377741.18.0.957477930692.issue35900@roundup.psfhosted.org> Pierre Glaser added the comment: Pickler objects provide a dispatch_table attribute, where the user can specify custom saving functions depending on the object-to-be-saved type. However, for performance purposes, this table is predated (in the C implementation only) by a hardcoded switch that will take care of the saving for many built-in types, without a lookup in the dispatch_table. Especially, it is not possible to define custom saving methods for functions and classes, although the current default (save_global, that saves an object using its module attribute path) is likely to fail at pickling or unpickling time in many cases. The aforementioned failures exist on purpose in the standard library (as a way to allow for the serialization of functions accessible from non-dynamic (*) modules only). However, there exist cases where serializing functions from dynamic modules matter. These cases are currently handled thanks the cloudpickle module (https://github.com/cloudpipe/cloudpickle), that is used by many distributed data-science frameworks such as pyspark, ray and dask. For the reasons explained above, cloudpickle's Pickler subclass derives from the python Pickler class instead of its C class, which severely harms its performance. While prototyping with Antoine Pitrou, we came to the conclusion that a hook could be added to the C Pickler class, in which an optional user-defined callback would be invoked (if defined) when saving functions and classes instead of the traditional save_global. Here is a patch so that we can have something concrete of which to discuss. (*) dynamic module are modules that cannot be imported by name as traditional python file backed module. Examples include the __main__ module that can be populated dynamically by running a script or by a, user writing code in a python shell / jupyter notebook. ---------- keywords: +patch Added file: https://bugs.python.org/file48102/pickler_hook.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 10:02:16 2019 From: report at bugs.python.org (SilentGhost) Date: Tue, 05 Feb 2019 15:02:16 +0000 Subject: [issue35900] Add pickler hook for the user to customize the serialization of user defined functions and types. In-Reply-To: <1549377622.96.0.737929222958.issue35900@roundup.psfhosted.org> Message-ID: <1549378936.47.0.145858088274.issue35900@roundup.psfhosted.org> Change by SilentGhost : ---------- title: Add pickler hoor for the user to customize the serialization of user defined functions and types. -> Add pickler hook for the user to customize the serialization of user defined functions and types. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 10:22:55 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 05 Feb 2019 15:22:55 +0000 Subject: [issue35899] '_is_sunder' function in 'enum' module fails on empty string In-Reply-To: <1549376859.01.0.998806898699.issue35899@roundup.psfhosted.org> Message-ID: <1549380175.4.0.320661395561.issue35899@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +barry, eli.bendersky, ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 10:40:07 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 05 Feb 2019 15:40:07 +0000 Subject: [issue35900] Add pickler hook for the user to customize the serialization of user defined functions and types. In-Reply-To: <1549377622.96.0.737929222958.issue35900@roundup.psfhosted.org> Message-ID: <1549381207.49.0.0560586802564.issue35900@roundup.psfhosted.org> Change by Antoine Pitrou : ---------- Removed message: https://bugs.python.org/msg334871 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 10:40:42 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 05 Feb 2019 15:40:42 +0000 Subject: [issue35900] Add pickler hook for the user to customize the serialization of user defined functions and types. In-Reply-To: <1549377622.96.0.737929222958.issue35900@roundup.psfhosted.org> Message-ID: <1549381242.58.0.937022805561.issue35900@roundup.psfhosted.org> Antoine Pitrou added the comment: FYI, I've removed the duplicate message :-) Also adding Serhiy as cc. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 10:45:39 2019 From: report at bugs.python.org (Eric Snow) Date: Tue, 05 Feb 2019 15:45:39 +0000 Subject: [issue32417] fromutc does not respect datetime subclasses In-Reply-To: <1514052939.19.0.213398074469.issue32417@psf.upfronthosting.co.za> Message-ID: <1549381539.66.0.572024998972.issue32417@roundup.psfhosted.org> Change by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 10:58:58 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 05 Feb 2019 15:58:58 +0000 Subject: [issue35896] sysconfig.get_platform returns wrong value when Python 32b is running under Windows 64b In-Reply-To: <1549316025.61.0.403140167175.issue35896@roundup.psfhosted.org> Message-ID: <1549382338.86.0.519144439866.issue35896@roundup.psfhosted.org> Steve Dower added the comment: This is intentional. The "platform" here represents the Python platform (for figuring out whether native modules are compatible), and since it's the 32-bit build of Python it should specify the 32-bit platform. To find out information about the machine you are running on, look at the platform module: https://docs.python.org/3/library/platform.html ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 11:03:43 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 05 Feb 2019 16:03:43 +0000 Subject: [issue35898] The TARGETDIR variable must be provided when invoking this installer In-Reply-To: <1549369147.85.0.114900737559.issue35898@roundup.psfhosted.org> Message-ID: <1549382623.14.0.126175911428.issue35898@roundup.psfhosted.org> Steve Dower added the comment: The installer hasn't changed since 3.7, so this seems unlikely to be a new issue. I see this line in your log file: MSI (s) (A8:D0) [13:09:39:028]: Ignoring disallowed property TARGETDIR Perhaps your IT department has configured some restrictions on installers? You could try selecting the option to install for All Users, since it seems your system is trying to upgrade to that automatically. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 11:12:15 2019 From: report at bugs.python.org (Brett R) Date: Tue, 05 Feb 2019 16:12:15 +0000 Subject: [issue35737] crypt AuthenticationError introduced with new Linux kernel In-Reply-To: <1547481144.26.0.447593759473.issue35737@roundup.psfhosted.org> Message-ID: <1549383135.47.0.353782293684.issue35737@roundup.psfhosted.org> Brett R added the comment: Karthikeyan, Thank you for looking into this. I have been trying, in the background, to make further progress on this issue but progress is slow and other issues crop up. While the version of Python here is old, it was the latest in RHEL/CentOS 7.5. We are trying to get RHEL 7.6 running as well. I understand that it appears 3rd party related, but I can't get much attention from the SaltStack folks either. Appreciate your patience as I try to narrow this down further. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 11:12:16 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 05 Feb 2019 16:12:16 +0000 Subject: [issue35899] '_is_sunder' function in 'enum' module fails on empty string In-Reply-To: <1549376859.01.0.998806898699.issue35899@roundup.psfhosted.org> Message-ID: <1549383136.72.0.675121899825.issue35899@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- assignee: -> ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 11:45:56 2019 From: report at bugs.python.org (jcrmatos) Date: Tue, 05 Feb 2019 16:45:56 +0000 Subject: [issue35896] sysconfig.get_platform returns wrong value when Python 32b is running under Windows 64b In-Reply-To: <1549316025.61.0.403140167175.issue35896@roundup.psfhosted.org> Message-ID: <1549385156.66.0.934356445044.issue35896@roundup.psfhosted.org> jcrmatos added the comment: Then what is the difference between sysconfig.get_platform and sys.platform? When should we use one or the other? Maybe changing sys.platform to 'win' instead of 'win32', like was done with 'linux' in Python 3.3 (changed from 'linux2' and 'linux3') would be a step in standardization and simplification. Another one is sys.platform and sysconfig.platform return 'win32' and os.name returns 'nt'. Can't it be changed (in Python 4) to 'win', maybe with a deprecation warning starting in 3.8? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 11:50:40 2019 From: report at bugs.python.org (MultiSosnooley) Date: Tue, 05 Feb 2019 16:50:40 +0000 Subject: [issue35901] json.dumps infinite recurssion Message-ID: <1549385438.15.0.743086795547.issue35901@roundup.psfhosted.org> New submission from MultiSosnooley : ``` __import__('json').dumps(object(), default=lambda o: repr(o).encode()) ``` Produce infinite recursion on `default` function. Here is more informative example: ``` >>> def f(o): ... input(f"{o!r} {type(o)}") ... return repr(o).encode() ... >>> import json >>> json.dumps(object(), default=f) b'' b"b''" b'b"b\'\'"' b'b\'b"b\\\'\\\'"\'' b'b\'b\\\'b"b\\\\\\\'\\\\\\\'"\\\'\'' ``` ---------- components: Library (Lib) messages: 334877 nosy: MultiSosnooley priority: normal severity: normal status: open title: json.dumps infinite recurssion type: crash versions: Python 3.6, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 12:17:42 2019 From: report at bugs.python.org (pmpp) Date: Tue, 05 Feb 2019 17:17:42 +0000 Subject: [issue35896] sysconfig.get_platform returns wrong value when Python 32b is running under Windows 64b In-Reply-To: <1549316025.61.0.403140167175.issue35896@roundup.psfhosted.org> Message-ID: <1549387062.61.0.234004037769.issue35896@roundup.psfhosted.org> pmpp added the comment: > what is the difference sys.platform is defined by code path taken while compiling. it is hardcoded and really represents the os abi used of a *supported* platform, it is to be trusted. while sysconfig.get_platform() try to guess from various sources with more or less success. > changing sys.platform on windows there are a number of different abi ( eg msvc (32/64 supported) / cygwin / mingw / midipix .... ) and one should expect sys.platform to point to the correct one. The maintainers ( like steve.dower ) help choose carrefully those codes and ensure they will always work, so i think you have been answered. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 12:26:32 2019 From: report at bugs.python.org (Julien Palard) Date: Tue, 05 Feb 2019 17:26:32 +0000 Subject: [issue35055] Error when we try to download the epub archive In-Reply-To: <1540322085.68.0.788709270274.issue35055@psf.upfronthosting.co.za> Message-ID: <1549387592.11.0.609224395478.issue35055@roundup.psfhosted.org> Julien Palard added the comment: Issue has been fixed upstream IIRC: https://github.com/sphinx-doc/sphinx/pull/5574 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 13:09:59 2019 From: report at bugs.python.org (Tim Burgess) Date: Tue, 05 Feb 2019 18:09:59 +0000 Subject: [issue28411] Eliminate PyInterpreterState.modules. In-Reply-To: <1476138783.81.0.661524291989.issue28411@psf.upfronthosting.co.za> Message-ID: <1549390199.75.0.406717900071.issue28411@roundup.psfhosted.org> Change by Tim Burgess : ---------- pull_requests: +11713 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 13:10:05 2019 From: report at bugs.python.org (Tim Burgess) Date: Tue, 05 Feb 2019 18:10:05 +0000 Subject: [issue28411] Eliminate PyInterpreterState.modules. In-Reply-To: <1476138783.81.0.661524291989.issue28411@psf.upfronthosting.co.za> Message-ID: <1549390205.0.0.104142511292.issue28411@roundup.psfhosted.org> Change by Tim Burgess : ---------- pull_requests: +11713, 11714 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 13:18:37 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 05 Feb 2019 18:18:37 +0000 Subject: [issue35901] json.dumps infinite recurssion In-Reply-To: <1549385438.15.0.743086795547.issue35901@roundup.psfhosted.org> Message-ID: <1549390717.48.0.458743471692.issue35901@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: I guess json module expects a return value from default function that is str, int, float, etc. that can be handled by built in encoders and returning a bytes object with repr causes it to keep calling default until a value of one of expected type is returned. With the encoded repr producing new objects circular reference cannot be detected. In the below example I keep returning encoded repr as per the original report and then return a string once length is more than 100. I think this is something similar to https://bugs.python.org/issue21213#msg217203 . # /tmp/foo.py import json; def default(o): out = repr(o).encode() print(id(out)) if len(out) > 100: print(out) return "string" return out print(json.dumps(object(), default=default)) ./python.exe /tmp/foo.py 4329334144 4328290960 4328289400 4329073088 4328910624 4329031520 4327246416 4328875288 b'b\'b\\\'b\\\\\\\'b\\\\\\\\\\\\\\\'b\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'b"b\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'"\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'\\\\\\\\\\\\\\\'\\\\\\\'\\\'\'' "string" ---------- nosy: +ezio.melotti, rhettinger, xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 13:20:03 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Tue, 05 Feb 2019 18:20:03 +0000 Subject: [issue35897] Support list as argument to .startswith() In-Reply-To: <1549355778.94.0.606894132692.issue35897@roundup.psfhosted.org> Message-ID: <1549390803.05.0.931515113452.issue35897@roundup.psfhosted.org> R?mi Lapeyre added the comment: > A programmer want to instruct the computer to do something, without having to care about how it works. This is not true, as a programmer you need to choose carefully your data structures because they matter, for example there is a difference between doing a lookup on an indexed field in an SQL database and a field that is not indexed. As a programmer you care because it impacts the performance of your application. The linked discussion explains the difference between list and tuple in this instance. @rhettinger: while this is not hard to fix, there is no mention in the documentation about why this choice has been made. A beginner don't know about the internals of cPython, should we add a small note about the optimization done with tuple? ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 13:55:45 2019 From: report at bugs.python.org (Aron Podrigal) Date: Tue, 05 Feb 2019 18:55:45 +0000 Subject: [issue27777] cgi.FieldStorage can't parse simple body with Content-Length and no Content-Disposition In-Reply-To: <1471355745.98.0.805545529346.issue27777@psf.upfronthosting.co.za> Message-ID: <1549392945.2.0.956757181379.issue27777@roundup.psfhosted.org> Aron Podrigal added the comment: I am experiencing the same issue. https://github.com/python/cpython/pull/10771 looks good. While were at it, and if PR 10771 is accepted, maybe we can change https://github.com/python/cpython/blob/6613b56173d26f32da9945691ff9f824304224a2/Lib/cgi.py#L717 to `read` instead of `readline` since we anyway read till EOF. ---------- nosy: +Aron Podrigal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 13:57:00 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Tue, 05 Feb 2019 18:57:00 +0000 Subject: [issue27777] cgi.FieldStorage can't parse simple body with Content-Length and no Content-Disposition In-Reply-To: <1471355745.98.0.805545529346.issue27777@psf.upfronthosting.co.za> Message-ID: <1549393020.69.0.206667341601.issue27777@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 14:17:59 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 05 Feb 2019 19:17:59 +0000 Subject: [issue35896] sysconfig.get_platform returns wrong value when Python 32b is running under Windows 64b In-Reply-To: <1549316025.61.0.403140167175.issue35896@roundup.psfhosted.org> Message-ID: <1549394279.02.0.225528202142.issue35896@roundup.psfhosted.org> Steve Dower added the comment: > sys.platform is defined by code path taken while compiling. it is hardcoded and really represents the os abi used of a *supported* platform Correct, though the examples I'd give are Win32 vs. WinRT vs. Cygwin, which are fundamentally different API surfaces for interacting with the operating system. sys.platform is win32 whenever Python is built against the Win32 API. sysconfig.get_platform is win32 when packages need to be built for 32-bit Windows. It's unfortunate that they were chosen to be the same, but that's long in the past, and I don't think the confusion is worth the confusion that would occur if it changed. os.name is also odd, and honestly I'd rather it just went away completely. I'd like the module to be called "posix" everywhere, since that's the API it exposes (it's an emulation layer on non-POSIX platforms), and checks should use sys.platform. Or at worst, "_os" instead of having an importable "nt" module. But for better or worse, that's how Python is designed, and until there's a serious project to redesign aspects at this level we aren't going to see any change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 15:30:15 2019 From: report at bugs.python.org (Ned Deily) Date: Tue, 05 Feb 2019 20:30:15 +0000 Subject: [issue35055] Error when we try to download the epub archive In-Reply-To: <1540322085.68.0.788709270274.issue35055@psf.upfronthosting.co.za> Message-ID: <1549398615.83.0.0550061622653.issue35055@roundup.psfhosted.org> Ned Deily added the comment: Yes, it looks like 3.6 and 3.7 have been building properly so that's good. However, I see that there seems to be an issue with building the 3.8.0 downloadables. It looks like only the html formats are being built and that now results in 404s for the others since 3.8.0a1 has been released. @mdk, can you take a look please and close this issue when appropriate? Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 16:51:07 2019 From: report at bugs.python.org (MultiSosnooley) Date: Tue, 05 Feb 2019 21:51:07 +0000 Subject: [issue35901] json.dumps infinite recurssion In-Reply-To: <1549385438.15.0.743086795547.issue35901@roundup.psfhosted.org> Message-ID: <1549403467.17.0.586260503293.issue35901@roundup.psfhosted.org> MultiSosnooley added the comment: Oh, I got it. Size is too high growing to reach recurtion limit. I replace repr with slow growing data and now there is good old recursion limit exception. import json class F: counter = 0 total = 0 data = b"" def __call__(self, o): self.counter += 1 self.data = b"1" + self.data self.total += len(self.data) print(self.counter, len(self.data), self.total) return self.data json.dumps(object(), default=F()) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 17:17:52 2019 From: report at bugs.python.org (Vadim Tsozik) Date: Tue, 05 Feb 2019 22:17:52 +0000 Subject: [issue35902] Forking from background thread Message-ID: <1549405071.04.0.889820238084.issue35902@roundup.psfhosted.org> New submission from Vadim Tsozik : Attached is code sample that forks child process either from main or from background thread. Child starts and joins all of its threads except a sleeping daemon. If parent forks child from main thread program exits immediately after child threads are joined and waitpid is unblocked by SIGCHLD. However if parent process happens to fork from main thread everything works correctly and process exits immediately without waiting for daemon to sleep for 3600 seconds. I'm wondering what is the difference between main and background thread in parent. Only one thread survives forking in child and becomes main thread in the child, so there should be no differences in the behavior. Thank you in advance for your help, ---------- components: Build files: threadforkmodel.py messages: 334886 nosy: vtsozik priority: normal severity: normal status: open title: Forking from background thread type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: https://bugs.python.org/file48103/threadforkmodel.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 17:31:27 2019 From: report at bugs.python.org (Christian Heimes) Date: Tue, 05 Feb 2019 22:31:27 +0000 Subject: [issue35902] Forking from background thread In-Reply-To: <1549405071.04.0.889820238084.issue35902@roundup.psfhosted.org> Message-ID: <1549405887.11.0.464461197658.issue35902@roundup.psfhosted.org> Christian Heimes added the comment: In general threads and forks don't mix well. If you fork from any thread but the main thread, you can run into undefined behavior. Daemon threads are a special property of Python's threading model. You need to have one non-daemon thread running to keep the process active. A Python process exits when all remaining threads are daemon threads. ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 17:40:45 2019 From: report at bugs.python.org (Roundup Robot) Date: Tue, 05 Feb 2019 22:40:45 +0000 Subject: [issue27777] cgi.FieldStorage can't parse simple body with Content-Length and no Content-Disposition In-Reply-To: <1471355745.98.0.805545529346.issue27777@psf.upfronthosting.co.za> Message-ID: <1549406445.61.0.925674822392.issue27777@roundup.psfhosted.org> Change by Roundup Robot : ---------- pull_requests: +11715 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 17:41:01 2019 From: report at bugs.python.org (Roundup Robot) Date: Tue, 05 Feb 2019 22:41:01 +0000 Subject: [issue27777] cgi.FieldStorage can't parse simple body with Content-Length and no Content-Disposition In-Reply-To: <1471355745.98.0.805545529346.issue27777@psf.upfronthosting.co.za> Message-ID: <1549406461.86.0.466140579464.issue27777@roundup.psfhosted.org> Change by Roundup Robot : ---------- pull_requests: +11715, 11716 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 17:41:18 2019 From: report at bugs.python.org (Roundup Robot) Date: Tue, 05 Feb 2019 22:41:18 +0000 Subject: [issue27777] cgi.FieldStorage can't parse simple body with Content-Length and no Content-Disposition In-Reply-To: <1471355745.98.0.805545529346.issue27777@psf.upfronthosting.co.za> Message-ID: <1549406478.92.0.383138094457.issue27777@roundup.psfhosted.org> Change by Roundup Robot : ---------- pull_requests: +11715, 11716, 11717 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 17:41:36 2019 From: report at bugs.python.org (Roundup Robot) Date: Tue, 05 Feb 2019 22:41:36 +0000 Subject: [issue27777] cgi.FieldStorage can't parse simple body with Content-Length and no Content-Disposition In-Reply-To: <1471355745.98.0.805545529346.issue27777@psf.upfronthosting.co.za> Message-ID: <1549406496.34.0.188768558125.issue27777@roundup.psfhosted.org> Change by Roundup Robot : ---------- pull_requests: +11715, 11716, 11717, 11718 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 17:50:24 2019 From: report at bugs.python.org (Neil Schemenauer) Date: Tue, 05 Feb 2019 22:50:24 +0000 Subject: [issue35903] Build of posixshmem.c should probe for required OS functions Message-ID: <1549407022.09.0.0256128012498.issue35903@roundup.psfhosted.org> New submission from Neil Schemenauer : The logic in setup.py that determines if _multiprocessing/posixshmem.c should get built is not very robust. I think it is better to use autoconfig to probe for the required functions and libraries. My autoconfig brain cells are a bit fuzzy but I think my patch is correct. I look for shm_open and shm_unlink. I also check if librt is required for these functions. ---------- assignee: davin components: Build keywords: patch messages: 334888 nosy: davin, nascheme priority: normal severity: normal stage: patch review status: open title: Build of posixshmem.c should probe for required OS functions type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 17:52:01 2019 From: report at bugs.python.org (Neil Schemenauer) Date: Tue, 05 Feb 2019 22:52:01 +0000 Subject: [issue35903] Build of posixshmem.c should probe for required OS functions In-Reply-To: <1549407022.09.0.0256128012498.issue35903@roundup.psfhosted.org> Message-ID: <1549407121.81.0.846968775345.issue35903@roundup.psfhosted.org> Change by Neil Schemenauer : ---------- pull_requests: +11719 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 17:52:05 2019 From: report at bugs.python.org (Neil Schemenauer) Date: Tue, 05 Feb 2019 22:52:05 +0000 Subject: [issue35903] Build of posixshmem.c should probe for required OS functions In-Reply-To: <1549407022.09.0.0256128012498.issue35903@roundup.psfhosted.org> Message-ID: <1549407125.67.0.184416339824.issue35903@roundup.psfhosted.org> Change by Neil Schemenauer : ---------- pull_requests: +11719, 11720 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 17:52:09 2019 From: report at bugs.python.org (Neil Schemenauer) Date: Tue, 05 Feb 2019 22:52:09 +0000 Subject: [issue35903] Build of posixshmem.c should probe for required OS functions In-Reply-To: <1549407022.09.0.0256128012498.issue35903@roundup.psfhosted.org> Message-ID: <1549407129.85.0.90096572564.issue35903@roundup.psfhosted.org> Change by Neil Schemenauer : ---------- pull_requests: +11719, 11720, 11721 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 18:01:04 2019 From: report at bugs.python.org (Aron Podrigal) Date: Tue, 05 Feb 2019 23:01:04 +0000 Subject: [issue27777] cgi.FieldStorage can't parse simple body with Content-Length and no Content-Disposition In-Reply-To: <1471355745.98.0.805545529346.issue27777@psf.upfronthosting.co.za> Message-ID: <1549407664.73.0.868209791259.issue27777@roundup.psfhosted.org> Aron Podrigal added the comment: A different approach. Always honor content length, and do not try to read more than. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 18:08:44 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 05 Feb 2019 23:08:44 +0000 Subject: [issue35851] Make search result in online docs keep their position when search finishes In-Reply-To: <1548772807.63.0.497905321537.issue35851@roundup.psfhosted.org> Message-ID: <1549408124.65.0.408777250755.issue35851@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: This is fixed upstream and will be available as Sphinx is upgraded. Closing it now. Thanks @roelschroeven for the report. Upstream PR : https://github.com/sphinx-doc/sphinx/pull/6018 ---------- resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 18:13:32 2019 From: report at bugs.python.org (Vadim Tsozik) Date: Tue, 05 Feb 2019 23:13:32 +0000 Subject: [issue35902] Forking from background thread In-Reply-To: <1549405071.04.0.889820238084.issue35902@roundup.psfhosted.org> Message-ID: <1549408412.86.0.0795671687567.issue35902@roundup.psfhosted.org> Vadim Tsozik added the comment: Thank you for your reply. I understand that forking and threads do not mix well if developer is not careful and child doesn't clear/reset synchronization variables inherited from parent. However this is not the case in provided code sample. The answer to my question is probably related to the fact that only main thread handles signaling by default in POSIX. But in the provided example parent background thread becomes main in the child. In parent it doesn't matter if waitpid blocks on main or background thread. The only thing really matters if code forks from main or background threads. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 18:35:59 2019 From: report at bugs.python.org (Charalampos Stratakis) Date: Tue, 05 Feb 2019 23:35:59 +0000 Subject: [issue35737] crypt AuthenticationError introduced with new Linux kernel In-Reply-To: <1547481144.26.0.447593759473.issue35737@roundup.psfhosted.org> Message-ID: <1549409759.7.0.750840755962.issue35737@roundup.psfhosted.org> Charalampos Stratakis added the comment: Hi Brett, Those issues should be reported on Red Hat's bugzilla, if it's definite that the kernel version (or a new cpython release downstream) is the one to blame for it. Also RHEL 7's python version while being 2.7.5, carries many additional patches on top with various fixes from later versions, so it wouldn't be easy to bisect an issue by relying solely on the upstream sources. However it really does seem like a saltstack issue. An easier reproducer would be of great help here. As suggested before you should also try if possible, to make saltstack utilize the latest compiled python2 sources from github. ---------- nosy: +cstratak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 18:59:22 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 05 Feb 2019 23:59:22 +0000 Subject: [issue35904] Add statistics.fmean(seq) Message-ID: <1549411161.36.0.783593325223.issue35904@roundup.psfhosted.org> New submission from Raymond Hettinger : The current mean() function makes heroic efforts to achieve last bit accuracy and when possible to retain the data type of the input. What is needed is an alternative that has a simpler signature, that is much faster, that is highly accurate without demanding perfection, and that is usually what people expect mean() is going to do, the same as their calculators or numpy.mean(): def fmean(seq: Sequence[float]) -> float: return math.fsum(seq) / len(seq) On my current 3.8 build, this code given an approx 500x speed-up (almost three orders of magnitude). Note that having a fast fmean() function is important in resampling statistics where the mean() is typically called many times: http://statistics.about.com/od/Applications/a/Example-Of-Bootstrapping.htm $ ./python.exe -m timeit -r 11 -s 'from random import random' -s 'from statistics import mean' -s 'seq = [random() for i in range(10_000)]' 'mean(seq)' 50 loops, best of 11: 6.8 msec per loop $ ./python.exe -m timeit -r 11 -s 'from random import random' -s 'from math import fsum' -s 'mean=lambda seq: fsum(seq)/len(seq)' -s 'seq = [random() for i in range(10_000)]' 'mean(seq)' 2000 loops, best of 11: 155 usec per loop ---------- assignee: steven.daprano components: Library (Lib) messages: 334894 nosy: rhettinger, steven.daprano, tim.peters priority: normal severity: normal status: open title: Add statistics.fmean(seq) type: behavior versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 19:12:23 2019 From: report at bugs.python.org (Jason R. Coombs) Date: Wed, 06 Feb 2019 00:12:23 +0000 Subject: [issue35905] macOS build docs need refresh (2019) Message-ID: <1549411942.7.0.0722764247373.issue35905@roundup.psfhosted.org> New submission from Jason R. Coombs : In https://github.com/python/devguide/issues/453#issuecomment-460848565, I understand that Ned wishes to update the macOS build docs prior to linking to them from the dev guide. ---------- assignee: docs at python components: Documentation messages: 334895 nosy: docs at python, jason.coombs, ned.deily priority: normal severity: normal status: open title: macOS build docs need refresh (2019) versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 19:13:45 2019 From: report at bugs.python.org (Ned Deily) Date: Wed, 06 Feb 2019 00:13:45 +0000 Subject: [issue35905] macOS build docs need refresh (2019) In-Reply-To: <1549411942.7.0.0722764247373.issue35905@roundup.psfhosted.org> Message-ID: <1549412025.98.0.188204565611.issue35905@roundup.psfhosted.org> Change by Ned Deily : ---------- assignee: docs at python -> ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 19:30:41 2019 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 Feb 2019 00:30:41 +0000 Subject: [issue35894] Apparent regression in 3.8-dev: 'TypeError: required field "type_ignores" missing from Module' In-Reply-To: <1549256747.48.0.424452103214.issue35894@roundup.psfhosted.org> Message-ID: <1549413041.65.0.408847840681.issue35894@roundup.psfhosted.org> Change by Guido van Rossum : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 19:32:12 2019 From: report at bugs.python.org (Sihoon Lee) Date: Wed, 06 Feb 2019 00:32:12 +0000 Subject: [issue35906] Header Injection in urllib Message-ID: <1549413131.7.0.216595978501.issue35906@roundup.psfhosted.org> New submission from Sihoon Lee : this patch can also be broken by path and query string. http://www.cvedetails.com/cve/CVE-2016-5699/ https://bugs.python.org/issue30458 can succeed to inject HTTP header and be more critical by bypassing illegal header check # Vulnerability PoC >>> import urllib.request >>> urllib.request.urlopen('http://127.0.0.1:1234/?q=HTTP/1.1\r\nHeader: Value\r\nHeader2: \r\n') or >>> urllib.request.urlopen('http://127.0.0.1:1234/HTTP/1.1\r\nHeader: Value\r\nHeader2: \r\n') > nc -lv 1234 GET /?q=HTTP/1.1 Header: Value Header2: HTTP/1.1 Accept-Encoding: identity Host: 127.0.0.1:1234 User-Agent: Python-urllib/3.8 Connection: close we can inject headers completely. ## Redis redis also be affected by bypassing SSRF protection checking header "host:" with this injection. >>> urllib2.urlopen('http://127.0.0.1:6379/?q=HTTP/1.1\r\nSET VULN POC\r\nHeader2:\r\n').read() '$-1\r\n+OK\r\n-ERR unknown command `Header2:`, with args beginning with: `HTTP/1.1`, \r\n-ERR unknown command `Accept-Encoding:`, with args beginning with: `identity`, \r\n' $ redis-cli 127.0.0.1:6379> GET VULN "POC" # Root Cause https://github.com/python/cpython/commit/cc54c1c0d2d05fe7404ba64c53df4b1352ed2262 - _hostprog = re.compile('^//([^/?]*)(.*)$') + _hostprog = re.compile('//([^/#?]*)(.*)', re.DOTALL) It could succeed to parse host because of re.DOTALL re.DOTALL gave the opportunity of injection. this version of the commit was 3.4.7+ this vulnerability can be affected 3.4.7+ ~ 3.8-dev <- I tested it. also, python 2.7.15 can be affected. I don't know which python2 version is affected because not test. maybe after the commit, all of higher versions can trigger this vulnerability. # Conclusion this patch provides more critical vulnerability to bypass the illegal header check. and we can inject HTTP header completely in urlopen() from this patch. (Although this vulnerability is old on 12 Jul 2017, I don't know why no one has submitted issue still now XDD) ---------- components: Library (Lib) messages: 334896 nosy: push0ebp priority: normal severity: normal status: open title: Header Injection in urllib type: security versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 19:33:33 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 06 Feb 2019 00:33:33 +0000 Subject: [issue35906] Header Injection in urllib In-Reply-To: <1549413131.7.0.216595978501.issue35906@roundup.psfhosted.org> Message-ID: <1549413213.12.0.989473120405.issue35906@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 19:36:15 2019 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 Feb 2019 00:36:15 +0000 Subject: [issue35766] Merge typed_ast back into CPython In-Reply-To: <1547771581.08.0.389360423635.issue35766@roundup.psfhosted.org> Message-ID: <1549413375.83.0.896266641921.issue35766@roundup.psfhosted.org> Change by Guido van Rossum : ---------- pull_requests: +11723 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 19:36:28 2019 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 Feb 2019 00:36:28 +0000 Subject: [issue35766] Merge typed_ast back into CPython In-Reply-To: <1547771581.08.0.389360423635.issue35766@roundup.psfhosted.org> Message-ID: <1549413388.42.0.958385543706.issue35766@roundup.psfhosted.org> Change by Guido van Rossum : ---------- pull_requests: +11723, 11724 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 19:36:39 2019 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 Feb 2019 00:36:39 +0000 Subject: [issue35766] Merge typed_ast back into CPython In-Reply-To: <1547771581.08.0.389360423635.issue35766@roundup.psfhosted.org> Message-ID: <1549413399.04.0.87885897581.issue35766@roundup.psfhosted.org> Change by Guido van Rossum : ---------- pull_requests: +11723, 11724, 11725 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 19:53:43 2019 From: report at bugs.python.org (Jason R. Coombs) Date: Wed, 06 Feb 2019 00:53:43 +0000 Subject: [issue24209] Allow IPv6 bind in http.server In-Reply-To: <1431784485.93.0.0140060801451.issue24209@psf.upfronthosting.co.za> Message-ID: <1549414423.02.0.382258268498.issue24209@roundup.psfhosted.org> Jason R. Coombs added the comment: I don't believe the current patch as accepted has the right behaviors. First off, the default behavior, which indicates "all interfaces" only binds to IPv4 interfaces. Additionally, "-b localhost" only binds to IPv4 localhost. Ideally, the bind should happen on all stacks unless a specific stack is indicated. ---------- assignee: -> jason.coombs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 20:33:11 2019 From: report at bugs.python.org (Jason R. Coombs) Date: Wed, 06 Feb 2019 01:33:11 +0000 Subject: [issue24209] Allow IPv6 bind in http.server In-Reply-To: <1431784485.93.0.0140060801451.issue24209@psf.upfronthosting.co.za> Message-ID: <1549416791.54.0.970923989226.issue24209@roundup.psfhosted.org> Change by Jason R. Coombs : ---------- pull_requests: +11726 stage: resolved -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 20:33:27 2019 From: report at bugs.python.org (Jason R. Coombs) Date: Wed, 06 Feb 2019 01:33:27 +0000 Subject: [issue24209] Allow IPv6 bind in http.server In-Reply-To: <1431784485.93.0.0140060801451.issue24209@psf.upfronthosting.co.za> Message-ID: <1549416807.0.0.88825234836.issue24209@roundup.psfhosted.org> Change by Jason R. Coombs : ---------- pull_requests: +11726, 11727 stage: resolved -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 20:33:41 2019 From: report at bugs.python.org (Jason R. Coombs) Date: Wed, 06 Feb 2019 01:33:41 +0000 Subject: [issue24209] Allow IPv6 bind in http.server In-Reply-To: <1431784485.93.0.0140060801451.issue24209@psf.upfronthosting.co.za> Message-ID: <1549416821.21.0.118426826131.issue24209@roundup.psfhosted.org> Change by Jason R. Coombs : ---------- pull_requests: +11726, 11727, 11728 stage: resolved -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 20:50:06 2019 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 06 Feb 2019 01:50:06 +0000 Subject: [issue35905] macOS build docs need refresh (2019) In-Reply-To: <1549411942.7.0.0722764247373.issue35905@roundup.psfhosted.org> Message-ID: <1549417806.63.0.599631775957.issue35905@roundup.psfhosted.org> Change by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 20:51:31 2019 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 06 Feb 2019 01:51:31 +0000 Subject: [issue35905] macOS build docs need refresh (2019) In-Reply-To: <1549411942.7.0.0722764247373.issue35905@roundup.psfhosted.org> Message-ID: <1549417891.99.0.975607243764.issue35905@roundup.psfhosted.org> Barry A. Warsaw added the comment: All I know is that for 3.7 and 3.8 (3.6 is different), I have this little helper script to build against Homebrew libraries. #!/bin/sh export CPPFLAGS="-I$(brew --prefix sqlite3)/include -I$(brew --prefix zlib)/include" export LDFLAGS="-L$(brew --prefix sqlite3)/lib -L$(brew --prefix zlib)/lib" export PKG_CONFIG_PATH="/usr/local/opt/openssl/lib/pkgconfig" ./configure ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 21:06:06 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 06 Feb 2019 02:06:06 +0000 Subject: [issue35904] Add statistics.fmean(seq) In-Reply-To: <1549411161.36.0.783593325223.issue35904@roundup.psfhosted.org> Message-ID: <1549418766.69.0.126716275849.issue35904@roundup.psfhosted.org> Josh Rosenberg added the comment: Correct me if I'm wrong, but at least initially, the first listed goal of statistics (per the PEP) was: "Correctness over speed. It is easier to speed up a correct but slow function than to correct a fast but buggy one." numpy already exists for people who need insane speed for these algorithms and are willing to compromise accuracy; am I wrong in my impression that statistics is more about providing correct batteries included that are fast enough for simple uses, not reimplementing numpy piece by piece for hardcore number crunching? Even if such a function were desirable, I don't like the naming symmetry between fsum and fmean; it's kind of misleading. math.fsum is a slower, but more precise, version of the built-in sum. Having statistics.fmean be a faster, less accurate, version of statistics.mean reverses that relationship between the f-prefixed and non-f-prefixed versions of a function. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 21:23:47 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Wed, 06 Feb 2019 02:23:47 +0000 Subject: [issue35906] Header Injection in urllib In-Reply-To: <1549413131.7.0.216595978501.issue35906@roundup.psfhosted.org> Message-ID: <1549419827.7.0.840248569331.issue35906@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 22:17:29 2019 From: report at bugs.python.org (Davin Potts) Date: Wed, 06 Feb 2019 03:17:29 +0000 Subject: [issue35903] Build of posixshmem.c should probe for required OS functions In-Reply-To: <1549407022.09.0.0256128012498.issue35903@roundup.psfhosted.org> Message-ID: <1549423049.95.0.585354486452.issue35903@roundup.psfhosted.org> Davin Potts added the comment: Agreed that the logic for building that code needs exactly this sort of change. Thanks for the patch! It looks like your patch does not happily detect the dependencies on MacOS for some reason, but all appears well on Windows & Linux. I will have a closer look in the morning on a MacOS system. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 23:03:25 2019 From: report at bugs.python.org (Neil Schemenauer) Date: Wed, 06 Feb 2019 04:03:25 +0000 Subject: [issue35903] Build of posixshmem.c should probe for required OS functions In-Reply-To: <1549407022.09.0.0256128012498.issue35903@roundup.psfhosted.org> Message-ID: <1549425805.03.0.906814180401.issue35903@roundup.psfhosted.org> Neil Schemenauer added the comment: I didn't understand autoconfig well enough but I think I fixed it now. Apparently MacOS is a platform where it has shm_open but you don't need to link with -lrt. The revised 'configure' should handle that correctly now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 5 23:07:26 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 06 Feb 2019 04:07:26 +0000 Subject: [issue35904] Add statistics.fmean(seq) In-Reply-To: <1549411161.36.0.783593325223.issue35904@roundup.psfhosted.org> Message-ID: <1549426046.05.0.656242406738.issue35904@roundup.psfhosted.org> Raymond Hettinger added the comment: > Correctness over speed. Are you saying that "fsum(seq) / len(seq)" is incorrect because on some older builds there is a rare possibility of an error of 1 unit in the last place? Just about everyone who uses this module will not care one whit about that. ISTM, a requirement for exactness violates "practicality beats purity". We really don't want to be in the position of advising people to never use this module because of design choices that aren't in line with user needs. > It is easier to speed up a correct but slow function > than to correct a fast but buggy one. Taken to an extreme, this could be used justify a BubbleSort. In the case of statistics.mean(), slowness of three orders of magnitude makes this a nearly catastrophic choice for real world use. > I don't like the naming symmetry between fsum and fmean; Any reasonable name will suffice. I suggested an f prefix that could be taken to mean that it is "fast" or that it returns a "float". It isn't much different than isqrt() for an integer square root. > numpy already exists for people who need insane speed for these algorithms > and are willing to compromise accuracy; Let's see what Steven and Tim think about this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 01:16:48 2019 From: report at bugs.python.org (Henry Chen) Date: Wed, 06 Feb 2019 06:16:48 +0000 Subject: [issue35812] Don't log an exception from the main coroutine in asyncio.run() In-Reply-To: <1548291532.01.0.358121522852.issue35812@roundup.psfhosted.org> Message-ID: <1549433808.19.0.155241436017.issue35812@roundup.psfhosted.org> Henry Chen added the comment: I'm having trouble reproducing this issue. The main_coro seems to disappear when an exception is raised in it, so that it does not show up in the set of tasks to cancel. I'm probably misunderstanding something basic here. Is it possible to provide a minimal example? ---------- nosy: +scotchka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 01:41:15 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 06 Feb 2019 06:41:15 +0000 Subject: [issue35902] Forking from background thread In-Reply-To: <1549405071.04.0.889820238084.issue35902@roundup.psfhosted.org> Message-ID: <1549435275.01.0.981572172601.issue35902@roundup.psfhosted.org> Raymond Hettinger added the comment: Unless it's clear that there is a buggy behavior or a useful feature request, it would be better to move this to StackOverflow which is a more appropriate forum for general questions on how Python works internally. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 03:19:53 2019 From: report at bugs.python.org (Sihoon Lee) Date: Wed, 06 Feb 2019 08:19:53 +0000 Subject: [issue35907] Unnecessary URL scheme exists to allow file:// reading file in urllib Message-ID: <1549441191.29.0.148559977828.issue35907@roundup.psfhosted.org> New submission from Sihoon Lee : The Unnecessary scheme exists in urlopen() urllib when people would protect to read file system in HTTP request of urlopen(), they often filter like this against SSRF. # Vulnerability PoC import urllib print urllib.urlopen('local_file:///etc/passwd').read()[:30] the result is ## # User Database # # Note t but if we use a scheme like this, parsing URL cannot parse scheme with urlparse() this is the parsed result. ParseResult(scheme='', netloc='', path='local_file:/etc/passwd', params='', query='', fragment='') def request(url): from urllib import urlopen from urlparse import urlparse result = urlparse(url) scheme = result.scheme if not scheme: return False #raise Exception("Required scheme") if scheme == 'file': return False #raise Exception("Don't open file") res = urlopen(url) content = res.read() print url, content[:30] return True assert request('file:///etc/passwd') == False assert request(' file:///etc/passwd') == False assert request('File:///etc/passwd') == False assert request('http://www.google.com') != False if they filter only file://, this mitigation can be bypassed against SSRF. with this way. assert request('local-file:/etc/passwd') == True ParseResult(scheme='local-file', netloc='', path='/etc/passwd', params='', query='', fragment='') parseing URL also can be passed. # Attack scenario this is the unnecessary URL scheme("local_file"). even if it has filtering, An Attacker can read arbitrary files as bypassing with it. # Root Cause URLopener::open in urllib.py from 203 lin name = 'open_' + urltype self.type = urltype name = name.replace('-', '_') #it can also allows local-file if not hasattr(self, name): #passed here hasattr(URLopener, 'open_local_file') if proxy: return self.open_unknown_proxy(proxy, fullurl, data) else: return self.open_unknown(fullurl, data) try: if data is None: return getattr(self, name)(url) else: return getattr(self, name)(url, data) #return URLopener::open_local_file it may be just trick because people usually use whitelist (allow only http or https. Even if but anyone may use blacklist like filtering file://, they will be affected with triggering SSRF ---------- components: Library (Lib) messages: 334905 nosy: push0ebp priority: normal severity: normal status: open title: Unnecessary URL scheme exists to allow file:// reading file in urllib type: security versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 03:30:28 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 06 Feb 2019 08:30:28 +0000 Subject: [issue35906] Header Injection in urllib In-Reply-To: <1549413131.7.0.216595978501.issue35906@roundup.psfhosted.org> Message-ID: <1549441828.5.0.769582070403.issue35906@roundup.psfhosted.org> Change by St?phane Wirtel : ---------- keywords: +patch pull_requests: +11729 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 03:30:36 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 06 Feb 2019 08:30:36 +0000 Subject: [issue35906] Header Injection in urllib In-Reply-To: <1549413131.7.0.216595978501.issue35906@roundup.psfhosted.org> Message-ID: <1549441836.21.0.537562744952.issue35906@roundup.psfhosted.org> Change by St?phane Wirtel : ---------- keywords: +patch, patch pull_requests: +11729, 11730 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 03:30:42 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 06 Feb 2019 08:30:42 +0000 Subject: [issue35906] Header Injection in urllib In-Reply-To: <1549413131.7.0.216595978501.issue35906@roundup.psfhosted.org> Message-ID: <1549441842.54.0.784085382992.issue35906@roundup.psfhosted.org> Change by St?phane Wirtel : ---------- keywords: +patch, patch, patch pull_requests: +11729, 11730, 11731 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 03:32:11 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 06 Feb 2019 08:32:11 +0000 Subject: [issue35906] Header Injection in urllib In-Reply-To: <1549413131.7.0.216595978501.issue35906@roundup.psfhosted.org> Message-ID: <1549441931.8.0.927613173167.issue35906@roundup.psfhosted.org> St?phane Wirtel added the comment: Hi all, Not sure for the right way for this fix but here is a PR. I am interested by your feedback. Thank you ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 03:48:23 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 06 Feb 2019 08:48:23 +0000 Subject: [issue35903] Build of posixshmem.c should probe for required OS functions In-Reply-To: <1549407022.09.0.0256128012498.issue35903@roundup.psfhosted.org> Message-ID: <1549442903.56.0.429514386433.issue35903@roundup.psfhosted.org> Ronald Oussoren added the comment: @Neil: On what version of macOS did you test? On 10.14.3 with Xcode 10.1 shm_open is in libSystem (that's named libc on most other unixy systems) and there is no library named librt. ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 03:55:55 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 06 Feb 2019 08:55:55 +0000 Subject: [issue35906] Header Injection in urllib In-Reply-To: <1549413131.7.0.216595978501.issue35906@roundup.psfhosted.org> Message-ID: <1549443355.56.0.155539612615.issue35906@roundup.psfhosted.org> Change by St?phane Wirtel : ---------- pull_requests: -11731 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 03:56:06 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 06 Feb 2019 08:56:06 +0000 Subject: [issue35906] Header Injection in urllib In-Reply-To: <1549413131.7.0.216595978501.issue35906@roundup.psfhosted.org> Message-ID: <1549443366.8.0.0445774430431.issue35906@roundup.psfhosted.org> Change by St?phane Wirtel : ---------- pull_requests: -11730 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 03:57:57 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 06 Feb 2019 08:57:57 +0000 Subject: [issue35907] Unnecessary URL scheme exists to allow file:// reading file in urllib In-Reply-To: <1549441191.29.0.148559977828.issue35907@roundup.psfhosted.org> Message-ID: <1549443477.68.0.882706744947.issue35907@roundup.psfhosted.org> Change by St?phane Wirtel : ---------- nosy: +christian.heimes, martin.panter, matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 03:58:50 2019 From: report at bugs.python.org (Matthias Klose) Date: Wed, 06 Feb 2019 08:58:50 +0000 Subject: [issue35908] build with building extension modules as builtins is broken in 3.8 Message-ID: <1549443528.5.0.674313815796.issue35908@roundup.psfhosted.org> New submission from Matthias Klose : the build with building extension modules as builtins is broken in 3.8. I assume that is some fallout from the header re-organization. It shows in the link step by having undefined references. Undefined symbols are listed below. Still looking where the behavior change was introduced, but help would be appreciated. ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: libpython3.8m.a(longobject.o):./build-static/../Include/object.h:434: more undefined references to `_PyTraceMalloc_NewReference' follow ./build-static/../Objects/longobject.c:1742: undefined reference to `PyErr_CheckSignals' ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' ./build-static/../Objects/longobject.c:2769: undefined reference to `PyErr_CheckSignals' ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: libpython3.8m.a(longobject.o):./build-static/../Include/object.h:434: more undefined references to `_PyTraceMalloc_NewReference' follow ./build-static/../Objects/longobject.c:3309: undefined reference to `PyErr_CheckSignals' ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' ./build-static/../Objects/longobject.c:3271: undefined reference to `PyErr_CheckSignals' ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: libpython3.8m.a(longobject.o):./build-static/../Include/object.h:434: more undefined references to `_PyTraceMalloc_NewReference' follow ./build-static/../Objects/unicodeobject.c:3766: undefined reference to `PyOS_FSPath' ./build-static/../Objects/unicodeobject.c:3808: undefined reference to `PyOS_FSPath' ./build-static/../Python/pylifecycle.c:2019: undefined reference to `_PyFaulthandler_Fini' /usr/bin/ld: ./build-static/../Python/pylifecycle.c:2019: undefined reference to `_PyFaulthandler_Fini' ./build-static/../Python/pylifecycle.c:1091: undefined reference to `PyOS_FiniInterrupts' /usr/bin/ld: ./build-static/../Python/pylifecycle.c:1143: undefined reference to `_PyTraceMalloc_Fini' /usr/bin/ld: ./build-static/../Python/pylifecycle.c:1152: undefined reference to `_PyFaulthandler_Fini' ./build-static/../Python/pylifecycle.c:860: undefined reference to `_PyFaulthandler_Init' ./build-static/../Python/pylifecycle.c:2150: undefined reference to `PyOS_InitInterrupts' ./build-static/../Python/pylifecycle.c:877: undefined reference to `_PyTraceMalloc_Init' ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: libpython3.8m.a(bytesobject.o):./build-static/../Include/object.h:434: more undefined references to `_PyTraceMalloc_NewReference' follow ./build-static/../Python/ceval.c:383: undefined reference to `PyErr_CheckSignals' ./build-static/../Python/errors.c:497: undefined reference to `PyErr_CheckSignals' /usr/bin/ld: ./build-static/../Python/errors.c:497: undefined reference to `PyErr_CheckSignals' /usr/bin/ld: ./build-static/../Python/errors.c:497: undefined reference to `PyErr_CheckSignals' /usr/bin/ld: ./build-static/../Python/errors.c:497: undefined reference to `PyErr_CheckSignals' ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: libpython3.8m.a(object.o):./build-static/../Include/object.h:434: more undefined references to `_PyTraceMalloc_NewReference' follow ./build-static/../Objects/object.c:486: undefined reference to `PyErr_CheckSignals' ./build-static/../Objects/object.c:533: undefined reference to `PyErr_CheckSignals' ./build-static/../Objects/object.c:342: undefined reference to `PyErr_CheckSignals' ./build-static/../Objects/object.c:2132: undefined reference to `_PyMem_DumpTraceback' ./build-static/../Objects/obmalloc.c:2392: undefined reference to `_PyMem_DumpTraceback' /usr/bin/ld: ./build-static/../Objects/obmalloc.c:2392: undefined reference to `_PyMem_DumpTraceback' ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' ./build-static/../Python/marshal.c:308: undefined reference to `_Py_hashtable_get_entry' /usr/bin/ld: ./build-static/../Python/marshal.c:326: undefined reference to `_Py_hashtable_set' /usr/bin/ld: ./build-static/../Python/marshal.c:308: undefined reference to `_Py_hashtable_get_entry' ./build-static/../Python/marshal.c:571: undefined reference to `_Py_hashtable_compare_direct' /usr/bin/ld: ./build-static/../Python/marshal.c:571: undefined reference to `_Py_hashtable_hash_ptr' /usr/bin/ld: ./build-static/../Python/marshal.c:571: undefined reference to `_Py_hashtable_new' ./build-static/../Python/marshal.c:597: undefined reference to `_Py_hashtable_foreach' /usr/bin/ld: ./build-static/../Python/marshal.c:598: undefined reference to `_Py_hashtable_destroy' ./build-static/../Python/marshal.c:326: undefined reference to `_Py_hashtable_set' ./build-static/../Python/marshal.c:597: undefined reference to `_Py_hashtable_foreach' /usr/bin/ld: ./build-static/../Python/marshal.c:598: undefined reference to `_Py_hashtable_destroy' ./build-static/../Python/marshal.c:571: undefined reference to `_Py_hashtable_compare_direct' /usr/bin/ld: ./build-static/../Python/marshal.c:571: undefined reference to `_Py_hashtable_hash_ptr' /usr/bin/ld: ./build-static/../Python/marshal.c:571: undefined reference to `_Py_hashtable_new' ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' ./build-static/../Python/bootstrap_hash.c:175: undefined reference to `PyErr_CheckSignals' ./build-static/../Python/traceback.c:572: undefined reference to `PyErr_CheckSignals' ./build-static/../Python/fileutils.c:1270: undefined reference to `PyErr_CheckSignals' ./build-static/../Python/fileutils.c:1442: undefined reference to `PyErr_CheckSignals' ./build-static/../Python/fileutils.c:1506: undefined reference to `PyErr_CheckSignals' /usr/bin/ld: libpython3.8m.a(fileutils.o):./build-static/../Python/fileutils.c:1560: more undefined references to `PyErr_CheckSignals' follow ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' ./build-static/../Modules/_posixsubprocess.c:687: undefined reference to `PyOS_BeforeFork' /usr/bin/ld: ./build-static/../Modules/_posixsubprocess.c:725: undefined reference to `PyOS_AfterFork_Parent' /usr/bin/ld: ./build-static/../Modules/_posixsubprocess.c:705: undefined reference to `PyOS_AfterFork_Child' ./build-static/../Modules/fcntlmodule.c:422: undefined reference to `PyErr_CheckSignals' ./build-static/../Modules/fcntlmodule.c:296: undefined reference to `PyErr_CheckSignals' ./build-static/../Modules/fcntlmodule.c:83: undefined reference to `PyErr_CheckSignals' /usr/bin/ld: ./build-static/../Modules/fcntlmodule.c:104: undefined reference to `PyErr_CheckSignals' ./build-static/../Modules/grpmodule.c:75: undefined reference to `_PyLong_FromGid' ./build-static/../Modules/grpmodule.c:107: undefined reference to `_Py_Gid_Converter' /usr/bin/ld: ./build-static/../Modules/grpmodule.c:120: undefined reference to `_Py_Gid_Converter' /usr/bin/ld: ./build-static/../Modules/grpmodule.c:169: undefined reference to `_PyLong_FromGid' ./build-static/../Modules/selectmodule.c:638: undefined reference to `PyErr_CheckSignals' ./build-static/../Modules/selectmodule.c:1563: undefined reference to `PyErr_CheckSignals' ./build-static/../Modules/selectmodule.c:332: undefined reference to `PyErr_CheckSignals' /usr/bin/ld: ./build-static/../Modules/selectmodule.c:332: undefined reference to `PyErr_CheckSignals' ./build-static/../Modules/socketmodule.c:903: undefined reference to `PyErr_CheckSignals' /usr/bin/ld: libpython3.8m.a(socketmodule.o):./build-static/../Modules/socketmodule.c:856: more undefined references to `PyErr_CheckSignals' follow ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: libpython3.8m.a(complexobject.o):./build-static/../Include/object.h:434: more undefined references to `_PyTraceMalloc_NewReference' follow ./build-static/../Python/bltinmodule.c:2071: undefined reference to `PyErr_CheckSignals' ./build-static/../Parser/myreadline.c:80: undefined reference to `PyErr_CheckSignals' /usr/bin/ld: ./build-static/../Parser/myreadline.c:88: undefined reference to `PyOS_InterruptOccurred' ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: libpython3.8m.a(bytesobject.o):./build-static/../Include/object.h:434: more undefined references to `_PyTraceMalloc_NewReference' follow ./build-static/../Objects/longobject.c:1742: undefined reference to `PyErr_CheckSignals' ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' ./build-static/../Objects/longobject.c:2769: undefined reference to `PyErr_CheckSignals' ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: libpython3.8m.a(longobject.o):./build-static/../Include/object.h:434: more undefined references to `_PyTraceMalloc_NewReference' follow ./build-static/../Objects/longobject.c:3309: undefined reference to `PyErr_CheckSignals' ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' ./build-static/../Objects/longobject.c:3271: undefined reference to `PyErr_CheckSignals' ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: libpython3.8m.a(longobject.o):./build-static/../Include/object.h:434: more undefined references to `_PyTraceMalloc_NewReference' follow ./build-static/../Objects/unicodeobject.c:3766: undefined reference to `PyOS_FSPath' ./build-static/../Objects/unicodeobject.c:3808: undefined reference to `PyOS_FSPath' ./build-static/../Python/pylifecycle.c:2019: undefined reference to `_PyFaulthandler_Fini' /usr/bin/ld: ./build-static/../Python/pylifecycle.c:2019: undefined reference to `_PyFaulthandler_Fini' ./build-static/../Python/pylifecycle.c:1091: undefined reference to `PyOS_FiniInterrupts' /usr/bin/ld: ./build-static/../Python/pylifecycle.c:1143: undefined reference to `_PyTraceMalloc_Fini' /usr/bin/ld: ./build-static/../Python/pylifecycle.c:1152: undefined reference to `_PyFaulthandler_Fini' ./build-static/../Python/pylifecycle.c:860: undefined reference to `_PyFaulthandler_Init' ./build-static/../Python/pylifecycle.c:2150: undefined reference to `PyOS_InitInterrupts' ./build-static/../Python/pylifecycle.c:877: undefined reference to `_PyTraceMalloc_Init' ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' ./build-static/../Python/ceval.c:383: undefined reference to `PyErr_CheckSignals' ./build-static/../Python/errors.c:497: undefined reference to `PyErr_CheckSignals' /usr/bin/ld: ./build-static/../Python/errors.c:497: undefined reference to `PyErr_CheckSignals' /usr/bin/ld: ./build-static/../Python/errors.c:497: undefined reference to `PyErr_CheckSignals' /usr/bin/ld: ./build-static/../Python/errors.c:497: undefined reference to `PyErr_CheckSignals' ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: libpython3.8m.a(floatobject.o):./build-static/../Objects/floatobject.c:124: more undefined references to `_PyTraceMalloc_NewReference' follow ./build-static/../Objects/object.c:486: undefined reference to `PyErr_CheckSignals' ./build-static/../Objects/object.c:533: undefined reference to `PyErr_CheckSignals' ./build-static/../Objects/object.c:342: undefined reference to `PyErr_CheckSignals' ./build-static/../Objects/object.c:2132: undefined reference to `_PyMem_DumpTraceback' ./build-static/../Objects/obmalloc.c:2392: undefined reference to `_PyMem_DumpTraceback' /usr/bin/ld: ./build-static/../Objects/obmalloc.c:2392: undefined reference to `_PyMem_DumpTraceback' ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' ./build-static/../Python/marshal.c:308: undefined reference to `_Py_hashtable_get_entry' /usr/bin/ld: ./build-static/../Python/marshal.c:326: undefined reference to `_Py_hashtable_set' /usr/bin/ld: ./build-static/../Python/marshal.c:308: undefined reference to `_Py_hashtable_get_entry' ./build-static/../Python/marshal.c:571: undefined reference to `_Py_hashtable_compare_direct' /usr/bin/ld: ./build-static/../Python/marshal.c:571: undefined reference to `_Py_hashtable_hash_ptr' /usr/bin/ld: ./build-static/../Python/marshal.c:571: undefined reference to `_Py_hashtable_new' ./build-static/../Python/marshal.c:597: undefined reference to `_Py_hashtable_foreach' /usr/bin/ld: ./build-static/../Python/marshal.c:598: undefined reference to `_Py_hashtable_destroy' ./build-static/../Python/marshal.c:326: undefined reference to `_Py_hashtable_set' ./build-static/../Python/marshal.c:597: undefined reference to `_Py_hashtable_foreach' /usr/bin/ld: ./build-static/../Python/marshal.c:598: undefined reference to `_Py_hashtable_destroy' ./build-static/../Python/marshal.c:571: undefined reference to `_Py_hashtable_compare_direct' /usr/bin/ld: ./build-static/../Python/marshal.c:571: undefined reference to `_Py_hashtable_hash_ptr' /usr/bin/ld: ./build-static/../Python/marshal.c:571: undefined reference to `_Py_hashtable_new' ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' ./build-static/../Python/bootstrap_hash.c:175: undefined reference to `PyErr_CheckSignals' ./build-static/../Python/traceback.c:572: undefined reference to `PyErr_CheckSignals' ./build-static/../Python/fileutils.c:1270: undefined reference to `PyErr_CheckSignals' ./build-static/../Python/fileutils.c:1442: undefined reference to `PyErr_CheckSignals' ./build-static/../Python/fileutils.c:1506: undefined reference to `PyErr_CheckSignals' /usr/bin/ld: libpython3.8m.a(fileutils.o):./build-static/../Python/fileutils.c:1560: more undefined references to `PyErr_CheckSignals' follow ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' ./build-static/../Modules/_posixsubprocess.c:687: undefined reference to `PyOS_BeforeFork' /usr/bin/ld: ./build-static/../Modules/_posixsubprocess.c:725: undefined reference to `PyOS_AfterFork_Parent' /usr/bin/ld: ./build-static/../Modules/_posixsubprocess.c:705: undefined reference to `PyOS_AfterFork_Child' ./build-static/../Modules/fcntlmodule.c:422: undefined reference to `PyErr_CheckSignals' ./build-static/../Modules/fcntlmodule.c:296: undefined reference to `PyErr_CheckSignals' ./build-static/../Modules/fcntlmodule.c:83: undefined reference to `PyErr_CheckSignals' /usr/bin/ld: ./build-static/../Modules/fcntlmodule.c:104: undefined reference to `PyErr_CheckSignals' ./build-static/../Modules/grpmodule.c:75: undefined reference to `_PyLong_FromGid' ./build-static/../Modules/grpmodule.c:107: undefined reference to `_Py_Gid_Converter' /usr/bin/ld: ./build-static/../Modules/grpmodule.c:120: undefined reference to `_Py_Gid_Converter' /usr/bin/ld: ./build-static/../Modules/grpmodule.c:169: undefined reference to `_PyLong_FromGid' ./build-static/../Modules/selectmodule.c:638: undefined reference to `PyErr_CheckSignals' ./build-static/../Modules/selectmodule.c:1563: undefined reference to `PyErr_CheckSignals' ./build-static/../Modules/selectmodule.c:332: undefined reference to `PyErr_CheckSignals' /usr/bin/ld: ./build-static/../Modules/selectmodule.c:332: undefined reference to `PyErr_CheckSignals' ./build-static/../Modules/socketmodule.c:903: undefined reference to `PyErr_CheckSignals' /usr/bin/ld: libpython3.8m.a(socketmodule.o):./build-static/../Modules/socketmodule.c:856: more undefined references to `PyErr_CheckSignals' follow ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: ./build-static/../Include/object.h:434: undefined reference to `_PyTraceMalloc_NewReference' /usr/bin/ld: libpython3.8m.a(complexobject.o):./build-static/../Include/object.h:434: more undefined references to `_PyTraceMalloc_NewReference' follow ./build-static/../Python/bltinmodule.c:2071: undefined reference to `PyErr_CheckSignals' ./build-static/../Parser/myreadline.c:80: undefined reference to `PyErr_CheckSignals' /usr/bin/ld: ./build-static/../Parser/myreadline.c:88: undefined reference to `PyOS_InterruptOccurred' ---------- components: Build messages: 334908 nosy: doko, vstinner priority: normal severity: normal status: open title: build with building extension modules as builtins is broken in 3.8 type: compile error versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 04:17:26 2019 From: report at bugs.python.org (Matthias Klose) Date: Wed, 06 Feb 2019 09:17:26 +0000 Subject: [issue35908] build with building extension modules as builtins is broken in 3.8 In-Reply-To: <1549443528.5.0.674313815796.issue35908@roundup.psfhosted.org> Message-ID: <1549444646.72.0.325540905477.issue35908@roundup.psfhosted.org> Matthias Klose added the comment: Setup.local used: # Edit this file for local setup changes array arraymodule.c # array objects cmath cmathmodule.c _math.c # -lm # complex math library functions math mathmodule.c _math.c # -lm # math library functions, e.g. sin() _struct _struct.c # binary structure packing/unpacking _random _randommodule.c # Random number generator _elementtree _elementtree.c -lexpat # elementtree accelerator _pickle _pickle.c # pickle accelerator _datetime _datetimemodule.c # datetime accelerator _bisect _bisectmodule.c # Bisection algorithms _heapq _heapqmodule.c # Heap queue algorithm unicodedata unicodedata.c # static Unicode character database fcntl fcntlmodule.c # fcntl(2) and ioctl(2) spwd spwdmodule.c # spwd(3) grp grpmodule.c # grp(3) select selectmodule.c # select(2); not on ancient System V _socket socketmodule.c _posixsubprocess _posixsubprocess.c # POSIX subprocess module helper _md5 md5module.c _sha1 sha1module.c _sha256 sha256module.c _sha512 sha512module.c _sha3 _sha3/sha3module.c _blake2 _blake2/blake2module.c _blake2/blake2b_impl.c _blake2/blake2s_impl.c syslog syslogmodule.c # syslog daemon interface binascii binascii.c zlib zlibmodule.c -I$(prefix)/include -L$(exec_prefix)/lib -lz ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 04:37:05 2019 From: report at bugs.python.org (uhei3nn9) Date: Wed, 06 Feb 2019 09:37:05 +0000 Subject: [issue35909] Zip Slip Vulnerability Message-ID: <1549445824.49.0.751818540829.issue35909@roundup.psfhosted.org> New submission from uhei3nn9 : As has been discovered in 06.2018 the python library is affected by the zip slip vulbnerability (meaning code execution) The affected section https://github.com/python/cpython/blob/3.7/Lib/tarfile.py has not been patched since then. Therefore it seems python has not yet fixed this vulnerability. Source: https://github.com/snyk/zip-slip-vulnerability ---------- components: Library (Lib) messages: 334910 nosy: uhei3nn9 priority: normal severity: normal status: open title: Zip Slip Vulnerability type: security versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 04:45:08 2019 From: report at bugs.python.org (SilentGhost) Date: Wed, 06 Feb 2019 09:45:08 +0000 Subject: [issue35909] Zip Slip Vulnerability In-Reply-To: <1549445824.49.0.751818540829.issue35909@roundup.psfhosted.org> Message-ID: <1549446308.68.0.984661721369.issue35909@roundup.psfhosted.org> Change by SilentGhost : ---------- keywords: +security_issue nosy: +lars.gustaebel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 04:47:21 2019 From: report at bugs.python.org (Sihoon Lee) Date: Wed, 06 Feb 2019 09:47:21 +0000 Subject: [issue35909] Zip Slip Vulnerability In-Reply-To: <1549445824.49.0.751818540829.issue35909@roundup.psfhosted.org> Message-ID: <1549446441.97.0.615006721294.issue35909@roundup.psfhosted.org> Sihoon Lee added the comment: When I had tested it before, It was not worked. Was it really worked? Could you show me your PoC Code? ---------- nosy: +push0ebp -lars.gustaebel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 04:53:05 2019 From: report at bugs.python.org (Matthias Klose) Date: Wed, 06 Feb 2019 09:53:05 +0000 Subject: [issue35908] build with building extension modules as builtins is broken in 3.8 In-Reply-To: <1549443528.5.0.674313815796.issue35908@roundup.psfhosted.org> Message-ID: <1549446785.89.0.831438877116.issue35908@roundup.psfhosted.org> Matthias Klose added the comment: found it, Setup.dist was renamed to Setup. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 04:58:33 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 06 Feb 2019 09:58:33 +0000 Subject: [issue35909] Zip Slip Vulnerability In-Reply-To: <1549445824.49.0.751818540829.issue35909@roundup.psfhosted.org> Message-ID: <1549447113.05.0.914916328626.issue35909@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- assignee: -> christian.heimes nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 05:03:19 2019 From: report at bugs.python.org (Phil Dream) Date: Wed, 06 Feb 2019 10:03:19 +0000 Subject: [issue35910] Curious problem with my choice of variables Message-ID: <1549447398.9.0.00215680394136.issue35910@roundup.psfhosted.org> New submission from Phil Dream : Firstable I am not a software expert just a hobby user so please be indulgent I use a Raspberry Pi3B+ with raspbian lite and Python 3.5.3 In my script, I need 2 nested "while" loops so I chose two variables to incriment them 'i' and j. This script don't work and I made a certain time to understand (I did not think Python could play me a trick). I needed to reset 'j' to go through the inner loop a few times and in fact I realized that when I initialized 'j', 'i' was also initialized !?!? Very curious isn't it ? I replaced 'i' by 'y' and no more problem, my script works very well. ---------- files: sirext.py messages: 334913 nosy: Phil Dream priority: normal severity: normal status: open title: Curious problem with my choice of variables type: behavior versions: Python 3.5 Added file: https://bugs.python.org/file48104/sirext.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 05:05:28 2019 From: report at bugs.python.org (Jeff Knupp) Date: Wed, 06 Feb 2019 10:05:28 +0000 Subject: [issue35909] Zip Slip Vulnerability In-Reply-To: <1549445824.49.0.751818540829.issue35909@roundup.psfhosted.org> Message-ID: <1549447528.51.0.831103314929.issue35909@roundup.psfhosted.org> Jeff Knupp added the comment: According to https://snyk.io/research/zip-slip-vulnerability (the source of the paper), Python hasn't been vulnerable since 2014. ---------- nosy: +jeffknupp _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 05:07:12 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Wed, 06 Feb 2019 10:07:12 +0000 Subject: [issue35910] Curious problem with my choice of variables In-Reply-To: <1549447398.9.0.00215680394136.issue35910@roundup.psfhosted.org> Message-ID: <1549447632.59.0.129662107107.issue35910@roundup.psfhosted.org> R?mi Lapeyre added the comment: Hi @Phil Dream, you reuse i in your inner loop, in the for statement. By the way, I suggest you look at range() to replace your while loop: https://docs.python.org/3/library/functions.html#func-range. For your others questions, the mailing list are more appropriate than the bug tracker. Have a nice day! ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 05:10:19 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 06 Feb 2019 10:10:19 +0000 Subject: [issue35910] Curious problem with my choice of variables In-Reply-To: <1549447398.9.0.00215680394136.issue35910@roundup.psfhosted.org> Message-ID: <1549447819.59.0.0592664645079.issue35910@roundup.psfhosted.org> St?phane Wirtel added the comment: Hi Phil, This bug tracker is more for the core-dev and the contributors of CPython. I suggest to you to use the right mailing list for your issues. or use #python-fr on freenode Mailing list: https://mail.python.org/mailman/listinfo/python-list I close this issue because it's not related to the internals of Python. ---------- nosy: +matrixise resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 05:13:52 2019 From: report at bugs.python.org (Phil Dream) Date: Wed, 06 Feb 2019 10:13:52 +0000 Subject: [issue35910] Curious problem with my choice of variables In-Reply-To: <1549447819.59.0.0592664645079.issue35910@roundup.psfhosted.org> Message-ID: <5c5ab35d.1c69fb81.931e1.8c89@mx.google.com> Phil Dream added the comment: OK, I am sorry I didn?t know Best regards De?: St?phane Wirtel Envoy? le?:mercredi 6 f?vrier 2019 11:10 ??: philsdream at gmail.com Objet?:[issue35910] Curious problem with my choice of variables St?phane Wirtel added the comment: Hi Phil, This bug tracker is more for the core-dev and the contributors of CPython. I suggest to you to use the right mailing list for your issues. or use #python-fr on freenode Mailing list: https://mail.python.org/mailman/listinfo/python-list I close this issue because it's not related to the internals of Python. ---------- nosy: +matrixise resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 05:14:22 2019 From: report at bugs.python.org (SilentGhost) Date: Wed, 06 Feb 2019 10:14:22 +0000 Subject: [issue35909] Zip Slip Vulnerability In-Reply-To: <1549445824.49.0.751818540829.issue35909@roundup.psfhosted.org> Message-ID: <1549448062.93.0.0501355821915.issue35909@roundup.psfhosted.org> SilentGhost added the comment: issue 21109 was mentioned as an example of reported behaviour in https://github.com/snyk/zip-slip-vulnerability/issues/4#issuecomment-395848367 ---------- nosy: +SilentGhost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 05:15:02 2019 From: report at bugs.python.org (Phil Dream) Date: Wed, 06 Feb 2019 10:15:02 +0000 Subject: [issue35910] Curious problem with my choice of variables In-Reply-To: <1549447632.59.0.129662107107.issue35910@roundup.psfhosted.org> Message-ID: <5c5ab3a3.1c69fb81.8a370.dc53@mx.google.com> Phil Dream added the comment: OK, I am sorry I didn?t know Thanks for the advice Best regards De?: R?mi Lapeyre Envoy? le?:mercredi 6 f?vrier 2019 11:07 ??: philsdream at gmail.com Objet?:[issue35910] Curious problem with my choice of variables R?mi Lapeyre added the comment: Hi @Phil Dream, you reuse i in your inner loop, in the for statement. By the way, I suggest you look at range() to replace your while loop: https://docs.python.org/3/library/functions.html#func-range. For your others questions, the mailing list are more appropriate than the bug tracker. Have a nice day! ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 05:32:47 2019 From: report at bugs.python.org (Christian Heimes) Date: Wed, 06 Feb 2019 10:32:47 +0000 Subject: [issue35909] Zip Slip Vulnerability In-Reply-To: <1549445824.49.0.751818540829.issue35909@roundup.psfhosted.org> Message-ID: <1549449167.79.0.248348545426.issue35909@roundup.psfhosted.org> Christian Heimes added the comment: You are both right and wrong. The zipfile module of Python 3.7 is fine, but the tarfile module is still vulnerable. $ curl -O https://raw.githubusercontent.com/snyk/zip-slip-vulnerability/master/archives/zip-slip.zip $ curl -O https://raw.githubusercontent.com/snyk/zip-slip-vulnerability/master/archives/zip-slip.tar $ mkdir /tmp/zipslip $ cd /tmp/zipslip Test zipfile: $ python3 >>> import zipfile >>> zf = zipfile.ZipFile('zip-slip.zip') >>> zf.printdir() File Name Modified Size good.txt 2018-04-15 22:04:30 19 ../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../tmp/evil.txt 2018-04-15 22:04:42 20 >>> zf.extractall() >>> exit() $ find . ./tmp ./tmp/evil.txt ./good.txt ./zip-slip.tar ./zip-slip.zip Test tarfile $ rm -rf good.txt tmp/ $ python3 >>> import tarfile >>> import tarfile >>> tf = tarfile.TarFile('zip-slip.tar') >>> tf.list() ?rw-r--r-- grander/staff 19 2018-04-15 19:04:29 good.txt ?rw-r--r-- grander/staff 20 2018-06-03 13:49:05 ../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../tmp/evil.txt >>> tf.extractall() # find . ./zip-slip.tar ./good.txt ./zip-slip.zip # cat /tmp/evil.txt this is an evil one ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 05:34:59 2019 From: report at bugs.python.org (Christian Heimes) Date: Wed, 06 Feb 2019 10:34:59 +0000 Subject: [issue21109] tarfile: Traversal attack vulnerability In-Reply-To: <1396253659.12.0.842636239516.issue21109@psf.upfronthosting.co.za> Message-ID: <1549449299.72.0.988126368952.issue21109@roundup.psfhosted.org> Christian Heimes added the comment: There is some new research on the topic, see https://snyk.io/research/zip-slip-vulnerability, https://github.com/snyk/zip-slip-vulnerability/issues/4#issuecomment-395848367 and BPO #35909 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 05:36:07 2019 From: report at bugs.python.org (Christian Heimes) Date: Wed, 06 Feb 2019 10:36:07 +0000 Subject: [issue35909] Zip Slip Vulnerability In-Reply-To: <1549445824.49.0.751818540829.issue35909@roundup.psfhosted.org> Message-ID: <1549449367.84.0.379312996095.issue35909@roundup.psfhosted.org> Christian Heimes added the comment: Thanks for reporting the issue. I'm closing this issue as duplicate of #21109. Let's keep all discussion on one issue. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> tarfile: Traversal attack vulnerability _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 05:53:52 2019 From: report at bugs.python.org (Christian Heimes) Date: Wed, 06 Feb 2019 10:53:52 +0000 Subject: [issue35907] Unnecessary URL scheme exists to allow file:// reading file in urllib In-Reply-To: <1549441191.29.0.148559977828.issue35907@roundup.psfhosted.org> Message-ID: <1549450432.64.0.020841312135.issue35907@roundup.psfhosted.org> Christian Heimes added the comment: Thanks for your report. I'm having a hard time understanding your English. If I understand you correctly, your bug report is about the open_local_file() method and the surprising fact that urllib supports the local_file schema. I agree, this looks like an implementation artefact. urllib should not expose the local_file schema. In Python 3 refuses local_file:// (tested with 3.4 to 3.7). >>> import urllib.request >>> urllib.request.urlopen('local_file:///etc/passwd').read()[:30] Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.6/urllib/request.py", line 223, in urlopen return opener.open(url, data, timeout) File "/usr/lib64/python3.6/urllib/request.py", line 526, in open response = self._open(req, data) File "/usr/lib64/python3.6/urllib/request.py", line 549, in _open 'unknown_open', req) File "/usr/lib64/python3.6/urllib/request.py", line 504, in _call_chain result = func(*args) File "/usr/lib64/python3.6/urllib/request.py", line 1388, in unknown_open raise URLError('unknown url type: %s' % type) urllib.error.URLError: ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 05:55:49 2019 From: report at bugs.python.org (Pierre Glaser) Date: Wed, 06 Feb 2019 10:55:49 +0000 Subject: [issue35911] add a cell construtor, and expose the cell type in Lib/types.py Message-ID: <1549450547.33.0.317079200708.issue35911@roundup.psfhosted.org> New submission from Pierre Glaser : cell objects are containers for the free variables of functions defined in a local scope. They are located in a function's __closure__ attribute (when it is not None). A cell is a very simple object, with a single (optional, e.g the cell can be empty) attribute: cell_contents. The C/Python API provides a constructor to create such objects (PyCell_New). However no cell.__new__ method is exposed to the pure python user. Workarounds exist, but are hacky, and involve the creation of intermediate, unused functions. Why would cell-creation be useful? because creating cells happens in pickle extensions modules designed to save user-defined functions and classes (https://github.com/cloudpipe/cloudpickle) (*). These moudules are dependencies of many widely-used data science frameworks (pyspark, ray, dask). Exposing a cell constructor will simplify theses extensions code base, and alleviate their maintenance cost. I propose to add and expose a simple cell constructor, that accepts 0 (empty cells) or 1 arguments. I also propose to expose the cell type in Lib/types.py (as types.CellType) (*): see related issues: https://bugs.python.org/issue35900 ---------- files: cell.patch keywords: patch messages: 334924 nosy: pierreglaser, pitrou, yselivanov priority: normal severity: normal status: open title: add a cell construtor, and expose the cell type in Lib/types.py type: enhancement versions: Python 3.8 Added file: https://bugs.python.org/file48105/cell.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 05:55:51 2019 From: report at bugs.python.org (Christian Heimes) Date: Wed, 06 Feb 2019 10:55:51 +0000 Subject: [issue35907] Unnecessary URL scheme exists to allow file:// reading file in urllib In-Reply-To: <1549441191.29.0.148559977828.issue35907@roundup.psfhosted.org> Message-ID: <1549450551.83.0.177640207786.issue35907@roundup.psfhosted.org> Christian Heimes added the comment: Only the Python 2 urllib module is affected. Python 2.7's urllib2 also correctly fails with local_file:// >>> import urllib2 >>> urllib2.urlopen('local_file:///etc/passwd').read()[:30] Traceback (most recent call last): File "", line 1, in File "/home/heimes/dev/python/2.7/Lib/urllib2.py", line 154, in urlopen return opener.open(url, data, timeout) File "/home/heimes/dev/python/2.7/Lib/urllib2.py", line 429, in open response = self._open(req, data) File "/home/heimes/dev/python/2.7/Lib/urllib2.py", line 452, in _open 'unknown_open', req) File "/home/heimes/dev/python/2.7/Lib/urllib2.py", line 407, in _call_chain result = func(*args) File "/home/heimes/dev/python/2.7/Lib/urllib2.py", line 1266, in unknown_open raise URLError('unknown url type: %s' % type) urllib2.URLError: ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 05:57:14 2019 From: report at bugs.python.org (Pierre Glaser) Date: Wed, 06 Feb 2019 10:57:14 +0000 Subject: [issue35911] add a cell construtor, and expose the cell type in Lib/types.py In-Reply-To: <1549450547.33.0.317079200708.issue35911@roundup.psfhosted.org> Message-ID: <1549450634.55.0.824085140305.issue35911@roundup.psfhosted.org> Change by Pierre Glaser : Added file: https://bugs.python.org/file48106/test_cell.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 06:08:36 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Wed, 06 Feb 2019 11:08:36 +0000 Subject: [issue30670] pprint for dict in sorted order or insert order? In-Reply-To: <1497492955.33.0.313949068523.issue30670@psf.upfronthosting.co.za> Message-ID: <1549451316.28.0.845068693785.issue30670@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- keywords: +patch pull_requests: +11732 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 06:08:55 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Wed, 06 Feb 2019 11:08:55 +0000 Subject: [issue30670] pprint for dict in sorted order or insert order? In-Reply-To: <1497492955.33.0.313949068523.issue30670@psf.upfronthosting.co.za> Message-ID: <1549451335.08.0.903848965327.issue30670@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- keywords: +patch, patch pull_requests: +11732, 11733 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 06:09:11 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Wed, 06 Feb 2019 11:09:11 +0000 Subject: [issue30670] pprint for dict in sorted order or insert order? In-Reply-To: <1497492955.33.0.313949068523.issue30670@psf.upfronthosting.co.za> Message-ID: <1549451351.66.0.424096773107.issue30670@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- keywords: +patch, patch, patch pull_requests: +11732, 11733, 11734 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 06:19:43 2019 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 06 Feb 2019 11:19:43 +0000 Subject: [issue22213] Make pyvenv style virtual environments easier to configure when embedding Python In-Reply-To: <1408275761.36.0.915361061447.issue22213@psf.upfronthosting.co.za> Message-ID: <1549451983.91.0.710029286679.issue22213@roundup.psfhosted.org> Nick Coghlan added the comment: (Added Victor, Eric, and Steve to the nosy list here, as I'd actually forgotten about this until issue #35706 reminded me) Core of the problem: the embedding APIs don't currently offer a Windows-compatible way of setting up "use this base Python and this venv site-packages", and the way of getting it to work on other platforms is pretty obscure. ---------- nosy: +eric.snow, steve.dower, vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 06:28:42 2019 From: report at bugs.python.org (Sihoon Lee) Date: Wed, 06 Feb 2019 11:28:42 +0000 Subject: [issue35907] Unnecessary URL scheme exists to allow file:// reading file in urllib In-Reply-To: <1549441191.29.0.148559977828.issue35907@roundup.psfhosted.org> Message-ID: <1549452522.92.0.447638700348.issue35907@roundup.psfhosted.org> Sihoon Lee added the comment: Sorry for my bad English. Yes, exactly. Only python 2.7 has been affected. not python3. So I chose only Python2.7 version. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 06:29:51 2019 From: report at bugs.python.org (Sihoon Lee) Date: Wed, 06 Feb 2019 11:29:51 +0000 Subject: [issue35907] Unnecessary URL scheme exists to allow file:// reading file in urllib In-Reply-To: <1549441191.29.0.148559977828.issue35907@roundup.psfhosted.org> Message-ID: <1549452591.5.0.61011819233.issue35907@roundup.psfhosted.org> Sihoon Lee added the comment: and only urllib, not urllib2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 06:33:37 2019 From: report at bugs.python.org (Christian Heimes) Date: Wed, 06 Feb 2019 11:33:37 +0000 Subject: [issue35907] Unnecessary URL scheme exists to allow file:// reading file in urllib In-Reply-To: <1549441191.29.0.148559977828.issue35907@roundup.psfhosted.org> Message-ID: <1549452817.97.0.59468711228.issue35907@roundup.psfhosted.org> Christian Heimes added the comment: I'm not a native English speaker either. I wasn't sure if I understood you correctly. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 06:42:22 2019 From: report at bugs.python.org (Sihoon Lee) Date: Wed, 06 Feb 2019 11:42:22 +0000 Subject: [issue35907] Unnecessary URL scheme exists to allow file:// reading file in urllib In-Reply-To: <1549441191.29.0.148559977828.issue35907@roundup.psfhosted.org> Message-ID: <1549453342.43.0.572777083469.issue35907@roundup.psfhosted.org> Sihoon Lee added the comment: I am not also native English speaker. It's OK. Thank you for reading my report ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 06:50:52 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 06 Feb 2019 11:50:52 +0000 Subject: [issue35911] add a cell construtor, and expose the cell type in Lib/types.py In-Reply-To: <1549450547.33.0.317079200708.issue35911@roundup.psfhosted.org> Message-ID: <1549453852.29.0.288478376409.issue35911@roundup.psfhosted.org> Change by Antoine Pitrou : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 06:53:28 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 06 Feb 2019 11:53:28 +0000 Subject: [issue35911] add a cell construtor, and expose the cell type in Lib/types.py In-Reply-To: <1549450547.33.0.317079200708.issue35911@roundup.psfhosted.org> Message-ID: <1549454008.35.0.759884740304.issue35911@roundup.psfhosted.org> Antoine Pitrou added the comment: Hi Pierre, You'll want to submit your patch as a GitHub pull request. Also your PR will have to contain: - tests for the new Python-facing API - documentation for the new API You may want to read more in the developer's guide: https://devguide.python.org/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 08:09:05 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Wed, 06 Feb 2019 13:09:05 +0000 Subject: [issue30670] pprint for dict in sorted order or insert order? In-Reply-To: <1497492955.33.0.313949068523.issue30670@psf.upfronthosting.co.za> Message-ID: <1549458545.67.0.356885202629.issue30670@roundup.psfhosted.org> Emmanuel Arias added the comment: Hi! > def pprint(data, *, sort_dicts=True): > ... > def pp(data, *args, **kwds): > pprint(data, *args, sort_dicts=False, **kwds) We could use the parameters `sort=`? IMHO is better a short parameters name. If we assign by default sort_dicts=True, that would have some error on unittest, isn't? ---------- nosy: +eamanu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 08:14:50 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Wed, 06 Feb 2019 13:14:50 +0000 Subject: [issue30670] pprint for dict in sorted order or insert order? In-Reply-To: <1497492955.33.0.313949068523.issue30670@psf.upfronthosting.co.za> Message-ID: <1549458890.58.0.546511212106.issue30670@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: pprint only sorts dicts currently so sort_dicts is better than sort that sounds more general. sort_dicts=True is the current behavior so I guess this is backwards compatible way to do this change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 08:19:19 2019 From: report at bugs.python.org (Philip Semanchuk) Date: Wed, 06 Feb 2019 13:19:19 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1549459159.73.0.21458540227.issue35813@roundup.psfhosted.org> Philip Semanchuk added the comment: Hi all, I'm the author of `posix_ipc` on which some of this code is based. I'd be happy to sign a contributor agreement in order to erase any concerns on that front. ---------- nosy: +osvenskan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 08:19:56 2019 From: report at bugs.python.org (Eryk Sun) Date: Wed, 06 Feb 2019 13:19:56 +0000 Subject: [issue35896] sysconfig.get_platform returns wrong value when Python 32b is running under Windows 64b In-Reply-To: <1549316025.61.0.403140167175.issue35896@roundup.psfhosted.org> Message-ID: <1549459196.04.0.796385587465.issue35896@roundup.psfhosted.org> Eryk Sun added the comment: > Correct, though the examples I'd give are Win32 vs. WinRT vs. Cygwin, > which are fundamentally different API surfaces for interacting with > the operating system. Cygwin and MSYS are presented as more than APIs; they're separate platforms. sys.platform is 'cygwin' or 'msys', and os.name is 'posix'. The Windows platform name is "win32". If we could change it, I'd prefer "windows". The C API is the "Windows API" or WINAPI. It used to be called Win32, which is still the popular name. The ABI for 32-bit x86 (Intel Architecture) is "win32". If we could change it, I'd prefer "win-ia32" to parallel "win-amd64". > os.name is also odd, and honestly I'd rather it just went away > completely. I'd like the module to be called "posix" everywhere, > since that's the API it exposes (it's an emulation layer on > non-POSIX platforms), and checks should use sys.platform. os is too entrenched to be renamed. But I'd like it if nt (posixmodule.c) were renamed windows_posix (or win32_posix) -- since it has nothing to do with the NT API. We would need to move the Windows-only functions to a "windows" (or "win32") platform module. This includes _getdiskusage, _getfinalpathname, _getfullpathname, _getvolumepathname, _isdir, and startfile. They have no place in a POSIX module. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 08:20:25 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Wed, 06 Feb 2019 13:20:25 +0000 Subject: [issue30670] pprint for dict in sorted order or insert order? In-Reply-To: <1497492955.33.0.313949068523.issue30670@psf.upfronthosting.co.za> Message-ID: <1549459225.51.0.732000677506.issue30670@roundup.psfhosted.org> Emmanuel Arias added the comment: > pprint only sorts dicts currently so sort_dicts is better than sort that sounds more general. Yes. Because pprint just sort dicts, I think that is better rename the parameter like just sort. But was an opinion, that does not affect to the behavior. > sort_dicts=True is the current behavior so I guess this is backwards compatible way to do this change. I understand it. I was confuse. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 08:20:44 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Wed, 06 Feb 2019 13:20:44 +0000 Subject: [issue30670] pprint for dict in sorted order or insert order? In-Reply-To: <1497492955.33.0.313949068523.issue30670@psf.upfronthosting.co.za> Message-ID: <1549459225.51.0.732000677506.issue30670@roundup.psfhosted.org> Emmanuel Arias added the comment: > pprint only sorts dicts currently so sort_dicts is better than sort that sounds more general. Yes. Because pprint just sort dicts, I think that is better rename the parameter like just sort. But was an opinion, that does not affect to the behavior. > sort_dicts=True is the current behavior so I guess this is backwards compatible way to do this change. I understand it. I was confuse. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 08:20:46 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Wed, 06 Feb 2019 13:20:46 +0000 Subject: [issue30670] pprint for dict in sorted order or insert order? In-Reply-To: <1497492955.33.0.313949068523.issue30670@psf.upfronthosting.co.za> Message-ID: <1549459246.15.0.88444250889.issue30670@roundup.psfhosted.org> R?mi Lapeyre added the comment: I agree with Karthikeyan, I would expect sort=True to sort all collections, including tuples and lists for example. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 09:24:59 2019 From: report at bugs.python.org (Ulrich Petri) Date: Wed, 06 Feb 2019 14:24:59 +0000 Subject: [issue35046] logging.StreamHandler performs two syscalls when one would do In-Reply-To: <1540234281.84.0.788709270274.issue35046@psf.upfronthosting.co.za> Message-ID: <1549463099.64.0.87319346235.issue35046@roundup.psfhosted.org> Ulrich Petri added the comment: This change breaks (probably unsupported) uses of the logging module (esp. in combination with structlog) where non-string objects are passed through the .format() and .emit() calls. Previously it was possible to set the terminator attribute to None (and then handling that case in a custom 'stream' implementation), which now breaks with a TypeError due to the concatenation. In case anyone else runs into this (however unlikely that is). A workaround is to set the .terminator to something like this: class ConcatenableNothing: def __radd__(self, other): return other ---------- nosy: +ulope _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 09:31:44 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 06 Feb 2019 14:31:44 +0000 Subject: [issue35902] Forking from background thread In-Reply-To: <1549405071.04.0.889820238084.issue35902@roundup.psfhosted.org> Message-ID: <1549463504.2.0.0690793980844.issue35902@roundup.psfhosted.org> Change by Antoine Pitrou : ---------- nosy: +pablogsal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 09:40:29 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 06 Feb 2019 14:40:29 +0000 Subject: [issue35902] Forking from background thread In-Reply-To: <1549405071.04.0.889820238084.issue35902@roundup.psfhosted.org> Message-ID: <1549464029.37.0.389973337973.issue35902@roundup.psfhosted.org> Antoine Pitrou added the comment: It is actually quite an intricate problem. What happens is that child process *main thread* ends, but not its background sleeping thread (the `lambda: time.sleep(3600)`). To diagnose it, you can display the process tree: ``` $ ps fu USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND antoine 12634 0.0 0.0 28308 9208 pts/0 Ss 15:21 0:00 bash antoine 2520 0.0 0.0 179072 10684 pts/0 Sl+ 15:29 0:00 \_ ./python threadforkmodel.py antoine 2522 0.0 0.0 0 0 pts/0 Zl+ 15:29 0:00 \_ [python] ``` Then you can display all threads for the child process (here with pid 2522): ``` $ ps -T -p 2522 PID SPID TTY TIME CMD 2522 2522 pts/0 00:00:00 python 2522 2525 pts/0 00:00:00 python ``` The main thread is marked zombie ("defunct") but thread 2525 is still running... What is it doing? Let's attach gdb: ``` $ gdb ./python --pid 2525 ``` And display the call stack: ``` (gdb) bt #0 0x00007f1fb3ca503f in __GI___select (nfds=nfds at entry=0, readfds=readfds at entry=0x0, writefds=writefds at entry=0x0, exceptfds=exceptfds at entry=0x0, timeout=timeout at entry=0x7f1fb23553c0) at ../sysdeps/unix/sysv/linux/select.c:41 #1 0x000055e6fc4fcf7e in pysleep (secs=) at ./Modules/timemodule.c:1864 #2 0x000055e6fc4fd022 in time_sleep (self=self at entry=, obj=) at ./Modules/timemodule.c:366 #3 0x000055e6fc3a02e7 in _PyMethodDef_RawFastCallKeywords (method=0x55e6fc887ee0 , self=, args=args at entry=0x7f1fb336a8f8, nargs=nargs at entry=1, kwnames=0x0) at Objects/call.c:646 #4 0x000055e6fc3a04c7 in _PyCFunction_FastCallKeywords ( func=func at entry=, args=args at entry=0x7f1fb336a8f8, nargs=nargs at entry=1, kwnames=kwnames at entry=0x0) at Objects/call.c:732 #5 0x000055e6fc4506e9 in call_function (pp_stack=pp_stack at entry=0x7f1fb2355570, oparg=oparg at entry=1, kwnames=kwnames at entry=0x0) at Python/ceval.c:4607 #6 0x000055e6fc45c678 in _PyEval_EvalFrameDefault (f=Frame 0x7f1fb336a770, for file threadforkmodel.py, line 36, in (), throwflag=) at Python/ceval.c:3195 #7 0x000055e6fc451110 in PyEval_EvalFrameEx (f=f at entry=Frame 0x7f1fb336a770, for file threadforkmodel.py, line 36, in (), throwflag=throwflag at entry=0) at Python/ceval.c:581 #8 0x000055e6fc451d21 in _PyEval_EvalCodeWithName (_co=_co at entry=, globals=globals at entry={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': , '__spec__': None, '__annotations__': {}, '__builtins__': , '__file__': 'threadforkmodel.py', '__cached__': None, 'threading': , 'time': , 'os': , 'atexit': , 'signal': , 'run': , 'start': , 'join': , 'runFork': , 'handleExit': , 'handleChildExit': , 'main': }, locals=locals at entry=0x0, args=args at entry=0x7f1fb4aec078, argcount=argcount at entry=0, kwnames=kwnames at entry=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name='', qualname='runFork..') at Python/ceval.c:3969 [...] ``` So basically the sleep() call wasn't woken up by the main thread's death... even though we might have expected it to. This is indeed a case of weird interaction between threads and processes. The only reference I could find is a single comment in a StackOverflow question: """ Be aware that infinite waits on semaphores, handles etc can cause your process to become a zombie in both Windows and Linux. """ The reason I'm posting this detailed explanation is that I hit the exact same issue when trying to debug the PEP 556 implementation, and it took me quite some time (and Pablo's help) to finally understand and workaround the issue. In the end, I would recommend you don't use fork() but use multiprocessing with the "forkserver" start method, which will eliminate such problems: https://docs.python.org/3/library/multiprocessing.html#contexts-and-start-methods ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 09:42:31 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 06 Feb 2019 14:42:31 +0000 Subject: [issue35902] Forking from background thread In-Reply-To: <1549405071.04.0.889820238084.issue35902@roundup.psfhosted.org> Message-ID: <1549464151.51.0.630121731552.issue35902@roundup.psfhosted.org> Antoine Pitrou added the comment: By the way, one likely explanation why this happens only when fork() is called from a non-main thread is that the non-main thread (which becomes the main thread in the child process) ends with pthread_exit() while the main thread would end with exit(). ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 09:42:43 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Wed, 06 Feb 2019 14:42:43 +0000 Subject: [issue34398] Docs search does not index glossary items In-Reply-To: <1534233148.48.0.56676864532.issue34398@psf.upfronthosting.co.za> Message-ID: <1549464163.19.0.345388600582.issue34398@roundup.psfhosted.org> Cheryl Sabella added the comment: @ammar2, this looks like a great addition to the docs. Would you be able to address Berker's request and also fix the merge conflict on the PR? Also adding Julien and Carol from the expert's index for documentation. ---------- nosy: +cheryl.sabella, mdk, willingc versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 09:45:34 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Wed, 06 Feb 2019 14:45:34 +0000 Subject: [issue35912] _testembed.c fails to compile when using --with-cxx-main in the configure step Message-ID: <1549464332.95.0.70522769189.issue35912@roundup.psfhosted.org> New submission from Pablo Galindo Salgado : Programs/_testembed.c is compiled with $(MAINCC) in Makefile.pre.in and that will use the C++ compiler if --with-cxx-main is used in the configuration step. The problem is that if the C++ compiler used is some of the more uncommon ones (like the solaris compiler) some parts of _testembed.c and its includes fail to compile because they are assuming C99 or compiler extension. There are mainly two: 1) _testembed.c has gotos that crosses variable definitions. The C++ standard says: If transfer of control enters the scope of any automatic variables (e.g. by jumping forward over a declaration statement), the program is ill-formed (cannot be compiled), unless all variables whose scope is entered have 1) scalar types declared without initializers 2) class types with trivial default constructors and trivial destructors declared without initializers 3) cv-qualified versions of one of the above 4) arrays of one of the above So the gotos that can be found in `dump_config_impl` in `_testembed.c` are invalidating this rule. 2) `testembed.c` is pulling `pystate.h` and that header file defines a macro (_PyCoreConfig_INIT) that uses designated initializers that are not available as an extension in all C++ compilers. The solutions that I can immediately think of aare: 1) Compile _testembed.c with the $(CC) instead of $(CCMAIN). 2) Change these files to make them compliant with the standard (by initializing all variables at the beginning and by using just compound literals). ---------- components: Interpreter Core messages: 334942 nosy: pablogsal priority: normal severity: normal status: open title: _testembed.c fails to compile when using --with-cxx-main in the configure step versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 10:50:28 2019 From: report at bugs.python.org (Jason R. Coombs) Date: Wed, 06 Feb 2019 15:50:28 +0000 Subject: [issue35905] macOS build docs need refresh (2019) In-Reply-To: <1549411942.7.0.0722764247373.issue35905@roundup.psfhosted.org> Message-ID: <1549468228.1.0.781467651168.issue35905@roundup.psfhosted.org> Jason R. Coombs added the comment: I also have a script that does something very similar (https://github.com/jaraco/jaraco.develop/blob/master/jaraco/develop/macos-build-python.py), invoked with `python -m jaraco.develop.macos-build-python` (or `pip-run -m jaraco.develop -- -m jaraco.develop.macos-build-python` if you don't have it installed). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 10:51:06 2019 From: report at bugs.python.org (Isaac Boukris) Date: Wed, 06 Feb 2019 15:51:06 +0000 Subject: [issue35913] asyncore: allow handling of half closed connections Message-ID: <1549468264.52.0.429414559636.issue35913@roundup.psfhosted.org> New submission from Isaac Boukris : When recv() return 0 we may still have data to send. Add a handler for this case, which may happen with some protocols, notably http1.0 ver. Also, do not call recv with a buffer size of zero to avoid ambiguous return value (see recv man page). ---------- components: Library (Lib) messages: 334944 nosy: Isaac Boukris priority: normal severity: normal status: open title: asyncore: allow handling of half closed connections type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 10:51:38 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 06 Feb 2019 15:51:38 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1549468298.87.0.00555554626417.issue35813@roundup.psfhosted.org> Terry J. Reedy added the comment: I would prefer that we be consistent. In any case, I think you should be added to Misc/ACKS in the PR. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 10:54:43 2019 From: report at bugs.python.org (Xiang Gao) Date: Wed, 06 Feb 2019 15:54:43 +0000 Subject: [issue35914] [2.7] PyStructSequence objects not behaving like nametuple Message-ID: <1549468482.77.0.451102979772.issue35914@roundup.psfhosted.org> New submission from Xiang Gao : Related: https://bugs.python.org/issue1820 On issue 1820, a bunch of improvements was made on PyStructSequence to make it behave like a namedtuple. These improvements are not ported to Python 2, which makes it a trouble to write python 2-3 compatible code. See also: https://github.com/pytorch/pytorch/pull/15429#discussion_r253205020 ---------- components: Interpreter Core messages: 334946 nosy: Xiang Gao priority: normal severity: normal status: open title: [2.7] PyStructSequence objects not behaving like nametuple type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 10:56:59 2019 From: report at bugs.python.org (Roundup Robot) Date: Wed, 06 Feb 2019 15:56:59 +0000 Subject: [issue35913] asyncore: allow handling of half closed connections In-Reply-To: <1549468264.52.0.429414559636.issue35913@roundup.psfhosted.org> Message-ID: <1549468619.95.0.598110356376.issue35913@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch pull_requests: +11735 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 10:57:01 2019 From: report at bugs.python.org (Roundup Robot) Date: Wed, 06 Feb 2019 15:57:01 +0000 Subject: [issue35913] asyncore: allow handling of half closed connections In-Reply-To: <1549468264.52.0.429414559636.issue35913@roundup.psfhosted.org> Message-ID: <1549468621.95.0.673754238402.issue35913@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch, patch pull_requests: +11735, 11736 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 11:08:49 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 06 Feb 2019 16:08:49 +0000 Subject: [issue35896] sysconfig.get_platform returns wrong value when Python 32b is running under Windows 64b In-Reply-To: <1549316025.61.0.403140167175.issue35896@roundup.psfhosted.org> Message-ID: <1549469329.44.0.933857936466.issue35896@roundup.psfhosted.org> Steve Dower added the comment: > This includes _getdiskusage, _getfinalpathname, _getfullpathname, _getvolumepathname, _isdir, and startfile. They have no place in a POSIX module. Except for startfile, I disagree. They are all there to help implement POSIX compatibility, and as private APIs, there's no better place to put them. In any case, this issue is closed for now, pending a discussion on python-dev. If anyone feel strongly about making changes, it'll need to start with a post on the mailing list. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 11:15:22 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 06 Feb 2019 16:15:22 +0000 Subject: [issue22213] Make pyvenv style virtual environments easier to configure when embedding Python In-Reply-To: <1408275761.36.0.915361061447.issue22213@psf.upfronthosting.co.za> Message-ID: <1549469722.54.0.266341929819.issue22213@roundup.psfhosted.org> Steve Dower added the comment: Victor may be thinking about it from time to time (or perhaps it's time to make the rest of the configuration changes plans concrete so we can all help out?), but I'd like to see this as either: * a helper function to fill out the core config structure from a pyvenv.cfg file (rather than hiding it deeper as it currently is), or better yet, * remove the dependency on all non-frozen imports at initialization and let embedders define Python code to do the initialization In the latter case, the main python.exe also gets to define its behavior. So for the most part, we should be able to remove getpath[p].c and move it into the site module, then make that our Python initialization step. This would also mean that if you are embedding Python but not allowing imports (e.g. as only a calculation engine), you don't have to do the dance of _denying_ all lookups, you simply don't initialize them. But as far as I know, we don't have a concrete vision for "how will consumers embed Python in their apps" that can translate into work - we're still all individually pulling in slightly different directions. Sorting that out is most important - having someone willing to do the customer engagement work to define an actual set of requirements and desirables would be fantastic. ---------- versions: +Python 3.8 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 11:17:38 2019 From: report at bugs.python.org (Ben Spiller) Date: Wed, 06 Feb 2019 16:17:38 +0000 Subject: [issue35915] re.search livelock/hang, searching for patterns starting .* in a large string Message-ID: <1549469857.93.0.911634458861.issue35915@roundup.psfhosted.org> New submission from Ben Spiller : These work fine and return instantly: python -c "import re; re.compile('.*x').match('y'*(1000*100))" python -c "import re; re.compile('x').search('y'*(1000*100))" python -c "import re; re.compile('.*x').search('y'*(1000*10))" This hangs / freezes / livelocks indefinitely, with lots of CPU usage: python -c "import re; re.compile('.*x').search('y'*(1000*100))" Admittedly performing a search() with a pattern starting .* isn't useful, however it's worth fixing as: - it's easily done by inexperienced developers, or users interacting with code that's far removed from the actual regex call - the failure mode of hanging forever (with the GIL held, of course) is quite severe (took us a lot of debugging with gdb before we figured out where our complex multi-threaded python program was hanging!), and - the fact that the behaviour is different based on the length of the string being matched suggests there is some kind of underlying bug in how the buffer is handled whcih might also affect other, more reasonable regex use cases ---------- components: Regular Expressions messages: 334949 nosy: benspiller, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: re.search livelock/hang, searching for patterns starting .* in a large string type: crash versions: Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 11:18:38 2019 From: report at bugs.python.org (DMITRY KOSHELEV) Date: Wed, 06 Feb 2019 16:18:38 +0000 Subject: [issue35916] 3.6.5 try/except/else/finally block executes code with typos, no errors Message-ID: <1549469917.09.0.661318828546.issue35916@roundup.psfhosted.org> New submission from DMITRY KOSHELEV : Hello dear developer! I was playing with try/else/finally block and have found a bug: Inside of "else" or/and "except" I can do this 1 + print('Why do you print me?') + 1 this would print "Why do you print me?", in case if I have "finally" block with a "return" statement, no error raises, if I don't have finally, nothing is printed. def foo(var): try: print("Hello") # 1 + print("Hello") except: 1 + print('Why do you print me?') + 1 else: 1 + print('Why do you print me?') + 1 finally: print("finally block") return ---------- files: bug_in_try_exceptions.py messages: 334950 nosy: dmitry_koshelev priority: normal severity: normal status: open title: 3.6.5 try/except/else/finally block executes code with typos, no errors type: behavior versions: Python 3.6 Added file: https://bugs.python.org/file48107/bug_in_try_exceptions.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 11:26:22 2019 From: report at bugs.python.org (SilentGhost) Date: Wed, 06 Feb 2019 16:26:22 +0000 Subject: [issue35916] 3.6.5 try/except/else/finally block executes code with typos, no errors In-Reply-To: <1549469917.09.0.661318828546.issue35916@roundup.psfhosted.org> Message-ID: <1549470382.59.0.452980562742.issue35916@roundup.psfhosted.org> SilentGhost added the comment: This seem to be the exactly documented behaviour. From https://docs.python.org/3.8/reference/compound_stmts.html#the-try-statement If finally is present, it specifies a ?cleanup? handler. The try clause is executed, including any except and else clauses. If an exception occurs in any of the clauses and is not handled, the exception is temporarily saved. The finally clause is executed. If there is a saved exception it is re-raised at the end of the finally clause. If the finally clause raises another exception, the saved exception is set as the context of the new exception. If the finally clause executes a return, break or continue statement, the saved exception is discarded. ---------- nosy: +SilentGhost resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 11:35:20 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 06 Feb 2019 16:35:20 +0000 Subject: [issue35917] multiprocessing: provide unit-tests for manager classes and shareable types Message-ID: <1549470919.94.0.961552344771.issue35917@roundup.psfhosted.org> New submission from Giampaolo Rodola' : This is a follow up of BPO-35813 and PR-11664 and it provides unit tests for SyncManager and SharedMemoryManager classes + all the shareable types which are supposed to be supported by them. Also, see relevant python-dev discussion at: https://mail.python.org/pipermail/python-dev/2019-February/156235.html. In doing so I discovered a couple of issues which I will treat in a separate BPO ticket (multiprocessing.managers's dict.has_key() and Pool() appear to be broken). ---------- components: Tests messages: 334952 nosy: giampaolo.rodola priority: normal severity: normal stage: patch review status: open title: multiprocessing: provide unit-tests for manager classes and shareable types type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 11:36:51 2019 From: report at bugs.python.org (SilentGhost) Date: Wed, 06 Feb 2019 16:36:51 +0000 Subject: [issue35913] asyncore: allow handling of half closed connections In-Reply-To: <1549468264.52.0.429414559636.issue35913@roundup.psfhosted.org> Message-ID: <1549471011.83.0.0572371923357.issue35913@roundup.psfhosted.org> Change by SilentGhost : ---------- nosy: +giampaolo.rodola, josiahcarlson, stutzbach versions: +Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 11:37:33 2019 From: report at bugs.python.org (Pierre Glaser) Date: Wed, 06 Feb 2019 16:37:33 +0000 Subject: [issue35911] add a cell construtor, and expose the cell type in Lib/types.py In-Reply-To: <1549450547.33.0.317079200708.issue35911@roundup.psfhosted.org> Message-ID: <1549471053.78.0.544846804974.issue35911@roundup.psfhosted.org> Change by Pierre Glaser : ---------- pull_requests: +11738 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 11:37:43 2019 From: report at bugs.python.org (Pierre Glaser) Date: Wed, 06 Feb 2019 16:37:43 +0000 Subject: [issue35911] add a cell construtor, and expose the cell type in Lib/types.py In-Reply-To: <1549450547.33.0.317079200708.issue35911@roundup.psfhosted.org> Message-ID: <1549471063.46.0.368250983261.issue35911@roundup.psfhosted.org> Change by Pierre Glaser : ---------- pull_requests: +11738, 11739 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 11:44:50 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 06 Feb 2019 16:44:50 +0000 Subject: [issue35917] multiprocessing: provide unit-tests for manager classes and shareable types In-Reply-To: <1549470919.94.0.961552344771.issue35917@roundup.psfhosted.org> Message-ID: <1549471490.27.0.615865195594.issue35917@roundup.psfhosted.org> Change by Terry J. Reedy : ---------- nosy: +davin, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 11:47:07 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 06 Feb 2019 16:47:07 +0000 Subject: [issue35917] multiprocessing: provide unit-tests for manager classes and shareable types In-Reply-To: <1549470919.94.0.961552344771.issue35917@roundup.psfhosted.org> Message-ID: <1549471627.23.0.831467366215.issue35917@roundup.psfhosted.org> Change by Giampaolo Rodola' : ---------- keywords: +patch pull_requests: +11740 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 11:47:12 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 06 Feb 2019 16:47:12 +0000 Subject: [issue35917] multiprocessing: provide unit-tests for manager classes and shareable types In-Reply-To: <1549470919.94.0.961552344771.issue35917@roundup.psfhosted.org> Message-ID: <1549471632.11.0.0955284902963.issue35917@roundup.psfhosted.org> Change by Giampaolo Rodola' : ---------- keywords: +patch, patch pull_requests: +11740, 11741 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 11:47:17 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 06 Feb 2019 16:47:17 +0000 Subject: [issue35917] multiprocessing: provide unit-tests for manager classes and shareable types In-Reply-To: <1549470919.94.0.961552344771.issue35917@roundup.psfhosted.org> Message-ID: <1549471637.36.0.615053741372.issue35917@roundup.psfhosted.org> Change by Giampaolo Rodola' : ---------- keywords: +patch, patch, patch pull_requests: +11740, 11741, 11742 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 11:48:45 2019 From: report at bugs.python.org (Ben Spiller) Date: Wed, 06 Feb 2019 16:48:45 +0000 Subject: [issue35915] re.search extreme slowness (looks like hang/livelock), searching for patterns containing .* in a large string In-Reply-To: <1549469857.93.0.911634458861.issue35915@roundup.psfhosted.org> Message-ID: <1549471725.04.0.895431195796.issue35915@roundup.psfhosted.org> Ben Spiller added the comment: Correction to original report - it doesn't hang indefinitely, it just takes a really long time. Specifically, looks like it's quadratic in the length of the input string. Increase the size of the input string to 1000*1000 and it's really really slow. I don't know for sure if it's possible to implement regexes in a way that avoids this pathological behaviour, but it's certainly quite risky that an otherwise working bit of code using a pattern containing .* can hang/livelock an application for an arbitrary amount of time if passed a larger-than-expected (but actually not that big) input string. ---------- title: re.search livelock/hang, searching for patterns starting .* in a large string -> re.search extreme slowness (looks like hang/livelock), searching for patterns containing .* in a large string type: crash -> performance _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 11:50:37 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 06 Feb 2019 16:50:37 +0000 Subject: [issue35917] multiprocessing: provide unit-tests for manager classes and shareable types In-Reply-To: <1549470919.94.0.961552344771.issue35917@roundup.psfhosted.org> Message-ID: <1549471837.34.0.845162763252.issue35917@roundup.psfhosted.org> Antoine Pitrou added the comment: Interesting. I had never looked too closely and assumed this was already tested. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 11:51:04 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 06 Feb 2019 16:51:04 +0000 Subject: [issue35917] multiprocessing: provide unit-tests for manager classes and shareable types In-Reply-To: <1549470919.94.0.961552344771.issue35917@roundup.psfhosted.org> Message-ID: <1549471864.38.0.0696886360352.issue35917@roundup.psfhosted.org> Antoine Pitrou added the comment: Would probably be worthwhile backporting to 3.7 as well. ---------- versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 11:57:17 2019 From: report at bugs.python.org (Ben Spiller) Date: Wed, 06 Feb 2019 16:57:17 +0000 Subject: [issue35915] re.search extreme slowness (looks like hang/livelock), searching for patterns containing .* in a large string In-Reply-To: <1549469857.93.0.911634458861.issue35915@roundup.psfhosted.org> Message-ID: <1549472237.36.0.409975452288.issue35915@roundup.psfhosted.org> Ben Spiller added the comment: Running this command: time python -c "import re; re.compile('y.*x').search('y'*(N))" It's clearly quadratic: N=100,000 time=7s N=200,000 time=18s N=400,000 time=110s N=1,000,000 time=690s This illustrates how a simple program that's working correctly can quickly degrade to a very long period of unresponsiveness after some fairly modest increases in size of input string. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 12:09:45 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 06 Feb 2019 17:09:45 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1549472985.92.0.0669938469613.issue35813@roundup.psfhosted.org> Giampaolo Rodola' added the comment: Unit-tests at https://bugs.python.org/issue35917. ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 12:15:25 2019 From: report at bugs.python.org (Tim Peters) Date: Wed, 06 Feb 2019 17:15:25 +0000 Subject: [issue35915] re.search extreme slowness (looks like hang/livelock), searching for patterns containing .* in a large string In-Reply-To: <1549469857.93.0.911634458861.issue35915@roundup.psfhosted.org> Message-ID: <1549473325.7.0.318910987921.issue35915@roundup.psfhosted.org> Tim Peters added the comment: Yes, it's quadratic time. If the string being searched has N characters, first it fails to find "x" in all N of 'em, then `.*` advances by one and it fails to find "x" in the trailing N-1 characters, then again in the trailing N-2, and so on. N + N-1 + N-2 + ... + 1 is quadratic in N. That's how this kind of regexp engine works. And it's mild, as such things go: you can also create poor regexps that take time _exponential_ in N that fail to match certain strings. It's unlikely this will change without replacing Python's regexp implementation entirely. For why, see Jeffrey Friedl's book "Mastering Regular Expressions" (published by O'Reilly). That book also spells out techniques for crafting regexps that don't suck ;-) It's not a small topic, alas. ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 12:22:17 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 06 Feb 2019 17:22:17 +0000 Subject: [issue35918] multiprocessing's SyncManager.dict.has_key() method is broken Message-ID: <1549473735.16.0.515862791139.issue35918@roundup.psfhosted.org> New submission from Giampaolo Rodola' : Related to BPO-35917: $ ./python Python 3.8.0a1+ (heads/master:cd90f6a369, Feb 6 2019, 17:16:10) [GCC 7.3.0] on linux >>> import multiprocessing.managers >>> m = multiprocessing.managers.SyncManager() >>> m.start() >>> d = m.dict() >>> 'has_key' in dir(d) True >>> d.has_key(1) Traceback (most recent call last): File "/home/giampaolo/cpython/Lib/multiprocessing/managers.py", line 271, in serve_client fallback_func = self.fallback_mapping[methodname] KeyError: 'has_key' ---------- messages: 334959 nosy: davin, giampaolo.rodola, jnoller, pitrou, sbt priority: normal severity: normal stage: needs patch status: open title: multiprocessing's SyncManager.dict.has_key() method is broken versions: Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 12:28:24 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 06 Feb 2019 17:28:24 +0000 Subject: [issue35913] asyncore: allow handling of half closed connections In-Reply-To: <1549468264.52.0.429414559636.issue35913@roundup.psfhosted.org> Message-ID: <1549474104.06.0.83996910765.issue35913@roundup.psfhosted.org> Giampaolo Rodola' added the comment: Assigning this to me but am not sure 1) when I'll be able to look at this 2) whether it's worth it as asyncore is deprecated in favor of asyncio. ---------- assignee: -> giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 12:35:56 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Wed, 06 Feb 2019 17:35:56 +0000 Subject: [issue35913] asyncore: allow handling of half closed connections In-Reply-To: <1549468264.52.0.429414559636.issue35913@roundup.psfhosted.org> Message-ID: <1549474556.46.0.906988431909.issue35913@roundup.psfhosted.org> Emmanuel Arias added the comment: Hi! > Assigning this to me but am not sure 1) when I'll be able to look at this 2) whether it's worth it as asyncore is deprecated in favor of asyncio. Yes, asyncore is deprecated since 3.6. ---------- nosy: +eamanu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 12:36:21 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 06 Feb 2019 17:36:21 +0000 Subject: [issue35919] multiprocessing: shared manager Pool fails with AttributeError Message-ID: <1549474580.7.0.974775956703.issue35919@roundup.psfhosted.org> New submission from Giampaolo Rodola' : import multiprocessing import multiprocessing.managers def f(n): return n * n def worker(pool): with pool: pool.apply_async(f, (10, )) manager = multiprocessing.managers.SyncManager() manager.start() pool = manager.Pool(processes=4) proc = multiprocessing.Process(target=worker, args=(pool, )) proc.start() proc.join() This is related to BPO-35917 and it fails with: Process Process-2: Traceback (most recent call last): File "/home/giampaolo/cpython/Lib/multiprocessing/process.py", line 302, in _bootstrap self.run() File "/home/giampaolo/cpython/Lib/multiprocessing/process.py", line 99, in run self._target(*self._args, **self._kwargs) File "foo.py", line 54, in worker pool.apply_async(f, (10, )) File "", line 2, in apply_async File "/home/giampaolo/cpython/Lib/multiprocessing/managers.py", line 802, in _callmethod proxytype = self._manager._registry[token.typeid][-1] AttributeError: 'NoneType' object has no attribute '_registry' ---------- messages: 334962 nosy: davin, giampaolo.rodola, pitrou priority: normal severity: normal status: open title: multiprocessing: shared manager Pool fails with AttributeError _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 12:47:38 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 06 Feb 2019 17:47:38 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1549475257.99.0.833252406747.issue35813@roundup.psfhosted.org> Giampaolo Rodola' added the comment: Also, for completeness (since discussion is getting split), please see my proposal to move SharedMemoryManager and SharedMemoryServer into multiprocessing.managers namespace and rename shared_memory.py to _shared_memory.py: https://mail.python.org/pipermail/python-dev/2019-February/156235.html Also, it appears ShareableList should be register()ed against SharedMemoryManager. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 12:49:04 2019 From: report at bugs.python.org (Isaac Boukris) Date: Wed, 06 Feb 2019 17:49:04 +0000 Subject: [issue35913] asyncore: allow handling of half closed connections In-Reply-To: <1549468264.52.0.429414559636.issue35913@roundup.psfhosted.org> Message-ID: <1549475344.4.0.362477250972.issue35913@roundup.psfhosted.org> Isaac Boukris added the comment: Fair enough. I'll sign the CLA meanwhile you consider it. In my opinion it may still be useful in addressing issues in existing projects written using asyncore (and maybe for python2 as well). Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 12:53:05 2019 From: report at bugs.python.org (Eric Snow) Date: Wed, 06 Feb 2019 17:53:05 +0000 Subject: [issue35914] [2.7] PyStructSequence objects not behaving like nametuple In-Reply-To: <1549468482.77.0.451102979772.issue35914@roundup.psfhosted.org> Message-ID: <1549475585.45.0.911660545789.issue35914@roundup.psfhosted.org> Eric Snow added the comment: tl;dr It's too late to change anything here. Also, is it actually a problem in practice? ---- At this point enhancements can not go into 2.7 (you're welcome to appeal to the release manager). The changes to `PyStructSequence` (from bpo-1820) appear to have been merged for 3.2 in July 2010. However, this is just after 2.7 went final and 3 months after the first beta release (where no more enhancements are allowed). Likewise, at this point we cannot revert the original change (from bpo-1820). Doing so in 3.7 (the only one taking bug fixes) or 3.8 (upcoming) would break compatibility with 3.2 and up. Notably, this discrepancy has been there since 2.7/3.2 were released (8+ years). I don't recall any previous reports of a problem here, so I expect the impact is small. Regardless, from what I understand the problem is that pytorch was returning tuples and (with that PR) was going to return "named" tuples. For C-extension functions it wouldn't actually be a tuple any more but a structseq instead. So user code that checked for a tuple would suddenly work differently. Is that right? If so, I'm not clear on when this would be a problem in practice. Why would users of pytorch (or any similar library) be checking the type returned from a specific function in the library's documented API? If it was returning a tuple before then I'd expect them to be using unpacking or index access. That would keep working if the library switched to namedtuple and structseq. ---------- nosy: +benjamin.peterson, christian.heimes, eric.snow, rhettinger type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 12:57:24 2019 From: report at bugs.python.org (Eric Snow) Date: Wed, 06 Feb 2019 17:57:24 +0000 Subject: [issue35914] [2.7] PyStructSequence objects not behaving like nametuple In-Reply-To: <1549468482.77.0.451102979772.issue35914@roundup.psfhosted.org> Message-ID: <1549475844.75.0.0165072602728.issue35914@roundup.psfhosted.org> Eric Snow added the comment: [1] https://devguide.python.org/#status-of-python-branches ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 12:58:09 2019 From: report at bugs.python.org (Eric Snow) Date: Wed, 06 Feb 2019 17:58:09 +0000 Subject: [issue35914] [2.7] PyStructSequence objects not behaving like nametuple In-Reply-To: <1549468482.77.0.451102979772.issue35914@roundup.psfhosted.org> Message-ID: <1549475889.0.0.903007147347.issue35914@roundup.psfhosted.org> Eric Snow added the comment: FWIW, if folks *are* checking for tuple (and I'd love to know why) then I'd recommend that they not. :) A more Pythonic (and arguably generally better) approach would be to stick tightly to what data you need and take advantage of duck-typing. When possible, try attribute access first if you expect that (e.g. namedtuple or struct seq). Otherwise try use unpacking. For example: ``` try: x, y = ret.x, ret.y except AttributeError: pass else: ... ``` ``` try: x, y, _ = ret except TypeError: pass except ValueError: pass else: ... ``` Either way is easier to follow than code that relies on type (and length) checking. They also have the advantage of allowing arbitrary types that fit (duck-typing). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 12:59:04 2019 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 06 Feb 2019 17:59:04 +0000 Subject: [issue35913] asyncore: allow handling of half closed connections In-Reply-To: <1549468264.52.0.429414559636.issue35913@roundup.psfhosted.org> Message-ID: <1549475944.59.0.563655577947.issue35913@roundup.psfhosted.org> Andrew Svetlov added the comment: My personal opinion is: we should accept bug fixes for asyncore but stop adding new features to the module. asyncio supersedes asyncore in all aspects. ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 13:25:03 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Wed, 06 Feb 2019 18:25:03 +0000 Subject: [issue27344] zipfile *does* support utf-8 filenames In-Reply-To: <1466176126.21.0.0133629365393.issue27344@psf.upfronthosting.co.za> Message-ID: <1549477503.15.0.758323786131.issue27344@roundup.psfhosted.org> Cheryl Sabella added the comment: This wording was removed as part of issue 32035. ---------- nosy: +cheryl.sabella resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> Documentation of zipfile.ZipFile().writestr() fails to mention that 'data' may also be bytes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 13:55:41 2019 From: report at bugs.python.org (Xiang Gao) Date: Wed, 06 Feb 2019 18:55:41 +0000 Subject: [issue35914] [2.7] PyStructSequence objects not behaving like nametuple In-Reply-To: <1549468482.77.0.451102979772.issue35914@roundup.psfhosted.org> Message-ID: <1549479341.5.0.121977992243.issue35914@roundup.psfhosted.org> Xiang Gao added the comment: Hi Eric, Thanks for your valuable information and fast reply. You understand the problem exactly correct: initially pytorch had codes like `isinstance(x, tuple)` and lots of `PyTuple_Check`, but when we start to change the return type from tuple to structseq, these checks starts to fail. Yes, I agree generally the impact is small for this issue. Most users of PyTorch would just use the way like `values, indices = a.max(dim=0)`, which works perfectly before or after that PR. The impacts are probably mostly on libraries that use PyTorch as dependency. These libraries might have generic code that should be able to handle returns of most operators, for example, something like: User code: ``` import torch import a_deep_learning_library class MyModel(torch.nn.Module): ...... def forward(self, input_): ...... return tensor.sum(dim=0) model = MyModel() a_deep_learning_library.do_something(model) ``` Code of a_deep_learning_library: ``` def do_something(model): input_ = prepare_input() output = model(input_) if torch.is_tensor(output): do_something_1(output) elif isinstance(output, float): do_something_2(output) elif isinstance(output, tuple): sum_ = sum(output) do_something_3(sum_) elif .... ``` Unpacking does not always work because it is hard to differentiate these two cases: `a, b = torch.tensor([1, 2])` and `a, b = torch.tensor([1, 2]), torch.tensor([3, 4])`, but your suggestion is very valuable. I am neither a member of PyTorch team nor a Facebook employee. I am just a community contributor working on that issue. I will open an issue on PyTorch discussing the problem. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 13:58:19 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Wed, 06 Feb 2019 18:58:19 +0000 Subject: [issue35899] '_is_sunder' function in 'enum' module fails on empty string In-Reply-To: <1549376859.01.0.998806898699.issue35899@roundup.psfhosted.org> Message-ID: <1549479499.58.0.359475892412.issue35899@roundup.psfhosted.org> Cheryl Sabella added the comment: I agree with R?mi Lapeyre. For reference, the len() check and current tests were added under issue 19156. ---------- nosy: +cheryl.sabella _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 14:12:58 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 06 Feb 2019 19:12:58 +0000 Subject: [issue35920] Windows 10 ARM32 platform support Message-ID: <1549480377.04.0.927646454693.issue35920@roundup.psfhosted.org> New submission from Steve Dower : As posted at https://mail.python.org/pipermail/python-dev/2019-February/156229.html, add support for the Windows ARM32 platform. This is related to issue33125, but we are doing ARM32 first before considering ARM64. Paul Monson (Paul.Monson at microsoft.com) is implementing the support and will be the primary contact for Windows ARM32 support. ---------- components: Windows messages: 334972 nosy: paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: needs patch status: open title: Windows 10 ARM32 platform support type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 14:25:27 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 06 Feb 2019 19:25:27 +0000 Subject: [issue35921] Use ccache by default Message-ID: <1549481125.53.0.646421596529.issue35921@roundup.psfhosted.org> New submission from Antoine Pitrou : While compiling CPython isn't very slow, enabling ccache if found would produce faster builds when developing. ---------- components: Build messages: 334973 nosy: pitrou priority: normal severity: normal status: open title: Use ccache by default type: resource usage versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 14:29:30 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 06 Feb 2019 19:29:30 +0000 Subject: [issue35921] Use ccache by default In-Reply-To: <1549481125.53.0.646421596529.issue35921@roundup.psfhosted.org> Message-ID: <1549481370.11.0.639124087998.issue35921@roundup.psfhosted.org> Antoine Pitrou added the comment: I've got a proof-of-concept patch, here are the results: Debug build, uncached real 0m50,260s user 1m52,663s sys 0m11,305s Debug build, cached real 0m4,511s user 0m4,009s sys 0m1,547s Non-debug build, uncached real 1m18,384s user 3m19,271s sys 0m12,319s Non-debug build, cached real 0m4,047s user 0m3,467s sys 0m1,621s This is on a 16-thread CPU. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 14:29:59 2019 From: report at bugs.python.org (Paul Monson) Date: Wed, 06 Feb 2019 19:29:59 +0000 Subject: [issue35920] Windows 10 ARM32 platform support In-Reply-To: <1549480377.04.0.927646454693.issue35920@roundup.psfhosted.org> Message-ID: <1549481399.87.0.175839692557.issue35920@roundup.psfhosted.org> Change by Paul Monson : ---------- nosy: +Paul Monson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 14:33:21 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 06 Feb 2019 19:33:21 +0000 Subject: [issue35921] Use ccache by default In-Reply-To: <1549481125.53.0.646421596529.issue35921@roundup.psfhosted.org> Message-ID: <1549481601.8.0.70962113893.issue35921@roundup.psfhosted.org> Change by Antoine Pitrou : ---------- keywords: +patch pull_requests: +11743 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 14:33:25 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 06 Feb 2019 19:33:25 +0000 Subject: [issue35921] Use ccache by default In-Reply-To: <1549481125.53.0.646421596529.issue35921@roundup.psfhosted.org> Message-ID: <1549481605.65.0.150682512706.issue35921@roundup.psfhosted.org> Change by Antoine Pitrou : ---------- keywords: +patch, patch pull_requests: +11743, 11744 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 14:33:28 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 06 Feb 2019 19:33:28 +0000 Subject: [issue35921] Use ccache by default In-Reply-To: <1549481125.53.0.646421596529.issue35921@roundup.psfhosted.org> Message-ID: <1549481608.72.0.522518504239.issue35921@roundup.psfhosted.org> Change by Antoine Pitrou : ---------- keywords: +patch, patch, patch pull_requests: +11743, 11744, 11745 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 14:35:25 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 06 Feb 2019 19:35:25 +0000 Subject: [issue35921] Use ccache by default In-Reply-To: <1549481125.53.0.646421596529.issue35921@roundup.psfhosted.org> Message-ID: <1549481725.13.0.820575637544.issue35921@roundup.psfhosted.org> Antoine Pitrou added the comment: This is Unix-only, but the same approach may be possible on Windows using clcache (https://github.com/frerich/clcache). ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 14:40:03 2019 From: report at bugs.python.org (Roundup Robot) Date: Wed, 06 Feb 2019 19:40:03 +0000 Subject: [issue35920] Windows 10 ARM32 platform support In-Reply-To: <1549480377.04.0.927646454693.issue35920@roundup.psfhosted.org> Message-ID: <1549482003.05.0.618728992572.issue35920@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch pull_requests: +11746 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 14:40:13 2019 From: report at bugs.python.org (Roundup Robot) Date: Wed, 06 Feb 2019 19:40:13 +0000 Subject: [issue35920] Windows 10 ARM32 platform support In-Reply-To: <1549480377.04.0.927646454693.issue35920@roundup.psfhosted.org> Message-ID: <1549482013.72.0.300381607868.issue35920@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch, patch pull_requests: +11746, 11747 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 14:40:24 2019 From: report at bugs.python.org (Roundup Robot) Date: Wed, 06 Feb 2019 19:40:24 +0000 Subject: [issue35920] Windows 10 ARM32 platform support In-Reply-To: <1549480377.04.0.927646454693.issue35920@roundup.psfhosted.org> Message-ID: <1549482024.26.0.976985579688.issue35920@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch, patch, patch pull_requests: +11746, 11747, 11749 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 14:40:33 2019 From: report at bugs.python.org (Roundup Robot) Date: Wed, 06 Feb 2019 19:40:33 +0000 Subject: [issue35920] Windows 10 ARM32 platform support In-Reply-To: <1549480377.04.0.927646454693.issue35920@roundup.psfhosted.org> Message-ID: <1549482033.95.0.821056810437.issue35920@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch, patch, patch, patch pull_requests: +11746, 11747, 11748, 11749 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 14:58:13 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 06 Feb 2019 19:58:13 +0000 Subject: [issue35913] asyncore: allow handling of half closed connections In-Reply-To: <1549468264.52.0.429414559636.issue35913@roundup.psfhosted.org> Message-ID: <1549483093.98.0.0697272233255.issue35913@roundup.psfhosted.org> Giampaolo Rodola' added the comment: > When recv() return 0 we may still have data to send. It seems recv() returning b"" is an alias for "connection lost". E.g. in Twisted: https://github.com/twisted/twisted/blob/06c891502be9f6389451fcc959cad5485f55d653/src/twisted/internet/tcp.py#L227-L248 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 14:59:04 2019 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 06 Feb 2019 19:59:04 +0000 Subject: [issue35904] Add statistics.fmean(seq) In-Reply-To: <1549411161.36.0.783593325223.issue35904@roundup.psfhosted.org> Message-ID: <1549483144.75.0.390309737329.issue35904@roundup.psfhosted.org> Change by Mark Dickinson : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 15:03:43 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 06 Feb 2019 20:03:43 +0000 Subject: [issue35921] Use ccache by default In-Reply-To: <1549481125.53.0.646421596529.issue35921@roundup.psfhosted.org> Message-ID: <1549483423.36.0.277284979523.issue35921@roundup.psfhosted.org> Steve Dower added the comment: I think the caching that MSVC does naturally handles this well enough - certainly rebuilds normally just build those files that have not changed. Besides not rebuilding .o[bj] files where the sources have not changed, what else do these tools do? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 15:13:22 2019 From: report at bugs.python.org (Isaac Boukris) Date: Wed, 06 Feb 2019 20:13:22 +0000 Subject: [issue35913] asyncore: allow handling of half closed connections In-Reply-To: <1549468264.52.0.429414559636.issue35913@roundup.psfhosted.org> Message-ID: <1549484002.78.0.176026256294.issue35913@roundup.psfhosted.org> Isaac Boukris added the comment: > It seems recv() returning b"" is an alias for "connection lost". E.g. in Twisted: To my understanding, technically the connection is not fully closed, it is just shut-down for reading but we can still perform write operations on it (that is, the client may be still waiting for the response). I can reproduce it with an http-1.0 client, I'll try to put up a test to demonstrate it more clearly. >From recv() man page: When a stream socket peer has performed an orderly shutdown, the return value will be 0 (the traditional "end-of-file" return). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 15:16:51 2019 From: report at bugs.python.org (Christian Heimes) Date: Wed, 06 Feb 2019 20:16:51 +0000 Subject: [issue35921] Use ccache by default In-Reply-To: <1549481125.53.0.646421596529.issue35921@roundup.psfhosted.org> Message-ID: <1549484211.78.0.448804437558.issue35921@roundup.psfhosted.org> Christian Heimes added the comment: The PR is not required. I have been using ccache for many years with a custom PATH. On Debian, it's recommended to modify PATH manually. On Fedora PATH is automatically modified by the ccache package. $ echo $PATH /home/heimes/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin $ ls -la /usr/lib64/ccache/ total 252 drwxr-xr-x. 2 root root 4096 Dec 21 11:23 . dr-xr-xr-x. 210 root root 249856 Jan 29 10:28 .. lrwxrwxrwx. 1 root root 16 Dec 21 11:23 c++ -> ../../bin/ccache lrwxrwxrwx. 1 root root 16 Dec 21 11:23 cc -> ../../bin/ccache lrwxrwxrwx. 1 root root 16 Dec 21 11:23 g++ -> ../../bin/ccache lrwxrwxrwx. 1 root root 16 Dec 21 11:23 gcc -> ../../bin/ccache lrwxrwxrwx. 1 root root 16 Dec 21 11:23 x86_64-redhat-linux-c++ -> ../../bin/ccache lrwxrwxrwx. 1 root root 16 Dec 21 11:23 x86_64-redhat-linux-g++ -> ../../bin/ccache lrwxrwxrwx. 1 root root 16 Dec 21 11:23 x86_64-redhat-linux-gcc -> ../../bin/ccache ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 15:25:47 2019 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 06 Feb 2019 20:25:47 +0000 Subject: [issue35904] Add statistics.fmean(seq) In-Reply-To: <1549411161.36.0.783593325223.issue35904@roundup.psfhosted.org> Message-ID: <1549484747.45.0.995915923308.issue35904@roundup.psfhosted.org> Mark Dickinson added the comment: > Are you saying that "fsum(seq) / len(seq)" is incorrect because on some > older builds there is a rare possibility of an error of 1 unit in the last > place? Just to be clear, it's not that rare a possibility, and it's not restricted to older builds. I think Raymond is referring to the bug where on some machines that are still using the x87 for arithmetic, double rounding can lead to the fsum result being out (by potentially an arbitrary amount, not just 1 ulp). But even without that consideration, we'll still often be out by 1 ulp or more on typical new systems. However, if I got my sums right (and assuming that fsum _is_ correctly rounded, and IEEE 754 arithmetic is in use, and the rounding mode hasn't been changed from its default of round-ties-to-even, and we're excluding corner cases like overflow, underflow, etc., etc.), the result of fsum(seq) / len(seq) can never be out by more than 1.5 ulps. That's better than NumPy can promise (even with its use of pairwise summation in some -- but not all -- cases), and should be good enough for almost any practical purpose. I think I'd rather see the regular statistics.mean sacrifice the good-to-the-last-bit accuracy (and it's really not that much of a sacrifice: accurate to 1.5 ulps is a _very_ respectable compromise) than have a new function. I don't know how feasible that is, though, given all the type-handling in statistics.mean. Bikeshedding time: the proposed fmean name seems a bit unfortunate in that it's reversing the sense of sum and fsum, where fsum is the correctly-rounded, slightly slower variant. My first assumption on seeing the name was that fmean was supposed to be to mean as fsum is to sum. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 15:28:39 2019 From: report at bugs.python.org (Neil Schemenauer) Date: Wed, 06 Feb 2019 20:28:39 +0000 Subject: [issue35903] Build of posixshmem.c should probe for required OS functions In-Reply-To: <1549407022.09.0.0256128012498.issue35903@roundup.psfhosted.org> Message-ID: <1549484919.01.0.0323339122805.issue35903@roundup.psfhosted.org> Neil Schemenauer added the comment: Hi Ronald, I tested with my MacBook but I'm not sure what version of the OS. Probably the latest but I can check when I get home. Maybe my comment was not clear. On my MacBook, you don't need librt for shm_open, etc. That sounds like it is the same as your 10.14.3. AC_SEARCH_LIBS is the macro I'm using to find if I need to link with librt. It is a bit hard to use though. It will execute the true clause if the function doesn't require any of the specified libraries. That seems to be the case for MacOS. It also adds -lrt to LIBS and so I have to undo that. I'm using $ac_cv_search_shm_open test if -lrt is actually needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 15:33:05 2019 From: report at bugs.python.org (Joseph Myers) Date: Wed, 06 Feb 2019 20:33:05 +0000 Subject: [issue35922] robotparser crawl_delay and request_rate do not work with no matching entry Message-ID: <1549485183.59.0.634497522614.issue35922@roundup.psfhosted.org> New submission from Joseph Myers : RobotFileParser.crawl_delay and RobotFileParser.request_rate raise AttributeError for a robots.txt with no matching entry for the given user-agent, including no default entry, rather than returning None which would be correct according to the documentation. E.g.: >>> from urllib.robotparser import RobotFileParser >>> parser = RobotFileParser() >>> parser.parse([]) >>> parser.crawl_delay('example') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.6/urllib/robotparser.py", line 182, in crawl_delay return self.default_entry.delay AttributeError: 'NoneType' object has no attribute 'delay' ---------- components: Library (Lib) messages: 334982 nosy: joseph_myers priority: normal severity: normal status: open title: robotparser crawl_delay and request_rate do not work with no matching entry type: behavior versions: Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 15:37:38 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Wed, 06 Feb 2019 20:37:38 +0000 Subject: [issue35922] robotparser crawl_delay and request_rate do not work with no matching entry In-Reply-To: <1549485183.59.0.634497522614.issue35922@roundup.psfhosted.org> Message-ID: <1549485458.47.0.437924407873.issue35922@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 15:50:28 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 06 Feb 2019 20:50:28 +0000 Subject: [issue35921] Use ccache by default In-Reply-To: <1549481125.53.0.646421596529.issue35921@roundup.psfhosted.org> Message-ID: <1549486228.59.0.61545797022.issue35921@roundup.psfhosted.org> St?phane Wirtel added the comment: time -p make CC="/usr/bin/ccache gcc" --jobs 4 --silent > stdout.txt ^ stderr.txt real 4.36 user 3.69 sys 1.73 on a 4-thread CPU i7-7560U CPU @ 2.40GHz ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 15:58:33 2019 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 06 Feb 2019 20:58:33 +0000 Subject: [issue35904] Add statistics.fmean(seq) In-Reply-To: <1549411161.36.0.783593325223.issue35904@roundup.psfhosted.org> Message-ID: <1549486713.9.0.194936563906.issue35904@roundup.psfhosted.org> Mark Dickinson added the comment: Double-checking my own assertions: here's an example of a list xs of floats for which `fsum(xs) / len(xs)` is out by more than 1 ulp. (Obtained simply by checking a few lists of random.random() outputs; it's probably possible to construct something more obvious.) Python 3.7.2 (default, Dec 30 2018, 08:55:50) [Clang 10.0.0 (clang-1000.11.45.5)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import fractions, math>>> xs = [float.fromhex(h) for h in ['0x1.88104e64ffa5cp-3', '0x1.9b793215ddca8p-3', '0x1.754cbf6b09730p-1', '0x1.e2b4ca1df3680p-2', '0x1.91689b66782e1p-1']] >>> approx_mean = math.fsum(xs) / len(xs) >>> approx_mean # in [0.25, 0.5], so 1 ulp is 2**-54 0.47536945341150305 >>> exact_mean = sum(fractions.Fraction(x) for x in xs) / len(xs) >>> exact_mean Fraction(10704368466236809, 22517998136852480) >>> error_in_ulps = abs(exact_mean - fractions.Fraction(approx_mean)) * 2**54 >>> float(error_in_ulps) 1.2 I ran checks on 1000000 such randomly generated lists, and the error never exceeded 1.5 ulps. Sketch of proof of the 1.5 ulps bound: the fsum result is out by at most 0.5 ulps; the length n of the list is presumably represented exactly (lists with more than 2**53 elements would be infeasible). Division of the fsum result by n keeps the relative error the same, but potentially magnifies the ulps error by two, due to the usual "wobble" between relative error and ulps error, so that gives us up to 1 ulp error. Then the result of the division may need to be rounded again, giving another potential error of up to 0.5 ulps. The bound is strict: we can't actually attain 1.5 ulps, so the result we get can't be more than 1 ulp away from the correctly rounded result. > the proposed fmean name seems a bit unfortunate in that it's reversing the sense of sum and fsum I see Josh already made this observation: apologies for the duplicate bikeshedding. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 16:12:40 2019 From: report at bugs.python.org (Felipe Manzano) Date: Wed, 06 Feb 2019 21:12:40 +0000 Subject: [issue19953] __iadd__() doc not strictly correct In-Reply-To: <1386792788.94.0.272007303341.issue19953@psf.upfronthosting.co.za> Message-ID: <1549487560.2.0.606663620485.issue19953@roundup.psfhosted.org> Change by Felipe Manzano : ---------- pull_requests: +11750 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 16:12:49 2019 From: report at bugs.python.org (Felipe Manzano) Date: Wed, 06 Feb 2019 21:12:49 +0000 Subject: [issue19953] __iadd__() doc not strictly correct In-Reply-To: <1386792788.94.0.272007303341.issue19953@psf.upfronthosting.co.za> Message-ID: <1549487569.83.0.452244672254.issue19953@roundup.psfhosted.org> Change by Felipe Manzano : ---------- pull_requests: +11750, 11751 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 16:12:58 2019 From: report at bugs.python.org (Felipe Manzano) Date: Wed, 06 Feb 2019 21:12:58 +0000 Subject: [issue19953] __iadd__() doc not strictly correct In-Reply-To: <1386792788.94.0.272007303341.issue19953@psf.upfronthosting.co.za> Message-ID: <1549487578.52.0.815992521558.issue19953@roundup.psfhosted.org> Change by Felipe Manzano : ---------- pull_requests: +11750, 11751, 11752 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 16:16:12 2019 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 06 Feb 2019 21:16:12 +0000 Subject: [issue35913] asyncore: allow handling of half closed connections In-Reply-To: <1549468264.52.0.429414559636.issue35913@roundup.psfhosted.org> Message-ID: <1549487772.72.0.199173459712.issue35913@roundup.psfhosted.org> Andrew Svetlov added the comment: Technically the change seems correct, we have the same logic for asyncio half-closed streams. But I want to raise the flag again: why we are adding new functionality to the *deprecated* module? It violates our on deprecation policy, isn't it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 16:27:11 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 06 Feb 2019 21:27:11 +0000 Subject: [issue35913] asyncore: allow handling of half closed connections In-Reply-To: <1549468264.52.0.429414559636.issue35913@roundup.psfhosted.org> Message-ID: <1549488431.49.0.32987312443.issue35913@roundup.psfhosted.org> Giampaolo Rodola' added the comment: I agree. The problem I have with this is that it introduces a new method (handle_eof), which ends up in the "new functionality" bucket (even though it's not backward incompatible per-se, as it defaults on calling handle_close() anyway, but still it is technically a new API). Point with asyncore/chat is that every time you try to fix them you end up messing with the public API one way or another. I know from experience (pyftpdlib) that all asyncore/chat users already subclass/overwrite the base classes quite massively, so if they really want to rely on this new functionality they probably already have implemented it themselves. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 16:29:14 2019 From: report at bugs.python.org (Nina Zakharenko) Date: Wed, 06 Feb 2019 21:29:14 +0000 Subject: [issue35887] Doc string for updating the frozen version of importlib in _bootstrap.py incorrect In-Reply-To: <1549071736.85.0.965218389814.issue35887@roundup.psfhosted.org> Message-ID: <1549488554.08.0.67757688151.issue35887@roundup.psfhosted.org> Change by Nina Zakharenko : ---------- keywords: +patch pull_requests: +11753 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 16:29:21 2019 From: report at bugs.python.org (Nina Zakharenko) Date: Wed, 06 Feb 2019 21:29:21 +0000 Subject: [issue35887] Doc string for updating the frozen version of importlib in _bootstrap.py incorrect In-Reply-To: <1549071736.85.0.965218389814.issue35887@roundup.psfhosted.org> Message-ID: <1549488561.81.0.845161703189.issue35887@roundup.psfhosted.org> Change by Nina Zakharenko : ---------- keywords: +patch, patch pull_requests: +11753, 11754 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 16:29:29 2019 From: report at bugs.python.org (Nina Zakharenko) Date: Wed, 06 Feb 2019 21:29:29 +0000 Subject: [issue35887] Doc string for updating the frozen version of importlib in _bootstrap.py incorrect In-Reply-To: <1549071736.85.0.965218389814.issue35887@roundup.psfhosted.org> Message-ID: <1549488569.6.0.265886961973.issue35887@roundup.psfhosted.org> Change by Nina Zakharenko : ---------- keywords: +patch, patch, patch pull_requests: +11753, 11754, 11755 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 16:40:15 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 06 Feb 2019 21:40:15 +0000 Subject: [issue35921] Use ccache by default In-Reply-To: <1549481125.53.0.646421596529.issue35921@roundup.psfhosted.org> Message-ID: <1549489215.92.0.459636360286.issue35921@roundup.psfhosted.org> Antoine Pitrou added the comment: > Besides not rebuilding .o[bj] files where the sources have not changed, what else do these tools do? That's a different caching scheme. MSVC, make, ninja and friend will compare timestamps of the .c and .o files are avoid rebuilding if the .o file is younger. However, this doesn't work when you switch e.g. git branches or compilation options (e.g. from debug to release and vice-versa). ccache caches compilation results in its own cache directory and hashes command-line arguments as well as source file contenst. So it covers more situations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 16:41:05 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 06 Feb 2019 21:41:05 +0000 Subject: [issue35921] Use ccache by default In-Reply-To: <1549481125.53.0.646421596529.issue35921@roundup.psfhosted.org> Message-ID: <1549489265.77.0.109308552241.issue35921@roundup.psfhosted.org> Antoine Pitrou added the comment: (sorry for the typos; a bit sick today) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 17:00:03 2019 From: report at bugs.python.org (Nina Zakharenko) Date: Wed, 06 Feb 2019 22:00:03 +0000 Subject: [issue35923] Update the BuiltinImporter in importlib to use loader._ORIGIN instead of a hardcoded value Message-ID: <1549490401.35.0.0798819591421.issue35923@roundup.psfhosted.org> New submission from Nina Zakharenko : Update the BuiltinImporter in importllib to set the origin from the shared `loader._ORIGIN` attribute instead of using the hard-coded value of 'built-in' in order to match the functionality of FrozenImporter. The FrozenImporter was updated to use this attribute in PR GH-11732 (https://github.com/python/cpython/pull/11732) ---------- assignee: nnja components: Interpreter Core messages: 334989 nosy: barry, nnja priority: low severity: normal status: open title: Update the BuiltinImporter in importlib to use loader._ORIGIN instead of a hardcoded value type: enhancement versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 17:56:33 2019 From: report at bugs.python.org (Isaac Boukris) Date: Wed, 06 Feb 2019 22:56:33 +0000 Subject: [issue35913] asyncore: allow handling of half closed connections In-Reply-To: <1549468264.52.0.429414559636.issue35913@roundup.psfhosted.org> Message-ID: <1549493793.61.0.589898685708.issue35913@roundup.psfhosted.org> Isaac Boukris added the comment: > But I want to raise the flag again: why we are adding new functionality to the *deprecated* module? It violates our on deprecation policy, isn't it? I'm biased but I see this as more of a small and subtle fix for the current logic that incorrectly treats this as a closed connection, rather than a new feature. In addition, it could serve a documentation hint for people troubleshooting edge cases in their code (especially people who are not familiar with these semantics). > Point with asyncore/chat is that every time you try to fix them you end up messing with the public API one way or another. I'd agree about the first commit (avoid calling recv with size zero), which may change the behavior for a poorly written application that tries to read a chunk of zero bytes, but the second commit is straight forward and I can't see how it could break anything. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 19:02:22 2019 From: report at bugs.python.org (Josiah Ulfers) Date: Thu, 07 Feb 2019 00:02:22 +0000 Subject: [issue35924] curses segfault resizing window Message-ID: <1549497741.38.0.310308715457.issue35924@roundup.psfhosted.org> New submission from Josiah Ulfers : To provoke a segmentation fault, run the attached, then grab the top or bottom edge of the window. Move it down or up until it overlaps the box. Might need to wiggle the edge a little, but it's reliably reproducible. Expected error, which is what happens when dragging the left or right edge instead of the top or bottom: Traceback (most recent call last): File "cursesfault.py", line 12, in curses.wrapper(main) File "/usr/lib64/python3.6/curses/__init__.py", line 94, in wrapper return func(stdscr, *args, **kwds) File "cursesfault.py", line 9, in main w.addstr(0, 0, box) _curses.error: addwstr() returned ERR Actual error message varies a little. It's either: *** Error in `python3': corrupted size vs. prev_size: 0x000055b3055ba820 *** Aborted (core dumped) Or: *** Error in `python3': double free or corruption (!prev): 0x000055b61e1ffbb0 *** Aborted (core dumped) Or: *** Error in `python': malloc(): memory corruption: 0x0000564907a5a4f0 *** Aborted (core dumped) Possibly relates to issue15581 --- Python 2.7.14 and 3.6.5 OpenSUSE 15.0 KDE Plasma 5.12.6 uname -a Linux ... 4.12.14-lp150.12.45-default #1 SMP Mon Jan 14 20:29:59 UTC 2019 (7a62739) x86_64 x86_64 x86_64 GNU/Linux ---------- components: Extension Modules files: cursesfault.py messages: 334991 nosy: Josiah Ulfers priority: normal severity: normal status: open title: curses segfault resizing window type: crash versions: Python 2.7, Python 3.6 Added file: https://bugs.python.org/file48108/cursesfault.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 19:39:24 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Thu, 07 Feb 2019 00:39:24 +0000 Subject: [issue22474] No explanation of how a task gets destroyed in asyncio 'task' documentation In-Reply-To: <1411516943.46.0.304192335953.issue22474@psf.upfronthosting.co.za> Message-ID: <1549499964.17.0.128879278741.issue22474@roundup.psfhosted.org> Cheryl Sabella added the comment: It seems that the note about a warning being logged if a pending task is destroyed does not exist in the new, rewritten version of the asyncio docs. Therefore, I'm going to close this as out of date. ---------- nosy: +cheryl.sabella resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 19:43:31 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 07 Feb 2019 00:43:31 +0000 Subject: [issue35921] Use ccache by default In-Reply-To: <1549481125.53.0.646421596529.issue35921@roundup.psfhosted.org> Message-ID: <1549500211.26.0.527846300345.issue35921@roundup.psfhosted.org> Raymond Hettinger added the comment: Antoine, thanks for pointing out that ccache exists. I got immediate build-time improvements. For the Mac, I did a "brew install ccache" and prepended "/usr/local/opt/ccache/libexec". No modification of our files was necessary. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 19:43:55 2019 From: report at bugs.python.org (Eric Snow) Date: Thu, 07 Feb 2019 00:43:55 +0000 Subject: [issue35914] [2.7] PyStructSequence objects not behaving like nametuple In-Reply-To: <1549468482.77.0.451102979772.issue35914@roundup.psfhosted.org> Message-ID: <1549500235.03.0.725171868467.issue35914@roundup.psfhosted.org> Eric Snow added the comment: Sounds good. I hope that helped. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 20:16:31 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Thu, 07 Feb 2019 01:16:31 +0000 Subject: [issue35606] Add prod() function to the math module In-Reply-To: <1546025352.75.0.868813504694.issue35606@roundup.psfhosted.org> Message-ID: <1549502191.53.0.857145308759.issue35606@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: PR 11359 has the following properties in its current state: Performance vs naive implementation ----------------------------------- ./python -m perf timeit -s "import functools;import operator;iterable=list(range(10000))" 'functools.reduce(operator.mul, iterable, 1)' ..................... Mean +- std dev: 654 us +- 15 us ./python -m perf timeit -s "import math;iterable=list(range(10000))" 'math.prod(iterable)' ..................... Mean +- std dev: 72.3 us +- 1.1 us ./python -m perf timeit -s "import functools;import operator;iterable=list(map(float,range(10000)))" 'functools.reduce(operator.mul, iterable, 1)' ..................... Mean +- std dev: 705 us +- 10 us ./python -m perf timeit -s "import math;iterable=list(map(float,range(10000)))" 'math.prod(iterable)' ..................... Mean +- std dev: 52.9 us +- 2.0 us ./python -m perf timeit -s "import functools;import decimal;import operator;iterable=list(map(decimal.Decimal,range(10000)))" 'functools.reduce(operator.mul, iterable, 1)' ..................... Mean +- std dev: 2.10 ms +- 0.03 ms ./python -m perf timeit -s "import math;import decimal;iterable=list(map(decimal.Decimal,range(10000)))" 'math.prod(iterable)' Mean +- std dev: 1.12 ms +- 0.21 ms Properties ---------- * It behaves with floats as numpy.prod: - A product of a finite floating-point (or convertible-to-float) numbers yields a float, nan or +-inf (no overflow checks). - A product involving infinities but no NaNs or zeros returns an appropriately-signed infinity. - A product involving both infinities and zeros (but not NaNs) returns 'NaN'. - A product involving a NaN at any point returns NaN. * Is a implemented as general purpose function - like the built-in sum - as Tim is advising. It can multiply any Python type but has two fast-paths for floats and integers (or a mix of both). ------------- In my humble opinion, any type-specialized implementation should exist in addition to this function (as fprod, iprod, scaledProd) while prod should remain as a general purpose function mirroring sum. Notice that people using numerical suites like numpy are used to the properties described in the previous paragraph and I think this is an advantage. The main advantage of the function as it exists now in PR11359 is convenience and speed (almost 10x for fast paths and 2x for general types). I think this function will be very useful for scientific/statistical computing without the need for pulling in numpy and friends. What do people think? ---------- nosy: +pablogsal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 20:45:28 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Thu, 07 Feb 2019 01:45:28 +0000 Subject: [issue35925] test_httplib test_nntplib test_ssl fail on ARMv7 Ubuntu 3.7 and ARMv7 Ubuntu 3.x buildbots Message-ID: <1549503926.32.0.191493141556.issue35925@roundup.psfhosted.org> New submission from Pablo Galindo Salgado : Example failures https://buildbot.python.org/all/#/builders/117 https://buildbot.python.org/all/#/builders/106 ====================================================================== ERROR: test_networked_good_cert (test.test_httplib.HTTPSTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/test/test_httplib.py", line 1629, in test_networked_good_cert h.request('GET', '/') File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py", line 1229, in request self._send_request(method, url, body, headers, encode_chunked) File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py", line 1275, in _send_request self.endheaders(body, encode_chunked=encode_chunked) File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py", line 1224, in endheaders self._send_output(message_body, encode_chunked=encode_chunked) File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py", line 1016, in _send_output self.send(msg) File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py", line 956, in send self.connect() File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py", line 1391, in connect self.sock = self._context.wrap_socket(self.sock, File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/ssl.py", line 405, in wrap_socket return self.sslsocket_class._create( File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/ssl.py", line 853, in _create self.do_handshake() File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/ssl.py", line 1117, in do_handshake self._sslobj.do_handshake() ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: EE certificate key too weak (_ssl.c:1055) ---------------------------------------------------------------------- Ran 105 tests in 2.477s Got an error: [SSL: SSLV3_ALERT_BAD_CERTIFICATE] sslv3 alert bad certificate (_ssl.c:1055) Got an error: [SSL: SSLV3_ALERT_BAD_CERTIFICATE] sslv3 alert bad certificate (_ssl.c:1055) Got an error: [SSL: SSLV3_ALERT_BAD_CERTIFICATE] sslv3 alert bad certificate (_ssl.c:1055) test_local_bad_hostname (test.test_httplib.HTTPSTest) ... server (('127.0.0.1', 41921):41921 ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)): [06/Feb/2019 06:22:07] code 404, message File not found server (('127.0.0.1', 41921):41921 ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)): [06/Feb/2019 06:22:07] "GET /nonexistent HTTP/1.1" 404 - server (('127.0.0.1', 41921):41921 ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)): [06/Feb/2019 06:22:07] code 404, message File not found server (('127.0.0.1', 41921):41921 ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)): [06/Feb/2019 06:22:07] "GET /nonexistent HTTP/1.1" 404 - stopping HTTPS server joining HTTPS thread ok test_local_good_hostname (test.test_httplib.HTTPSTest) ... server (('127.0.0.1', 38877):38877 ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)): [06/Feb/2019 06:22:07] code 404, message File not found server (('127.0.0.1', 38877):38877 ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)): [06/Feb/2019 06:22:07] "GET /nonexistent HTTP/1.1" 404 - stopping HTTPS server joining HTTPS thread ok Got an error: [SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:1055) test_local_unknown_cert (test.test_httplib.HTTPSTest) ... stopping HTTPS server joining HTTPS thread ok Multiple SSL failures, also old commits that previously succeeded fail now. This seems something in the buildbot itself. Gregory, do you know if something SLL related was upgraded/modify in the gps-ubuntu-exynos5-armv7l worker? ---------- components: Tests messages: 334996 nosy: gregory.p.smith, pablogsal priority: normal severity: normal status: open title: test_httplib test_nntplib test_ssl fail on ARMv7 Ubuntu 3.7 and ARMv7 Ubuntu 3.x buildbots versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 21:19:44 2019 From: report at bugs.python.org (Dong-hee Na) Date: Thu, 07 Feb 2019 02:19:44 +0000 Subject: [issue35923] Update the BuiltinImporter in importlib to use loader._ORIGIN instead of a hardcoded value In-Reply-To: <1549490401.35.0.0798819591421.issue35923@roundup.psfhosted.org> Message-ID: <1549505984.58.0.896491284217.issue35923@roundup.psfhosted.org> Dong-hee Na added the comment: @nnja Hi, Can I work on this issue if no one works on it? ---------- nosy: +corona10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 21:49:03 2019 From: report at bugs.python.org (Paul Monson) Date: Thu, 07 Feb 2019 02:49:03 +0000 Subject: [issue35740] openssl version 1.1.1 need to be there in cpython-source-deps for windows ARM64 In-Reply-To: <1547538324.61.0.844550645044.issue35740@roundup.psfhosted.org> Message-ID: <1549507743.85.0.43045486411.issue35740@roundup.psfhosted.org> Change by Paul Monson : ---------- nosy: +Paul Monson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 21:49:23 2019 From: report at bugs.python.org (Paul Monson) Date: Thu, 07 Feb 2019 02:49:23 +0000 Subject: [issue35705] libffi support is not there for windows on ARM64 In-Reply-To: <1547121550.49.0.236282242813.issue35705@roundup.psfhosted.org> Message-ID: <1549507763.78.0.357068072387.issue35705@roundup.psfhosted.org> Change by Paul Monson : ---------- nosy: +Paul Monson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 21:53:24 2019 From: report at bugs.python.org (Paul Monson) Date: Thu, 07 Feb 2019 02:53:24 +0000 Subject: [issue35926] Need openssl 1.1.1 support on Windows for ARM and ARM64 Message-ID: <1549508003.09.0.398179114845.issue35926@roundup.psfhosted.org> New submission from Paul Monson : Need code and test changes to match https://bugs.python.org/issue35740 ---------- assignee: christian.heimes components: SSL, Windows messages: 334998 nosy: Paul Monson, christian.heimes, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Need openssl 1.1.1 support on Windows for ARM and ARM64 type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 21:55:45 2019 From: report at bugs.python.org (Roundup Robot) Date: Thu, 07 Feb 2019 02:55:45 +0000 Subject: [issue35926] Need openssl 1.1.1 support on Windows for ARM and ARM64 In-Reply-To: <1549508003.09.0.398179114845.issue35926@roundup.psfhosted.org> Message-ID: <1549508145.32.0.0647959933853.issue35926@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch pull_requests: +11757 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 21:55:56 2019 From: report at bugs.python.org (Roundup Robot) Date: Thu, 07 Feb 2019 02:55:56 +0000 Subject: [issue35926] Need openssl 1.1.1 support on Windows for ARM and ARM64 In-Reply-To: <1549508003.09.0.398179114845.issue35926@roundup.psfhosted.org> Message-ID: <1549508156.95.0.348385654101.issue35926@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch, patch pull_requests: +11757, 11758 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 21:56:05 2019 From: report at bugs.python.org (Roundup Robot) Date: Thu, 07 Feb 2019 02:56:05 +0000 Subject: [issue35926] Need openssl 1.1.1 support on Windows for ARM and ARM64 In-Reply-To: <1549508003.09.0.398179114845.issue35926@roundup.psfhosted.org> Message-ID: <1549508165.25.0.115470177231.issue35926@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch, patch, patch pull_requests: +11757, 11758, 11759 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 21:56:15 2019 From: report at bugs.python.org (Roundup Robot) Date: Thu, 07 Feb 2019 02:56:15 +0000 Subject: [issue35926] Need openssl 1.1.1 support on Windows for ARM and ARM64 In-Reply-To: <1549508003.09.0.398179114845.issue35926@roundup.psfhosted.org> Message-ID: <1549508175.01.0.818282938704.issue35926@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch, patch, patch, patch pull_requests: +11757, 11758, 11759, 11760 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 22:05:31 2019 From: report at bugs.python.org (Sihoon Lee) Date: Thu, 07 Feb 2019 03:05:31 +0000 Subject: [issue35906] Header Injection in urllib In-Reply-To: <1549413131.7.0.216595978501.issue35906@roundup.psfhosted.org> Message-ID: <1549508731.55.0.59770614197.issue35906@roundup.psfhosted.org> Sihoon Lee added the comment: Sorry, I'm late. My review is here. https://github.com/python/cpython/pull/11768 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 22:34:00 2019 From: report at bugs.python.org (Martin Panter) Date: Thu, 07 Feb 2019 03:34:00 +0000 Subject: [issue35906] Header Injection in urllib In-Reply-To: <1549413131.7.0.216595978501.issue35906@roundup.psfhosted.org> Message-ID: <1549510440.36.0.403946117452.issue35906@roundup.psfhosted.org> Martin Panter added the comment: Maybe related to Victor's "Issue 1" described in Issue 32085. That is also a security bug about CRLF in the URL's path, but was opened before Issue 30500 was opened and the code changed, so I'm not sure if it is the same as this or not. Also there is Issue 13359, a proposal to automatically percent-encode invalid URLs. For a security fix, I'm not sure but it might be safer to raise an exception, rather than rewriting the invalid URL to a valid one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 23:16:50 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 07 Feb 2019 04:16:50 +0000 Subject: [issue35925] test_httplib test_nntplib test_ssl fail on ARMv7 Ubuntu 3.7 and ARMv7 Ubuntu 3.x buildbots In-Reply-To: <1549503926.32.0.191493141556.issue35925@roundup.psfhosted.org> Message-ID: Gregory P. Smith added the comment: FYI - the name of this bot is misleading. It is now Debian testing as of 18 hours ago instead of obsolete Ubuntu 14.04. I finally upgraded it. Opens version says 1.1.1a. -- blame half the typos on my phone. On Wed, Feb 6, 2019, 5:45 PM Pablo Galindo Salgado > New submission from Pablo Galindo Salgado : > > Example failures > > https://buildbot.python.org/all/#/builders/117 > https://buildbot.python.org/all/#/builders/106 > > ====================================================================== > ERROR: test_networked_good_cert (test.test_httplib.HTTPSTest) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/test/test_httplib.py", > line 1629, in test_networked_good_cert > h.request('GET', '/') > File > "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py", > line 1229, in request > self._send_request(method, url, body, headers, encode_chunked) > File > "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py", > line 1275, in _send_request > self.endheaders(body, encode_chunked=encode_chunked) > File > "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py", > line 1224, in endheaders > self._send_output(message_body, encode_chunked=encode_chunked) > File > "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py", > line 1016, in _send_output > self.send(msg) > File > "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py", > line 956, in send > self.connect() > File > "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py", > line 1391, in connect > self.sock = self._context.wrap_socket(self.sock, > File > "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/ssl.py", > line 405, in wrap_socket > return self.sslsocket_class._create( > File > "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/ssl.py", > line 853, in _create > self.do_handshake() > File > "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/ssl.py", > line 1117, in do_handshake > self._sslobj.do_handshake() > ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate > verify failed: EE certificate key too weak (_ssl.c:1055) > ---------------------------------------------------------------------- > Ran 105 tests in 2.477s > > Got an error: > [SSL: SSLV3_ALERT_BAD_CERTIFICATE] sslv3 alert bad certificate > (_ssl.c:1055) > Got an error: > [SSL: SSLV3_ALERT_BAD_CERTIFICATE] sslv3 alert bad certificate > (_ssl.c:1055) > Got an error: > [SSL: SSLV3_ALERT_BAD_CERTIFICATE] sslv3 alert bad certificate > (_ssl.c:1055) > test_local_bad_hostname (test.test_httplib.HTTPSTest) ... server > (('127.0.0.1', 41921):41921 ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)): > [06/Feb/2019 06:22:07] code 404, message File not found > server (('127.0.0.1', 41921):41921 ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', > 256)): > [06/Feb/2019 06:22:07] "GET /nonexistent HTTP/1.1" 404 - > server (('127.0.0.1', 41921):41921 ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', > 256)): > [06/Feb/2019 06:22:07] code 404, message File not found > server (('127.0.0.1', 41921):41921 ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', > 256)): > [06/Feb/2019 06:22:07] "GET /nonexistent HTTP/1.1" 404 - > stopping HTTPS server > joining HTTPS thread > ok > test_local_good_hostname (test.test_httplib.HTTPSTest) ... server > (('127.0.0.1', 38877):38877 ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)): > [06/Feb/2019 06:22:07] code 404, message File not found > server (('127.0.0.1', 38877):38877 ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', > 256)): > [06/Feb/2019 06:22:07] "GET /nonexistent HTTP/1.1" 404 - > stopping HTTPS server > joining HTTPS thread > ok > Got an error: > [SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:1055) > test_local_unknown_cert (test.test_httplib.HTTPSTest) ... stopping HTTPS > server > joining HTTPS thread > ok > > Multiple SSL failures, also old commits that previously succeeded fail > now. This seems something in the buildbot itself. Gregory, do you know if > something SLL related was upgraded/modify in the gps-ubuntu-exynos5-armv7l > worker? > > ---------- > components: Tests > messages: 334996 > nosy: gregory.p.smith, pablogsal > priority: normal > severity: normal > status: open > title: test_httplib test_nntplib test_ssl fail on ARMv7 Ubuntu 3.7 and > ARMv7 Ubuntu 3.x buildbots > versions: Python 3.7, Python 3.8 > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 23:19:04 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 07 Feb 2019 04:19:04 +0000 Subject: [issue35925] test_httplib test_nntplib test_ssl fail on ARMv7 Ubuntu 3.7 and ARMv7 Ubuntu 3.x buildbots In-Reply-To: <1549503926.32.0.191493141556.issue35925@roundup.psfhosted.org> Message-ID: <1549513144.08.0.750812391063.issue35925@roundup.psfhosted.org> Change by Gregory P. Smith : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 6 23:38:32 2019 From: report at bugs.python.org (ADataGman) Date: Thu, 07 Feb 2019 04:38:32 +0000 Subject: [issue35927] Intra-package References Documentation Incomplete Message-ID: <1549514310.42.0.442993756904.issue35927@roundup.psfhosted.org> New submission from ADataGman : Attempting to follow https://docs.python.org/3.6/tutorial/modules.html#intra-package-references I was unable to recreate the intra-package reference as described. "For example, if the module sound.filters.vocoder needs to use the echo module in the sound.effects package, it can use from sound.effects import echo." Creating the file structure described in https://docs.python.org/3.6/tutorial/modules.html#packages, with empty __init__.py files at all levels, or with __all__ defined as containing relevant file names, results in "No module named 'sound'". If I try to run this using "from ..effects import echo" then it results in "attempted relative import beyond top-level package". At least one other user has run into this issue with this stack overflow post: https://stackoverflow.com/questions/53109627/python-intra-package-reference-doesnt-work-at-all ---------- assignee: docs at python components: Documentation files: sound.zip messages: 335002 nosy: ADataGman, docs at python priority: normal severity: normal status: open title: Intra-package References Documentation Incomplete type: behavior versions: Python 3.6 Added file: https://bugs.python.org/file48109/sound.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 00:18:27 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Thu, 07 Feb 2019 05:18:27 +0000 Subject: [issue22228] Adapt bash readline operate-and-get-next function In-Reply-To: <1408441328.29.0.0681426449148.issue22228@psf.upfronthosting.co.za> Message-ID: <1549516707.45.0.541876253866.issue22228@roundup.psfhosted.org> Steven D'Aprano added the comment: If the licencing issue is resolved, can we reconsider this for 3.8? ---------- versions: +Python 3.8 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 01:12:04 2019 From: report at bugs.python.org (Nina Zakharenko) Date: Thu, 07 Feb 2019 06:12:04 +0000 Subject: [issue35923] Update the BuiltinImporter in importlib to use loader._ORIGIN instead of a hardcoded value In-Reply-To: <1549490401.35.0.0798819591421.issue35923@roundup.psfhosted.org> Message-ID: <1549519924.97.0.192199708157.issue35923@roundup.psfhosted.org> Nina Zakharenko added the comment: Hey Dong-hee, Unfortunately, I already started the work on this which is why I assigned the ticket to myself when I opened it. This work came up as a continuation of another ticket I worked on - bpo-35321 / GH-11732. I wanted to keep them as separate issues. I'm sorry, I hope you find another ticket to work on soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 01:20:03 2019 From: report at bugs.python.org (Sihoon Lee) Date: Thu, 07 Feb 2019 06:20:03 +0000 Subject: [issue35906] Header Injection in urllib In-Reply-To: <1549413131.7.0.216595978501.issue35906@roundup.psfhosted.org> Message-ID: <1549520403.63.0.335512528167.issue35906@roundup.psfhosted.org> Sihoon Lee added the comment: Yes, I thought so. before the commit version i said, the previous version(~3.4.6), raised an exception(no host given~) in urlopen failing parsing host. If this patch wants to be same as the previous version, It is right to raise an exception like the previous version. I thought there is no exact answer, only depends on Python features. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 01:59:04 2019 From: report at bugs.python.org (Lele Gaifax) Date: Thu, 07 Feb 2019 06:59:04 +0000 Subject: [issue22228] Adapt bash readline operate-and-get-next function In-Reply-To: <1408441328.29.0.0681426449148.issue22228@psf.upfronthosting.co.za> Message-ID: <1549522744.43.0.590171205953.issue22228@roundup.psfhosted.org> Lele Gaifax added the comment: Luckily the referenced branch is still around on GH: https://github.com/lelit/cpython-hg-mirror/tree/issue22228_2 As the name says, it is not related to modern CPython' git repo though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 02:04:06 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 07 Feb 2019 07:04:06 +0000 Subject: [issue35606] Add prod() function to the math module In-Reply-To: <1546025352.75.0.868813504694.issue35606@roundup.psfhosted.org> Message-ID: <1549523046.39.0.391513576191.issue35606@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset bc098515864d0d1ffe8fb97ca1a0526c30fee45a by Raymond Hettinger (Pablo Galindo) in branch 'master': bpo-35606: Implement math.prod (GH-11359) https://github.com/python/cpython/commit/bc098515864d0d1ffe8fb97ca1a0526c30fee45a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 02:04:59 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 07 Feb 2019 07:04:59 +0000 Subject: [issue35606] Add prod() function to the math module In-Reply-To: <1546025352.75.0.868813504694.issue35606@roundup.psfhosted.org> Message-ID: <1549523099.75.0.638554257287.issue35606@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 02:59:44 2019 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 07 Feb 2019 07:59:44 +0000 Subject: [issue35913] asyncore: allow handling of half closed connections In-Reply-To: <1549468264.52.0.429414559636.issue35913@roundup.psfhosted.org> Message-ID: <1549526384.22.0.152229540778.issue35913@roundup.psfhosted.org> Andrew Svetlov added the comment: The change adds a new public method. The method should be added to documentation also. Documentation requires `.. versionadded:: 3.8` tag. It doesn't look like *just a bugfix* but a feature. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 03:25:16 2019 From: report at bugs.python.org (Isaac Boukris) Date: Thu, 07 Feb 2019 08:25:16 +0000 Subject: [issue35913] asyncore: allow handling of half closed connections In-Reply-To: <1549468264.52.0.429414559636.issue35913@roundup.psfhosted.org> Message-ID: <1549527916.75.0.271661941662.issue35913@roundup.psfhosted.org> Isaac Boukris added the comment: if not data: # a closed connection is indicated by signaling # a read condition, and having recv() return 0. self.handle_close() return b'' This above is the current code. Do you agree that it makes a wrong assumption and therefore behave incorrectly? If so, how do you suggest fixing it without adding a new method? Otherwise; maybe we can at least amend the comment in the code, and perhaps add a word or two to the doc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 06:03:24 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 07 Feb 2019 11:03:24 +0000 Subject: [issue35917] multiprocessing: provide unit-tests for manager classes and shareable types In-Reply-To: <1549470919.94.0.961552344771.issue35917@roundup.psfhosted.org> Message-ID: <1549537404.67.0.331010398403.issue35917@roundup.psfhosted.org> Antoine Pitrou added the comment: New changeset 2848d9d29914948621bce26bf0d9a89f2e19b97b by Antoine Pitrou (Giampaolo Rodola) in branch 'master': bpo-35917: Test multiprocessing manager classes and shareable types (GH-11772) https://github.com/python/cpython/commit/2848d9d29914948621bce26bf0d9a89f2e19b97b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 06:09:20 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 07 Feb 2019 11:09:20 +0000 Subject: [issue35917] multiprocessing: provide unit-tests for manager classes and shareable types In-Reply-To: <1549470919.94.0.961552344771.issue35917@roundup.psfhosted.org> Message-ID: <1549537760.27.0.424090031766.issue35917@roundup.psfhosted.org> Change by Antoine Pitrou : ---------- pull_requests: +11761 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 06:09:28 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 07 Feb 2019 11:09:28 +0000 Subject: [issue35917] multiprocessing: provide unit-tests for manager classes and shareable types In-Reply-To: <1549470919.94.0.961552344771.issue35917@roundup.psfhosted.org> Message-ID: <1549537768.22.0.598283669122.issue35917@roundup.psfhosted.org> Change by Antoine Pitrou : ---------- pull_requests: +11761, 11762 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 06:09:35 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 07 Feb 2019 11:09:35 +0000 Subject: [issue35917] multiprocessing: provide unit-tests for manager classes and shareable types In-Reply-To: <1549470919.94.0.961552344771.issue35917@roundup.psfhosted.org> Message-ID: <1549537775.83.0.377812846557.issue35917@roundup.psfhosted.org> Change by Antoine Pitrou : ---------- pull_requests: +11761, 11762, 11763 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 06:34:16 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 07 Feb 2019 11:34:16 +0000 Subject: [issue35917] multiprocessing: provide unit-tests for manager classes and shareable types In-Reply-To: <1549470919.94.0.961552344771.issue35917@roundup.psfhosted.org> Message-ID: <1549539256.72.0.166745351077.issue35917@roundup.psfhosted.org> Antoine Pitrou added the comment: New changeset 15526f5be72f547288c16d53526fc74f15ee61ed by Antoine Pitrou in branch '3.7': [3.7] bpo-35917: Test multiprocessing manager classes and shareable types (GH-11772) (GH-11780) https://github.com/python/cpython/commit/15526f5be72f547288c16d53526fc74f15ee61ed ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 06:34:54 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 07 Feb 2019 11:34:54 +0000 Subject: [issue35917] multiprocessing: provide unit-tests for manager classes and shareable types In-Reply-To: <1549470919.94.0.961552344771.issue35917@roundup.psfhosted.org> Message-ID: <1549539294.7.0.738333300282.issue35917@roundup.psfhosted.org> Antoine Pitrou added the comment: Thanks Giampaolo! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 06:49:11 2019 From: report at bugs.python.org (Ned Batchelder) Date: Thu, 07 Feb 2019 11:49:11 +0000 Subject: [issue2506] Add mechanism to disable optimizations In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za> Message-ID: <1549540151.89.0.150189423783.issue2506@roundup.psfhosted.org> Ned Batchelder added the comment: FWIW, Yury started a pull request: https://github.com/python/cpython/pull/9693 ---------- keywords: -patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 07:14:52 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Thu, 07 Feb 2019 12:14:52 +0000 Subject: [issue35904] Add statistics.fmean(seq) In-Reply-To: <1549411161.36.0.783593325223.issue35904@roundup.psfhosted.org> Message-ID: <20190207121443.GG1834@ando.pearwood.info> Steven D'Aprano added the comment: In the PEP, I did say that I was making no attempt to compete with numpy for speed, and that correctness was more important than speed. That doesn't mean I don't care about speed. Nor do I necessarily care about absolute precision when given nothing but float arguments. Mark suggests that using fsum() will be accurate to within 1.5 ulp which satisfies me for float arguments. I doubt that stdev etc would be able to promise that accuracy, so provided your data is all floats, that seems like a pretty good result for the mean. But I'm not super-keen on having two separate mean() functions if that opens the floodgates to people wanting every statistics function to grow a fast-but-floats-only twin. That would make me sad. But maybe mean() is special enough to justify twinning it. In my ideal world, I'd have a single mean() function that had a fast-path for float data, but would automatically drop down to a slower but more accurate path for other types, out-of-range data, etc. I believe that the the built-in sum() function does something like this. When I say "more accurate", this isn't a complaint about fsum(). It refers to the limitation of floats themselves. Call me Mr Silly if you like, but if I need to take the average of numbers bigger than 2**1074 I would like to be able to, even if it takes a bit longer :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 07:18:37 2019 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 07 Feb 2019 12:18:37 +0000 Subject: [issue22213] Make pyvenv style virtual environments easier to configure when embedding Python In-Reply-To: <1408275761.36.0.915361061447.issue22213@psf.upfronthosting.co.za> Message-ID: <1549541917.22.0.243741269384.issue22213@roundup.psfhosted.org> Nick Coghlan added the comment: Yeah, I mainly cc'ed Victor and Eric since making this easier ties into one of the original design goals for PEP 432 (even though I haven't managed to persuade either of them to become co-authors of that PEP yet). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 07:23:49 2019 From: report at bugs.python.org (Dave Shawley) Date: Thu, 07 Feb 2019 12:23:49 +0000 Subject: [issue32972] unittest.TestCase coroutine support In-Reply-To: <1519843317.02.0.467229070634.issue32972@psf.upfronthosting.co.za> Message-ID: <1549542229.51.0.483947348483.issue32972@roundup.psfhosted.org> Dave Shawley added the comment: Hi everyone, I'm trying to reboot conversation on this issue since I would love for this to land in Python 3.8. At the recommendation of Terry Jan Reedy, here is my summary of where I think that the discussion is currently. If anything is misrepresented, incorrectly linked, or if I misspelled anyones name, I apologize. Feel free to correct any mistakes that you notice. New subclass of TestCase versus enhancing unittest.TestCase ----------------------------------------------------------- This was one of the primary discussion points since the start of this BPO. I believe that Petter S (msg313454), Yury Selivanov (msg313695), and Andrew Svetlov (msg313481) were +1 on having a new sub-class of unittest.TestCase whereas Zachary Ware (msg313696) and R. David Murray (msg313413) would prefer that unittest.TestCase be enhanced to support async methods directly. This is (in my opinion) the most contentious of the issues. It also is the one with the largest impact on the implementation. I feel that it is still largely up in the air amongst the core developers. Lifecycle of the loop --------------------- Whether the loop should live for the entire execution of a TestCase or for the execution of an individual test method came up a few times. Nathaniel Smith (msg313455) was concerned about callbacks leaking between tests. Yury Selivanov and Zachary Ware agreed that having a single event loop per class was acceptable (msg313696 and msg313700). Support for other loops ----------------------- Supporting 3rd party loop implementations (e.g., Tornado, Twisted, curio/trio) was discussed briefly. The conclusion that I drew from the discussion is that the built-in testing class was not required to offer direct support to non-asyncio compatible loops. Most notably msg313481 from Andrew Svetlov influenced my implementation. Where should support live? -------------------------- This is only relevant if we are not enhancing unittest.TestCase. Petter S favored that the separate test case implementation live in asyncio instead of unittest. I don't believe that anyone else had a strong opinion on this issue. Should we have explicit methods for async behavior? --------------------------------------------------- Yury Selivanov was most outspoken on explicitly named "async" methods like "asyncSetup", "asyncAddCallback", and the like. Particularly in msg313695 and msg313700. Zachary Ware seemed to agree that the separation was necessary but the functionality could be implemented by calling the async methods from the existing setUp and setUpClass methods (msg313699). Did I miss anything? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 07:30:33 2019 From: report at bugs.python.org (Palle Ravn) Date: Thu, 07 Feb 2019 12:30:33 +0000 Subject: [issue35928] socket makefile read-write discards received data Message-ID: <1549542632.16.0.548779418887.issue35928@roundup.psfhosted.org> New submission from Palle Ravn : Using socket.makefile in read-write mode had a bug introduced between version 3.6.6 and 3.6.7. The same bug is present in version 3.7.x. The below code example will behave very differently between 3.6.6 and 3.6.7. It's based on the echo-server example from the docs. import socket HOST = '127.0.0.1' PORT = 0 with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s: s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) s.bind((HOST, PORT)) print(f'Waiting for connection on port {s.getsockname()[1]}') s.listen(1) conn, addr = s.accept() print(f'Connected by {addr}') with conn: f = conn.makefile(mode='rw') while True: m = f.readline() print(f'msg: {m!r}') if not m: exit(0) f.write(m) f.flush() Python 3.6.7: Sending the string "Hello\nYou\n" will only print "Hello\n" and also only return "Hello\n" to the client. Removing the lines with f.write(m) and f.flush() and both "Hello\n" and "You\n" will be returned to the client. It's like the call to f.write() somehow empties the read buffer. Python 3.6.6: Sending "Hello\nYou\n" will return "Hello\n" and "You\n" to the client without any modifications to the above code. ---------- components: IO messages: 335017 nosy: pravn priority: normal severity: normal status: open title: socket makefile read-write discards received data type: behavior versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 07:31:12 2019 From: report at bugs.python.org (Dave Shawley) Date: Thu, 07 Feb 2019 12:31:12 +0000 Subject: [issue32972] unittest.TestCase coroutine support In-Reply-To: <1519843317.02.0.467229070634.issue32972@psf.upfronthosting.co.za> Message-ID: <1549542672.3.0.80397634516.issue32972@roundup.psfhosted.org> Dave Shawley added the comment: PR 10296 is my implementation of a unittest.TestCase subclass solution to this issue. This comment explains the approach and rationale in detail. Let's discuss this and see if the implementation meets expectations or should be abandoned. I refactored unittest.TestCase to isolate the running of test methods into a new helper method named _runTest and add a new hook named _terminateTest. The _runTest method is used to customize test method execution in sub-classes. The _terminateTest method is called from within the finally block in unittest.TestCase.run. It is an empty method in unittest.TestCase. This was the only change to unittest.TestCase. A new class unittest.AsyncioTestCase was added that implements async-based testing. It is a direct sub-class of unittest.TestCase that: * uses a @property named loop to lazily create an event loop instance * destroys the event loop instance in _terminateTest * re-implements _runTest to call new asynchronous hook methods * adds asyncSetUp and asyncTearDown methods that simply call the synchronous methods * re-implements doCleanups to call co-routines asynchronously Rationale --------- I used asyncio.iscoroutinefunction to detect if test methods or callbacks are co-routines. You explicitly opt-in to async behavior using the async marker on things that you want to run on the loop. This will cause problems with using the patch decorator on test methods since they will no not be detected as co-routines. I took this approach primarily to simplify the code and enforce explicitness. Since the implementation is a new sub-class, it cannot break existing code and new code can place the patch inside of the test method instead of decorating the method. I believe that creating an destroying the loop with each test method execution is the safest approach for managing the lifecycle. I view having the loop exist at the class level is an unnecessary optimization. I also ensure that code under test that calls asyncio.get_event_loop or asyncio.get_running_loop will receive the loop by calling asyncio.set_event_loop with the new loop. This came up in PR review with Petter S. The management of the loop is isolated into a property which makes it possible to create custom sub-classes that instantiate 3rd party loops that are asyncio compatible. This is the only concession that my implementation makes to supporting other loop classes. If it is not clear, I believe that a new sub-class of unittest.TestCase is necessary for a clean implementation. It preserves unittest.TestCase so the risk of breaking existing code is minimized and the async functionality is isolated in a new class that is explicitly meant to test async code. This is also necessary if the implementation should exist in the asyncio module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 08:09:21 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Thu, 07 Feb 2019 13:09:21 +0000 Subject: [issue30130] array.array is not an instance of collections.MutableSequence In-Reply-To: <1492786836.55.0.150930236704.issue30130@psf.upfronthosting.co.za> Message-ID: <1549544961.04.0.307897058807.issue30130@roundup.psfhosted.org> Cheryl Sabella added the comment: As Jim mentioned, issue 29727 also discusses registering array.array. See issue 23864, issue 25737, issue 35190, and issue 35349 for discussions about collections.abc in general. Closing this as a duplicate. ---------- nosy: +cheryl.sabella resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> collections.abc.Reversible doesn't fully support the reversing protocol _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 08:22:49 2019 From: report at bugs.python.org (Jason R. Coombs) Date: Thu, 07 Feb 2019 13:22:49 +0000 Subject: [issue24209] Allow IPv6 bind in http.server In-Reply-To: <1431784485.93.0.0140060801451.issue24209@psf.upfronthosting.co.za> Message-ID: <1549545769.5.0.925455295005.issue24209@roundup.psfhosted.org> Jason R. Coombs added the comment: New changeset f289084c83190cc72db4a70c58f007ec62e75247 by Jason R. Coombs in branch 'master': bpo-24209: In http.server script, rely on getaddrinfo to bind to preferred address based on the bind parameter. (#11767) https://github.com/python/cpython/commit/f289084c83190cc72db4a70c58f007ec62e75247 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 08:28:36 2019 From: report at bugs.python.org (Jason R. Coombs) Date: Thu, 07 Feb 2019 13:28:36 +0000 Subject: [issue24209] Allow IPv6 bind in http.server In-Reply-To: <1431784485.93.0.0140060801451.issue24209@psf.upfronthosting.co.za> Message-ID: <1549546116.41.0.475960362286.issue24209@roundup.psfhosted.org> Change by Jason R. Coombs : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 08:32:51 2019 From: report at bugs.python.org (Jason R. Coombs) Date: Thu, 07 Feb 2019 13:32:51 +0000 Subject: [issue17561] Add socket.create_server_sock() convenience function In-Reply-To: <1364402909.97.0.467946240817.issue17561@psf.upfronthosting.co.za> Message-ID: <1549546371.27.0.788856250963.issue17561@roundup.psfhosted.org> Jason R. Coombs added the comment: In issue24209, I ended up settling on this implementation (https://github.com/python/cpython/blob/f289084c83190cc72db4a70c58f007ec62e75247/Lib/http/server.py#L1227-L1234), which seems to work well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 08:57:08 2019 From: report at bugs.python.org (Rohit travels and tours) Date: Thu, 07 Feb 2019 13:57:08 +0000 Subject: [issue35929] rtat.net Message-ID: <1549547827.35.0.165428804268.issue35929@roundup.psfhosted.org> Change by Rohit travels and tours : ---------- assignee: docs at python components: 2to3 (2.x to 3.x conversion tool), Build, Demos and Tools, Distutils, Documentation, Extension Modules, FreeBSD, Library (Lib), SSL, email, macOS nosy: barry, docs at python, dstufft, eric.araujo, koobs, ned.deily, r.david.murray, ronaldoussoren, roufique7 priority: normal severity: normal status: open title: rtat.net type: resource usage versions: Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 09:25:32 2019 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 07 Feb 2019 14:25:32 +0000 Subject: [issue35930] Raising an exception raised in a "future" instance will create reference cycles Message-ID: <1549549530.21.0.398741964575.issue35930@roundup.psfhosted.org> New submission from Jes?s Cea Avi?n : Try this in a terminal: """ import gc import concurrent.futures executor = concurrent.futures.ThreadPoolExecutor(999) def a(): 1/0 future=executor.submit(a) future.result() # An exception is raised here. That is normal gc.set_debug(gc.DEBUG_SAVEALL) gc.collect() gc.garbage """ You will see (python 3.7) that 23 objects are collected when cleaning the cycle. The problem is the attribute "future._exception". If the exception provided by the "future" is raised somewhere else, we will have reference cycles because we have the same exception/traceback in two different places in the traceback framestack. I commonly do this in my code: """ try: future.result() # This will raise an exception if the future did it except Exception: ... some clean up ... raise # Propagate the "future" exception """ This approach will create reference cycles. They will eventually cleaned up, but I noticed this issue because the cycle clean up phase was touching big objects with many references but unused for a long time, so they were living in the SWAP. The cycle collection was hugely slow because of this and the interpreter is completely stopped until done. Not sure about what to do about this. I am currently doing something like: """ try: future.result() # This will raise an exception if the future did it except Exception: if future.done(): del future._exception raise # Propagate the exception """ I am breaking the cycle manually. I do not use "future.set_exception(None) because side effects like notifying waiters. I think this is a bug to be solved. Not sure how to do it cleanly. What do you think? Ideas?. ---------- messages: 335022 nosy: jcea priority: normal severity: normal status: open title: Raising an exception raised in a "future" instance will create reference cycles versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 10:13:11 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Thu, 07 Feb 2019 15:13:11 +0000 Subject: [issue4356] Add "key" argument to "bisect" module functions In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za> Message-ID: <1549552391.25.0.499952165546.issue4356@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- pull_requests: +11764 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 10:13:41 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Thu, 07 Feb 2019 15:13:41 +0000 Subject: [issue4356] Add "key" argument to "bisect" module functions In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za> Message-ID: <1549552421.41.0.0768280728413.issue4356@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- pull_requests: +11764, 11765 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 10:14:13 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Thu, 07 Feb 2019 15:14:13 +0000 Subject: [issue4356] Add "key" argument to "bisect" module functions In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za> Message-ID: <1549552453.19.0.329866254951.issue4356@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- pull_requests: +11764, 11765, 11766 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 10:44:53 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 07 Feb 2019 15:44:53 +0000 Subject: [issue34572] C unpickling bypasses import thread safety In-Reply-To: <1535990001.55.0.56676864532.issue34572@psf.upfronthosting.co.za> Message-ID: <1549554293.72.0.838769487133.issue34572@roundup.psfhosted.org> Antoine Pitrou added the comment: Interesting I could not reproduce here, even by throwing Pandas into the mix and spawning 1024 workers... ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 10:45:29 2019 From: report at bugs.python.org (Mariatta Wijaya) Date: Thu, 07 Feb 2019 15:45:29 +0000 Subject: [issue35929] rtat.net Message-ID: <1549554329.22.0.782118981945.issue35929@roundup.psfhosted.org> New submission from Mariatta Wijaya : Please provide more info about the bug you're reporting. As it is, this looks like spam, so I'm closing it. ---------- assignee: docs at python -> nosy: +Mariatta resolution: -> not a bug stage: -> resolved status: open -> closed type: resource usage -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 10:45:41 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 07 Feb 2019 15:45:41 +0000 Subject: [issue34572] C unpickling bypasses import thread safety In-Reply-To: <1535990001.55.0.56676864532.issue34572@psf.upfronthosting.co.za> Message-ID: <1549554341.31.0.47924368831.issue34572@roundup.psfhosted.org> Change by Antoine Pitrou : ---------- nosy: +brett.cannon, eric.snow, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 10:53:22 2019 From: report at bugs.python.org (Zachary Ware) Date: Thu, 07 Feb 2019 15:53:22 +0000 Subject: [issue35929] Spam In-Reply-To: <1549554329.22.0.782118981945.issue35929@roundup.psfhosted.org> Message-ID: <1549554802.71.0.623340307475.issue35929@roundup.psfhosted.org> Change by Zachary Ware : ---------- components: -2to3 (2.x to 3.x conversion tool), Build, Demos and Tools, Distutils, Documentation, Extension Modules, FreeBSD, Library (Lib), SSL, email, macOS nosy: -Mariatta, barry, docs at python, dstufft, eric.araujo, koobs, ned.deily, r.david.murray, ronaldoussoren, roufique7 title: rtat.net -> Spam versions: -Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 11:02:53 2019 From: report at bugs.python.org (daniel hahler) Date: Thu, 07 Feb 2019 16:02:53 +0000 Subject: [issue35931] pdb: "debug print(" crashes with SyntaxError Message-ID: <1549555371.45.0.73616044825.issue35931@roundup.psfhosted.org> New submission from daniel hahler : `debug print(` will make pdb crash with a SyntaxError: % python -c '__import__("pdb").set_trace()' --Return-- > (1)()->None (Pdb) print( *** SyntaxError: unexpected EOF while parsing (Pdb) debug print( ENTERING RECURSIVE DEBUGGER Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.7/bdb.py", line 92, in trace_dispatch return self.dispatch_return(frame, arg) File "/usr/lib64/python3.7/bdb.py", line 151, in dispatch_return self.user_return(frame, arg) File "/usr/lib64/python3.7/pdb.py", line 293, in user_return self.interaction(frame, None) File "/usr/lib64/python3.7/pdb.py", line 352, in interaction self._cmdloop() File "/usr/lib64/python3.7/pdb.py", line 321, in _cmdloop self.cmdloop() File "/usr/lib64/python3.7/cmd.py", line 138, in cmdloop stop = self.onecmd(line) File "/usr/lib64/python3.7/pdb.py", line 418, in onecmd return cmd.Cmd.onecmd(self, line) File "/usr/lib64/python3.7/cmd.py", line 217, in onecmd return func(arg) File "/usr/lib64/python3.7/pdb.py", line 1099, in do_debug sys.call_tracing(p.run, (arg, globals, locals)) File "/usr/lib64/python3.7/bdb.py", line 582, in run cmd = compile(cmd, "", "exec") File "", line 1 print( ^ SyntaxError: unexpected EOF while parsing ---------- components: Library (Lib) messages: 335025 nosy: blueyed priority: normal severity: normal status: open title: pdb: "debug print(" crashes with SyntaxError versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 11:03:42 2019 From: report at bugs.python.org (daniel hahler) Date: Thu, 07 Feb 2019 16:03:42 +0000 Subject: [issue35931] pdb: "debug print(" crashes with SyntaxError In-Reply-To: <1549555371.45.0.73616044825.issue35931@roundup.psfhosted.org> Message-ID: <1549555422.59.0.579585476637.issue35931@roundup.psfhosted.org> Change by daniel hahler : ---------- keywords: +patch pull_requests: +11767 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 11:03:46 2019 From: report at bugs.python.org (daniel hahler) Date: Thu, 07 Feb 2019 16:03:46 +0000 Subject: [issue35931] pdb: "debug print(" crashes with SyntaxError In-Reply-To: <1549555371.45.0.73616044825.issue35931@roundup.psfhosted.org> Message-ID: <1549555426.39.0.0733871775128.issue35931@roundup.psfhosted.org> Change by daniel hahler : ---------- keywords: +patch, patch pull_requests: +11767, 11768 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 11:28:09 2019 From: report at bugs.python.org (Eric Snow) Date: Thu, 07 Feb 2019 16:28:09 +0000 Subject: [issue28411] Eliminate PyInterpreterState.modules. In-Reply-To: <1476138783.81.0.661524291989.issue28411@psf.upfronthosting.co.za> Message-ID: <1549556889.96.0.0853949290108.issue28411@roundup.psfhosted.org> Change by Eric Snow : ---------- pull_requests: -11713 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 11:28:27 2019 From: report at bugs.python.org (Eric Snow) Date: Thu, 07 Feb 2019 16:28:27 +0000 Subject: [issue28411] Eliminate PyInterpreterState.modules. In-Reply-To: <1476138783.81.0.661524291989.issue28411@psf.upfronthosting.co.za> Message-ID: <1549556907.68.0.644380413948.issue28411@roundup.psfhosted.org> Change by Eric Snow : ---------- pull_requests: -11714 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 11:29:49 2019 From: report at bugs.python.org (Eric Snow) Date: Thu, 07 Feb 2019 16:29:49 +0000 Subject: [issue28411] Eliminate PyInterpreterState.modules. In-Reply-To: <1476138783.81.0.661524291989.issue28411@psf.upfronthosting.co.za> Message-ID: <1549556989.46.0.669873937173.issue28411@roundup.psfhosted.org> Eric Snow added the comment: FTR, gh-9047 (for issue #34572) mentions this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 11:30:33 2019 From: report at bugs.python.org (Eric Snow) Date: Thu, 07 Feb 2019 16:30:33 +0000 Subject: [issue28411] Eliminate PyInterpreterState.modules. In-Reply-To: <1476138783.81.0.661524291989.issue28411@psf.upfronthosting.co.za> Message-ID: <1549557033.83.0.0559747062166.issue28411@roundup.psfhosted.org> Change by Eric Snow : ---------- assignee: -> eric.snow type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 11:39:48 2019 From: report at bugs.python.org (Eric Snow) Date: Thu, 07 Feb 2019 16:39:48 +0000 Subject: [issue34572] C unpickling bypasses import thread safety In-Reply-To: <1535990001.55.0.56676864532.issue34572@psf.upfronthosting.co.za> Message-ID: <1549557588.84.0.36695846072.issue34572@roundup.psfhosted.org> Eric Snow added the comment: Perhaps PyImport_GetModule() should aquire-release the module's lock before the lookup? This would effectively be a call to _lock_unlock_module() in importlib._bootstrap. The alternative is to encourage using PyImport_Import() instead, like the PR has done. In the case the docs for PyImport_GetModule() should make it clear that it is guaranteed that the module is fully imported yet (and recommend using PyImport_Import() for the guarantee). Either way there should be a new issue for the more general change (and it should reference this issue). ---------- type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 12:20:36 2019 From: report at bugs.python.org (Ethan Furman) Date: Thu, 07 Feb 2019 17:20:36 +0000 Subject: [issue35899] '_is_sunder' function in 'enum' module fails on empty string In-Reply-To: <1549376859.01.0.998806898699.issue35899@roundup.psfhosted.org> Message-ID: <1549560036.54.0.0264328949836.issue35899@roundup.psfhosted.org> Ethan Furman added the comment: Yes, the first solution will be fine. Maxwell, can you create a github pull request with that? ---------- keywords: +easy stage: -> needs patch type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 12:33:29 2019 From: report at bugs.python.org (Sateesh Kumar) Date: Thu, 07 Feb 2019 17:33:29 +0000 Subject: [issue35932] Interpreter gets stuck while applying a compiled regex pattern Message-ID: <1549560807.38.0.703809508219.issue35932@roundup.psfhosted.org> New submission from Sateesh Kumar : The python interpreter gets stuck while applying a compiled regex pattern against a given string. The regex matching doesn't get stuck if uncompiled regex pattern is used, or if the flag "re.IGNORECASE" is not used for regex match. Below code snippets gives more details. * Variant-1 # Python process gets stuck ~/workbench$ cat match.py import re pattern = "^[_a-z0-9-]+([\.'_a-z0-9-]+)*@[a-z0-9]+([\.a-z0-9-]+)*(\.[a-z]{2,4})$" compiled_pattern = re.compile(pattern, re.IGNORECASE) val = "Z230-B900_X-Suite_Migration_Shared_Volume" re.match(compiled_pattern, val) ~/workbench$ python match.py ^^^ The interpreter gets stuck. * Variant-2 (Using uncompiled pattern) # python interpreter doesn't get stuck ~/workbench$ cat match.py import re pattern = "^[_a-z0-9-]+([\.'_a-z0-9-]+)*@[a-z0-9]+([\.a-z0-9-]+)*(\.[a-z]{2,4})$" compiled_pattern = re.compile(pattern, re.IGNORECASE) val = "Z230-B900_X-Suite_Migration_Shared_Volume" re.match(pattern, val) * Variant-3 (Using compiled pattern, but without flag re.IGNORECASE) # Python interpreter doesn't get stuck ~/workbench$ cat match.py import re pattern = "^[_a-z0-9-]+([\.'_a-z0-9-]+)*@[a-z0-9]+([\.a-z0-9-]+)*(\.[a-z]{2,4})$" compiled_pattern = re.compile(pattern) val = "Z230-B900_X-Suite_Migration_Shared_Volume" re.match(compiled_pattern, val) # Platform details ~/workbench$ python -V Python 2.7.12 ~/workbench$ uname -a Linux ubuntu16-template 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux Though above details are from Python/2.7 I see similar beahviour with Python/3.5.2 too. ---------- files: gdb_trace messages: 335029 nosy: Sateesh Kumar priority: normal severity: normal status: open title: Interpreter gets stuck while applying a compiled regex pattern type: crash versions: Python 2.7 Added file: https://bugs.python.org/file48110/gdb_trace _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 12:52:31 2019 From: report at bugs.python.org (Neil Schemenauer) Date: Thu, 07 Feb 2019 17:52:31 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1549561951.36.0.982090985835.issue35813@roundup.psfhosted.org> Neil Schemenauer added the comment: I didn't finish reviewing completely yet but here are some comments. I think the random filename generation can be pulled out of _posixshmem. Make it require that a filename is passed into it. That moves a fair bit of complexity out of C and into Python. In the Python module, I suggest that you could use secrets.token_hex() to build the filename. Put the loop that retries because of name collisions in the Python module as well. If you like, I can try to make a patch that does the above. When looking at at how the Python code would handle a name collision, I see this code: + switch (errno) { + case EACCES: + PyErr_Format(pPermissionsException, + "No permission to %s this segment", + (flags & O_TRUNC) ? "truncate" : "access" + ); + break; + + case EEXIST: + PyErr_SetString(pExistentialException, + "Shared memory with the specified name already exists"); + break; + + case ENOENT: + PyErr_SetString(pExistentialException, + "No shared memory exists with the specified name"); + break; + + case EINVAL: + PyErr_SetString(PyExc_ValueError, "Invalid parameter(s)"); + break; + + case EMFILE: + PyErr_SetString(PyExc_OSError, + "This process already has the maximum number of files open"); + break; + + case ENFILE: + PyErr_SetString(PyExc_OSError, + "The system limit on the total number of open files has been reached"); + break; + + case ENAMETOOLONG: + PyErr_SetString(PyExc_ValueError, + "The name is too long"); + break; + + default: + PyErr_SetFromErrno(PyExc_OSError); + break; + } I think it might be cleaner just to make it: PyErr_SetFromErrno(PyExc_OSError); Then, if you need a customized exception or message, you can re-raise inside the Python code. To me, it seems simpler and more direct to just preserve the errno and always raise OSError. Changing things to ValueError means that callers need to look at the message text to differentiate between some errno values. Is it the case that _posixshmem started life as a module that would be used directly and not something hidden by another layer of abstraction? If so, having these customized exceptions and having it do the filename generation itself makes sense. However, it is an internal implementation detail of shared_memory.py, I think it should be simplified to do only what is needed. E.g. a thin layer of the system calls. ---------- nosy: +nascheme _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 12:55:23 2019 From: report at bugs.python.org (Pierre Glaser) Date: Thu, 07 Feb 2019 17:55:23 +0000 Subject: [issue35933] python doc does not say that the state kwarg in Pickler.save_reduce can be a tuple (and not only a dict) Message-ID: <1549562122.06.0.315178283617.issue35933@roundup.psfhosted.org> New submission from Pierre Glaser : Hello all, This 16-year old commit (*) allows an object's state to be updated using its slots instead of its __dict__ at unpickling time. To use this functionality, the state keyword-argument of Pickler.save_reduce (which maps to the third item of the tuple returned by __reduce__) should be a length-2 tuple. As far as I can tell, this is not mentioned in the documentation (**). I suggest having the docs updated. What do you think? (*) https://github.com/python/cpython/commit/ac5b5d2e8b849c499d323b0263ace22e56b4f0d9 (**) https://docs.python.org/3.8/library/pickle.html#object.__reduce__ ---------- assignee: docs at python components: Documentation messages: 335031 nosy: alexandre.vassalotti, docs at python, pierreglaser, pitrou, serhiy.storchaka priority: normal severity: normal status: open title: python doc does not say that the state kwarg in Pickler.save_reduce can be a tuple (and not only a dict) versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 12:56:33 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Thu, 07 Feb 2019 17:56:33 +0000 Subject: [issue35932] Interpreter gets stuck while applying a compiled regex pattern In-Reply-To: <1549560807.38.0.703809508219.issue35932@roundup.psfhosted.org> Message-ID: <1549562193.0.0.265183707226.issue35932@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 13:02:22 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 07 Feb 2019 18:02:22 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1549562542.41.0.797565850226.issue35813@roundup.psfhosted.org> Antoine Pitrou added the comment: (also, OSError will automatically convert to more specific subclasses for some errnos, see PEP 3151: >>> raise OSError(errno.ENOENT, "foobar") Traceback (most recent call last): File "", line 1, in raise OSError(errno.ENOENT, "foobar") FileNotFoundError: [Errno 2] foobar ) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 13:18:55 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 07 Feb 2019 18:18:55 +0000 Subject: [issue35933] python doc does not say that the state kwarg in Pickler.save_reduce can be a tuple (and not only a dict) In-Reply-To: <1549562122.06.0.315178283617.issue35933@roundup.psfhosted.org> Message-ID: <1549563535.6.0.33345276465.issue35933@roundup.psfhosted.org> Antoine Pitrou added the comment: Does it still work? With both the C and Python pickler? Can you post an example? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 14:15:04 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 07 Feb 2019 19:15:04 +0000 Subject: [issue35934] Add socket.bind_socket() utility function Message-ID: <1549566902.79.0.677687282333.issue35934@roundup.psfhosted.org> New submission from Giampaolo Rodola' : The main point of this patch is to automatize all the necessary tasks which are usually involved when creating a server socket, amongst which: * determining the right family based on address, similarly to socket.create_connection() * whether to use SO_REUSEADDR depending on the platform * set AI_PASSIVE flag for getaddrinfo() * set a more optimal default backlog This is somewhat related to issue17561 which I prefer to leave pending for now (need to think about it more carefully). issue17561 is complementary to this one so it appears it can be integrated later (or never) without altering the base functionality implemented in here. ---------- components: Library (Lib) messages: 335034 nosy: asvetlov, cheryl.sabella, giampaolo.rodola, jaraco, josiah.carlson, loewis, neologix, pitrou priority: normal severity: normal stage: patch review status: open title: Add socket.bind_socket() utility function versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 14:17:10 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 07 Feb 2019 19:17:10 +0000 Subject: [issue35934] Add socket.bind_socket() utility function In-Reply-To: <1549566902.79.0.677687282333.issue35934@roundup.psfhosted.org> Message-ID: <1549567030.22.0.479348685638.issue35934@roundup.psfhosted.org> Change by Giampaolo Rodola' : ---------- keywords: +patch pull_requests: +11769 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 14:17:25 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 07 Feb 2019 19:17:25 +0000 Subject: [issue35934] Add socket.bind_socket() utility function In-Reply-To: <1549566902.79.0.677687282333.issue35934@roundup.psfhosted.org> Message-ID: <1549567045.18.0.844599469932.issue35934@roundup.psfhosted.org> Change by Giampaolo Rodola' : ---------- keywords: +patch, patch pull_requests: +11769, 11770 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 14:17:38 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 07 Feb 2019 19:17:38 +0000 Subject: [issue35934] Add socket.bind_socket() utility function In-Reply-To: <1549566902.79.0.677687282333.issue35934@roundup.psfhosted.org> Message-ID: <1549567058.95.0.727097673358.issue35934@roundup.psfhosted.org> Change by Giampaolo Rodola' : ---------- keywords: +patch, patch, patch pull_requests: +11769, 11770, 11771 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 14:22:13 2019 From: report at bugs.python.org (SilentGhost) Date: Thu, 07 Feb 2019 19:22:13 +0000 Subject: [issue35932] Interpreter gets stuck while applying a compiled regex pattern In-Reply-To: <1549560807.38.0.703809508219.issue35932@roundup.psfhosted.org> Message-ID: <1549567333.58.0.117556524328.issue35932@roundup.psfhosted.org> SilentGhost added the comment: In your variant 2 you're not using re.IGNORECASE flag, if you do you're likely to encounter the same behaviour as for the compiled pattern. At least I do on python3.6 ---------- components: +Regular Expressions nosy: +SilentGhost, ezio.melotti, mrabarnett type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 14:24:06 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 07 Feb 2019 19:24:06 +0000 Subject: [issue17561] Add socket.create_server_sock() convenience function In-Reply-To: <1364402909.97.0.467946240817.issue17561@psf.upfronthosting.co.za> Message-ID: <1549567446.52.0.0762038124412.issue17561@roundup.psfhosted.org> Giampaolo Rodola' added the comment: After careful thinking I realize I'm not completely sure about how to expose the IPv4/6 functionality yet. I prefer to defer it for later and start landing a bind_socket() utility function which serves as a base for this functionality. See: issue17561. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 14:36:58 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 07 Feb 2019 19:36:58 +0000 Subject: [issue35911] add a cell construtor, and expose the cell type in Lib/types.py In-Reply-To: <1549450547.33.0.317079200708.issue35911@roundup.psfhosted.org> Message-ID: <1549568218.32.0.197325872855.issue35911@roundup.psfhosted.org> Antoine Pitrou added the comment: New changeset df8d2cde63c865446468351f8f648e1c7bd45109 by Antoine Pitrou (Pierre Glaser) in branch 'master': bpo-35911: add cell constructor (GH-11771) https://github.com/python/cpython/commit/df8d2cde63c865446468351f8f648e1c7bd45109 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 14:37:16 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 07 Feb 2019 19:37:16 +0000 Subject: [issue35911] add a cell construtor, and expose the cell type in Lib/types.py In-Reply-To: <1549450547.33.0.317079200708.issue35911@roundup.psfhosted.org> Message-ID: <1549568236.14.0.211539743539.issue35911@roundup.psfhosted.org> Change by Antoine Pitrou : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 14:52:03 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 07 Feb 2019 19:52:03 +0000 Subject: [issue35615] "RuntimeError: Dictionary changed size during iteration" when copying a WeakValueDictionary In-Reply-To: <1546116337.91.0.423915840639.issue35615@roundup.psfhosted.org> Message-ID: <1549569123.95.0.508671158529.issue35615@roundup.psfhosted.org> Antoine Pitrou added the comment: New changeset 96d37dbcd23e65a7a57819aeced9034296ef747e by Antoine Pitrou (Fish) in branch 'master': bpo-35615: Fix crashes when copying a Weak{Key,Value}Dictionary. (GH-11384) https://github.com/python/cpython/commit/96d37dbcd23e65a7a57819aeced9034296ef747e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 14:52:36 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 07 Feb 2019 19:52:36 +0000 Subject: [issue35615] "RuntimeError: Dictionary changed size during iteration" when copying a WeakValueDictionary In-Reply-To: <1546116337.91.0.423915840639.issue35615@roundup.psfhosted.org> Message-ID: <1549569156.17.0.521747707006.issue35615@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11773 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 14:52:43 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 07 Feb 2019 19:52:43 +0000 Subject: [issue35615] "RuntimeError: Dictionary changed size during iteration" when copying a WeakValueDictionary In-Reply-To: <1546116337.91.0.423915840639.issue35615@roundup.psfhosted.org> Message-ID: <1549569163.88.0.00278346376773.issue35615@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11773, 11774 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 14:52:51 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 07 Feb 2019 19:52:51 +0000 Subject: [issue35615] "RuntimeError: Dictionary changed size during iteration" when copying a WeakValueDictionary In-Reply-To: <1546116337.91.0.423915840639.issue35615@roundup.psfhosted.org> Message-ID: <1549569171.17.0.114309158307.issue35615@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11773, 11774, 11775 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 15:09:19 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 07 Feb 2019 20:09:19 +0000 Subject: [issue35615] "RuntimeError: Dictionary changed size during iteration" when copying a WeakValueDictionary In-Reply-To: <1546116337.91.0.423915840639.issue35615@roundup.psfhosted.org> Message-ID: <1549570159.29.0.702290534364.issue35615@roundup.psfhosted.org> Antoine Pitrou added the comment: New changeset 48769a28ad6ef4183508951fa6a378531ace26a4 by Antoine Pitrou (Miss Islington (bot)) in branch '3.7': bpo-35615: Fix crashes when copying a Weak{Key,Value}Dictionary. (GH-11384) (GH-11785) https://github.com/python/cpython/commit/48769a28ad6ef4183508951fa6a378531ace26a4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 15:09:29 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 07 Feb 2019 20:09:29 +0000 Subject: [issue35615] "RuntimeError: Dictionary changed size during iteration" when copying a WeakValueDictionary In-Reply-To: <1546116337.91.0.423915840639.issue35615@roundup.psfhosted.org> Message-ID: <1549570159.29.0.702290534364.issue35615@roundup.psfhosted.org> Antoine Pitrou added the comment: New changeset 48769a28ad6ef4183508951fa6a378531ace26a4 by Antoine Pitrou (Miss Islington (bot)) in branch '3.7': bpo-35615: Fix crashes when copying a Weak{Key,Value}Dictionary. (GH-11384) (GH-11785) https://github.com/python/cpython/commit/48769a28ad6ef4183508951fa6a378531ace26a4 ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 15:19:53 2019 From: report at bugs.python.org (Eryk Sun) Date: Thu, 07 Feb 2019 20:19:53 +0000 Subject: [issue14094] ntpath.realpath() should use GetFinalPathNameByHandle() In-Reply-To: <1329954470.08.0.180096078595.issue14094@psf.upfronthosting.co.za> Message-ID: <1549570793.17.0.940080696403.issue14094@roundup.psfhosted.org> Change by Eryk Sun : ---------- components: -Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 15:20:32 2019 From: report at bugs.python.org (Eryk Sun) Date: Thu, 07 Feb 2019 20:20:32 +0000 Subject: [issue14094] ntpath.realpath() should use GetFinalPathNameByHandle() In-Reply-To: <1329954470.08.0.180096078595.issue14094@psf.upfronthosting.co.za> Message-ID: <1549570832.31.0.9365861868.issue14094@roundup.psfhosted.org> Change by Eryk Sun : ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 15:33:37 2019 From: report at bugs.python.org (Eryk Sun) Date: Thu, 07 Feb 2019 20:33:37 +0000 Subject: [issue14094] ntpath.realpath() should use GetFinalPathNameByHandle() In-Reply-To: <1329954470.08.0.180096078595.issue14094@psf.upfronthosting.co.za> Message-ID: <1549571617.7.0.799538548102.issue14094@roundup.psfhosted.org> Eryk Sun added the comment: Ping on PR 11248. It would be nice to get this into 3.8. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 15:59:04 2019 From: report at bugs.python.org (Pierre Glaser) Date: Thu, 07 Feb 2019 20:59:04 +0000 Subject: [issue35933] python doc does not say that the state kwarg in Pickler.save_reduce can be a tuple (and not only a dict) In-Reply-To: <1549562122.06.0.315178283617.issue35933@roundup.psfhosted.org> Message-ID: <1549573144.13.0.200174121083.issue35933@roundup.psfhosted.org> Pierre Glaser added the comment: It turns out that both pickle and _pickle implement this feature, but the behavior is inconsistent. - As a reminder, instances of slotted classes do not have a dict attribute (1) - On the other side, when pickling slotted class instances, __getstate__ can return a tuple of 2 dicts. The first dict represents the __dict__ attribute. Because of (1), this first dict should simply be a sentinel value. In pickle, the condition is that it evaluates to False, but in _pickle, it should be explicitly None. (- Finally, The second dict in state contains the slotted attribute. ) Here are the lines in the two files causing the inconsistent behavior: https://github.com/python/cpython/blob/master/Modules/_pickle.c#L6236 https://github.com/python/cpython/blob/master/Lib/pickle.py#L1549 I included an example that illustrates it. ---------- Added file: https://bugs.python.org/file48111/test_slots.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 16:00:28 2019 From: report at bugs.python.org (Pierre Glaser) Date: Thu, 07 Feb 2019 21:00:28 +0000 Subject: [issue35933] python doc does not say that the state kwarg in Pickler.save_reduce can be a tuple (and not only a dict) In-Reply-To: <1549562122.06.0.315178283617.issue35933@roundup.psfhosted.org> Message-ID: <1549573228.31.0.106284460465.issue35933@roundup.psfhosted.org> Change by Pierre Glaser : Removed file: https://bugs.python.org/file48111/test_slots.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 16:00:57 2019 From: report at bugs.python.org (Pierre Glaser) Date: Thu, 07 Feb 2019 21:00:57 +0000 Subject: [issue35933] python doc does not say that the state kwarg in Pickler.save_reduce can be a tuple (and not only a dict) In-Reply-To: <1549562122.06.0.315178283617.issue35933@roundup.psfhosted.org> Message-ID: <1549573257.69.0.725207353871.issue35933@roundup.psfhosted.org> Change by Pierre Glaser : Added file: https://bugs.python.org/file48112/test_slots.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 16:01:38 2019 From: report at bugs.python.org (Pierre Glaser) Date: Thu, 07 Feb 2019 21:01:38 +0000 Subject: [issue35933] python doc does not say that the state kwarg in Pickler.save_reduce can be a tuple (and not only a dict) In-Reply-To: <1549562122.06.0.315178283617.issue35933@roundup.psfhosted.org> Message-ID: <1549573298.45.0.0339712924536.issue35933@roundup.psfhosted.org> Change by Pierre Glaser : Removed file: https://bugs.python.org/file48112/test_slots.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 16:01:59 2019 From: report at bugs.python.org (Pierre Glaser) Date: Thu, 07 Feb 2019 21:01:59 +0000 Subject: [issue35933] python doc does not say that the state kwarg in Pickler.save_reduce can be a tuple (and not only a dict) In-Reply-To: <1549562122.06.0.315178283617.issue35933@roundup.psfhosted.org> Message-ID: <1549573319.96.0.14656458978.issue35933@roundup.psfhosted.org> Change by Pierre Glaser : Added file: https://bugs.python.org/file48113/test_slots.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 17:08:46 2019 From: report at bugs.python.org (Steve Dower) Date: Thu, 07 Feb 2019 22:08:46 +0000 Subject: [issue14094] ntpath.realpath() should use GetFinalPathNameByHandle() In-Reply-To: <1329954470.08.0.180096078595.issue14094@psf.upfronthosting.co.za> Message-ID: <1549577326.26.0.652853986756.issue14094@roundup.psfhosted.org> Steve Dower added the comment: Posted a review. I suggest a few changes for the sake of tidying up, but I agree that I'd like to see more tests added. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 17:21:34 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 07 Feb 2019 22:21:34 +0000 Subject: [issue35933] python doc does not say that the state kwarg in Pickler.save_reduce can be a tuple (and not only a dict) In-Reply-To: <1549562122.06.0.315178283617.issue35933@roundup.psfhosted.org> Message-ID: <1549578094.63.0.0378848598051.issue35933@roundup.psfhosted.org> Antoine Pitrou added the comment: You can have both a dict and slots by subclassing: >>> class A: ...: __slots__ = ('x',) ...: >>> class B(A): pass >>> >>> b = B() >>> b.x = 5 >>> b.y = 6 >>> b.__dict__ {'y': 6} >>> A.x >>> A.x.__get__(b) 5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 17:23:56 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 07 Feb 2019 22:23:56 +0000 Subject: [issue35933] python doc does not say that the state kwarg in Pickler.save_reduce can be a tuple (and not only a dict) In-Reply-To: <1549562122.06.0.315178283617.issue35933@roundup.psfhosted.org> Message-ID: <1549578236.37.0.0290751439768.issue35933@roundup.psfhosted.org> Raymond Hettinger added the comment: Interestingly, you can also put an instance dict in slots: >>> class A: __slots__ = ['x', '__dict__'] >>> a = A() >>> a.x = 5 >>> a.y = 6 >>> a.__dict__ {'y': 6} >>> a.x 5 ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 17:34:48 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Thu, 07 Feb 2019 22:34:48 +0000 Subject: [issue35904] Add statistics.fmean(seq) In-Reply-To: <1549411161.36.0.783593325223.issue35904@roundup.psfhosted.org> Message-ID: <20190207223441.GH1834@ando.pearwood.info> Steven D'Aprano added the comment: > def fmean(seq: Sequence[float]) -> float: > return math.fsum(seq) / len(seq) Is it intentional that this doesn't support iterators? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 17:44:14 2019 From: report at bugs.python.org (Sateesh Kumar) Date: Thu, 07 Feb 2019 22:44:14 +0000 Subject: [issue35932] Interpreter gets stuck while applying a regex pattern In-Reply-To: <1549560807.38.0.703809508219.issue35932@roundup.psfhosted.org> Message-ID: <1549579454.95.0.686425483694.issue35932@roundup.psfhosted.org> Sateesh Kumar added the comment: @SilentGhost, You are right, when I pass the flag "re.IGNORECASE" for example in Variant-2 the python process do gets stuck. Here is the revised code for Variant-2: * Variant-2 %cat match.py import re pattern = "^[_a-z0-9-]+([\.'_a-z0-9-]+)*@[a-z0-9]+([\.a-z0-9-]+)*(\.[a-z]{2,4})$" val = "Z230-B900_X-Suite_Migration_Shared_Volume" re.match(pattern, val, re.IGNORECASE) ~/workbench$ python match.py ^^^ The interpreter gets stuck. Thanks for the correction. I have also modified the title of this issue accordingly. ---------- title: Interpreter gets stuck while applying a compiled regex pattern -> Interpreter gets stuck while applying a regex pattern _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 18:30:30 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 07 Feb 2019 23:30:30 +0000 Subject: [issue35925] test_httplib test_nntplib test_ssl fail on ARMv7 buster/sid buildbots In-Reply-To: <1549503926.32.0.191493141556.issue35925@roundup.psfhosted.org> Message-ID: <1549582230.01.0.874575191145.issue35925@roundup.psfhosted.org> Gregory P. Smith added the comment: I had emailed Christian around the same time you filed this. """ The problem likely not related to your hardware. I guess it's caused by tightened crypto polices. OpenSSL 1.1.1 has disabled some weak crypto. Some platforms like Debian and RHEL require even larger key sizes or have disable some algorithms. Does the test also fail with the env var OPENSSL_CONF set to a non-existing path? """ - christian.heimes testing that theory... setting OPENSSL_CONF=/invalid-path does indeed "fix" (work around) the failures. Presumably by relaxing the default system constraints. I could have that env var set for this buildbot and eliminate the failure. But do we _want_ to do that? Anyone who compiles CPython and tries to run the test suite on a modern system with such an OpenSSL configuration is going to see similar failures and likely come to us first asking about them. It seems like we'd be better off adjusting our test suite to work around the constraints or disable them only for the duration of a test intentionally violating them? ---------- title: test_httplib test_nntplib test_ssl fail on ARMv7 Ubuntu 3.7 and ARMv7 Ubuntu 3.x buildbots -> test_httplib test_nntplib test_ssl fail on ARMv7 buster/sid buildbots _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 18:32:56 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 07 Feb 2019 23:32:56 +0000 Subject: [issue35925] test_httplib test_nntplib test_ssl fail on ARMv7 Debian buster buildbot In-Reply-To: <1549503926.32.0.191493141556.issue35925@roundup.psfhosted.org> Message-ID: <1549582376.46.0.035963213282.issue35925@roundup.psfhosted.org> Change by Gregory P. Smith : ---------- title: test_httplib test_nntplib test_ssl fail on ARMv7 buster/sid buildbots -> test_httplib test_nntplib test_ssl fail on ARMv7 Debian buster buildbot _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 19:10:58 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 08 Feb 2019 00:10:58 +0000 Subject: [issue35904] Add statistics.fmean(seq) In-Reply-To: <1549411161.36.0.783593325223.issue35904@roundup.psfhosted.org> Message-ID: <1549584658.38.0.853557916562.issue35904@roundup.psfhosted.org> Raymond Hettinger added the comment: >> def fmean(seq: Sequence[float]) -> float: >> return math.fsum(seq) / len(seq) > > Is it intentional that this doesn't support iterators? Since we need both the sum and the length, this seemed like a good starting point. Also, the existing mean() function already covers the more general cases. I suspect that it is common to keep the data in memory so that more than one descriptive statistic can be generated: data = load_measurements() data.sort() n = len(data) mu = fastmean(data) sigma = stdev(data, xbar=mu) low, q1, q2, q3, high = data[0], data[n//4], data[n//2], data[3*n//4], data[-1] popular = mode(data, first_tie=True) It's possible (though possibly not desirable) to provide an fallback path: def fastmean(data: Iterable) -> float: try: return fsum(data) / len(data) except TypeError: # Slow alternative return float(mean(data)) # Memory intensive alternative data = list(data) return fsum(data) / len(data) # Less accurate alternative total = n = 0 for n, x in enumerate(data, start=1): total += x return total / n ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 19:16:15 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 08 Feb 2019 00:16:15 +0000 Subject: [issue35904] Add statistics.fastmean(seq) In-Reply-To: <1549411161.36.0.783593325223.issue35904@roundup.psfhosted.org> Message-ID: <1549584975.18.0.851539148888.issue35904@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- title: Add statistics.fmean(seq) -> Add statistics.fastmean(seq) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 19:40:47 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Fri, 08 Feb 2019 00:40:47 +0000 Subject: [issue35931] pdb: "debug print(" crashes with SyntaxError In-Reply-To: <1549555371.45.0.73616044825.issue35931@roundup.psfhosted.org> Message-ID: <1549586447.15.0.688572614888.issue35931@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 19:44:12 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Fri, 08 Feb 2019 00:44:12 +0000 Subject: [issue4356] Add "key" argument to "bisect" module functions In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za> Message-ID: <1549586652.15.0.792967920498.issue4356@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- nosy: +remi.lapeyre versions: +Python 3.8 -Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 20:12:59 2019 From: report at bugs.python.org (Chris Billington) Date: Fri, 08 Feb 2019 01:12:59 +0000 Subject: [issue35935] threading.Event().wait() not interruptable with Ctrl-C on Windows Message-ID: <1549588377.49.0.765820535798.issue35935@roundup.psfhosted.org> New submission from Chris Billington : I'm experiencing that the following short program: import threading event = threading.Event() event.wait() Cannot be interrupted with Ctrl-C on Python 2.7.15 or 3.7.1 on Windows 10 (using the Anaconda Python distribution). However, if the wait is given a timeout: import threading event = threading.Event() while True: if event.wait(10000): break then this is interruptable on Python 2.7.15, but is still uninterruptible on Python 3.7.1. ---------- components: Windows messages: 335049 nosy: Chris Billington, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: threading.Event().wait() not interruptable with Ctrl-C on Windows type: behavior versions: Python 2.7, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 20:16:47 2019 From: report at bugs.python.org (Chris Billington) Date: Fri, 08 Feb 2019 01:16:47 +0000 Subject: [issue35935] threading.Event().wait() not interruptable with Ctrl-C on Windows In-Reply-To: <1549588377.49.0.765820535798.issue35935@roundup.psfhosted.org> Message-ID: <1549588607.52.0.929020551249.issue35935@roundup.psfhosted.org> Chris Billington added the comment: If I add: import signal signal.signal(signal.SIGINT, signal.SIG_DFL) before the wait() call, then the call is interruptible on both Python versions without needing to add a timeout. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 20:34:16 2019 From: report at bugs.python.org (Dong-hee Na) Date: Fri, 08 Feb 2019 01:34:16 +0000 Subject: [issue35899] '_is_sunder' function in 'enum' module fails on empty string In-Reply-To: <1549376859.01.0.998806898699.issue35899@roundup.psfhosted.org> Message-ID: <1549589656.68.0.44328140269.issue35899@roundup.psfhosted.org> Change by Dong-hee Na : ---------- nosy: +corona10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 20:43:20 2019 From: report at bugs.python.org (Dong-hee Na) Date: Fri, 08 Feb 2019 01:43:20 +0000 Subject: [issue12317] inspect.getabsfile() is not documented In-Reply-To: <1308351508.86.0.88677303291.issue12317@psf.upfronthosting.co.za> Message-ID: <1549590200.87.0.763340522282.issue12317@roundup.psfhosted.org> Dong-hee Na added the comment: @pitrou Hi, Can I work on this issue? ---------- nosy: +corona10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 20:48:02 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Fri, 08 Feb 2019 01:48:02 +0000 Subject: [issue12317] inspect.getabsfile() is not documented In-Reply-To: <1308351508.86.0.88677303291.issue12317@psf.upfronthosting.co.za> Message-ID: <1549590482.03.0.587895686733.issue12317@roundup.psfhosted.org> R?mi Lapeyre added the comment: Hi @corona10, Antoine's message is from 2013 and inspect.getabsfile() is still not documented, I think it's safe to say he's not working on it. You can work on the issue and open a new PR on GitHub when you think it is ready for review :) ---------- nosy: +remi.lapeyre versions: +Python 3.6, Python 3.7, Python 3.8 -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 21:17:30 2019 From: report at bugs.python.org (Tim Peters) Date: Fri, 08 Feb 2019 02:17:30 +0000 Subject: [issue35932] Interpreter gets stuck while applying a regex pattern In-Reply-To: <1549560807.38.0.703809508219.issue35932@roundup.psfhosted.org> Message-ID: <1549592250.52.0.205368765361.issue35932@roundup.psfhosted.org> Tim Peters added the comment: Without re.IGNORECASE, the leading ^[_a-z0-9-]+ can't even match the first character (`val` starts with uppercase Z), so it fails instantly. With re.IGNORECASE, it's not "stuck", but is taking a verrrrrry long time to try an enormous number of (ultimately doomed) possibilities due to the way the regexp is written. This is due to using nested quantifiers for no apparent reason. For any character class C, (C+)* matches the same set of strings as C* but the former way can _try_ to match in an exponential (in the length of the string) number of ways. So replace ([\.'_a-z0-9-]+)* and ([\.a-z0-9-]+)* with [\.'_a-z0-9-]* and [\.a-z0-9-]* and it fails to match `val` quickly (even with re.IGNORECASE). For more on this (which applies to many regexp implementations, not just Python's), here's a start: https://www.mathworks.com/matlabcentral/answers/95953-why-can-nested-quantifiers-in-regexp-can-cause-inefficient-failures-in-matlab-6-5-r13 The "Mastering Regular Expressions" book referenced in that answer is an excellent book-length treatment of this (and related) topic(s). ---------- nosy: +tim.peters resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 22:13:20 2019 From: report at bugs.python.org (Brandt Bucher) Date: Fri, 08 Feb 2019 03:13:20 +0000 Subject: [issue35936] Give modulefinder some much-needed updates. Message-ID: <1549595598.95.0.389205049029.issue35936@roundup.psfhosted.org> Change by Brandt Bucher : ---------- components: Library (Lib) nosy: brandtbucher priority: normal severity: normal status: open title: Give modulefinder some much-needed updates. type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 22:15:36 2019 From: report at bugs.python.org (Dong-hee Na) Date: Fri, 08 Feb 2019 03:15:36 +0000 Subject: [issue12317] inspect.getabsfile() is not documented In-Reply-To: <1308351508.86.0.88677303291.issue12317@psf.upfronthosting.co.za> Message-ID: <1549595736.03.0.54018903772.issue12317@roundup.psfhosted.org> Change by Dong-hee Na : ---------- keywords: +patch pull_requests: +11776 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 22:15:50 2019 From: report at bugs.python.org (Dong-hee Na) Date: Fri, 08 Feb 2019 03:15:50 +0000 Subject: [issue12317] inspect.getabsfile() is not documented In-Reply-To: <1308351508.86.0.88677303291.issue12317@psf.upfronthosting.co.za> Message-ID: <1549595750.92.0.718779568556.issue12317@roundup.psfhosted.org> Change by Dong-hee Na : ---------- keywords: +patch, patch pull_requests: +11776, 11777 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 22:16:04 2019 From: report at bugs.python.org (Dong-hee Na) Date: Fri, 08 Feb 2019 03:16:04 +0000 Subject: [issue12317] inspect.getabsfile() is not documented In-Reply-To: <1308351508.86.0.88677303291.issue12317@psf.upfronthosting.co.za> Message-ID: <1549595764.27.0.634052766269.issue12317@roundup.psfhosted.org> Change by Dong-hee Na : ---------- keywords: +patch, patch, patch pull_requests: +11776, 11777, 11778 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 22:20:39 2019 From: report at bugs.python.org (Brandt Bucher) Date: Fri, 08 Feb 2019 03:20:39 +0000 Subject: [issue35936] Give modulefinder some much-needed updates. Message-ID: <1549596039.09.0.478412891062.issue35936@roundup.psfhosted.org> New submission from Brandt Bucher : I've written a patch here that includes a few useful fixes. Namely: - It doesn't crash if it encounters a syntax error. (17396) - It doesn't report certain name collisions as bad. (35376) - It doesn't use mutable default arguments in its initializer. - Most importantly, it now uses `importlib` instead of `imp`, which is deprecated. (25160) As a benefit, frozen built-in modules (`zip import`, for example), are now correctly reported. With the exception of these bug fixes, I've been very careful to preserve the original behavior, and have not changed any part of the API. This patch also includes 2 new regression tests. ---------- versions: +Python 3.8 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 22:23:56 2019 From: report at bugs.python.org (Brandt Bucher) Date: Fri, 08 Feb 2019 03:23:56 +0000 Subject: [issue35936] Give modulefinder some much-needed updates. In-Reply-To: <1549596039.09.0.478412891062.issue35936@roundup.psfhosted.org> Message-ID: <1549596236.6.0.0705706823437.issue35936@roundup.psfhosted.org> Change by Brandt Bucher : ---------- keywords: +patch pull_requests: +11779 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 22:23:58 2019 From: report at bugs.python.org (Brandt Bucher) Date: Fri, 08 Feb 2019 03:23:58 +0000 Subject: [issue17396] modulefinder fails if module contains syntax error In-Reply-To: <1363003425.82.0.865184669213.issue17396@psf.upfronthosting.co.za> Message-ID: <1549596238.85.0.948552613242.issue17396@roundup.psfhosted.org> Change by Brandt Bucher : ---------- pull_requests: +11781 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 22:23:58 2019 From: report at bugs.python.org (Brandt Bucher) Date: Fri, 08 Feb 2019 03:23:58 +0000 Subject: [issue35936] Give modulefinder some much-needed updates. In-Reply-To: <1549596039.09.0.478412891062.issue35936@roundup.psfhosted.org> Message-ID: <1549596238.84.0.168472465602.issue35936@roundup.psfhosted.org> Change by Brandt Bucher : ---------- keywords: +patch, patch pull_requests: +11779, 11780 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 22:24:09 2019 From: report at bugs.python.org (Brandt Bucher) Date: Fri, 08 Feb 2019 03:24:09 +0000 Subject: [issue35376] modulefinder skips nested modules with same name as top-level bad module In-Reply-To: <1543762855.5.0.788709270274.issue35376@psf.upfronthosting.co.za> Message-ID: <1549596249.29.0.401030878545.issue35376@roundup.psfhosted.org> Change by Brandt Bucher : ---------- pull_requests: +11785 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 22:24:09 2019 From: report at bugs.python.org (Brandt Bucher) Date: Fri, 08 Feb 2019 03:24:09 +0000 Subject: [issue17396] modulefinder fails if module contains syntax error In-Reply-To: <1363003425.82.0.865184669213.issue17396@psf.upfronthosting.co.za> Message-ID: <1549596249.27.0.652166128814.issue17396@roundup.psfhosted.org> Change by Brandt Bucher : ---------- pull_requests: +11781, 11782 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 22:24:14 2019 From: report at bugs.python.org (Brandt Bucher) Date: Fri, 08 Feb 2019 03:24:14 +0000 Subject: [issue25160] Stop using deprecated imp module; imp should now emit a real DeprecationWarning In-Reply-To: <1442559979.71.0.954965412351.issue25160@psf.upfronthosting.co.za> Message-ID: <1549596254.51.0.901693153023.issue25160@roundup.psfhosted.org> Change by Brandt Bucher : ---------- pull_requests: +11786 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 22:24:20 2019 From: report at bugs.python.org (Brandt Bucher) Date: Fri, 08 Feb 2019 03:24:20 +0000 Subject: [issue17396] modulefinder fails if module contains syntax error In-Reply-To: <1363003425.82.0.865184669213.issue17396@psf.upfronthosting.co.za> Message-ID: <1549596260.5.0.564854682685.issue17396@roundup.psfhosted.org> Change by Brandt Bucher : ---------- pull_requests: +11781, 11782, 11783 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 22:24:25 2019 From: report at bugs.python.org (Brandt Bucher) Date: Fri, 08 Feb 2019 03:24:25 +0000 Subject: [issue20020] "modernize" the modulefinder module In-Reply-To: <1387425925.56.0.593354940747.issue20020@psf.upfronthosting.co.za> Message-ID: <1549596265.73.0.253597491536.issue20020@roundup.psfhosted.org> Change by Brandt Bucher : ---------- keywords: +patch pull_requests: +11788 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 22:24:25 2019 From: report at bugs.python.org (Brandt Bucher) Date: Fri, 08 Feb 2019 03:24:25 +0000 Subject: [issue25160] Stop using deprecated imp module; imp should now emit a real DeprecationWarning In-Reply-To: <1442559979.71.0.954965412351.issue25160@psf.upfronthosting.co.za> Message-ID: <1549596265.71.0.02665356767.issue25160@roundup.psfhosted.org> Change by Brandt Bucher : ---------- pull_requests: +11786, 11787 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 22:24:32 2019 From: report at bugs.python.org (Brandt Bucher) Date: Fri, 08 Feb 2019 03:24:32 +0000 Subject: [issue17396] modulefinder fails if module contains syntax error In-Reply-To: <1363003425.82.0.865184669213.issue17396@psf.upfronthosting.co.za> Message-ID: <1549596272.51.0.20757458822.issue17396@roundup.psfhosted.org> Change by Brandt Bucher : ---------- pull_requests: +11781, 11782, 11783, 11784 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 22:24:33 2019 From: report at bugs.python.org (Brandt Bucher) Date: Fri, 08 Feb 2019 03:24:33 +0000 Subject: [issue20020] "modernize" the modulefinder module In-Reply-To: <1387425925.56.0.593354940747.issue20020@psf.upfronthosting.co.za> Message-ID: <1549596273.04.0.451323388084.issue20020@roundup.psfhosted.org> Change by Brandt Bucher : ---------- keywords: +patch, patch pull_requests: +11788, 11789 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 7 22:55:33 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 08 Feb 2019 03:55:33 +0000 Subject: [issue12317] inspect.getabsfile() is not documented In-Reply-To: <1308351508.86.0.88677303291.issue12317@psf.upfronthosting.co.za> Message-ID: <1549598133.81.0.118926423817.issue12317@roundup.psfhosted.org> Terry J. Reedy added the comment: 3.6 is also on security-fix-only status ---------- versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 00:13:00 2019 From: report at bugs.python.org (Eryk Sun) Date: Fri, 08 Feb 2019 05:13:00 +0000 Subject: [issue35935] threading.Event().wait() not interruptable with Ctrl-C on Windows In-Reply-To: <1549588377.49.0.765820535798.issue35935@roundup.psfhosted.org> Message-ID: <1549602780.77.0.102500044432.issue35935@roundup.psfhosted.org> Eryk Sun added the comment: Python's C signal handler sets a flag and returns, and the signal is eventually handled in the main thread. In Windows, this means the Python SIGINT handler won't be called so long as the main thread is blocked. (In Unix the signal is delivered on the main thread and interrupts most blocking calls.) In Python 3, our C signal handler also signals a SIGINT kernel event object. This gets used in functions such as time.sleep(). However, threading wait and join methods do not support this event. In principle they could, so long as the underlying implementation continues to use kernel semaphore objects, but that may change. There's been pressure to adopt native condition variables instead of using semaphores. When you enable the default handler, that's actually the default console control-event handler. It simply exits via ExitProcess(STATUS_CONTROL_C_EXIT). This works because the console control event is delivered by creating a new thread that starts at a private CtrlRoutine function in kernelbase.dll, so it doesn't matter that the main thread may be blocked. By default SIGBREAK also executes the default handler, so Ctrl+Break almost always works to kill a console process. Shells such as cmd.exe usually ignore it, because it would be annoying if Ctrl+Break also killed the shell and destroyed the console window. Note also that Python's signal architecture cannot support CTRL_CLOSE_EVENT, even though it's also mapped to SIGBREAK. The problem is that our C handler simply sets a flag and returns. For the close event, the session server waits on the control thread for up to 5 seconds and then terminates the process. Thus the C signal handler returning immediately means our process will be killed long before our Python handler gets called. We may need to actually handle the event, such as ensuring that atexit functions are called. Currently the only way to handle closing the console window and cases where the main thread is blocked is to install our own console control handler using ctypes or PyWin32. Usually we do this to ensure a clean, controlled shutdown. Here's what this looks like with ctypes: import ctypes from ctypes import wintypes kernel32 = ctypes.WinDLL('kernel32', use_last_error=True) CTRL_C_EVENT = 0 CTRL_BREAK_EVENT = 1 CTRL_CLOSE_EVENT = 2 HANDLER_ROUTINE = ctypes.WINFUNCTYPE(wintypes.BOOL, wintypes.DWORD) kernel32.SetConsoleCtrlHandler.argtypes = ( HANDLER_ROUTINE, wintypes.BOOL) @HANDLER_ROUTINE def handler(ctrl): if ctrl == CTRL_C_EVENT: handled = do_ctrl_c() elif ctrl == CTRL_BREAK_EVENT: handled = do_ctrl_break() elif ctrl == CTRL_CLOSE_EVENT: handled = do_ctrl_close() else: handled = False # If not handled, call the next handler. return handled if not kernel32.SetConsoleCtrlHandler(handler, True): raise ctypes.WinError(ctypes.get_last_error()) The do_ctrl_* functions could simply be sys.exit(1), which will ensure that atexit handlers get called. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 00:28:53 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Fri, 08 Feb 2019 05:28:53 +0000 Subject: [issue35904] Add statistics.fmean(seq) In-Reply-To: <1549411161.36.0.783593325223.issue35904@roundup.psfhosted.org> Message-ID: <20190208052845.GJ1834@ando.pearwood.info> Steven D'Aprano added the comment: > On my current 3.8 build, this code given an approx 500x speed-up On my system, I only get a 30x speed-up using your timeit code. Using ints instead of random floats, I only get a 9x speed-up. This just goes to show how sensitive these timing results are on platform and hardware. What do you think of this implementation? def floatmean(data:Iterable) -> Float: try: n = len(data) except TypeError: # Handle iterators with no len. n = 0 def count(x): nonlocal n n += 1 return x total = math.fsum(map(count, data)) return total/n else: return math.fsum(data)/n Compared to the "no frills" fsum()/len() version: - I see no visible slowdown on lists of floats; - it handles iterators as well. On my computer, the difference between the sequence path and the iterator path is just a factor of 3.5. How does it compare on other machines? As for the name, I think we have three reasonable candidates: float_mean fast_mean fmean (with or without underscores for the first two). Do people have a preference? ---------- title: Add statistics.fastmean(seq) -> Add statistics.fmean(seq) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 00:36:57 2019 From: report at bugs.python.org (Dan Snider) Date: Fri, 08 Feb 2019 05:36:57 +0000 Subject: [issue35937] Add instancemethod to types.py Message-ID: <1549604215.56.0.840022461634.issue35937@roundup.psfhosted.org> New submission from Dan Snider : Having the ability to add binding behavior to any callable is an incredibly useful feature if one knows how to take advantage of it, but unfortunately, nothing that currently (publicly) exists comes close to filling the gap `instancemethod`s secrecy leaves. There really isn't anything else to say about it because it's simply amazing at what it does, and publicly exposing it has zero drawback that I could possibly imagine. Here's a benchmark I just ran 3.6 (can't check 3.7 but shouldn't be significantly different): if 1: from functools import _lru_cache_wrapper, partial method = type((lambda:0).__get__(0)) for cls in object.__subclasses__(): if cls.__name__ == 'instancemethod': instancemethod = cls break del cls class Object: lrx = _lru_cache_wrapper(id, 0, 0, tuple) imx = instancemethod(id) smx = property(partial(method, id)) fnx = lambda self, f=id: f(self) >>> ob = Object() >>> stex.Compare.load_meth_call('ob', '', None, 'lrx', 'imx', 'smx', 'fnx') ------------------------------------------------------------------------ [*] Trial duration: 0.5 seconds [*] Num trials: 20 [*] Verbose: True [*] Imports: ('ob',) +-------+-----------------------+-------+-------+ +-INDEX +-INSTRUCTION + OPARG-+ STACK-+ +-------------------------------+-------+-------+ |[ 22] FOR_ITER ------------> ( 12) 1| |[ 24] STORE_FAST ----------> ( 2) 0| |[ 26] LOAD_FAST -----------> ( 0) 1| |[ 28] LOAD_ATTR -----------> ( 2) 1| |[ 30] CALL_FUNCTION -------> ( 0) 1| |[ 32] POP_TOP ----- 0| |[ 34] JUMP_ABSOLUTE -------> ( 22) 0| +-------+-------+-----------+---+-------+-------+---+ +-STATEMENT + NANOSEC-+ NUM LOOPS-+ EACH LOOP-+ +---------------+-----------+-----------+-----------+ | "ob.lrx()" -> 10.000(b) 55_902(k) 179(ns) | "ob.imx()" -> 10.000(b) 80_053(k) 125(ns) | "ob.smx()" -> 10.000(b) 48_040(k) 208(ns) | "ob.fnx()" -> 10.000(b) 42_759(k) 234(ns) ---------- components: Library (Lib) messages: 335058 nosy: bup priority: normal severity: normal status: open title: Add instancemethod to types.py type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 00:44:01 2019 From: report at bugs.python.org (paul j3) Date: Fri, 08 Feb 2019 05:44:01 +0000 Subject: [issue35533] argparse standard error usage for exit / error In-Reply-To: <1545220030.92.0.788709270274.issue35533@psf.upfronthosting.co.za> Message-ID: <1549604641.66.0.083032739241.issue35533@roundup.psfhosted.org> paul j3 added the comment: The proposed PR does not address this issue. It just adds comments to the method code, which aren't really needed. The method is short and obvious. We don't need, at this time, to get into questions of whether comments in argparse.py conform to one of the PEPs. All this issue needs is a change to the documentation. Changing: ArgumentParser.exit(status=0, message=None) This method terminates the program, exiting with the specified status and, if given, it prints a message before that. to: ArgumentParser.exit(status=0, message=None) This method terminates the program, exiting with the specified status and, if given, it prints a message to **standard error** before that. While I'm not opposed to this change, I don't think it is important. The documentation makes these two methods public, which I believe serves two purposes: - developers may want to issue their own `parser.error('...')` call, during post-parsing value checking, or issue their own `parser.exit()` call in a custom 'Action' class (much like what '_HelpAction' does). - developers might want to modify one or both of these in a ArgumentParser subclass. The unittesting code in argparse does this to capture and redirect errors. In both cases I expect the developer will want to read the code as well as the documentation. The fact that `exit()` uses stderr is quite obvious from the code. It's worth keeping in mind that the documentation never replicates the code. For example, in this case the documentation says error(), "terminates the program with a status code of 2.", when what it really does is "terminates with a call to exit(status=2)". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 02:59:19 2019 From: report at bugs.python.org (=?utf-8?b?RmXImXRpbMSDIEdlb3JnZSBDxIN0xINsaW4=?=) Date: Fri, 08 Feb 2019 07:59:19 +0000 Subject: [issue35938] crash of METADATA file cannot be fixed by reinstall of python Message-ID: <1549612757.81.0.536418249681.issue35938@roundup.psfhosted.org> New submission from Fe?til? George C?t?lin : The pip install module crash with this error: Could not install packages due to an EnvironmentError: [Errno 2] No such file or directory: 'c:\\python364\\lib\\site-packages\\traits-4.6.0.dist-info\\METADATA ' You are using pip version 18.1, however version 19.0.1 is available. You should consider upgrading via the 'python -m pip install --upgrade pip' comm and. I try to fix with the reinstall the python 3.6.4 but not working. I think the METADATA was delete by the antivirus. The version I used is 3.6.4 but the crash can be at any python version. ---------- messages: 335060 nosy: catafest priority: normal severity: normal status: open title: crash of METADATA file cannot be fixed by reinstall of python type: crash versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 03:14:45 2019 From: report at bugs.python.org (Dong-hee Na) Date: Fri, 08 Feb 2019 08:14:45 +0000 Subject: [issue35939] Remove urllib.parse._splittype from mimetypes.guess_type Message-ID: <1549613683.87.0.509050815243.issue35939@roundup.psfhosted.org> New submission from Dong-hee Na : Since urllib.parse.splittype is deprecated on 3.8. In the future urllib.parse._splittype also should be removed. I found that mimetypes.guess_type uses urllib.parse._splittype and it can be replaced and it also looks like solve the issue mentioned on https://github.com/python/cpython/blame/e42b705188271da108de42b55d9344642170aa2b/Lib/test/test_urllib2.py#L749 And I checked that all unit tests are passed when --- a/Lib/mimetypes.py +++ b/Lib/mimetypes.py @@ -114,7 +114,8 @@ class MimeTypes: but non-standard types. """ url = os.fspath(url) - scheme, url = urllib.parse._splittype(url) + p = urllib.parse.urlparse(url) + scheme, url = p.scheme, p.path if scheme == 'data': # syntax of data URLs: # dataurl := "data:" [ mediatype ] [ ";base64" ] "," data diff --git a/Lib/test/test_urllib2.py b/Lib/test/test_urllib2.py index 876fcd4199..0677390c2b 100644 --- a/Lib/test/test_urllib2.py +++ b/Lib/test/test_urllib2.py @@ -746,7 +746,7 @@ class HandlerTests(unittest.TestCase): ["foo", "bar"], "", None), ("ftp://localhost/baz.gif;type=a", "localhost", ftplib.FTP_PORT, "", "", "A", - [], "baz.gif", None), # XXX really this should guess image/gif + [], "baz.gif", "image/gif"), ]: req = Request(url) req.timeout = None I'd like to work on this issue if this proposal is accepted! Always thanks ---------- components: Library (Lib) messages: 335061 nosy: corona10 priority: normal severity: normal status: open title: Remove urllib.parse._splittype from mimetypes.guess_type type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 03:24:05 2019 From: report at bugs.python.org (Dong-hee Na) Date: Fri, 08 Feb 2019 08:24:05 +0000 Subject: [issue35939] Remove urllib.parse._splittype from mimetypes.guess_type In-Reply-To: <1549613683.87.0.509050815243.issue35939@roundup.psfhosted.org> Message-ID: <1549614245.78.0.340719418716.issue35939@roundup.psfhosted.org> Change by Dong-hee Na : ---------- versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 03:35:48 2019 From: report at bugs.python.org (=?utf-8?b?RmXImXRpbMSDIEdlb3JnZSBDxIN0xINsaW4=?=) Date: Fri, 08 Feb 2019 08:35:48 +0000 Subject: [issue35938] crash of METADATA file cannot be fixed by reinstall of python In-Reply-To: <1549612757.81.0.536418249681.issue35938@roundup.psfhosted.org> Message-ID: <1549614948.98.0.988107536104.issue35938@roundup.psfhosted.org> Fe?til? George C?t?lin added the comment: I delete two folders of traits Using the pip-review --auto this is the output of traits: copying traits\util\tests\__init__.py -> build\lib.win-amd64-3.6\traits\util\t ests running build_ext building 'traits.ctraits' extension creating build\temp.win-amd64-3.6 creating build\temp.win-amd64-3.6\Release creating build\temp.win-amd64-3.6\Release\traits C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14 .16.27023\bin\HostX86\x64\cl.exe /c /nologo /Ox /W3 /GL /DNDEBUG /MD -Ic:\python 364\include -Ic:\python364\include "-IC:\Program Files (x86)\Microsoft Visual St udio\2017\Community\VC\Tools\MSVC\14.16.27023\include" "-IC:\Program Files (x86) \Windows Kits\NETFXSDK\4.6.1\include\um" "-IC:\Program Files (x86)\Windows Kits\ 10\include\10.0.17763.0\ucrt" "-IC:\Program Files (x86)\Windows Kits\10\include\ 10.0.17134.0\shared" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.1713 4.0\um" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.17134.0\winrt" "- IC:\Program Files (x86)\Windows Kits\10\include\10.0.17134.0\cppwinrt" /Tctraits /ctraits.c /Fobuild\temp.win-amd64-3.6\Release\traits/ctraits.obj -DNDEBUG=1 -O3 cl : Command line warning D9002 : ignoring unknown option '-O3' ctraits.c c:\python364\include\pyconfig.h(59): fatal error C1083: Cannot open include fi le: 'io.h': No such file or directory error: command 'C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Commun ity\\VC\\Tools\\MSVC\\14.16.27023\\bin\\HostX86\\x64\\cl.exe' failed with exit s tatus 2 ---------------------------------------- Failed building wheel for traits Running setup.py clean for traits Failed to build scapy traits chalice 1.7.0 has requirement attrs==17.4.0, but you'll have attrs 18.2.0 which is incompatible. chalice 1.7.0 has requirement click<7.0,>=6.6, but you'll have click 7.0 which i s incompatible. chalice 1.7.0 has requirement typing==3.6.4; python_version < "3.7", but you'll have typing 3.6.6 which is incompatible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 03:54:39 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Fri, 08 Feb 2019 08:54:39 +0000 Subject: [issue35938] crash of METADATA file cannot be fixed by reinstall of python In-Reply-To: <1549612757.81.0.536418249681.issue35938@roundup.psfhosted.org> Message-ID: <1549616079.7.0.916832979624.issue35938@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: traits is not a part of stdlib and the tracker deals with issues in CPython. I think this is a third party issue or something related to your environment that can be reported to the respective project. ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 04:25:39 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 08 Feb 2019 09:25:39 +0000 Subject: [issue35938] crash of METADATA file cannot be fixed by reinstall of python In-Reply-To: <1549612757.81.0.536418249681.issue35938@roundup.psfhosted.org> Message-ID: <1549617939.06.0.657050029562.issue35938@roundup.psfhosted.org> St?phane Wirtel added the comment: hi @xtreak because I don't have a windows vm with me, I can't reproduce this issue, but maybe this issue is related with ensurepip or just with pip. when I have seen this issue, my first reaction was "it's not related to python", but I am not sure. ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 04:30:50 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 08 Feb 2019 09:30:50 +0000 Subject: [issue35921] Use ccache by default In-Reply-To: <1549481125.53.0.646421596529.issue35921@roundup.psfhosted.org> Message-ID: <1549618250.7.0.00465874115108.issue35921@roundup.psfhosted.org> St?phane Wirtel added the comment: Hi @Raymond I use this script since 1 year for the compilation of Python, https://github.com/python/cpython/pull/11773#issuecomment-461179522 #!/usr/bin/env fish set number_of_cpu (python3 -c "import os; print(os.sysconf('SC_NPROCESSORS_ONLN'))") ./configure --prefix=$PWD-build --with-pydebug --silent -C > stdout.txt ^ stderr.txt make CC="/usr/bin/ccache gcc" --jobs $number_of_cpu --silent > stdout.txt ^ stderr.txt Really useful because I use the cache of configure.ac and ccache for makefile. Now we could use distcc (for a distributed compilation or alternative) but I don't think the result will be really significative. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 04:34:32 2019 From: report at bugs.python.org (Pierre Glaser) Date: Fri, 08 Feb 2019 09:34:32 +0000 Subject: [issue35933] python doc does not say that the state kwarg in Pickler.save_reduce can be a tuple (and not only a dict) In-Reply-To: <1549562122.06.0.315178283617.issue35933@roundup.psfhosted.org> Message-ID: <1549618472.29.0.99843932044.issue35933@roundup.psfhosted.org> Pierre Glaser added the comment: Thanks Antoine and Raymond for the feedback. Indeed, a subclass of a slotted class can have a dict: I enriched the script, pickling_depickling instances of such subclasses, with the length-2 tuple __getstate__ method, and made sure their attributes were properly retrieved. Apart from the different checks on state carried out in the c load_build and the python load_build, AFAICT, it seems like this feature works :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 04:34:50 2019 From: report at bugs.python.org (Pierre Glaser) Date: Fri, 08 Feb 2019 09:34:50 +0000 Subject: [issue35933] python doc does not say that the state kwarg in Pickler.save_reduce can be a tuple (and not only a dict) In-Reply-To: <1549562122.06.0.315178283617.issue35933@roundup.psfhosted.org> Message-ID: <1549618490.31.0.101592504023.issue35933@roundup.psfhosted.org> Change by Pierre Glaser : Removed file: https://bugs.python.org/file48113/test_slots.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 04:35:14 2019 From: report at bugs.python.org (Hinayf Wikileakean) Date: Fri, 08 Feb 2019 09:35:14 +0000 Subject: [issue28488] shutil.make_archive (xxx, zip, root_dir) is adding './' entry to archive which is wrong In-Reply-To: <1476968870.46.0.0294634101167.issue28488@psf.upfronthosting.co.za> Message-ID: <1549618514.04.0.990097935256.issue28488@roundup.psfhosted.org> Hinayf Wikileakean added the comment: There is a similar bug/issue for 'tar' archives. ---------- nosy: +Hinayf Wikileakean _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 04:37:11 2019 From: report at bugs.python.org (Pierre Glaser) Date: Fri, 08 Feb 2019 09:37:11 +0000 Subject: [issue35933] python doc does not say that the state kwarg in Pickler.save_reduce can be a tuple (and not only a dict) In-Reply-To: <1549562122.06.0.315178283617.issue35933@roundup.psfhosted.org> Message-ID: <1549618631.14.0.729171202701.issue35933@roundup.psfhosted.org> Change by Pierre Glaser : Added file: https://bugs.python.org/file48114/test_slots.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 04:52:58 2019 From: report at bugs.python.org (Bangert) Date: Fri, 08 Feb 2019 09:52:58 +0000 Subject: [issue35875] Crash by Pandas - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd In-Reply-To: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> Message-ID: <1549619578.58.0.675228254808.issue35875@roundup.psfhosted.org> Change by Bangert : ---------- title: Crash - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd -> Crash by Pandas - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 04:54:31 2019 From: report at bugs.python.org (Bangert) Date: Fri, 08 Feb 2019 09:54:31 +0000 Subject: [issue35875] Crash by Pandas - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd In-Reply-To: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> Message-ID: <1549619670.99.0.0613852536393.issue35875@roundup.psfhosted.org> Bangert added the comment: I updated Pandas with the same result. I created new environments. When I load Pandas I get the same result and behaiviour. Permanent crashes of the python.exe. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 05:20:37 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Fri, 08 Feb 2019 10:20:37 +0000 Subject: [issue35875] Crash by Pandas - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd In-Reply-To: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> Message-ID: <1549621237.36.0.203525116501.issue35875@roundup.psfhosted.org> R?mi Lapeyre added the comment: Hi Bangert, thanks for reporting the issue. we need more information to reproduce the bug. Can you post the requirement.txt file as a text file rather than a screenshot and the step to reproduce the crash starting from an empty project? Were you able to reproduce the crash on another computer or is it specific to yours? ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 05:21:59 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Fri, 08 Feb 2019 10:21:59 +0000 Subject: [issue35938] crash of METADATA file cannot be fixed by reinstall of python In-Reply-To: <1549612757.81.0.536418249681.issue35938@roundup.psfhosted.org> Message-ID: <1549621319.53.0.189656096225.issue35938@roundup.psfhosted.org> Steven D'Aprano added the comment: That's not a crash. You are trying to install a package using pip, pip sees that it is missing the METADATA file and reports a problem. That is working correctly, not a crash. There is no way for us to know how the metadata file got deleted. Maybe you deleted it yourself by accident? Maybe an anti-virus program moved it. Maybe you never installed it. Maybe the traits package is broken and you need to report the issue to them. But whatever the problem is, it isn't a problem with your Python installation. You can reinstall Python a million times, that isn't going to make the traits METADATA file reappear. If you are absolutely sure that the traits package doesn't have a METADATA file, you should report this to the maintainers of the traits package. The *second* problem you report is a missing io.h file. That sounds like it has been deleted. Again, we have no way of knowing how. Unless someone reproduces that error we can only guess that this is something specific to your system and not a problem with Python. The *third* problem you report is with chalice. Again, this has nothing to do with Python, it is a third-party library and pip is doing exactly the right thing. chalice has unmet dependencies and cannot be installed, so pip is reporting the problem. You should complain to the chalice maintainers that their requirements are too strict. I don't think any of these problems have anything to do with Python itself, so I'm going to close this issue as "Third Party". If you have additional information which shows that it is a Python problem, please tell us and we will re-open the issue. ---------- nosy: +steven.daprano resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 05:25:54 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Fri, 08 Feb 2019 10:25:54 +0000 Subject: [issue35904] Add statistics.fmean(seq) In-Reply-To: <20190208052845.GJ1834@ando.pearwood.info> Message-ID: <20190208102548.GK1834@ando.pearwood.info> Steven D'Aprano added the comment: Oh, I seem to have accidentally reverted the change of title. Sorry, that was definitely not intended and I don't know how it happened. But now that it has, I'm not going to change it until we have a decision on a name. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 06:01:17 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 08 Feb 2019 11:01:17 +0000 Subject: [issue35937] Add instancemethod to types.py In-Reply-To: <1549604215.56.0.840022461634.issue35937@roundup.psfhosted.org> Message-ID: <1549623677.95.0.133490741631.issue35937@roundup.psfhosted.org> Ronald Oussoren added the comment: Could you expand on why instancemethod is amazing, other than that's it is apparently fast at something. ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 06:17:35 2019 From: report at bugs.python.org (Bangert) Date: Fri, 08 Feb 2019 11:17:35 +0000 Subject: [issue35875] Crash by Pandas - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd In-Reply-To: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> Message-ID: <1549624655.54.0.407542471283.issue35875@roundup.psfhosted.org> Change by Bangert : Added file: https://bugs.python.org/file48115/Conda-Algos-Joint-Crash-04.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 06:43:40 2019 From: report at bugs.python.org (Bangert) Date: Fri, 08 Feb 2019 11:43:40 +0000 Subject: [issue35875] Crash by Pandas - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd In-Reply-To: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> Message-ID: <1549626220.93.0.638867457237.issue35875@roundup.psfhosted.org> Change by Bangert : Added file: https://bugs.python.org/file48116/Conda-Algos-Joint-Crash-05.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 06:44:10 2019 From: report at bugs.python.org (Bangert) Date: Fri, 08 Feb 2019 11:44:10 +0000 Subject: [issue35875] Crash by Pandas - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd In-Reply-To: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> Message-ID: <1549626250.46.0.493590034044.issue35875@roundup.psfhosted.org> Change by Bangert : Added file: https://bugs.python.org/file48117/requirements.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 06:56:53 2019 From: report at bugs.python.org (Bangert) Date: Fri, 08 Feb 2019 11:56:53 +0000 Subject: [issue35875] Crash by Pandas - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd In-Reply-To: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> Message-ID: <1549627013.25.0.253025164097.issue35875@roundup.psfhosted.org> Change by Bangert : Removed file: https://bugs.python.org/file48117/requirements.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 06:58:45 2019 From: report at bugs.python.org (Bangert) Date: Fri, 08 Feb 2019 11:58:45 +0000 Subject: [issue35875] Crash by Pandas - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd In-Reply-To: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> Message-ID: <1549627125.54.0.0678956226406.issue35875@roundup.psfhosted.org> Change by Bangert : Added file: https://bugs.python.org/file48118/requirementsWin7-Prof-SP1-x64-English.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 06:59:08 2019 From: report at bugs.python.org (Bangert) Date: Fri, 08 Feb 2019 11:59:08 +0000 Subject: [issue35875] Crash by Pandas - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd In-Reply-To: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> Message-ID: <1549627148.39.0.964192802584.issue35875@roundup.psfhosted.org> Change by Bangert : Added file: https://bugs.python.org/file48119/requirementsWin10-Educ-1809-x64-German.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 06:59:33 2019 From: report at bugs.python.org (Bangert) Date: Fri, 08 Feb 2019 11:59:33 +0000 Subject: [issue35875] Crash by Pandas - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd In-Reply-To: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> Message-ID: <1549627173.5.0.820812501064.issue35875@roundup.psfhosted.org> Change by Bangert : Added file: https://bugs.python.org/file48120/Conda-Algos-Joint-Crash-06.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 07:02:07 2019 From: report at bugs.python.org (Bangert) Date: Fri, 08 Feb 2019 12:02:07 +0000 Subject: [issue35875] Crash by Pandas - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd In-Reply-To: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> Message-ID: <1549627327.97.0.29852776667.issue35875@roundup.psfhosted.org> Bangert added the comment: 1. In Win7 the crash happens on every change in code, even in the webroot of tensorboard. 2. In Win10 there is !no! crash ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 07:02:39 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Fri, 08 Feb 2019 12:02:39 +0000 Subject: [issue35937] Add instancemethod to types.py In-Reply-To: <1549604215.56.0.840022461634.issue35937@roundup.psfhosted.org> Message-ID: <1549627359.3.0.61506466201.issue35937@roundup.psfhosted.org> Steven D'Aprano added the comment: I presume you aren't referring to this: from types import MethodType > There really isn't anything else to say about it How about starting with why you want this and what you will do with it? According to this post on StackOverflow: https://stackoverflow.com/questions/40876368/where-can-i-find-an-instancemethod-in-the-python-3-standard-library The name instancemethod looks a lot like a bound method object, but it turns out it's something else entirely. It's a weird internal thing that, according to its documentation, is supposed to be the new way for C types to represent their methods, except that the standard C-level API for creating a type doesn't actually use it. According to conversations on the Python issue tracker, this feature was requested by the developers of Cython and Pyrex. Given that this is not used anywhere in CPython, the documentation for the C API specifically says it is not exposed to Python code, and the name is painfully misleading, we should assume that it is undocumented for a reason. It might help to persuade the core devs to expose it as part of the public Python API if you have a use-case for this. (And if so, I think it desperately needs to change the displayed name away from "instancemethod", since that's not what it returns.) See also #28842 ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 07:04:14 2019 From: report at bugs.python.org (Bangert) Date: Fri, 08 Feb 2019 12:04:14 +0000 Subject: [issue35875] Crash by Pandas - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd In-Reply-To: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> Message-ID: <1549627454.29.0.0532739705655.issue35875@roundup.psfhosted.org> Change by Bangert : Removed file: https://bugs.python.org/file48120/Conda-Algos-Joint-Crash-06.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 07:04:33 2019 From: report at bugs.python.org (Bangert) Date: Fri, 08 Feb 2019 12:04:33 +0000 Subject: [issue35875] Crash by Pandas - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd In-Reply-To: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> Message-ID: <1549627473.46.0.431614113789.issue35875@roundup.psfhosted.org> Change by Bangert : Removed file: https://bugs.python.org/file48116/Conda-Algos-Joint-Crash-05.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 07:05:43 2019 From: report at bugs.python.org (Bangert) Date: Fri, 08 Feb 2019 12:05:43 +0000 Subject: [issue35875] Crash by Pandas - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd In-Reply-To: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> Message-ID: <1549627543.93.0.148837839437.issue35875@roundup.psfhosted.org> Change by Bangert : Added file: https://bugs.python.org/file48121/Conda-Algos-Joint-Crash-Win7-RWTH-SAP1.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 07:06:02 2019 From: report at bugs.python.org (Bangert) Date: Fri, 08 Feb 2019 12:06:02 +0000 Subject: [issue35875] Crash by Pandas - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd In-Reply-To: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> Message-ID: <1549627562.09.0.921160872863.issue35875@roundup.psfhosted.org> Change by Bangert : Added file: https://bugs.python.org/file48122/Conda-Algos-Joint-NoCrash-Win10-RWTH-SAP2.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 07:14:41 2019 From: report at bugs.python.org (Bangert) Date: Fri, 08 Feb 2019 12:14:41 +0000 Subject: [issue35875] Crash by Pandas - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd In-Reply-To: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> Message-ID: <1549628081.41.0.57300975931.issue35875@roundup.psfhosted.org> Change by Bangert : Removed file: https://bugs.python.org/file48115/Conda-Algos-Joint-Crash-04.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 07:14:58 2019 From: report at bugs.python.org (Bangert) Date: Fri, 08 Feb 2019 12:14:58 +0000 Subject: [issue35875] Crash by Pandas - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd In-Reply-To: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> Message-ID: <1549628098.79.0.201233939941.issue35875@roundup.psfhosted.org> Change by Bangert : Removed file: https://bugs.python.org/file48122/Conda-Algos-Joint-NoCrash-Win10-RWTH-SAP2.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 07:15:16 2019 From: report at bugs.python.org (Bangert) Date: Fri, 08 Feb 2019 12:15:16 +0000 Subject: [issue35875] Crash by Pandas - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd In-Reply-To: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> Message-ID: <1549628116.36.0.202851176319.issue35875@roundup.psfhosted.org> Change by Bangert : Removed file: https://bugs.python.org/file48121/Conda-Algos-Joint-Crash-Win7-RWTH-SAP1.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 07:15:44 2019 From: report at bugs.python.org (Bangert) Date: Fri, 08 Feb 2019 12:15:44 +0000 Subject: [issue35875] Crash by Pandas - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd In-Reply-To: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> Message-ID: <1549628144.95.0.361441108372.issue35875@roundup.psfhosted.org> Change by Bangert : Added file: https://bugs.python.org/file48123/Conda-Algos-Joint-Crash-Event-Win7-RWTH-SAP1.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 07:16:07 2019 From: report at bugs.python.org (Bangert) Date: Fri, 08 Feb 2019 12:16:07 +0000 Subject: [issue35875] Crash by Pandas - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd In-Reply-To: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> Message-ID: <1549628166.99.0.0149758984778.issue35875@roundup.psfhosted.org> Change by Bangert : Added file: https://bugs.python.org/file48124/Conda-Algos-Joint-Crash-Popup-Win7-RWTH-SAP1.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 07:16:28 2019 From: report at bugs.python.org (Bangert) Date: Fri, 08 Feb 2019 12:16:28 +0000 Subject: [issue35875] Crash by Pandas - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd In-Reply-To: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> Message-ID: <1549628188.97.0.124347804742.issue35875@roundup.psfhosted.org> Change by Bangert : Added file: https://bugs.python.org/file48125/Conda-Algos-Joint-Crash-Silent-Event-Win10-RWTH-SAP2.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 07:17:49 2019 From: report at bugs.python.org (Bangert) Date: Fri, 08 Feb 2019 12:17:49 +0000 Subject: [issue35875] Crash by Pandas - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd In-Reply-To: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> Message-ID: <1549628269.56.0.341095049719.issue35875@roundup.psfhosted.org> Change by Bangert : Added file: https://bugs.python.org/file48126/Conda-Algos-Joint-Crash-Silent-Project-Win10-RWTH-SAP2.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 07:29:24 2019 From: report at bugs.python.org (Bangert) Date: Fri, 08 Feb 2019 12:29:24 +0000 Subject: [issue35875] Crash by Pandas - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd In-Reply-To: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> Message-ID: <1549628964.0.0.870912405203.issue35875@roundup.psfhosted.org> Bangert added the comment: Correction - I did not see the popup in Win10 for it is a silent crash without popup so: 1. Win 7 crashes with popup 2. Win10 crashes silently ---------- Added file: https://bugs.python.org/file48127/Crash-Popup-Win7-RWTH-SAP1.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 08:02:06 2019 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 08 Feb 2019 13:02:06 +0000 Subject: [issue35904] Add statistics.fmean(seq) In-Reply-To: <1549411161.36.0.783593325223.issue35904@roundup.psfhosted.org> Message-ID: <1549630926.43.0.567993361813.issue35904@roundup.psfhosted.org> Mark Dickinson added the comment: No further bikeshedding on the name from me; +1 on whatever you decide on. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 08:06:52 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Fri, 08 Feb 2019 13:06:52 +0000 Subject: [issue35937] Add instancemethod to types.py In-Reply-To: <1549604215.56.0.840022461634.issue35937@roundup.psfhosted.org> Message-ID: <1549631212.14.0.942271697332.issue35937@roundup.psfhosted.org> Cheryl Sabella added the comment: Also see issue 11776 about documenting the signatures. ---------- nosy: +cheryl.sabella _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 08:20:44 2019 From: report at bugs.python.org (uhei3nn9) Date: Fri, 08 Feb 2019 13:20:44 +0000 Subject: [issue21109] tarfile: Traversal attack vulnerability In-Reply-To: <1396253659.12.0.842636239516.issue21109@psf.upfronthosting.co.za> Message-ID: <1549632044.53.0.274812571502.issue21109@roundup.psfhosted.org> uhei3nn9 added the comment: Is there any update on this? Will this be fixed in the next release? Having a code execution vulnerability (yes it is!) in python for 5 years does not really spark confidence... ---------- nosy: +uhei3nn9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 08:20:50 2019 From: report at bugs.python.org (Steven Davidson) Date: Fri, 08 Feb 2019 13:20:50 +0000 Subject: [issue23607] Inconsistency in datetime.utcfromtimestamp(Decimal) In-Reply-To: <1425810901.79.0.570490913636.issue23607@psf.upfronthosting.co.za> Message-ID: <1549632050.93.0.626642346502.issue23607@roundup.psfhosted.org> Change by Steven Davidson : ---------- nosy: +Steven Davidson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 08:22:05 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Fri, 08 Feb 2019 13:22:05 +0000 Subject: [issue24087] Documentation doesn't explain the term "coroutine" (PEP 342) In-Reply-To: <1430425552.31.0.779606074615.issue24087@psf.upfronthosting.co.za> Message-ID: <1549632125.55.0.944994135625.issue24087@roundup.psfhosted.org> Cheryl Sabella added the comment: While some of the proposed changes in this issue have been applied to the documentation under other issues, other changes have not been applied. Is it still desirable to incorporate the other changes (such as native coroutine) or have the existing doc changes been enough to make this issue obsolete? Thank you. ---------- nosy: +cheryl.sabella _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 08:28:16 2019 From: report at bugs.python.org (Lele Gaifax) Date: Fri, 08 Feb 2019 13:28:16 +0000 Subject: [issue22228] Adapt bash readline operate-and-get-next function In-Reply-To: <1408441328.29.0.0681426449148.issue22228@psf.upfronthosting.co.za> Message-ID: <1549632496.27.0.107591092138.issue22228@roundup.psfhosted.org> Lele Gaifax added the comment: I rebased my work on current master of the cpython git repository, cherry picking the changes from the old branch (that was based on a at the time unofficial git mirror of the mercurial repository). To avoid any ambiguity I called it "issue22228_3", so it is now available here: https://github.com/lelit/cpython/tree/issue22228_3 Since now I own a Mac, I could find the energies to adapt the changes to libedit, if at all possible. That would be even more likely to happen should I receive some positive feedback on the chances this has to be accepted :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 08:30:43 2019 From: report at bugs.python.org (Ramy Abdel-Azim) Date: Fri, 08 Feb 2019 13:30:43 +0000 Subject: [issue17164] MozillaCookieJar does not handle session cookies In-Reply-To: <1360358603.06.0.441613239061.issue17164@psf.upfronthosting.co.za> Message-ID: <1549632643.33.0.301686649671.issue17164@roundup.psfhosted.org> Ramy Abdel-Azim added the comment: Hi, Is there any update on this ticket? I would love to use Requests instead of writing a curl command and running it from the command line out of my script but I need this functionality to pull the cookies.txt file in. Thanks! _Ramy ---------- nosy: +Ramy Abdel-Azim _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 08:54:27 2019 From: report at bugs.python.org (Paul Moore) Date: Fri, 08 Feb 2019 13:54:27 +0000 Subject: [issue24087] Documentation doesn't explain the term "coroutine" (PEP 342) In-Reply-To: <1430425552.31.0.779606074615.issue24087@psf.upfronthosting.co.za> Message-ID: <1549634067.0.0.903125061559.issue24087@roundup.psfhosted.org> Paul Moore added the comment: I'm OK that the basic glossary item is now covered. I don't know about any of the other issues Martin mentioned. I've closed the issue as my original comment is addressed, but if Martin wants to reopen it to address his concerns, I'm OK with him doing that. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 09:06:49 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Fri, 08 Feb 2019 14:06:49 +0000 Subject: [issue35940] multiprocessing manager tests fail in the Refleaks buildbots Message-ID: <1549634808.3.0.556124260005.issue35940@roundup.psfhosted.org> New submission from Pablo Galindo Salgado : After PR11772, some buildbots with refleak checks fail because the tests modify the environment (leaking processes or threads or files ...). Some of the failures: https://buildbot.python.org/all/#builders/80/builds/506 ttps://buildbot.python.org/all/#builders/114/builds/375 https://buildbot.python.org/all/#builders/1/builds/497 == Tests result: ENV CHANGED == 409 tests OK. 10 slowest tests: - test_multiprocessing_spawn: 32 min 19 sec - test_concurrent_futures: 25 min 37 sec - test_asyncio: 24 min 56 sec - test_multiprocessing_forkserver: 13 min 57 sec - test_multiprocessing_fork: 11 min 2 sec - test_zipfile: 10 min 2 sec - test_decimal: 8 min 30 sec - test_gdb: 8 min 301 ms - test_lib2to3: 7 min 46 sec - test_buffer: 7 min 43 sec 3 tests altered the execution environment: test_multiprocessing_fork test_multiprocessing_forkserver test_multiprocessing_spawn 8 tests skipped: test_devpoll test_kqueue test_msilib test_startfile test_winconsoleio test_winreg test_winsound test_zipfile64 ---------- components: Tests messages: 335083 nosy: giampaolo.rodola, pablogsal, pitrou priority: normal severity: normal status: open title: multiprocessing manager tests fail in the Refleaks buildbots versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 09:43:30 2019 From: report at bugs.python.org (Michael Schlenker) Date: Fri, 08 Feb 2019 14:43:30 +0000 Subject: [issue35941] ssl.enum_certificates() regression Message-ID: <1549637009.73.0.764067041861.issue35941@roundup.psfhosted.org> New submission from Michael Schlenker : The introduction of the ReadOnly flag in the ssl.enum_certificates() function implementation has introduced a regression. The old version returned certificates for both the current user and the local system, the new function only enumerates system wide certificates and ignores the current user. The old function before Patch from https://bugs.python.org/issue25939 used a different function to open the certificate store (CertOpenStore vs. CertOpenSystemStore). Probably some of the param flags are not identical, the new code explictly lists only local system. Testing: 1. Import a self signed CA only into the 'current user' trustworthy certificates. 2. Use IE to Connect to a https:// website using that trust root. Works. 3. Try to open the website with old python and new python. Old one works, new one fails. Or just enum certificates: 1. Import a self signed CA into the current_user trusted store. 2. Compare outputs of: import ssl len(ssl.enum_certificates('ROOT')) ---------- assignee: christian.heimes components: SSL, Windows messages: 335084 nosy: christian.heimes, paul.moore, schlenk, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: ssl.enum_certificates() regression type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 09:59:06 2019 From: report at bugs.python.org (Christian Heimes) Date: Fri, 08 Feb 2019 14:59:06 +0000 Subject: [issue35941] ssl.enum_certificates() regression In-Reply-To: <1549637009.73.0.764067041861.issue35941@roundup.psfhosted.org> Message-ID: <1549637946.34.0.545046683196.issue35941@roundup.psfhosted.org> Christian Heimes added the comment: I guess the flags are wrong. https://hg.python.org/cpython/rev/d6474257ef38 changed flags to CERT_SYSTEM_STORE_LOCAL_MACHINE. To get local user certs, the flag should probably be CERT_SYSTEM_STORE_CURRENT_USER. ---------- assignee: christian.heimes -> steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 10:00:49 2019 From: report at bugs.python.org (Christian Heimes) Date: Fri, 08 Feb 2019 15:00:49 +0000 Subject: [issue35941] ssl.enum_certificates() regression In-Reply-To: <1549637009.73.0.764067041861.issue35941@roundup.psfhosted.org> Message-ID: <1549638049.9.0.234141592824.issue35941@roundup.psfhosted.org> Change by Christian Heimes : ---------- versions: -Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 10:24:33 2019 From: report at bugs.python.org (Paul Ganssle) Date: Fri, 08 Feb 2019 15:24:33 +0000 Subject: [issue32417] fromutc does not respect datetime subclasses In-Reply-To: <1514052939.19.0.213398074469.issue32417@psf.upfronthosting.co.za> Message-ID: <1549639473.73.0.578838211774.issue32417@roundup.psfhosted.org> Change by Paul Ganssle : ---------- pull_requests: +11790 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 10:24:43 2019 From: report at bugs.python.org (Paul Ganssle) Date: Fri, 08 Feb 2019 15:24:43 +0000 Subject: =?utf-8?b?W2lzc3VlMzUzNjRdIERhdGV0aW1lIOKAnGZyb210aW1lc3RhbXAoKeKAnSBp?= =?utf-8?q?gnores_inheritance_if_timezone_is_not_None?= In-Reply-To: <1543598741.31.0.788709270274.issue35364@psf.upfronthosting.co.za> Message-ID: <1549639483.42.0.688501852841.issue35364@roundup.psfhosted.org> Change by Paul Ganssle : ---------- pull_requests: +11794 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 10:24:43 2019 From: report at bugs.python.org (Paul Ganssle) Date: Fri, 08 Feb 2019 15:24:43 +0000 Subject: [issue32417] fromutc does not respect datetime subclasses In-Reply-To: <1514052939.19.0.213398074469.issue32417@psf.upfronthosting.co.za> Message-ID: <1549639483.4.0.642848159884.issue32417@roundup.psfhosted.org> Change by Paul Ganssle : ---------- pull_requests: +11790, 11791 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 10:24:53 2019 From: report at bugs.python.org (Paul Ganssle) Date: Fri, 08 Feb 2019 15:24:53 +0000 Subject: [issue32417] fromutc does not respect datetime subclasses In-Reply-To: <1514052939.19.0.213398074469.issue32417@psf.upfronthosting.co.za> Message-ID: <1549639493.14.0.696981452966.issue32417@roundup.psfhosted.org> Change by Paul Ganssle : ---------- pull_requests: +11790, 11791, 11792 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 10:24:54 2019 From: report at bugs.python.org (Paul Ganssle) Date: Fri, 08 Feb 2019 15:24:54 +0000 Subject: =?utf-8?b?W2lzc3VlMzUzNjRdIERhdGV0aW1lIOKAnGZyb210aW1lc3RhbXAoKeKAnSBp?= =?utf-8?q?gnores_inheritance_if_timezone_is_not_None?= In-Reply-To: <1543598741.31.0.788709270274.issue35364@psf.upfronthosting.co.za> Message-ID: <1549639494.77.0.616440353533.issue35364@roundup.psfhosted.org> Change by Paul Ganssle : ---------- pull_requests: +11794, 11795 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 10:25:02 2019 From: report at bugs.python.org (Paul Ganssle) Date: Fri, 08 Feb 2019 15:25:02 +0000 Subject: [issue32417] fromutc does not respect datetime subclasses In-Reply-To: <1514052939.19.0.213398074469.issue32417@psf.upfronthosting.co.za> Message-ID: <1549639502.17.0.479010236374.issue32417@roundup.psfhosted.org> Change by Paul Ganssle : ---------- pull_requests: +11790, 11791, 11792, 11793 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 10:25:41 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 08 Feb 2019 15:25:41 +0000 Subject: [issue35935] threading.Event().wait() not interruptable with Ctrl-C on Windows In-Reply-To: <1549588377.49.0.765820535798.issue35935@roundup.psfhosted.org> Message-ID: <1549639541.34.0.596034285094.issue35935@roundup.psfhosted.org> Steve Dower added the comment: I'm not sure it's quite as simple as calling sys.exit, but it would be a great project to bring universal cancellation support to all (regularly) blocking functions. Asyncio has suffered from this as well. Part of the problem is that POSIX APIs often don't support cancellation, and so things have been designed in ways that prevent use of Windows's cancellation support (via APCs or kernel events). Given that we would have to emulate a lot of things on all platforms to make it consistent, this is certainly a PEP and long-term project. (And probably a lot of arguments with people who don't like new abstractions :( ) But on this particular issue, making the unconditional wait be interruptable by signals shouldn't be impossible. It's been done elsewhere, so probably just this one got missed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 10:28:09 2019 From: report at bugs.python.org (Michael Schlenker) Date: Fri, 08 Feb 2019 15:28:09 +0000 Subject: [issue35941] ssl.enum_certificates() regression In-Reply-To: <1549637009.73.0.764067041861.issue35941@roundup.psfhosted.org> Message-ID: <1549639689.27.0.811297163191.issue35941@roundup.psfhosted.org> Michael Schlenker added the comment: It probably is even worse. The flag seems to specifiy the physical locations, and just using CERT_SYSTEM_STORE_LOCAL_SYSTEM probably misses the certificates distributed by Group Policy or AD too, in addition to the stores for the current user. See https://blogs.msdn.microsoft.com/muaddib/2013/10/18/understanding-and-managing-the-certificate-stores-used-for-smart-card-logon/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 10:38:46 2019 From: report at bugs.python.org (Paul Ganssle) Date: Fri, 08 Feb 2019 15:38:46 +0000 Subject: [issue32417] fromutc does not respect datetime subclasses In-Reply-To: <1514052939.19.0.213398074469.issue32417@psf.upfronthosting.co.za> Message-ID: <1549640326.35.0.509557537078.issue32417@roundup.psfhosted.org> Paul Ganssle added the comment: Hm, when I made the "What's new" issue, it added the same PR to the "Pull requests" 4 times instead of once, and in the history it seems like it *tried* to actually add PR 11790, 11791, 11792 and 11793 (only the first one exists at the moment). Not sure why that happened and where I'd report that bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 10:40:38 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Fri, 08 Feb 2019 15:40:38 +0000 Subject: [issue17164] MozillaCookieJar does not handle session cookies In-Reply-To: <1360358603.06.0.441613239061.issue17164@psf.upfronthosting.co.za> Message-ID: <1549640438.54.0.156518738873.issue17164@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 10:42:44 2019 From: report at bugs.python.org (Paul Ganssle) Date: Fri, 08 Feb 2019 15:42:44 +0000 Subject: [issue32417] fromutc does not respect datetime subclasses In-Reply-To: <1514052939.19.0.213398074469.issue32417@psf.upfronthosting.co.za> Message-ID: <1549640564.31.0.76513075392.issue32417@roundup.psfhosted.org> Paul Ganssle added the comment: Ah, sorry for the noise, this is a known issue: https://github.com/python/bugs.python.org/issues/12 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 10:51:43 2019 From: report at bugs.python.org (glin) Date: Fri, 08 Feb 2019 15:51:43 +0000 Subject: [issue30782] Allow limiting the number of concurrent tasks in asyncio.as_completed In-Reply-To: <1498525522.6.0.617023291854.issue30782@psf.upfronthosting.co.za> Message-ID: <1549641103.12.0.309809629068.issue30782@roundup.psfhosted.org> glin added the comment: @Andrew Svetlov: I was surprised when you wrote "as_completed() is low-level API.", so I wondered what is high level API and I googled it and first that came was official doc: https://docs.python.org/3/library/asyncio-api-index.html Where it's written that it's high level API indeed. IMHO without limit, all of these functions are quite impractical (as_completed, wait, gather, ...). I have simple to moderately complex scripts and I'm running into problems with it (API servers limiting number of requests per minute, /tmp/ (4GB ramdisk) out of space, memory issues... Please reconsider adding limit to these functions as it's suppose to be high level API, not low level. Thanks ---------- nosy: +glin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 11:02:10 2019 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Fri, 08 Feb 2019 16:02:10 +0000 Subject: [issue32417] fromutc does not respect datetime subclasses In-Reply-To: <1514052939.19.0.213398074469.issue32417@psf.upfronthosting.co.za> Message-ID: <1549641730.44.0.487414557645.issue32417@roundup.psfhosted.org> ?ukasz Langa added the comment: New changeset d9503c307a8b6a7b73f6344183602ffb014d3356 by ?ukasz Langa (Paul Ganssle) in branch 'master': Add What's New entry for date subclass behavior (#11790) https://github.com/python/cpython/commit/d9503c307a8b6a7b73f6344183602ffb014d3356 ---------- nosy: +lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 11:02:17 2019 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Fri, 08 Feb 2019 16:02:17 +0000 Subject: =?utf-8?b?W2lzc3VlMzUzNjRdIERhdGV0aW1lIOKAnGZyb210aW1lc3RhbXAoKeKAnSBp?= =?utf-8?q?gnores_inheritance_if_timezone_is_not_None?= In-Reply-To: <1543598741.31.0.788709270274.issue35364@psf.upfronthosting.co.za> Message-ID: <1549641737.52.0.469160963638.issue35364@roundup.psfhosted.org> ?ukasz Langa added the comment: New changeset d9503c307a8b6a7b73f6344183602ffb014d3356 by ?ukasz Langa (Paul Ganssle) in branch 'master': Add What's New entry for date subclass behavior (#11790) https://github.com/python/cpython/commit/d9503c307a8b6a7b73f6344183602ffb014d3356 ---------- nosy: +lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 11:05:33 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Fri, 08 Feb 2019 16:05:33 +0000 Subject: [issue35922] robotparser crawl_delay and request_rate do not work with no matching entry In-Reply-To: <1549485183.59.0.634497522614.issue35922@roundup.psfhosted.org> Message-ID: <1549641933.42.0.975760966267.issue35922@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- keywords: +patch pull_requests: +11796 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 11:07:45 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Fri, 08 Feb 2019 16:07:45 +0000 Subject: [issue35922] robotparser crawl_delay and request_rate do not work with no matching entry In-Reply-To: <1549485183.59.0.634497522614.issue35922@roundup.psfhosted.org> Message-ID: <1549642065.08.0.555378804795.issue35922@roundup.psfhosted.org> R?mi Lapeyre added the comment: Thanks for your report Joseph, I opened a new PR to fix this. ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 11:29:45 2019 From: report at bugs.python.org (SilentGhost) Date: Fri, 08 Feb 2019 16:29:45 +0000 Subject: [issue35939] Remove urllib.parse._splittype from mimetypes.guess_type In-Reply-To: <1549613683.87.0.509050815243.issue35939@roundup.psfhosted.org> Message-ID: <1549643385.34.0.832734741007.issue35939@roundup.psfhosted.org> Change by SilentGhost : ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 11:31:09 2019 From: report at bugs.python.org (SilentGhost) Date: Fri, 08 Feb 2019 16:31:09 +0000 Subject: [issue35936] Give modulefinder some much-needed updates. In-Reply-To: <1549596039.09.0.478412891062.issue35936@roundup.psfhosted.org> Message-ID: <1549643469.91.0.257590561061.issue35936@roundup.psfhosted.org> Change by SilentGhost : ---------- nosy: +jvr _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 11:34:40 2019 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Fri, 08 Feb 2019 16:34:40 +0000 Subject: [issue35942] posixmodule.c:path_converter() returns an invalid exception message for broken PathLike objects Message-ID: <1549643679.09.0.475002054663.issue35942@roundup.psfhosted.org> New submission from ?ukasz Langa : >>> class K: ... def __fspath__(self): ... return 1 ... >>> import os >>> os.stat(K()) Traceback (most recent call last): File "", line 1, in TypeError: stat: path should be string, bytes, os.PathLike or integer, not int This error message is internally inconsistent: - it suggests that the error is about the path argument whereas it's in fact about the value returned from `__fspath__()` - it hilariously states "should be integer, not int" - it claims os.PathLike is fine as a return value from `__fspath__()` whereas it's not I would advise removing the custom `__fspath__()` handling from `path_converter` and just directly using PyOS_FSPath which returns a valid error in this case (example from pypy3): >>>> class K: .... def __fspath__(self): .... return 1 .... >>>> import os >>>> os.open(K(), os.O_RDONLY) Traceback (most recent call last): File "", line 1, in TypeError: expected K.__fspath__() to return str or bytes, not int ---------- messages: 335094 nosy: lukasz.langa priority: normal severity: normal stage: needs patch status: open title: posixmodule.c:path_converter() returns an invalid exception message for broken PathLike objects type: behavior versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 11:36:57 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Fri, 08 Feb 2019 16:36:57 +0000 Subject: [issue17164] MozillaCookieJar does not handle session cookies In-Reply-To: <1360358603.06.0.441613239061.issue17164@psf.upfronthosting.co.za> Message-ID: <1549643817.2.0.14456953499.issue17164@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- pull_requests: +11797 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 11:37:05 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Fri, 08 Feb 2019 16:37:05 +0000 Subject: [issue17164] MozillaCookieJar does not handle session cookies In-Reply-To: <1360358603.06.0.441613239061.issue17164@psf.upfronthosting.co.za> Message-ID: <1549643825.25.0.26727835459.issue17164@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- pull_requests: +11797, 11798 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 11:37:13 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Fri, 08 Feb 2019 16:37:13 +0000 Subject: [issue17164] MozillaCookieJar does not handle session cookies In-Reply-To: <1360358603.06.0.441613239061.issue17164@psf.upfronthosting.co.za> Message-ID: <1549643833.33.0.7534723155.issue17164@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- pull_requests: +11797, 11798, 11799 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 11:39:40 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Fri, 08 Feb 2019 16:39:40 +0000 Subject: [issue17164] MozillaCookieJar does not handle session cookies In-Reply-To: <1360358603.06.0.441613239061.issue17164@psf.upfronthosting.co.za> Message-ID: <1549643980.99.0.0244768248981.issue17164@roundup.psfhosted.org> R?mi Lapeyre added the comment: Hi Ramy, thanks for bumping the issue. The solution suggested by Piotr Dobrogost is backward compatible and I think it's the right thing to do. I opened a new PR thanks to the patch of J?r?mie Detrey. ---------- versions: +Python 3.7, Python 3.8 -Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 11:55:34 2019 From: report at bugs.python.org (Eric Snow) Date: Fri, 08 Feb 2019 16:55:34 +0000 Subject: [issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h In-Reply-To: <1549069628.87.0.454232469964.issue35886@roundup.psfhosted.org> Message-ID: <1549644934.5.0.575751488695.issue35886@roundup.psfhosted.org> Change by Eric Snow : ---------- pull_requests: -11625 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 11:55:51 2019 From: report at bugs.python.org (Eric Snow) Date: Fri, 08 Feb 2019 16:55:51 +0000 Subject: [issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h In-Reply-To: <1549069628.87.0.454232469964.issue35886@roundup.psfhosted.org> Message-ID: <1549644951.52.0.977350577865.issue35886@roundup.psfhosted.org> Change by Eric Snow : ---------- pull_requests: -11624 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 12:09:57 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 08 Feb 2019 17:09:57 +0000 Subject: [issue34572] C unpickling bypasses import thread safety In-Reply-To: <1535990001.55.0.56676864532.issue34572@psf.upfronthosting.co.za> Message-ID: <1549645797.37.0.905614206087.issue34572@roundup.psfhosted.org> Antoine Pitrou added the comment: I agree that more generally PyImport_GetModule() should be fixed. But it should be done carefully so as to not to lose the performance benefit of doing it. I think we should open a separate issue about that. PS: one possibility is to reuse the optimization already done in PyImport_ImportModuleLevelObject(): /* Optimization: only call _bootstrap._lock_unlock_module() if __spec__._initializing is true. NOTE: because of this, initializing must be set *before* stuffing the new module in sys.modules. */ spec = _PyObject_GetAttrId(mod, &PyId___spec__); if (_PyModuleSpec_IsInitializing(spec)) { PyObject *value = _PyObject_CallMethodIdObjArgs(interp->importlib, &PyId__lock_unlock_module, abs_name, NULL); if (value == NULL) { Py_DECREF(spec); goto error; } Py_DECREF(value); } Py_XDECREF(spec); ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 12:13:38 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 08 Feb 2019 17:13:38 +0000 Subject: [issue35943] PyImport_GetModule() can return partially-initialized module Message-ID: <1549646017.22.0.395154635441.issue35943@roundup.psfhosted.org> New submission from Antoine Pitrou : PyImport_GetModule() returns whatever is in sys.modules, even if the module is still importing and therefore only partially initialized. One possibility is to reuse the optimization already done in PyImport_ImportModuleLevelObject(): /* Optimization: only call _bootstrap._lock_unlock_module() if __spec__._initializing is true. NOTE: because of this, initializing must be set *before* stuffing the new module in sys.modules. */ spec = _PyObject_GetAttrId(mod, &PyId___spec__); if (_PyModuleSpec_IsInitializing(spec)) { PyObject *value = _PyObject_CallMethodIdObjArgs(interp->importlib, &PyId__lock_unlock_module, abs_name, NULL); if (value == NULL) { Py_DECREF(spec); goto error; } Py_DECREF(value); } Py_XDECREF(spec); Issue originally mentioned in issue34572. ---------- components: Interpreter Core messages: 335097 nosy: brett.cannon, eric.snow, ncoghlan, pitrou priority: normal severity: normal stage: needs patch status: open title: PyImport_GetModule() can return partially-initialized module type: behavior versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 12:14:11 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 08 Feb 2019 17:14:11 +0000 Subject: [issue34572] C unpickling bypasses import thread safety In-Reply-To: <1535990001.55.0.56676864532.issue34572@psf.upfronthosting.co.za> Message-ID: <1549646051.36.0.681782940097.issue34572@roundup.psfhosted.org> Antoine Pitrou added the comment: Opened issue35943 for PyImport_GetModule(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 12:15:55 2019 From: report at bugs.python.org (Eric Snow) Date: Fri, 08 Feb 2019 17:15:55 +0000 Subject: [issue34572] C unpickling bypasses import thread safety In-Reply-To: <1535990001.55.0.56676864532.issue34572@psf.upfronthosting.co.za> Message-ID: <1549646155.43.0.267156045126.issue34572@roundup.psfhosted.org> Eric Snow added the comment: Thanks, Antoine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 12:18:15 2019 From: report at bugs.python.org (Eric Snow) Date: Fri, 08 Feb 2019 17:18:15 +0000 Subject: [issue35943] PyImport_GetModule() can return partially-initialized module In-Reply-To: <1549646017.22.0.395154635441.issue35943@roundup.psfhosted.org> Message-ID: <1549646295.37.0.90251061746.issue35943@roundup.psfhosted.org> Eric Snow added the comment: Yeah, that makes sense. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 12:19:40 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 08 Feb 2019 17:19:40 +0000 Subject: [issue35943] PyImport_GetModule() can return partially-initialized module In-Reply-To: <1549646017.22.0.395154635441.issue35943@roundup.psfhosted.org> Message-ID: <1549646380.66.0.222803746914.issue35943@roundup.psfhosted.org> Change by Antoine Pitrou : ---------- nosy: +pablogsal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 12:56:04 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 08 Feb 2019 17:56:04 +0000 Subject: [issue35904] Add statistics.fmean(seq) In-Reply-To: <1549411161.36.0.783593325223.issue35904@roundup.psfhosted.org> Message-ID: <1549648564.54.0.690550451617.issue35904@roundup.psfhosted.org> Raymond Hettinger added the comment: +1 from me as well. I like your count() solution because 1) it gives the same answer for both an iterator and for an iterable 2) it preserves the memory friendly characteristics of iterators, 3), it is still reasonably fast, and 4) the function signature is still simple. My top name preference is "fmean" because I'm used to "isqrt" for integers, "fsqrt" for floats, and "cmath" for complex where the first letter means the type. Incidentally, that is why "fsum" is named with an "f". My second choice is "fastmean" without an underscore. To my ear, "float_mean" is confusing, as if "float" were a verb and "mean" were the direct object, the antonym of "sink_mean" ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 13:35:02 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 08 Feb 2019 18:35:02 +0000 Subject: [issue35889] sqlite3.Row doesn't have useful repr In-Reply-To: <1549112536.04.0.744689521798.issue35889@roundup.psfhosted.org> Message-ID: <1549650902.14.0.398657945613.issue35889@roundup.psfhosted.org> Terry J. Reedy added the comment: Enhancements only go into future versions. This would have the same pluses and minuses as printing dicts in full. I don't know the general feeling about expanding the classes printed out like this, or whether Gerhard is still active. If you don't get responses within a few days, you might try posting to python-ideas list. ---------- nosy: +ghaering, terry.reedy versions: -Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 13:48:50 2019 From: report at bugs.python.org (Neil Schemenauer) Date: Fri, 08 Feb 2019 18:48:50 +0000 Subject: [issue35903] Build of posixshmem.c should probe for required OS functions In-Reply-To: <1549407022.09.0.0256128012498.issue35903@roundup.psfhosted.org> Message-ID: <1549651730.18.0.207898594895.issue35903@roundup.psfhosted.org> Neil Schemenauer added the comment: New changeset 5741c45acf9b0ce22ff0dbf56322fe0ff16cfcfc by Neil Schemenauer in branch 'master': bpo-35903: Use autoconfig to probe for shm_open() and shm_unlink(). (#11765) https://github.com/python/cpython/commit/5741c45acf9b0ce22ff0dbf56322fe0ff16cfcfc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 13:55:31 2019 From: report at bugs.python.org (Neil Schemenauer) Date: Fri, 08 Feb 2019 18:55:31 +0000 Subject: [issue35903] Build of posixshmem.c should probe for required OS functions In-Reply-To: <1549407022.09.0.0256128012498.issue35903@roundup.psfhosted.org> Message-ID: <1549652131.2.0.378662913943.issue35903@roundup.psfhosted.org> Change by Neil Schemenauer : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 13:56:13 2019 From: report at bugs.python.org (Paul Ganssle) Date: Fri, 08 Feb 2019 18:56:13 +0000 Subject: [issue35943] PyImport_GetModule() can return partially-initialized module In-Reply-To: <1549646017.22.0.395154635441.issue35943@roundup.psfhosted.org> Message-ID: <1549652173.67.0.415456907636.issue35943@roundup.psfhosted.org> Change by Paul Ganssle : ---------- nosy: +p-ganssle _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 14:14:21 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 08 Feb 2019 19:14:21 +0000 Subject: [issue35927] Intra-package References Documentation Incomplete In-Reply-To: <1549514310.42.0.442993756904.issue35927@roundup.psfhosted.org> Message-ID: <1549653261.55.0.860418125305.issue35927@roundup.psfhosted.org> Terry J. Reedy added the comment: 3.6 only gets security patches. I cannot comment on relative imports as I never use them, but the absolute imports should work and do for me. I just added to idlelib.idle_test a file a.py containing 'from idlelib.idle_test import htest' and it works find. The idlelib and idle_test __init__.py files are not empty, but that should not make a difference. In fact, many of the test_xyz modules already import from the non-test utility modules in the same directory. The error messsage suggests that you did not put the top level package directory, 'sound', in a directory in sys.path, as you must. What directory contains your sound package and what is your sys.path? I suspect that this should be closed as 'not a bug'. ---------- nosy: +brett.cannon, eric.snow, ncoghlan, terry.reedy versions: +Python 3.7, Python 3.8 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 14:31:01 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 08 Feb 2019 19:31:01 +0000 Subject: [issue35927] Intra-package References Documentation Incomplete In-Reply-To: <1549514310.42.0.442993756904.issue35927@roundup.psfhosted.org> Message-ID: <1549654261.52.0.212780914748.issue35927@roundup.psfhosted.org> Terry J. Reedy added the comment: When reporting problems, copy and paste into the report the complete exception traceback and error message. For import problems, also copy and paste sys.path. If you disagree that this should be closed, please do so. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 15:02:35 2019 From: report at bugs.python.org (Eryk Sun) Date: Fri, 08 Feb 2019 20:02:35 +0000 Subject: [issue35875] Crash by Pandas - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd In-Reply-To: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> Message-ID: <1549656155.31.0.810908116084.issue35875@roundup.psfhosted.org> Eryk Sun added the comment: The access violation (exception code 0xC0000005) occurs in algos.cp36-win_amd64.pyd, which is a Pandas extension module, so I'm closing this issue as third party. You can open an issue with the Pandas project at their GitHub repo: https://github.com/pandas-dev/pandas/issues It will help whoever has to analyze this problem if you include the crash dump file. The default location for dump files is "%LocalAppData%\CrashDumps". In Windows 7 and 10, it should be enabled by default and configured to keep at least the last 10 dump files. Regarding error reporting in Windows 10, the default policy is to not show a user interface. If the Windows Error Reporting service is called, it still executes as before (e.g. saving crash dumps and sending anonymized data to Microsoft), but users won't see a dialog, which for most people is a useless annoyance. If desired, we can show the error-reporting dialog by setting a DWORD value of 0 named "DontShowUI" in either of the following registry keys: HKLM\Software\Microsoft\Windows\Windows Error Reporting HKLM\Software\Policies\Microsoft\Windows\Windows Error Reporting That said, error reporting itself may be disabled, which can be configured by setting the flag SEM_NOGPFAULTERRORBOX in the error mode of the process, thread, or job. (GPFAULT, or "General Protection Fault", is used loosely here to mean an unhandled exception.) It can also be repressed if the process calls SetUnhandledExceptionFilter to set a custom unhandled exception filter that returns either EXCEPTION_EXECUTE_HANDLER or EXCEPTION_CONTINUE_EXECUTION instead of EXCEPTION_CONTINUE_SEARCH. So it may be normal for a particular program to not show the error-reporting dialog. ---------- nosy: +eryksun resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 16:03:19 2019 From: report at bugs.python.org (princebaridi) Date: Fri, 08 Feb 2019 21:03:19 +0000 Subject: [issue35944] Python 3.7 install error Message-ID: <1549659797.94.0.56697514118.issue35944@roundup.psfhosted.org> New submission from princebaridi : win10 x64 bit machine. looks like msi installer error/ ---------- components: Installation files: Python 3.7.2 (64-bit)_20190208145004_000_core_JustForMe.log messages: 335107 nosy: lasonjack priority: normal severity: normal status: open title: Python 3.7 install error type: crash versions: Python 3.7 Added file: https://bugs.python.org/file48128/Python 3.7.2 (64-bit)_20190208145004_000_core_JustForMe.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 16:13:05 2019 From: report at bugs.python.org (Zachary Ware) Date: Fri, 08 Feb 2019 21:13:05 +0000 Subject: [issue35944] Python 3.7 install error In-Reply-To: <1549659797.94.0.56697514118.issue35944@roundup.psfhosted.org> Message-ID: <1549660385.01.0.588992109335.issue35944@roundup.psfhosted.org> Change 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 Fri Feb 8 16:16:18 2019 From: report at bugs.python.org (Nic Watson) Date: Fri, 08 Feb 2019 21:16:18 +0000 Subject: [issue35945] Cannot distinguish between subtask cancellation and running task cancellation Message-ID: <1549660576.62.0.347711337086.issue35945@roundup.psfhosted.org> New submission from Nic Watson : Goal: to distinguish inside a CancelledError exception handler whether the current running task is being cancelled, or another task that the current task is pending on was cancelled. Example: import asyncio async def task2func(): await asyncio.sleep(2) async def task1func(task2): try: await task2 except asyncio.CancelledError: print("I don't know if I got cancelled") async def main(): loop = asyncio.get_event_loop() task2 = loop.create_task(task2func()) task1 = loop.create_task(task1func(task2)) await asyncio.sleep(0.5) print('Cancelling first task') task1.cancel() await task1 await asyncio.sleep(0.5) task2 = loop.create_task(task2func()) task1 = loop.create_task(task1func(task2)) await asyncio.sleep(0.5) print('Cancelling second task') task2.cancel() await task1 asyncio.run(main()) If I have a task1 waiting on a task2, there's no public method (that I can tell) available in the task1func exception handler to distinguish between whether task1 or task2 were cancelled. There is an internal field task_must_cancel in the C task struct that could be used to interrogate one's own current task to see if it is being cancelled. It is not available from Python (without ctypes hacking). The Python implementation's equivalent is called _must_cancel. (I'm not sure it is a good idea to export this from an API design perspective, but it does mean a mechanism exists.) A workaround is that one can explicitly add attributes to the Python task object to communicate that a task is *starting to* be cancelled. This field would have the same purpose as the task_must_cancel field. ---------- components: asyncio messages: 335108 nosy: asvetlov, jnwatson, yselivanov priority: normal severity: normal status: open title: Cannot distinguish between subtask cancellation and running task cancellation versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 16:20:07 2019 From: report at bugs.python.org (epiphyte) Date: Fri, 08 Feb 2019 21:20:07 +0000 Subject: [issue35945] Cannot distinguish between subtask cancellation and running task cancellation In-Reply-To: <1549660576.62.0.347711337086.issue35945@roundup.psfhosted.org> Message-ID: <1549660807.72.0.463669143577.issue35945@roundup.psfhosted.org> Change by epiphyte : ---------- nosy: +epiphyte _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 16:29:52 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 08 Feb 2019 21:29:52 +0000 Subject: [issue35944] Python 3.7 install error In-Reply-To: <1549659797.94.0.56697514118.issue35944@roundup.psfhosted.org> Message-ID: <1549661392.69.0.0278151878099.issue35944@roundup.psfhosted.org> Steve Dower added the comment: That looks like an incomplete log. Do you have the log file without "000_core_JustForMe" at the end of the name? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 16:36:36 2019 From: report at bugs.python.org (princebaridi) Date: Fri, 08 Feb 2019 21:36:36 +0000 Subject: [issue35944] Python 3.7 install error In-Reply-To: <1549659797.94.0.56697514118.issue35944@roundup.psfhosted.org> Message-ID: <1549661796.76.0.0814855494263.issue35944@roundup.psfhosted.org> princebaridi added the comment: sure sorry ---------- Added file: https://bugs.python.org/file48129/Python 3.7.2 (64-bit)_20190208145004.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 16:55:59 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 08 Feb 2019 21:55:59 +0000 Subject: [issue35944] Python 3.7 install error In-Reply-To: <1549659797.94.0.56697514118.issue35944@roundup.psfhosted.org> Message-ID: <1549662959.92.0.504471114786.issue35944@roundup.psfhosted.org> Steve Dower added the comment: It seems to think the install has been deleted between extracting/verifying it and launching the installer. Do you have any antivirus running that you could disable? Those can sometimes interfere like this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 17:15:09 2019 From: report at bugs.python.org (Mark Forrer) Date: Fri, 08 Feb 2019 22:15:09 +0000 Subject: [issue35946] Ambiguous documentation for assert_called_with() Message-ID: <1549664108.48.0.268470561842.issue35946@roundup.psfhosted.org> New submission from Mark Forrer : The documentation for assert_called_with() is ambiguous with regard to the fact that the method only checks the most recent call. This behavior for assert_called_with() is only documented under assert_any_call(), which users are unlikely to read when making quick reference to the documentation. ---------- assignee: docs at python components: Documentation messages: 335112 nosy: chimaerase, docs at python priority: normal severity: normal status: open title: Ambiguous documentation for assert_called_with() versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 17:37:41 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Fri, 08 Feb 2019 22:37:41 +0000 Subject: [issue35946] Ambiguous documentation for assert_called_with() In-Reply-To: <1549664108.48.0.268470561842.issue35946@roundup.psfhosted.org> Message-ID: <1549665461.42.0.71572774798.issue35946@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- keywords: +patch pull_requests: +11800 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 17:37:44 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Fri, 08 Feb 2019 22:37:44 +0000 Subject: [issue35946] Ambiguous documentation for assert_called_with() In-Reply-To: <1549664108.48.0.268470561842.issue35946@roundup.psfhosted.org> Message-ID: <1549665464.81.0.268938158471.issue35946@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- keywords: +patch, patch pull_requests: +11800, 11801 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 17:37:48 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Fri, 08 Feb 2019 22:37:48 +0000 Subject: [issue35946] Ambiguous documentation for assert_called_with() In-Reply-To: <1549664108.48.0.268470561842.issue35946@roundup.psfhosted.org> Message-ID: <1549665468.36.0.355221707737.issue35946@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- keywords: +patch, patch, patch pull_requests: +11800, 11801, 11802 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 17:39:09 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 08 Feb 2019 22:39:09 +0000 Subject: [issue35904] Add statistics.fmean(seq) In-Reply-To: <1549411161.36.0.783593325223.issue35904@roundup.psfhosted.org> Message-ID: <1549665549.17.0.206021177416.issue35904@roundup.psfhosted.org> Raymond Hettinger added the comment: Would you like me to submit a PR with docs and tests? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 17:39:20 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Fri, 08 Feb 2019 22:39:20 +0000 Subject: [issue35946] Ambiguous documentation for assert_called_with() In-Reply-To: <1549664108.48.0.268470561842.issue35946@roundup.psfhosted.org> Message-ID: <1549665560.43.0.0793436216434.issue35946@roundup.psfhosted.org> R?mi Lapeyre added the comment: Hi Mark Forrer, I opened a new PR to add this precision to assert_called_with documentation. ---------- nosy: +remi.lapeyre versions: +Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 17:40:47 2019 From: report at bugs.python.org (Paul Monson) Date: Fri, 08 Feb 2019 22:40:47 +0000 Subject: [issue35947] Update libffi_msvc to current version of libffi Message-ID: <1549665646.45.0.12391127948.issue35947@roundup.psfhosted.org> New submission from Paul Monson : libffi needs to be updated to the current version for Windows builds to make it easier to add ARM support ---------- components: Windows, ctypes messages: 335115 nosy: Paul Monson, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Update libffi_msvc to current version of libffi type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 17:42:59 2019 From: report at bugs.python.org (Paul Monson) Date: Fri, 08 Feb 2019 22:42:59 +0000 Subject: [issue35948] update version of libffi in cpython-sources-dep Message-ID: <1549665777.79.0.514593871654.issue35948@roundup.psfhosted.org> New submission from Paul Monson : libffi needs to be updated to the current version for Windows builds to make it easier to add ARM support ---------- components: Windows, ctypes messages: 335116 nosy: Paul Monson, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: update version of libffi in cpython-sources-dep type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 18:12:59 2019 From: report at bugs.python.org (Martin Panter) Date: Fri, 08 Feb 2019 23:12:59 +0000 Subject: [issue35928] socket makefile read-write discards received data In-Reply-To: <1549542632.16.0.548779418887.issue35928@roundup.psfhosted.org> Message-ID: <1549667579.5.0.379583614473.issue35928@roundup.psfhosted.org> Martin Panter added the comment: Looking over the changelog, my guess (untested) is this is caused by commit d6a283b3 for Issue 25862. That change looks like it drops the internal TextIOWrapper decoding buffer for each successful write. I don't have the right version of Python to test with, but I expect this to also be broken without using a socket: >>> f = TextIOWrapper(BufferedRWPair(BytesIO(b"Hello\nYou\n"), BytesIO())) >>> f.readline() 'Hello\n' >>> f.write(_) 6 >>> f.readline() # Does this now return EOF? 'You\n' ---------- keywords: +3.6regression nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 18:20:42 2019 From: report at bugs.python.org (Martin Panter) Date: Fri, 08 Feb 2019 23:20:42 +0000 Subject: [issue25862] TextIOWrapper assertion failure after read() and SEEK_CUR In-Reply-To: <1450143790.74.0.198268951027.issue25862@psf.upfronthosting.co.za> Message-ID: <1549668042.4.0.186347555204.issue25862@roundup.psfhosted.org> Martin Panter added the comment: I haven?t confirmed, but it looks like the original change here broke bidirectional reading and writing with a single TextIOWrapper object; see Issue 35928. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 18:25:29 2019 From: report at bugs.python.org (Martin Panter) Date: Fri, 08 Feb 2019 23:25:29 +0000 Subject: [issue22347] mimetypes.guess_type("//example.com") misinterprets host name as file name In-Reply-To: <1409971957.28.0.64915967452.issue22347@psf.upfronthosting.co.za> Message-ID: <1549668329.08.0.397331680381.issue22347@roundup.psfhosted.org> Change by Martin Panter : ---------- dependencies: +Remove urllib.parse._splittype from mimetypes.guess_type _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 18:53:24 2019 From: report at bugs.python.org (Mark Forrer) Date: Fri, 08 Feb 2019 23:53:24 +0000 Subject: [issue35946] Ambiguous documentation for assert_called_with() In-Reply-To: <1549665560.43.0.0793436216434.issue35946@roundup.psfhosted.org> Message-ID: Mark Forrer added the comment: Thank you R?mi! Thanks, --Mark-- On Fri, Feb 8, 2019 at 2:39 PM R?mi Lapeyre wrote: > > R?mi Lapeyre added the comment: > > Hi Mark Forrer, I opened a new PR to add this precision to > assert_called_with documentation. > > ---------- > nosy: +remi.lapeyre > versions: +Python 3.8 > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 19:21:13 2019 From: report at bugs.python.org (Paul Monson) Date: Sat, 09 Feb 2019 00:21:13 +0000 Subject: [issue35947] Update libffi_msvc to current version of libffi In-Reply-To: <1549665646.45.0.12391127948.issue35947@roundup.psfhosted.org> Message-ID: <1549671673.61.0.395132352679.issue35947@roundup.psfhosted.org> Change by Paul Monson : ---------- keywords: +patch pull_requests: +11803 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 19:21:21 2019 From: report at bugs.python.org (Paul Monson) Date: Sat, 09 Feb 2019 00:21:21 +0000 Subject: [issue35947] Update libffi_msvc to current version of libffi In-Reply-To: <1549665646.45.0.12391127948.issue35947@roundup.psfhosted.org> Message-ID: <1549671681.99.0.600272405352.issue35947@roundup.psfhosted.org> Change by Paul Monson : ---------- keywords: +patch, patch pull_requests: +11803, 11804 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 19:21:32 2019 From: report at bugs.python.org (Paul Monson) Date: Sat, 09 Feb 2019 00:21:32 +0000 Subject: [issue35947] Update libffi_msvc to current version of libffi In-Reply-To: <1549665646.45.0.12391127948.issue35947@roundup.psfhosted.org> Message-ID: <1549671692.48.0.438094633401.issue35947@roundup.psfhosted.org> Change by Paul Monson : ---------- keywords: +patch, patch, patch pull_requests: +11803, 11804, 11806 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 19:21:42 2019 From: report at bugs.python.org (Paul Monson) Date: Sat, 09 Feb 2019 00:21:42 +0000 Subject: [issue35947] Update libffi_msvc to current version of libffi In-Reply-To: <1549665646.45.0.12391127948.issue35947@roundup.psfhosted.org> Message-ID: <1549671702.46.0.57714800984.issue35947@roundup.psfhosted.org> Change by Paul Monson : ---------- keywords: +patch, patch, patch, patch pull_requests: +11803, 11804, 11805, 11806 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 20:14:43 2019 From: report at bugs.python.org (Eric Snow) Date: Sat, 09 Feb 2019 01:14:43 +0000 Subject: [issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h In-Reply-To: <1549069628.87.0.454232469964.issue35886@roundup.psfhosted.org> Message-ID: <1549674883.34.0.321491130128.issue35886@roundup.psfhosted.org> Eric Snow added the comment: @Victor, do you see any problems with doing this? It will help simplify other changes I'm working on. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 20:25:00 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 09 Feb 2019 01:25:00 +0000 Subject: [issue35948] update version of libffi in cpython-sources-dep In-Reply-To: <1549665777.79.0.514593871654.issue35948@roundup.psfhosted.org> Message-ID: <1549675500.9.0.108953269665.issue35948@roundup.psfhosted.org> Steve Dower added the comment: This is complete. Right now it's a straight merge from the libffi repo, as we want to be on their latest to help resolve any remaining bugs. Once they make a stable release, we can snap to that. ---------- assignee: -> steve.dower resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 20:45:42 2019 From: report at bugs.python.org (Eric Snow) Date: Sat, 09 Feb 2019 01:45:42 +0000 Subject: [issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h In-Reply-To: <1549069628.87.0.454232469964.issue35886@roundup.psfhosted.org> Message-ID: <1549676742.11.0.0838036245154.issue35886@roundup.psfhosted.org> Change by Eric Snow : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 21:00:20 2019 From: report at bugs.python.org (Eric Snow) Date: Sat, 09 Feb 2019 02:00:20 +0000 Subject: [issue35949] Move PyThreadState into Include/internal/pycore_pystate.h Message-ID: <1549677619.84.0.322696563838.issue35949@roundup.psfhosted.org> New submission from Eric Snow : (also see issue #35886) In November Victor created the Include/cpython directory and moved a decent amount of public (but not limited) API there. This included the PyThreadState struct. I'd like to move it into the "internal" headers since it is somewhat coupled to the internal runtime implementation. The alternative is extra complexity. I ran into this while working on another issue. There are 2 problems, however, with PyThreadState which make a move potentially challenging. In fact, they could be (but probably aren't) cause for moving it back to Include/pystate.h. 1. the docs say: "The only public data member is PyInterpreterState *interp, which points to this thread?s interpreter state." 2. the struct has 6 fields that are exposed (likely unintentionally) in "stable" header files via the following macros: # Include/object.h Py_TRASHCAN_SAFE_BEGIN Py_TRASHCAN_SAFE_END Include.ceval.h Py_EnterRecursiveCall Py_LeaveRecursiveCall _Py_MakeRecCheck Py_ALLOW_RECURSION Py_END_ALLOW_RECURSION I'm not sure how that factors into the stable ABI (PyThreadState wasn't ever guarded by Py_LIMITED_API). However, keep in mind that Victor already moved PyThreadState out of the "stable" headers in November. I'm fine with sorting out the situation with the macros if that's okay to do. Likewise the promised field ("interp") should be solvable one way or another (e.g. remove it or use a private struct). ...or we could do nothing or (if the change in Novemver is a problem) move it back to Include/pystate.h. ---------- components: Interpreter Core messages: 335122 nosy: eric.snow, ncoghlan, vstinner priority: normal severity: normal status: open title: Move PyThreadState into Include/internal/pycore_pystate.h type: behavior versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 21:15:26 2019 From: report at bugs.python.org (Dong-hee Na) Date: Sat, 09 Feb 2019 02:15:26 +0000 Subject: [issue22347] mimetypes.guess_type("//example.com") misinterprets host name as file name In-Reply-To: <1409971957.28.0.64915967452.issue22347@psf.upfronthosting.co.za> Message-ID: <1549678526.31.0.341779138812.issue22347@roundup.psfhosted.org> Dong-hee Na added the comment: The proposed patch I mentioned on bpo-35939 also solve the above situation. Python 3.8.0a1+ (heads/bpo-12317:96d37dbcd2, Feb 8 2019, 12:03:40) [Clang 9.1.0 (clang-902.0.39.1)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mimetypes >>> mimetypes.guess_type("http://example.com") (None, None) >>> mimetypes.guess_type("example.com") ('application/x-msdownload', None) >>> I've also added the unit tests of mimetypes-host.patch. It works well. I think that we close this issue also when the bpo-35939 is closed. Thanks alot! ---------- nosy: +corona10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 21:16:14 2019 From: report at bugs.python.org (Dong-hee Na) Date: Sat, 09 Feb 2019 02:16:14 +0000 Subject: [issue35939] Remove urllib.parse._splittype from mimetypes.guess_type In-Reply-To: <1549613683.87.0.509050815243.issue35939@roundup.psfhosted.org> Message-ID: <1549678574.44.0.556042632273.issue35939@roundup.psfhosted.org> Change by Dong-hee Na : ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 21:19:48 2019 From: report at bugs.python.org (Dong-hee Na) Date: Sat, 09 Feb 2019 02:19:48 +0000 Subject: [issue22347] mimetypes.guess_type("//example.com") misinterprets host name as file name In-Reply-To: <1409971957.28.0.64915967452.issue22347@psf.upfronthosting.co.za> Message-ID: <1549678788.81.0.830564417285.issue22347@roundup.psfhosted.org> Change by Dong-hee Na : ---------- versions: +Python 3.7, Python 3.8 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 22:16:18 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 09 Feb 2019 03:16:18 +0000 Subject: [issue35833] IDLE: revise doc for control chars sent to Shell In-Reply-To: <1548514370.87.0.460753518023.issue35833@roundup.psfhosted.org> Message-ID: <1549682178.41.0.781352612842.issue35833@roundup.psfhosted.org> Change by Terry J. Reedy : ---------- keywords: +patch pull_requests: +11807 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 22:16:24 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 09 Feb 2019 03:16:24 +0000 Subject: [issue35833] IDLE: revise doc for control chars sent to Shell In-Reply-To: <1548514370.87.0.460753518023.issue35833@roundup.psfhosted.org> Message-ID: <1549682184.53.0.483868884077.issue35833@roundup.psfhosted.org> Change by Terry J. Reedy : ---------- keywords: +patch, patch pull_requests: +11807, 11808 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 22:16:32 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 09 Feb 2019 03:16:32 +0000 Subject: [issue35833] IDLE: revise doc for control chars sent to Shell In-Reply-To: <1548514370.87.0.460753518023.issue35833@roundup.psfhosted.org> Message-ID: <1549682192.12.0.429265988789.issue35833@roundup.psfhosted.org> Change by Terry J. Reedy : ---------- keywords: +patch, patch, patch pull_requests: +11807, 11808, 11809 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 22:52:03 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 09 Feb 2019 03:52:03 +0000 Subject: [issue35833] IDLE: revise doc for control chars sent to Shell In-Reply-To: <1548514370.87.0.460753518023.issue35833@roundup.psfhosted.org> Message-ID: <1549684316.07.0.23383416006.issue35833@roundup.psfhosted.org> Terry J. Reedy added the comment: New changeset 8a03ff2ff4db973c9fe152561f1796e72cb71132 by Terry Jan Reedy in branch 'master': bpo-35833: Revise IDLE doc for control codes sent to Shell. (GH-11799) https://github.com/python/cpython/commit/8a03ff2ff4db973c9fe152561f1796e72cb71132 ---------- pull_requests: +11810 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 22:52:05 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 09 Feb 2019 03:52:05 +0000 Subject: [issue35833] IDLE: revise doc for control chars sent to Shell In-Reply-To: <1548514370.87.0.460753518023.issue35833@roundup.psfhosted.org> Message-ID: <1549684325.69.0.330143431266.issue35833@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11810, 11811 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 22:51:56 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 09 Feb 2019 03:51:56 +0000 Subject: [issue35833] IDLE: revise doc for control chars sent to Shell In-Reply-To: <1548514370.87.0.460753518023.issue35833@roundup.psfhosted.org> Message-ID: <1549684316.07.0.23383416006.issue35833@roundup.psfhosted.org> Terry J. Reedy added the comment: New changeset 8a03ff2ff4db973c9fe152561f1796e72cb71132 by Terry Jan Reedy in branch 'master': bpo-35833: Revise IDLE doc for control codes sent to Shell. (GH-11799) https://github.com/python/cpython/commit/8a03ff2ff4db973c9fe152561f1796e72cb71132 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 23:43:23 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 09 Feb 2019 04:43:23 +0000 Subject: [issue35833] IDLE: revise doc for control chars sent to Shell In-Reply-To: <1548514370.87.0.460753518023.issue35833@roundup.psfhosted.org> Message-ID: <1549687403.61.0.941637794628.issue35833@roundup.psfhosted.org> miss-islington added the comment: New changeset 3fcfef357e64a25afd52ec6a0d1b5284cb162203 by Miss Islington (bot) in branch '3.7': bpo-35833: Revise IDLE doc for control codes sent to Shell. (GH-11799) https://github.com/python/cpython/commit/3fcfef357e64a25afd52ec6a0d1b5284cb162203 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 23:44:06 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 09 Feb 2019 04:44:06 +0000 Subject: [issue35833] IDLE: revise doc for control chars sent to Shell In-Reply-To: <1548514370.87.0.460753518023.issue35833@roundup.psfhosted.org> Message-ID: <1549687446.92.0.263517810732.issue35833@roundup.psfhosted.org> Change by Terry J. Reedy : ---------- pull_requests: -11809 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 23:44:24 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 09 Feb 2019 04:44:24 +0000 Subject: [issue35833] IDLE: revise doc for control chars sent to Shell In-Reply-To: <1548514370.87.0.460753518023.issue35833@roundup.psfhosted.org> Message-ID: <1549687464.39.0.0299459928703.issue35833@roundup.psfhosted.org> Change by Terry J. Reedy : ---------- pull_requests: -11808 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 23:44:43 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 09 Feb 2019 04:44:43 +0000 Subject: [issue35833] IDLE: revise doc for control chars sent to Shell In-Reply-To: <1548514370.87.0.460753518023.issue35833@roundup.psfhosted.org> Message-ID: <1549687483.62.0.0262637932665.issue35833@roundup.psfhosted.org> Change by Terry J. Reedy : ---------- pull_requests: -11811 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 8 23:45:12 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 09 Feb 2019 04:45:12 +0000 Subject: [issue35833] IDLE: revise doc for control chars sent to Shell In-Reply-To: <1548514370.87.0.460753518023.issue35833@roundup.psfhosted.org> Message-ID: <1549687512.17.0.466519109517.issue35833@roundup.psfhosted.org> Change by Terry J. Reedy : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 9 01:16:22 2019 From: report at bugs.python.org (ADataGman) Date: Sat, 09 Feb 2019 06:16:22 +0000 Subject: [issue35927] Intra-package References Documentation Incomplete In-Reply-To: <1549654261.52.0.212780914748.issue35927@roundup.psfhosted.org> Message-ID: ADataGman added the comment: Here's the full error log I receive when using the code I submitted with both ..effects and sound.effects. It also includes a print out of the sys path as run from vocoder. I tried running this in 3.7.2 and still get the same errors. It seems like it's already on the sys path? I'm not saying there is a bug in python itself, it's just not at all clear from the documentation that what is described as being a way to access sibling packages actually works. Given the attached code sample, as a newb I'd greatly appreciate an example of how to take that sample and turn it into functioning code with whatever modifiers is necessary. Ultimately whatever changes are made I'd like to see reflected in the documentation for the intra-reference section. PS C:\sound> & C:/Users/user/AppData/Local/Programs/Python/Python37/python.exe c:/sound/filters/vocoder.py Traceback (most recent call last): File "c:/sound/filters/vocoder.py", line 7, in vocoder.pp() File "c:/sound/filters/vocoder.py", line 4, in pp from ..effects import echo ValueError: attempted relative import beyond top-level package PS C:\sound> & C:/Users/user/AppData/Local/Programs/Python/Python37/python.exe c:/sound/filters/vocoder.py Traceback (most recent call last): File "c:/sound/filters/vocoder.py", line 7, in vocoder.pp() File "c:/sound/filters/vocoder.py", line 4, in pp from sound.effects import echo ModuleNotFoundError: No module named 'sound' PS C:\sound> & C:/Users/user/AppData/Local/Programs/Python/Python37/python.exe c:/sound/filters/vocoder.py ['c:\\sound\\filters', 'C:\\Users\\user\\AppData\\Local\\Programs\\Python\\Python37\\python37.zip', 'C:\\Users\\user\\AppData\\Local\\Programs\\Python\\Python37\\DLLs', 'C:\\Users\\user\\AppData\\Local\\Programs\\Python\\Python37\\lib', 'C:\\Users\\user\\AppData\\Local\\Programs\\Python\\Python37', 'C:\\Users\\user\\AppData\\Roaming\\Python\\Python37\\site-packages', 'C:\\Users\\user\\AppData\\Local\\Programs\\Python\\Python37\\lib\\site-packages'] On Fri, Feb 8, 2019 at 2:31 PM Terry J. Reedy wrote: > > Terry J. Reedy added the comment: > > When reporting problems, copy and paste into the report the complete > exception traceback and error message. For import problems, also copy and > paste sys.path. If you disagree that this should be closed, please do so. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 9 03:00:46 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Sat, 09 Feb 2019 08:00:46 +0000 Subject: [issue21625] help()'s more-mode is frustrating In-Reply-To: <1401624278.41.0.968851571107.issue21625@psf.upfronthosting.co.za> Message-ID: <1549699246.15.0.946058407253.issue21625@roundup.psfhosted.org> Change by Steven D'Aprano : ---------- nosy: +steven.daprano versions: +Python 3.8 -Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 9 03:05:46 2019 From: report at bugs.python.org (Bangert) Date: Sat, 09 Feb 2019 08:05:46 +0000 Subject: [issue35875] Crash by Pandas - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd In-Reply-To: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> Message-ID: <1549699546.15.0.332379834985.issue35875@roundup.psfhosted.org> Bangert added the comment: yes OK - thank you very much ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 9 03:15:19 2019 From: report at bugs.python.org (Bangert) Date: Sat, 09 Feb 2019 08:15:19 +0000 Subject: [issue35875] Crash by Pandas - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd In-Reply-To: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> Message-ID: <1549700119.71.0.00269296427951.issue35875@roundup.psfhosted.org> Bangert added the comment: So the solution is: If you don't need algos then comment it out C:\A-Cond-3-64\envs\TensorflowCpu\Lib\site-packages\pandas\_libs\algos.cp36-win_amd64.pyd The sequence crash of the join extension only depends on algos and is gone if you comment out algos in Win7 and Win10. Best regards Axel Arnold Bangert - Herzogenrath 09.02.2019 ---------- Added file: https://bugs.python.org/file48130/Algos-Commented-Out-Crash-Popup-Win7-Win10-RWTH-SAP.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 9 03:26:35 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 09 Feb 2019 08:26:35 +0000 Subject: [issue35904] Add statistics.fmean(seq) In-Reply-To: <1549411161.36.0.783593325223.issue35904@roundup.psfhosted.org> Message-ID: <1549700795.1.0.541418074216.issue35904@roundup.psfhosted.org> Raymond Hettinger added the comment: FWIW, fabs() and fmod() are other examples of where "f" indicates a function specialized to convert inputs to floats, perform floating point math, and return a float. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 9 05:26:13 2019 From: report at bugs.python.org (Bangert) Date: Sat, 09 Feb 2019 10:26:13 +0000 Subject: [issue35875] Crash by Pandas - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd In-Reply-To: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> Message-ID: <1549707973.11.0.485183943776.issue35875@roundup.psfhosted.org> Bangert added the comment: Yes I wanted to upload the crash dump files at the beginning of the session but your upload size restriction does not allow this ---------- Added file: https://bugs.python.org/file48131/Crash-Dump-Files-Win7-RWTH-SAP1-Size-Too-Large-For-Upload-To-PythonBugs.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 9 06:39:34 2019 From: report at bugs.python.org (Ma Lin) Date: Sat, 09 Feb 2019 11:39:34 +0000 Subject: [issue35859] Capture behavior depends on the order of an alternation In-Reply-To: <1548857774.3.0.1614070954.issue35859@roundup.psfhosted.org> Message-ID: <1549712374.8.0.845069487526.issue35859@roundup.psfhosted.org> Ma Lin added the comment: For a capture group, state->mark[] array stores it's begin and end: begin: state->mark[(group_number-1)*2] end: state->mark[(group_number-1)*2+1] So state->mark[0] is the begin of the first capture group. state->mark[1] is the end of the first capture group. re.search(r'(ab|a)*?b', 'ab') In this case, here is a simplified actions record: 01 MARK 0 02 "a": first "a" in the pattern [SUCCESS] 03 BRANCH 04 "b": first "b" in the pattern [SUCCESS] 05 MARK 1 06 "b": second "b" in the pattern [FAIL] 07 try next (ab|a)*? [FAIL] 08 MARK 0 09 "a": first "a" in the pattern [FAIL] 10 BRANCH: try next branch 11 "": the second branch [SUCCESS] 12 MARK 1 13 "b" [SUCCESS]: second "b" in the pattern MARK_PUSH(lastmark) macro didn't protect MARK-0 if it was the only available mark, while the BRANCH op uses this macro to protect capture groups before trying a branch. So capture group 1 is [MARK-0 at Line-08, MARK-1 at line-12), this is wrong. The correct capture group 1 should be [MARK-0 at Line-01, MARK-1 at line-12). ---------- versions: +Python 3.7, Python 3.8 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 9 07:58:51 2019 From: report at bugs.python.org (Eric N. Vander Weele) Date: Sat, 09 Feb 2019 12:58:51 +0000 Subject: [issue35912] _testembed.c fails to compile when using --with-cxx-main in the configure step In-Reply-To: <1549464332.95.0.70522769189.issue35912@roundup.psfhosted.org> Message-ID: <1549717131.35.0.103275722448.issue35912@roundup.psfhosted.org> Change by Eric N. Vander Weele : ---------- nosy: +ericvw _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 9 08:34:43 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Sat, 09 Feb 2019 13:34:43 +0000 Subject: [issue35912] _testembed.c fails to compile when using --with-cxx-main in the configure step In-Reply-To: <1549464332.95.0.70522769189.issue35912@roundup.psfhosted.org> Message-ID: <1549719283.46.0.0844289839248.issue35912@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 9 08:36:24 2019 From: report at bugs.python.org (Steve Palmer) Date: Sat, 09 Feb 2019 13:36:24 +0000 Subject: [issue35950] io.BufferedReader.writabe is False, but io.BufferedReader.truncate does not raise OSError Message-ID: <1549719382.2.0.923720230511.issue35950@roundup.psfhosted.org> New submission from Steve Palmer : An io.BUfferedReader object has an (inherited) writable method that returns False. io.IOBase states in the description of the writable method that "If False, write() and truncate() will raise OSError." However, if the BufferedReader object is constructed from a writabe io.RawIOBase object, then the truncate does not raise the exception. >>> import io >>> import tempfile >>> rf = tempfile.TemporaryFile(buffering=0) >>> rf <_io.FileIO name=3 mode='rb+' closefd=True> >>> bf = io.BufferedReader(rf) >>> bf.writable() False >>> bf.truncate(0) 0 Looking at _pyio.py file, the truncate method in the _BufferedIOMixin wrapper class delegates the truncation to it's raw attribute. If the raw element permits the truncation, then it will proceed regardless of the writable state of the wrapper class. I'd suggest that modifying the truncate method in _BufferedIOMixin to raise OSError (or Unsupported) if not self.writable() could fix this problem. ---------- components: IO messages: 335132 nosy: steverpalmer priority: normal severity: normal status: open title: io.BufferedReader.writabe is False, but io.BufferedReader.truncate does not raise OSError versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 9 08:38:09 2019 From: report at bugs.python.org (Steve Palmer) Date: Sat, 09 Feb 2019 13:38:09 +0000 Subject: [issue35950] io.BufferedReader.writabe is False, but io.BufferedReader.truncate does not raise OSError In-Reply-To: <1549719382.2.0.923720230511.issue35950@roundup.psfhosted.org> Message-ID: <1549719489.59.0.11322666008.issue35950@roundup.psfhosted.org> Change by Steve Palmer : ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 9 10:40:41 2019 From: report at bugs.python.org (Bob Kline) Date: Sat, 09 Feb 2019 15:40:41 +0000 Subject: [issue34028] Python 3.7.0 wont compile with SSL Support 1.1.0 > alledged missing X509_VERIFY_PARAM_set1_host() support In-Reply-To: <1530609211.5.0.56676864532.issue34028@psf.upfronthosting.co.za> Message-ID: <1549726841.39.0.635067176488.issue34028@roundup.psfhosted.org> Bob Kline added the comment: I had to add $HOME/usr/lib64 to LD_LIBRARY_PATH to get make to work. ---------- nosy: +bkline _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 9 11:49:09 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Sat, 09 Feb 2019 16:49:09 +0000 Subject: [issue35940] multiprocessing manager tests fail in the Refleaks buildbots In-Reply-To: <1549634808.3.0.556124260005.issue35940@roundup.psfhosted.org> Message-ID: <1549730949.02.0.318312866728.issue35940@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- keywords: +patch pull_requests: +11812 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 9 11:49:14 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Sat, 09 Feb 2019 16:49:14 +0000 Subject: [issue35940] multiprocessing manager tests fail in the Refleaks buildbots In-Reply-To: <1549634808.3.0.556124260005.issue35940@roundup.psfhosted.org> Message-ID: <1549730954.52.0.0104159006263.issue35940@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- keywords: +patch, patch pull_requests: +11812, 11813 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 9 11:49:18 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Sat, 09 Feb 2019 16:49:18 +0000 Subject: [issue35940] multiprocessing manager tests fail in the Refleaks buildbots In-Reply-To: <1549634808.3.0.556124260005.issue35940@roundup.psfhosted.org> Message-ID: <1549730958.66.0.97296194136.issue35940@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- keywords: +patch, patch, patch pull_requests: +11812, 11813, 11814 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 9 11:58:24 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Sat, 09 Feb 2019 16:58:24 +0000 Subject: [issue35808] Let's retire pgen In-Reply-To: <1548221537.82.0.492786218381.issue35808@roundup.psfhosted.org> Message-ID: <1549731504.0.0.904720048187.issue35808@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- nosy: +pablogsal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 9 12:10:44 2019 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 09 Feb 2019 17:10:44 +0000 Subject: [issue35951] os.renames() creates directories if original name doesn't exist Message-ID: <1549732242.93.0.821054504106.issue35951@roundup.psfhosted.org> New submission from Chris Jerdonek : os.renames() creates and leaves behind the intermediate directories if the original (source) path doesn't exist. >>> import os >>> os.mkdir('temp') >>> os.mkdir('temp/test') >>> os.renames('temp/not-exists', 'temp/test2/test3/test4') Traceback (most recent call last): File "", line 1, in File "/.../3.6.5/lib/python3.6/os.py", line 267, in renames rename(old, new) FileNotFoundError: [Errno 2] No such file or directory: 'temp/not-exists' -> 'temp/test2/test3/test4' >>> os.listdir('temp/test2') ['test3'] >>> os.listdir('temp/test2/test3') [] ---------- components: Library (Lib) messages: 335134 nosy: chris.jerdonek priority: normal severity: normal status: open title: os.renames() creates directories if original name doesn't exist type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 9 12:50:06 2019 From: report at bugs.python.org (Paul Ganssle) Date: Sat, 09 Feb 2019 17:50:06 +0000 Subject: =?utf-8?b?W2lzc3VlMzUzNjRdIERhdGV0aW1lIOKAnGZyb210aW1lc3RhbXAoKeKAnSBp?= =?utf-8?q?gnores_inheritance_if_timezone_is_not_None?= In-Reply-To: <1543598741.31.0.788709270274.issue35364@psf.upfronthosting.co.za> Message-ID: <1549734606.93.0.624276139994.issue35364@roundup.psfhosted.org> Paul Ganssle added the comment: This issue and bpo-32417 can be closed now, as they are fixed on master. ---------- versions: +Python 3.8 -Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 9 13:13:06 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sat, 09 Feb 2019 18:13:06 +0000 Subject: [issue21269] Provide args and kwargs attributes on mock call objects In-Reply-To: <1397681262.54.0.610859323151.issue21269@psf.upfronthosting.co.za> Message-ID: <1549735986.83.0.65098340676.issue21269@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: args and kwargs property can be introduced on the call object to return the args and kwargs stored in the tuple. Currently wrapping call object with tuple can get a tuple of args and kwargs but a property would be helpful. A first attempt patch on this. Feedback on the API would be helpful. $ ./python.exe Python 3.8.0a1+ (heads/master:8a03ff2ff4, Feb 9 2019, 10:42:29) [Clang 7.0.2 (clang-700.1.81)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from unittest.mock import Mock >>> m = Mock() >>> m(1, a=1) >>> m.call_args_list[0] call(1, a=1) >>> tuple(m.call_args_list[0]) # wrapping it with tuple can give args and kwargs currently ((1,), {'a': 1}) >>> m.call_args_list[0].args # With patch return args (1,) >>> m.call_args_list[0].kwargs # With patch return kwargs {'a': 1} A simple patch would be as below : ? cpython git:(master) ? git diff | cat diff --git a/Lib/unittest/mock.py b/Lib/unittest/mock.py index ef5c55d6a1..ef1aa1dcea 100644 --- a/Lib/unittest/mock.py +++ b/Lib/unittest/mock.py @@ -2124,6 +2124,24 @@ class _Call(tuple): def index(self, *args, **kwargs): return self.__getattr__('index')(*args, **kwargs) + @property + def args(self): + if len(self) == 2: + args, kwargs = self + else: + name, args, kwargs = self + + return args + + @property + def kwargs(self): + if len(self) == 2: + args, kwargs = self + else: + name, args, kwargs = self + + return kwargs + def __repr__(self): if not self._mock_from_kall: name = self._mock_name or 'call' ---------- nosy: +cjw296, xtreak versions: +Python 3.8 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 9 14:27:09 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Sat, 09 Feb 2019 19:27: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: <1549740429.16.0.938312409992.issue16353@roundup.psfhosted.org> Cheryl Sabella added the comment: 3.7 added `sys.getandroidapilevel()` under #28740. As Xavier mentioned in msg271439, that was used for subprocess.Popen in #16255 and also merged as part of 3.7. I'm not sure if there is still interest in adding a `default_shell` to the os module using `sys.androidapilevel()` and the last batch that Xavier uploaded in 2016. ---------- nosy: +cheryl.sabella _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 9 14:41:25 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 09 Feb 2019 19:41:25 +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: <1549741285.87.0.371944916891.issue16353@roundup.psfhosted.org> Antoine Pitrou added the comment: I think the functionality of getting either the system-wide default shell or the current user's default shell can be useful regardless of whether the specific subprocess issue was fixed. ---------- nosy: +ncoghlan stage: patch review -> needs patch versions: +Python 3.8 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 9 16:06:07 2019 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 09 Feb 2019 21:06:07 +0000 Subject: [issue35952] test.pythoninfo prints a stack trace and exits with 1 when the compiler does not exist Message-ID: <1549746365.16.0.119204181787.issue35952@roundup.psfhosted.org> New submission from Xavier de Gaye : The call to subprocess.Popen() in collect_cc() of Lib/test/pythoninfo.py raises an exception when the compiler that has been used to build python is not present on the host running python. In that case pythoninfo prints a stack trace and exits with an error. On the other side if the execution of the compiler to get its version fails, the error is silently ignored. It seems the exception should be ignored as well. ---------- components: Library (Lib) messages: 335139 nosy: xdegaye priority: normal severity: normal status: open title: test.pythoninfo prints a stack trace and exits with 1 when the compiler does not exist type: behavior versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 9 16:13:52 2019 From: report at bugs.python.org (Kumar Akshay) Date: Sat, 09 Feb 2019 21:13:52 +0000 Subject: [issue21269] Provide args and kwargs attributes on mock call objects In-Reply-To: <1397681262.54.0.610859323151.issue21269@psf.upfronthosting.co.za> Message-ID: <1549746832.05.0.48543420753.issue21269@roundup.psfhosted.org> Kumar Akshay added the comment: Hey @xtreak, if you're not working on this, can I submit the patch? ---------- nosy: +kakshay _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 9 17:31:28 2019 From: report at bugs.python.org (STINNER Victor) Date: Sat, 09 Feb 2019 22:31:28 +0000 Subject: [issue35875] Crash by Pandas - algos.cp36-win_amd64.pyd join.cp36-win_amd64.pyd In-Reply-To: <1549018346.31.0.580371718902.issue35875@roundup.psfhosted.org> Message-ID: <1549751488.14.0.0683885745281.issue35875@roundup.psfhosted.org> Change by STINNER Victor : ---------- nosy: -vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 9 17:52:41 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Sat, 09 Feb 2019 22:52:41 +0000 Subject: [issue18283] shutil.which() should support bytes In-Reply-To: <1371914951.06.0.665120918364.issue18283@psf.upfronthosting.co.za> Message-ID: <1549752761.75.0.607016355053.issue18283@roundup.psfhosted.org> Cheryl Sabella added the comment: Would it be worthwhile to make a PR of this for 3.8? ---------- nosy: +cheryl.sabella versions: +Python 3.8 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 9 18:41:31 2019 From: report at bugs.python.org (Roundup Robot) Date: Sat, 09 Feb 2019 23:41:31 +0000 Subject: [issue35500] Align expected and actual calls on mock.assert_called_with error message In-Reply-To: <1544813146.35.0.788709270274.issue35500@psf.upfronthosting.co.za> Message-ID: <1549755691.4.0.337958616338.issue35500@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch pull_requests: +11815 stage: test needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 9 18:41:45 2019 From: report at bugs.python.org (Roundup Robot) Date: Sat, 09 Feb 2019 23:41:45 +0000 Subject: [issue35500] Align expected and actual calls on mock.assert_called_with error message In-Reply-To: <1544813146.35.0.788709270274.issue35500@psf.upfronthosting.co.za> Message-ID: <1549755705.94.0.188343656685.issue35500@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch, patch pull_requests: +11815, 11816 stage: test needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 9 18:42:00 2019 From: report at bugs.python.org (Roundup Robot) Date: Sat, 09 Feb 2019 23:42:00 +0000 Subject: [issue35500] Align expected and actual calls on mock.assert_called_with error message In-Reply-To: <1544813146.35.0.788709270274.issue35500@psf.upfronthosting.co.za> Message-ID: <1549755720.94.0.882390063788.issue35500@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch, patch, patch pull_requests: +11815, 11816, 11817 stage: test needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 9 18:42:14 2019 From: report at bugs.python.org (Roundup Robot) Date: Sat, 09 Feb 2019 23:42:14 +0000 Subject: [issue35500] Align expected and actual calls on mock.assert_called_with error message In-Reply-To: <1544813146.35.0.788709270274.issue35500@psf.upfronthosting.co.za> Message-ID: <1549755734.68.0.519273540932.issue35500@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch, patch, patch, patch pull_requests: +11815, 11816, 11817, 11818 stage: test needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 9 20:27:13 2019 From: report at bugs.python.org (Chih-Hsuan Yen) Date: Sun, 10 Feb 2019 01:27:13 +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: <1549762033.07.0.95682297329.issue16353@roundup.psfhosted.org> Change by Chih-Hsuan Yen : ---------- nosy: -yan12125 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 9 21:37:38 2019 From: report at bugs.python.org (Celelibi) Date: Sun, 10 Feb 2019 02:37:38 +0000 Subject: [issue34424] Unicode names break email header In-Reply-To: <1534546922.5.0.56676864532.issue34424@psf.upfronthosting.co.za> Message-ID: <1549766258.8.0.844955422912.issue34424@roundup.psfhosted.org> Change by Celelibi : ---------- nosy: +Celelibi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 01:59:47 2019 From: report at bugs.python.org (Tal Einat) Date: Sun, 10 Feb 2019 06:59:47 +0000 Subject: [issue35500] Align expected and actual calls on mock.assert_called_with error message In-Reply-To: <1544813146.35.0.788709270274.issue35500@psf.upfronthosting.co.za> Message-ID: <1549781987.91.0.721279529969.issue35500@roundup.psfhosted.org> Change by Tal Einat : ---------- pull_requests: -11816 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 02:00:01 2019 From: report at bugs.python.org (Tal Einat) Date: Sun, 10 Feb 2019 07:00:01 +0000 Subject: [issue35500] Align expected and actual calls on mock.assert_called_with error message In-Reply-To: <1544813146.35.0.788709270274.issue35500@psf.upfronthosting.co.za> Message-ID: <1549782001.87.0.514640784163.issue35500@roundup.psfhosted.org> Change by Tal Einat : ---------- pull_requests: -11816, 11817 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 02:00:16 2019 From: report at bugs.python.org (Tal Einat) Date: Sun, 10 Feb 2019 07:00:16 +0000 Subject: [issue35500] Align expected and actual calls on mock.assert_called_with error message In-Reply-To: <1544813146.35.0.788709270274.issue35500@psf.upfronthosting.co.za> Message-ID: <1549782016.95.0.535836737666.issue35500@roundup.psfhosted.org> Change by Tal Einat : ---------- pull_requests: -11816, 11817, 11818 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 02:16:30 2019 From: report at bugs.python.org (Tal Einat) Date: Sun, 10 Feb 2019 07:16:30 +0000 Subject: [issue35500] Align expected and actual calls on mock.assert_called_with error message In-Reply-To: <1544813146.35.0.788709270274.issue35500@psf.upfronthosting.co.za> Message-ID: <1549782990.44.0.105850653447.issue35500@roundup.psfhosted.org> Tal Einat added the comment: Karthikeyan, what do you think of the suggestions by Terry and myself to achieve alignment by replacing the word "Actual" with a longer alternative, such as "Observed" or "Received"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 02:33:39 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sun, 10 Feb 2019 07:33:39 +0000 Subject: [issue35500] Align expected and actual calls on mock.assert_called_with error message In-Reply-To: <1544813146.35.0.788709270274.issue35500@psf.upfronthosting.co.za> Message-ID: <1549784019.48.0.642473566671.issue35500@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: I think "Actual" is more consistent with other error messages like assert_has_calls. I haven't seen usage of observed or received in error messages and hence my opinion on using expected and actual though they are not visually aligned. I don't have a strong opinion on this. I will leave it to the maintainer who wants to merge this change and I am fine as long as the calls are represented on separate lines which is a good improvement over current format. >>> m.assert_has_calls(mock.call(1)) Traceback (most recent call last): File "", line 1, in File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/unittest/mock.py", line 857, in assert_has_calls raise AssertionError( AssertionError: Calls not found. Expected: ['', (1,), {}] Actual: [call(1), call(2)]. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 02:39:49 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sun, 10 Feb 2019 07:39:49 +0000 Subject: [issue21269] Provide args and kwargs attributes on mock call objects In-Reply-To: <1397681262.54.0.610859323151.issue21269@psf.upfronthosting.co.za> Message-ID: <1549784389.64.0.195917454.issue21269@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: @kakshay, I am not working on it so feel free to pick it up. I stumbled upon this while looking into mock issues and I just posted a patch to gather API feedback. I guess it would be helpful if someone confirms it would be a good addition so that there is less rework. Thanks ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 03:17:30 2019 From: report at bugs.python.org (Tal Einat) Date: Sun, 10 Feb 2019 08:17:30 +0000 Subject: [issue35500] Align expected and actual calls on mock.assert_called_with error message In-Reply-To: <1544813146.35.0.788709270274.issue35500@psf.upfronthosting.co.za> Message-ID: <1549786650.18.0.690685290664.issue35500@roundup.psfhosted.org> Tal Einat added the comment: After more thought, I agree that it isn't worth changing the current wording from "Actual" to something else. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 03:49:07 2019 From: report at bugs.python.org (SilentGhost) Date: Sun, 10 Feb 2019 08:49:07 +0000 Subject: [issue35924] curses segfault resizing window In-Reply-To: <1549497741.38.0.310308715457.issue35924@roundup.psfhosted.org> Message-ID: <1549788547.22.0.848107704625.issue35924@roundup.psfhosted.org> Change by SilentGhost : ---------- nosy: +twouters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 04:14:00 2019 From: report at bugs.python.org (Kumar Akshay) Date: Sun, 10 Feb 2019 09:14:00 +0000 Subject: [issue21269] Provide args and kwargs attributes on mock call objects In-Reply-To: <1397681262.54.0.610859323151.issue21269@psf.upfronthosting.co.za> Message-ID: <1549790040.84.0.53536345547.issue21269@roundup.psfhosted.org> Change by Kumar Akshay : ---------- keywords: +patch pull_requests: +11819 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 04:14:09 2019 From: report at bugs.python.org (Kumar Akshay) Date: Sun, 10 Feb 2019 09:14:09 +0000 Subject: [issue21269] Provide args and kwargs attributes on mock call objects In-Reply-To: <1397681262.54.0.610859323151.issue21269@psf.upfronthosting.co.za> Message-ID: <1549790049.84.0.157507857431.issue21269@roundup.psfhosted.org> Change by Kumar Akshay : ---------- keywords: +patch, patch pull_requests: +11819, 11820 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 04:14:18 2019 From: report at bugs.python.org (Kumar Akshay) Date: Sun, 10 Feb 2019 09:14:18 +0000 Subject: [issue21269] Provide args and kwargs attributes on mock call objects In-Reply-To: <1397681262.54.0.610859323151.issue21269@psf.upfronthosting.co.za> Message-ID: <1549790058.17.0.431223281163.issue21269@roundup.psfhosted.org> Change by Kumar Akshay : ---------- keywords: +patch, patch, patch pull_requests: +11819, 11820, 11821 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 04:18:05 2019 From: report at bugs.python.org (Kumar Akshay) Date: Sun, 10 Feb 2019 09:18:05 +0000 Subject: [issue21269] Provide args and kwargs attributes on mock call objects In-Reply-To: <1397681262.54.0.610859323151.issue21269@psf.upfronthosting.co.za> Message-ID: <1549790285.81.0.391896379966.issue21269@roundup.psfhosted.org> Kumar Akshay added the comment: Thanks @xtreak! I've added a PR with the following API ? cpython git:(fix-issue-21269) ? ./python.exe Python 3.8.0a0 (heads/fix-issue-21269-dirty:2433a2ab70, Feb 10 2019, 14:24:54) [Clang 10.0.0 (clang-1000.10.44.4)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from unittest.mock import Mock >>> m = Mock() >>> m(1, a=23) >>> m.call_args call(1, a=23) >>> m.call_args.args #after this patch (1,) >>> m.call_args.kwargs #after this patch {'a': 23} >>> m.call_args_list[0].args #after this patch (1,) >>> m.call_args_list[0].kwargs #after this patch {'a': 23} ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 05:15:23 2019 From: report at bugs.python.org (Francis MB) Date: Sun, 10 Feb 2019 10:15:23 +0000 Subject: [issue35892] Fix awkwardness of statistics.mode() for multimodal datasets In-Reply-To: <1549219885.57.0.86866159357.issue35892@roundup.psfhosted.org> Message-ID: <1549793723.17.0.53910423482.issue35892@roundup.psfhosted.org> Francis MB added the comment: >> There may be better names for the flag. "tie_goes_to_first_encountered" seemed a bit long though ;-) Could it may be an alternative to set the mode tie case in a form like: def mode(seq, *, case=CHOOSE_FIRST): [...] (or TIE_CHOOSE_FIRST, ...) where CHOOSE_FIRST is an enum ? Thanks! ---------- nosy: +francismb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 06:32:15 2019 From: report at bugs.python.org (Julien Palard) Date: Sun, 10 Feb 2019 11:32:15 +0000 Subject: [issue35055] Error when we try to download the epub archive In-Reply-To: <1540322085.68.0.788709270274.issue35055@psf.upfronthosting.co.za> Message-ID: <1549798335.87.0.84418592311.issue35055@roundup.psfhosted.org> Julien Palard added the comment: @ned the issue with builds in 3.8 come from our use of column and row spanning in the 3.8 documentation, breaking the plain text builder. I fixed it in https://github.com/sphinx-doc/sphinx/pull/5559 which has to be release in march IIRC. ---------- resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 06:48:47 2019 From: report at bugs.python.org (muhzi) Date: Sun, 10 Feb 2019 11:48:47 +0000 Subject: [issue35953] crosscompilation fails with clang on android Message-ID: <1549799326.05.0.946506554759.issue35953@roundup.psfhosted.org> Change by muhzi : ---------- components: Cross-Build nosy: Alex.Willmer, muhzi priority: normal severity: normal status: open title: crosscompilation fails with clang on android type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 07:03:16 2019 From: report at bugs.python.org (muhzi) Date: Sun, 10 Feb 2019 12:03:16 +0000 Subject: [issue35953] crosscompilation fails with clang on android Message-ID: <1549800196.49.0.252123188802.issue35953@roundup.psfhosted.org> New submission from muhzi : Trying to cross compile python for android using NDK r19. but I keep facing a linker error. x86_64-linux-android21-clang -pie -L~/Android/Sdk/ndk-bundle/platforms/android-21/arch-x86_64/usr/lib64 -Xlinker -export-dynamic -o python \ Modules/python.o \ -L. -lpython2.7 -ldl -lm ./libpython2.7.so: error: undefined reference to 'nl_langinfo' clang: error: linker command failed with exit code 1 (use -v to see invocation) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 07:28:36 2019 From: report at bugs.python.org (Adeokkuw) Date: Sun, 10 Feb 2019 12:28:36 +0000 Subject: [issue35954] Incoherent type conversion in configparser Message-ID: <1549801714.53.0.77041525212.issue35954@roundup.psfhosted.org> New submission from Adeokkuw : configparser interface implicitly converts all objects to str (read_dict [sic] on line 724 of "3.7/Lib/configparser.py") while saving but not while lookup (__getitem__ on line 956). MWE: ``` config = configparser.ConfigParser() config[123] = {} print(config[123]) ``` ~> KeyError: 123 ---------- components: Library (Lib) messages: 335150 nosy: Adeokkuw priority: normal severity: normal status: open title: Incoherent type conversion in configparser type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 07:46:09 2019 From: report at bugs.python.org (Adeokkuw) Date: Sun, 10 Feb 2019 12:46:09 +0000 Subject: [issue35954] Incoherent type conversion in configparser In-Reply-To: <1549801714.53.0.77041525212.issue35954@roundup.psfhosted.org> Message-ID: <1549802769.11.0.931289725614.issue35954@roundup.psfhosted.org> Adeokkuw added the comment: Btw: The name "read_dict" [1] as well as its docstring say exactly the opposite of what it does. It acts as a "save_dict". Maybe that can be fixed on the go ... The docstring """ [...] All types held in the dictionary are converted to strings during reading, including section names, option names and keys. [...] """ actually implies what is my proposal here: Convert arguments to str during lookup as well. ``` def __getitem__(self, key): if key != self.default_section and not self.has_section(key): raise KeyError(key) return self._proxies[key] ``` to ``` def __getitem__(self, key): try: key = str(key) except (WhateverError, IsRelevantHereError): raise KeyError(key) if key != self.default_section and not self.has_section(key): raise KeyError(key) return self._proxies[key] ``` [1] https://github.com/python/cpython/blob/3.7/Lib/configparser.py ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 07:52:15 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sun, 10 Feb 2019 12:52:15 +0000 Subject: [issue35954] Incoherent type conversion in configparser In-Reply-To: <1549801714.53.0.77041525212.issue35954@roundup.psfhosted.org> Message-ID: <1549803135.91.0.103580787407.issue35954@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 07:52:35 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Sun, 10 Feb 2019 12:52:35 +0000 Subject: [issue35954] Incoherent type conversion in configparser In-Reply-To: <1549801714.53.0.77041525212.issue35954@roundup.psfhosted.org> Message-ID: <1549803155.26.0.325189891873.issue35954@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 08:01:55 2019 From: report at bugs.python.org (Dong-hee Na) Date: Sun, 10 Feb 2019 13:01:55 +0000 Subject: [issue12317] inspect.getabsfile() is not documented In-Reply-To: <1308351508.86.0.88677303291.issue12317@psf.upfronthosting.co.za> Message-ID: <1549803715.19.0.75352345986.issue12317@roundup.psfhosted.org> Dong-hee Na added the comment: @terry.reedy I submited the PR 11786 for this issue. If you are okay can you take a look please? Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 08:05:00 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Sun, 10 Feb 2019 13:05:00 +0000 Subject: [issue35460] Add PyDict_GetItemStringWithError In-Reply-To: <1544526024.8.0.788709270274.issue35460@psf.upfronthosting.co.za> Message-ID: <1549803900.53.0.666590615641.issue35460@roundup.psfhosted.org> Ronald Oussoren added the comment: Adding PyDict_GetItemStringWithError makes is possible to migrate existing code to a design that does not ignore errors. I have a significant number of calls to PyDict_GetItemString that cannot be switch toed PyDict_GetItem without increasing the number of lines of C code I have to write (or in other words, if PyDict_GetItemString wouldn't exist I'd have invented this myself for use in extensions I write). Another reason for adding the function is consistency in the API. BTW. I've added a function with the same signature as the proposed PyDict_GetItemStringWithError to my exension's code base, which is something I'd have to do anyway for backward compatibility with older CPython versions. W.r.t API design: I prefer the interface of _PyObject_LookupAttr to that of PyDict_GetItemWithError, even if the additional cost of a call to PyErr_Occurred() is insignificant in most of my code (esp. when guarded with a test for a NULL return value from PyDict_GetItemWithError). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 08:24:33 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sun, 10 Feb 2019 13:24:33 +0000 Subject: [issue35953] crosscompilation fails with clang on android In-Reply-To: <1549800196.49.0.252123188802.issue35953@roundup.psfhosted.org> Message-ID: <1549805073.96.0.787247091805.issue35953@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +xdegaye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 09:12:00 2019 From: report at bugs.python.org (Jason R. Coombs) Date: Sun, 10 Feb 2019 14:12:00 +0000 Subject: [issue35955] unittest assertEqual reports incorrect location of mismatch Message-ID: <1549807918.24.0.168325596231.issue35955@roundup.psfhosted.org> New submission from Jason R. Coombs : In [this job](https://travis-ci.org/jaraco/cmdix/jobs/491246158), a project is using assertEqual to compare two directory listings that don't match in the group. But the hint markers pointing to the mismatch are pointing at positions that match: E AssertionError: '--w-[50 chars]drwxrwxr-x 2 2000 2000 4096 2019-02-10 14:[58 chars]oo\n' != '--w-[50 chars]drwxr-xr-x 2 2000 2000 4096 2019-02-10 14:[58 chars]oo\n' E --w-r---wx 1 2000 2000 999999 2019-02-10 14:02 bar E - drwxrwxr-x 2 2000 2000 4096 2019-02-10 14:02 biz E ? --- E + drwxr-xr-x 2 2000 2000 4096 2019-02-10 14:02 biz E ? +++ E - -rw-rw-r-- 1 2000 2000 100 2019-02-10 14:02 foo E ? --- E + -rw-r--r-- 1 2000 2000 100 2019-02-10 14:02 foo E ? +++ As you can see, it's the 'group' section of the flags that differ between the left and right comparison, but the hints point at the 'user' section for the left side and the 'world' section for the right side, even though they match. I observed this on Python 3.7.1. I haven't delved deeper to see if the issue exists on 3.7.2 or 3.8. ---------- components: Library (Lib) messages: 335154 nosy: jaraco priority: normal severity: normal status: open title: unittest assertEqual reports incorrect location of mismatch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 09:14:00 2019 From: report at bugs.python.org (Jason R. Coombs) Date: Sun, 10 Feb 2019 14:14:00 +0000 Subject: [issue35955] unittest assertEqual reports incorrect location of mismatch In-Reply-To: <1549807918.24.0.168325596231.issue35955@roundup.psfhosted.org> Message-ID: <1549808040.98.0.00429326282989.issue35955@roundup.psfhosted.org> Jason R. Coombs added the comment: I should acknowledge that I'm using pytest here also... and pytest may be the engine that's performing the reporting of the failed assertion. In fact, switching to simple assertions, I see the same behavior, so I now suspect the issue may lie with pytest and not unittest. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 09:14:19 2019 From: report at bugs.python.org (Jason R. Coombs) Date: Sun, 10 Feb 2019 14:14:19 +0000 Subject: [issue35955] unittest assertEqual reports incorrect location of mismatch In-Reply-To: <1549807918.24.0.168325596231.issue35955@roundup.psfhosted.org> Message-ID: <1549808059.6.0.147484996504.issue35955@roundup.psfhosted.org> Change by Jason R. Coombs : ---------- resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 09:24:56 2019 From: report at bugs.python.org (Jason R. Coombs) Date: Sun, 10 Feb 2019 14:24:56 +0000 Subject: [issue35955] unittest assertEqual reports incorrect location of mismatch In-Reply-To: <1549807918.24.0.168325596231.issue35955@roundup.psfhosted.org> Message-ID: <1549808696.44.0.969500646306.issue35955@roundup.psfhosted.org> Jason R. Coombs added the comment: I was able to replicate the issue using pytest and not unittest, so I've [reported the issue with that project](https://github.com/pytest-dev/pytest/issues/4765). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 09:42:50 2019 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 10 Feb 2019 14:42:50 +0000 Subject: [issue35460] Add PyDict_GetItemStringWithError In-Reply-To: <1544526024.8.0.788709270274.issue35460@psf.upfronthosting.co.za> Message-ID: <1549809770.18.0.440772751962.issue35460@roundup.psfhosted.org> Stefan Behnel added the comment: The overhead of calling PyErr_Occurred() is definitely negligible in something as involved as PyDict_GetItemStringWithError(), where a mere key lookup first has to fire up the string decoder on a C character buffer to create a new string object and then calculate its hash value, just to throw away all that right after the tiny time interval that it takes to look up the key in the dict. It is not something I would encourage anyone to do in code that has only the slightest excuse for being implemented in C. :) Rather, I would propose to open up the ID-String API that CPython uses internally, so that user code can benefit from fast lookups of interned strings with pre-initialised hash values, without having to care about creating and cleaning up string constants themselves all the time. (FWIW, Cython also generates interned string constants automatically, but does not currently use the ID-API, also because it does it for *all* its strings, not just those that resemble identifiers etc.) ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 09:58:27 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sun, 10 Feb 2019 14:58:27 +0000 Subject: [issue35955] unittest assertEqual reports incorrect location of mismatch In-Reply-To: <1549807918.24.0.168325596231.issue35955@roundup.psfhosted.org> Message-ID: <1549810707.0.0.386818298203.issue35955@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Sorry to comment on a closed issue. I see the following behavior with difflib.ndiff which is used under the hood by unittest. The strings that differ by '-' and 'w' generate different output compared to 'a' and 'w'. I find the output for diff using '-' and 'w' little confusing and is this caused due to '-' which is also used as a marker in difflib? $ ./python.exe Python 3.8.0a1+ (heads/master:8a03ff2ff4, Feb 9 2019, 10:42:29) [Clang 7.0.2 (clang-700.1.81)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import difflib >>> print(''.join(difflib.ndiff(["drwxrwxr-x 2 2000 2000\n"], ["drwxr-xr-x 2 2000 2000\n"]))) - drwxrwxr-x 2 2000 2000 ? --- + drwxr-xr-x 2 2000 2000 ? +++ >>> print(''.join(difflib.ndiff(["drwxrwxr-x 2 2000 2000\n"], ["drwxraxr-x 2 2000 2000\n"]))) - drwxrwxr-x 2 2000 2000 ? ^ + drwxraxr-x 2 2000 2000 ? ^ ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 10:40:20 2019 From: report at bugs.python.org (Ivan Levkivskyi) Date: Sun, 10 Feb 2019 15:40:20 +0000 Subject: [issue35878] ast.c: end_col_offset may be used uninitialized in this function In-Reply-To: <1549020161.52.0.11493245766.issue35878@roundup.psfhosted.org> Message-ID: <1549813220.03.0.383884221776.issue35878@roundup.psfhosted.org> Change by Ivan Levkivskyi : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 10:51:44 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Sun, 10 Feb 2019 15:51:44 +0000 Subject: [issue35460] Add PyDict_GetItemStringWithError In-Reply-To: <1544526024.8.0.788709270274.issue35460@psf.upfronthosting.co.za> Message-ID: <1549813904.26.0.516511903572.issue35460@roundup.psfhosted.org> Ronald Oussoren added the comment: There are more reasons to implement in C than just speed ;-). In my code I have two usecases for using PyDict_GetItemString, both not in performance critical code 1) Look up a hardcoded name in a dictionary. These could be switched to the Id API if that were public (and I might implement something like the Id API myself). 2) Look up a name that is passed in as a "char*" from C code that's outside of my control. This is a real use case for a PyDict_GetItemString API and not easilty converted to another API. In PyObjC the majority of calls to PyDict_GetItemString are in the first category, while most of the latter would probably be better of using a PyDict_GetItemBytes API. Although I definitely to not propose to add such an API to CPython. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 11:00:49 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Sun, 10 Feb 2019 16:00:49 +0000 Subject: [issue21269] Provide args and kwargs attributes on mock call objects In-Reply-To: <1397681262.54.0.610859323151.issue21269@psf.upfronthosting.co.za> Message-ID: <1549814449.07.0.698448864003.issue21269@roundup.psfhosted.org> R?mi Lapeyre added the comment: I like this patch, working with calls often feels weird and this change simplify attribute access. ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 11:08:20 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Sun, 10 Feb 2019 16:08:20 +0000 Subject: [issue21269] Provide args and kwargs attributes on mock call objects In-Reply-To: <1397681262.54.0.610859323151.issue21269@psf.upfronthosting.co.za> Message-ID: <1549814900.04.0.700789416912.issue21269@roundup.psfhosted.org> R?mi Lapeyre added the comment: @xtreak, couldn't we have made `_Call` inherit from namedtuple to achieve a similar result (albeit the handling of name would be weird)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 11:28:49 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sun, 10 Feb 2019 16:28:49 +0000 Subject: [issue21269] Provide args and kwargs attributes on mock call objects In-Reply-To: <1397681262.54.0.610859323151.issue21269@psf.upfronthosting.co.za> Message-ID: <1549816129.1.0.620417923065.issue21269@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: This feels safer to me with respect to backwards compatibility and also that it might be easier to backport this to mock on GitHub which works with Python 2.7. I have less knowledge on difference between tuple and namedtuple internals so I might be wrong here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 11:33:40 2019 From: report at bugs.python.org (fabrice salvaire) Date: Sun, 10 Feb 2019 16:33:40 +0000 Subject: [issue35956] Sort documentation could be improved for complex sorting Message-ID: <1549816419.03.0.97544553945.issue35956@roundup.psfhosted.org> New submission from fabrice salvaire : I just implemented Graham Scan algorithm in Python 3 and have to read carefully the sort documentation. Notice this is a good algorithm for a large audience language like Python. Since Python 3, the old order function cmp is depicted as an old way to proceed. But some sorting procedure require complex order like this def sort_by_y(p0, p1): return p0.x - p1.x if (p0.y == p1.y) else p0.y - p1.y sorted(points, key=cmp_to_key(sort_by_y)) which is less natural to implement than def sort_by_y(p0, p1): return p0.x < p1.x if (p0.y == p1.y) else p0.y < p1.y sorted(points, cmp=sort_by_y) Since Python 3 we should do this points.sort(key=attrgetter('x')) points.sort(key=attrgetter('y')) But we must take care to the chaining order !!! Here we must sort first on x then on y. I think the documentation could explain much better how to perform complex sort and the performance of the Python sort algorithm. Is the old way faster than the new one ??? What about short and large array ??? What happen when we sort a zillion of short array ??? ---------- assignee: docs at python components: Documentation messages: 335163 nosy: FabriceSalvaire, docs at python priority: normal severity: normal status: open title: Sort documentation could be improved for complex sorting type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 11:37:44 2019 From: report at bugs.python.org (SilentGhost) Date: Sun, 10 Feb 2019 16:37:44 +0000 Subject: [issue35956] Sort documentation could be improved for complex sorting In-Reply-To: <1549816419.03.0.97544553945.issue35956@roundup.psfhosted.org> Message-ID: <1549816664.96.0.735387915438.issue35956@roundup.psfhosted.org> SilentGhost added the comment: Is this not equivalent to the following? sorted(points, key=lambda p: (p.y, p.x)) ---------- nosy: +SilentGhost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 12:26:58 2019 From: report at bugs.python.org (=?utf-8?q?J=C3=A9r=C3=B4me_LAURENS?=) Date: Sun, 10 Feb 2019 17:26:58 +0000 Subject: [issue35957] Indentation explanation is unclear Message-ID: <1549819617.52.0.344509790006.issue35957@roundup.psfhosted.org> New submission from J?r?me LAURENS : https://docs.python.org/3/reference/lexical_analysis.html#indentation reads Point 1: "Tabs are replaced (from left to right) by one to eight spaces such that the total number of characters up to and including the replacement is a multiple of eight" and in the next paragraph Point 2: "Indentation is rejected as inconsistent if a source file mixes tabs and spaces in a way that makes the meaning dependent on the worth of a tab in spaces" In point 1, each tab has definitely a unique space counterpart, in point 2, tabs may have different space counterpart, which one is reliable ? The documentation should state that Point 1 concerns cPython, or at least indicate that the 8 may depend on the implementation, which then gives sense to point 2. ---------- assignee: docs at python components: Documentation messages: 335165 nosy: J?r?me LAURENS, docs at python priority: normal severity: normal status: open title: Indentation explanation is unclear type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 12:37:18 2019 From: report at bugs.python.org (Jon McMahon) Date: Sun, 10 Feb 2019 17:37:18 +0000 Subject: [issue35958] io.IOBase subclasses don't play nice with abc.abstractmethod Message-ID: <1549820237.63.0.597110746163.issue35958@roundup.psfhosted.org> New submission from Jon McMahon : Subclasses of io.IOBase can be instantiated with abstractmethod()s, even though ABCs are supposed to prevent this from happening. I'm guessing this has to do with io using the _io C module because the alternative pure-python implementation _pyio doesn't seem to have this issue. I'm using Python 3.6.7 >>> import _pyio >>> import io >>> import abc >>> class TestPurePython(_pyio.IOBase): ... @abc.abstractmethod ... def foo(self): ... print('Pure python implementation') ... >>> class TestCExtension(io.IOBase): ... @abc.abstractmethod ... def bar(self): ... print('C extension implementation') ... >>> x=TestPurePython() Traceback (most recent call last): File "", line 1, in TypeError: Can't instantiate abstract class TestPurePython with abstract methods foo >>> y=TestCExtension() >>> y.bar() C extension implementation >>> ---------- components: IO messages: 335166 nosy: Jon McMahon priority: normal severity: normal status: open title: io.IOBase subclasses don't play nice with abc.abstractmethod versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 13:03:40 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Sun, 10 Feb 2019 18:03:40 +0000 Subject: [issue35956] Sort documentation could be improved for complex sorting In-Reply-To: <1549816419.03.0.97544553945.issue35956@roundup.psfhosted.org> Message-ID: <1549821820.83.0.468496430118.issue35956@roundup.psfhosted.org> Cheryl Sabella added the comment: Take a look at issue 35020 which discusses multisort. ---------- nosy: +cheryl.sabella _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 14:08:55 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sun, 10 Feb 2019 19:08:55 +0000 Subject: [issue35959] math.prod(range(10)) caues segfault Message-ID: <1549825733.5.0.0745476001214.issue35959@roundup.psfhosted.org> New submission from Karthikeyan Singaravelan : math.prod introduced with issue35606 seems to segfault when zero is present on some cases like start or middle of the iterable. I couldn't find the exact cause of this. This also occurs in optimized builds. # Python information built with ./configure && make ? cpython git:(master) ./python.exe Python 3.8.0a1+ (heads/master:8a03ff2ff4, Feb 11 2019, 00:13:49) [Clang 7.0.2 (clang-700.1.81)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> # Segfaults with range(10), [0, 1, 2, 3] and [1, 0, 2, 3] ? cpython git:(master) ./python.exe -X faulthandler -c 'import math; print(math.prod(range(10)))' Fatal Python error: Floating point exception Current thread 0x00007fff7939f300 (most recent call first): File "", line 1 in [1] 40465 floating point exception ./python.exe -X faulthandler -c 'import math; print(math.prod(range(10)))' ? cpython git:(master) ./python.exe -X faulthandler -c 'import math; print(math.prod([0, 1, 2, 3]))' Fatal Python error: Floating point exception Current thread 0x00007fff7939f300 (most recent call first): File "", line 1 in [1] 40414 floating point exception ./python.exe -X faulthandler -c 'import math; print(math.prod([0, 1, 2, 3]))' ? cpython git:(master) ./python.exe -X faulthandler -c 'import math; print(math.prod([1, 0, 2, 3]))' Fatal Python error: Floating point exception Current thread 0x00007fff7939f300 (most recent call first): File "", line 1 in [1] 40425 floating point exception ./python.exe -X faulthandler -c 'import math; print(math.prod([1, 0, 2, 3]))' # No segfault when zero is at the end and floats seem to work fine. ? cpython git:(master) ./python.exe -X faulthandler -c 'import math; print(math.prod([1, 2, 3, 0]))' 0 ? cpython git:(master) ./python.exe -c 'import math; print(math.prod(map(float, range(10))))' 0.0 ---------- components: Library (Lib) messages: 335168 nosy: pablogsal, rhettinger, xtreak priority: normal severity: normal status: open title: math.prod(range(10)) caues segfault type: crash versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 14:18:40 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Sun, 10 Feb 2019 19:18:40 +0000 Subject: [issue35959] math.prod(range(10)) caues segfault In-Reply-To: <1549825733.5.0.0745476001214.issue35959@roundup.psfhosted.org> Message-ID: <1549826320.19.0.185901389575.issue35959@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: The problem is that the intermediate result (i_result) can be 0 when doing the overflow check: x / i_result != b i am working on a fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 14:20:17 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Sun, 10 Feb 2019 19:20:17 +0000 Subject: [issue35959] math.prod(range(10)) caues segfault In-Reply-To: <1549825733.5.0.0745476001214.issue35959@roundup.psfhosted.org> Message-ID: <1549826417.73.0.980332523994.issue35959@roundup.psfhosted.org> R?mi Lapeyre added the comment: Could it be https://github.com/python/cpython/blob/master/Modules/mathmodule.c#L2565 When 0 is in the iterator, i_result get sets to 0 and then on the next iteration x/i_result is 0/0 which is undefined behavior? C99 6.5.5p5 - The result of the / operator is the quotient from the division of the first operand by the second; the result of the % operator is the remainder. In both operations, if the value of the second operand is zero, the behavior is undefined. I will do some tests, if it's that I will post a patch. ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 14:20:46 2019 From: report at bugs.python.org (Brandt Bucher) Date: Sun, 10 Feb 2019 19:20:46 +0000 Subject: [issue35936] Give modulefinder some much-needed updates. In-Reply-To: <1549596039.09.0.478412891062.issue35936@roundup.psfhosted.org> Message-ID: <1549826446.89.0.496598390068.issue35936@roundup.psfhosted.org> Brandt Bucher added the comment: Alright, I've gotten all of the tests passing for the new importlib-only implementation. I broke these modifications out into a new private function, _find_module, to make it clear that this fix is a simple drop-in replacement for imp.find_module. Let me know if there's anything I've missed or could improve. Otherwise, I feel my work here is done! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 14:23:07 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Sun, 10 Feb 2019 19:23:07 +0000 Subject: [issue35959] math.prod(range(10)) caues segfault In-Reply-To: <1549825733.5.0.0745476001214.issue35959@roundup.psfhosted.org> Message-ID: <1549826587.95.0.694853524963.issue35959@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- keywords: +patch pull_requests: +11822 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 14:23:13 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Sun, 10 Feb 2019 19:23:13 +0000 Subject: [issue35959] math.prod(range(10)) caues segfault In-Reply-To: <1549825733.5.0.0745476001214.issue35959@roundup.psfhosted.org> Message-ID: <1549826593.56.0.38024198952.issue35959@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- keywords: +patch, patch pull_requests: +11822, 11823 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 14:23:19 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Sun, 10 Feb 2019 19:23:19 +0000 Subject: [issue35959] math.prod(range(10)) caues segfault In-Reply-To: <1549825733.5.0.0745476001214.issue35959@roundup.psfhosted.org> Message-ID: <1549826599.37.0.823555237824.issue35959@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- keywords: +patch, patch, patch pull_requests: +11822, 11823, 11824 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 14:24:24 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Sun, 10 Feb 2019 19:24:24 +0000 Subject: [issue35959] math.prod(range(10)) caues segfault In-Reply-To: <1549825733.5.0.0745476001214.issue35959@roundup.psfhosted.org> Message-ID: <1549826664.04.0.914307244375.issue35959@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: PR11808 fixes the error and add some basic test. Please review the PR instead :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 14:40:55 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Sun, 10 Feb 2019 19:40:55 +0000 Subject: [issue35940] multiprocessing manager tests fail in the Refleaks buildbots In-Reply-To: <1549634808.3.0.556124260005.issue35940@roundup.psfhosted.org> Message-ID: <1549827655.09.0.293487529918.issue35940@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 14:57:08 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Sun, 10 Feb 2019 19:57:08 +0000 Subject: [issue35959] math.prod(range(10)) caues segfault In-Reply-To: <1549825733.5.0.0745476001214.issue35959@roundup.psfhosted.org> Message-ID: <1549828628.65.0.254718015343.issue35959@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 15:32:02 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Sun, 10 Feb 2019 20:32:02 +0000 Subject: [issue35959] math.prod(range(10)) caues segfault In-Reply-To: <1549825733.5.0.0745476001214.issue35959@roundup.psfhosted.org> Message-ID: <1549830722.78.0.856936374492.issue35959@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- pull_requests: +11825 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 15:32:11 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Sun, 10 Feb 2019 20:32:11 +0000 Subject: [issue35959] math.prod(range(10)) caues segfault In-Reply-To: <1549825733.5.0.0745476001214.issue35959@roundup.psfhosted.org> Message-ID: <1549830731.65.0.654672142595.issue35959@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- pull_requests: +11825, 11826 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 15:32:19 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Sun, 10 Feb 2019 20:32:19 +0000 Subject: [issue35959] math.prod(range(10)) caues segfault In-Reply-To: <1549825733.5.0.0745476001214.issue35959@roundup.psfhosted.org> Message-ID: <1549830739.75.0.872598554684.issue35959@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- pull_requests: +11825, 11826, 11827 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 17:00:36 2019 From: report at bugs.python.org (=?utf-8?b?TWF0w7rFoSBWYWxv?=) Date: Sun, 10 Feb 2019 22:00:36 +0000 Subject: [issue9584] fnmatch, glob: Allow curly brace expansion In-Reply-To: <1281688613.27.0.00233773234268.issue9584@psf.upfronthosting.co.za> Message-ID: <1549836036.63.0.405634080322.issue9584@roundup.psfhosted.org> Mat?? Valo added the comment: Hi All, this is a humble ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 17:15:29 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Sun, 10 Feb 2019 22:15:29 +0000 Subject: [issue35278] [security] directory traversal in tempfile prefix In-Reply-To: <1542631563.19.0.788709270274.issue35278@psf.upfronthosting.co.za> Message-ID: <1549836929.85.0.848846262582.issue35278@roundup.psfhosted.org> Cheryl Sabella added the comment: Adding ?ukasz to the nosy list as release manager. ---------- nosy: +cheryl.sabella, lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 17:42:45 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Sun, 10 Feb 2019 22:42:45 +0000 Subject: [issue35940] multiprocessing manager tests fail in the Refleaks buildbots In-Reply-To: <1549634808.3.0.556124260005.issue35940@roundup.psfhosted.org> Message-ID: <1549838565.6.0.453127977953.issue35940@roundup.psfhosted.org> Giampaolo Rodola' added the comment: Pablo thanks a lot for taking care of this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 17:46:29 2019 From: report at bugs.python.org (Brennan) Date: Sun, 10 Feb 2019 22:46:29 +0000 Subject: [issue35899] '_is_sunder' function in 'enum' module fails on empty string In-Reply-To: <1549376859.01.0.998806898699.issue35899@roundup.psfhosted.org> Message-ID: <1549838789.17.0.462834861878.issue35899@roundup.psfhosted.org> Brennan <375 at holbertonschool.com> added the comment: I'm not sure if Maxwell is still working on this issue, but may I pick it up? I can submit a PR within the day. ---------- nosy: +bdbaraban _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 18:05:45 2019 From: report at bugs.python.org (Anthony Sottile) Date: Sun, 10 Feb 2019 23:05:45 +0000 Subject: [issue34652] never enable lchmod on Linux In-Reply-To: <1536788618.14.0.956365154283.issue34652@psf.upfronthosting.co.za> Message-ID: <1549839945.77.0.548103177048.issue34652@roundup.psfhosted.org> Anthony Sottile added the comment: I believe this also closes https://bugs.python.org/issue31940 and https://bugs.python.org/issue28627 ---------- nosy: +Anthony Sottile _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 18:15:22 2019 From: report at bugs.python.org (Ethan Furman) Date: Sun, 10 Feb 2019 23:15:22 +0000 Subject: [issue35899] '_is_sunder' function in 'enum' module fails on empty string In-Reply-To: <1549376859.01.0.998806898699.issue35899@roundup.psfhosted.org> Message-ID: <1549840522.66.0.143958074825.issue35899@roundup.psfhosted.org> Ethan Furman added the comment: Let's give Maxwell until the 14th (so a week from when I asked him to turn his code into a patch) and if nothing from him by then you are welcome to take it over. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 18:20:29 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 10 Feb 2019 23:20:29 +0000 Subject: [issue12317] inspect.getabsfile() is not documented In-Reply-To: <1308351508.86.0.88677303291.issue12317@psf.upfronthosting.co.za> Message-ID: <1549840829.88.0.519893543283.issue12317@roundup.psfhosted.org> Terry J. Reedy added the comment: Given the absence of agreement among core-devs, a PR is a bit premature. Looking again at the existing docstring, I think it must be revised before copying and *not* copied as is. 0. The existing first sentence mislead me. The 'source or compiled file' must be a Python source or compiled Python (.pyc) file. An object in a compiled C file gives a TypeError. Change 'an object' to 'a Python-coded object'. 1. The 'object' argument cannot be just any Python-coded object (class object instance). Based on the exception message, add this second sentence: "The object must be a module, class, method, function, traceback, frame, or code object." Otherwise, TypeError. 2. The second paragraph is garbled. All objects in a module have a common origin, not a unique origin. I think the idea is that the name for the origin should be a standardized full path. I think that this paragraph adds so little that it should be deleted rather than revised. What paused this issue was Brett's opinion that getabsfile is untrustworthy and, with __file__ absolute, 'pointless', to a degree that it should not be documented. (If that were true, it should be deprecated.) I read the 3.7.2 source for getabsfile, getsourcefile, and getfile. The returned name is based on either module.__file__ or code.co_filename. I think the function should be kept and documented. 1. Assuming that both __file__ and co_filename are now normcased and normalized absolute paths, (and identical for functions,) then "os.path.normcase(os.path.abspath(_filename))" is a no-op returning _filename as is, and should be dropped. There is no longer a "guess at what the cwd was when a module was imported" in getabsfile itself. 2. getfile and getsourcefile do non-trivial switching and name processing that users would not get right if getabsfile were not present. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 18:20:55 2019 From: report at bugs.python.org (Brennan D Baraban) Date: Sun, 10 Feb 2019 23:20:55 +0000 Subject: [issue35899] '_is_sunder' function in 'enum' module fails on empty string In-Reply-To: <1549376859.01.0.998806898699.issue35899@roundup.psfhosted.org> Message-ID: <1549840855.11.0.0619372114551.issue35899@roundup.psfhosted.org> Brennan D Baraban <375 at holbertonschool.com> added the comment: Got it, makes sense. Thank you. New contributor here :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 18:32:48 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Sun, 10 Feb 2019 23:32:48 +0000 Subject: [issue35904] Add statistics.fmean(seq) In-Reply-To: <1549665549.17.0.206021177416.issue35904@roundup.psfhosted.org> Message-ID: <20190210233241.GQ1834@ando.pearwood.info> Steven D'Aprano added the comment: > Would you like me to submit a PR with docs and tests? Yes please! I'm happy with the name fmean. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 19:12:13 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Mon, 11 Feb 2019 00:12:13 +0000 Subject: [issue35892] Fix awkwardness of statistics.mode() for multimodal datasets In-Reply-To: <1549219885.57.0.86866159357.issue35892@roundup.psfhosted.org> Message-ID: <20190211001203.GR1834@ando.pearwood.info> Steven D'Aprano added the comment: Thanks Raymond for the interesting use-case. The original design of mode() was support only the basic form taught in secondary schools, namely a single unique mode for categorical data or discrete numerical data. I think it is time to consider a richer interface to support more uses, such as estimating the mode of continuous numerical data, and the multi-mode case you bring up. One reason I've been hesitant is that deciding what is the right behaviour is quite hard (or at least it has been for me). I think there are a few cases to consider: - the existing behaviour (which may not be very useful?) which is to raise an exception unless the mode is unique; - would it be more useful to return an out-of-band value like a NAN or None? - the multi-mode case where you want some arbitrary(?) mode, possibly the left-most (smallest) for numeric data; - the multi-mode case where you want all the modes. I like Francis' suggestion to use an enum to select the behavioural, er, mode (pun intended). What do you think? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 19:36:42 2019 From: report at bugs.python.org (Brennan D Baraban) Date: Mon, 11 Feb 2019 00:36:42 +0000 Subject: [issue23460] Decimals do not obey ':g' exponential notation formatting rules In-Reply-To: <1423847721.13.0.666007782647.issue23460@psf.upfronthosting.co.za> Message-ID: <1549845402.63.0.511336486405.issue23460@roundup.psfhosted.org> Brennan D Baraban <375 at holbertonschool.com> added the comment: What is the status of this issue? I can submit a PR based on Tuomas Suutari's patch. ---------- nosy: +bdbaraban _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 19:49:00 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 11 Feb 2019 00:49:00 +0000 Subject: [issue35808] Let's retire pgen In-Reply-To: <1548221537.82.0.492786218381.issue35808@roundup.psfhosted.org> Message-ID: <1549846140.5.0.719228636328.issue35808@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- keywords: +patch pull_requests: +11828 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 19:49:08 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 11 Feb 2019 00:49:08 +0000 Subject: [issue35808] Let's retire pgen In-Reply-To: <1548221537.82.0.492786218381.issue35808@roundup.psfhosted.org> Message-ID: <1549846148.47.0.616981162839.issue35808@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- keywords: +patch, patch pull_requests: +11828, 11829 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 19:49:16 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 11 Feb 2019 00:49:16 +0000 Subject: [issue35808] Let's retire pgen In-Reply-To: <1548221537.82.0.492786218381.issue35808@roundup.psfhosted.org> Message-ID: <1549846156.05.0.947815290932.issue35808@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- keywords: +patch, patch, patch pull_requests: +11828, 11829, 11830 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 19:50:28 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 11 Feb 2019 00:50:28 +0000 Subject: [issue35808] Let's retire pgen In-Reply-To: <1548221537.82.0.492786218381.issue35808@roundup.psfhosted.org> Message-ID: <1549846228.76.0.899209192606.issue35808@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- pull_requests: -11830 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 19:50:42 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 11 Feb 2019 00:50:42 +0000 Subject: [issue35808] Let's retire pgen In-Reply-To: <1548221537.82.0.492786218381.issue35808@roundup.psfhosted.org> Message-ID: <1549846242.09.0.850428014033.issue35808@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- pull_requests: -11829, 11830 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 20:06:55 2019 From: report at bugs.python.org (Christopher Hunt) Date: Mon, 11 Feb 2019 01:06:55 +0000 Subject: [issue35960] dataclasses.field does not preserve empty metadata object Message-ID: <1549847214.14.0.863197964236.issue35960@roundup.psfhosted.org> New submission from Christopher Hunt : The metadata argument to dataclasses.field is not preserved in the resulting Field.metadata attribute if the argument is a mapping with length 0. The docs for dataclasses.field state: > metadata: This can be a mapping or None. None is treated as an empty dict. This value is wrapped in MappingProxyType() to make it read-only, and exposed on the Field object. The docs for MappingProxyType() state: > Read-only proxy of a mapping. It provides a dynamic view on the mapping?s entries, which means that when the mapping changes, the view reflects these changes. I assumed that the mapping provided could be updated after class initialization and the changes would reflect in the field's metadata attribute. Indeed this is the case when the mapping is non-empty, but not when the mapping is initially empty. For example: $ python Python 3.8.0a1+ (heads/master:9db56fb8fa, Feb 10 2019, 19:54:10) [GCC 7.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from dataclasses import field >>> d = {} >>> v = field(metadata=d) >>> d['i'] = 1 >>> v.metadata mappingproxy({}) >>> v = field(metadata=d) >>> v.metadata mappingproxy({'i': 1}) >>> d['j'] = 2 >>> v.metadata mappingproxy({'i': 1, 'j': 2}) In my case I have a LazyDict into which I was trying to save partial(callback, field). I could not have the field before it was initialized so I tried: d = {} member: T = field(metadata=d) d['key'] = partial(callback, field) and it failed same as above. As a workaround, one can set a dummy value in the mapping prior to calling dataclasses.field and then remove/overwrite it afterwards. ---------- components: Library (Lib) messages: 335184 nosy: chrahunt priority: normal severity: normal status: open title: dataclasses.field does not preserve empty metadata object type: behavior versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 20:25:12 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 11 Feb 2019 01:25:12 +0000 Subject: [issue35961] gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small Message-ID: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> New submission from Pablo Galindo Salgado : I am seeing some failures in travis and some buildbots: 0:02:24 load avg: 3.30 [147/420/1] test_slice crashed (Exit code -6) -- running: test_multiprocessing_spawn (32 sec 523 ms), test_asyncio (45 sec 433 ms), test_multiprocessing_forkserver (47 sec 869 ms) Modules/gcmodule.c:110: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small Enable tracemalloc to get the memory block allocation traceback object : .BadCmp object at 0x2ab2051faef0> type : BadCmp refcount: 1 address : 0x2ab2051faef0 Fatal Python error: _PyObject_AssertFailed Current thread 0x00002ab1fe0519c0 (most recent call first): File "/home/travis/build/python/cpython/Lib/test/test_slice.py", line 107 in File "/home/travis/build/python/cpython/Lib/unittest/case.py", line 197 in handle File "/home/travis/build/python/cpython/Lib/unittest/case.py", line 782 in assertRaises File "/home/travis/build/python/cpython/Lib/test/test_slice.py", line 107 in test_cmp File "/home/travis/build/python/cpython/Lib/unittest/case.py", line 642 in run File "/home/travis/build/python/cpython/Lib/unittest/case.py", line 702 in __call__ File "/home/travis/build/python/cpython/Lib/unittest/suite.py", line 122 in run File "/home/travis/build/python/cpython/Lib/unittest/suite.py", line 84 in __call__ File "/home/travis/build/python/cpython/Lib/unittest/suite.py", line 122 in run File "/home/travis/build/python/cpython/Lib/unittest/suite.py", line 84 in __call__ File "/home/travis/build/python/cpython/Lib/unittest/suite.py", line 122 in run File "/home/travis/build/python/cpython/Lib/unittest/runner.py", line 176 in run File "/home/travis/build/python/cpython/Lib/test/support/__init__.py", line 1935 in _run_suite File "/home/travis/build/python/cpython/Lib/test/support/__init__.py", line 2031 in run_unittest File "/home/travis/build/python/cpython/Lib/test/libregrtest/runtest.py", line 178 in test_runner File "/home/travis/build/python/cpython/Lib/test/libregrtest/runtest.py", line 182 in runtest_inner File "/home/travis/build/python/cpython/Lib/test/libregrtest/runtest.py", line 127 in runtest File "/home/travis/build/python/cpython/Lib/test/libregrtest/runtest_mp.py", line 68 in run_tests_worker File "/home/travis/build/python/cpython/Lib/test/libregrtest/main.py", line 600 in _main File "/home/travis/build/python/cpython/Lib/test/libregrtest/main.py", line 586 in main File "/home/travis/build/python/cpython/Lib/test/libregrtest/main.py", line 640 in main File "/home/travis/build/python/cpython/Lib/test/regrtest.py", line 46 in _main File "/home/travis/build/python/cpython/Lib/test/regrtest.py", line 50 in File "/home/travis/build/python/cpython/Lib/runpy.py", line 85 in _run_code Usually, this happens with test_slice but when the test runner runs test_slice in isolation, it succeeds. I am afraid that this will be a weird combination of tests. ---------- components: Tests messages: 335185 nosy: pablogsal priority: normal severity: normal status: open title: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 20:33:52 2019 From: report at bugs.python.org (Ammar Askar) Date: Mon, 11 Feb 2019 01:33:52 +0000 Subject: [issue35951] os.renames() creates directories if original name doesn't exist In-Reply-To: <1549732242.93.0.821054504106.issue35951@roundup.psfhosted.org> Message-ID: <1549848832.92.0.113644579172.issue35951@roundup.psfhosted.org> Ammar Askar added the comment: It seems this behavior is somewhat documented: https://docs.python.org/3/library/os.html#os.renames >Works like rename(), except creation of any intermediate directories needed to make the new pathname good is attempted first. >This function can fail with the new directory structure made if you lack permissions needed to remove the leaf directory or file. The source directory not existing isn't the same as not having permissions to remove it but close enough. ---------- nosy: +ammar2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 20:39:51 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 11 Feb 2019 01:39:51 +0000 Subject: [issue35956] Sort documentation could be improved for complex sorting In-Reply-To: <1549816419.03.0.97544553945.issue35956@roundup.psfhosted.org> Message-ID: <1549849191.43.0.52561484247.issue35956@roundup.psfhosted.org> Raymond Hettinger added the comment: It seems to me that the sorting howto covers this topic. If I'm reading the OP's task correctly, it isn't complex at all: points.sort(key=attrgetter('x', 'y')) # x is primary key; y is secondary ---------- assignee: docs at python -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 20:52:46 2019 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 11 Feb 2019 01:52:46 +0000 Subject: [issue31940] copystat on symlinks fails for alpine -- faulty lchmod implementation? In-Reply-To: <1509753073.77.0.213398074469.issue31940@psf.upfronthosting.co.za> Message-ID: <1549849966.63.0.189623469569.issue31940@roundup.psfhosted.org> Change by Benjamin Peterson : ---------- resolution: -> duplicate stage: patch review -> resolved status: open -> closed superseder: -> never enable lchmod on Linux _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 20:53:13 2019 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 11 Feb 2019 01:53:13 +0000 Subject: [issue28627] [alpine] shutil.copytree fail to copy a direcotry with broken symlinks In-Reply-To: <1478471671.65.0.611428361622.issue28627@psf.upfronthosting.co.za> Message-ID: <1549849993.62.0.187992454612.issue28627@roundup.psfhosted.org> Change by Benjamin Peterson : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 21:08:38 2019 From: report at bugs.python.org (Christopher Hunt) Date: Mon, 11 Feb 2019 02:08:38 +0000 Subject: [issue35960] dataclasses.field does not preserve empty metadata object In-Reply-To: <1549847214.14.0.863197964236.issue35960@roundup.psfhosted.org> Message-ID: <1549850918.41.0.458194497416.issue35960@roundup.psfhosted.org> Change by Christopher Hunt : ---------- keywords: +patch pull_requests: +11831 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 21:08:41 2019 From: report at bugs.python.org (Christopher Hunt) Date: Mon, 11 Feb 2019 02:08:41 +0000 Subject: [issue35960] dataclasses.field does not preserve empty metadata object In-Reply-To: <1549847214.14.0.863197964236.issue35960@roundup.psfhosted.org> Message-ID: <1549850921.33.0.885801556656.issue35960@roundup.psfhosted.org> Change by Christopher Hunt : ---------- keywords: +patch, patch pull_requests: +11831, 11832 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 21:08:45 2019 From: report at bugs.python.org (Christopher Hunt) Date: Mon, 11 Feb 2019 02:08:45 +0000 Subject: [issue35960] dataclasses.field does not preserve empty metadata object In-Reply-To: <1549847214.14.0.863197964236.issue35960@roundup.psfhosted.org> Message-ID: <1549850925.03.0.0641058152035.issue35960@roundup.psfhosted.org> Change by Christopher Hunt : ---------- keywords: +patch, patch, patch pull_requests: +11831, 11832, 11833 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 21:22:30 2019 From: report at bugs.python.org (Ammar Askar) Date: Mon, 11 Feb 2019 02:22:30 +0000 Subject: [issue35796] time.localtime returns error for negative values In-Reply-To: <1548070339.94.0.0791021620364.issue35796@roundup.psfhosted.org> Message-ID: <1549851750.05.0.750973388202.issue35796@roundup.psfhosted.org> Ammar Askar added the comment: Victor is correct, this is a limitation in Windows. As the documentation for time notes: >Although this module is always available, not all functions are available on all platforms. Most of the functions defined in this module call platform C library functions with the same name. It may sometimes be helpful to consult the platform documentation, because the semantics of these functions varies among platforms. https://docs.python.org/3/library/time.html#module-time And as the Windows documentation notes: >less than 0 or greater than _MAX__TIME64_T: EINVAL https://msdn.microsoft.com/en-us/library/a442x3ye.aspx?f=255&MSPPError=-2147217396 ---------- nosy: +ammar2 resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 21:30:05 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 11 Feb 2019 02:30:05 +0000 Subject: [issue35889] sqlite3.Row doesn't have useful repr In-Reply-To: <1549112536.04.0.744689521798.issue35889@roundup.psfhosted.org> Message-ID: <1549852205.41.0.72198454056.issue35889@roundup.psfhosted.org> Raymond Hettinger added the comment: +1 from me. We're already made regular expression match objects less opaque and that has been useful. There's no need for a python-ideas discussion for this. If a repr doesn't round-trip, we generally put it angle brackets (see PEP 8): >>> re.search(r'([a-z]+)(\d*)', 'alpha7') The Row object access style uses square brackets and has a keys() method. That suggests a dict-like representation would be intuitive and match how Row objects are used: ro['salary'] and ro.keys(). Putting those two ideas together we get: Note the OP's suggestion for keyword argument style doesn't make sense for two reasons: 1) Row objects don't allow attribute access (i.e. ro.name is invalid) and 2) the field names are not required to be valid Python identifiers (i.e. ro['class'] is possible but ro.class is syntactically invalid because "class" is a keyword). ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 21:46:34 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 11 Feb 2019 02:46:34 +0000 Subject: [issue35460] Add PyDict_GetItemStringWithError In-Reply-To: <1544526024.8.0.788709270274.issue35460@psf.upfronthosting.co.za> Message-ID: <1549853194.63.0.373966620797.issue35460@roundup.psfhosted.org> Raymond Hettinger added the comment: -1 for expanding this API. As Serhiy pointed-out, PyDict_GetItemString() is an old API kept just for backward compatibility. For your use case, it is easy to call PyUnicode_FromString(key) and then follow-up with PyDict_GetItemWithError(). The latter way is more flexible in that it allows you to cache the unicode object for future use (something you're going to want to do if you care about performance). The latter way also lets you intern the string as well. FWIW, if it is only your own code, it is trivially easy to write your own helper function if that is what you needed for a single porting project. IMO, unnecessarily adding to many variants of the same function just makes the API harder to learn (see all the ObjectCall variants for example) and makes the code harder for us to maintain. ISTM most of the concrete APIs are deliberately sparse, so adding this variant would be a change in the philosophy of the C-API. Also, we mostly want people to use the abstract API unless they know for sure that a target dictionary is an exact dict (this has been an outstanding problem for OrderedDicts for example). ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 21:55:33 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Mon, 11 Feb 2019 02:55:33 +0000 Subject: [issue35961] gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> Message-ID: <1549853733.55.0.714938234707.issue35961@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: I too saw this a week back but couldn't reproduce it. There is one another test that fails like this and passes on verbose mode issue35809 . Travis doesn't report tests that fail in the complete run and pass during verbose run like buildbots do. ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 21:58:07 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Mon, 11 Feb 2019 02:58:07 +0000 Subject: [issue35960] dataclasses.field does not preserve empty metadata object In-Reply-To: <1549847214.14.0.863197964236.issue35960@roundup.psfhosted.org> Message-ID: <1549853887.41.0.323367009478.issue35960@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 22:07:58 2019 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 11 Feb 2019 03:07:58 +0000 Subject: [issue35951] os.renames() creates directories if original name doesn't exist In-Reply-To: <1549732242.93.0.821054504106.issue35951@roundup.psfhosted.org> Message-ID: <1549854478.53.0.203152632815.issue35951@roundup.psfhosted.org> Chris Jerdonek added the comment: Lacking permissions seems very different to me from the source directory or file not existing. For example, in the example I provided, I did have the needed permissions. Incidentally (and this is a separate documentation issue), the note seems unclear as to whether "the leaf directory or file" the user lacks permissions to remove is in reference to the "rightmost path segments of the old name" being pruned away, or the new directory structure to be removed on failure. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 22:18:52 2019 From: report at bugs.python.org (Ammar Askar) Date: Mon, 11 Feb 2019 03:18:52 +0000 Subject: [issue35951] os.renames() creates directories if original name doesn't exist In-Reply-To: <1549732242.93.0.821054504106.issue35951@roundup.psfhosted.org> Message-ID: <1549855132.53.0.983047463052.issue35951@roundup.psfhosted.org> Ammar Askar added the comment: Aah, I interpreted the combination of the warning and the fact that it says "attempted first" to mean that any failures in the actual renaming will leave the new directory in place. That is, no cleanup is ever performed. A quick glance at the code seems to suggest that as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 23:39:47 2019 From: report at bugs.python.org (Davin Potts) Date: Mon, 11 Feb 2019 04:39:47 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1549859987.83.0.639157367245.issue35813@roundup.psfhosted.org> Change by Davin Potts : ---------- pull_requests: +11834 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 23:40:10 2019 From: report at bugs.python.org (Davin Potts) Date: Mon, 11 Feb 2019 04:40:10 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1549860010.53.0.413968314794.issue35813@roundup.psfhosted.org> Change by Davin Potts : ---------- pull_requests: +11834, 11835 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 10 23:40:35 2019 From: report at bugs.python.org (Davin Potts) Date: Mon, 11 Feb 2019 04:40:35 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1549860035.89.0.14174092578.issue35813@roundup.psfhosted.org> Change by Davin Potts : ---------- pull_requests: +11834, 11835, 11836 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 01:09:04 2019 From: report at bugs.python.org (Davin Potts) Date: Mon, 11 Feb 2019 06:09:04 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1549865344.0.0.85863770649.issue35813@roundup.psfhosted.org> Davin Potts added the comment: Docs and tests are now available in a new PR. I have stayed focused on getting these docs and tests to everyone without delay but that means I have not yet had an opportunity to respond to the helpful comments, thoughtful questions, and threads that have popped up in the last few days. I will follow up with all comments as quickly as possible starting in the morning. There are two topics in particular that I hope will trigger a wider discussion: the api around the SharedMemory class and the inclusion-worthiness of the shareable_wrap function. Regarding the api of SharedMemory, the docs explain that not all of the current input parameters are supportable/enforceable across platforms. I believe we want an api that is relevant across all platforms but at the same time we do not want to unnecessarily suppress/hide functionality that would be useful on some platforms -- there needs to be a balance between these motivations but where do we strike that balance? Regarding the inclusion-worthiness of the shareable_wrap function, I deliberately did not include it in the docs but its docstring in the code explains its purpose. If included, it would drastically simplify working with NumPy arrays; please see the code example in the docs demonstrating the use of NumPy arrays without the aid of the shareable_wrap function. I have received feedback from others using this function also worth discussing. Thank you to everyone who has already looked at the code and shared helpful thoughts -- please have a look at the tests and docs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 01:22:39 2019 From: report at bugs.python.org (Davin Potts) Date: Mon, 11 Feb 2019 06:22:39 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1549866159.91.0.87768873982.issue35813@roundup.psfhosted.org> Davin Potts added the comment: @giampaolo.rodola: Your patch from 3 days ago in issue35917 included additional tests around the SharedMemoryManager which are now causing test failures in my new PR. This is my fault because I altered SharedMemoryManager to no longer support functionality from SyncManager that I thought could be confusing to include. I am just now discovering this and am not immediately sure if simply removing the SharedMemoryManager-relevant lines from your patch is the right solution but I wanted to mention this thought right away. Thank you for discovering that SyncManager was being overlooked in the tests and the nice patch in issue35917. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 02:39:18 2019 From: report at bugs.python.org (Palle Ravn) Date: Mon, 11 Feb 2019 07:39:18 +0000 Subject: [issue35928] socket makefile read-write discards received data In-Reply-To: <1549542632.16.0.548779418887.issue35928@roundup.psfhosted.org> Message-ID: <1549870758.1.0.531419057183.issue35928@roundup.psfhosted.org> Palle Ravn added the comment: >>> f = TextIOWrapper(BufferedRWPair(BytesIO(b"Hello\nYou\n"), BytesIO())) >>> f.readline() 'Hello\n' >>> f.write(_) 6 >>> f.readline() # Returns empty string '' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 02:52:57 2019 From: report at bugs.python.org (Ammar Askar) Date: Mon, 11 Feb 2019 07:52:57 +0000 Subject: [issue35928] socket makefile read-write discards received data In-Reply-To: <1549542632.16.0.548779418887.issue35928@roundup.psfhosted.org> Message-ID: <1549871577.14.0.840061885383.issue35928@roundup.psfhosted.org> Ammar Askar added the comment: Recreatable on master as well, also Martin your suspicion seems correct, reverting https://github.com/python/cpython/commit/23db935bcf258657682e66464bf8512def8af830 fixes it. ---------- nosy: +ammar2, serhiy.storchaka stage: -> needs patch versions: +Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 03:12:22 2019 From: report at bugs.python.org (Tuomas Suutari) Date: Mon, 11 Feb 2019 08:12:22 +0000 Subject: [issue23460] Decimals do not obey ':g' exponential notation formatting rules In-Reply-To: <1549845402.63.0.511336486405.issue23460@roundup.psfhosted.org> Message-ID: Tuomas Suutari added the comment: > What is the status of this issue? I can submit a PR based on Tuomas Suutari's patch. Don't know more about the status, but nobody seemed to care to take my patch forward. If contributions are accepted as GitHub pull requests these days, I can do it myself too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 03:31:21 2019 From: report at bugs.python.org (Stefan Krah) Date: Mon, 11 Feb 2019 08:31:21 +0000 Subject: [issue23460] Decimals do not obey ':g' exponential notation formatting rules In-Reply-To: <1423847721.13.0.666007782647.issue23460@psf.upfronthosting.co.za> Message-ID: <1549873881.16.0.820817165749.issue23460@roundup.psfhosted.org> Stefan Krah added the comment: The patch LGTM, but I'm not sure if we need to document __format__(). Personally I probably wouldn't. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 03:31:34 2019 From: report at bugs.python.org (Stefan Krah) Date: Mon, 11 Feb 2019 08:31:34 +0000 Subject: [issue23460] Decimals do not obey ':g' exponential notation formatting rules In-Reply-To: <1423847721.13.0.666007782647.issue23460@psf.upfronthosting.co.za> Message-ID: <1549873881.16.0.820817165749.issue23460@roundup.psfhosted.org> Stefan Krah added the comment: The patch LGTM, but I'm not sure if we need to document __format__(). Personally I probably wouldn't. ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 03:31:36 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Mon, 11 Feb 2019 08:31:36 +0000 Subject: [issue23460] Decimals do not obey ':g' exponential notation formatting rules In-Reply-To: <1423847721.13.0.666007782647.issue23460@psf.upfronthosting.co.za> Message-ID: <1549873896.78.0.266308581997.issue23460@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: > If contributions are accepted as GitHub pull requests these days, I can do it myself too. GitHub pull requests are accepted. Please see https://devguide.python.org/ . Thanks ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 03:34:10 2019 From: report at bugs.python.org (Stefan Krah) Date: Mon, 11 Feb 2019 08:34:10 +0000 Subject: [issue23460] Decimals do not obey ':g' exponential notation formatting rules In-Reply-To: <1423847721.13.0.666007782647.issue23460@psf.upfronthosting.co.za> Message-ID: <1549874050.22.0.540780258749.issue23460@roundup.psfhosted.org> Stefan Krah added the comment: Yes, these days PRs are the only way to get anything done. Before GitHub it would have been possible to just commit the small diff directly to master. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 03:55:19 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 11 Feb 2019 08:55:19 +0000 Subject: [issue35460] Add PyDict_GetItemStringWithError In-Reply-To: <1544526024.8.0.788709270274.issue35460@psf.upfronthosting.co.za> Message-ID: <1549875319.48.0.633746926533.issue35460@roundup.psfhosted.org> Ronald Oussoren added the comment: I can live without this API, I mostly filed this issue because there's an obvious hole in the API when you look at API description: SetItem, SetItemString, DelItem, DelItemString, GetItem, GetItemString, GetItemWithError, <>. Thanks for the explanations. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 03:56:21 2019 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 11 Feb 2019 08:56:21 +0000 Subject: [issue35953] crosscompilation fails with clang on android In-Reply-To: <1549800196.49.0.252123188802.issue35953@roundup.psfhosted.org> Message-ID: <1549875381.41.0.186438150709.issue35953@roundup.psfhosted.org> Xavier de Gaye added the comment: This problem has been fixed in python 3.7. Most of the changes made to fix the problems of cross-building python for android have been done on python 3.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 04:58:19 2019 From: report at bugs.python.org (Vidar Fauske) Date: Mon, 11 Feb 2019 09:58:19 +0000 Subject: [issue26024] Non-ascii Windows locale names In-Reply-To: <1452090490.23.0.240691672935.issue26024@psf.upfronthosting.co.za> Message-ID: <1549879099.29.0.447499081489.issue26024@roundup.psfhosted.org> Vidar Fauske added the comment: This issue can still be triggered for Python 3.7 by the following line (running on a Windows machine with a Norwegian locale as default): locale.setlocale(locale.LC_ALL, locale.getdefaultlocale()) ---------- versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 05:12:41 2019 From: report at bugs.python.org (Magnien Sebastien) Date: Mon, 11 Feb 2019 10:12:41 +0000 Subject: [issue35962] Slight error in words in [ 2.4.1. String and Bytes literals ] Message-ID: <1549879959.7.0.265215879488.issue35962@roundup.psfhosted.org> New submission from Magnien Sebastien : The documentation reads : " The backslash (\) character is used to escape characters that otherwise have a special meaning, such as newline, backslash itself, or the quote character. " However, 'n' does not "otherwise have a special meaning", nor does it represent a new line. The backslash character does in fact do two different things : 1) It removes special meanings from characters that have one (\\). 2) It assigns a special meaning to normal characters (\n). A better description would therefore be : " The backslash (\) character is used to either escape characters that have a special meaning, such as backslash itself, or the quote character - or give special meaning to characters that do not have one, such as 'n', whose escapment '\n' means 'newline'. " ---------- assignee: docs at python components: Documentation messages: 335205 nosy: Magnien Sebastien, docs at python priority: normal severity: normal status: open title: Slight error in words in [ 2.4.1. String and Bytes literals ] type: enhancement versions: Python 2.7, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 05:47:14 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 11 Feb 2019 10:47:14 +0000 Subject: [issue22062] Fix pathlib.Path.(r)glob doc glitches. In-Reply-To: <1406239862.0.0.293742999811.issue22062@psf.upfronthosting.co.za> Message-ID: <1549882034.63.0.0612698752435.issue22062@roundup.psfhosted.org> miss-islington added the comment: New changeset 537b6caa565ec2fc304ba6f4400cd347ce2af64b by Miss Islington (bot) (Eivind Teig) in branch 'master': bpo-22062: Updated docstring and documentation for pathlib (GH-8519) https://github.com/python/cpython/commit/537b6caa565ec2fc304ba6f4400cd347ce2af64b ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 05:47:33 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 11 Feb 2019 10:47:33 +0000 Subject: [issue22062] Fix pathlib.Path.(r)glob doc glitches. In-Reply-To: <1406239862.0.0.293742999811.issue22062@psf.upfronthosting.co.za> Message-ID: <1549882034.63.0.0612698752435.issue22062@roundup.psfhosted.org> miss-islington added the comment: New changeset 537b6caa565ec2fc304ba6f4400cd347ce2af64b by Miss Islington (bot) (Eivind Teig) in branch 'master': bpo-22062: Updated docstring and documentation for pathlib (GH-8519) https://github.com/python/cpython/commit/537b6caa565ec2fc304ba6f4400cd347ce2af64b ---------- nosy: +miss-islington pull_requests: +11837 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 05:47:34 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 11 Feb 2019 10:47:34 +0000 Subject: [issue22062] Fix pathlib.Path.(r)glob doc glitches. In-Reply-To: <1406239862.0.0.293742999811.issue22062@psf.upfronthosting.co.za> Message-ID: <1549882034.63.0.0612698752435.issue22062@roundup.psfhosted.org> miss-islington added the comment: New changeset 537b6caa565ec2fc304ba6f4400cd347ce2af64b by Miss Islington (bot) (Eivind Teig) in branch 'master': bpo-22062: Updated docstring and documentation for pathlib (GH-8519) https://github.com/python/cpython/commit/537b6caa565ec2fc304ba6f4400cd347ce2af64b ---------- nosy: +miss-islington pull_requests: +11837, 11839 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 05:47:36 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 11 Feb 2019 10:47:36 +0000 Subject: [issue22062] Fix pathlib.Path.(r)glob doc glitches. In-Reply-To: <1406239862.0.0.293742999811.issue22062@psf.upfronthosting.co.za> Message-ID: <1549882034.63.0.0612698752435.issue22062@roundup.psfhosted.org> miss-islington added the comment: New changeset 537b6caa565ec2fc304ba6f4400cd347ce2af64b by Miss Islington (bot) (Eivind Teig) in branch 'master': bpo-22062: Updated docstring and documentation for pathlib (GH-8519) https://github.com/python/cpython/commit/537b6caa565ec2fc304ba6f4400cd347ce2af64b ---------- nosy: +miss-islington pull_requests: +11837, 11838, 11839 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 06:13:58 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Feb 2019 11:13:58 +0000 Subject: [issue21622] ctypes.util incorrectly fails for libraries without DT_SONAME In-Reply-To: <1401593302.24.0.994822187168.issue21622@psf.upfronthosting.co.za> Message-ID: <1549883638.87.0.634084539896.issue21622@roundup.psfhosted.org> Change by STINNER Victor : ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 06:31:25 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Feb 2019 11:31:25 +0000 Subject: =?utf-8?q?=5Bissue35963=5D_Python/symtable=2Ec=3A_warning=3A_enumeration_?= =?utf-8?q?value_=E2=80=98FunctionType=5Fkind=E2=80=99_not_handled_in_swit?= =?utf-8?q?ch_=5B-Wswitch=5D=22?= Message-ID: <1549884684.1.0.958621485817.issue35963@roundup.psfhosted.org> New submission from STINNER Victor : On x86 Gentoo Installed with X 3.x buildbot, there is a compiler warning: "Python/symtable.c:289:5: warning: enumeration value ?FunctionType_kind? not handled in switch [-Wswitch]" https://buildbot.python.org/all/#/builders/103/builds/2067 It might me related to the implementation of the PEP 572 (bpo-35224), but I'm not sure. See also bpo-35878. ---------- components: Interpreter Core messages: 335207 nosy: emilyemorehouse, levkivskyi, vstinner priority: normal severity: normal status: open title: Python/symtable.c: warning: enumeration value ?FunctionType_kind? not handled in switch [-Wswitch]" versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 06:31:47 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Feb 2019 11:31:47 +0000 Subject: [issue35878] ast.c: end_col_offset may be used uninitialized in this function In-Reply-To: <1549020161.52.0.11493245766.issue35878@roundup.psfhosted.org> Message-ID: <1549884707.85.0.516759123856.issue35878@roundup.psfhosted.org> STINNER Victor added the comment: Ivan Levkivskyi fixed the warning with commit 181835d5a9bffee247bc2f7eefc778c1812bc982. I created bpo-35963 Python/symtable.c: warning: enumeration value ?FunctionType_kind? not handled in switch [-Wswitch]" for a remaining warning. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 06:58:20 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 11 Feb 2019 11:58:20 +0000 Subject: =?utf-8?q?=5Bissue35963=5D_Python/symtable=2Ec=3A_warning=3A_enumeration_?= =?utf-8?q?value_=E2=80=98FunctionType=5Fkind=E2=80=99_not_handled_in_swit?= =?utf-8?q?ch_=5B-Wswitch=5D=22?= In-Reply-To: <1549884684.1.0.958621485817.issue35963@roundup.psfhosted.org> Message-ID: <1549886300.14.0.212786397031.issue35963@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 06:58:57 2019 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 11 Feb 2019 11:58:57 +0000 Subject: [issue35960] dataclasses.field does not preserve empty metadata object In-Reply-To: <1549847214.14.0.863197964236.issue35960@roundup.psfhosted.org> Message-ID: <1549886337.65.0.218689124008.issue35960@roundup.psfhosted.org> Change by Eric V. Smith : ---------- assignee: -> eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 06:59:33 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Feb 2019 11:59:33 +0000 Subject: [issue18283] shutil.which() should support bytes In-Reply-To: <1371914951.06.0.665120918364.issue18283@psf.upfronthosting.co.za> Message-ID: <1549886373.5.0.503237601897.issue18283@roundup.psfhosted.org> STINNER Victor added the comment: > Would it be worthwhile to make a PR of this for 3.8? Yes. Would you be interested to convert my old patch to a fresh PR? I can help you to work on that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 07:03:05 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 11 Feb 2019 12:03:05 +0000 Subject: [issue22062] Fix pathlib.Path.(r)glob doc glitches. In-Reply-To: <1406239862.0.0.293742999811.issue22062@psf.upfronthosting.co.za> Message-ID: <1549886585.38.0.524268084798.issue22062@roundup.psfhosted.org> miss-islington added the comment: New changeset 2259b5af3c711b40d2b81eacc1b5d75cda1ae3e2 by Miss Islington (bot) in branch '3.7': [3.7] bpo-22062: Updated docstring and documentation for pathlib (GH-8519) (GH-11817) https://github.com/python/cpython/commit/2259b5af3c711b40d2b81eacc1b5d75cda1ae3e2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 07:03:20 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 11 Feb 2019 12:03:20 +0000 Subject: [issue22062] Fix pathlib.Path.(r)glob doc glitches. In-Reply-To: <1406239862.0.0.293742999811.issue22062@psf.upfronthosting.co.za> Message-ID: <1549886585.38.0.524268084798.issue22062@roundup.psfhosted.org> miss-islington added the comment: New changeset 2259b5af3c711b40d2b81eacc1b5d75cda1ae3e2 by Miss Islington (bot) in branch '3.7': [3.7] bpo-22062: Updated docstring and documentation for pathlib (GH-8519) (GH-11817) https://github.com/python/cpython/commit/2259b5af3c711b40d2b81eacc1b5d75cda1ae3e2 ---------- stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 07:40:48 2019 From: report at bugs.python.org (HFM) Date: Mon, 11 Feb 2019 12:40:48 +0000 Subject: [issue35964] shutil.make_archive (xxx, tar, root_dir) is adding './' entry to archive which is wrong Message-ID: <1549888846.57.0.721579437713.issue35964@roundup.psfhosted.org> New submission from HFM : Running shutil.make_archive('a', 'tar', 'subdir') is created wrong and not really needed entry "./" which is visible in tarfile.Tarfile.list(): ['./', 'foo/', 'hello.txt', 'foo/bar.txt'] I have tested and found this issue in the following versions of python: 2.7.15rc1 FOUND 3.6.7 FOUND 3.7.1 FOUND I've attached a simple script which illustrates problem. Tested on Ubuntu Linux with mentioned python versions. Similar issue has been fixed for 'zip' (https://bugs.python.org/issue28488) but exists for 'tar' archives. ---------- components: Library (Lib) files: tarfile_test.tar messages: 335211 nosy: HFM, alanmcintyre, bialix, python-dev, serhiy.storchaka, tarek, twouters priority: normal severity: normal status: open title: shutil.make_archive (xxx, tar, root_dir) is adding './' entry to archive which is wrong versions: Python 2.7, Python 3.6, Python 3.7 Added file: https://bugs.python.org/file48132/tarfile_test.tar _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 08:04:42 2019 From: report at bugs.python.org (SylvainDe) Date: Mon, 11 Feb 2019 13:04:42 +0000 Subject: [issue35965] Behavior for unittest.assertRaisesRegex differs depending on whether it is used as a context manager Message-ID: <1549890280.86.0.630330095869.issue35965@roundup.psfhosted.org> New submission from SylvainDe : On some Python versions, the following pieces of code have a different behavior which is not something I'd expect: ``` DESCRIPT_REQUIRES_TYPE_RE = r"descriptor '\w+' requires a 'set' object but received a 'int'" ... def test_assertRaisesRegex(self): self.assertRaisesRegex(TypeError, DESCRIPT_REQUIRES_TYPE_RE, set.add, 0) def test_assertRaisesRegex_contextman(self): with self.assertRaisesRegex(TypeError, DESCRIPT_REQUIRES_TYPE_RE): set.add(0) ``` On impacted Python versions, only test_assertRaisesRegex_contextman fails while test_assertRaisesRegex works fine. Logs for the failure: ``` ====================================================================== FAIL: test_assertRaisesRegex_contextman (didyoumean_sugg_tests.SetAddIntRegexpTests) ---------------------------------------------------------------------- TypeError: descriptor 'add' for 'set' objects doesn't apply to 'int' object During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/travis/build/.../didyoumean/didyoumean_sugg_tests.py", line 23, in test_assertRaisesRegex_contextman set.add(0) AssertionError: "descriptor '\w+' requires a 'set' object but received a 'int'" does not match "descriptor 'add' for 'set' objects doesn't apply to 'int' object" ``` Either I am missing something or it looks like a bug to me. If needed, more details/context can be found on the StackOverflow question I opened: https://stackoverflow.com/questions/54612348/different-error-message-when-unittest-assertraisesregex-is-called-as-a-context-m . I can provide the details directly here if it is relevant. ---------- components: Tests messages: 335212 nosy: SylvainDe priority: normal severity: normal status: open title: Behavior for unittest.assertRaisesRegex differs depending on whether it is used as a context manager type: behavior versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 08:11:58 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 11 Feb 2019 13:11:58 +0000 Subject: [issue35965] Behavior for unittest.assertRaisesRegex differs depending on whether it is used as a context manager In-Reply-To: <1549890280.86.0.630330095869.issue35965@roundup.psfhosted.org> Message-ID: <1549890718.82.0.211764446542.issue35965@roundup.psfhosted.org> Ronald Oussoren added the comment: On which Python versions do you see this problem? Both tests pass on my system (macOS 10.4.3) with Python 3.7.2, 3.6.3 and 3.5.5. ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 08:15:08 2019 From: report at bugs.python.org (SylvainDe) Date: Mon, 11 Feb 2019 13:15:08 +0000 Subject: [issue35965] Behavior for unittest.assertRaisesRegex differs depending on whether it is used as a context manager In-Reply-To: <1549890280.86.0.630330095869.issue35965@roundup.psfhosted.org> Message-ID: <1549890908.81.0.132159697244.issue35965@roundup.psfhosted.org> SylvainDe added the comment: That's the very weird thing. I've been unable to reproduce this locally but it can be seen on Travis runs. Here are the results so far (Versions numbers are retrieved with python -VV and python -c "import sys; print(sys._git)"): On some versions, both tests pass: Python 3.6 and before Python 3.7.0a4+ (heads/master:4666ec5, Jan 26 2018, 04:14:24) - [GCC 4.8.4] - ('CPython', 'heads/master', '4666ec5')) On some versions, both tests fail: Python 3.8.0a1+ (heads/master:8a03ff2, Feb 9 2019, 07:30:26) [GCC 5.4.0 20160609] - ('CPython', 'heads/master', '8a03ff2') On some versions, only test_assertRaisesRegex_contextman fails which is what I find confusing: Python 3.7.1 (default, Dec 5 2018, 18:09:53) [GCC 5.4.0 20160609] - ('CPython', '', '') Python 3.7.2+ (heads/3.7:3fcfef3, Feb 9 2019, 07:30:09) [GCC 5.4.0 20160609] - ('CPython', 'heads/3.7', '3fcfef3') Corresponding Travis build: https://travis-ci.org/SylvainDe/DidYouMean-Python/builds/491118939 . Corresponding code on Github: https://github.com/SylvainDe/DidYouMean-Python/blob/issue36_investigation/didyoumean/didyoumean_sugg_tests.py I'm happy to add more debug information and retrigger builds if needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 08:27:50 2019 From: report at bugs.python.org (sheiun) Date: Mon, 11 Feb 2019 13:27:50 +0000 Subject: [issue35966] Didn't raise "StopIteration" Error when I use "yield" in the function Message-ID: <1549891669.28.0.260534836361.issue35966@roundup.psfhosted.org> New submission from sheiun : Python 3.6.7 |Anaconda custom (64-bit)| (default, Oct 28 2018, 19:44:12) [MSC v.1915 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> def generate_loop(): ... for i in range(10): ... print(i) ... # should raise StopIteration when i > 5 ... k = next(j for j in range(5) if j == i) ... print(k) ... yield k ... >>> >>> def generate(): ... # should raise StopIteration ... k = next(j for j in range(5) if j == 6) ... yield k ... >>> >>> print(list(generate_loop())) 0 0 1 1 2 2 3 3 4 4 5 [0, 1, 2, 3, 4] >>> >>> print(list(generate())) [] >>> >>> k = next(j for j in range(5) if j == 6) Traceback (most recent call last): File "", line 1, in StopIteration >>> ---------- components: Library (Lib) files: test.py messages: 335215 nosy: sheiun priority: normal severity: normal status: open title: Didn't raise "StopIteration" Error when I use "yield" in the function versions: Python 3.6 Added file: https://bugs.python.org/file48133/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 08:31:49 2019 From: report at bugs.python.org (sheiun) Date: Mon, 11 Feb 2019 13:31:49 +0000 Subject: [issue35966] Didn't raise "StopIteration" Error when I use "yield" in the function In-Reply-To: <1549891669.28.0.260534836361.issue35966@roundup.psfhosted.org> Message-ID: <1549891909.31.0.0607349100074.issue35966@roundup.psfhosted.org> sheiun added the comment: But it still can catch by using try/except >>> def generate_loop_stopiteration(): ... for i in range(10): ... print(i) ... # should raise StopIteration when i > 5 ... try: ... k = next(j for j in range(5) if j == i) ... except StopIteration: ... print('catch') ... print(k) ... yield k ... >>> print(list(generate_loop_stopiteration())) 0 0 1 1 2 2 3 3 4 4 5 catch 4 6 catch 4 7 catch 4 8 catch 4 9 catch 4 [0, 1, 2, 3, 4, 4, 4, 4, 4, 4] >>> ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 08:32:03 2019 From: report at bugs.python.org (sheiun) Date: Mon, 11 Feb 2019 13:32:03 +0000 Subject: [issue35966] Didn't raise "StopIteration" Error when I use "yield" in the function In-Reply-To: <1549891669.28.0.260534836361.issue35966@roundup.psfhosted.org> Message-ID: <1549891923.49.0.130938082029.issue35966@roundup.psfhosted.org> Change by sheiun : ---------- nosy: -sheiun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 08:46:42 2019 From: report at bugs.python.org (SilentGhost) Date: Mon, 11 Feb 2019 13:46:42 +0000 Subject: [issue35966] Didn't raise "StopIteration" Error when I use "yield" in the function In-Reply-To: <1549891669.28.0.260534836361.issue35966@roundup.psfhosted.org> Message-ID: <1549892802.88.0.515147114848.issue35966@roundup.psfhosted.org> SilentGhost added the comment: Within a generator function, StopIteration exception is a sign that generator is finished. This is why this exception is caught automatically, and closes generator. This is normal and documented behaviour of generators. ---------- nosy: +SilentGhost, sheiun resolution: -> not a bug stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 09:03:41 2019 From: report at bugs.python.org (Oskar Persson) Date: Mon, 11 Feb 2019 14:03:41 +0000 Subject: [issue35964] shutil.make_archive (xxx, tar, root_dir) is adding './' entry to archive which is wrong In-Reply-To: <1549888846.57.0.721579437713.issue35964@roundup.psfhosted.org> Message-ID: <1549893821.55.0.151994547936.issue35964@roundup.psfhosted.org> Change by Oskar Persson : ---------- nosy: +Oskar Persson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 09:05:40 2019 From: report at bugs.python.org (Jason R. Coombs) Date: Mon, 11 Feb 2019 14:05:40 +0000 Subject: [issue7850] platform.system() should be "macosx" instead of "Darwin" on OSX In-Reply-To: <1265236812.59.0.190434450591.issue7850@psf.upfronthosting.co.za> Message-ID: <1549893940.0.0.517051944463.issue7850@roundup.psfhosted.org> Jason R. Coombs added the comment: This issue now needs to consider that Mac OS X was renamed to macOS. ---------- nosy: +jaraco _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 09:12:04 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Feb 2019 14:12:04 +0000 Subject: [issue7850] platform.system() should be "macosx" instead of "Darwin" on OSX In-Reply-To: <1265236812.59.0.190434450591.issue7850@psf.upfronthosting.co.za> Message-ID: <1549894324.66.0.547906972242.issue7850@roundup.psfhosted.org> STINNER Victor added the comment: I suggest to close this issue. @Ronald: Or do you think that something should still be done on macOS in the platform module? This issue looks like a duplicate of bpo-35516. It has been decided that platform.system_alias() doesn't replace Darwin with macOS (it's now explained in a comment: see my commit 60875db2f67815d7d181c552bfac59e8c97619e3). I modified platform.platform() to return "macOS" rather than "darwin" on macOS: "bpo-35344: platform.platform() uses mac_ver() on macOS (GH-10780)" (commit ea0ca218b0c28b2af2b1f6a5d3383569de7fc2c1). ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 09:29:25 2019 From: report at bugs.python.org (Jason R. Coombs) Date: Mon, 11 Feb 2019 14:29:25 +0000 Subject: [issue35967] Better platform.processor support Message-ID: <1549895363.53.0.252912531241.issue35967@roundup.psfhosted.org> New submission from Jason R. Coombs : or: Unable to implement 'uname' on Python due to recursive call or: platform.uname() should avoid calling `uname` in a subprocess In [this issue](https://github.com/jaraco/cmdix/issues/1), I stumbled across a strange and somewhat unintuitive behavior. This project attempts to supply a `uname` executable implemented in Python, so that such functionality could be exposed on any platform including Windows. What I found, however, was that because the stdlib `platform` module actually invokes `sh -c uname -p` during most any call of the module (https://github.com/python/cpython/blob/9db56fb8faaa3cd66e7fe82740a4ae4d786bb27f/Lib/platform.py#L836), attempting to use that functionality on a system where `uname` is implemented by Python (and on the path), will probably fail after a long delay due to infinite recursion. Moreover, the _only_ call that's currently invoking `uname` in a subprocess is the `processor` resolution, which I suspect is rarely used, in part because the results from it are inconsistent and not particularly useful. For example, on Windows, you get a detailed description from the hardware: 'Intel64 Family 6 Model 142 Stepping 9, GenuineIntel' On macOS, you get just 'i386'. And on Linux, I see 'x86_64' or sometimes just '' (in docker). To make matters even worse, this `uname -p` call happens unconditionally on non-Windows systems for nearly any call in platform. As a result, it's impossible to suppress the invocation of `uname`, especially when functionality like `pkg_resources` and its environment markers is invoked early. I suggest instead the platform module should (a) resolve processor information in a more uniform manner and (b) not ever call uname, maybe [with something like this](https://github.com/jaraco/cmdix/blob/d61e6d3b40032a25feff0a9fb2a79afaa7dcd4e0/cmdix/command/uname.py#L53-L77). At the very least, the `uname` call should be late-bound so that it's not invoked unconditionally for rarely-used information. After some period for comment, I'll draft an implementation. ---------- messages: 335220 nosy: jaraco priority: normal severity: normal status: open title: Better platform.processor support _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 09:36:05 2019 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 11 Feb 2019 14:36:05 +0000 Subject: [issue35959] math.prod(range(10)) caues segfault In-Reply-To: <1549825733.5.0.0745476001214.issue35959@roundup.psfhosted.org> Message-ID: <1549895765.56.0.235481206194.issue35959@roundup.psfhosted.org> Mark Dickinson added the comment: This approach to overflow checking needs reworking; the current code, in lines like: long x = i_result * b; induces undefined behaviour on overflow. That's something we need to avoid. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 09:39:43 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Mon, 11 Feb 2019 14:39:43 +0000 Subject: [issue35918] multiprocessing's SyncManager.dict.has_key() method is broken In-Reply-To: <1549473735.16.0.515862791139.issue35918@roundup.psfhosted.org> Message-ID: <1549895983.52.0.217305359881.issue35918@roundup.psfhosted.org> R?mi Lapeyre added the comment: Hi @giampaolo.rodola, I will post a PR for this issue. ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 09:45:41 2019 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 11 Feb 2019 14:45:41 +0000 Subject: [issue35959] math.prod(range(10)) caues segfault In-Reply-To: <1549825733.5.0.0745476001214.issue35959@roundup.psfhosted.org> Message-ID: <1549896341.6.0.521999090632.issue35959@roundup.psfhosted.org> Mark Dickinson added the comment: See below for a link to the Python 2.7 code for int * int multiplication (which needs to detect overflow so that it knows when to promote to long): https://github.com/python/cpython/blob/2f1a317d5fdc45b9d714b067906f612f636ba08e/Objects/intobject.c#L496-L518 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 09:48:55 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Mon, 11 Feb 2019 14:48:55 +0000 Subject: [issue35959] math.prod(range(10)) caues segfault In-Reply-To: <1549825733.5.0.0745476001214.issue35959@roundup.psfhosted.org> Message-ID: <1549896535.78.0.619838163533.issue35959@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: @pablogsal I am reopening this since this has an open PR though original issue was fixed. Feel free to close this if this can be discussed in a separate issue. ---------- resolution: fixed -> stage: resolved -> patch review status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 09:49:39 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Mon, 11 Feb 2019 14:49:39 +0000 Subject: [issue18283] shutil.which() should support bytes In-Reply-To: <1371914951.06.0.665120918364.issue18283@psf.upfronthosting.co.za> Message-ID: <1549896579.82.0.578562960024.issue18283@roundup.psfhosted.org> Change by Cheryl Sabella : ---------- pull_requests: +11840 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 09:53:25 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 11 Feb 2019 14:53:25 +0000 Subject: [issue35959] math.prod(range(10)) caues segfault In-Reply-To: <1549825733.5.0.0745476001214.issue35959@roundup.psfhosted.org> Message-ID: <1549896805.77.0.467215443198.issue35959@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: @Mark Dickinson Thanks for the links. I had opened yesterday PR11809 addressing the UB and adding more tests. Could you review the PR? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 09:57:33 2019 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 11 Feb 2019 14:57:33 +0000 Subject: [issue35959] math.prod(range(10)) caues segfault In-Reply-To: <1549825733.5.0.0745476001214.issue35959@roundup.psfhosted.org> Message-ID: <1549897053.84.0.0961323370403.issue35959@roundup.psfhosted.org> Mark Dickinson added the comment: @Pablo: Thanks; I saw the PR. It looks as though the troublesome line long x = i_result * b; is still there in that PR, though. Or am I misreading? The difficulty here is that the check for overflow has to happen as a means of preventing invoking undefined behaviour; it doesn't really work to invoke the undefined behaviour first and then check to see what went wrong. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 09:58:33 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 11 Feb 2019 14:58:33 +0000 Subject: [issue26024] Non-ascii Windows locale names In-Reply-To: <1452090490.23.0.240691672935.issue26024@psf.upfronthosting.co.za> Message-ID: <1549897113.68.0.987152751756.issue26024@roundup.psfhosted.org> Steve Dower added the comment: We should switch to _wsetlocale, or else come up with a more sensible mapping that makes sense between platforms (like we have for encodings already). I suspect the latter requires proper design and discussion, so it's worth doing the first part immediately. ---------- versions: +Python 3.8 -Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 10:04:59 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 11 Feb 2019 15:04:59 +0000 Subject: [issue7850] platform.system() should be "macosx" instead of "Darwin" on OSX In-Reply-To: <1265236812.59.0.190434450591.issue7850@psf.upfronthosting.co.za> Message-ID: <1549897499.51.0.0414465862593.issue7850@roundup.psfhosted.org> Ronald Oussoren added the comment: This issue can be closed. Status quo wins due to backward compatibility concerns. BTW. The primary reason for proposing "macosx" as the return value for platform.system() is that the platform name as used in egg files (at the time, now wheels) is "macosx". That, and having two clearly different platforms with the same name (macOS and iOS). And one final note: I definitely wouldn't mind having an API in platform that returns the marketing name and version of the current system (like mac_ver and linux_distribution). But that API cannot be system_alias because its API contract does not give it access to enough information. Such an API could be designed in a new issue. ---------- resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 10:09:35 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 11 Feb 2019 15:09:35 +0000 Subject: [issue35959] math.prod(range(10)) caues segfault In-Reply-To: <1549825733.5.0.0745476001214.issue35959@roundup.psfhosted.org> Message-ID: <1549897775.09.0.766200863735.issue35959@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: @Mark long x = i_result * b; is still on the PR but the check for overflow does not use x. I will update the PR to move that line inside the overflow-safe block to prevent UB from happening and affecting the check itself (or the rest of the code). Thanks for pointing that out! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 10:24:55 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Mon, 11 Feb 2019 15:24:55 +0000 Subject: [issue35918] multiprocessing's SyncManager.dict.has_key() method is broken In-Reply-To: <1549473735.16.0.515862791139.issue35918@roundup.psfhosted.org> Message-ID: <1549898695.47.0.441265404272.issue35918@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- keywords: +patch pull_requests: +11841 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 10:25:06 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Mon, 11 Feb 2019 15:25:06 +0000 Subject: [issue35918] multiprocessing's SyncManager.dict.has_key() method is broken In-Reply-To: <1549473735.16.0.515862791139.issue35918@roundup.psfhosted.org> Message-ID: <1549898706.29.0.975886415039.issue35918@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- keywords: +patch, patch pull_requests: +11841, 11842 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 10:25:15 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Mon, 11 Feb 2019 15:25:15 +0000 Subject: [issue35918] multiprocessing's SyncManager.dict.has_key() method is broken In-Reply-To: <1549473735.16.0.515862791139.issue35918@roundup.psfhosted.org> Message-ID: <1549898715.65.0.862816436367.issue35918@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- keywords: +patch, patch, patch pull_requests: +11841, 11842, 11843 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 10:25:52 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Mon, 11 Feb 2019 15:25:52 +0000 Subject: [issue35918] multiprocessing's SyncManager.dict.has_key() method is broken In-Reply-To: <1549473735.16.0.515862791139.issue35918@roundup.psfhosted.org> Message-ID: <1549898752.31.0.570307699256.issue35918@roundup.psfhosted.org> R?mi Lapeyre added the comment: has_key method has been removed in Python3 so I think we can remove it from the DictProxy as well as nobody should be relying on it anymore. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 10:44:15 2019 From: report at bugs.python.org (Roundup Robot) Date: Mon, 11 Feb 2019 15:44:15 +0000 Subject: [issue35889] sqlite3.Row doesn't have useful repr In-Reply-To: <1549112536.04.0.744689521798.issue35889@roundup.psfhosted.org> Message-ID: <1549899855.75.0.20118556946.issue35889@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch pull_requests: +11844 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 10:44:23 2019 From: report at bugs.python.org (Roundup Robot) Date: Mon, 11 Feb 2019 15:44:23 +0000 Subject: [issue35889] sqlite3.Row doesn't have useful repr In-Reply-To: <1549112536.04.0.744689521798.issue35889@roundup.psfhosted.org> Message-ID: <1549899863.04.0.309654054874.issue35889@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch, patch pull_requests: +11844, 11845 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 10:44:31 2019 From: report at bugs.python.org (Roundup Robot) Date: Mon, 11 Feb 2019 15:44:31 +0000 Subject: [issue35889] sqlite3.Row doesn't have useful repr In-Reply-To: <1549112536.04.0.744689521798.issue35889@roundup.psfhosted.org> Message-ID: <1549899871.84.0.22588971967.issue35889@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch, patch, patch pull_requests: +11844, 11845, 11847 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 10:44:41 2019 From: report at bugs.python.org (Roundup Robot) Date: Mon, 11 Feb 2019 15:44:41 +0000 Subject: [issue35889] sqlite3.Row doesn't have useful repr In-Reply-To: <1549112536.04.0.744689521798.issue35889@roundup.psfhosted.org> Message-ID: <1549899881.47.0.670353362958.issue35889@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch, patch, patch, patch pull_requests: +11844, 11845, 11846, 11847 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 10:57:44 2019 From: report at bugs.python.org (Jason R. Coombs) Date: Mon, 11 Feb 2019 15:57:44 +0000 Subject: [issue35955] difflib reports incorrect location of mismatch In-Reply-To: <1549807918.24.0.168325596231.issue35955@roundup.psfhosted.org> Message-ID: <1549900664.65.0.834268182779.issue35955@roundup.psfhosted.org> Jason R. Coombs added the comment: I'm re-opening this issue as it does seem to apply stdlib (difflib.ndiff), which is why I encountered it both in unittest and pytest. Thanks xtreak for the distilled example. ---------- resolution: third party -> stage: resolved -> status: closed -> open title: unittest assertEqual reports incorrect location of mismatch -> difflib reports incorrect location of mismatch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 11:05:31 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 11 Feb 2019 16:05:31 +0000 Subject: [issue35918] multiprocessing's SyncManager.dict.has_key() method is broken In-Reply-To: <1549473735.16.0.515862791139.issue35918@roundup.psfhosted.org> Message-ID: <1549901131.16.0.834650129175.issue35918@roundup.psfhosted.org> Antoine Pitrou added the comment: That sounds fine to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 11:06:24 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Mon, 11 Feb 2019 16:06:24 +0000 Subject: [issue35965] Behavior for unittest.assertRaisesRegex differs depending on whether it is used as a context manager In-Reply-To: <1549890280.86.0.630330095869.issue35965@roundup.psfhosted.org> Message-ID: <1549901184.68.0.353496831009.issue35965@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Is this something related to running under coverage? With the failure commit on Travis I built the binary and there are no failures with unittest but the tests fail with coverage. Running 'set.add(0)' under coverage and as normal file generates different error messages. Can you try running with unittest to see if there are any discrepancies? I am adding @nedbat who might have a better explanation. # Python version (foo-venv) karthi at ubuntu-s-1vcpu-1gb-blr1-01:~/cpython$ python Python 3.8.0a1+ (tags/v3.8.0a1-23-g8a03ff2ff4:8a03ff2ff4, Feb 11 2019, 15:51:54) [GCC 5.4.0 20160609] on linux Type "help", "copyright", "credits" or "license" for more information. >>> # set.add(0) under coverage and as a file (foo-venv) karthi at ubuntu-s-1vcpu-1gb-blr1-01:~/cpython$ echo "set.add(0)" > foo.py (foo-venv) karthi at ubuntu-s-1vcpu-1gb-blr1-01:~/cpython$ coverage run foo.py Traceback (most recent call last): File "foo.py", line 1, in set.add(0) TypeError: descriptor 'add' for 'set' objects doesn't apply to 'int' object (foo-venv) karthi at ubuntu-s-1vcpu-1gb-blr1-01:~/cpython$ python foo.py Traceback (most recent call last): File "foo.py", line 1, in set.add(0) TypeError: descriptor 'add' requires a 'set' object but received a 'int' # Running the reported case will fail while running under coverage (foo-venv) karthi at ubuntu-s-1vcpu-1gb-blr1-01:~/cpython$ python -m unittest discover --start-directory=/tmp/suggest --pattern=*.py .. ---------------------------------------------------------------------- Ran 2 tests in 0.002s OK (foo-venv) karthi at ubuntu-s-1vcpu-1gb-blr1-01:~/cpython$ coverage run -m unittest discover --start-directory=/tmp/suggest --pattern=*.py FF ====================================================================== FAIL: test_assertRaisesRegex (foo.FooTest) ---------------------------------------------------------------------- TypeError: descriptor 'add' for 'set' objects doesn't apply to 'int' object During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/tmp/suggest/foo.py", line 8, in test_assertRaisesRegex self.assertRaisesRegex(TypeError, DESCRIPT_REQUIRES_TYPE_RE, set.add, 0) AssertionError: "descriptor '\w+' requires a 'set' object but received a 'int'" does not match "descriptor 'add' for 'set' objects doesn't apply to 'int' object" ====================================================================== FAIL: test_assertRaisesRegex_contextman (foo.FooTest) ---------------------------------------------------------------------- TypeError: descriptor 'add' for 'set' objects doesn't apply to 'int' object During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/tmp/suggest/foo.py", line 12, in test_assertRaisesRegex_contextman set.add(0) AssertionError: "descriptor '\w+' requires a 'set' object but received a 'int'" does not match "descriptor 'add' for 'set' objects doesn't apply to 'int' object" ---------------------------------------------------------------------- Ran 2 tests in 0.003s FAILED (failures=2) # Executed test (foo-venv) karthi at ubuntu-s-1vcpu-1gb-blr1-01:~/cpython$ cat /tmp/suggest/foo.py import unittest DESCRIPT_REQUIRES_TYPE_RE = r"descriptor '\w+' requires a 'set' object but received a 'int'" class FooTest(unittest.TestCase): def test_assertRaisesRegex(self): self.assertRaisesRegex(TypeError, DESCRIPT_REQUIRES_TYPE_RE, set.add, 0) def test_assertRaisesRegex_contextman(self): with self.assertRaisesRegex(TypeError, DESCRIPT_REQUIRES_TYPE_RE): set.add(0) if __name__ == "__main__": unittest.main() ---------- nosy: +nedbat, xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 11:10:47 2019 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 11 Feb 2019 16:10:47 +0000 Subject: [issue35766] Merge typed_ast back into CPython In-Reply-To: <1547771581.08.0.389360423635.issue35766@roundup.psfhosted.org> Message-ID: <1549901447.89.0.61163975168.issue35766@roundup.psfhosted.org> Guido van Rossum added the comment: New changeset 4b250fc1da9c893803cf724a4974450b5e10bd8a by Guido van Rossum in branch 'master': bpo-35766 follow-up: Add an error check to new_type_comment() (#11766) https://github.com/python/cpython/commit/4b250fc1da9c893803cf724a4974450b5e10bd8a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 11:12:19 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Mon, 11 Feb 2019 16:12:19 +0000 Subject: [issue35955] difflib reports incorrect location of mismatch In-Reply-To: <1549807918.24.0.168325596231.issue35955@roundup.psfhosted.org> Message-ID: <1549901539.25.0.119164969793.issue35955@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: I have tried with different places where only '-' and 'w' differ. They seemed to produce correct diff except for this once case where the diff was confusing. ---------- nosy: +tim.peters type: -> behavior versions: +Python 2.7, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 11:14:31 2019 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 11 Feb 2019 16:14:31 +0000 Subject: =?utf-8?q?=5Bissue35963=5D_Python/symtable=2Ec=3A_warning=3A_enumeration_?= =?utf-8?q?value_=E2=80=98FunctionType=5Fkind=E2=80=99_not_handled_in_swit?= =?utf-8?q?ch_=5B-Wswitch=5D=22?= In-Reply-To: <1549884684.1.0.958621485817.issue35963@roundup.psfhosted.org> Message-ID: <1549901671.24.0.530271902104.issue35963@roundup.psfhosted.org> Guido van Rossum added the comment: Sure, I'll fix it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 11:18:37 2019 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 11 Feb 2019 16:18:37 +0000 Subject: =?utf-8?q?=5Bissue35963=5D_Python/symtable=2Ec=3A_warning=3A_enumeration_?= =?utf-8?q?value_=E2=80=98FunctionType=5Fkind=E2=80=99_not_handled_in_swit?= =?utf-8?q?ch_=5B-Wswitch=5D=22?= In-Reply-To: <1549884684.1.0.958621485817.issue35963@roundup.psfhosted.org> Message-ID: <1549901917.12.0.263847163078.issue35963@roundup.psfhosted.org> Change by Guido van Rossum : ---------- keywords: +patch pull_requests: +11848 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 11:18:43 2019 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 11 Feb 2019 16:18:43 +0000 Subject: =?utf-8?q?=5Bissue35963=5D_Python/symtable=2Ec=3A_warning=3A_enumeration_?= =?utf-8?q?value_=E2=80=98FunctionType=5Fkind=E2=80=99_not_handled_in_swit?= =?utf-8?q?ch_=5B-Wswitch=5D=22?= In-Reply-To: <1549884684.1.0.958621485817.issue35963@roundup.psfhosted.org> Message-ID: <1549901923.89.0.206199679568.issue35963@roundup.psfhosted.org> Change by Guido van Rossum : ---------- keywords: +patch, patch pull_requests: +11848, 11849 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 11:18:50 2019 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 11 Feb 2019 16:18:50 +0000 Subject: =?utf-8?q?=5Bissue35963=5D_Python/symtable=2Ec=3A_warning=3A_enumeration_?= =?utf-8?q?value_=E2=80=98FunctionType=5Fkind=E2=80=99_not_handled_in_swit?= =?utf-8?q?ch_=5B-Wswitch=5D=22?= In-Reply-To: <1549884684.1.0.958621485817.issue35963@roundup.psfhosted.org> Message-ID: <1549901930.81.0.311174182793.issue35963@roundup.psfhosted.org> Change by Guido van Rossum : ---------- keywords: +patch, patch, patch pull_requests: +11848, 11849, 11850 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 11:19:20 2019 From: report at bugs.python.org (SylvainDe) Date: Mon, 11 Feb 2019 16:19:20 +0000 Subject: [issue35965] Behavior for unittest.assertRaisesRegex differs depending on whether it is used as a context manager In-Reply-To: <1549890280.86.0.630330095869.issue35965@roundup.psfhosted.org> Message-ID: <1549901960.72.0.696645095353.issue35965@roundup.psfhosted.org> SylvainDe added the comment: This is a brilliant idea! I'll give it a try and keep you posted. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 11:39:58 2019 From: report at bugs.python.org (Dylan Lloyd) Date: Mon, 11 Feb 2019 16:39:58 +0000 Subject: [issue35968] lib2to3 cannot parse rf'' Message-ID: <1549903197.05.0.60525639701.issue35968@roundup.psfhosted.org> New submission from Dylan Lloyd : ``` #!/usr/bin/env python # -*- coding: utf-8 -*- regex_format = rf'' ``` ``` yapf poc.py ``` ``` Traceback (most recent call last): File "lib/python3.6/site-packages/yapf/yapflib/pytree_utils.py", line 115, in ParseCodeToTree tree = parser_driver.parse_string(code, debug=False) File "lib/python3.6/lib2to3/pgen2/driver.py", line 107, in parse_string return self.parse_tokens(tokens, debug) File "lib/python3.6/lib2to3/pgen2/driver.py", line 72, in parse_tokens if p.addtoken(type, value, (prefix, start)): File "lib/python3.6/lib2to3/pgen2/parse.py", line 159, in addtoken raise ParseError("bad input", type, value, context) lib2to3.pgen2.parse.ParseError: bad input: type=3, value="''", context=('', (4, 17)) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "bin/yapf", line 10, in sys.exit(run_main()) File "lib/python3.6/site-packages/yapf/__init__.py", line 326, in run_main sys.exit(main(sys.argv)) File "lib/python3.6/site-packages/yapf/__init__.py", line 213, in main verbose=args.verbose) File "lib/python3.6/site-packages/yapf/__init__.py", line 263, in FormatFiles in_place, print_diff, verify, verbose) File "lib/python3.6/site-packages/yapf/__init__.py", line 289, in _FormatFile logger=logging.warning) File "lib/python3.6/site-packages/yapf/yapflib/yapf_api.py", line 91, in FormatFile verify=verify) File "lib/python3.6/site-packages/yapf/yapflib/yapf_api.py", line 129, in FormatCode tree = pytree_utils.ParseCodeToTree(unformatted_source) File "lib/python3.6/site-packages/yapf/yapflib/pytree_utils.py", line 121, in ParseCodeToTree tree = parser_driver.parse_string(code, debug=False) File "lib/python3.6/lib2to3/pgen2/driver.py", line 107, in parse_string return self.parse_tokens(tokens, debug) File "lib/python3.6/lib2to3/pgen2/driver.py", line 72, in parse_tokens if p.addtoken(type, value, (prefix, start)): File "lib/python3.6/lib2to3/pgen2/parse.py", line 159, in addtoken raise ParseError("bad input", type, value, context) lib2to3.pgen2.parse.ParseError: bad input: type=3, value="''", context=('', (4, 17)) ``` ---------- components: 2to3 (2.x to 3.x conversion tool) messages: 335238 nosy: majuscule priority: normal severity: normal status: open title: lib2to3 cannot parse rf'' type: crash versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 12:00:56 2019 From: report at bugs.python.org (SylvainDe) Date: Mon, 11 Feb 2019 17:00:56 +0000 Subject: [issue35965] Behavior for unittest.assertRaisesRegex differs depending on whether it is used as a context manager In-Reply-To: <1549890280.86.0.630330095869.issue35965@roundup.psfhosted.org> Message-ID: <1549904456.74.0.905882120933.issue35965@roundup.psfhosted.org> SylvainDe added the comment: I have no explanation whatsoever but removing the call to coverage seems to remove the issue: https://travis-ci.org/SylvainDe/DidYouMean-Python/builds/491727724 . I guess we can close this issue - sorry for the inconvenience. @nedbat: do you want me to open an issue in coverage ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 12:02:42 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Mon, 11 Feb 2019 17:02:42 +0000 Subject: [issue35968] lib2to3 cannot parse rf'' In-Reply-To: <1549903197.05.0.60525639701.issue35968@roundup.psfhosted.org> Message-ID: <1549904562.57.0.981509926818.issue35968@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Seems related : issue33266 ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 12:18:39 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Mon, 11 Feb 2019 17:18:39 +0000 Subject: [issue35968] lib2to3 cannot parse rf'' In-Reply-To: <1549903197.05.0.60525639701.issue35968@roundup.psfhosted.org> Message-ID: <1549905519.02.0.992377719081.issue35968@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: The reported example works fine on master and 3.7 . The related issue's fix was not backported to 3.6 . 3.6 is in security fixes only mode. So upgrading to 3.7 will help and I propose closing this as a duplicate of issue33266 . ? cpython git:(master) ? cat foo.py #!/usr/bin/env python # -*- coding: utf-8 -*- regex_format = rf'' ? cpython git:(master) ? ./python.exe ./Tools/scripts/2to3 foo.py RefactoringTool: Skipping optional fixer: buffer RefactoringTool: Skipping optional fixer: idioms RefactoringTool: Skipping optional fixer: set_literal RefactoringTool: Skipping optional fixer: ws_comma RefactoringTool: No changes to foo.py RefactoringTool: Files that need to be modified: RefactoringTool: foo.py ? cpython git:(master) ? python3.7 ./Tools/scripts/2to3 foo.py RefactoringTool: Skipping optional fixer: buffer RefactoringTool: Skipping optional fixer: idioms RefactoringTool: Skipping optional fixer: set_literal RefactoringTool: Skipping optional fixer: ws_comma RefactoringTool: No changes to foo.py RefactoringTool: Files that need to be modified: RefactoringTool: foo.py ? cpython git:(master) ? python3.6 ./Tools/scripts/2to3 foo.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 foo.py: ParseError: bad input: type=3, value="''", context=('', (4, 17)) RefactoringTool: No files need to be modified. RefactoringTool: There was 1 error: RefactoringTool: Can't parse foo.py: ParseError: bad input: type=3, value="''", context=('', (4, 17)) ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 12:29:06 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 11 Feb 2019 17:29:06 +0000 Subject: [issue35378] multiprocessing.Pool.imaps iterators do not maintain alive the multiprocessing.Pool objects In-Reply-To: <1543769012.57.0.788709270274.issue35378@psf.upfronthosting.co.za> Message-ID: <1549906146.28.0.380461179239.issue35378@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: New changeset 3766f18c524c57784eea7c0001602017d2122156 by Pablo Galindo in branch 'master': bpo-35378: Fix multiprocessing.Pool references (GH-11627) https://github.com/python/cpython/commit/3766f18c524c57784eea7c0001602017d2122156 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 12:47:40 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 11 Feb 2019 17:47:40 +0000 Subject: [issue35378] multiprocessing.Pool.imaps iterators do not maintain alive the multiprocessing.Pool objects In-Reply-To: <1543769012.57.0.788709270274.issue35378@psf.upfronthosting.co.za> Message-ID: <1549907260.6.0.83123381083.issue35378@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 12:51:18 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Mon, 11 Feb 2019 17:51:18 +0000 Subject: [issue35965] Behavior for unittest.assertRaisesRegex differs depending on whether it is used as a context manager In-Reply-To: <1549890280.86.0.630330095869.issue35965@roundup.psfhosted.org> Message-ID: <1549907478.8.0.797540443531.issue35965@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: No problem, after some debugging the statement finally executed is 'exec(compile("set.add(0)", "foo.py", "exec"))' . In Python interpreter this will give the expected error. It also gives the same error before coverage.start() [0] and gives a different one as in the report once the statement is executed after coverage.start(). So this might be something to do with coverage and I have less knowledge about the internals. I am closing this as third party since I couldn't see any issue with CPython and you might want to follow up coverage issue tracker. Thanks for the report though! [0] https://github.com/nedbat/coveragepy/blob/f12db7fd4b3ab288f7f770f7138062951feaa6c9/coverage/cmdline.py#L639 ---------- resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 13:15:36 2019 From: report at bugs.python.org (Paul Ganssle) Date: Mon, 11 Feb 2019 18:15:36 +0000 Subject: [issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import Message-ID: <1549908934.51.0.669039845286.issue35969@roundup.psfhosted.org> New submission from Paul Ganssle : Just noticed this (tested on Python 3.7 and 3.8): mkdir /tmp/demo cd /tmp/demo cat << EOF > abc.py raise Exception("Hi") EOF PYTHONPATH=: python -c "" This will crash the interpreter with: Fatal Python error: init_sys_streams: can't initialize sys standard streams Traceback (most recent call last): File ".../lib/python3.7/io.py", line 52, in File "/tmp/demo/abc.py", line 1, in Exception: Hi Aborted (core dumped) It seems that the problem is that the io module imports the abc module, which raises an exception, so io fails to load. Evidently the io module is necessary to load the interpreter, so the interpreter crashes. Here's the backtrace for 3.7.2 on Arch Linux: (gdb) bt #0 0x00007f234b3f0d7f in raise () from /usr/lib/libc.so.6 #1 0x00007f234b3db672 in abort () from /usr/lib/libc.so.6 #2 0x00007f234b7db490 in fatal_error (prefix=prefix at entry=0x7f234b9d5fe0 <__func__.16645> "init_sys_streams", msg=msg at entry=0x7f234ba01f60 "can't initialize sys standard streams", status=status at entry=-1) at Python/pylifecycle.c:2179 #3 0x00007f234b8460cb in _Py_FatalInitError (err=...) at Python/pylifecycle.c:2198 #4 0x00007f234b8495a9 in pymain_init (pymain=0x7fff971cca70) at Modules/main.c:3019 #5 0x0000555dfa560050 in ?? () #6 0x00007fff971ccbc0 in ?? () #7 0x0000000000000000 in ?? () I'm not sure if anything can or should be done about this. It's very fair for the interpreter to fail to start, though I would guess that it should do that without dumping a core. ---------- messages: 335244 nosy: p-ganssle priority: normal severity: normal status: open title: Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import type: crash versions: Python 2.7, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 13:20:32 2019 From: report at bugs.python.org (Paul Ganssle) Date: Mon, 11 Feb 2019 18:20:32 +0000 Subject: [issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import In-Reply-To: <1549908934.51.0.669039845286.issue35969@roundup.psfhosted.org> Message-ID: <1549909232.78.0.217116915125.issue35969@roundup.psfhosted.org> Paul Ganssle added the comment: Tested with 3.6 and 2.7 - core dump on 3.6, no core dump on 2.7. The crash on 2.7 goes through a different path, it goes site.py > os.py >= UserDict.py > _abcoll.py > abc.py. That may account for why it's not crashing the interpreter itself. ---------- versions: +Python 3.6 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 13:20:56 2019 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 11 Feb 2019 18:20:56 +0000 Subject: [issue35955] difflib reports incorrect location of mismatch In-Reply-To: <1549807918.24.0.168325596231.issue35955@roundup.psfhosted.org> Message-ID: <1549909256.99.0.6700986089.issue35955@roundup.psfhosted.org> Chris Jerdonek added the comment: Is this a duplicate of issue24780? ---------- nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 13:25:41 2019 From: report at bugs.python.org (Jason R. Coombs) Date: Mon, 11 Feb 2019 18:25:41 +0000 Subject: [issue35955] difflib reports incorrect location of mismatch In-Reply-To: <1549807918.24.0.168325596231.issue35955@roundup.psfhosted.org> Message-ID: <1549909541.22.0.190849612196.issue35955@roundup.psfhosted.org> Jason R. Coombs added the comment: I don't think so, because the issue happens on a single line diff... although it's plausible there's a common-mode fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 13:32:16 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Mon, 11 Feb 2019 18:32:16 +0000 Subject: [issue35955] difflib reports incorrect location of mismatch In-Reply-To: <1549807918.24.0.168325596231.issue35955@roundup.psfhosted.org> Message-ID: <1549909936.09.0.0460239885918.issue35955@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: I am not sure this is a duplicate since the other issue was about newline at the end of strings. This is about the diff being little irrelevant even with newline in the end for strings. Sample program where change in 5th character gives the reported diff. import difflib for i in range(7): print(f"Change character at {i}") a = list("drwxrwxr-x 2 2000 2000\n") b = "drwxrwxr-x 2 2000 2000\n" a[i] = '-' a = ''.join(a) print(''.join(difflib.ndiff([a], [b]))) Change character at 0 - -rwxrwxr-x 2 2000 2000 ? ^ + drwxrwxr-x 2 2000 2000 ? ^ Change character at 1 - d-wxrwxr-x 2 2000 2000 ? ^ + drwxrwxr-x 2 2000 2000 ? ^ Change character at 2 - dr-xrwxr-x 2 2000 2000 ? ^ + drwxrwxr-x 2 2000 2000 ? ^ Change character at 3 - drw-rwxr-x 2 2000 2000 ? ^ + drwxrwxr-x 2 2000 2000 ? ^ Change character at 4 - drwx-wxr-x 2 2000 2000 ? ^ + drwxrwxr-x 2 2000 2000 ? ^ Change character at 5 - drwxr-xr-x 2 2000 2000 ? --- + drwxrwxr-x 2 2000 2000 ? +++ Change character at 6 - drwxrw-r-x 2 2000 2000 ? ^ + drwxrwxr-x 2 2000 2000 ? ^ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 13:35:43 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Mon, 11 Feb 2019 18:35:43 +0000 Subject: [issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import In-Reply-To: <1549908934.51.0.669039845286.issue35969@roundup.psfhosted.org> Message-ID: <1549910143.53.0.855604554108.issue35969@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: I hope there are certain modules that CPython interpreter expects to load properly. There were some cases in the past where encodings module caused the interpreter to crash. A similar scenario. ? cpython git:(master) echo "raise Exception('a')" > encodings.py ? cpython git:(master) ? PYTHONPATH=: ./python.exe Fatal Python error: initfsencoding: failed to get the Python codec of the filesystem encoding Traceback (most recent call last): File "/Users/karthikeyansingaravelan/stuff/python/cpython/encodings.py", line 1, in Exception: a [1] 29005 abort PYTHONPATH=: ./python.exe ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 13:41:07 2019 From: report at bugs.python.org (Ned Deily) Date: Mon, 11 Feb 2019 18:41:07 +0000 Subject: [issue35968] lib2to3 cannot parse rf'' In-Reply-To: <1549903197.05.0.60525639701.issue35968@roundup.psfhosted.org> Message-ID: <1549910467.82.0.48220422693.issue35968@roundup.psfhosted.org> Ned Deily added the comment: @xtreak, I concur. While it would have better to originally fix this in the release where f strings first appeared, the window to do that has closed. Sorry! ---------- nosy: +ned.deily resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> 2to3 doesn't parse all valid string literals _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 13:44:41 2019 From: report at bugs.python.org (Brennan D Baraban) Date: Mon, 11 Feb 2019 18:44:41 +0000 Subject: [issue23460] Decimals do not obey ':g' exponential notation formatting rules In-Reply-To: <1423847721.13.0.666007782647.issue23460@psf.upfronthosting.co.za> Message-ID: <1549910681.28.0.95204376788.issue23460@roundup.psfhosted.org> Brennan D Baraban <375 at holbertonschool.com> added the comment: Well, Tuomas, I defer submission of a PR to you, as its your original patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 13:45:10 2019 From: report at bugs.python.org (Ned Deily) Date: Mon, 11 Feb 2019 18:45:10 +0000 Subject: [issue35967] Better platform.processor support In-Reply-To: <1549895363.53.0.252912531241.issue35967@roundup.psfhosted.org> Message-ID: <1549910710.02.0.0814532665472.issue35967@roundup.psfhosted.org> Change by Ned Deily : ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 13:46:15 2019 From: report at bugs.python.org (Tim Peters) Date: Mon, 11 Feb 2019 18:46:15 +0000 Subject: [issue35955] difflib reports incorrect location of mismatch In-Reply-To: <1549807918.24.0.168325596231.issue35955@roundup.psfhosted.org> Message-ID: <1549910775.37.0.578936082231.issue35955@roundup.psfhosted.org> Tim Peters added the comment: difflib generally synchs on the longest contiguous matching subsequence that doesn't contain a "junk" element. By default, `ndiff()`'s optional `charjunk` argument considers blanks and tabs to be junk characters. In the strings: "drwxrwxr-x 2 2000 2000\n" "drwxr-xr-x 2 2000 2000\n" the longest matching substring not containing whitespace is "rwxr-x", of length 6, starting at index 4 in the first string and at index 1 in the second. So it's aligning the strings like so: "drwxrwxr-x 2 2000 2000\n" "drwxr-xr-x 2 2000 2000\n" 123456 That's why it wants to delete the 1:4 slice in the first string and insert "r-x" after the longest matching substring. The default is aimed at improving results for human-readable text, like prose and Python code, where stuff between whitespace is often read "as a whole" (words, keywords, identifiers, ...). For cases like this one, where character-by-character differences are important, it's often better to pass `charjunk=None`. Then the longest matching substring is "xr-x 2 2000 2000" at the tail end of both strings, and you get the output you're expecting. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 13:54:01 2019 From: report at bugs.python.org (Ernest W. Durbin III) Date: Mon, 11 Feb 2019 18:54:01 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1549911241.73.0.455825814279.issue2771@roundup.psfhosted.org> Ernest W. Durbin III added the comment: comment on test issue to test the request time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 13:56:22 2019 From: report at bugs.python.org (Ernest W. Durbin III) Date: Mon, 11 Feb 2019 18:56:22 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1549911382.92.0.472463290747.issue2771@roundup.psfhosted.org> Ernest W. Durbin III added the comment: test comment ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 13:57:42 2019 From: report at bugs.python.org (Robert Kuska) Date: Mon, 11 Feb 2019 18:57:42 +0000 Subject: [issue35970] no help flag in base64 util Message-ID: <1549911460.74.0.450147054737.issue35970@roundup.psfhosted.org> New submission from Robert Kuska : I failed today to print help message for base64 utility without an error: $ python3 -m base64 -help option -h not recognized usage: /usr/local/Cellar/python/3.7.2_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/base64.py [-d|-e|-u|-t] [file|-] -d, -u: decode -e: encode (default) -t: encode and decode string 'Aladdin:open sesame So I felt like this is a ripple in time space continuum worth adjusting. I already opened a PR to address this (probably not so worthy) issue (link attached). ---------- messages: 335255 nosy: rkuska priority: normal pull_requests: 11851 severity: normal status: open title: no help flag in base64 util _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 14:02:34 2019 From: report at bugs.python.org (Paul Ganssle) Date: Mon, 11 Feb 2019 19:02:34 +0000 Subject: [issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import In-Reply-To: <1549908934.51.0.669039845286.issue35969@roundup.psfhosted.org> Message-ID: <1549911754.13.0.807099545451.issue35969@roundup.psfhosted.org> Paul Ganssle added the comment: @Karthikeyan I would certainly consider this a duplicate of the encodings bug/behavior that you demonstrate. I don't see an existing bug on the tracker for it, though. I think it's pretty clear that the interpreter needs to fail, but it seems to *crash* rather than exit gracefully with a non-zero return code, which I think is the main problem. I'll note that it *does* print some stuff out before it crashes, which makes me think that even though io and/or encodings hasn't loaded, you still are able to do the "print an error message" part of "print an error message and exit with non-zero error code". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 14:04:34 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Mon, 11 Feb 2019 19:04:34 +0000 Subject: [issue35955] difflib reports incorrect location of mismatch In-Reply-To: <1549807918.24.0.168325596231.issue35955@roundup.psfhosted.org> Message-ID: <1549911874.17.0.0638665239866.issue35955@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Thanks for the explanation. This seems to give the desired diff with charjunk=None passed to multiline string comparison helper. I am not sure how useful it would be to pass it to sequence and dict comparison that also use ndiff. I can open a PR if it's okay with the set of strings in the report as a test case. There are no test case failures in existing unittest folder test suite so this seems like a safe change to me. # With patch charjunk=None ./python.exe ../backups/bpo35955_1.py F ====================================================================== FAIL: test_foo (__main__.FooTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "../backups/bpo35955_1.py", line 6, in test_foo self.assertEqual("drwxrwxr-x 2 2000 2000\n", "drwxr-xr-x 2 2000 2000\n") AssertionError: 'drwxrwxr-x 2 2000 2000\n' != 'drwxr-xr-x 2 2000 2000\n' - drwxrwxr-x 2 2000 2000 ? ^ + drwxr-xr-x 2 2000 2000 ? ^ ---------------------------------------------------------------------- Ran 1 test in 0.003s FAILED (failures=1) # Without patch ? cpython git:(master) ? python3.7 ../backups/bpo35955_1.py F ====================================================================== FAIL: test_foo (__main__.FooTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "../backups/bpo35955_1.py", line 6, in test_foo self.assertEqual("drwxrwxr-x 2 2000 2000\n", "drwxr-xr-x 2 2000 2000\n") AssertionError: 'drwxrwxr-x 2 2000 2000\n' != 'drwxr-xr-x 2 2000 2000\n' - drwxrwxr-x 2 2000 2000 ? --- + drwxr-xr-x 2 2000 2000 ? +++ ---------------------------------------------------------------------- Ran 1 test in 0.002s FAILED (failures=1) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 14:07:17 2019 From: report at bugs.python.org (Ernest W. Durbin III) Date: Mon, 11 Feb 2019 19:07:17 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1549912037.91.0.700663552677.issue2771@roundup.psfhosted.org> Ernest W. Durbin III added the comment: test mail sending ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 14:12:06 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Mon, 11 Feb 2019 19:12:06 +0000 Subject: [issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import In-Reply-To: <1549908934.51.0.669039845286.issue35969@roundup.psfhosted.org> Message-ID: <1549912326.93.0.0912432798923.issue35969@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Sorry by previous reports I was talking about some of the issues where the installers were not correct though I couldn't find the issue at the moment. I just presented it as a data point where some necessary modules that cannot be imported could lead to crash. But if this can be dealt with in a better way I think it will be a good improvement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 14:26:06 2019 From: report at bugs.python.org (Davin Potts) Date: Mon, 11 Feb 2019 19:26:06 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1549913166.41.0.480079672368.issue35813@roundup.psfhosted.org> Davin Potts added the comment: @terry.reedy and @ronaldoussoren: I have asked Van again to provide comments here clarifying the topics of (1) copyright notices and (2) requiring the BSD-licensed-work's author to sign a contributor agreement. Specifically regarding the appearance of __copyright__, I added my agreement to your comments on GH-11816 on this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 14:28:26 2019 From: report at bugs.python.org (Ernest W. Durbin III) Date: Mon, 11 Feb 2019 19:28:26 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1549913306.13.0.523415909084.issue2771@roundup.psfhosted.org> Ernest W. Durbin III added the comment: should be fast send. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 14:34:56 2019 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 11 Feb 2019 19:34:56 +0000 Subject: =?utf-8?q?=5Bissue35963=5D_Python/symtable=2Ec=3A_warning=3A_enumeration_?= =?utf-8?q?value_=E2=80=98FunctionType=5Fkind=E2=80=99_not_handled_in_swit?= =?utf-8?q?ch_=5B-Wswitch=5D=22?= In-Reply-To: <1549884684.1.0.958621485817.issue35963@roundup.psfhosted.org> Message-ID: <1549913696.07.0.551647627048.issue35963@roundup.psfhosted.org> Guido van Rossum added the comment: New changeset 522346d792d9013140a3f4ad3534ac10f38d9085 by Guido van Rossum in branch 'master': Complete switch cases in symtable.c; fixes bpo-35963 (GH-11821) https://github.com/python/cpython/commit/522346d792d9013140a3f4ad3534ac10f38d9085 ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 14:57:33 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Feb 2019 19:57:33 +0000 Subject: =?utf-8?q?=5Bissue35963=5D_Python/symtable=2Ec=3A_warning=3A_enumeration_?= =?utf-8?q?value_=E2=80=98FunctionType=5Fkind=E2=80=99_not_handled_in_swit?= =?utf-8?q?ch_=5B-Wswitch=5D=22?= In-Reply-To: <1549884684.1.0.958621485817.issue35963@roundup.psfhosted.org> Message-ID: <1549915053.92.0.904272827892.issue35963@roundup.psfhosted.org> STINNER Victor added the comment: Thanks for the fix, Guido ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 14:59:11 2019 From: report at bugs.python.org (Ernest W. Durbin III) Date: Mon, 11 Feb 2019 19:59:11 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1549915151.56.0.344705122251.issue2771@roundup.psfhosted.org> Ernest W. Durbin III added the comment: test ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 15:04:12 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 11 Feb 2019 20:04:12 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1549915452.97.0.826528265172.issue2771@roundup.psfhosted.org> Antoine Pitrou added the comment: notifying a lot of people ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 15:05:52 2019 From: report at bugs.python.org (Jason R. Coombs) Date: Mon, 11 Feb 2019 20:05:52 +0000 Subject: [issue35955] difflib reports incorrect location of mismatch In-Reply-To: <1549807918.24.0.168325596231.issue35955@roundup.psfhosted.org> Message-ID: <1549915552.65.0.822996932614.issue35955@roundup.psfhosted.org> Jason R. Coombs added the comment: Nice insight Tim. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 15:07:41 2019 From: report at bugs.python.org (Tim Peters) Date: Mon, 11 Feb 2019 20:07:41 +0000 Subject: [issue35955] difflib reports incorrect location of mismatch In-Reply-To: <1549807918.24.0.168325596231.issue35955@roundup.psfhosted.org> Message-ID: <1549915661.45.0.782148296356.issue35955@roundup.psfhosted.org> Tim Peters added the comment: It's probably OK, but there's no "pure win" to be had here. There's generally more than one way to convert one string to another, and what "looks right" to humans depends a whole lot on context. For example, consider these strings: "private Thread currentThread;" "private volatile Thread currentThread;" "It's obvious" someone inserted "volatile" into the first string, and that's what ndiff's default says: - private Thread currentThread; + private volatile Thread currentThread; ? +++++++++ However, pass `charjunk=None` instead, and ndiff claims someone inserted "e volatil" after the "t" in "private": - private Thread currentThread; + private volatile Thread currentThread; ? +++++++++ Which is also a correct way, but - to human eyes - an insane way ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 16:28:56 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 11 Feb 2019 21:28:56 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1549920536.96.0.387052766728.issue2771@roundup.psfhosted.org> St?phane Wirtel added the comment: irc pong ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 16:46:00 2019 From: report at bugs.python.org (Gabriel Corona) Date: Mon, 11 Feb 2019 21:46:00 +0000 Subject: [issue35971] Documentation should warn about code injection from current working directory Message-ID: <1549921560.53.0.488831977782.issue35971@roundup.psfhosted.org> New submission from Gabriel Corona : The CLI tools shipped in Debian python-rdflib-tools package can load modules from the current directory [1]: $ echo 'print("Something")' > cgi.py $ rdf2dot INFO:rdflib:RDFLib Version: 4.2.2 Something Reading from stdin as None... This could be a security issue because an attacker could possibly exploit this behavior to execute arbitrary code. This happens because these CLI tools are implemented as: #!/bin/sh exec /usr/bin/python -m rdflib.tools.rdfpipe $* "python -m $module", "python -c $code" and "$command | python" prepend the current working directory in the Python path. The Python documentation [2] should probably warn about this. In Python 3, "-I" could be suggested to prevent the script/current directory to be added to the Python path. However, this flag has other effects. The Python documentation suggests "python -m" commands at some places [3-5]: some form of warning at those places might be nice as well. See the related behavior of Perl. Perl used to include "." in @INC but this was removed for security reasons [6]. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921751. [2] https://docs.python.org/3/using/cmdline.html [3] https://docs.python.org/3.1/library/json.html [4] https://docs.python.org/3/library/http.server.html [5] https://docs.python.org/3/library/zipapp.html [6] https://metacpan.org/pod/release/XSAWYERX/perl-5.26.0/pod/perldelta.pod#Removal-of-the-current-directory-%28%22.%22%29-from- at INC ---------- messages: 335271 nosy: Gabriel Corona priority: normal severity: normal status: open title: Documentation should warn about code injection from current working directory type: security versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 16:52:48 2019 From: report at bugs.python.org (Alexey Izbyshev) Date: Mon, 11 Feb 2019 21:52:48 +0000 Subject: [issue35972] _xxsubinterpreters: channel_send() may truncate ints on 32-bit platforms Message-ID: <1549921968.67.0.462504390355.issue35972@roundup.psfhosted.org> New submission from Alexey Izbyshev : Victor Stinner pointed out that on x86 Gentoo Installed with X 3.x buildbot, there is a compiler warning: Python/pystate.c:1483:18: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] (https://buildbot.python.org/all/#/builders/103/builds/2067) This warning reveals a bug: static int _long_shared(PyObject *obj, _PyCrossInterpreterData *data) { int64_t value = PyLong_AsLongLong(obj); if (value == -1 && PyErr_Occurred()) { if (PyErr_ExceptionMatches(PyExc_OverflowError)) { PyErr_SetString(PyExc_OverflowError, "try sending as bytes"); } return -1; } data->data = (void *)value; A 64-bit value is converted to void *, which is 32-bit on 32-bit platforms. I've implemented a PR that uses Py_ssize_t instead to match the pointer size and to preserve the ability to work with negative numbers. ---------- assignee: izbyshev components: Extension Modules messages: 335272 nosy: eric.snow, izbyshev, vstinner priority: normal severity: normal status: open title: _xxsubinterpreters: channel_send() may truncate ints on 32-bit platforms type: behavior versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 16:57:07 2019 From: report at bugs.python.org (Alexey Izbyshev) Date: Mon, 11 Feb 2019 21:57:07 +0000 Subject: [issue35972] _xxsubinterpreters: channel_send() may truncate ints on 32-bit platforms In-Reply-To: <1549921968.67.0.462504390355.issue35972@roundup.psfhosted.org> Message-ID: <1549922227.75.0.513758562533.issue35972@roundup.psfhosted.org> Change by Alexey Izbyshev : ---------- keywords: +patch pull_requests: +11852 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 17:52:04 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 11 Feb 2019 22:52:04 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1549925524.76.0.974274845205.issue35813@roundup.psfhosted.org> Giampaolo Rodola' added the comment: I submitted an initial review / comments in the PR. I think this is good for a first iteration in order to understand what APIs to expose publicly (also, keep in mind I may not have a full picture of how this is intended to be used precisely). As for the doc, I find it a bit too verbose. If the namespace change is accepted consider doing the following: * document `SharedMemoryManager` right after `SyncManager`. That would let you reuse the description for `Semaphore`, `Barrier`, `Lock`, etc. * within `SharedMemoryManager` doc link/point to a different section of the doc where you explain the whole thing in more details, and also document the remaining APIs Just an idea. Writing good doc is not easy and it requires actually putting hands on it. Hope this helps. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 18:05:56 2019 From: report at bugs.python.org (Brennan Vincent) Date: Mon, 11 Feb 2019 23:05:56 +0000 Subject: [issue35973] `growable_int_array type_ignores` in parsetok.c is not always freed. Message-ID: <1549926356.5.0.0624072683347.issue35973@roundup.psfhosted.org> New submission from Brennan Vincent : To reproduce: (1) build python: `../configure --prefix=$HOME/prefix --with-pydebug --without-pymalloc && make install` (2) run with valgrind: `valgrind --leak-check=full ~/prefix/bin/python3` (3) exit immediately from the interpreter by pressing ^D (4) Note the following output from Valgrind: ``` ==3810071== 40 bytes in 1 blocks are definitely lost in loss record 3 of 527 ==3810071== at 0x4C28B5F: malloc (vg_replace_malloc.c:299) ==3810071== by 0x59ED58: growable_int_array_init (parsetok.c:27) ==3810071== by 0x59EE14: parsetok (parsetok.c:235) ==3810071== by 0x59F697: PyParser_ParseFileObject (parsetok.c:176) ==3810071== by 0x522E85: PyParser_ASTFromFileObject (pythonrun.c:1224) ==3810071== by 0x5231E9: PyRun_InteractiveOneObjectEx (pythonrun.c:238) ==3810071== by 0x5234D0: PyRun_InteractiveLoopFlags (pythonrun.c:120) ==3810071== by 0x523BF2: PyRun_AnyFileExFlags (pythonrun.c:78) ==3810071== by 0x4204FE: pymain_run_stdin (main.c:1185) ==3810071== by 0x42126B: pymain_run_python (main.c:1675) ==3810071== by 0x422EE0: pymain_main (main.c:1820) ==3810071== by 0x422F75: _Py_UnixMain (main.c:1857) ``` Reproduced on git commit hash 522346d792d9013140a3f4ad3534ac10f38d9085 . ---------- components: Interpreter Core messages: 335274 nosy: umanwizard priority: normal severity: normal status: open title: `growable_int_array type_ignores` in parsetok.c is not always freed. type: resource usage versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 18:11:22 2019 From: report at bugs.python.org (Marat Sharafutdinov) Date: Mon, 11 Feb 2019 23:11:22 +0000 Subject: [issue35974] os.DirEntry.inode() returns invalid value within Docker container Message-ID: <1549926682.07.0.790537148313.issue35974@roundup.psfhosted.org> New submission from Marat Sharafutdinov : I'm trying to build Python 3.7.2 within official CentOS 7.6.1810 image (https://hub.docker.com/_/centos) and getting the following error during testing: ====================================================================== FAIL: test_attributes (test.test_os.TestScandir) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/src/python/Lib/test/test_os.py", line 3367, in test_attributes self.check_entry(entry, 'dir', True, False, False) File "/usr/src/python/Lib/test/test_os.py", line 3319, in check_entry os.stat(entry.path, follow_symlinks=False).st_ino) AssertionError: 28093768 != 85098458 I guess this bug applies to Docker containers in general. For instance it's reproduced with the official Python 3.7.2-stretch image based on the Debian Stretch (https://hub.docker.com/_/python): $ docker run --rm -it python:3.7.2-stretch Python 3.7.2 (default, Feb 6 2019, 12:04:03) [GCC 6.3.0 20170516] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.mkdir('/test_dir') >>> for entry in os.scandir('/'): ... if entry.name == 'test_dir': ... break ... >>> print(entry, entry.inode(), os.stat(entry.path, follow_symlinks=False).st_ino) 23898155 85118011 >>> assert entry.inode() == os.stat(entry.path, follow_symlinks=False).st_ino Traceback (most recent call last): File "", line 1, in AssertionError >>> In case of using host volume when running container it works ok, - the problem occurs when using default Docker volume: $ docker run --rm -it -v /home/decaz/workspace:/host_dir python:3.7.2-stretch Python 3.7.2 (default, Feb 6 2019, 12:04:03) [GCC 6.3.0 20170516] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.mkdir('/host_dir/test_dir') >>> for entry in os.scandir('/host_dir'): ... if entry.name == 'test_dir': ... break ... >>> print(entry, entry.inode(), os.stat(entry.path, follow_symlinks=False).st_ino) 12873222 12873222 >>> assert entry.inode() == os.stat(entry.path, follow_symlinks=False).st_ino >>> Similar issue - https://bugs.python.org/issue32811. ---------- components: Build messages: 335275 nosy: decaz priority: normal severity: normal status: open title: os.DirEntry.inode() returns invalid value within Docker container type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 19:10:08 2019 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 12 Feb 2019 00:10:08 +0000 Subject: =?utf-8?q?=5Bissue35963=5D_Python/symtable=2Ec=3A_warning=3A_enumeration_?= =?utf-8?q?value_=E2=80=98FunctionType=5Fkind=E2=80=99_not_handled_in_swit?= =?utf-8?q?ch_=5B-Wswitch=5D=22?= In-Reply-To: <1549884684.1.0.958621485817.issue35963@roundup.psfhosted.org> Message-ID: <1549930208.74.0.0251186944022.issue35963@roundup.psfhosted.org> Change by Guido van Rossum : ---------- stage: resolved -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 19:11:24 2019 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 12 Feb 2019 00:11:24 +0000 Subject: [issue35766] Merge typed_ast back into CPython In-Reply-To: <1547771581.08.0.389360423635.issue35766@roundup.psfhosted.org> Message-ID: <1549930284.57.0.696078233191.issue35766@roundup.psfhosted.org> Guido van Rossum added the comment: I have some follow-up wishes but I'll create a new issue. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 19:23:38 2019 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 12 Feb 2019 00:23:38 +0000 Subject: [issue35975] Put back the ability to parse files where async/await aren't keywords Message-ID: <1549931018.54.0.209945896308.issue35975@roundup.psfhosted.org> New submission from Guido van Rossum : Now that the ast module can be used to parse type comments, there?s one more feature I?d like to lobby for ? a flag that modifies the grammar slightly so it resembles an older version of Python (going back to 3.4). This is used in mypy to decouple the Python version you?re running from the Python version for which you?re checking compatibility (useful when checking code that will be deployed on a system with a different Python version installed). I imagine this would be useful to other linters as well, and the implementation is mostly manipulating whether `async` and `await` are keywords. But if there?s pushback to this part I can live without it ? the rest of the work is still useful. The implementation in typed_ast takes the form of a feature_version flag which is set to the minor Python version to be parsed. Setting it to 4 or lower would make async/await never keywords, setting it to 5 or 6 would make them conditional per PEP 492, and setting it to 7 or higher would make these unconditional keywords. A few minor uses of the same flag also reject f-strings, annotated assignments (PEP 526), and matrix multiply for versions where those don't exist. But I don't need all of those -- I really just need to be able to select the 3.5/3.6 rules for conditional async/await keywords, since all the other features are purely backwards compatible, whereas with async/await there is legal (and plentiful!) code that uses these as variable or function names that should be supported in 3.5/3.6 mode. Of course having it be a (minor) version number would still be more future-proof -- if say in 3.10 we add a match expression using some kind of conditional keyword hack, we might have to dust it off. Note that much of what I'm asking for would effectively roll back https://bugs.python.org/issue30406 -- sorry Jelle! (Though there's more to it -- Serhiy's introduction of Grammar/Token followed, and I would still need to thread some kind of flag all the way from ast.parse() to tokenizer.c. ---------- messages: 335277 nosy: gvanrossum priority: normal severity: normal status: open title: Put back the ability to parse files where async/await aren't keywords _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 19:23:54 2019 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 12 Feb 2019 00:23:54 +0000 Subject: [issue35766] Merge typed_ast back into CPython In-Reply-To: <1547771581.08.0.389360423635.issue35766@roundup.psfhosted.org> Message-ID: <1549931034.29.0.364452703219.issue35766@roundup.psfhosted.org> Guido van Rossum added the comment: See https://bugs.python.org/issue35975 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 19:27:46 2019 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 12 Feb 2019 00:27:46 +0000 Subject: =?utf-8?q?=5Bissue35963=5D_Python/symtable=2Ec=3A_warning=3A_enumeration_?= =?utf-8?q?value_=E2=80=98FunctionType=5Fkind=E2=80=99_not_handled_in_swit?= =?utf-8?q?ch_=5B-Wswitch=5D=22?= In-Reply-To: <1549884684.1.0.958621485817.issue35963@roundup.psfhosted.org> Message-ID: <1549931266.33.0.377792906287.issue35963@roundup.psfhosted.org> Change by Guido van Rossum : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 19:35:27 2019 From: report at bugs.python.org (Matej Cepl) Date: Tue, 12 Feb 2019 00:35:27 +0000 Subject: [issue35505] Test test_imaplib fail in test_imap4_host_default_value In-Reply-To: <1544833222.75.0.788709270274.issue35505@psf.upfronthosting.co.za> Message-ID: <1549931727.98.0.671600544.issue35505@roundup.psfhosted.org> Change by Matej Cepl : ---------- keywords: +patch pull_requests: +11853 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 19:35:49 2019 From: report at bugs.python.org (Ivan Levkivskyi) Date: Tue, 12 Feb 2019 00:35:49 +0000 Subject: [issue35975] Put back the ability to parse files where async/await aren't keywords In-Reply-To: <1549931018.54.0.209945896308.issue35975@roundup.psfhosted.org> Message-ID: <1549931749.65.0.467124430116.issue35975@roundup.psfhosted.org> Change by Ivan Levkivskyi : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 19:37:26 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 12 Feb 2019 00:37:26 +0000 Subject: [issue35918] multiprocessing's SyncManager.dict.has_key() method is broken In-Reply-To: <1549473735.16.0.515862791139.issue35918@roundup.psfhosted.org> Message-ID: <1549931846.7.0.650821098751.issue35918@roundup.psfhosted.org> Giampaolo Rodola' added the comment: New changeset a31f4cc881992e84d351957bd9ac1a92f882fa39 by Giampaolo Rodola (R?mi Lapeyre) in branch 'master': bpo-35918: Remove broken has_key method and add test (#11819) https://github.com/python/cpython/commit/a31f4cc881992e84d351957bd9ac1a92f882fa39 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 19:37:51 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 12 Feb 2019 00:37:51 +0000 Subject: [issue35918] multiprocessing's SyncManager.dict.has_key() method is broken In-Reply-To: <1549473735.16.0.515862791139.issue35918@roundup.psfhosted.org> Message-ID: <1549931871.94.0.656804662094.issue35918@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11854 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 20:09:29 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 12 Feb 2019 01:09:29 +0000 Subject: [issue35918] multiprocessing's SyncManager.dict.has_key() method is broken In-Reply-To: <1549473735.16.0.515862791139.issue35918@roundup.psfhosted.org> Message-ID: <1549933769.33.0.292560550627.issue35918@roundup.psfhosted.org> Giampaolo Rodola' added the comment: New changeset 58f05ce059cc5207320fef27a9fbc0ffdc2b1d1a by Giampaolo Rodola (Miss Islington (bot)) in branch '3.7': bpo-35918: Remove broken has_key method and add test (GH-11819) (#11824) https://github.com/python/cpython/commit/58f05ce059cc5207320fef27a9fbc0ffdc2b1d1a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 20:24:40 2019 From: report at bugs.python.org (Ethan Smith) Date: Tue, 12 Feb 2019 01:24:40 +0000 Subject: [issue35975] Put back the ability to parse files where async/await aren't keywords In-Reply-To: <1549931018.54.0.209945896308.issue35975@roundup.psfhosted.org> Message-ID: <1549934680.31.0.267934826258.issue35975@roundup.psfhosted.org> Change by Ethan Smith : ---------- nosy: +Ethan Smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 20:37:23 2019 From: report at bugs.python.org (Eric Snow) Date: Tue, 12 Feb 2019 01:37:23 +0000 Subject: [issue35972] _xxsubinterpreters: channel_send() may truncate ints on 32-bit platforms In-Reply-To: <1549921968.67.0.462504390355.issue35972@roundup.psfhosted.org> Message-ID: <1549935443.17.0.707794494489.issue35972@roundup.psfhosted.org> Eric Snow added the comment: Is "long long" (AKA int64_t) 32 bits or 64 bits on a 32-bit platform? It it's always 32 bits then there is no problem here. Otherwise I agree we have a problem to fix. My understanding is that it is the former (always 32 bits). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 20:42:19 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 12 Feb 2019 01:42:19 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1549935739.99.0.852302485469.issue35813@roundup.psfhosted.org> Raymond Hettinger added the comment: FWIW, I read the draft docs and found them to be at the right level throughout. I definitely wouldn't want anything more terse. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 21:01:31 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 12 Feb 2019 02:01:31 +0000 Subject: [issue35971] Documentation should warn about code injection from current working directory In-Reply-To: <1549921560.53.0.488831977782.issue35971@roundup.psfhosted.org> Message-ID: <1549936891.56.0.54238910363.issue35971@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: The change in behavior of Perl was discussed in https://mail.python.org/pipermail/python-ideas/2017-June/045842.html ---------- nosy: +vstinner, xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 22:51:20 2019 From: report at bugs.python.org (Davin Potts) Date: Tue, 12 Feb 2019 03:51:20 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1549943480.91.0.127589292389.issue35813@roundup.psfhosted.org> Davin Potts added the comment: @giampaolo.rodola: It definitely helps. Conceptually, SyncManager provides "distributed shared memory" where lists, dicts, etc. are held in memory by one process but may be accessed remotely from another via a Proxy Object. Mutating a dict from one process requires sending a message to some other process to request the change be made. In contrast, SharedMemoryManager provides non-distributed shared memory where a special region of memory is held by the OS kernel (not a process) and made directly addressable to many processes simultaneously. Modifying any data in this special region of memory requires zero process-to-process communication; any of the processes may modify the data directly. In a speed contest, the SharedMemoryManager wins in every use case -- and it is not a close race. There are other advantages and disadvantages to each, but speed is the key differentiator. Thinking ahead to the future of SharedMemoryManager, there is the potential for a POSIX shared memory based semaphore. The performance of this semaphore across processes should drastically outperform SyncManager's semaphore. It might be something we will want to support in the future. SharedMemoryManager needs a synchronization mechanism now (in support of common use cases) to coordinate across processes, which is why I initially thought SharedMemoryManager should expose the Lock, Semaphore, Event, Barrier, etc. powered by distributed shared memory. I am no longer sure this is the right choice for three reasons: (1) it unnecessarily complicates and confuses the separation of what is powered by fast SystemV-style shared memory and what is powered by slow distributed shared memory, (2) it would be a very simple example in the docs to show how to add our existing Lock or Semaphore to SharedMemoryManager via register(), (3) if we one day implement POSIX shared memory semaphores (and equivalent where POSIX is not supported), we will have the burden of an existing lock/semaphore creation methods and apis with behavioral differences. I propose that it would be clearer but no less usable if we drop these registered object types (created via calls to register()) from SharedMemoryManager. It is one line of code for a user to add "Lock" to SharedMemoryManager, which I think we can demonstrate well with a simple example. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 23:02:51 2019 From: report at bugs.python.org (Paul Monson) Date: Tue, 12 Feb 2019 04:02:51 +0000 Subject: [issue35976] PCBuild file changes for arm32 should be separated from code changes for review Message-ID: <1549944171.25.0.954799038115.issue35976@roundup.psfhosted.org> Change by Paul Monson : ---------- components: Build, Windows nosy: Paul Monson, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: PCBuild file changes for arm32 should be separated from code changes for review type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 23:06:36 2019 From: report at bugs.python.org (Paul Monson) Date: Tue, 12 Feb 2019 04:06:36 +0000 Subject: [issue35976] PCBuild file changes for arm32 should be separated from code changes for review Message-ID: <1549944396.41.0.346052705117.issue35976@roundup.psfhosted.org> Change by Paul Monson : ---------- keywords: +patch pull_requests: +11855 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 23:42:06 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 12 Feb 2019 04:42:06 +0000 Subject: [issue17561] Add socket.bind_socket() convenience function In-Reply-To: <1364402909.97.0.467946240817.issue17561@psf.upfronthosting.co.za> Message-ID: <1549946526.21.0.534589654757.issue17561@roundup.psfhosted.org> Giampaolo Rodola' added the comment: After iterating over this over the last few days I realized it makes more sense to implement and discuss the whole thing in here and as a single PR, so sorry about previously splitting this in a separate ticket/PR. Relevant PR is now this one and is ready for review: https://github.com/python/cpython/pull/11784 Relevant changes which probably require attention/discussion are: 1) since it was sort of ambiguous I renamed "has_dual_stack()" to "supports_hybrid_ipv46()". There could be space for some bikeshed as we already have "socket.has_ipv6" so this may be "has_hybrid_ipv46()" called instead 2) if family is unspecified and determined from *host* (e.g. "localhost" or "") the function sorts getaddrinfo() results preferring AF_INET over AF_INET6 3) doc includes link to my http://code.activestate.com/recipes/578504 recipe for platforms not supporting hybrid_ipv46 natively 4) it may be worthwhile (or maybe not?) to have another complementary bind_sockets() (plural) function returning all items from getaddrinfo(). That would be useful for non-blocking apps/frameworks and could be reused by asyncio. Also, I'm CC-ing people from issue20215 as it contains relevant comments. ---------- keywords: -easy nosy: +Carlos.Ralli, Paul Marks, andreasr, berker.peksag, dazhaoyu, gregory.p.smith, jleedev, jpokorny, martin.panter, nirs, r.david.murray pull_requests: +11856 title: Add socket.create_server_sock() convenience function -> Add socket.bind_socket() convenience function _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 11 23:45:54 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 12 Feb 2019 04:45:54 +0000 Subject: [issue35934] Add socket.bind_socket() utility function In-Reply-To: <1549566902.79.0.677687282333.issue35934@roundup.psfhosted.org> Message-ID: <1549946754.84.0.0572370356341.issue35934@roundup.psfhosted.org> Giampaolo Rodola' added the comment: Closing this out as duplicate. Will continue in issue35934. ---------- resolution: -> duplicate stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 00:03:50 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 12 Feb 2019 05:03:50 +0000 Subject: [issue35973] `growable_int_array type_ignores` in parsetok.c is not always freed. In-Reply-To: <1549926356.5.0.0624072683347.issue35973@roundup.psfhosted.org> Message-ID: <1549947830.91.0.103716658699.issue35973@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 00:36:43 2019 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 12 Feb 2019 05:36:43 +0000 Subject: [issue35973] `growable_int_array type_ignores` in parsetok.c is not always freed. In-Reply-To: <1549926356.5.0.0624072683347.issue35973@roundup.psfhosted.org> Message-ID: <1549949803.38.0.0229599150361.issue35973@roundup.psfhosted.org> Guido van Rossum added the comment: Thanks for the report! I think I see a path through the code that doesn't free the memory. Does this patch fix it? diff --git a/Parser/parsetok.c b/Parser/parsetok.c index 1fa4a1286b..6a96f6bc5a 100644 --- a/Parser/parsetok.c +++ b/Parser/parsetok.c @@ -370,7 +370,6 @@ parsetok(struct tok_state *tok, grammar *g, int start, perrdetail *err_ret, type_ignores.items[i], 0); } } - growable_int_array_deallocate(&type_ignores); #ifndef PGEN /* Check that the source for a single input statement really @@ -405,6 +404,8 @@ parsetok(struct tok_state *tok, grammar *g, int start, perrdetail *err_ret, else n = NULL; + growable_int_array_deallocate(&type_ignores); + #ifdef PY_PARSER_REQUIRES_FUTURE_KEYWORD *flags = ps->p_flags; #endif ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 01:18:12 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Tue, 12 Feb 2019 06:18:12 +0000 Subject: [issue21914] Create unit tests for Turtle guionly In-Reply-To: <1404442037.11.0.611165319303.issue21914@psf.upfronthosting.co.za> Message-ID: <1549952292.97.0.976259427473.issue21914@roundup.psfhosted.org> Joannah Nanjekye added the comment: @RAJALAKSHMI V Any status on this? I would love to take this up if you are no longer working on it. ---------- nosy: +nanjekyejoannah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 01:52:09 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Tue, 12 Feb 2019 06:52:09 +0000 Subject: [issue25461] Unclear language (the word ineffective) in the documentation for os.walk In-Reply-To: <1445533538.52.0.421272081658.issue25461@psf.upfronthosting.co.za> Message-ID: <1549954329.43.0.382268375983.issue25461@roundup.psfhosted.org> Joannah Nanjekye added the comment: What is the status on this? From this discussion, it looks like @vstinner pushed changes to resolve this. Do we close this? If this still needs a patch, then one of the patches can be reviewed in a PR on GitHub. ---------- nosy: +nanjekyejoannah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 02:14:14 2019 From: report at bugs.python.org (RAJALAKSHMI V) Date: Tue, 12 Feb 2019 07:14:14 +0000 Subject: [issue21914] Create unit tests for Turtle guionly In-Reply-To: <1549952292.97.0.976259427473.issue21914@roundup.psfhosted.org> Message-ID: RAJALAKSHMI V added the comment: I?m no longer working on this. Please feel free to take it up. Rajalakshmi.V > On 12-Feb-2019, at 11:48 AM, Joannah Nanjekye wrote: > > > Joannah Nanjekye added the comment: > > @RAJALAKSHMI V Any status on this? I would love to take this up if you are no longer working on it. > > ---------- > nosy: +nanjekyejoannah > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 04:44:54 2019 From: report at bugs.python.org (Alexey Izbyshev) Date: Tue, 12 Feb 2019 09:44:54 +0000 Subject: [issue35972] _xxsubinterpreters: channel_send() may truncate ints on 32-bit platforms In-Reply-To: <1549921968.67.0.462504390355.issue35972@roundup.psfhosted.org> Message-ID: <1549964694.16.0.598618732995.issue35972@roundup.psfhosted.org> Alexey Izbyshev added the comment: "long long" is mandated to be at least 64-bit by C99 (5.2.4.2.1 Sizes of integer types). If it were 32-bit, no warnings would have been issued. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 04:58:36 2019 From: report at bugs.python.org (Tal Einat) Date: Tue, 12 Feb 2019 09:58:36 +0000 Subject: [issue21109] tarfile: Traversal attack vulnerability In-Reply-To: <1396253659.12.0.842636239516.issue21109@psf.upfronthosting.co.za> Message-ID: <1549965516.57.0.304359179151.issue21109@roundup.psfhosted.org> Tal Einat added the comment: > Is there any update on this? Will this be fixed in the next release? There was progress made as described on this issue, but there is yet work to be done, and no-one seems to be taking this upon themselves at the moment. I agree that it would be great to have this in 3.8. ---------- versions: -Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 05:29:55 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Tue, 12 Feb 2019 10:29:55 +0000 Subject: [issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import In-Reply-To: <1549908934.51.0.669039845286.issue35969@roundup.psfhosted.org> Message-ID: <1549967395.84.0.455628767693.issue35969@roundup.psfhosted.org> Emmanuel Arias added the comment: Hi, The reason of the aborted(core dump) of the interpreter is because when the init process was wrong, the ```_Py_NO_RETURN fatal_error()``` call and abort() So, I change it for a exit(status) to avoid break the interpreter (I attach a patch) What do you think about it? If all it's ok I can prepare the PR ---------- keywords: +patch nosy: +eamanu Added file: https://bugs.python.org/file48134/0001-avoid-abort-when-initialize-python-fail.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 05:55:12 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 10:55:12 +0000 Subject: [issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import In-Reply-To: <1549908934.51.0.669039845286.issue35969@roundup.psfhosted.org> Message-ID: <1549968912.91.0.126725166471.issue35969@roundup.psfhosted.org> STINNER Victor added the comment: Last year, I reworked Python initialization to introduce a new _PyInitError structure which allows to report a failure to the caller of a function instead of calling directly Py_FatalError() which always call abort() immediately. _PyInitError allows to distinguish "user error" and "internal error". User error is caused by an user mistake, whereas internal errors are all other errors. User errors don't call abort() to avoid dumping a core dump. It's not always easy to decide if a bug is caused by the user or not. For example, a memory allocation failure is now considered as an "user error": #define _Py_INIT_NO_MEMORY() _Py_INIT_USER_ERR("memory allocation failed") See Include/coreconfig.h for the definition of _PyInitError and related macros. One enhancement of this new API is that it now reports the name of the C function which causes the error. The initial bug report says "Fatal Python error: init_sys_streams: can't initialize sys standard streams": init_sys_streams() function raised the fatal error. ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 05:57:04 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 10:57:04 +0000 Subject: [issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import In-Reply-To: <1549908934.51.0.669039845286.issue35969@roundup.psfhosted.org> Message-ID: <1549969024.39.0.683214130682.issue35969@roundup.psfhosted.org> STINNER Victor added the comment: A workaround is the usage of -I option: vstinner at apu$ PYTHONPATH=: python3 -c "" Fatal Python error: init_sys_streams: can't initialize sys standard streams Traceback (most recent call last): File "/usr/lib64/python3.7/io.py", line 52, in File "/tmp/demo/abc.py", line 1, in Exception: Hi Aborted (core dumped) vstinner at apu$ PYTHONPATH=: python3 -I -c "" A long term solution would to enable -I behavior by default: don't add the current directory to sys.path when using -c CMD. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 06:50:57 2019 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 12 Feb 2019 11:50:57 +0000 Subject: [issue35960] dataclasses.field does not preserve empty metadata object In-Reply-To: <1549847214.14.0.863197964236.issue35960@roundup.psfhosted.org> Message-ID: <1549972257.17.0.759160582981.issue35960@roundup.psfhosted.org> Eric V. Smith added the comment: New changeset b01786c8812c4cc24dd561b5941025bdd6f444c0 by Eric V. Smith (Christopher Hunt) in branch 'master': bpo-35960: Fix dataclasses.field throwing away empty metadata. (GH-11815) https://github.com/python/cpython/commit/b01786c8812c4cc24dd561b5941025bdd6f444c0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 06:51:09 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 12 Feb 2019 11:51:09 +0000 Subject: [issue35960] dataclasses.field does not preserve empty metadata object In-Reply-To: <1549847214.14.0.863197964236.issue35960@roundup.psfhosted.org> Message-ID: <1549972269.39.0.789409686505.issue35960@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11857 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 07:11:52 2019 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 12 Feb 2019 12:11:52 +0000 Subject: [issue35960] dataclasses.field does not preserve empty metadata object In-Reply-To: <1549847214.14.0.863197964236.issue35960@roundup.psfhosted.org> Message-ID: <1549973512.45.0.780884724723.issue35960@roundup.psfhosted.org> Eric V. Smith added the comment: New changeset 0a834c18cdafa5447d4436878e64aa7a4e4dc817 by Eric V. Smith (Miss Islington (bot)) in branch '3.7': bpo-35960: Fix dataclasses.field throwing away empty metadata. (GH-11815) (GH-11826) https://github.com/python/cpython/commit/0a834c18cdafa5447d4436878e64aa7a4e4dc817 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 07:12:47 2019 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 12 Feb 2019 12:12:47 +0000 Subject: [issue35960] dataclasses.field does not preserve empty metadata object In-Reply-To: <1549847214.14.0.863197964236.issue35960@roundup.psfhosted.org> Message-ID: <1549973567.17.0.19891404368.issue35960@roundup.psfhosted.org> Eric V. Smith added the comment: Thanks for the patch! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 07:55:24 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 12:55:24 +0000 Subject: [issue35972] _xxsubinterpreters: channel_send() may truncate ints on 32-bit platforms In-Reply-To: <1549921968.67.0.462504390355.issue35972@roundup.psfhosted.org> Message-ID: <1549976124.44.0.543330900605.issue35972@roundup.psfhosted.org> STINNER Victor added the comment: What matters here is that _PyCrossInterpreterData.data type is void*. So the largest integer that you can store is intptr_t (signed) or uintptr_t (unsigned). In practice, sizeof(void*) == sizeof(intptr_t) == sizeof(uintptr_t) == sizeof(size_t) == sizeof(ssize_t). IMHO using size_t or ssize_t is a good solution, since it's well supported in Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 08:00:45 2019 From: report at bugs.python.org (=?utf-8?q?J=C3=A9r=C3=B4me_LAURENS?=) Date: Tue, 12 Feb 2019 13:00:45 +0000 Subject: [issue35957] Indentation explanation is unclear In-Reply-To: <1549819617.52.0.344509790006.issue35957@roundup.psfhosted.org> Message-ID: <1549976445.99.0.841355747777.issue35957@roundup.psfhosted.org> J?r?me LAURENS added the comment: To be more precise, consider code def f(x): \tx=0 # 7 spaces + one tab return x # 8 spaces In cpython, both indentation levels are 8 and no indentation error is reported (this is the case where both tab size and alt tab size are equal) If instead of 8 the tab would count for 6 spaces, then we would have 12 and 8 as indentation level, resulting in a mismatch and an indentation error being reported, according to the documentation. This is inconsistent. Then either the documentation is faulty or cpython is. Actually, cpython accepts a mix of space and tabs only when tabs are in 8, 16, 24... positions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 08:01:27 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 13:01:27 +0000 Subject: [issue25461] Unclear language (the word ineffective) in the documentation for os.walk In-Reply-To: <1445533538.52.0.421272081658.issue25461@psf.upfronthosting.co.za> Message-ID: <1549976487.14.0.0850669139981.issue25461@roundup.psfhosted.org> STINNER Victor added the comment: > What is the status on this? From this discussion, it looks like @vstinner pushed changes to resolve this. Do we close this? If this still needs a patch, then one of the patches can be reviewed in a PR on GitHub. It seems like os_walk_doc.patch and issue25461.patch have been written after I pushed my changes. Would you be interested to convert these patches into a proper PR? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 08:06:52 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 13:06:52 +0000 Subject: [issue35971] Documentation should warn about code injection from current working directory In-Reply-To: <1549921560.53.0.488831977782.issue35971@roundup.psfhosted.org> Message-ID: <1549976812.94.0.345473998654.issue35971@roundup.psfhosted.org> STINNER Victor added the comment: Documentation is one thing. But I'm interested to discuss again (in 2019) the idea of changing the default behavior in Python 3.8 to enhance the "default" security. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 08:17:57 2019 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 12 Feb 2019 13:17:57 +0000 Subject: [issue35927] Intra-package References Documentation Incomplete In-Reply-To: <1549514310.42.0.442993756904.issue35927@roundup.psfhosted.org> Message-ID: <1549977477.88.0.425083482491.issue35927@roundup.psfhosted.org> Nick Coghlan added the comment: As discussed in http://python-notes.curiousefficiency.org/en/latest/python_concepts/import_traps.html#executing-the-main-module-twice and https://www.python.org/dev/peps/pep-0395/#why-are-my-imports-broken the cryptic error message here is due to the relative import being resolved based on the module name "__main__", since the submodule was executed directly, rather than the intended "sound.filter.vocoder" name that it would have when imported or executed via the "-m" switch. It's spectacularly unobvious what's going on if you're not deeply familiar with the intricacies of main module execution, but I haven't had any great ideas for practical ways to improve the error message. I'm not sure we currently have access to the required info at the point this error is raised, but perhaps it would be enough to add the name of the module doing the import to the error message as a reminder that directly executing scripts inside packages does weird things to import resolution? Something like: "Attempted relative import beyond top-level package '__main__'" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 08:33:33 2019 From: report at bugs.python.org (Paul Ganssle) Date: Tue, 12 Feb 2019 13:33:33 +0000 Subject: [issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import In-Reply-To: <1549908934.51.0.669039845286.issue35969@roundup.psfhosted.org> Message-ID: <1549978413.63.0.959826866887.issue35969@roundup.psfhosted.org> Paul Ganssle added the comment: > One enhancement of this new API is that it now reports the name of the C function which causes the error. The initial bug report says "Fatal Python error: init_sys_streams: can't initialize sys standard streams": init_sys_streams() function raised the fatal error. I think that's a welcome change, the main question is whether it's necessary to hard-crash the interpreter and dump the core, or if, in most cases, the error message + non-zero return code would be sufficient. It's not clear to me how useful the traceback itself is, but of course I'm giving a toy example where the Python exception is sufficient to debug what's failing. I would think that *in general* if the interpreter is failing to initialize because of a problem in the Python stack, printing the Python traceback should be sufficient. If there's good reason to think otherwise, then I'm fine with closing this bug. Otherwise I'd say it would be nice to refactor in such a way that avoids the core dump when the problem is on the Python side (leaving in place the error message you added that shows where it failed on the C side). > A workaround is the usage of -I option: In this case I don't think we need a workaround, because the issue is really "should it be possible for a pure python crash to cause the interpreter to crash rather than exit with an error code?" Shadowing a standard library module from your PYTHONPATH is just the easiest way to manifest this. (Though probably more people should be using -I, so it's good to bring it up). > A long term solution would to enable -I behavior by default: don't add the current directory to sys.path when using -c CMD. If you've been following the recent issues with the PEP 517 rollout in setuptools, you'll see that I'm deeply sympathetic to this view (though in this case I'm not amazingly optimistic about its feasibility). Probably we shouldn't derail this issue too much with a discussion of our revolutionary views on the right default Python path, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 08:35:18 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 13:35:18 +0000 Subject: [issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import In-Reply-To: <1549908934.51.0.669039845286.issue35969@roundup.psfhosted.org> Message-ID: <1549978518.7.0.524583312588.issue35969@roundup.psfhosted.org> STINNER Victor added the comment: See also bpo-35971: "Documentation should warn about code injection from current working directory" which discuss changing the default behavior. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 09:36:01 2019 From: report at bugs.python.org (Clayton Olney) Date: Tue, 12 Feb 2019 14:36:01 +0000 Subject: [issue14465] xml.etree.ElementTree: add feature to prettify XML output In-Reply-To: <1333294084.01.0.984287406664.issue14465@psf.upfronthosting.co.za> Message-ID: <1549982161.06.0.364676697453.issue14465@roundup.psfhosted.org> Clayton Olney added the comment: I have a use case where the receiving application is expecting the indentation, and I need to run my code in Lambda. So, lxml is out of the question. ---------- nosy: +Clayton Olney _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 10:08:07 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 12 Feb 2019 15:08:07 +0000 Subject: [issue35971] Documentation should warn about code injection from current working directory In-Reply-To: <1549921560.53.0.488831977782.issue35971@roundup.psfhosted.org> Message-ID: <1549984087.31.0.911933729987.issue35971@roundup.psfhosted.org> Ronald Oussoren added the comment: I don't know a good reason for including $PWD in sys.path for "python -m", I expect only scripts that run other scripts (such as coverage.py) might want the current behaviour and those can adjust to new behaviour. For "python -c CMD" the current behaviour is easier to defend, this matches the behaviour w.r.t. sys.path of typing the command in an interactive session. The behaviour for scripts (add the directory where the script is located to sys.path) is also easier to defend: that makes it easier to use scripts without installing stuf and without explicitly managing sys.path. I've used this in the past to split scripts into modules without installing modules in a global directory, but these days I tend to use virtual environment for that. I guess the usefulness of this behaviour depends on the type of user: the current behaviour is useful for more casual use of Python (which includes people learning python) ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 10:11:38 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Tue, 12 Feb 2019 15:11:38 +0000 Subject: [issue35951] os.renames() creates directories if original name doesn't exist In-Reply-To: <1549732242.93.0.821054504106.issue35951@roundup.psfhosted.org> Message-ID: <1549984298.96.0.0324447282775.issue35951@roundup.psfhosted.org> Change by Joannah Nanjekye : ---------- keywords: +patch pull_requests: +11858 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 10:20:21 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 15:20:21 +0000 Subject: [issue35951] os.renames() creates directories if original name doesn't exist In-Reply-To: <1549732242.93.0.821054504106.issue35951@roundup.psfhosted.org> Message-ID: <1549984821.66.0.307672248595.issue35951@roundup.psfhosted.org> Change by STINNER Victor : ---------- versions: +Python 3.8 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 10:40:19 2019 From: report at bugs.python.org (Eric Snow) Date: Tue, 12 Feb 2019 15:40:19 +0000 Subject: [issue35972] _xxsubinterpreters: channel_send() may truncate ints on 32-bit platforms In-Reply-To: <1549921968.67.0.462504390355.issue35972@roundup.psfhosted.org> Message-ID: <1549986019.79.0.769638236965.issue35972@roundup.psfhosted.org> Eric Snow added the comment: Having slept on it and given the extra info you've provided I'm more comfortable with the proposed solution now. :) So the result will be that on 32-bit architectures only 32-bit (signed) ints will be allowed through channels. On 64-bit platforms (and higher) it will still be 64-bit ints. That's a livable outcome, particularly since 32-bit platforms already have to deal with such variation already. :) Plus, the consistency with sys.maxsize makes sense. The alternative (on 32-bit arch) would be to send through a struct containing the long long, similar to what we do for str and bytes. I don't think that's worth it. If it matters we can do something like that later (since it's an implementation detail). Consequently, I've approved the PR. I'll merge it in a little while. Thanks for working on this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 10:41:06 2019 From: report at bugs.python.org (Eric Snow) Date: Tue, 12 Feb 2019 15:41:06 +0000 Subject: [issue35972] _xxsubinterpreters: channel_send() may truncate ints on 32-bit platforms In-Reply-To: <1549921968.67.0.462504390355.issue35972@roundup.psfhosted.org> Message-ID: <1549986066.47.0.403707485842.issue35972@roundup.psfhosted.org> Change by Eric Snow : ---------- components: +Interpreter Core -Extension Modules stage: patch review -> commit review status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 10:42:16 2019 From: report at bugs.python.org (Eric Snow) Date: Tue, 12 Feb 2019 15:42:16 +0000 Subject: [issue35972] _xxsubinterpreters: channel_send() may truncate ints on 32-bit platforms In-Reply-To: <1549921968.67.0.462504390355.issue35972@roundup.psfhosted.org> Message-ID: <1549986136.51.0.800253338191.issue35972@roundup.psfhosted.org> Eric Snow added the comment: FTR, issue #34569 covered similar ground. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 10:46:19 2019 From: report at bugs.python.org (Eric Snow) Date: Tue, 12 Feb 2019 15:46:19 +0000 Subject: [issue35971] Documentation should warn about code injection from current working directory In-Reply-To: <1549921560.53.0.488831977782.issue35971@roundup.psfhosted.org> Message-ID: <1549986379.59.0.114566006708.issue35971@roundup.psfhosted.org> Eric Snow added the comment: +Nick (who may have some insight here) ---------- nosy: +eric.snow, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 10:55:30 2019 From: report at bugs.python.org (Eric Snow) Date: Tue, 12 Feb 2019 15:55:30 +0000 Subject: [issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import In-Reply-To: <1549908934.51.0.669039845286.issue35969@roundup.psfhosted.org> Message-ID: <1549986930.76.0.937671937648.issue35969@roundup.psfhosted.org> Eric Snow added the comment: On Tue, Feb 12, 2019 at 3:57 AM STINNER Victor wrote: > A long term solution would to enable -I behavior by default: don't add the current directory to sys.path when using -c CMD. >From what I can recall, it was a conscious decision to include CWD in sys.path. Doing so benefits some scripting use cases. The downside is the effect when running an app. ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 11:00:32 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 16:00:32 +0000 Subject: [issue35971] Documentation should warn about code injection from current working directory In-Reply-To: <1549921560.53.0.488831977782.issue35971@roundup.psfhosted.org> Message-ID: <1549987232.06.0.222149228365.issue35971@roundup.psfhosted.org> STINNER Victor added the comment: If someone wants to change the Python default behavior, a PEP will be required since it would be a major backward incompatible changes. A lot of details and use cases must be discussed and documented. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 11:02:21 2019 From: report at bugs.python.org (Eric Snow) Date: Tue, 12 Feb 2019 16:02:21 +0000 Subject: [issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import In-Reply-To: <1549908934.51.0.669039845286.issue35969@roundup.psfhosted.org> Message-ID: <1549987341.86.0.341236771994.issue35969@roundup.psfhosted.org> Eric Snow added the comment: related: issue #13475 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 11:02:37 2019 From: report at bugs.python.org (Eric Snow) Date: Tue, 12 Feb 2019 16:02:37 +0000 Subject: [issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import In-Reply-To: <1549908934.51.0.669039845286.issue35969@roundup.psfhosted.org> Message-ID: <1549987357.91.0.777951571582.issue35969@roundup.psfhosted.org> Eric Snow added the comment: @Guido, I recall a while back you explained the value of adding CWD to sys.path. Would you mind providing some insight here? ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 11:02:59 2019 From: report at bugs.python.org (Eric Snow) Date: Tue, 12 Feb 2019 16:02:59 +0000 Subject: [issue35971] Documentation should warn about code injection from current working directory In-Reply-To: <1549921560.53.0.488831977782.issue35971@roundup.psfhosted.org> Message-ID: <1549987379.39.0.173013140926.issue35971@roundup.psfhosted.org> Eric Snow added the comment: related: issue #13475 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 11:04:42 2019 From: report at bugs.python.org (Eric Snow) Date: Tue, 12 Feb 2019 16:04:42 +0000 Subject: [issue35971] Documentation should warn about code injection from current working directory In-Reply-To: <1549921560.53.0.488831977782.issue35971@roundup.psfhosted.org> Message-ID: <1549987482.77.0.108183436179.issue35971@roundup.psfhosted.org> Eric Snow added the comment: Note that I've asked Guido to comment about CWD in sys.path on issue #35969. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 11:06:47 2019 From: report at bugs.python.org (Eric Snow) Date: Tue, 12 Feb 2019 16:06:47 +0000 Subject: [issue35972] _xxsubinterpreters: channel_send() may truncate ints on 32-bit platforms In-Reply-To: <1549921968.67.0.462504390355.issue35972@roundup.psfhosted.org> Message-ID: <1549987607.73.0.634670963617.issue35972@roundup.psfhosted.org> Eric Snow added the comment: New changeset 16f842da3c862d76a1177bd8ef9579703c24fa5a by Eric Snow (Alexey Izbyshev) in branch 'master': bpo-35972: _xxsubinterpreters: Fix potential integer truncation on 32-bit in channel_send() (gh-11822) https://github.com/python/cpython/commit/16f842da3c862d76a1177bd8ef9579703c24fa5a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 11:07:30 2019 From: report at bugs.python.org (Eric Snow) Date: Tue, 12 Feb 2019 16:07:30 +0000 Subject: [issue35972] _xxsubinterpreters: channel_send() may truncate ints on 32-bit platforms In-Reply-To: <1549921968.67.0.462504390355.issue35972@roundup.psfhosted.org> Message-ID: <1549987650.31.0.67616951787.issue35972@roundup.psfhosted.org> Eric Snow added the comment: Thanks, Alexey! ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 11:10:30 2019 From: report at bugs.python.org (Paul Ganssle) Date: Tue, 12 Feb 2019 16:10:30 +0000 Subject: [issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import In-Reply-To: <1549908934.51.0.669039845286.issue35969@roundup.psfhosted.org> Message-ID: <1549987830.24.0.915276793478.issue35969@roundup.psfhosted.org> Paul Ganssle added the comment: > @Guido, I recall a while back you explained the value of adding CWD to sys.path. Would you mind providing some insight here I think bpo-35971 or bpo-13475 are better places to discuss that, because this issue doesn't require CWD to be in the path. You can trigger this by any mechanism that would raise an exception in the Python code used to initialize the interpreter. Even if we restrict it to the most common case - shadowing a part of the standard library - you would still be able to trigger this as long as you have *some* mechanism to manipulate the python path in the environment that allows you to put paths on there with higher precedence than the standard library. I think the core question in this issue is whether errors in the Python code run during the interpreter initialization should crash the interpreter or exit gracefully with an error code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 11:24:41 2019 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 12 Feb 2019 16:24:41 +0000 Subject: [issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import In-Reply-To: <1549908934.51.0.669039845286.issue35969@roundup.psfhosted.org> Message-ID: <1549988681.27.0.347276729738.issue35969@roundup.psfhosted.org> Change by Guido van Rossum : ---------- nosy: -gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 11:27:40 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 16:27:40 +0000 Subject: [issue35977] test_slice crashed on s390x Debian 3.x: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small Message-ID: <1549988860.34.0.384038147585.issue35977@roundup.psfhosted.org> New submission from STINNER Victor : s390x Debian 3.x: https://buildbot.python.org/all/#/builders/13/builds/2344 0:06:26 load avg: 0.92 [291/420/1] test_slice crashed (Exit code -6) Modules/gcmodule.c:110: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small Enable tracemalloc to get the memory block allocation traceback object : .BadCmp object at 0x3ff93967e90> type : BadCmp refcount: 1 address : 0x3ff93967e90 Fatal Python error: _PyObject_AssertFailed Current thread 0x000003ff95272700 (most recent call first): File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/test_slice.py", line 107 in File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/case.py", line 197 in handle File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/case.py", line 782 in assertRaises File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/test_slice.py", line 107 in test_cmp File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/case.py", line 642 in run File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/case.py", line 702 in __call__ ... ---------- components: Interpreter Core messages: 335320 nosy: pablogsal, vstinner priority: normal severity: normal status: open title: test_slice crashed on s390x Debian 3.x: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 11:28:09 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 16:28:09 +0000 Subject: [issue35977] test_slice crashed on s390x Debian 3.x: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549988860.34.0.384038147585.issue35977@roundup.psfhosted.org> Message-ID: <1549988889.28.0.845670940949.issue35977@roundup.psfhosted.org> STINNER Victor added the comment: When the test has been ran one more time in verbose mode, it passed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 11:31:10 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 16:31:10 +0000 Subject: [issue35977] test_slice crashed on s390x Debian 3.x: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549988860.34.0.384038147585.issue35977@roundup.psfhosted.org> Message-ID: <1549989070.7.0.027257694103.issue35977@roundup.psfhosted.org> STINNER Victor added the comment: I'm unable to reproduce the issue on my Fedora 29 (x86-64) laptop. I used two terminals: * ./python -m test -F -j0 test_slice test_slice test_slice test_slice test_slice test_slice test_slice test_slice * ./python -m test -j0 -u all,-gui -r # stress the system to randomize timings in test_slice ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 11:34:12 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 12 Feb 2019 16:34:12 +0000 Subject: [issue35977] test_slice crashed on s390x Debian 3.x: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549988860.34.0.384038147585.issue35977@roundup.psfhosted.org> Message-ID: <1549989252.36.0.733119342253.issue35977@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Duplicate of issue35961 ? It occurs in Travis too ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 11:36:49 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 12 Feb 2019 16:36:49 +0000 Subject: [issue35977] test_slice crashed on s390x Debian 3.x: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549988860.34.0.384038147585.issue35977@roundup.psfhosted.org> Message-ID: <1549989409.66.0.249069821993.issue35977@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Sorry, it occurs in Travis too randomly not consistently. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 11:36:57 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 12 Feb 2019 16:36:57 +0000 Subject: [issue35976] Enable Windows projects to build with platform ARM32 Message-ID: <1549989417.75.0.745284008446.issue35976@roundup.psfhosted.org> New submission from Steve Dower : Just updating the title to reflect what the patch actually does in isolation - you probably should update the PR and NEWS items to match. It's fine (probably preferred) to mention in the issue and PR text that it's been split out from another PR. But we have to account for the (very small) chance that this part is merged and the rest is not - in that case, having a standalone description of the change is much more helpful. ---------- title: PCBuild file changes for arm32 should be separated from code changes for review -> Enable Windows projects to build with platform ARM32 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 11:47:07 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 16:47:07 +0000 Subject: [issue35977] test_slice crashed on s390x Debian 3.x: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549988860.34.0.384038147585.issue35977@roundup.psfhosted.org> Message-ID: <1549990027.34.0.134065482443.issue35977@roundup.psfhosted.org> Change by STINNER Victor : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 11:47:27 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 16:47:27 +0000 Subject: [issue35961] gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> Message-ID: <1549990047.05.0.211123771571.issue35961@roundup.psfhosted.org> STINNER Victor added the comment: bpo-35977 has been marked as a duplicate, copy of the first message: s390x Debian 3.x: https://buildbot.python.org/all/#/builders/13/builds/2344 0:06:26 load avg: 0.92 [291/420/1] test_slice crashed (Exit code -6) Modules/gcmodule.c:110: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small Enable tracemalloc to get the memory block allocation traceback object : .BadCmp object at 0x3ff93967e90> type : BadCmp refcount: 1 address : 0x3ff93967e90 Fatal Python error: _PyObject_AssertFailed Current thread 0x000003ff95272700 (most recent call first): File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/test_slice.py", line 107 in File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/case.py", line 197 in handle File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/case.py", line 782 in assertRaises File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/test_slice.py", line 107 in test_cmp File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/case.py", line 642 in run File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/case.py", line 702 in __call__ ... ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 11:47:35 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 16:47:35 +0000 Subject: [issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> Message-ID: <1549990055.89.0.470527861201.issue35961@roundup.psfhosted.org> Change by STINNER Victor : ---------- title: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small -> test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 11:49:43 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 16:49:43 +0000 Subject: [issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> Message-ID: <1549990183.2.0.0328116685952.issue35961@roundup.psfhosted.org> STINNER Victor added the comment: > I am seeing some failures in travis and some buildbots: Do you have an url to an example of crash on Travis? Which buildbots are affected? I saw the crash on s390x Debian 3.x. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 11:49:58 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 16:49:58 +0000 Subject: [issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> Message-ID: <1549990198.15.0.178412202425.issue35961@roundup.psfhosted.org> STINNER Victor added the comment: I'm unable to reproduce the issue on my Fedora 29 (x86-64) laptop. I used two terminals: * ./python -m test -F -j0 test_slice test_slice test_slice test_slice test_slice test_slice test_slice test_slice * ./python -m test -j0 -u all,-gui -r # stress the system to randomize timings in test_slice ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 11:54:43 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 16:54:43 +0000 Subject: [issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> Message-ID: <1549990483.83.0.257592392903.issue35961@roundup.psfhosted.org> STINNER Victor added the comment: Extract of the crashing test: def test_cmp(self): ... class Exc(Exception): pass class BadCmp(object): def __eq__(self, other): raise Exc s1 = slice(BadCmp()) s2 = slice(BadCmp()) self.assertEqual(s1, s1) self.assertRaises(Exc, lambda: s1 == s2) # <==== CRASH HERE ... The latest change in test_slice.py has been made in 2016: 3 years ago. Latest changes in Objects/sliceobject.c were refactoring related to header files (november 2018). The latest "significant" change was done in April 2018: "bpo-33012: Fix invalid function cast warnings with gcc 8 for METH_NOARGS". I bet more on a recent change which is not directly related to slices... like the implementation of the PEP 572? It would help to know when the crash started to occur exactly (date + time). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 11:55:44 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 16:55:44 +0000 Subject: [issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> Message-ID: <1549990544.16.0.128530855272.issue35961@roundup.psfhosted.org> STINNER Victor added the comment: Lukasz: I'm not sure what is happening here, but such random bugs are always scrary. I raise the priority to "release blocker" until we know more about the issue. ---------- nosy: +lukasz.langa priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 12:05:43 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 17:05:43 +0000 Subject: [issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> Message-ID: <1549991143.61.0.59397577078.issue35961@roundup.psfhosted.org> STINNER Victor added the comment: On s390x Debian 3.x, it seems like the bug started to show up near: https://buildbot.python.org/all/#/builders/13/builds/2328 This build contains 2 changes, one doc change and this namedtuple change which mentions reference count: https://github.com/python/cpython/commit/64360ada0f6123a051e9dc6cd04f030ec1322e46 "Complete and neaten-up namedtuple's replacement of builtin function lookups with derefs (GH-11794)" Ok, but I don't see the relationship between namedtupled and this specific test!? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 12:06:22 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 12 Feb 2019 17:06:22 +0000 Subject: [issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> Message-ID: <1549991182.69.0.98539429926.issue35961@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: > Do you have an url to an example of crash on Travis? Travis crash that occurred few days back : https://travis-ci.org/python/cpython/jobs/491701299 . I first noticed it on an IDLE lib PR where this failure was unrelated but I can remember occurring at least few weeks back. I will try get the older one. Sorry I forgot to file an issue during that time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 12:13:39 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 17:13:39 +0000 Subject: [issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> Message-ID: <1549991619.61.0.884093333409.issue35961@roundup.psfhosted.org> STINNER Victor added the comment: Ah! I found a way to reproduce the crash: diff --git a/Lib/test/test_slice.py b/Lib/test/test_slice.py index 4ae4142c60..b18f8f1c8c 100644 --- a/Lib/test/test_slice.py +++ b/Lib/test/test_slice.py @@ -1,4 +1,8 @@ # tests for slice objects; in particular the indices method. +import gc, random +n = random.randint(1, 700) +print("set_threshold(%s)" % n) +gc.set_threshold(n) import itertools import operator $ ./python -m test -F -j0 test_slice test_slice test_slice test_slice test_slice test_slice test_slice test_slice I went up to January 1st, 2018 (commit e8ed96550c6aa9a1e39c36e67e892994e25e2c41): the test already crashed with my patch, so it's not a regression. I reset the priority. ---------- priority: release blocker -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 12:14:11 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 17:14:11 +0000 Subject: [issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> Message-ID: <1549991651.09.0.817424738622.issue35961@roundup.psfhosted.org> STINNER Victor added the comment: See also this idea of changing gc.set_threshold() when using -X dev: https://mail.python.org/pipermail/python-dev/2018-June/153857.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 12:25:01 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 12 Feb 2019 17:25:01 +0000 Subject: [issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> Message-ID: <1549992301.13.0.780126039145.issue35961@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: It has been crashing for almost all the last 5 PRs merged to master : https://travis-ci.org/python/cpython/jobs/492241988 - Feb 12, 21:51 https://travis-ci.org/python/cpython/jobs/492123432 - Feb 12, 17:33 https://travis-ci.org/python/cpython/jobs/491917875 - Feb 12, 06:20 https://travis-ci.org/python/cpython/jobs/491898690 - Feb 12, 05:15 https://travis-ci.org/python/cpython/jobs/491798997 - Feb 12, 01:19 It's easy to overlook this since PR passes on verbose mode . There is another test these days that fails very frequently but passes on verbose mode : issue35809 . It's little hard to track their first failure since Travis provides no search capability for logs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 12:26:58 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 12 Feb 2019 17:26:58 +0000 Subject: [issue5996] abstract class instantiable when subclassing built-in types In-Reply-To: <1242050763.07.0.145569961651.issue5996@psf.upfronthosting.co.za> Message-ID: <1549992418.73.0.0719354697254.issue5996@roundup.psfhosted.org> Josh Rosenberg added the comment: Closed #35958 as a duplicate of this issue (and updated the title, since clearly the problem is not specific to dict). Patch probably needs to be rebased/rewritten against latest trunk (given it dates from Mercurial days). ---------- nosy: +Jon McMahon, josh.r stage: -> patch review title: abstract class instantiable when subclassing dict -> abstract class instantiable when subclassing built-in types versions: +Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 12:30:26 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Tue, 12 Feb 2019 17:30:26 +0000 Subject: [issue5996] abstract class instantiable when subclassing built-in types In-Reply-To: <1242050763.07.0.145569961651.issue5996@psf.upfronthosting.co.za> Message-ID: <1549992626.27.0.265392807028.issue5996@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 12:36:02 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 12 Feb 2019 17:36:02 +0000 Subject: [issue35918] multiprocessing's SyncManager.dict.has_key() method is broken In-Reply-To: <1549473735.16.0.515862791139.issue35918@roundup.psfhosted.org> Message-ID: <1549992962.62.0.392395992544.issue35918@roundup.psfhosted.org> Change by Josh Rosenberg : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 12:37:52 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 12 Feb 2019 17:37:52 +0000 Subject: [issue35978] test_venv fails in Travis with GCC Message-ID: <1549993072.6.0.794740252515.issue35978@roundup.psfhosted.org> New submission from Karthikeyan Singaravelan : I noticed this while checking issue35961. test_venv is always failing on GCC which is marked as optional in Travis. Log : https://travis-ci.org/python/cpython/jobs/492123436#L1909 0:39:35 load avg: 1.00 [390/416] test_venv test test_venv failed -- Traceback (most recent call last): File "/home/travis/build/python/cpython/Lib/test/test_venv.py", line 309, in test_multiprocessing out, err = check_output([envpy, '-c', File "/home/travis/build/python/cpython/Lib/test/test_venv.py", line 37, in check_output raise subprocess.CalledProcessError( subprocess.CalledProcessError: Command '['/tmp/tmpg8ubeyfn/bin/python', '-c', 'from multiprocessing import Pool; print(Pool(1).apply_async("Python".lower).get(3))']' died with . Also GCC test have been timing out for at least past 4 months : https://python.zulipchat.com/#narrow/stream/116742-core.2Fhelp/topic/GCC.20build.20in.20Travis.20always.20times.20out ---------- messages: 335338 nosy: pablogsal, vstinner, xtreak priority: normal severity: normal status: open title: test_venv fails in Travis with GCC type: behavior versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 12:56:05 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 17:56:05 +0000 Subject: [issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> Message-ID: <1549994165.55.0.991600602869.issue35961@roundup.psfhosted.org> STINNER Victor added the comment: I removed Lukasz from the nosy list since it's not a regression. No need to spam our 3.8 release manager ;-) ---------- nosy: -lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 13:02:57 2019 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 12 Feb 2019 18:02:57 +0000 Subject: [issue5996] abstract class instantiable when subclassing built-in types In-Reply-To: <1242050763.07.0.145569961651.issue5996@psf.upfronthosting.co.za> Message-ID: <1549994577.94.0.707401709378.issue5996@roundup.psfhosted.org> Change by Guido van Rossum : ---------- nosy: -gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 13:10:25 2019 From: report at bugs.python.org (Brennan Vincent) Date: Tue, 12 Feb 2019 18:10:25 +0000 Subject: [issue35973] `growable_int_array type_ignores` in parsetok.c is not always freed. In-Reply-To: <1549926356.5.0.0624072683347.issue35973@roundup.psfhosted.org> Message-ID: <1549995025.27.0.140183396477.issue35973@roundup.psfhosted.org> Brennan Vincent added the comment: Hi Guido, I have tried applying your patch. It seems to fix the issue (Valgrind no longer reports memory definitely lost). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 13:23:18 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 18:23:18 +0000 Subject: [issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> Message-ID: <1549995798.97.0.583350119818.issue35961@roundup.psfhosted.org> Change by STINNER Victor : ---------- keywords: +patch pull_requests: +11859 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 13:24:43 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 18:24:43 +0000 Subject: [issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> Message-ID: <1549995883.03.0.920789374635.issue35961@roundup.psfhosted.org> STINNER Victor added the comment: Extract of slice_richcompare(): t1 = PyTuple_New(3); if (t1 == NULL) return NULL; t2 = PyTuple_New(3); if (t2 == NULL) { Py_DECREF(t1); return NULL; } PyTuple_SET_ITEM(t1, 0, ((PySliceObject *)v)->start); PyTuple_SET_ITEM(t1, 1, ((PySliceObject *)v)->stop); PyTuple_SET_ITEM(t1, 2, ((PySliceObject *)v)->step); PyTuple_SET_ITEM(t2, 0, ((PySliceObject *)w)->start); PyTuple_SET_ITEM(t2, 1, ((PySliceObject *)w)->stop); PyTuple_SET_ITEM(t2, 2, ((PySliceObject *)w)->step); res = PyObject_RichCompare(t1, t2, op); PyTuple_SET_ITEM(t1, 0, NULL); PyTuple_SET_ITEM(t1, 1, NULL); PyTuple_SET_ITEM(t1, 2, NULL); PyTuple_SET_ITEM(t2, 0, NULL); PyTuple_SET_ITEM(t2, 1, NULL); PyTuple_SET_ITEM(t2, 2, NULL); Py_DECREF(t1); Py_DECREF(t2); return res; t1 and t2 tuples are tracked by the GC, but t1 and t2 items are *borrowed* references. gc.collect() calls subtract_refs() which decreases the reference counter of all objects tracked by the GC... but v, w, t1 and t2 contain the same references which causes the assertion error. The code is quite old: commit 47b9ff6ba11fab4c90556357c437cb4feec1e853 Author: Guido van Rossum Date: Thu Aug 24 00:41:19 2006 +0000 Restructure comparison dramatically. There is no longer a default *ordering* between objects; there is only a default equality test (defined by an object being equal to itself only). Read the comment in object.c. The current implementation never uses a three-way comparison to compute a rich comparison, but it does use a rich comparison to compute a three-way comparison. I'm not quite done ripping out all the calls to PyObject_Compare/Cmp, or replacing tp_compare implementations with tp_richcompare implementations; but much of that has happened (to make most unit tests pass). (...) +static PyObject * +slice_richcompare(PyObject *v, PyObject *w, int op) ... + t1 = PyTuple_New(3); + t2 = PyTuple_New(3); + if (t1 == NULL || t2 == NULL) + return NULL; + + PyTuple_SET_ITEM(t1, 0, ((PySliceObject *)v)->start); + PyTuple_SET_ITEM(t1, 1, ((PySliceObject *)v)->stop); + PyTuple_SET_ITEM(t1, 2, ((PySliceObject *)v)->step); + PyTuple_SET_ITEM(t2, 0, ((PySliceObject *)w)->start); + PyTuple_SET_ITEM(t2, 1, ((PySliceObject *)w)->stop); + PyTuple_SET_ITEM(t2, 2, ((PySliceObject *)w)->step); ... I see two options: * Ensure that t1 and t2 temporary objects are not tracked by the GC * Modify slice_richcompare() to use strong references, rather than *borrowed* references I wrote PR 11828 which implements the first solution. The second solution has a minor impact on performance. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 13:30:23 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 18:30:23 +0000 Subject: [issue35505] Test test_imaplib fail in test_imap4_host_default_value In-Reply-To: <1544833222.75.0.788709270274.issue35505@psf.upfronthosting.co.za> Message-ID: <1549996223.52.0.2332244537.issue35505@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 3dc67d0316740e78e7cd014343f34d85908219b7 by Victor Stinner (Mat?j Cepl) in branch 'master': bpo-35505: Skip test_imap4_host_default_value if localhost listens on IMAP port (GH-11823) https://github.com/python/cpython/commit/3dc67d0316740e78e7cd014343f34d85908219b7 ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 13:30:40 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 12 Feb 2019 18:30:40 +0000 Subject: [issue35505] Test test_imaplib fail in test_imap4_host_default_value In-Reply-To: <1544833222.75.0.788709270274.issue35505@psf.upfronthosting.co.za> Message-ID: <1549996240.92.0.952154056352.issue35505@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11860 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 13:43:19 2019 From: report at bugs.python.org (Stefan Behnel) Date: Tue, 12 Feb 2019 18:43:19 +0000 Subject: [issue35810] Object Initialization Bug with Heap-allocated Types In-Reply-To: <1548275752.94.0.463880453345.issue35810@roundup.psfhosted.org> Message-ID: <1549996999.25.0.33731922322.issue35810@roundup.psfhosted.org> Stefan Behnel added the comment: Victor asked me for a review, so, well, what should I say? The intention seems right, and the patch also looks good to me. >From the top of my head, I wouldn't know any problems this would produce with Cython specifically, although it's worth testing. If we find anything, then it's hopefully easy to adapt to in a point release, which Cython users can then build their code with to support Py3.8+. That's the way it usually works with Cython. The main problem I see is that while this change may crash in some cases (the lucky cases that are easy to detect), it will leak references in others, which can be really difficult to detect. My own biased little gut feeling still wants me to believe that the impact of this could be somewhat low. Why? Well, how many heap-allocated types with a custom "tp_dealloc()" do you expect there to be? My feeling is that most existing code still uses statically allocated types for that. CPython has a couple of examples (that the PR adapts), but IIRC, that's mostly because some core devs wanted to test-ride parts of the newer type creation C-API in the standard library (a perfectly valid reason, but that also makes it a bad example). From the little valley that I sit in, I don't see a large bunch of other usages of that API out in the wild. That doesn't mean they are not there, and there might well be some large projects that could be bitten by this change. But I'm sure it's not the majority. So, on the one hand, any breaking change to the C-API may make users end up with little maintained projects that they depend on and that break in Py3.y and later without anyone having access to the PyPI project account to push a fix release. Very annoying situation. On the other hand, a breaking C-API change is not the only problematic case, and people have to deal with similar situations anyway. CPython changes are really just one of many, many ways to render your code unusable. I would suggest clear, open communication of this. It's solving a bug. It makes CPython safer. It's not difficult to adapt your code, once you know it's affected. The usual PY_VERSION_HEX guard will do it for you. I think we should risk it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 13:46:48 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 18:46:48 +0000 Subject: [issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> Message-ID: <1549997208.24.0.0423055962824.issue35961@roundup.psfhosted.org> STINNER Victor added the comment: It's impressive *and* scary that such 13 years old bug only show up today... I modified the GC threshold in the site module with this patch: diff --git a/Lib/site.py b/Lib/site.py index ad1146332b..68cdf105b1 100644 --- a/Lib/site.py +++ b/Lib/site.py @@ -557,6 +557,10 @@ def main(): This function is called automatically when this module is imported, unless the python interpreter was started with the -S flag. """ + import gc, random + n = random.randint(5, 100) + gc.set_threshold(n) + global ENABLE_USER_SITE orig_path = sys.path[:] Running the test suite with this patch doesn't catch the bug :-( $ ./python -m test -j0 -r -u all,-gui ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 13:54:35 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 12 Feb 2019 18:54:35 +0000 Subject: [issue35505] Test test_imaplib fail in test_imap4_host_default_value In-Reply-To: <1544833222.75.0.788709270274.issue35505@psf.upfronthosting.co.za> Message-ID: <1549997675.06.0.917214522562.issue35505@roundup.psfhosted.org> miss-islington added the comment: New changeset 009220eae2e6b456707c1c89ef3f344b682e89d5 by Miss Islington (bot) in branch '3.7': bpo-35505: Skip test_imap4_host_default_value if localhost listens on IMAP port (GH-11823) https://github.com/python/cpython/commit/009220eae2e6b456707c1c89ef3f344b682e89d5 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 13:59:49 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 12 Feb 2019 18:59:49 +0000 Subject: [issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> Message-ID: <1549997989.75.0.36622959368.issue35961@roundup.psfhosted.org> Josh Rosenberg added the comment: Victor found the same bug I found while I was composing this, posting only to incorporate proposed solution: I *think* I have a cause for this, but someone else with greater understanding of the cycle collector should check me if the suggested fix has non-trivial performance implications (I suspect the answer is no, performance is unaffected). slice_richcompare borrows its behavior from tuple by creating a temporary tuple for each slice, the delegating to the tuple comparison ( https://github.com/python/cpython/blob/master/Objects/sliceobject.c#L591 ). Problem is, it uses borrowed references when creating said tuples, not owned references. Because test_slice's BadCmp.__eq__ is implemented in Python, the comparison can be interrupted by cycle collection during the __eq__ call. When then happens, there are precisely two references to the BadCmp object: 1. In the slice (owned) 2. In the temporary tuple (borrowed) When a cycle collection occurs during the comparison, and subtract_refs ( https://github.com/python/cpython/blob/master/Modules/gcmodule.c#L398 ) is called, the BadCmp object in question is visited via both the slice and the tuple, and since it has no non-container objects referencing it, it ends up with the initial reference count of 1 attempting to drop to -1, and the assertion is violated. While the code of gcmodule.c appears to have been refactored since 3.7 so the assert occurs in a different function, with a slightly different message, it would break the same way in both 3.7 and master, and whether or not it triggers the bug, the broken behavior of slice_richcompare hasn't changed for a *long* time. Underlying problem would seem to be slice's richcompare believing it's okay to make a tuple from borrowed references, then make a call on it that can trigger calls into Python level code (and therefore into the cycle collector); everything else is behaving correctly here. I'm guessing the only reason it's not seen in the wild is that slices based on Python defined types are almost never compared at all, let alone compared on debug builds that would be checking the assert and with an accelerated cycle collection cycle that would make a hit likely. Solution would be to stop trying to microoptimize slice_richcompare to avoid reference count manipulation and just build a proper tuple. It would even simplify the code since we could just use PyTuple_Pack, reducing custom code by replacing: t1 = PyTuple_New(3); if (t1 == NULL) return NULL; t2 = PyTuple_New(3); if (t2 == NULL) { Py_DECREF(t1); return NULL; } PyTuple_SET_ITEM(t1, 0, ((PySliceObject *)v)->start); PyTuple_SET_ITEM(t1, 1, ((PySliceObject *)v)->stop); PyTuple_SET_ITEM(t1, 2, ((PySliceObject *)v)->step); PyTuple_SET_ITEM(t2, 0, ((PySliceObject *)w)->start); PyTuple_SET_ITEM(t2, 1, ((PySliceObject *)w)->stop); PyTuple_SET_ITEM(t2, 2, ((PySliceObject *)w)->step); with: t1 = PyTuple_Pack(3, ((PySliceObject *)v)->start, ((PySliceObject *)v)->stop, ((PySliceObject *)v)->step); if (t1 == NULL) return NULL; t2 = PyTuple_Pack(3, ((PySliceObject *)w)->start, ((PySliceObject *)w)->stop, ((PySliceObject *)w)->step); if (t2 == NULL) { Py_DECREF(t1); return NULL; } and makes cleanup simpler, since you can just delete: PyTuple_SET_ITEM(t1, 0, NULL); PyTuple_SET_ITEM(t1, 1, NULL); PyTuple_SET_ITEM(t1, 2, NULL); PyTuple_SET_ITEM(t2, 0, NULL); PyTuple_SET_ITEM(t2, 1, NULL); PyTuple_SET_ITEM(t2, 2, NULL); and let the DECREFs for t1/t2 do their work normally. If for some reason the reference count manipulation is unacceptable, this *could* switch between two behaviors depending on whether or not start/stop/step are of known types (e.g. if all are NoneType/int, this could use the borrowed refs code path safely) where a call back into Python level code is impossible; given that slices are usually made of None and/or ints, this would remove most of the cost for the common case, at the expense of more complicated code. Wouldn't help numpy types though, and I suspect the cost of pre-checking the types for all six values involved would eliminate most of the savings. Sorry for not submitting a proper PR; the work machine I use during the day is not suitable for development (doesn't even have Python installed). ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 14:00:07 2019 From: report at bugs.python.org (Tim Peters) Date: Tue, 12 Feb 2019 19:00:07 +0000 Subject: [issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> Message-ID: <1549998007.73.0.631454028213.issue35961@roundup.psfhosted.org> Tim Peters added the comment: > It's impressive *and* scary that such 13 years old > bug only show up today... Then again, there's probably no other code in the world that compares slice objects ;-) ---------- nosy: +tim.peters -josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 14:02:06 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 19:02:06 +0000 Subject: [issue35810] Object Initialization Bug with Heap-allocated Types In-Reply-To: <1548275752.94.0.463880453345.issue35810@roundup.psfhosted.org> Message-ID: <1549998126.46.0.974435146638.issue35810@roundup.psfhosted.org> STINNER Victor added the comment: > I would suggest clear, open communication of this. It's solving a bug. It makes CPython safer. It's not difficult to adapt your code, once you know it's affected. The usual PY_VERSION_HEX guard will do it for you. I think we should risk it. It would be nice to give an example of code in the Porting guide (What's new in Python 3.8?). ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 14:11:40 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 12 Feb 2019 19:11:40 +0000 Subject: [issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> Message-ID: <1549998700.18.0.0988658854342.issue35961@roundup.psfhosted.org> Josh Rosenberg added the comment: Ah, I see Victor posted an alternative PR that avoids the reference counting overhead by explicitly removing the temporary tuples from GC tracking. I'm mildly worried by that approach, only because the only documented use case for PyObject_GC_UnTrack is in tp_dealloc (that said, the code explicitly allows it to be called twice due to the Py_TRASHCAN mechanism, so it's probably safe so long as the GC design never changes dramatically). If slice comparison really is performance sensitive enough to justify this, so be it, but I'd personally prefer to reduce the custom code involved in a rarely used code path (we're not even caching constant slices yet, so no comparisons are likely to occur for 99.99% of slices, right?). ---------- nosy: +josh.r versions: +Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 14:18:24 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 19:18:24 +0000 Subject: [issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> Message-ID: <1549999104.91.0.962155789414.issue35961@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +11861 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 14:19:52 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 19:19:52 +0000 Subject: [issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> Message-ID: <1549999192.0.0.305778787779.issue35961@roundup.psfhosted.org> STINNER Victor added the comment: I wrote PR 11830: the other solution that I propose, use strong references rather than borrowed references. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 14:20:37 2019 From: report at bugs.python.org (Tim Peters) Date: Tue, 12 Feb 2019 19:20:37 +0000 Subject: [issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> Message-ID: <1549999237.12.0.103769816456.issue35961@roundup.psfhosted.org> Tim Peters added the comment: Josh, I'd say the speed of this code doesn't matter one whit to anything. Like you, I'd _prefer_ that the issue be fixed by building "real tuples" that own their own references, which would also (as you showed) allow for briefer, simpler, clearer code. But I'm OK with playing obscure GC tricks too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 14:21:44 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 19:21:44 +0000 Subject: [issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> Message-ID: <1549999304.18.0.895251871999.issue35961@roundup.psfhosted.org> STINNER Victor added the comment: > Then again, there's probably no other code in the world that compares slice objects ;-) Well, that's a good explanation :-) So maybe there is no need to keep the micro-optimization and PR 11830 would be safer (use strong references), rather than PR 11828 (untrack the 2 internal tuples). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 14:29:15 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 19:29:15 +0000 Subject: [issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> Message-ID: <1549999755.84.0.982875678008.issue35961@roundup.psfhosted.org> STINNER Victor added the comment: Oh, Tim Peters succeded somehow to remove Josh Rosenberg from the nosy list: I add him again ;-) Thanks Josh for your analysis, it seems like we agree :-) I wrote PR 11830 to use strong references, as you proposed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 14:30:34 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 19:30:34 +0000 Subject: [issue35978] test_venv fails in Travis with GCC In-Reply-To: <1549993072.6.0.794740252515.issue35978@roundup.psfhosted.org> Message-ID: <1549999834.54.0.236101383988.issue35978@roundup.psfhosted.org> STINNER Victor added the comment: Pablo: Can this issue be related bpo-35378? commit 3766f18c524c57784eea7c0001602017d2122156 Author: Pablo Galindo Date: Mon Feb 11 17:29:00 2019 +0000 bpo-35378: Fix multiprocessing.Pool references (GH-11627) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 14:31:09 2019 From: report at bugs.python.org (Tim Peters) Date: Tue, 12 Feb 2019 19:31:09 +0000 Subject: [issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> Message-ID: <1549999869.16.0.770447901333.issue35961@roundup.psfhosted.org> Tim Peters added the comment: > Oh, Tim Peters succeded somehow to > remove Josh Rosenberg from the nosy list: I add him again ;-) Certainly wasn't my intent! That happens too often on the tracker. Thanks for noticing! :-( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 14:37:23 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 12 Feb 2019 19:37:23 +0000 Subject: [issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> Message-ID: <1550000243.93.0.0910160222976.issue35961@roundup.psfhosted.org> Josh Rosenberg added the comment: +1 on PR 11830 from me. Can always revisit if #11107 is ever implemented and it turns out that the reference count manipulation means startup is too slow due to all the slice interning triggered comparisons (unlikely, but theoretically possible I guess). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 14:39:07 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 19:39:07 +0000 Subject: [issue34172] multiprocessing.Pool and ThreadPool leak resources after being deleted In-Reply-To: <1532105129.76.0.56676864532.issue34172@psf.upfronthosting.co.za> Message-ID: <1550000347.09.0.128614334109.issue34172@roundup.psfhosted.org> STINNER Victor added the comment: Pablo fixed bpo-35378 with: New changeset 3766f18c524c57784eea7c0001602017d2122156 by Pablo Galindo in branch 'master': bpo-35378: Fix multiprocessing.Pool references (GH-11627) https://github.com/python/cpython/commit/3766f18c524c57784eea7c0001602017d2122156 Does this change also fix this issue? If not, can we attempt again to fix this issue? Moreover, should we do something in Python 3.7? Sadly, I don't think that we can do anything for 3.7 and 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 14:39:32 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 19:39:32 +0000 Subject: [issue35378] multiprocessing.Pool.imaps iterators do not maintain alive the multiprocessing.Pool objects In-Reply-To: <1543769012.57.0.788709270274.issue35378@psf.upfronthosting.co.za> Message-ID: <1550000372.79.0.92987898475.issue35378@roundup.psfhosted.org> STINNER Victor added the comment: Thanks Pablo for the fix ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 14:39:51 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 12 Feb 2019 19:39:51 +0000 Subject: [issue35978] test_venv fails in Travis with GCC In-Reply-To: <1549993072.6.0.794740252515.issue35978@roundup.psfhosted.org> Message-ID: <1550000391.12.0.00100926773753.issue35978@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: That looks like a similar example of the problem that bpo35378 solves. But the PR is merged and the test keeps failing: test test_venv failed -- Traceback (most recent call last): File "/home/travis/build/python/cpython/Lib/test/test_venv.py", line 309, in test_multiprocessing out, err = check_output([envpy, '-c', File "/home/travis/build/python/cpython/Lib/test/test_venv.py", line 37, in check_output raise subprocess.CalledProcessError( subprocess.CalledProcessError: Command '['/tmp/tmplplx90pf/bin/python', '-c', 'from multiprocessing import Pool; print(Pool(1).apply_async("Python".lower).get(3))']' died with . https://travis-ci.org/python/cpython/jobs/492305033 Running that command locally on master does not die with SIGABRT: ? ./python -c 'from multiprocessing import Pool; print(Pool(1).apply_async("Python".lower).get(3))'; echo $? python /home/pablogsal/github/cpython/Lib/multiprocessing/pool.py:234: ResourceWarning: unclosed running multiprocessing pool _warn(f"unclosed running multiprocessing pool {self!r}", ResourceWarning: Enable tracemalloc to get the object allocation traceback 0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 14:46:22 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 12 Feb 2019 19:46:22 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1550000782.08.0.282062082797.issue35813@roundup.psfhosted.org> Antoine Pitrou added the comment: Davin: > This is my fault because I altered SharedMemoryManager to no longer support functionality from SyncManager that I thought could be confusing to include. I am just now discovering this and am not immediately sure if simply removing the SharedMemoryManager-relevant lines from your patch is the right solution but I wanted to mention this thought right away. If SharedMemoryManager subclasses SyncManager then I *think* it should obey the SyncManager contract. Regardless of the shared memory facility, the user may also want to "shared" regular proxies between processes. (to be honest, I don't think the multiprocessing Manager facility is used a lot currently...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 14:54:49 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 19:54:49 +0000 Subject: [issue35978] test_venv fails in Travis with GCC In-Reply-To: <1549993072.6.0.794740252515.issue35978@roundup.psfhosted.org> Message-ID: <1550001289.52.0.960858378428.issue35978@roundup.psfhosted.org> STINNER Victor added the comment: I can reproduce the crash using the same command than the job. Simplified commands to reproduce the bug: ./configure && make ./python -m venv venv ./venv/bin/python -m test test_venv -m test.test_venv.BasicTest.test_multiprocessing ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 14:56:21 2019 From: report at bugs.python.org (Davin Potts) Date: Tue, 12 Feb 2019 19:56:21 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1550001381.92.0.996000312072.issue35813@roundup.psfhosted.org> Davin Potts added the comment: @Antoine: SharedMemoryManager does not subclass SyncManager but it did previously. This is the source of the confusion. SharedMemoryManager subclasses BaseManager which does not provide Value, Array, list, dict, etc. Agreed that the manager facility does not appear to see that much use in existing code. When working with shared memory, I expect SharedMemoryManager to be much more popular. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 14:58:39 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 19:58:39 +0000 Subject: [issue35978] test_venv fails in Travis with GCC In-Reply-To: <1549993072.6.0.794740252515.issue35978@roundup.psfhosted.org> Message-ID: <1550001519.3.0.479496354293.issue35978@roundup.psfhosted.org> STINNER Victor added the comment: The Python of the virtual environment created by the test doesn't work: $ /tmp/tmp0vybyos2/bin/python -c pass Could not find platform independent libraries Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] Fatal Python error: initfsencoding: failed to get the Python codec of the filesystem encoding ModuleNotFoundError: No module named 'encodings' Current thread 0x00007f2956ab8740 (most recent call first): Aborted ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 15:02:15 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 20:02:15 +0000 Subject: [issue35978] test_venv fails in Travis with GCC In-Reply-To: <1549993072.6.0.794740252515.issue35978@roundup.psfhosted.org> Message-ID: <1550001735.32.0.793934521433.issue35978@roundup.psfhosted.org> STINNER Victor added the comment: Hum, test_executable() of test_venv is skipped if run in a venv, but not test_multiprocessing(): # If a venv is created from a source build and that venv is used to # run the test, the pyvenv.cfg in the venv created in the test will # point to the venv being used to run the test, and we lose the link # to the source build - so Python can't initialise properly. @skipInVenv ... self.run_with_capture(venv.create, self.env_dir) envpy = os.path.join(os.path.realpath(self.env_dir), self.bindir, self.exe) ... def test_multiprocessing(self): ... self.run_with_capture(venv.create, self.env_dir) envpy = os.path.join(os.path.realpath(self.env_dir), self.bindir, self.exe) ... The test has been added by: commit 4e02f8f8b4baab63f927cfd87b401200ba2969e9 Author: Steve Dower Date: Fri Jan 25 14:59:12 2019 -0800 ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 15:15:16 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 12 Feb 2019 20:15:16 +0000 Subject: [issue35155] Clarify Protocol Handlers in urllib.request Docs In-Reply-To: <1541286673.86.0.788709270274.issue35155@psf.upfronthosting.co.za> Message-ID: <1550002516.67.0.987178703271.issue35155@roundup.psfhosted.org> Terry J. Reedy added the comment: Cheryl, you know rst better than me. Is there any markup to indicate that a word is a placeholder, not meant to be taken literally? Or is Denton's '' instead of 'placeholder' the best choice? See the PR and answer there. ---------- nosy: +cheryl.sabella, orsenthil, terry.reedy versions: -Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 15:22:54 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 12 Feb 2019 20:22:54 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1550002974.91.0.298937464696.issue35813@roundup.psfhosted.org> Antoine Pitrou added the comment: > SharedMemoryManager does not subclass SyncManager but it did previously. Ah, right. Then it's ok to change the tests IMO. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 15:38:40 2019 From: report at bugs.python.org (Eddie Elizondo) Date: Tue, 12 Feb 2019 20:38:40 +0000 Subject: [issue35810] Object Initialization Bug with Heap-allocated Types In-Reply-To: <1548275752.94.0.463880453345.issue35810@roundup.psfhosted.org> Message-ID: <1550003920.96.0.642847264739.issue35810@roundup.psfhosted.org> Eddie Elizondo added the comment: Thanks for the thorough feedback Stefan! I would like to just add an extra thing to everything you already mentioned: This change will NEVER cause a crash. The change that we are introducing is an incref to a type object (no decrefs). Thus, there are two-ish scenarios: 1) The type object is immortal: This means that the type does not incref/decref its refcount automatically on instance creation. Adding this incref will not affect the fact that it's already immortal. An example of this is structsequences. The change that I added in the PR is to convert it to an refcounted type (instead of immortal). 2.1) The type is recounted (automatically): Achieved through the generic allocation which already increfs the type. Given that this refactors that incref, then this behavior should stay exactly the same. 2.2) The type is refcounted (manually): Achieved by not using the generic allocation and instead using `PyObject_{,GC}_New{Var}`. To properly refcount this type, a manual incref is required after object instantiation. Usually, I've seen this pattern in very carefully engineered types where a NULL is jammed into `tp_new` to make it into a non-instantiable type. Examples of this are Modules/_tkinter.c and Modules/_curses_panel.c. Anyways, adding this incref will leak this type, but will not cause a crash. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 15:45:48 2019 From: report at bugs.python.org (Eddie Elizondo) Date: Tue, 12 Feb 2019 20:45:48 +0000 Subject: [issue35810] Object Initialization Bug with Heap-allocated Types In-Reply-To: <1548275752.94.0.463880453345.issue35810@roundup.psfhosted.org> Message-ID: <1550004348.94.0.0309475135061.issue35810@roundup.psfhosted.org> Eddie Elizondo added the comment: Now, with that in mind - can you guys point me to the right thing to do now - how can we move this forward? :) * Should I write something up in python-dev/Discourse? * Do I need to update the PY_VERSION_HEX? * Do I need to write an entry in the Porting guide? Let me know what you think! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 15:57:12 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Feb 2019 20:57:12 +0000 Subject: [issue35505] Test test_imaplib fail in test_imap4_host_default_value In-Reply-To: <1544833222.75.0.788709270274.issue35505@psf.upfronthosting.co.za> Message-ID: <1550005032.28.0.107529063724.issue35505@roundup.psfhosted.org> STINNER Victor added the comment: Thanks Mat?j Cepl for the fix and thanks Petr Stupka for the bug report ;-) ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 16:03:10 2019 From: report at bugs.python.org (Stefan Behnel) Date: Tue, 12 Feb 2019 21:03:10 +0000 Subject: [issue35810] Object Initialization does not incref Heap-allocated Types In-Reply-To: <1548275752.94.0.463880453345.issue35810@roundup.psfhosted.org> Message-ID: <1550005390.79.0.977937580356.issue35810@roundup.psfhosted.org> Stefan Behnel added the comment: Adding Christian Tismer to the nosy list since he might be able to elaborate on the impact on PySide (which IIRC uses the stable ABI, and thus, heap types). ---------- components: +Extension Modules, Interpreter Core -Library (Lib) nosy: +Christian.Tismer title: Object Initialization Bug with Heap-allocated Types -> Object Initialization does not incref Heap-allocated Types type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 16:46:51 2019 From: report at bugs.python.org (Matthew Barnett) Date: Tue, 12 Feb 2019 21:46:51 +0000 Subject: [issue35155] Clarify Protocol Handlers in urllib.request Docs In-Reply-To: <1541286673.86.0.788709270274.issue35155@psf.upfronthosting.co.za> Message-ID: <1550008011.57.0.0304101101712.issue35155@roundup.psfhosted.org> Matthew Barnett added the comment: You could italicise the "protocol" part using asterisks, like this: *protocol*_request or this: *protocol*\ _request depending on the implementation of the rst software. ---------- nosy: +mrabarnett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 16:55:24 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 12 Feb 2019 21:55:24 +0000 Subject: [issue35967] Better platform.processor support In-Reply-To: <1549895363.53.0.252912531241.issue35967@roundup.psfhosted.org> Message-ID: <1550008524.38.0.316952337887.issue35967@roundup.psfhosted.org> Antoine Pitrou added the comment: Your proposal sounds fine to me. You could fall back on platform.machine() instead of calling `uname` explicitly. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 17:32:24 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Tue, 12 Feb 2019 22:32:24 +0000 Subject: [issue35155] Clarify Protocol Handlers in urllib.request Docs In-Reply-To: <1541286673.86.0.788709270274.issue35155@psf.upfronthosting.co.za> Message-ID: <1550010744.28.0.000499006477221.issue35155@roundup.psfhosted.org> Cheryl Sabella added the comment: I don't think there is anything specifically defined for a placeholder. However, looking at the current urllib.request documentation, there are 2 places that use the ``_`` method for a placeholder - .proxy and .proxy, with the latter explaining what means. > By default, ProxyHandler uses the environment variables named _proxy, where is the URL scheme involved. That line was added by Georg Brandl (granted it was part of converting all the docs), which would lead me to believe that is the accepted way to do it. Also, the argument clinic how-to has the following: > The length of the string will be passed in to the impl function, just after the string parameter, as a parameter named ``_length``. I'll make a comment on the PR too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 17:32:26 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 12 Feb 2019 22:32:26 +0000 Subject: [issue35951] os.renames() creates directories if original name doesn't exist In-Reply-To: <1549732242.93.0.821054504106.issue35951@roundup.psfhosted.org> Message-ID: <1550010746.18.0.354844418934.issue35951@roundup.psfhosted.org> Giampaolo Rodola' added the comment: The proposed change makes the problem a lot less likely to occur, but technically it doesn't fix it because if the src file/dir disappears between "os.path.exists(src)" and os.rename(src, dst)" calls you'll end up with a race condition. We may still want to do it, but can't make promises about full reliability. Also, it seems to me this behavior should be expected, because the doc explains the whole thing basically happens as a 3-step process (create dst dirs, rename, remove old src path). As such the cleanup in case of failure should not be expected, nor is promised. Also, FileNotFoundError is just one. os.rename() may fail for other reasons (and still leave the dst directory tree behind). If there is something we can do here is probably make the doc more clear (it talks about "lack of permissions" when instead it should have talked on "any error". Extra (unrelated): as I commented on the PR, there are no unit-tests for os.renames(). ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 17:39:36 2019 From: report at bugs.python.org (Brandt Bucher) Date: Tue, 12 Feb 2019 22:39:36 +0000 Subject: [issue35936] Give modulefinder some much-needed updates. In-Reply-To: <1549596039.09.0.478412891062.issue35936@roundup.psfhosted.org> Message-ID: <1550011176.81.0.607922944735.issue35936@roundup.psfhosted.org> Change by Brandt Bucher : ---------- nosy: +barry, brett.cannon, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 17:40:57 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 12 Feb 2019 22:40:57 +0000 Subject: [issue35942] posixmodule.c:path_converter() returns an invalid exception message for broken PathLike objects In-Reply-To: <1549643679.09.0.475002054663.issue35942@roundup.psfhosted.org> Message-ID: <1550011257.24.0.691396641026.issue35942@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- keywords: +patch pull_requests: +11862 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 18:11:05 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 12 Feb 2019 23:11:05 +0000 Subject: [issue35973] `growable_int_array type_ignores` in parsetok.c is not always freed. In-Reply-To: <1549926356.5.0.0624072683347.issue35973@roundup.psfhosted.org> Message-ID: <1550013065.74.0.0819647550848.issue35973@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- keywords: +patch pull_requests: +11863 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 18:20:09 2019 From: report at bugs.python.org (Zackery Spytz) Date: Tue, 12 Feb 2019 23:20:09 +0000 Subject: [issue21360] mailbox.Maildir should ignore files named with a leading dot In-Reply-To: <1398550003.67.0.360972625113.issue21360@psf.upfronthosting.co.za> Message-ID: <1550013609.8.0.0722397282966.issue21360@roundup.psfhosted.org> Zackery Spytz added the comment: I've created a PR for this issue. ---------- nosy: +ZackerySpytz versions: +Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 18:27:01 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 12 Feb 2019 23:27:01 +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: <1550014021.5.0.670704981722.issue26415@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- nosy: +pablogsal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 18:29:16 2019 From: report at bugs.python.org (Joshua Oreman) Date: Tue, 12 Feb 2019 23:29:16 +0000 Subject: [issue32810] Expose ags_gen and agt_gen in asynchronous generators In-Reply-To: <1518205773.11.0.467229070634.issue32810@psf.upfronthosting.co.za> Message-ID: <1550014156.13.0.159793067372.issue32810@roundup.psfhosted.org> Joshua Oreman added the comment: I also ran into this. My workaround was to use gc.get_referents() on the async_generator_asend object, which returns a one-element list containing the async generator object. I don't know if this is guaranteed or just happened to work in the cases I was using it, but it might be good enough? ---------- nosy: +Joshua Oreman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 18:57:07 2019 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 12 Feb 2019 23:57:07 +0000 Subject: [issue35951] os.renames() creates directories if original name doesn't exist In-Reply-To: <1549732242.93.0.821054504106.issue35951@roundup.psfhosted.org> Message-ID: <1550015827.15.0.788519818369.issue35951@roundup.psfhosted.org> Chris Jerdonek added the comment: > As such the cleanup in case of failure should not be expected, Given that the documentation specifically calls out permissions errors as a cause of leaving the new directory in place, it wouldn't be unreasonable for someone to think the function does a cleanup step on failure using the same pruning process on the target directory. In fact, that scenario is the one scenario I can think of that makes how the note is written make sense -- the cleanup step not having permissions to remove the intermediate directories it just created ("This function can fail with the new directory structure made if you lack permissions needed to remove the leaf directory or file [just created]"). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 19:42:47 2019 From: report at bugs.python.org (Dan Snider) Date: Wed, 13 Feb 2019 00:42:47 +0000 Subject: [issue35979] Incorrect __text_signature__ for the __get__ slot wrapper Message-ID: <1550018567.03.0.305357698132.issue35979@roundup.psfhosted.org> New submission from Dan Snider : The current signature: "__get__($self, instance, owner, /)\n--\n\nReturn an attribute of instance, which is of type owner." doens't match how wrap_descr_get actually parses the arguments to __get__ with: PyArg_UnpackTuple(args, "", 1, 2, &obj, &type) ---------- messages: 335378 nosy: bup priority: normal severity: normal status: open title: Incorrect __text_signature__ for the __get__ slot wrapper _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 20:08:44 2019 From: report at bugs.python.org (shawnberry) Date: Wed, 13 Feb 2019 01:08:44 +0000 Subject: [issue35980] Py3 BIF random.choices() is O(N**2) but I've written O(N) code for the same task Message-ID: <1550020124.01.0.607459314938.issue35980@roundup.psfhosted.org> New submission from shawnberry : Please see my GitHub page https://github.com/shawnberry/Improved_random.choices/blob/master/Improved_Py3_BIF_random_dot_choices.py for code that reduces Py3 BIF random.choices() from O(N**2) to O(N). This is my first suggestion to improve Python code. Thanks, shawnberry121 at gmail.com ---------- components: Library (Lib) files: Improved_Py3_BIF_random_dot_choices.py hgrepos: 380 messages: 335379 nosy: shawn_berry priority: normal severity: normal status: open title: Py3 BIF random.choices() is O(N**2) but I've written O(N) code for the same task type: performance versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 Added file: https://bugs.python.org/file48135/Improved_Py3_BIF_random_dot_choices.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 20:13:50 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Wed, 13 Feb 2019 01:13:50 +0000 Subject: [issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import In-Reply-To: <1549908934.51.0.669039845286.issue35969@roundup.psfhosted.org> Message-ID: <1550020430.08.0.744202748632.issue35969@roundup.psfhosted.org> Emmanuel Arias added the comment: > Otherwise I'd say it would be nice to refactor in such a way that avoids the core dump when the problem is on the Python side I agree with @p-ganssle, If exist some problem on initialize Python interpreter it would be great if it return a non-zero status and avoid an abort() + Python3.5. I test it and has the same result. ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 20:27:22 2019 From: report at bugs.python.org (Ammar Askar) Date: Wed, 13 Feb 2019 01:27:22 +0000 Subject: [issue35980] Py3 BIF random.choices() is O(N**2) but I've written O(N) code for the same task In-Reply-To: <1550020124.01.0.607459314938.issue35980@roundup.psfhosted.org> Message-ID: <1550021242.22.0.926987022363.issue35980@roundup.psfhosted.org> Ammar Askar added the comment: I can't speak to the complexity of the choices function but if you're proposing an alternative implementation for choices, it would be wise to show the benefits empirically. That is, benchmarks and an explanation of why your implementation would be better than just an example of your code among an example. Additionally, you need to expand your implementation to match all the functionality of the current function and make a pull request to the main Python repository. Adding Raymond to nosy, the original author of random.choices ---------- nosy: +ammar2, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 20:43:55 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Wed, 13 Feb 2019 01:43:55 +0000 Subject: [issue35980] Py3 BIF random.choices() is O(N**2) but I've written O(N) code for the same task In-Reply-To: <1550020124.01.0.607459314938.issue35980@roundup.psfhosted.org> Message-ID: <1550022235.7.0.82891024643.issue35980@roundup.psfhosted.org> Change by Emmanuel Arias : ---------- nosy: +eamanu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 20:44:15 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Wed, 13 Feb 2019 01:44:15 +0000 Subject: [issue35962] Slight error in words in [ 2.4.1. String and Bytes literals ] In-Reply-To: <1549879959.7.0.265215879488.issue35962@roundup.psfhosted.org> Message-ID: <1550022255.51.0.543790717712.issue35962@roundup.psfhosted.org> Change by Cheryl Sabella : ---------- nosy: +ncoghlan versions: +Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 20:45:06 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Wed, 13 Feb 2019 01:45:06 +0000 Subject: [issue35980] Py3 BIF random.choices() is O(N**2) but I've written O(N) code for the same task In-Reply-To: <1550020124.01.0.607459314938.issue35980@roundup.psfhosted.org> Message-ID: <1550022306.5.0.0584696050893.issue35980@roundup.psfhosted.org> Steven D'Aprano added the comment: What's "BIF" mean? You use that term multiple times but I have never heard it before. I'm sorry, I don't understand your code (and don't have time to study it in detail to decipher it). It would help if you factored out your new implementation of choices() into a separate function. I see that your timing code it not reliable for timing individual function calls. You include your setup code that builds the input to choices() as well as the time it takes to print messages, so we can't really draw any reliable conclusions about the speed of choices() from your timings. To give an analogy: you start the stopwatch at home. Climb into the shower and wash, get dressed, have breakfast, drive to work, park the car, buy a coffee at the shop next door, go to your office, greet your fellow co-workers, and finally stop the stopwatch. And then you say that the total time measured was the time it took you to drive to work alone. Finally, I can't actually work out what part of your code is intended as a replacement for the choices() function. You should factor it out into a separate function, then time the two function calls: choices(dataset, weights) shawn_choices(dataset, weights) alone (without timing the setup of the datasets, or the I/O, or any other irrelevant costs). You probably should use the timeit module for the actual timing. As for the versions of Python, 3.6 and older are in "bug fix only" mode, so this will not apply to anything older than 3.7. ---------- nosy: +steven.daprano versions: -Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 20:56:36 2019 From: report at bugs.python.org (Michael Sullivan) Date: Wed, 13 Feb 2019 01:56:36 +0000 Subject: [issue34235] PyArg_ParseTupleAndKeywords: support required keyword arguments In-Reply-To: <1532610257.0.0.56676864532.issue34235@psf.upfronthosting.co.za> Message-ID: <1550022996.93.0.924038758853.issue34235@roundup.psfhosted.org> Change by Michael Sullivan : ---------- keywords: +patch pull_requests: +11865 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 21:33:50 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 13 Feb 2019 02:33:50 +0000 Subject: [issue35155] Clarify Protocol Handlers in urllib.request Docs In-Reply-To: <1541286673.86.0.788709270274.issue35155@psf.upfronthosting.co.za> Message-ID: <1550025230.18.0.533647287072.issue35155@roundup.psfhosted.org> Terry J. Reedy added the comment: unittest is another module with half-fixed and half-variable names. The default (glob) pattern for test module names is given as "test*.py". The fixed pattern for test methods is given as "starts with 'test'". This could have been given, I believe, as re "test/w*", but it wasn't. The former is clearer for more people. So no guidance there. I agree that we should follow the 2 precedents. Thank you both. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 21:43:45 2019 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 13 Feb 2019 02:43:45 +0000 Subject: [issue35973] `growable_int_array type_ignores` in parsetok.c is not always freed. In-Reply-To: <1549926356.5.0.0624072683347.issue35973@roundup.psfhosted.org> Message-ID: <1550025825.11.0.730765766813.issue35973@roundup.psfhosted.org> Guido van Rossum added the comment: Fixed by b9d2e97601847a1845bf96e2895a6214f02b92a6 (GH-11832). ---------- nosy: +pablogsal resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 21:59:14 2019 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 13 Feb 2019 02:59:14 +0000 Subject: [issue35975] Put back the ability to parse files where async/await aren't keywords In-Reply-To: <1549931018.54.0.209945896308.issue35975@roundup.psfhosted.org> Message-ID: <1550026754.26.0.324849477245.issue35975@roundup.psfhosted.org> Change by Guido van Rossum : ---------- assignee: -> gvanrossum components: +Interpreter Core stage: -> needs patch type: -> behavior versions: +Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 12 23:35:36 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 13 Feb 2019 04:35:36 +0000 Subject: [issue35927] Intra-package References Documentation Incomplete In-Reply-To: <1549514310.42.0.442993756904.issue35927@roundup.psfhosted.org> Message-ID: <1550032536.55.0.41841593392.issue35927@roundup.psfhosted.org> Terry J. Reedy added the comment: AData> You log and output show that you problem is as described: package 'sound' is in directory "C:/" and "C:/" is not is sys.path. Possible remedies: 1. Add "C:/" to sys.path at the top of each module that imports sound. This is a nuisance. 2. Move the sound package to 'C:\\Users\\user\\AppData\\Local\\Programs\\Python\\Python37\\lib\\site-packages'. This can also a nuisance. 3. Add a file named 'C.pth' and containing "C:/" to the site-packages. ('pth' abbreviates 'path'.) This makes C:/ an extension of site-packages. But all the non-python stuff in C: likely makes this a bad idea. 4 (3 improved). Add a directory such as "C:/pyprojects", make the contents of the .pth file "C:/pyprojects", and move sound to pyprojects. This is what I have done. When I install a new version of Python, I copy the .pth file to the new site-packeges directory. Works great. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 01:30:08 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Wed, 13 Feb 2019 06:30:08 +0000 Subject: [issue35121] Cookie domain check returns incorrect results In-Reply-To: <1540968768.96.0.788709270274.issue35121@psf.upfronthosting.co.za> Message-ID: <1550039408.29.0.455626009702.issue35121@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: This issue affects 2.7 as well along with 3.4 and 3.5. The initial report was notified to security at python.org . 2.7.16 release candidate dates were announced at https://mail.python.org/pipermail/python-dev/2019-February/156266.html. I have prepared an initial backport of this with tests for 2.7 at https://github.com/python/cpython/compare/2.7...tirkarthi:bpo35121-27 . Serhiy has approved the PR for master. I have added notes here and on the PR about the issue and implementation in other languages. It would be helpful if someone can double check my analysis since cookiejar has not received much change over the years. If this is a potential candidate for 2.7 release I can help with that once the changes are merged to master. Adding Benjamin Peterson to this issue to take a call on if it needs to be backported to 2.7. If it's planned for a backport then also to decide on priority if this needs to be part of 2.7.16 or later release. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 02:00:36 2019 From: report at bugs.python.org (Zachary Ware) Date: Wed, 13 Feb 2019 07:00:36 +0000 Subject: [issue21107] Add pgen.vcxproj to allow regenerating grammar files on Windows In-Reply-To: <1396238659.26.0.487973987032.issue21107@psf.upfronthosting.co.za> Message-ID: <1550041236.89.0.421904992959.issue21107@roundup.psfhosted.org> Zachary Ware added the comment: This patch is *way* out of date, and we're in the midst of removing pgen (issue35808) anyway, so I'm closing this issue. ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 02:15:24 2019 From: report at bugs.python.org (maokk) Date: Wed, 13 Feb 2019 07:15:24 +0000 Subject: [issue35981] shutil make_archive create wrong file when base name contains dots at end Message-ID: <1550042124.47.0.589800343777.issue35981@roundup.psfhosted.org> New submission from maokk : shutil.make_archive("foo...bar..", "zip", os.path.abspath("c:/test")) create zipfile called "foo...bar.zip" not "foo...bar...zip" ---------- components: Distutils messages: 335388 nosy: dstufft, eric.araujo, highwind priority: normal severity: normal status: open title: shutil make_archive create wrong file when base name contains dots at end type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 02:41:12 2019 From: report at bugs.python.org (shawnberry) Date: Wed, 13 Feb 2019 07:41:12 +0000 Subject: [issue35980] Py3 BIF random.choices() is O(N**2) but I've written O(N) code for the same task In-Reply-To: <1550022306.5.0.0584696050893.issue35980@roundup.psfhosted.org> Message-ID: shawnberry added the comment: Hi PSF, Upon further review, random.choices() is O(N). I was looping through the values in random.choices() to make it O(N**2) in my code. Next time I will thoroughly check a function on its own before raising any issue. Fyi, BIF is built-in function. Please close this issue. Best, Shawn On Tue, Feb 12, 2019 at 5:45 PM Steven D'Aprano wrote: > > Steven D'Aprano added the comment: > > What's "BIF" mean? You use that term multiple times but I have never heard > it before. > > I'm sorry, I don't understand your code (and don't have time to study it > in detail to decipher it). It would help if you factored out your new > implementation of choices() into a separate function. > > I see that your timing code it not reliable for timing individual function > calls. You include your setup code that builds the input to choices() as > well as the time it takes to print messages, so we can't really draw any > reliable conclusions about the speed of choices() from your timings. > > To give an analogy: you start the stopwatch at home. Climb into the shower > and wash, get dressed, have breakfast, drive to work, park the car, buy a > coffee at the shop next door, go to your office, greet your fellow > co-workers, and finally stop the stopwatch. And then you say that the total > time measured was the time it took you to drive to work alone. > > Finally, I can't actually work out what part of your code is intended as a > replacement for the choices() function. You should factor it out into a > separate function, then time the two function calls: > > choices(dataset, weights) > shawn_choices(dataset, weights) > > alone (without timing the setup of the datasets, or the I/O, or any other > irrelevant costs). You probably should use the timeit module for the actual > timing. > > As for the versions of Python, 3.6 and older are in "bug fix only" mode, > so this will not apply to anything older than 3.7. > > ---------- > nosy: +steven.daprano > versions: -Python 3.4, Python 3.5, Python 3.6 > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 02:43:32 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 13 Feb 2019 07:43:32 +0000 Subject: [issue35980] Py3 BIF random.choices() is O(N**2) but I've written O(N) code for the same task In-Reply-To: <1550020124.01.0.607459314938.issue35980@roundup.psfhosted.org> Message-ID: <1550043812.62.0.304316721874.issue35980@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 02:43:39 2019 From: report at bugs.python.org (Susan Su) Date: Wed, 13 Feb 2019 07:43:39 +0000 Subject: [issue35500] Align expected and actual calls on mock.assert_called_with error message In-Reply-To: <1544813146.35.0.788709270274.issue35500@psf.upfronthosting.co.za> Message-ID: <1550043819.14.0.00842487555645.issue35500@roundup.psfhosted.org> Susan Su added the comment: After taking a look at the assert_called_with function, I noticed that the formatting is inconsistent for the following case: from unittest import mock m = mock.Mock() a = [1, 2, 3, 4] m.assert_called_with(*a) Traceback (most recent call last): File "", line 1, in File "/vagrant/cpython/Lib/unittest/mock.py", line 817, in assert_called_with raise AssertionError('Expected call: %s\nNot called' % (expected,)) AssertionError: Expected call: mock(1, 2, 3) Not called If you believe it would be appropriate, I would like to change the format of the code above to the following: Traceback (most recent call last): File "", line 1, in File "/vagrant/cpython/Lib/unittest/mock.py", line 817, in assert_called_with raise AssertionError( AssertionError: expected call not found. Expected: mock(1, 2, 3, 4) Not called This way, we would create consistency in our output. ---------- nosy: +suhearsawho _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 02:45:19 2019 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 13 Feb 2019 07:45:19 +0000 Subject: [issue35980] Py3 BIF random.choices() is O(N**2) but I've written O(N) code for the same task In-Reply-To: <1550020124.01.0.607459314938.issue35980@roundup.psfhosted.org> Message-ID: <1550043919.24.0.89767938872.issue35980@roundup.psfhosted.org> Mark Dickinson added the comment: Closing as requested by OP. ---------- nosy: +mark.dickinson stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 02:49:16 2019 From: report at bugs.python.org (SilentGhost) Date: Wed, 13 Feb 2019 07:49:16 +0000 Subject: [issue35980] Py3 BIF random.choices() is O(N**2) but I've written O(N) code for the same task In-Reply-To: <1550020124.01.0.607459314938.issue35980@roundup.psfhosted.org> Message-ID: <1550044156.64.0.211968330719.issue35980@roundup.psfhosted.org> Change by SilentGhost : ---------- resolution: -> not a bug _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 02:55:55 2019 From: report at bugs.python.org (SilentGhost) Date: Wed, 13 Feb 2019 07:55:55 +0000 Subject: [issue35979] Incorrect __text_signature__ for the __get__ slot wrapper In-Reply-To: <1550018567.03.0.305357698132.issue35979@roundup.psfhosted.org> Message-ID: <1550044555.91.0.345487688985.issue35979@roundup.psfhosted.org> SilentGhost added the comment: Is it not? This seems to be doing exactly what's intended. If you have a reproducible bug trigger, please post it, but I'll close the issue in the meantime. ---------- nosy: +SilentGhost resolution: -> not a bug stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 03:53:27 2019 From: report at bugs.python.org (Roundup Robot) Date: Wed, 13 Feb 2019 08:53:27 +0000 Subject: [issue25461] Unclear language (the word ineffective) in the documentation for os.walk In-Reply-To: <1445533538.52.0.421272081658.issue25461@psf.upfronthosting.co.za> Message-ID: <1550048007.96.0.867708102989.issue25461@roundup.psfhosted.org> Change by Roundup Robot : ---------- pull_requests: +11867 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 04:03:00 2019 From: report at bugs.python.org (Tal Einat) Date: Wed, 13 Feb 2019 09:03:00 +0000 Subject: [issue35500] Align expected and actual calls on mock.assert_called_with error message In-Reply-To: <1544813146.35.0.788709270274.issue35500@psf.upfronthosting.co.za> Message-ID: <1550048580.96.0.35616336327.issue35500@roundup.psfhosted.org> Tal Einat added the comment: Susan, I agree that similarly improving the failure message for assert_called_with would be good. I find the final "Not called" line unclear, though. Perhaps something like the following: AssertionError: expected call not found. Expected: mock(1, 2, 3, 4) Actual: Not called ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 04:41:27 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Wed, 13 Feb 2019 09:41:27 +0000 Subject: [issue35982] Create unit-tests for os.renames() Message-ID: <1550050887.9.0.145116201828.issue35982@roundup.psfhosted.org> New submission from Joannah Nanjekye : In a discussion to fix https://bugs.python.org/issue35951, @giampaolo.rodola pointed out that there are no tests for os.renames() I have opened this issue to track this. ---------- messages: 335395 nosy: nanjekyejoannah priority: normal severity: normal status: open title: Create unit-tests for os.renames() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 04:47:20 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 13 Feb 2019 09:47:20 +0000 Subject: [issue35981] shutil make_archive create wrong file when base name contains dots at end In-Reply-To: <1550042124.47.0.589800343777.issue35981@roundup.psfhosted.org> Message-ID: <1550051240.8.0.16677697316.issue35981@roundup.psfhosted.org> St?phane Wirtel added the comment: I have just tried with 3.7.2 and I don't get your error. Python 3.7.2 (default, Jan 16 2019, 19:49:22) [GCC 8.2.1 20181215 (Red Hat 8.2.1-6)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import shutil >>> import os >>> shutil.make_archive('demo...bar..', 'zip', os.path.abspath('/tmp/demo')) '/tmp/demo/demo...bar...zip' >>> ls -l /tmp/demo -rw-r--r--. 1 stephane stephane 226 13 f?v 10:45 demo...bar...zip ---------- nosy: +matrixise resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 04:49:59 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Wed, 13 Feb 2019 09:49:59 +0000 Subject: [issue35981] shutil make_archive create wrong file when base name contains dots at end In-Reply-To: <1550042124.47.0.589800343777.issue35981@roundup.psfhosted.org> Message-ID: <1550051399.01.0.0872967890757.issue35981@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Is this Windows specific? I am unable to reproduce this on Mac and Ubuntu with master and Python 3.7 . ? cpython git:(master) ./python.exe -c 'import os, shutil; shutil.make_archive("foo...bar..", "zip", os.path.abspath("./Tools"))' ? cpython git:(master) ? ls foo...bar...zip foo...bar...zip ? cpython git:(master) ? rm foo...bar...zip ? cpython git:(master) python3.7 -c 'import os, shutil; shutil.make_archive("foo...bar..", "zip", os.path.abspath("./Tools"))' ? cpython git:(master) ? ls foo...bar...zip foo...bar...zip ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 04:54:57 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Wed, 13 Feb 2019 09:54:57 +0000 Subject: [issue35951] os.renames() creates directories if original name doesn't exist In-Reply-To: <1549732242.93.0.821054504106.issue35951@roundup.psfhosted.org> Message-ID: <1550051697.84.0.349338144086.issue35951@roundup.psfhosted.org> Joannah Nanjekye added the comment: @giampaolo.rodola thanks for insight on tests. I dint catch that at all :) I am working on tests for os.renames() I opened an issue to track that here : https://bugs.python.org/issue35982. IMHO, I think we need to improve the current behavior. This discussion is not yet conclusive. You pointed out that this fix makes the problem a lot less likely to occur but we may end up with a race condition. Can we close this PR so that maybe someone comes with a fix that addresses both problems? can we work with this fix? Am happy to comply with any decision. cc @vstinner Once we agree on this, I will make necessary changes also in the review of this PR. ---------- nosy: +nanjekyejoannah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 04:58:49 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 13 Feb 2019 09:58:49 +0000 Subject: [issue35982] Create unit-tests for os.renames() In-Reply-To: <1550050887.9.0.145116201828.issue35982@roundup.psfhosted.org> Message-ID: <1550051929.23.0.310688874952.issue35982@roundup.psfhosted.org> St?phane Wirtel added the comment: good catch ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 05:02:53 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Wed, 13 Feb 2019 10:02:53 +0000 Subject: [issue35982] Create unit-tests for os.renames() In-Reply-To: <1550050887.9.0.145116201828.issue35982@roundup.psfhosted.org> Message-ID: <1550052173.42.0.155685219922.issue35982@roundup.psfhosted.org> Joannah Nanjekye added the comment: I am working on this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 05:12:38 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 13 Feb 2019 10:12:38 +0000 Subject: [issue35982] Create unit-tests for os.renames() In-Reply-To: <1550050887.9.0.145116201828.issue35982@roundup.psfhosted.org> Message-ID: <1550052758.74.0.517832380557.issue35982@roundup.psfhosted.org> St?phane Wirtel added the comment: ok, I was working on this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 05:17:11 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 13 Feb 2019 10:17:11 +0000 Subject: [issue35982] Create unit-tests for os.renames() In-Reply-To: <1550050887.9.0.145116201828.issue35982@roundup.psfhosted.org> Message-ID: <1550053031.81.0.733816738304.issue35982@roundup.psfhosted.org> St?phane Wirtel added the comment: You can check this branch, but I have not created the PR because you were working on this issue. https://github.com/matrixise/cpython/commit/3f23deceef423b038273d28080d4aaee664b6bc9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 05:49:35 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 13 Feb 2019 10:49:35 +0000 Subject: [issue35982] Create unit-tests for os.renames() In-Reply-To: <1550050887.9.0.145116201828.issue35982@roundup.psfhosted.org> Message-ID: <1550054975.3.0.925772387979.issue35982@roundup.psfhosted.org> Change by St?phane Wirtel : ---------- keywords: +patch pull_requests: +11868 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 05:52:46 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 13 Feb 2019 10:52:46 +0000 Subject: [issue35982] Create unit-tests for os.renames() In-Reply-To: <1550050887.9.0.145116201828.issue35982@roundup.psfhosted.org> Message-ID: <1550055166.67.0.869899523715.issue35982@roundup.psfhosted.org> St?phane Wirtel added the comment: ok, I have created a PR, you can comment it and we can work together on this PR. Have a nice day, St?phane ---------- stage: patch review -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 05:54:45 2019 From: report at bugs.python.org (Olivier Grisel) Date: Wed, 13 Feb 2019 10:54:45 +0000 Subject: [issue35900] Add pickler hook for the user to customize the serialization of user defined functions and types. In-Reply-To: <1549377622.96.0.737929222958.issue35900@roundup.psfhosted.org> Message-ID: <1550055285.75.0.812395065332.issue35900@roundup.psfhosted.org> Olivier Grisel added the comment: Adding such a hook would make it possible to reimplement cloudpickle.CloudPickler by deriving from the fast _pickle.Pickler class (instead of the slow pickle._Pickler as done currently). This would mean rewriting most of the CloudPickler method to only rely on a save_reduce-style design instead of directly calling pickle._Pickler.write and pickle._Pickler.save. This is tedious but doable. There is however a blocker with the current way closures are set: when we pickle a dynamically defined function (e.g. lambda, nested function or function in __main__), we currently use a direct call to memoize (https://github.com/cloudpipe/cloudpickle/blob/v0.7.0/cloudpickle/cloudpickle.py#L594) so as to be able to refer to the function itself in its own closure without causing an infinite loop in CloudPickler.dump. This also makes possible to pickle mutually recursive functions. The easiest way to avoid having to call memoize explicitly would be to be able to pass the full __closure__ attribute in the state dict of the reduce call. Indeed the save_reduce function calls memoize automatically after saving the reconstructor and its args but prior to saving the state: https://github.com/python/cpython/blob/v3.7.2/Modules/_pickle.c#L3903-L3931 It would therefore be possible to pass a (state, slotstate) tuple with the closure in slotstate that so it could be reconstructed at unpickling time with a setattr: https://github.com/python/cpython/blob/v3.7.2/Modules/_pickle.c#L6258-L6272 However, it is currently not possible to setattr __closure__ at the moment. We can only set individual closure cell contents (which is not compatible with the setattr state trick described above). To summarize, we need to implement the setter function for the __closure__ attribute of functions and methods to make it natural to reimplement the CloudPickler by inheriting from _pickle.Pickler using the hook described in this issue. ---------- nosy: +Olivier.Grisel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 06:02:31 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Wed, 13 Feb 2019 11:02:31 +0000 Subject: [issue35983] tp_dealloc trashcan shouldn't be called for subclasses Message-ID: <1550055751.42.0.717332216151.issue35983@roundup.psfhosted.org> New submission from Jeroen Demeyer : When designing an extension type subclassing an existing type, it makes sense to call the tp_dealloc of the base class from the tp_dealloc of the subclass. Now suppose that I'm subclassing "list" which uses the trashcan mechanism. Then it can happen that the tp_dealloc of list puts this object in the trashcan, even though the tp_dealloc of the subclass has already been called. Then the tp_dealloc of the subclass may be called multiple times, which is unsafe (tp_dealloc is expected to be called exactly once). To solve this, the trashcan mechanism should be disabled when tp_dealloc is called from a subclass. Interestingly, subtype_dealloc also solves this in a much more involved way (see the "Q. Why the bizarre (net-zero) manipulation of _PyRuntime.trash_delete_nesting around the trashcan macros?") in Objects/typeobject.c ---------- components: Interpreter Core messages: 335405 nosy: jdemeyer, pitrou, scoder priority: normal severity: normal status: open title: tp_dealloc trashcan shouldn't be called for subclasses versions: Python 2.7, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 06:08:00 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 13 Feb 2019 11:08:00 +0000 Subject: [issue35983] tp_dealloc trashcan shouldn't be called for subclasses In-Reply-To: <1550055751.42.0.717332216151.issue35983@roundup.psfhosted.org> Message-ID: <1550056080.35.0.0287171624408.issue35983@roundup.psfhosted.org> St?phane Wirtel added the comment: Jeroen, could you share your example? I am learning the C-API of Python and this example could be interesting. ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 06:09:44 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 13 Feb 2019 11:09:44 +0000 Subject: [issue35982] Create unit-tests for os.renames() In-Reply-To: <1550050887.9.0.145116201828.issue35982@roundup.psfhosted.org> Message-ID: <1550056184.11.0.3862360541.issue35982@roundup.psfhosted.org> St?phane Wirtel added the comment: Hi Giampaolo, I added you to this issue, about the tests, I have created a very simple test but I would like to know your advice. Thank you, ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 06:10:03 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Wed, 13 Feb 2019 11:10:03 +0000 Subject: [issue35984] test__xxsubinterpreters leaked [3, 4, 3] memory blocks, sum=1 Message-ID: <1550056203.45.0.644918745906.issue35984@roundup.psfhosted.org> New submission from Pablo Galindo Salgado : The reafleak buildbots have detected memory block leaks in test__xxsubinterpreters: Ran 112 tests in 4.721s OK (skipped=5) . test__xxsubinterpreters leaked [3, 4, 3] memory blocks, sum=10 1 test failed again: test__xxsubinterpreters == Tests result: FAILURE then FAILURE == https://buildbot.python.org/all/#/builders/1/builds/502 https://buildbot.python.org/all/#/builders/80/builds/511 Bisecting shows 16f842da3c862d76a1177bd8ef9579703c24fa5a is the first bad commit. This was introduced in PR11822. ---------- components: Tests messages: 335408 nosy: eric.snow, pablogsal, vstinner priority: normal severity: normal status: open title: test__xxsubinterpreters leaked [3, 4, 3] memory blocks, sum=1 versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 06:15:21 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Feb 2019 11:15:21 +0000 Subject: [issue35984] test__xxsubinterpreters leaked [3, 4, 3] memory blocks, sum=1 In-Reply-To: <1550056203.45.0.644918745906.issue35984@roundup.psfhosted.org> Message-ID: <1550056521.62.0.207422300236.issue35984@roundup.psfhosted.org> STINNER Victor added the comment: > Bisecting shows 16f842da3c862d76a1177bd8ef9579703c24fa5a is the first bad commit. This was introduced in PR11822. That's issue bpo-35972. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 06:16:05 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Feb 2019 11:16:05 +0000 Subject: [issue35972] _xxsubinterpreters: channel_send() may truncate ints on 32-bit platforms In-Reply-To: <1549921968.67.0.462504390355.issue35972@roundup.psfhosted.org> Message-ID: <1550056565.78.0.743352804854.issue35972@roundup.psfhosted.org> STINNER Victor added the comment: > New changeset 16f842da3c862d76a1177bd8ef9579703c24fa5a by Eric Snow (Alexey Izbyshev) in branch 'master': > bpo-35972: _xxsubinterpreters: Fix potential integer truncation on 32-bit in channel_send() (gh-11822) It seems like this change introduced a reference leak: bpo-35984. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 06:16:09 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Feb 2019 11:16:09 +0000 Subject: [issue35984] test__xxsubinterpreters leaked [3, 4, 3] memory blocks, sum=1 In-Reply-To: <1550056203.45.0.644918745906.issue35984@roundup.psfhosted.org> Message-ID: <1550056569.22.0.0160217220968.issue35984@roundup.psfhosted.org> Change by STINNER Victor : ---------- nosy: +izbyshev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 06:17:17 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Feb 2019 11:17:17 +0000 Subject: [issue35984] test__xxsubinterpreters leaked [3, 4, 3] memory blocks, sum=1 In-Reply-To: <1550056203.45.0.644918745906.issue35984@roundup.psfhosted.org> Message-ID: <1550056637.13.0.887398888223.issue35984@roundup.psfhosted.org> STINNER Victor added the comment: $ ./python -m test.bisect_cmd -R 3:3 test__xxsubinterpreters found: test.test__xxsubinterpreters.ShareableTypeTests.test_non_shareable_int ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 06:17:53 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Feb 2019 11:17:53 +0000 Subject: [issue35984] test__xxsubinterpreters leaked [3, 4, 3] memory blocks, sum=1 In-Reply-To: <1550056203.45.0.644918745906.issue35984@roundup.psfhosted.org> Message-ID: <1550056673.36.0.879164721471.issue35984@roundup.psfhosted.org> STINNER Victor added the comment: I'm mentoring Alexey Izbyshev. @Alexey: Do you want to work on this issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 06:20:46 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Wed, 13 Feb 2019 11:20:46 +0000 Subject: [issue35982] Create unit-tests for os.renames() In-Reply-To: <1550050887.9.0.145116201828.issue35982@roundup.psfhosted.org> Message-ID: <1550056846.65.0.337126326029.issue35982@roundup.psfhosted.org> Joannah Nanjekye added the comment: If you have created a PR, that is fine. Am not able to look now though may be later. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 06:20:59 2019 From: report at bugs.python.org (Alexey Izbyshev) Date: Wed, 13 Feb 2019 11:20:59 +0000 Subject: [issue35984] test__xxsubinterpreters leaked [3, 4, 3] memory blocks, sum=1 In-Reply-To: <1550056203.45.0.644918745906.issue35984@roundup.psfhosted.org> Message-ID: <1550056859.31.0.394780719998.issue35984@roundup.psfhosted.org> Alexey Izbyshev added the comment: I'll look into it later today. An obvious guess is that my test simply exposed an existing leak because the exception code path wasn't tested before AFAIK, but I need to check it. ---------- assignee: -> izbyshev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 06:25:13 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Feb 2019 11:25:13 +0000 Subject: [issue18283] shutil.which() should support bytes In-Reply-To: <1371914951.06.0.665120918364.issue18283@psf.upfronthosting.co.za> Message-ID: <1550057113.22.0.352818320512.issue18283@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 5680f6546dcda550ad70eefa0a5ebf1375303307 by Victor Stinner (Cheryl Sabella) in branch 'master': bpo-18283: Add support for bytes to shutil.which (GH-11818) https://github.com/python/cpython/commit/5680f6546dcda550ad70eefa0a5ebf1375303307 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 06:25:48 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Feb 2019 11:25:48 +0000 Subject: [issue18283] shutil.which() should support bytes In-Reply-To: <1371914951.06.0.665120918364.issue18283@psf.upfronthosting.co.za> Message-ID: <1550057148.99.0.624338696402.issue18283@roundup.psfhosted.org> Change by STINNER Victor : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 06:32:01 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Feb 2019 11:32:01 +0000 Subject: [issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> Message-ID: <1550057521.34.0.158672743286.issue35961@roundup.psfhosted.org> STINNER Victor added the comment: New changeset dcb68f47f74b0cc8a1896d4a4c5a6b83c0bbeeae by Victor Stinner in branch 'master': bpo-35961: Fix a crash in slice_richcompare() (GH-11830) https://github.com/python/cpython/commit/dcb68f47f74b0cc8a1896d4a4c5a6b83c0bbeeae ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 06:32:25 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 13 Feb 2019 11:32:25 +0000 Subject: [issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> Message-ID: <1550057545.66.0.437620999489.issue35961@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11869 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 06:34:32 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Feb 2019 11:34:32 +0000 Subject: [issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> Message-ID: <1550057672.59.0.0613798472414.issue35961@roundup.psfhosted.org> STINNER Victor added the comment: Python 2.7 is not affected: it doesn't have the slice_richcompare() function, but the old slice_compare() implementation. Python 3.6 is affected but doesn't accept bugfixes anymore: https://devguide.python.org/#status-of-python-branches This bug is 13 years old, I don't think that it's really useful to fix it. It mostly impact test_slice and only test_slice. ---------- versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 06:37:21 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Feb 2019 11:37:21 +0000 Subject: [issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> Message-ID: <1550057841.91.0.0185547134381.issue35961@roundup.psfhosted.org> STINNER Victor added the comment: > This bug is 13 years old, I don't think that it's really useful to fix it. It mostly impact test_slice and only test_slice. To be clear, I compiled Python 3.6 in release mode and applied test_slice patch of msg335333: no crash after 1500 runs. The bug is an assertion error, but assertions are only compiled in debug mode. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 06:47:18 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Feb 2019 11:47:18 +0000 Subject: [issue35810] Object Initialization does not incref Heap-allocated Types In-Reply-To: <1548275752.94.0.463880453345.issue35810@roundup.psfhosted.org> Message-ID: <1550058438.67.0.856080232096.issue35810@roundup.psfhosted.org> STINNER Victor added the comment: > * Should I write something up in python-dev/Discourse? Please open a thread on python-dev. The purpose is not really to ask if it's worth it, but more to communicate properly on backward incompatible changes. > * Do I need to update the PY_VERSION_HEX? No. The release manager is responsible for that. > * Do I need to write an entry in the Porting guide? Yes. You should add a new "Changes in the C API" section to: https://docs.python.org/dev/whatsnew/3.8.html#porting-to-python-3-8 This is why you can show an example of dealloc using #ifdef with PY_VERSION_HEX. Example in 3.7 doc: https://docs.python.org/dev/whatsnew/3.7.html#changes-in-the-c-api ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 06:49:38 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 13 Feb 2019 11:49:38 +0000 Subject: [issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> Message-ID: <1550058578.54.0.552267251793.issue35961@roundup.psfhosted.org> miss-islington added the comment: New changeset a78251e2d6de37f46c230be924032a87df730761 by Miss Islington (bot) in branch '3.7': bpo-35961: Fix a crash in slice_richcompare() (GH-11830) https://github.com/python/cpython/commit/a78251e2d6de37f46c230be924032a87df730761 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 06:49:43 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Feb 2019 11:49:43 +0000 Subject: [issue35984] test__xxsubinterpreters leaked [3, 4, 3] memory blocks, sum=1 In-Reply-To: <1550056203.45.0.644918745906.issue35984@roundup.psfhosted.org> Message-ID: <1550058583.01.0.645648194563.issue35984@roundup.psfhosted.org> STINNER Victor added the comment: > I'll look into it later today. An obvious guess is that my test simply exposed an existing leak because the exception code path wasn't tested before AFAIK, but I need to check it. Right. I don't think that your change introduced a regression. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 06:51:24 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Wed, 13 Feb 2019 11:51:24 +0000 Subject: [issue35981] shutil make_archive create wrong file when base name contains dots at end In-Reply-To: <1550042124.47.0.589800343777.issue35981@roundup.psfhosted.org> Message-ID: <1550058684.12.0.756088945498.issue35981@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Could be the case that it's windows specific. For "foo...bar..." abspath returns "foo...bar..." in Python on Mac. I don't have access to Windows but checking this on dotnet fiddle with C# which I hope uses Windows full path strips out the leading dots which I think could be a case with os.path.abspath used in make_archive. Sample fiddle : https://dotnetfiddle.net/PhRr98. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 06:52:47 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Feb 2019 11:52:47 +0000 Subject: [issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small In-Reply-To: <1549848310.82.0.602608735214.issue35961@roundup.psfhosted.org> Message-ID: <1550058767.58.0.836530238221.issue35961@roundup.psfhosted.org> STINNER Victor added the comment: Thanks everyone for helping on the analysis and for reviews obviously. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 07:08:03 2019 From: report at bugs.python.org (Lukas J) Date: Wed, 13 Feb 2019 12:08:03 +0000 Subject: [issue35985] Folding tries to slice from 0 to float("+inf") when maxlength is 0 Message-ID: <1550059683.58.0.369389520684.issue35985@roundup.psfhosted.org> New submission from Lukas J : When converting an email.message.Message with the policy set to email.policy.EmailPolicy with all default settings, I eventually end up with this exception: File "/usr/lib/python3.7/email/_header_value_parser.py", line 2727, in _fold_as_ew first_part = to_encode[:text_space] TypeError: slice indices must be integers or None or have an __index__ method Which is caused because text_space is a float of value +inf. This is set on line 2594 of the same file: maxlen = policy.max_line_length or float("+inf") For some reason policy.max_line_length is set to zero, even though the default should be 78 after a glance into the source. So there's maybe even two issues: 1.) The fallback for maxlen shouldn't be float("+inf"), as that is not an integer and thus can't be sliced by. I think a big integer would suffice instead, for example 100000000 2.) policy.max_line_length seems to lose it's value in the default settings somewhere along the way if it isn't explicitly set. Current workaround: Set max_line_length of the policy to a value (78 is default) ---------- components: email messages: 335424 nosy: Lukas J, barry, r.david.murray priority: normal severity: normal status: open title: Folding tries to slice from 0 to float("+inf") when maxlength is 0 versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 07:15:53 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Wed, 13 Feb 2019 12:15:53 +0000 Subject: [issue35985] Folding tries to slice from 0 to float("+inf") when maxlength is 0 In-Reply-To: <1550059683.58.0.369389520684.issue35985@roundup.psfhosted.org> Message-ID: <1550060153.64.0.921965312418.issue35985@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: This seems to be same as issue33524 ? ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 07:22:24 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 13 Feb 2019 12:22:24 +0000 Subject: [issue35899] '_is_sunder' function in 'enum' module fails on empty string In-Reply-To: <1549376859.01.0.998806898699.issue35899@roundup.psfhosted.org> Message-ID: <1550060544.34.0.855219282281.issue35899@roundup.psfhosted.org> Change by St?phane Wirtel : ---------- keywords: +patch pull_requests: +11870 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 07:22:40 2019 From: report at bugs.python.org (Lukas J) Date: Wed, 13 Feb 2019 12:22:40 +0000 Subject: [issue35985] Folding tries to slice from 0 to float("+inf") when maxlength is 0 In-Reply-To: <1550059683.58.0.369389520684.issue35985@roundup.psfhosted.org> Message-ID: <1550060560.89.0.844622315854.issue35985@roundup.psfhosted.org> Lukas J added the comment: Indeed it is. Sorry I didn't find it before. So it seems that changing float("+inf") to sys.maxsize would solve the problem? I've tried it in an interactive shell: >>> a = "asd"; import sys >>> a[:sys.maxsize] 'asd' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 07:23:59 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 13 Feb 2019 12:23:59 +0000 Subject: [issue35899] '_is_sunder' function in 'enum' module fails on empty string In-Reply-To: <1549376859.01.0.998806898699.issue35899@roundup.psfhosted.org> Message-ID: <1550060639.82.0.670600184636.issue35899@roundup.psfhosted.org> St?phane Wirtel added the comment: Hi, I have created the PR for Maxwell. After tomorrow, if we have no news from him, I propose to you to update/comment the PR. Of course, I will add a co-authored-by field in the commit. ---------- keywords: -patch nosy: +matrixise stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 07:26:53 2019 From: report at bugs.python.org (=?utf-8?b?5p2O56yR5p2l?=) Date: Wed, 13 Feb 2019 12:26:53 +0000 Subject: [issue35986] print() documentation typo? Message-ID: <1550060813.07.0.324151562751.issue35986@roundup.psfhosted.org> New submission from ??? : print(), default value sep, should be ' '(one space), rather than an empty str, ''. ---------- assignee: docs at python components: Documentation messages: 335428 nosy: docs at python, ??? priority: normal severity: normal status: open title: print() documentation typo? type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 07:28:00 2019 From: report at bugs.python.org (=?utf-8?b?5p2O56yR5p2l?=) Date: Wed, 13 Feb 2019 12:28:00 +0000 Subject: [issue35986] print() documentation typo? In-Reply-To: <1550060813.07.0.324151562751.issue35986@roundup.psfhosted.org> Message-ID: <1550060880.5.0.465335373225.issue35986@roundup.psfhosted.org> ??? added the comment: sep argument default value should be ' '(a space), rather than ''(an empty string). ---------- resolution: -> remind _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 07:28:04 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 13 Feb 2019 12:28:04 +0000 Subject: [issue35985] Folding tries to slice from 0 to float("+inf") when maxlength is 0 In-Reply-To: <1550059683.58.0.369389520684.issue35985@roundup.psfhosted.org> Message-ID: <1550060884.36.0.857779684866.issue35985@roundup.psfhosted.org> St?phane Wirtel added the comment: Could you share your example? Thank you ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 07:37:00 2019 From: report at bugs.python.org (Lukas J) Date: Wed, 13 Feb 2019 12:37:00 +0000 Subject: [issue35985] Folding tries to slice from 0 to float("+inf") when maxlength is 0 In-Reply-To: <1550059683.58.0.369389520684.issue35985@roundup.psfhosted.org> Message-ID: <1550061420.72.0.100058568282.issue35985@roundup.psfhosted.org> Lukas J added the comment: Minimal example: import email.policy import email.mime.text responsehtml = "somehtmlbody" msg = email.mime.text.MIMEText(responsehtml, "html", policy=email.policy.EmailPolicy()) msg["to"] = "test at example.com" msg["cc"] = "??? " msg["From"] = "foo at bar.com" msg["Subject"] = "test" msg.as_string() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 07:42:58 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Wed, 13 Feb 2019 12:42:58 +0000 Subject: [issue35985] Folding tries to slice from 0 to float("+inf") when maxlength is 0 In-Reply-To: <1550059683.58.0.369389520684.issue35985@roundup.psfhosted.org> Message-ID: <1550061778.48.0.290650814299.issue35985@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Thanks for the confirmation. I would propose closing this as a duplicate. The PR on the other issue might fix your issue and is just waiting on a NEWS entry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 07:45:45 2019 From: report at bugs.python.org (Lukas J) Date: Wed, 13 Feb 2019 12:45:45 +0000 Subject: [issue35985] Folding tries to slice from 0 to float("+inf") when maxlength is 0 In-Reply-To: <1550059683.58.0.369389520684.issue35985@roundup.psfhosted.org> Message-ID: <1550061945.55.0.438060991666.issue35985@roundup.psfhosted.org> Lukas J added the comment: Ok thank you! ---------- resolution: -> duplicate stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 07:45:54 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Wed, 13 Feb 2019 12:45:54 +0000 Subject: [issue35986] print() documentation typo? In-Reply-To: <1550060813.07.0.324151562751.issue35986@roundup.psfhosted.org> Message-ID: <1550061954.66.0.987493047533.issue35986@roundup.psfhosted.org> Steven D'Aprano added the comment: Which documentation are you referring to? The docstring says: print(value, ..., sep=' ', end='\n', file=sys.stdout, flush=False) which is clearly a space. The docs here: https://docs.python.org/3/library/functions.html#print say something very similar: print(*objects, sep=' ', end='\n', file=sys.stdout, flush=False) but it is really hard to see the space on the website unless you look very carefully, because the font used is a proportional font instead of a monospaced font. So the space shown is a tiny little sliver of whitespace. But if you copy and paste the function signature into your text editor, or somewhere you can set the font to use a fixed-width programmers font, you will see that there definitely is a space there. So not a typo, but possibly a poor choice of font. It might be nice to rethink the choice of font for parameter lists. ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 07:57:50 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 13 Feb 2019 12:57:50 +0000 Subject: [issue35985] Folding tries to slice from 0 to float("+inf") when maxlength is 0 In-Reply-To: <1550059683.58.0.369389520684.issue35985@roundup.psfhosted.org> Message-ID: <1550062670.07.0.838639363288.issue35985@roundup.psfhosted.org> St?phane Wirtel added the comment: Just add the link to the other issue: https://bugs.python.org/issue33524 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 07:58:43 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 13 Feb 2019 12:58:43 +0000 Subject: [issue33524] non-ascii characters in headers causes TypeError on email.policy.Policy.fold In-Reply-To: <1526402130.36.0.682650639539.issue33524@psf.upfronthosting.co.za> Message-ID: <1550062723.28.0.83552992922.issue33524@roundup.psfhosted.org> St?phane Wirtel added the comment: See this issue as a duplicata of this one: https://bugs.python.org/issue35985 ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 08:06:27 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Wed, 13 Feb 2019 13:06:27 +0000 Subject: [issue35985] Folding tries to slice from 0 to float("+inf") when maxlength is 0 In-Reply-To: <1550059683.58.0.369389520684.issue35985@roundup.psfhosted.org> Message-ID: <1550063187.03.0.0400380301072.issue35985@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- superseder: -> non-ascii characters in headers causes TypeError on email.policy.Policy.fold _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 08:24:31 2019 From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=) Date: Wed, 13 Feb 2019 13:24:31 +0000 Subject: [issue35224] PEP 572: Assignment Expressions In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za> Message-ID: <1550064271.07.0.53610265359.issue35224@roundup.psfhosted.org> Miro Hron?ok added the comment: PEP 572 is nowhere to be found in https://docs.python.org/3.8/whatsnew/3.8.html Should I open a separate issue for that? ---------- nosy: +hroncok _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 08:32:41 2019 From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=) Date: Wed, 13 Feb 2019 13:32:41 +0000 Subject: [issue35224] PEP 572: Assignment Expressions In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za> Message-ID: <1550064761.94.0.592922913273.issue35224@roundup.psfhosted.org> Miro Hron?ok added the comment: (I've somehow missed the previous comments about the same, sorry about that.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 08:43:38 2019 From: report at bugs.python.org (Samuel GIFFARD) Date: Wed, 13 Feb 2019 13:43:38 +0000 Subject: [issue35987] Mypy and Asyncio import cannot be skipped Message-ID: <1550065418.2.0.752410201909.issue35987@roundup.psfhosted.org> New submission from Samuel GIFFARD : Some modules cannot be found with mypy. And cannot be silenced/skipped by mypy. Have the following 3 files: ############################## # example1.py from asyncio import BaseEventLoop # Module 'asyncio' has no attribute 'BaseEventLoop' from asyncio import Semaphore # OK import aiostream # gets skipped correctly import asyncio # OK asyncio.windows_events.WindowsProactorEventLoopPolicy() # Module has no attribute 'windows_events' asyncio.WindowsProactorEventLoopPolicy() # Module has no attribute 'WindowsProactorEventLoopPolicy' ############################## # mypy.ini [mypy] python_version = 3.7 [mypy-asyncio,aiostream] follow_imports = skip ignore_missing_imports = True ############################## # Pipfile [[source]] url = "https://pypi.org/simple" verify_ssl = true name = "pypi" [dev-packages] [packages] mypy = "==0.670" aiostream = "==0.3.1" [requires] python_version = "3.7" ############################## $> pipenv install #... $> pipenv run python -m mypy --config-file mypy.ini example1.py example1.py:1: error: Module 'asyncio' has no attribute 'BaseEventLoop' example1.py:5: error: Module has no attribute "windows_events" example1.py:6: error: Module has no attribute "WindowsProactorEventLoopPolicy" Why Semaphore (and others) works and BaseEventLoop (among others) doesn't work... no idea. But it completely breaks mypy that it somehow cannot be skipped nor silenced. ---------- components: asyncio messages: 335439 nosy: Samuel GIFFARD, asvetlov, yselivanov priority: normal severity: normal status: open title: Mypy and Asyncio import cannot be skipped type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 09:00:11 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Wed, 13 Feb 2019 14:00:11 +0000 Subject: [issue35983] tp_dealloc trashcan shouldn't be called for subclasses In-Reply-To: <1550055751.42.0.717332216151.issue35983@roundup.psfhosted.org> Message-ID: <1550066411.11.0.795398254588.issue35983@roundup.psfhosted.org> Jeroen Demeyer added the comment: The problem is easily reproduced with Cython: cdef class List(list): cdef int deallocated def __dealloc__(self): if self.deallocated: print("Deallocated twice!") self.deallocated = 1 L = None for i in range(10**4): L = List((L,)) del L ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 09:00:49 2019 From: report at bugs.python.org (Samuel GIFFARD) Date: Wed, 13 Feb 2019 14:00:49 +0000 Subject: [issue35987] Mypy and Asyncio import cannot be skipped In-Reply-To: <1550065418.2.0.752410201909.issue35987@roundup.psfhosted.org> Message-ID: <1550066449.89.0.296521632345.issue35987@roundup.psfhosted.org> Samuel GIFFARD added the comment: I've created a similar ticket on mypy side: https://github.com/python/mypy/issues/6383 as I'm not sure where this belongs to. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 09:04:52 2019 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 13 Feb 2019 14:04:52 +0000 Subject: [issue12374] Execution model should explain compile vs definition vs execution time In-Reply-To: <1308582911.55.0.701954968644.issue12374@psf.upfronthosting.co.za> Message-ID: <1550066692.84.0.704283346564.issue12374@roundup.psfhosted.org> Nick Coghlan added the comment: Cheryl has started the conversion process for the old user reference manuscript [1], so I think it makes sense to mark this as "postponed" for now, until we see how far we can get with this more usage-centric level of explanation as a separate project from the language reference. [1] https://github.com/ncoghlan/python-userref/tree/master/converted ---------- resolution: -> postponed stage: needs patch -> resolved status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 09:05:47 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 13 Feb 2019 14:05:47 +0000 Subject: [issue35986] print() documentation typo? In-Reply-To: <1550060813.07.0.324151562751.issue35986@roundup.psfhosted.org> Message-ID: <1550066747.27.0.752297129598.issue35986@roundup.psfhosted.org> St?phane Wirtel added the comment: @steven I have a solution with a css selector if we update the python-docs theme for Sphinx. You can check my screenshot ---------- nosy: +matrixise Added file: https://bugs.python.org/file48136/print_screenshot.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 09:08:16 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Wed, 13 Feb 2019 14:08:16 +0000 Subject: [issue35987] Mypy and Asyncio import cannot be skipped In-Reply-To: <1550065418.2.0.752410201909.issue35987@roundup.psfhosted.org> Message-ID: <1550066896.49.0.172601134126.issue35987@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Thanks for the report. mypy is not part of stdlib and it seems that typeshed doesn't have BaseEventLoop defined in asyncio.__init__.pyi [0] . Adding it to the import removes the error . I guess this needs to be filed in typeshed. There is an issue open for missing asyncio top level functions at https://github.com/python/typeshed/issues/2313 . I would propose closing this as third party. I am adding mypy devs as a confirmation and to follow up the issue with typeshed for updating stub files. [0] https://github.com/python/typeshed/blob/b3aac58db01c6bdc63452066bd9cd5f761e79044/stdlib/3/asyncio/__init__.pyi#L101 ---------- nosy: +gvanrossum, levkivskyi, xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 09:26:11 2019 From: report at bugs.python.org (Ivan Levkivskyi) Date: Wed, 13 Feb 2019 14:26:11 +0000 Subject: [issue35987] Mypy and Asyncio import cannot be skipped In-Reply-To: <1550065418.2.0.752410201909.issue35987@roundup.psfhosted.org> Message-ID: <1550067971.49.0.65605912056.issue35987@roundup.psfhosted.org> Ivan Levkivskyi added the comment: This is not a Python issue, this should be reported on typeshed tracker (but likely a duplicate of the issue mentioned by Karthikeyan). ---------- resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 09:26:23 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Wed, 13 Feb 2019 14:26:23 +0000 Subject: [issue35981] shutil make_archive create wrong file when base name contains dots at end In-Reply-To: <1550042124.47.0.589800343777.issue35981@roundup.psfhosted.org> Message-ID: <1550067983.86.0.118274524225.issue35981@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: On windows os.path.abspath("foo...bar..") returns "foo...bar" which is used in shutil.make_archive [0] returning foo...bar.zip. @matrixise , I am reopening this and adding Windows so that this can be confirmed as known behavior and closed. https://github.com/python/cpython/blob/dcb68f47f74b0cc8a1896d4a4c5a6b83c0bbeeae/Lib/shutil.py#L964 ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware resolution: rejected -> stage: resolved -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 09:46:09 2019 From: report at bugs.python.org (Hinko Kocevar) Date: Wed, 13 Feb 2019 14:46:09 +0000 Subject: [issue35988] Python interpreter segfault Message-ID: <1550069169.56.0.128755825216.issue35988@roundup.psfhosted.org> New submission from Hinko Kocevar : I'm running a tornado server with websockets client. Every now and then the python3.5 crashes, seg faults. I added code tracking (https://stackoverflow.com/questions/2663841/python-tracing-a-segmentation-fault) and this is what I see: line, /usr/lib64/python3.5/asyncio/events.py:675 call, /usr/lib64/python3.5/asyncio/events.py:621 line, /usr/lib64/python3.5/asyncio/events.py:627 line, /usr/lib64/python3.5/asyncio/events.py:628 line, /usr/lib64/python3.5/asyncio/events.py:629 return, /usr/lib64/python3.5/asyncio/events.py:629 line, /usr/lib64/python3.5/asyncio/events.py:676 line, /usr/lib64/python3.5/asyncio/events.py:677 return, /usr/lib64/python3.5/asyncio/events.py:677 line, /usr/lib64/python3.5/asyncio/futures.py:172 line, /usr/lib64/python3.5/asyncio/futures.py:173 call, /usr/lib64/python3.5/asyncio/base_events.py:1461 line, /usr/lib64/python3.5/asyncio/base_events.py:1462 return, /usr/lib64/python3.5/asyncio/base_events.py:1462 return, /usr/lib64/python3.5/asyncio/futures.py:173 line, /usr/lib64/python3.5/site-packages/tornado/iostream.py:584 call, /usr/lib64/python3.5/asyncio/futures.py:315 line, /usr/lib64/python3.5/asyncio/futures.py:322 line, /usr/lib64/python3.5/asyncio/futures.py:325 return, /usr/lib64/python3.5/asyncio/futures.py:325 line, /usr/lib64/python3.5/site-packages/tornado/iostream.py:585 line, /usr/lib64/python3.5/site-packages/tornado/iostream.py:586 line, /usr/lib64/python3.5/site-packages/tornado/iostream.py:587 call, /usr/lib64/python3.5/site-packages/tornado/iostream.py:1045 line, /usr/lib64/python3.5/site-packages/tornado/iostream.py:1046 line, /usr/lib64/python3.5/site-packages/tornado/iostream.py:1047 call, /usr/lib64/python3.5/site-packages/tornado/iostream.py:134 line, /usr/lib64/python3.5/site-packages/tornado/iostream.py:135 return, /usr/lib64/python3.5/site-packages/tornado/iostream.py:135 line, /usr/lib64/python3.5/site-packages/tornado/iostream.py:1048 line, /usr/lib64/python3.5/site-packages/tornado/iostream.py:1050 line, /usr/lib64/python3.5/site-packages/tornado/iostream.py:1051 line, /usr/lib64/python3.5/site-packages/tornado/iostream.py:1052 line, /usr/lib64/python3.5/site-packages/tornado/iostream.py:1060 call, /usr/lib64/python3.5/site-packages/tornado/iostream.py:163 line, /usr/lib64/python3.5/site-packages/tornado/iostream.py:168 line, /usr/lib64/python3.5/site-packages/tornado/iostream.py:169 line, /usr/lib64/python3.5/site-packages/tornado/iostream.py:170 line, /usr/lib64/python3.5/site-packages/tornado/iostream.py:174 line, /usr/lib64/python3.5/site-packages/tornado/iostream.py:175 line, /usr/lib64/python3.5/site-packages/tornado/iostream.py:176 return, /usr/lib64/python3.5/site-packages/tornado/iostream.py:176 call, /usr/lib64/python3.5/site-packages/tornado/iostream.py:1247 line, /usr/lib64/python3.5/site-packages/tornado/iostream.py:1248 line, /usr/lib64/python3.5/site-packages/tornado/iostream.py:1249 Program received signal SIGPIPE, Broken pipe. 0x00007ffff76f7bfb in __libc_send (fd=14, buf=0x118a0b0, n=2332, flags=0) at ../sysdeps/unix/sysv/linux/x86_64/send.c:31 31 ssize_t result = INLINE_SYSCALL (sendto, 6, fd, buf, n, flags, NULL, Missing separate debuginfos, use: debuginfo-install python35u-3.5.6-1.ius.centos7.x86_64 (gdb) (gdb) (gdb) (gdb) bt #0 0x00007ffff76f7bfb in __libc_send (fd=14, buf=0x118a0b0, n=2332, flags=0) at ../sysdeps/unix/sysv/linux/x86_64/send.c:31 #1 0x00007fffed7c6c66 in sock_send_impl () from /usr/lib64/python3.5/lib-dynload/_socket.cpython-35m-x86_64-linux-gnu.so #2 0x00007fffed7c9e06 in sock_call_ex () from /usr/lib64/python3.5/lib-dynload/_socket.cpython-35m-x86_64-linux-gnu.so #3 0x00007fffed7ca79f in sock_send () from /usr/lib64/python3.5/lib-dynload/_socket.cpython-35m-x86_64-linux-gnu.so #4 0x00007ffff79b60d9 in PyCFunction_Call () from /lib64/libpython3.5m.so.1.0 #5 0x00007ffff7a2f646 in PyEval_EvalFrameEx () from /lib64/libpython3.5m.so.1.0 #6 0x00007ffff7a2ea88 in PyEval_EvalFrameEx () from /lib64/libpython3.5m.so.1.0 #7 0x00007ffff7a2ea88 in PyEval_EvalFrameEx () from /lib64/libpython3.5m.so.1.0 #8 0x00007ffff7a30ebc in _PyEval_EvalCodeWithName () from /lib64/libpython3.5m.so.1.0 #9 0x00007ffff7a2e22f in PyEval_EvalFrameEx () from /lib64/libpython3.5m.so.1.0 #10 0x00007ffff7a30ebc in _PyEval_EvalCodeWithName () from /lib64/libpython3.5m.so.1.0 #11 0x00007ffff7a2e22f in PyEval_EvalFrameEx () from /lib64/libpython3.5m.so.1.0 #12 0x00007ffff7a30ebc in _PyEval_EvalCodeWithName () from /lib64/libpython3.5m.so.1.0 #13 0x00007ffff7a2e22f in PyEval_EvalFrameEx () from /lib64/libpython3.5m.so.1.0 #14 0x00007ffff7a30ebc in _PyEval_EvalCodeWithName () from /lib64/libpython3.5m.so.1.0 #15 0x00007ffff7a2e22f in PyEval_EvalFrameEx () from /lib64/libpython3.5m.so.1.0 #16 0x00007ffff79924c0 in gen_send_ex () from /lib64/libpython3.5m.so.1.0 #17 0x00007ffff7a2ec28 in PyEval_EvalFrameEx () from /lib64/libpython3.5m.so.1.0 #18 0x00007ffff7a30ebc in _PyEval_EvalCodeWithName () from /lib64/libpython3.5m.so.1.0 #19 0x00007ffff7a30fc8 in PyEval_EvalCodeEx () from /lib64/libpython3.5m.so.1.0 #20 0x00007ffff799958e in function_call () from /lib64/libpython3.5m.so.1.0 #21 0x00007ffff796e2aa in PyObject_Call () from /lib64/libpython3.5m.so.1.0 #22 0x00007ffff7a2be87 in PyEval_EvalFrameEx () from /lib64/libpython3.5m.so.1.0 #23 0x00007ffff7a2ea88 in PyEval_EvalFrameEx () from /lib64/libpython3.5m.so.1.0 #24 0x00007ffff7a2ea88 in PyEval_EvalFrameEx () from /lib64/libpython3.5m.so.1.0 #25 0x00007ffff7a2ea88 in PyEval_EvalFrameEx () from /lib64/libpython3.5m.so.1.0 #26 0x00007ffff7a2ea88 in PyEval_EvalFrameEx () from /lib64/libpython3.5m.so.1.0 #27 0x00007ffff7a2ea88 in PyEval_EvalFrameEx () from /lib64/libpython3.5m.so.1.0 #28 0x00007ffff7a30ebc in _PyEval_EvalCodeWithName () from /lib64/libpython3.5m.so.1.0 #29 0x00007ffff7a30fc8 in PyEval_EvalCodeEx () from /lib64/libpython3.5m.so.1.0 #30 0x00007ffff7a3100b in PyEval_EvalCode () from /lib64/libpython3.5m.so.1.0 #31 0x00007ffff7a50434 in run_mod () from /lib64/libpython3.5m.so.1.0 #32 0x00007ffff7a528bd in PyRun_FileExFlags () from /lib64/libpython3.5m.so.1.0 #33 0x00007ffff7a52a27 in PyRun_SimpleFileExFlags () from /lib64/libpython3.5m.so.1.0 #34 0x00007ffff7a68bec in Py_Main () from /lib64/libpython3.5m.so.1.0 #35 0x0000000000400a29 in main () (gdb) ---------- components: asyncio messages: 335447 nosy: asvetlov, hinxx, yselivanov priority: normal severity: normal status: open title: Python interpreter segfault type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 10:22:53 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Wed, 13 Feb 2019 15:22:53 +0000 Subject: [issue33376] [pysqlite] Duplicate rows can be returned after rolling back a transaction In-Reply-To: <1524874511.54.0.682650639539.issue33376@psf.upfronthosting.co.za> Message-ID: <1550071373.74.0.125603538442.issue33376@roundup.psfhosted.org> Change by Cheryl Sabella : ---------- versions: -Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 10:25:27 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 13 Feb 2019 15:25:27 +0000 Subject: [issue35982] Create unit-tests for os.renames() In-Reply-To: <1550050887.9.0.145116201828.issue35982@roundup.psfhosted.org> Message-ID: <1550071527.54.0.287398658062.issue35982@roundup.psfhosted.org> Giampaolo Rodola' added the comment: Assigning this to me. FWIW I created a post on python-dev in order to add a test.support.rmpath() utility function and hopefully cover other os.* functions which may also be untested or not properly tested: https://mail.python.org/pipermail/python-dev/2019-February/156267.html ---------- assignee: -> giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 10:25:29 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Feb 2019 15:25:29 +0000 Subject: [issue35988] Python interpreter segfault In-Reply-To: <1550069169.56.0.128755825216.issue35988@roundup.psfhosted.org> Message-ID: <1550071529.54.0.524121103084.issue35988@roundup.psfhosted.org> STINNER Victor added the comment: > Every now and then the python3.5 crashes, seg faults. Sorry but Python 3.5 no longer accepts bugfixes and has known bugs. http://devguide.python.org/#status-of-python-branches It's time to upgrade your Python! Are you able to reproduce the crash on Python 3.6 or 3.7? ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 10:27:25 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Feb 2019 15:27:25 +0000 Subject: [issue35988] Python interpreter segfault In-Reply-To: <1550069169.56.0.128755825216.issue35988@roundup.psfhosted.org> Message-ID: <1550071645.04.0.724543378062.issue35988@roundup.psfhosted.org> STINNER Victor added the comment: > Program received signal SIGPIPE, Broken pipe. SIGPIPE is not a bug, it's a deliberate signal to notice something to your application. You have to ignore SIGPIPE in gdb: (gdb) handle SIGPIPE nostop noprint Signal Stop Print Pass to program Description SIGPIPE No No Yes Broken pipe ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 10:28:21 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Feb 2019 15:28:21 +0000 Subject: [issue35988] Python interpreter segfault In-Reply-To: <1550069169.56.0.128755825216.issue35988@roundup.psfhosted.org> Message-ID: <1550071701.12.0.179337042007.issue35988@roundup.psfhosted.org> STINNER Victor added the comment: You can enable faulthandler to get a traceback of your Python theads when a crash occurs: https://pythondev.readthedocs.io/debug_tools.html#get-a-traceback-on-a-crash ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 10:29:17 2019 From: report at bugs.python.org (Emily Morehouse) Date: Wed, 13 Feb 2019 15:29:17 +0000 Subject: [issue35224] PEP 572: Assignment Expressions In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za> Message-ID: <1550071757.63.0.836591772007.issue35224@roundup.psfhosted.org> Emily Morehouse added the comment: I have a work-in-progress (WIP) documentation branch I've been working on that I'll push up this week to address the following: - Add summary to What's New in Doc/whatsnew/3.8.rst - Add to list of delimiters in Doc/reference/lexical_analysis.rst - Add usage documentation in Doc/reference/expressions.rst - Update FAQ in Doc/faq/design.rst (https://bugs.python.org/issue35666) If anyone has another area they think the documentation should be updated, please let me know! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 10:34:50 2019 From: report at bugs.python.org (Eric Snow) Date: Wed, 13 Feb 2019 15:34:50 +0000 Subject: [issue35983] tp_dealloc trashcan shouldn't be called for subclasses In-Reply-To: <1550055751.42.0.717332216151.issue35983@roundup.psfhosted.org> Message-ID: <1550072090.94.0.585843815654.issue35983@roundup.psfhosted.org> Eric Snow added the comment: FWIW, subclassing builtin types is a relatively new thing. There are still a number of lingering (older) implementation details throughout CPython that were written assuming no subclassing. I'd guess that this is one of them. ---------- nosy: +eric.snow stage: -> test needed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 10:41:48 2019 From: report at bugs.python.org (Hinko Kocevar) Date: Wed, 13 Feb 2019 15:41:48 +0000 Subject: [issue35988] Python interpreter segfault In-Reply-To: <1550069169.56.0.128755825216.issue35988@roundup.psfhosted.org> Message-ID: <1550072508.53.0.318807930375.issue35988@roundup.psfhosted.org> Hinko Kocevar added the comment: > Are you able to reproduce the crash on Python 3.6 or 3.7? I'm running it under python3.6 as we speak. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 10:42:39 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 13 Feb 2019 15:42:39 +0000 Subject: [issue35983] tp_dealloc trashcan shouldn't be called for subclasses In-Reply-To: <1550055751.42.0.717332216151.issue35983@roundup.psfhosted.org> Message-ID: <1550072559.02.0.0473213195021.issue35983@roundup.psfhosted.org> Antoine Pitrou added the comment: By "relatively new thing", you mean less than 20 years old? :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 10:46:45 2019 From: report at bugs.python.org (Hinko Kocevar) Date: Wed, 13 Feb 2019 15:46:45 +0000 Subject: [issue35988] Python interpreter segfault In-Reply-To: <1550069169.56.0.128755825216.issue35988@roundup.psfhosted.org> Message-ID: <1550072805.85.0.966917245459.issue35988@roundup.psfhosted.org> Hinko Kocevar added the comment: Using python3.6 now. I've also used the 'handle SIGPIPE nostop noprint' to skip SIGPIPE. Now the interpreter is killed instead: INF 2019-02-13 15:42:19,131 web:2162 log_request - 200 GET /NPM.html (10.0.6.209) 1.10ms [Thread 0x7fffe76eb700 (LWP 8411) exited] [Thread 0x7fffe78ec700 (LWP 8410) exited] [Thread 0x7fffe7a2d700 (LWP 8409) exited] [Thread 0x7fffe7d41700 (LWP 8408) exited] [Thread 0x7fffe8542700 (LWP 8407) exited] Program terminated with signal SIGKILL, Killed. The program no longer exists. (gdb) bt No stack. (gdb) And the dmesg shows, what I think is the real reason, for python3.5/3.6 dying on me (out of memory): [26194250.313676] vmtoolsd invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0 [26194250.313691] vmtoolsd cpuset=/ mems_allowed=0 [26194250.313696] CPU: 0 PID: 29876 Comm: vmtoolsd Not tainted 3.10.0-693.21.1.el7.x86_64 #1 [26194250.313697] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/05/2016 [26194250.313698] Call Trace: [26194250.313714] [] dump_stack+0x19/0x1b [26194250.313717] [] dump_header+0x90/0x229 [26194250.313725] [] ? ktime_get_ts64+0x52/0xf0 [26194250.313733] [] ? delayacct_end+0x8f/0xb0 [26194250.313737] [] oom_kill_process+0x254/0x3d0 [26194250.313739] [] ? oom_unkillable_task+0xcd/0x120 [26194250.313740] [] ? find_lock_task_mm+0x56/0xc0 [26194250.313742] [] out_of_memory+0x4b6/0x4f0 [26194250.313744] [] __alloc_pages_slowpath+0x5d6/0x724 [26194250.313747] [] __alloc_pages_nodemask+0x405/0x420 [26194250.313752] [] alloc_pages_current+0x98/0x110 [26194250.313757] [] __page_cache_alloc+0x97/0xb0 [26194250.313759] [] filemap_fault+0x170/0x420 [26194250.313869] [] ext4_filemap_fault+0x36/0x50 [ext4] [26194250.313875] [] __do_fault+0x58/0xe0 [26194250.313876] [] do_read_fault.isra.44+0x4b/0x130 [26194250.313880] [] handle_mm_fault+0x691/0xfa0 [26194250.313888] [] ? cputime_adjust+0x94/0x150 [26194250.313893] [] __do_page_fault+0x154/0x450 [26194250.313894] [] do_page_fault+0x35/0x90 [26194250.313898] [] page_fault+0x28/0x30 [26194250.313912] Mem-Info: [26194250.313915] active_anon:317608 inactive_anon:106541 isolated_anon:0 active_file:836 inactive_file:1338 isolated_file:0 unevictable:0 dirty:0 writeback:0 unstable:0 slab_reclaimable:5892 slab_unreclaimable:7233 mapped:394 shmem:334 pagetables:5322 bounce:0 free:12861 free_pcp:12 free_cma:0 [26194250.313920] Node 0 DMA free:7624kB min:380kB low:472kB high:568kB active_anon:3680kB inactive_anon:3828kB active_file:4kB inactive_file:96kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15992kB managed:15908kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:4kB slab_reclaimable:96kB slab_unreclaimable:52kB kernel_stack:32kB pagetables:160kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:492 all_unreclaimable? yes [26194250.313925] lowmem_reserve[]: 0 1822 1822 1822 [26194250.313927] Node 0 DMA32 free:43820kB min:44672kB low:55840kB high:67008kB active_anon:1266752kB inactive_anon:422336kB active_file:3340kB inactive_file:5256kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:2080704kB managed:1867756kB mlocked:0kB dirty:0kB writeback:0kB mapped:1572kB shmem:1332kB slab_reclaimable:23472kB slab_unreclaimable:28880kB kernel_stack:3200kB pagetables:21128kB unstable:0kB bounce:0kB free_pcp:48kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:11345 all_unreclaimable? yes [26194250.313930] lowmem_reserve[]: 0 0 0 0 [26194250.313932] Node 0 DMA: 4*4kB (UEM) 9*8kB (UEM) 9*16kB (UEM) 3*32kB (E) 2*64kB (UE) 2*128kB (UE) 3*256kB (UM) 4*512kB (UEM) 4*1024kB (EM) 0*2048kB 0*4096kB = 7624kB [26194250.313939] Node 0 DMA32: 386*4kB (E) 482*8kB (UE) 324*16kB (UEM) 247*32kB (UEM) 157*64kB (UEM) 56*128kB (UEM) 18*256kB (UEM) 7*512kB (UEM) 0*1024kB 0*2048kB 0*4096kB = 43896kB [26194250.313945] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB [26194250.313946] 3429 total pagecache pages [26194250.313947] 890 pages in swap cache [26194250.313950] Swap cache stats: add 52552391, delete 52551501, find 24707502/29312733 [26194250.313951] Free swap = 0kB [26194250.313951] Total swap = 2047996kB [26194250.313952] 524174 pages RAM [26194250.313953] 0 pages HighMem/MovableOnly [26194250.313953] 53258 pages reserved [26194250.313954] [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name [26194250.313963] [ 564] 0 564 9307 371 23 46 0 systemd-journal [26194250.313965] [ 751] 81 751 9244 104 21 89 -900 dbus-daemon [26194250.313967] [ 783] 0 783 138064 94 101 9333 0 NetworkManager [26194250.313968] [ 849] 0 849 28343 0 58 3123 0 dhclient [26194250.313970] [ 1016] 0 1016 8818 35 19 236 0 systemd-logind [26194250.313971] [ 1033] 0 1033 27511 0 10 29 0 agetty [26194250.313973] [ 1063] 0 1063 58637 1 70 2842 0 salt-minion [26194250.313974] [ 1064] 0 1064 7674 0 20 83 0 oddjobd [26194250.313976] [ 1855] 0 1855 188662 798 115 5821 0 salt-minion [26194250.313977] [ 6990] 0 6990 5418 39 16 42 0 irqbalance [26194250.313979] [ 7014] 38 7014 9491 36 19 117 0 ntpd [26194250.313980] [ 1093] 1768605311 1093 9175 10 19 75 0 caRepeater [26194250.313982] [ 2463] 0 2463 28203 0 57 257 -1000 sshd [26194250.313984] [23726] 0 23726 11089 1 25 112 -1000 systemd-udevd [26194250.313985] [29632] 0 29632 90496 237 97 6261 0 firewalld [26194250.313987] [29874] 0 29874 24891 0 42 403 0 VGAuthService [26194250.313988] [29876] 0 29876 56747 91 56 246 0 vmtoolsd [26194250.313990] [29942] 0 29942 31206 0 27 90 0 lvmetad [26194250.313991] [ 7357] 0 7357 22907 5 45 255 0 master [26194250.313993] [ 7359] 89 7359 25518 0 48 266 0 qmgr [26194250.313994] [ 7387] 0 7387 15511 17 30 139 -1000 auditd [26194250.313995] [ 7432] 0 7432 31572 19 18 137 0 crond [26194250.313997] [ 7455] 0 7455 109816 325 91 447 0 rsyslogd [26194250.313998] [ 7498] 996 7498 300955 41 535 265234 0 redis-server [26194250.314000] [ 7559] 999 7559 156319 94 63 981 0 polkitd [26194250.314002] [ 7577] 0 7577 143454 101 100 2695 0 tuned [26194250.314003] [ 7822] 0 7822 67726 10 80 248 0 sssd [26194250.314004] [ 7823] 0 7823 134088 951 183 4925 0 sssd_be [26194250.314006] [ 7824] 0 7824 73958 195 92 171 0 sssd_nss [26194250.314007] [ 7825] 0 7825 64757 216 78 167 0 sssd_pam [26194250.314009] [14104] 0 14104 110005 41 158 543 0 smbd [26194250.314010] [14106] 0 14106 103821 41 146 515 0 smbd-notifyd [26194250.314012] [14107] 0 14107 103940 47 148 509 0 cleanupd [26194250.314013] [14108] 0 14108 110001 33 148 549 0 lpqd [26194250.314014] [14117] 0 14117 87243 47 118 401 0 nmbd [26194250.314016] [23233] 0 23233 48857 180 49 4827 0 miniserv.pl [26194250.314017] [13608] 1768605311 13608 34728 230 18 105 0 screen [26194250.314019] [13609] 1768605311 13609 31772 235 18 201 0 bash [26194250.314020] [ 7203] 0 7203 110827 69 159 546 0 smbd [26194250.314021] [ 7293] 0 7293 48031 1 87 355 0 sshd [26194250.314023] [ 7296] 1768605311 7296 48417 41 86 723 0 sshd [26194250.314024] [ 7297] 1768605311 7297 31730 1 17 391 0 bash [26194250.314025] [ 7399] 0 7399 118856 85 159 944 0 smbd [26194250.314027] [ 7467] 1768605311 7467 34483 8 22 68 0 screen [26194250.314028] [ 8047] 0 8047 110262 185 155 449 0 smbd [26194250.314030] [ 8085] 0 8085 48031 5 89 351 0 sshd [26194250.314031] [ 8087] 1768605311 8087 48031 28 85 335 0 sshd [26194250.314032] [ 8088] 1768605311 8088 31767 245 17 191 0 bash [26194250.314034] [ 8367] 1768605311 8367 40484 0 32 713 0 vim [26194250.314035] [ 8368] 89 8368 25474 0 45 253 0 pickup [26194250.314037] [ 8392] 0 8392 70218 0 82 315 0 sudo [26194250.314038] [ 8395] 0 8395 28294 0 13 49 0 bash [26194250.314039] [ 8397] 0 8397 55725 1 63 12295 0 gdb [26194250.314041] [ 8399] 0 8399 713552 418045 1224 162923 0 python3.6 [26194250.314042] Out of memory: Kill process 8399 (python3.6) score 574 or sacrifice child [26194250.315180] Killed process 8399 (python3.6) total-vm:2854208kB, anon-rss:1672180kB, file-rss:0kB, shmem-rss:0kB ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 10:47:49 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Feb 2019 15:47:49 +0000 Subject: [issue35988] Python interpreter segfault In-Reply-To: <1550069169.56.0.128755825216.issue35988@roundup.psfhosted.org> Message-ID: <1550072869.18.0.206069365375.issue35988@roundup.psfhosted.org> STINNER Victor added the comment: > [26194250.314042] Out of memory: Kill process 8399 (python3.6) score 574 or sacrifice child That's not a bug in Python: your application is using more memory than what is available in the system. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 10:48:34 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Feb 2019 15:48:34 +0000 Subject: [issue35224] PEP 572: Assignment Expressions In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za> Message-ID: <1550072914.37.0.789918223549.issue35224@roundup.psfhosted.org> STINNER Victor added the comment: > If anyone has another area they think the documentation should be updated, please let me know! If we forget something, it's not an issue: it can be added later! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 10:51:52 2019 From: report at bugs.python.org (Eric Snow) Date: Wed, 13 Feb 2019 15:51:52 +0000 Subject: [issue35972] _xxsubinterpreters: channel_send() may truncate ints on 32-bit platforms In-Reply-To: <1549921968.67.0.462504390355.issue35972@roundup.psfhosted.org> Message-ID: <1550073112.59.0.500766500669.issue35972@roundup.psfhosted.org> Eric Snow added the comment: ack ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 10:52:37 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Wed, 13 Feb 2019 15:52:37 +0000 Subject: [issue35983] tp_dealloc trashcan shouldn't be called for subclasses In-Reply-To: <1550055751.42.0.717332216151.issue35983@roundup.psfhosted.org> Message-ID: <1550073157.44.0.452232404777.issue35983@roundup.psfhosted.org> Change by Jeroen Demeyer : ---------- keywords: +patch pull_requests: +11871 stage: test needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 11:13:55 2019 From: report at bugs.python.org (John Florian) Date: Wed, 13 Feb 2019 16:13:55 +0000 Subject: [issue35989] ipaddress.IPv4Network allows prefix > 32 Message-ID: <1550074435.28.0.00523777369606.issue35989@roundup.psfhosted.org> New submission from John Florian : I wanted a simple is_valid_ipv4_network() function, so I wrote one and a bunch of unit tests where I discovered that I can legally: >>> n = IPv4Network(('192.168.123.234', 12345678)) >>> n IPv4Network('192.168.123.234/12345678') >>> n.prefixlen 12345678 >>> n.max_prefixlen 32 I assume this is a bug. ---------- messages: 335460 nosy: John Florian priority: normal severity: normal status: open title: ipaddress.IPv4Network allows prefix > 32 versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 11:14:52 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Wed, 13 Feb 2019 16:14:52 +0000 Subject: [issue35989] ipaddress.IPv4Network allows prefix > 32 In-Reply-To: <1550074435.28.0.00523777369606.issue35989@roundup.psfhosted.org> Message-ID: <1550074492.66.0.837347228294.issue35989@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 11:19:15 2019 From: report at bugs.python.org (Eric Snow) Date: Wed, 13 Feb 2019 16:19:15 +0000 Subject: [issue35984] test__xxsubinterpreters leaked [3, 4, 3] memory blocks, sum=1 In-Reply-To: <1550056203.45.0.644918745906.issue35984@roundup.psfhosted.org> Message-ID: <1550074755.08.0.592363384649.issue35984@roundup.psfhosted.org> Eric Snow added the comment: Alexey, even though the refleak does not appear to be related to your earlier PR, you are welcome to keep working on this issue. :) If you do then please add me as a reviewer on whatever PR you make. Also, I'd be glad to answer any questions you have about the _xxsubinterpreters module. The more folks that understand that code, the better. :) On the other hand, if you decide at this point that you'd rather do something else than track down refleaks I introduced then I'd totally understand. :) In that case feel free to assign this issue to me at that time. ---------- stage: -> test needed type: -> resource usage _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 11:19:25 2019 From: report at bugs.python.org (Eric Snow) Date: Wed, 13 Feb 2019 16:19:25 +0000 Subject: [issue35984] test__xxsubinterpreters leaked [3, 4, 3] memory blocks, sum=1 In-Reply-To: <1550056203.45.0.644918745906.issue35984@roundup.psfhosted.org> Message-ID: <1550074765.47.0.852218022203.issue35984@roundup.psfhosted.org> Eric Snow added the comment: FYI, the _xxsubinterpreters module serves several purposes. First, it allows us to more thoroughly test the subinterpreter functionality of CPython (doing so via _testembed and _testcapi is messy), effectively in test__xxsubinterpreters. Second, it is the foundation for helpers (which I intend on adding to test.support in the 3.8 time frame) for easily using subinterpreters in the test suite in lieu of subprocesses. Third, ultimately it will be the low-level implementation of PEP 554. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 11:28:05 2019 From: report at bugs.python.org (Eric Snow) Date: Wed, 13 Feb 2019 16:28:05 +0000 Subject: [issue35983] tp_dealloc trashcan shouldn't be called for subclasses In-Reply-To: <1550072559.02.0.0473213195021.issue35983@roundup.psfhosted.org> Message-ID: Eric Snow added the comment: On Wed, Feb 13, 2019 at 8:42 AM Antoine Pitrou wrote: > Antoine Pitrou added the comment: > > By "relatively new thing", you mean less than 20 years old? :-) Yeah, looks like it was in the 2.2 release (Dec 2001) for PEP 253. Anyway, I know of several core devs who are still opposed to subclassing builtin types. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 12:05:33 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Feb 2019 17:05:33 +0000 Subject: [issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h In-Reply-To: <1549069628.87.0.454232469964.issue35886@roundup.psfhosted.org> Message-ID: <1550077533.21.0.858086409717.issue35886@roundup.psfhosted.org> STINNER Victor added the comment: > @Victor, do you see any problems with doing this? It will help simplify other changes I'm working on. I'm quite sure that they are users of the PyInterpreterState structure outside CPython internals and stdlib, but I expect that the number is quite low. Since internal headers are now installed (I modified "make install" for that) (but need to define Py_BUILD_CORE), it might be acceptable to force users of this structure to opt-in for internal headers. Just make sure that we properly communicate on such backward incompatible changes: * "C API Changes" section of https://docs.python.org/dev/whatsnew/3.8.html#porting-to-python-3-8 * mail to python-dev The bpo-35810 also proposes a subtle backward incompatible change which makes me unhappy, but Stefan Behnel seems less scared than me, so maybe it will be fine. Maybe we need to organize a collective effort to better communicate on our backward incompatible C API changes. The capi-sig mailing list may be a good channel for that. I asked to test some popular C extensions to check that they are not broken. If it's the case, we should help them to be prepared for the new C API. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 12:06:13 2019 From: report at bugs.python.org (SilentGhost) Date: Wed, 13 Feb 2019 17:06:13 +0000 Subject: [issue35989] ipaddress.IPv4Network allows prefix > 32 In-Reply-To: <1550074435.28.0.00523777369606.issue35989@roundup.psfhosted.org> Message-ID: <1550077573.4.0.435868327743.issue35989@roundup.psfhosted.org> Change by SilentGhost : ---------- components: +Library (Lib) nosy: +pitrou stage: -> test needed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 12:06:53 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Feb 2019 17:06:53 +0000 Subject: [issue35949] Move PyThreadState into Include/internal/pycore_pystate.h In-Reply-To: <1549677619.84.0.322696563838.issue35949@roundup.psfhosted.org> Message-ID: <1550077613.21.0.0151408742089.issue35949@roundup.psfhosted.org> STINNER Victor added the comment: Same ratione than for PyInterpreterState: https://bugs.python.org/issue35886#msg335464 Except that I expect that a few more projects rely on PyThreadState fields. Maybe not. It's hard to guess :-( I mean that I'm ok-ish with the change but it should be carefully prepared and announced. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 12:11:04 2019 From: report at bugs.python.org (Sihoon Lee) Date: Wed, 13 Feb 2019 17:11:04 +0000 Subject: [issue35907] Unnecessary URL scheme exists to allow file:// reading file in urllib In-Reply-To: <1549441191.29.0.148559977828.issue35907@roundup.psfhosted.org> Message-ID: <1550077864.36.0.63420313683.issue35907@roundup.psfhosted.org> Change by Sihoon Lee : ---------- keywords: +patch pull_requests: +11872 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 12:13:32 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Feb 2019 17:13:32 +0000 Subject: [issue35706] Make it easier to use a venv with an embedded Python interpreter In-Reply-To: <1547129099.62.0.924394155356.issue35706@roundup.psfhosted.org> Message-ID: <1550078012.15.0.411041529017.issue35706@roundup.psfhosted.org> STINNER Victor added the comment: PEP 432 will allow to give with fine control on parameters used to initialize Python. Sadly, I failed to agree with Nick Coghlan and Eric Snow on the API. The current implementation (_PyCoreConfig and _PyMainInterpreterConfig) has some flaw (don't separate clearly the early initialization and Unicode-ready state, the interpreter contains main and core config whereas some options are duplicated in both configs, etc.). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 12:14:26 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Feb 2019 17:14:26 +0000 Subject: [issue35706] Make it easier to use a venv with an embedded Python interpreter In-Reply-To: <1547129099.62.0.924394155356.issue35706@roundup.psfhosted.org> Message-ID: <1550078066.5.0.99187212389.issue35706@roundup.psfhosted.org> STINNER Victor added the comment: See also bpo-22213. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 12:14:28 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Feb 2019 17:14:28 +0000 Subject: [issue22213] Make pyvenv style virtual environments easier to configure when embedding Python In-Reply-To: <1408275761.36.0.915361061447.issue22213@psf.upfronthosting.co.za> Message-ID: <1550078068.47.0.707515776849.issue22213@roundup.psfhosted.org> STINNER Victor added the comment: PEP 432 will allow to give with fine control on parameters used to initialize Python. Sadly, I failed to agree with Nick Coghlan and Eric Snow on the API. The current implementation (_PyCoreConfig and _PyMainInterpreterConfig) has some flaw (don't separate clearly the early initialization and Unicode-ready state, the interpreter contains main and core config whereas some options are duplicated in both configs, etc.). See also bpo-35706. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 12:44:49 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 13 Feb 2019 17:44:49 +0000 Subject: [issue35706] Make it easier to use a venv with an embedded Python interpreter In-Reply-To: <1547129099.62.0.924394155356.issue35706@roundup.psfhosted.org> Message-ID: <1550079889.34.0.421768467726.issue35706@roundup.psfhosted.org> Steve Dower added the comment: That's not a "see also" - it's just a duplicate :) I'll close this one as the other one has been around longer. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Make pyvenv style virtual environments easier to configure when embedding Python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 12:56:56 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 13 Feb 2019 17:56:56 +0000 Subject: [issue22213] Make pyvenv style virtual environments easier to configure when embedding Python In-Reply-To: <1408275761.36.0.915361061447.issue22213@psf.upfronthosting.co.za> Message-ID: <1550080616.84.0.256720824268.issue22213@roundup.psfhosted.org> Steve Dower added the comment: I just closed 35706 as a duplicate of this one (the titles are basically identical, which feels like a good hint ;) ) It seems that the disagreement about the design is fundamentally a disagreement between a "quick, painful but complete fix" and "slow, careful improvements with a transition period". Both are valid approaches, and since Victor is putting actual effort in right now he gets to "win", but I do think we can afford to move faster. It seems the main people who will suffer from the pain here are embedders (who are already suffering pain) and the core developers (who explicitly signed up for pain!). But without knowing the end goal, we can't accelerate. Currently PEP 432 is the best description we have, and it looks like Victor has been heading in that direction too (deliberately? I don't know :) ). But it seems like a good time to review it, replace the "here's the current state of things" with "here's an imaginary ideal state of things" and fill the rest with "here are the steps to get there without breaking the world". By necessity, it touches a lot of people's contributions to Python, but it also has the potential to seriously improve even more people's ability to _use_ Python (for example, I know an app that you all would recognize the name of who is working on embedding Python right now and would _love_ certain parts of this side of things to be improved). Nick - has the steering council been thinking about ways to promote collaborative development of ideas like this? I'm thinking an Etherpad style environment for the brainstorm period (in lieu of an in-person whiteboard session) that's easy for us all to add our concerns to, that can then be turned into something more formal. Nick, Victor, Eric, (others?) - are you interested in having a virtual whiteboard session to brainstorm how the "perfect" initialization looks? And probably a follow-up to brainstorm how to get there without breaking the world? I don't think we're going to get to be in the same room anytime before the language summit, and it would be awesome to have something concrete to discuss there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 13:07:14 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 13 Feb 2019 18:07:14 +0000 Subject: [issue35988] Python interpreter segfault In-Reply-To: <1550069169.56.0.128755825216.issue35988@roundup.psfhosted.org> Message-ID: <1550081234.86.0.542135888347.issue35988@roundup.psfhosted.org> Josh Rosenberg added the comment: "your application is using more memory than what is available in the system." Well, it alone may not be using more memory, but the cumulative usage on the system is "too high" by whatever metric the OOM killer is using (IIRC the default rule is that actual committed memory must be less than swap size + 50% of RAM). The OOM killer is a strange and terrible beast, and the behavior varies based on configuration, relative memory usage of each process grouping, minimizing number of processes killed, etc. You can find deep implementation details on it (including how to disable a given process for consideration) here: https://linux-mm.org/OOM_Killer The real solution to problems like this usually amounts to: 1. Install more RAM. 2. Increase the size of your swap partition. Doesn't "fix" being shy of memory if you're actually using more memory than you have RAM, but allows you to handle overcommit (particularly for fork+exec scenarios where the forked process's memory will be freed momentarily) without the OOM killer getting involved, and to limp along slowly, without actually failing, if you actually allocate and use more memory than you have RAM. 3. Tweak the overcommit heuristics to allow more overcommit before invoking the OOM killer. 4. Disable overcommit entirely, so memory allocations fail immediately if sufficient backing storage is not available, rather than succeeding, only to invoke the OOM killer when the allocated memory gets used and the shortage is discovered. This is a good solution if the program(s) in question aren't poorly designed such that they try to allocate many GBs of memory up front even when they're unlikely to need it; unfortunately, there are commonly used programs that overallocate like this and render this solution non-viable if they're part of your setup. Regardless, this isn't a bug in Python itself. Any process that uses a lot of memory (Apache, MySQL) and hasn't explicitly removed itself from OOM killer consideration is going to look tasty when an OOM scenario occurs. ---------- nosy: +josh.r resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 13:30:33 2019 From: report at bugs.python.org (Roundup Robot) Date: Wed, 13 Feb 2019 18:30:33 +0000 Subject: [issue5038] urrlib2/httplib doesn't reset file position between requests In-Reply-To: <1232730438.9.0.904675957675.issue5038@psf.upfronthosting.co.za> Message-ID: <1550082633.43.0.799501463721.issue5038@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch pull_requests: +11873 stage: test needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 13:33:09 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 13 Feb 2019 18:33:09 +0000 Subject: [issue15753] No-argument super in method with variable arguments raises SystemError In-Reply-To: <1345549960.82.0.102703520127.issue15753@psf.upfronthosting.co.za> Message-ID: <1550082789.96.0.528631657445.issue15753@roundup.psfhosted.org> Josh Rosenberg added the comment: Moving from pending back to open (not sure what was "pending" about it?). The workaround is viable (and used by Python implemented dict subclasses in the standard library since they must accept **kwargs with arbitrary strings, including self), but it does seem a little silly that it's required. Leaving it as low priority since the workaround exists. Still, would be nice to make super() seamless, pulling the first argument if the function accepts it as non-varargs, and the first element of the first argument if it's varargs. If someone reassigns self/args, that's on them; it's fine to raise a RuntimeError if they use no-arg super(), requiring them to use two-arg super explicitly in that case. ---------- priority: normal -> low status: pending -> open versions: +Python 3.8 -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 13:51:17 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Wed, 13 Feb 2019 18:51:17 +0000 Subject: [issue15753] No-argument super in method with variable arguments raises SystemError In-Reply-To: <1345549960.82.0.102703520127.issue15753@psf.upfronthosting.co.za> Message-ID: <1550083877.19.0.32538053636.issue15753@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 14:28:48 2019 From: report at bugs.python.org (John Florian) Date: Wed, 13 Feb 2019 19:28:48 +0000 Subject: [issue35990] ipaddress.IPv4Interface won't accept 2-tuple (address, mask) Message-ID: <1550086128.37.0.0760252061885.issue35990@roundup.psfhosted.org> New submission from John Florian : The docs say """The meaning of address is as in the constructor of IPv4Network, except that arbitrary host addresses are always accepted.""" However, that doesn't seem to be entirely true: >>> tup1 = ('192.168.123.234', 24) >>> tup2 = ('192.168.123.234', '255.255.255.0') >>> IPv4Network(tup1, strict=False) IPv4Network('192.168.123.0/24') >>> IPv4Network(tup2, strict=False) IPv4Network('192.168.123.0/24') >>> IPv4Interface(tup1) IPv4Interface('192.168.123.234/24') >>> IPv4Interface(tup2) Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.7/ipaddress.py", line 1391, in __init__ self._prefixlen = int(address[1]) ValueError: invalid literal for int() with base 10: '255.255.255.0' ---------- messages: 335474 nosy: John Florian priority: normal severity: normal status: open title: ipaddress.IPv4Interface won't accept 2-tuple (address, mask) versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 15:45:06 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 13 Feb 2019 20:45:06 +0000 Subject: [issue35989] ipaddress.IPv4Network allows prefix > 32 In-Reply-To: <1550074435.28.0.00523777369606.issue35989@roundup.psfhosted.org> Message-ID: <1550090706.65.0.247847218136.issue35989@roundup.psfhosted.org> Change by St?phane Wirtel : ---------- keywords: +patch pull_requests: +11875 stage: test needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 15:47:15 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 13 Feb 2019 20:47:15 +0000 Subject: [issue35989] ipaddress.IPv4Network allows prefix > 32 In-Reply-To: <1550074435.28.0.00523777369606.issue35989@roundup.psfhosted.org> Message-ID: <1550090835.13.0.34754352068.issue35989@roundup.psfhosted.org> St?phane Wirtel added the comment: I proposed my PR but I prefer a review because in the code of ipaddress, there is a function for the validation of an address with the netmask. Maybe we could use this function and try to refactor/improve the current code. ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 15:51:51 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Wed, 13 Feb 2019 20:51:51 +0000 Subject: [issue35983] tp_dealloc trashcan shouldn't be called for subclasses In-Reply-To: <1550055751.42.0.717332216151.issue35983@roundup.psfhosted.org> Message-ID: <1550091111.78.0.00937239119348.issue35983@roundup.psfhosted.org> Jeroen Demeyer added the comment: NOTE: also OrderedDict currently uses trashcan hacking to work around this problem: /* Call the base tp_dealloc(). Since it too uses the trashcan mechanism, * temporarily decrement trash_delete_nesting to prevent triggering it * and putting the partially deallocated object on the trashcan's * to-be-deleted-later list. */ --tstate->trash_delete_nesting; assert(_tstate->trash_delete_nesting < PyTrash_UNWIND_LEVEL); PyDict_Type.tp_dealloc((PyObject *)self); ++tstate->trash_delete_nesting; So this seems to be a known problem which deserves to be fixed properly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 16:08:06 2019 From: report at bugs.python.org (Alexey Izbyshev) Date: Wed, 13 Feb 2019 21:08:06 +0000 Subject: [issue35984] test__xxsubinterpreters leaked [3, 4, 3] memory blocks, sum=1 In-Reply-To: <1550056203.45.0.644918745906.issue35984@roundup.psfhosted.org> Message-ID: <1550092086.07.0.139930554024.issue35984@roundup.psfhosted.org> Change by Alexey Izbyshev : ---------- keywords: +patch pull_requests: +11876 stage: test needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 16:19:23 2019 From: report at bugs.python.org (Alexey Izbyshev) Date: Wed, 13 Feb 2019 21:19:23 +0000 Subject: [issue35984] test__xxsubinterpreters leaked [3, 4, 3] memory blocks, sum=1 In-Reply-To: <1550056203.45.0.644918745906.issue35984@roundup.psfhosted.org> Message-ID: <1550092763.4.0.0286482956437.issue35984@roundup.psfhosted.org> Alexey Izbyshev added the comment: Thank you for your introduction about _xxsubinterpreters, Eric. This particular leak is easy: it's right in _channel_send(). I've submitted a PR. I've also done a quick scan of neighboring code, and it seems there are other leaks as well, e.g.: * PyThread_free_lock() is not called at https://github.com/python/cpython/blob/dcb68f47f74b0cc8a1896d4a4c5a6b83c0bbeeae/Modules/_xxsubinterpretersmodule.c#L761 (and below) * data is not released and freed at https://github.com/python/cpython/blob/dcb68f47f74b0cc8a1896d4a4c5a6b83c0bbeeae/Modules/_xxsubinterpretersmodule.c#L1387 Do you think it'd make sense to go through the module to find and fix leaks? Or is this code in an early stage for such cleanup? As a side note, such leaks should be easily found by static analyzers such as Coverity (assuming it understands CPython allocation functions like PyMem_NEW), so it might make sense to check out its reports on the module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 16:32:31 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Wed, 13 Feb 2019 21:32:31 +0000 Subject: [issue17703] Trashcan mechanism segfault during interpreter finalization in Python 2.7.4 In-Reply-To: <1365774192.26.0.770170442284.issue17703@psf.upfronthosting.co.za> Message-ID: <1550093551.03.0.455949173318.issue17703@roundup.psfhosted.org> Jeroen Demeyer added the comment: See also https://bugs.python.org/issue35983 for another trashcan-related issue. ---------- nosy: +jdemeyer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 17:02:35 2019 From: report at bugs.python.org (Roundup Robot) Date: Wed, 13 Feb 2019 22:02:35 +0000 Subject: [issue20523] global .pdbrc on windows 7 not reachable out of the box In-Reply-To: <1391637453.5.0.977818995818.issue20523@psf.upfronthosting.co.za> Message-ID: <1550095355.99.0.427738096456.issue20523@roundup.psfhosted.org> Change by Roundup Robot : ---------- pull_requests: +11877 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 17:11:40 2019 From: report at bugs.python.org (Roundup Robot) Date: Wed, 13 Feb 2019 22:11:40 +0000 Subject: [issue20523] global .pdbrc on windows 7 not reachable out of the box In-Reply-To: <1391637453.5.0.977818995818.issue20523@psf.upfronthosting.co.za> Message-ID: <1550095900.13.0.031758673078.issue20523@roundup.psfhosted.org> Change by Roundup Robot : ---------- pull_requests: +11878 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 18:04:32 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Feb 2019 23:04:32 +0000 Subject: [issue22213] Make pyvenv style virtual environments easier to configure when embedding Python In-Reply-To: <1408275761.36.0.915361061447.issue22213@psf.upfronthosting.co.za> Message-ID: <1550099072.15.0.587753992836.issue22213@roundup.psfhosted.org> STINNER Victor added the comment: > It seems that the disagreement about the design is fundamentally a disagreement between a "quick, painful but complete fix" and "slow, careful improvements with a transition period". Both are valid approaches, and since Victor is putting actual effort in right now he gets to "win", but I do think we can afford to move faster. Technically, the API already exists and is exposed as a private API: * "_PyCoreConfig" structure * "_PyInitError _Py_InitializeFromConfig(const _PyCoreConfig *config)" function * "void _Py_FatalInitError(_PyInitError err)" function (should be called on failure) I'm not really sure of the benefit compared to the current initialization API using Py_xxx global configuration variables (ex: Py_IgnoreEnvironmentFlag) and Py_Initialize(). _PyCoreConfig basically exposed *all* input parameters used to initialize Python, much more than jsut global configuration variables and the few function that can be called before Py_Initialize(): https://docs.python.org/dev/c-api/init.html > Currently PEP 432 is the best description we have, and it looks like Victor has been heading in that direction too (deliberately? I don't know :) ). Well, it's a strange story. At the beginning, I had a very simple use case... it took me more or less one year to implement it :-) My use case was to add... a new -X utf8 command line option: * parsing the command line requires to decode bytes using an encoding * the encoding depends on the locale, environment variable and options on the command line * environment variables depend on the command line (-E option) If the utf8 mode is enabled (PEP 540), the encoding must be set to UTF-8, all configuration must be removed and the whole configuration (env vars, cmdline, etc.) must be read again from scratch :-) To be able to do that, I had to collect *every single* thing which has an impact on the Python initialization: all things that I moved into _PyCoreConfig. ... but I didn't want to break the backward compatibility, so I had to keep support for Py_xxx global configuration variables... and also the few initialization functions like Py_SetPath() or Py_SetStandardStreamEncoding(). Later it becomes very dark, my goal became very unclear and I looked at the PEP 432 :-) Well, I wanted to expose _PyCoreConfig somehow, so I looked at the PEP 432 to see how it can be exposed. > By necessity, it touches a lot of people's contributions to Python, but it also has the potential to seriously improve even more people's ability to _use_ Python (for example, I know an app that you all would recognize the name of who is working on embedding Python right now and would _love_ certain parts of this side of things to be improved). _PyCoreConfig "API" makes some things way simpler. Maybe it was already possible to do them previously but it was really hard, or maybe it was just not possible. If a _PyCoreConfig field is set: it has the priority over any other way to initialize the field. _PyCoreConfig has the highest prioririty. For example, _PyCoreConfig allows to completely ignore the code which computes sys.path (and related variables) by setting directly the "path configuration": * nmodule_search_path, module_search_paths: list of sys.path paths * executable: sys.executable */ * prefix: sys.prefix * base_prefix: sys.base_prefix * exec_prefix: sys.exec_prefix * base_exec_prefix sys.base_exec_prefix * (Windows only) dll_path: Windows DLL path The code which initializes these fields is really complex. Without _PyCoreConfig, it's hard to make sure that these fields are properly initialized as an embedder would like. > Nick, Victor, Eric, (others?) - are you interested in having a virtual whiteboard session to brainstorm how the "perfect" initialization looks? And probably a follow-up to brainstorm how to get there without breaking the world? I don't think we're going to get to be in the same room anytime before the language summit, and it would be awesome to have something concrete to discuss there. Sorry, I'm not sure of the API / structures, but when I discussed with Eric Snow at the latest sprint, we identified different steps in the Python initialization: * only use bytes (no encoding), no access to the filesystem (not needed at this point) * encoding defined, can use Unicode * use the filesystem * configuration converted as Python objects * Python is fully initialized -- Once I experimented to reorganize _PyCoreConfig and _PyMainInterpreterConfig to avoid redundancy: add a _PyPreConfig which contains only fields which are needed before _PyMainInterpreterConfig. With that change, _PyMainInterpreterConfig (and _PyPreConfig) *contained* _PyCoreConfig. But it the change became very large, I wasn't sure that it was a good idea, I abandonned my change. * https://github.com/python/cpython/pull/10575 * https://bugs.python.org/issue35266 * I have a more advanced version in this branch of my fork: https://github.com/vstinner/cpython/commits/pre_config_next -- Ok, something else. _PyCoreConfig (and _PyMainInterpreterConfig) contain memory allocated on the heap. Problem: Python initialization changes the memory allocator. Code using _PyCoreConfig requires some "tricks" to ensure that the memory is *freed* with the same allocator used to *allocate* memory. I created bpo-35265 "Internal C API: pass the memory allocator in a context" to pass a "context" to a lot of functions, context which contains the memory allocator but can contain more things later. The idea of "a context" came during the discussion about a new C API: stop to rely on any global variable or "shared state", but *explicitly* pass a context to all functions. With that, it becomes possible to imagine to have two interpreters running in the same threads "at the same time". Honestly, I'm not really sure that it's fully possible to implement this idea... Python has *so many* "shared state", like *everywhere*. It's really a giant project to move these shared states into structures and pass pointers to these structures. So again, I abandonned my experimental change: https://github.com/python/cpython/pull/10574 -- Memory allocator, context, different structures for configuration... it's really not an easy topic :-( There are so many constraints put into a single API! The conservation option at this point is to keep the API private. ... Maybe we can explain how to use the private API but very explicitly warn that this API is experimental and can be broken anytime... And I plan to break it, to avoid redundancy between core and main configuration for example. ... I hope that these explanations give you a better idea of the big picture and the challenges :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 18:21:20 2019 From: report at bugs.python.org (Brett Cannon) Date: Wed, 13 Feb 2019 23:21:20 +0000 Subject: [issue35887] Doc string for updating the frozen version of importlib in _bootstrap.py incorrect In-Reply-To: <1549071736.85.0.965218389814.issue35887@roundup.psfhosted.org> Message-ID: <1550100080.89.0.569898753928.issue35887@roundup.psfhosted.org> Brett Cannon added the comment: New changeset 1dc5cb9cb3447211069a7788208254b1cfa8ec98 by Brett Cannon (Nina Zakharenko) in branch 'master': bpo-35887: Add make regen-importlib step to importlib._bootstrap docstring (GH-11777) https://github.com/python/cpython/commit/1dc5cb9cb3447211069a7788208254b1cfa8ec98 ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 18:33:28 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 13 Feb 2019 23:33:28 +0000 Subject: [issue1054041] Python doesn't exit with proper resultcode on SIGINT Message-ID: <1550100808.63.0.374330093105.issue1054041@roundup.psfhosted.org> Change by Gregory P. Smith : ---------- versions: +Python 3.8 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 18:58:34 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 13 Feb 2019 23:58:34 +0000 Subject: [issue1054041] Python doesn't exit with proper resultcode on SIGINT Message-ID: <1550102314.79.0.855486376879.issue1054041@roundup.psfhosted.org> Gregory P. Smith added the comment: Taking a renewed look at this 8 years later... I agree, re-triggering the signal with the SIG_DFL handler would prevent us from doing the existing interpreter shutdown cleanup if we did it too early which would be a behavior change other than the exit value correction. So we should delay the re-signaling kill(getpid(), SIGINT) call until we've completed that and are about to exit anyways. The code has moved around a lot since i generated this patch on a 3.2-ish tree so it'll take me a while to untangle what would need to go where to create a PR. Instead of kill(getpid(), SIGINT) or raise(SIGINT), we could just checking the _UnhandledKeyboardInterrupt flag we return our exit valye adjusting it to be the one a calling shell may be expecting to indicate a SIGINT. That goes against the advice of https://www.cons.org/cracauer/sigint.html but is likely to work. A question that leads to is what _is_ the correct value. On Linux the magic 130 happens to be (SIGINT + 128). Triggering the libc or kernel supplied SIG_DFL handler as a final act avoids us ever needing to know what possible mechanisms to indicate this to the parent process are preferred on a platform. (if we know it is merely an exit value we could capture that in to a #define with a configure.ac check if the + 128 trick were deemed too magical despite being what everyone likely implements, standardized or not) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 19:02:17 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 14 Feb 2019 00:02:17 +0000 Subject: [issue1054041] Python doesn't exit with proper resultcode on SIGINT Message-ID: <1550102537.69.0.983803706686.issue1054041@roundup.psfhosted.org> Change by Gregory P. Smith : ---------- stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 19:06:50 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 14 Feb 2019 00:06:50 +0000 Subject: [issue1054041] Python doesn't exit with proper resultcode on SIGINT Message-ID: <1550102810.82.0.913551441428.issue1054041@roundup.psfhosted.org> STINNER Victor added the comment: > A question that leads to is what _is_ the correct value. What do you think of using a short test program (ex: uses raise(SIGINT)) in ./configure to get the "default exit code" to define a constant, and then use the constant for exit() in Python? I dislike the idea of raising signals in general. The exact behavior of signals depends too much on the OS, it's hard to get it right. But having a configurable exit code looks safe and simple enough. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 19:07:56 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Thu, 14 Feb 2019 00:07:56 +0000 Subject: [issue35899] '_is_sunder' function in 'enum' module fails on empty string In-Reply-To: <1549376859.01.0.998806898699.issue35899@roundup.psfhosted.org> Message-ID: <1550102876.93.0.152821196186.issue35899@roundup.psfhosted.org> Cheryl Sabella added the comment: I found this issue that Serhiy did on the devguide where he added {} around the placeholder: https://github.com/python/devguide/pull/444 I think that might be the correct way to do it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 19:09:08 2019 From: report at bugs.python.org (Steve Dower) Date: Thu, 14 Feb 2019 00:09:08 +0000 Subject: [issue22213] Make pyvenv style virtual environments easier to configure when embedding Python In-Reply-To: <1408275761.36.0.915361061447.issue22213@psf.upfronthosting.co.za> Message-ID: <1550102948.01.0.552595371281.issue22213@roundup.psfhosted.org> Steve Dower added the comment: Thanks, Victor, that's great information. > Memory allocator, context, different structures for configuration... it's really not an easy topic :-( There are so many constraints put into a single API! This is why I'm keen to design the ideal *user* API first (that is, write the examples of how you would use it) and then figure out how we can make it fit. It's kind of the opposite approach from what you've been doing to adapt the existing code to suit particular needs. For example, imagine instead of all the PySet*() functions followed by Py_Initialize() you could do this: PyObject *runtime = PyRuntime_Create(); /* optional calls */ PyRuntime_SetAllocators(runtime, &my_malloc, &my_realloc, &my_free); PyRuntime_SetHashSeed(runtime, 12345); /* sets this as the current runtime via a thread local */ auto old_runtime = PyRuntime_Activate(runtime); assert(old_runtime == NULL) /* pretend triple quoting works in C for a minute ;) */ const char *init = """ import os.path import sys sys.executable = argv0 sys.prefix = os.path.dirname(argv0) sys.path = [os.getcwd(), sys.prefix, os.path.join(sys.prefix, "Lib")] pyvenv = os.path.join(sys.prefix, "pyvenv.cfg") try: with open(pyvenv, "r", encoding="utf-8") as f: # *only* utf-8 support at this stage for line in f: if line.startswith("home"): sys.path.append(line.partition("=")[2].strip()) break except FileNotFoundError: pass if sys.platform == "win32": sys.stdout = open("CONOUT$", "w", encoding="utf-8") else: # no idea if this is right, but you get the idea sys.stdout = open("/dev/tty", "w", encoding="utf-8") """; PyObject *globals = PyDict_New(); /* only UTF-8 support at this stage */ PyDict_SetItemString(globals, "argv0", PyUnicode_FromString(argv[0])); PyRuntime_Initialize(runtime, init_code, globals); Py_DECREF(globals); /* now we've initialised, loading codecs will succeed if we can find them or fail if not, * so we'd have to do cleanup to avoid depending on them without the user being able to * avoid it... */ PyEval_EvalString("open('file.txt', 'w', encoding='gb18030').close()"); /* may as well reuse DECREF for consistency */ Py_DECREF(runtime); Maybe it's a terrible idea? Honestly I'd be inclined to do other big changes at the same time (make PyObject opaque and interface driven, for example). My point is that if the goal is to "move the existing internals around" then that's all we'll ever achieve. If we can say "the goal is to make this example work" then we'll be able to do much more. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 19:16:06 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 14 Feb 2019 00:16:06 +0000 Subject: [issue1054041] Python doesn't exit with proper resultcode on SIGINT Message-ID: <1550103366.2.0.527989608779.issue1054041@roundup.psfhosted.org> Gregory P. Smith added the comment: I expect that'll work as desired and avoids the re-raising of the signal. Unless told otherwise I assume this should be a POSIX specific platform behavior. ie: no return value alteration due to an uncaught KeyboardInterrupt on the Windows API build. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 19:38:19 2019 From: report at bugs.python.org (ADataGman) Date: Thu, 14 Feb 2019 00:38:19 +0000 Subject: [issue35927] Intra-package References Documentation Incomplete In-Reply-To: <1550032536.55.0.41841593392.issue35927@roundup.psfhosted.org> Message-ID: ADataGman added the comment: Terry, thank you for the detailed list of alternatives on how to approach this, that's helpful in how to tackle this issue in my current development. Nick, for the relative imports of relative imports I think the error message is fine. It makes sense. It doesn't necessarily give you a lot of hints on where to go next unfortunately, but it does explain why it doesn't work. For the absolute imports, a hint like, the module must be discoverable in sys.path or the like if you wanted to make this clearer. My biggest concern was just that the way the documentation is written for https://docs.python.org/3.6/tutorial/modules.html#intra-package-references . It implies that the code will run without any hint of needing to be either run from a higher level, or a work around used like Terry suggested. Now that I've spent a few days researching and reading more on my own, and with help from you and Terry, I understand what's happening and have options. But for others just reading the docs and not already familiar, it's not clear why the current example wouldn't work when run from the sibling level. I'd like to see the documentation for intra-package references updated to clearly state that the code is being run from a level above. "For example, if the module sound.filters.vocoder needs to use the echo module in the sound.effects package, it can use from sound.effects import echo." only works if you run it from the sound module. Which is fine! It's just not clear to a newb that it's being executed from the sound package rather than the filters package. Perhaps modify https://docs.python.org/3.6/tutorial/modules.html#packages to include a "sound.py" at the top level folder, and in the explanation for the intra-package reference, just mention that the example quoted above runs from that new file. If there is a optimal way to modify the path for adding in a sibling level package, please include that. Otherwise just clarify that the example relies on the code being run from something from another level up. On Tue, Feb 12, 2019 at 11:35 PM Terry J. Reedy wrote: > > Terry J. Reedy added the comment: > > AData> You log and output show that you problem is as described: package > 'sound' is in directory "C:/" and "C:/" is not is sys.path. Possible > remedies: > 1. Add "C:/" to sys.path at the top of each module that imports sound. > This is a nuisance. > 2. Move the sound package to > 'C:\\Users\\user\\AppData\\Local\\Programs\\Python\\Python37\\lib\\site-packages'. > This can also a nuisance. > 3. Add a file named 'C.pth' and containing "C:/" to the site-packages. > ('pth' abbreviates 'path'.) This makes C:/ an extension of site-packages. > But all the non-python stuff in C: likely makes this a bad idea. > 4 (3 improved). Add a directory such as "C:/pyprojects", make the contents > of the .pth file "C:/pyprojects", and move sound to pyprojects. > This is what I have done. When I install a new version of Python, I copy > the .pth file to the new site-packeges directory. Works great. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 20:01:36 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Thu, 14 Feb 2019 01:01:36 +0000 Subject: [issue35899] '_is_sunder' function in 'enum' module fails on empty string In-Reply-To: <1549376859.01.0.998806898699.issue35899@roundup.psfhosted.org> Message-ID: <1550106096.61.0.29792719772.issue35899@roundup.psfhosted.org> Change by Cheryl Sabella : ---------- Removed message: https://bugs.python.org/msg335483 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 20:01:54 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Thu, 14 Feb 2019 01:01:54 +0000 Subject: [issue35155] Clarify Protocol Handlers in urllib.request Docs In-Reply-To: <1541286673.86.0.788709270274.issue35155@psf.upfronthosting.co.za> Message-ID: <1550106114.49.0.500241108743.issue35155@roundup.psfhosted.org> Cheryl Sabella added the comment: I found this issue that Serhiy did on the devguide where he added {} around the placeholder: https://github.com/python/devguide/pull/444 I think that might be the correct way to do it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 20:24:38 2019 From: report at bugs.python.org (Eryk Sun) Date: Thu, 14 Feb 2019 01:24:38 +0000 Subject: [issue1054041] Python doesn't exit with proper resultcode on SIGINT Message-ID: <1550107478.91.0.181832796898.issue1054041@roundup.psfhosted.org> Eryk Sun added the comment: For Windows, the default console control handler calls ExitProcess(STATUS_CONTROL_C_EXIT). If CMD is waiting on an application that exits with STATUS_CONTROL_C_EXIT, it prints "^C" to indicate the process was killed by Ctrl+C. For example: >>> STATUS_CONTROL_C_EXIT = 0xC000013A - 2**32 >>> STATUS_CONTROL_C_EXIT -1073741510 >>> sys.exit(STATUS_CONTROL_C_EXIT) ^C C:\>echo %errorlevel% -1073741510 Note that switching to SIG_DFL with raise(SIGINT) does not invoke the default console control handler in Windows. It just invokes the default raise() behavior, which is to call _exit(3). This exit status value of 3 is arbitrary and meaningless. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 20:34:20 2019 From: report at bugs.python.org (Steve Dower) Date: Thu, 14 Feb 2019 01:34:20 +0000 Subject: [issue35920] Windows 10 ARM32 platform support In-Reply-To: <1549480377.04.0.927646454693.issue35920@roundup.psfhosted.org> Message-ID: <1550108060.57.0.359351978773.issue35920@roundup.psfhosted.org> Steve Dower added the comment: Issue35976 was broken out for the more mechanical changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 20:39:20 2019 From: report at bugs.python.org (Denton Liu) Date: Thu, 14 Feb 2019 01:39:20 +0000 Subject: [issue35155] Clarify Protocol Handlers in urllib.request Docs In-Reply-To: <1550106114.49.0.500241108743.issue35155@roundup.psfhosted.org> Message-ID: Denton Liu added the comment: I gave that a try but it seems like it just outputs the {} literally in the case of the method role. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 21:22:36 2019 From: report at bugs.python.org (Lisa Roach) Date: Thu, 14 Feb 2019 02:22:36 +0000 Subject: [issue35500] Align expected and actual calls on mock.assert_called_with error message In-Reply-To: <1544813146.35.0.788709270274.issue35500@psf.upfronthosting.co.za> Message-ID: <1550110956.58.0.995531635565.issue35500@roundup.psfhosted.org> Lisa Roach added the comment: New changeset 2bdd5858e3f89555c8de73a0f307d63536129dbd by Lisa Roach (Susan Su) in branch 'master': bpo-35500: align expected and actual calls on mock.assert_called_with error message. (GH-11804) https://github.com/python/cpython/commit/2bdd5858e3f89555c8de73a0f307d63536129dbd ---------- nosy: +lisroach _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 21:34:43 2019 From: report at bugs.python.org (Lisa Roach) Date: Thu, 14 Feb 2019 02:34:43 +0000 Subject: [issue21150] Add quick links table to argparse docs In-Reply-To: <1396558035.28.0.485991636726.issue21150@psf.upfronthosting.co.za> Message-ID: <1550111683.08.0.598658772856.issue21150@roundup.psfhosted.org> Lisa Roach added the comment: It looks like @louielu might not be around anymore to finish this PR? If there are no objections I'd like to give a new contributor @suhearsawho a shot at this. ---------- nosy: +lisroach _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 21:45:54 2019 From: report at bugs.python.org (Lisa Roach) Date: Thu, 14 Feb 2019 02:45:54 +0000 Subject: [issue35962] Slight error in words in [ 2.4.1. String and Bytes literals ] In-Reply-To: <1549879959.7.0.265215879488.issue35962@roundup.psfhosted.org> Message-ID: <1550112354.65.0.646560716817.issue35962@roundup.psfhosted.org> Lisa Roach added the comment: The updated line sounds good to me, please make a PR. ---------- nosy: +lisroach _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 23:51:19 2019 From: report at bugs.python.org (Lisa Roach) Date: Thu, 14 Feb 2019 04:51:19 +0000 Subject: [issue35132] python-gdb error: Python Exception Type does not have a target In-Reply-To: <1541068819.38.0.788709270274.issue35132@psf.upfronthosting.co.za> Message-ID: <1550119879.38.0.130546985989.issue35132@roundup.psfhosted.org> Change by Lisa Roach : ---------- keywords: +patch pull_requests: +11879 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 13 23:54:42 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 14 Feb 2019 04:54:42 +0000 Subject: [issue35155] Clarify Protocol Handlers in urllib.request Docs In-Reply-To: <1541286673.86.0.788709270274.issue35155@psf.upfronthosting.co.za> Message-ID: <1550120082.04.0.909692554091.issue35155@roundup.psfhosted.org> Terry J. Reedy added the comment: For file names, the result is in italics. Looking at https://devguide.python.org/exploring/, that seems to work well. Can we just use **? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 00:29:16 2019 From: report at bugs.python.org (Tim Burgess) Date: Thu, 14 Feb 2019 05:29:16 +0000 Subject: [issue29466] pickle does not serialize Exception __cause__ field In-Reply-To: <1486406196.69.0.481594976881.issue29466@psf.upfronthosting.co.za> Message-ID: <1550122156.39.0.853893891879.issue29466@roundup.psfhosted.org> Change by Tim Burgess : ---------- nosy: +tjb900 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 01:09:00 2019 From: report at bugs.python.org (Susan Su) Date: Thu, 14 Feb 2019 06:09:00 +0000 Subject: [issue21150] Add quick links table to argparse docs In-Reply-To: <1396558035.28.0.485991636726.issue21150@psf.upfronthosting.co.za> Message-ID: <1550124540.08.0.907316538988.issue21150@roundup.psfhosted.org> Susan Su added the comment: I'm available to start working on this bug. Please let me know if any suggestions, concerns or comments come up! Thank you. ---------- nosy: +suhearsawho _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 01:09:55 2019 From: report at bugs.python.org (Susan Su) Date: Thu, 14 Feb 2019 06:09:55 +0000 Subject: [issue33043] Add a 'Contributing to Docs' link at the bottom of docs.python.org In-Reply-To: <1520703028.47.0.467229070634.issue33043@psf.upfronthosting.co.za> Message-ID: <1550124595.98.0.522855580429.issue33043@roundup.psfhosted.org> Susan Su added the comment: I am available to start working on this bug. Please let me know if any issues, concerns, or suggestions come up! Thank you. ---------- nosy: +suhearsawho _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 01:09:55 2019 From: report at bugs.python.org (wangjiangqiang) Date: Thu, 14 Feb 2019 06:09:55 +0000 Subject: [issue35991] potential double free in Modules/_randommodule.c line 295 and line 317 Message-ID: <1550124595.27.0.553680989056.issue35991@roundup.psfhosted.org> Change by wangjiangqiang <767563655 at qq.com>: ---------- nosy: wjq-security priority: normal severity: normal status: open title: potential double free in Modules/_randommodule.c line 295 and line 317 type: security _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 01:14:12 2019 From: report at bugs.python.org (Caleb Donovick) Date: Thu, 14 Feb 2019 06:14:12 +0000 Subject: [issue35992] Metaclasses interfere with __class_getitem__ Message-ID: <1550124852.78.0.300044847884.issue35992@roundup.psfhosted.org> New submission from Caleb Donovick : OS: Debian testing python3 -VV: Python 3.7.2+ (default, Feb 2 2019, 14:31:48) [gcc 8.2.0] The following: ``` class Meta(type): pass class X(metaclass=Meta): def __class_getitem__(cls, key): return key X[10] ``` Results in ``` TypeError: 'Meta' object does not support indexing ``` However, PEP 560 specifically states that __class_getitem__ should be used as fall back for when a metaclass does not implement __getitem__. ---------- assignee: docs at python components: Documentation, Interpreter Core messages: 335497 nosy: Donovick, docs at python priority: normal severity: normal status: open title: Metaclasses interfere with __class_getitem__ type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 01:20:44 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 14 Feb 2019 06:20:44 +0000 Subject: [issue35991] potential double free in Modules/_randommodule.c line 295 and line 317 Message-ID: <1550125244.58.0.0376179706866.issue35991@roundup.psfhosted.org> New submission from Karthikeyan Singaravelan : Though random module doesn't receive frequent changes can you please add the relevant lines in the description or the relevant commit with the corresponding line number in the report with a description. On master with commit [0] line 295 calls PyMem_Free(key); and then calls goto Done where PyMem_Free(key); is again executed which I assume is the report. [0] https://github.com/python/cpython/blob/d73ac0eba992a33992210915739d73250bf6d38d/Modules/_randommodule.c#L295 ---------- nosy: +mark.dickinson, rhettinger, xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 01:21:26 2019 From: report at bugs.python.org (wangjiangqiang) Date: Thu, 14 Feb 2019 06:21:26 +0000 Subject: [issue35993] incorrect use of released memory in Python/pystate.c line 284 Message-ID: <1550125286.46.0.185634050351.issue35993@roundup.psfhosted.org> Change by wangjiangqiang <767563655 at qq.com>: ---------- nosy: wjq-security priority: normal severity: normal status: open title: incorrect use of released memory in Python/pystate.c line 284 type: security _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 01:23:18 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 14 Feb 2019 06:23:18 +0000 Subject: [issue35992] Metaclasses interfere with __class_getitem__ In-Reply-To: <1550124852.78.0.300044847884.issue35992@roundup.psfhosted.org> Message-ID: <1550125398.88.0.140430547687.issue35992@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 01:35:32 2019 From: report at bugs.python.org (wangjiangqiang) Date: Thu, 14 Feb 2019 06:35:32 +0000 Subject: [issue35991] potential double free in Modules/_randommodule.c line 295 and line 317 In-Reply-To: <1550125244.58.0.0376179706866.issue35991@roundup.psfhosted.org> Message-ID: <1550126132.84.0.590881205827.issue35991@roundup.psfhosted.org> wangjiangqiang <767563655 at qq.com> added the comment: line 295 calls PyMem_Free(key),then "key" was freed again in line 317 which causes the bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 01:37:55 2019 From: report at bugs.python.org (Brennan D Baraban) Date: Thu, 14 Feb 2019 06:37:55 +0000 Subject: [issue35899] '_is_sunder' function in 'enum' module fails on empty string In-Reply-To: <1549376859.01.0.998806898699.issue35899@roundup.psfhosted.org> Message-ID: <1550126275.03.0.208861548663.issue35899@roundup.psfhosted.org> Brennan D Baraban <375 at holbertonschool.com> added the comment: Thank you, St?phane. I submitted a change request to your PR just now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 01:38:01 2019 From: report at bugs.python.org (wangjiangqiang) Date: Thu, 14 Feb 2019 06:38:01 +0000 Subject: [issue35993] incorrect use of released memory in Python/pystate.c line 284 Message-ID: <1550126281.35.0.272027846904.issue35993@roundup.psfhosted.org> New submission from wangjiangqiang <767563655 at qq.com>: the code is trying to visit a link list in a loop, it tries to visit the next node in line 284 "interp = interp->next" while the current node is freed in line 296 "PyMem_RawFree(interp);" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 02:02:30 2019 From: report at bugs.python.org (Zackery Spytz) Date: Thu, 14 Feb 2019 07:02:30 +0000 Subject: [issue35991] potential double free in Modules/_randommodule.c line 295 and line 317 In-Reply-To: <1550125244.58.0.0376179706866.issue35991@roundup.psfhosted.org> Message-ID: <1550127750.03.0.0842834709414.issue35991@roundup.psfhosted.org> Change by Zackery Spytz : ---------- keywords: +patch pull_requests: +11880 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 02:05:30 2019 From: report at bugs.python.org (Brennan D Baraban) Date: Thu, 14 Feb 2019 07:05:30 +0000 Subject: [issue23460] Decimals do not obey ':g' exponential notation formatting rules In-Reply-To: <1423847721.13.0.666007782647.issue23460@psf.upfronthosting.co.za> Message-ID: <1550127930.13.0.151356663257.issue23460@roundup.psfhosted.org> Change by Brennan D Baraban <375 at holbertonschool.com>: ---------- pull_requests: +11881 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 02:25:15 2019 From: report at bugs.python.org (Brennan D Baraban) Date: Thu, 14 Feb 2019 07:25:15 +0000 Subject: [issue23460] Decimals do not obey ':g' exponential notation formatting rules In-Reply-To: <1423847721.13.0.666007782647.issue23460@psf.upfronthosting.co.za> Message-ID: <1550129115.89.0.980035664289.issue23460@roundup.psfhosted.org> Brennan D Baraban <375 at holbertonschool.com> added the comment: I submitted a PR just now. I only pushed the change to `string.rst`, as per Stefan Krah's suggestion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 02:32:12 2019 From: report at bugs.python.org (Denton Liu) Date: Thu, 14 Feb 2019 07:32:12 +0000 Subject: [issue35155] Clarify Protocol Handlers in urllib.request Docs In-Reply-To: <1541286673.86.0.788709270274.issue35155@psf.upfronthosting.co.za> Message-ID: <1550129532.78.0.215922254189.issue35155@roundup.psfhosted.org> Denton Liu added the comment: Unfortunately, inline markup can't be combined with roles. Using asterisks, it shows up as `**_open()` and using braces, `{}_open`. I'm not sure how this works but it _might_ be possible to change how :meth: role is interpreted but I believe that's outside the scope of this change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 02:32:35 2019 From: report at bugs.python.org (Peixing Xin) Date: Thu, 14 Feb 2019 07:32:35 +0000 Subject: [issue35994] In WalkTests of test_os.py, sub2_tree missed the dir "SUB21" if symlink can't be supported. Message-ID: <1550129555.65.0.532598908006.issue35994@roundup.psfhosted.org> New submission from Peixing Xin : Looking into the setUp method of WalkTests class in test_os.py, sub2_tree missed "SUB21" in its directory list if support.can_symlink() returns False. ---------- components: Tests messages: 335505 nosy: pxinwr priority: normal severity: normal status: open title: In WalkTests of test_os.py, sub2_tree missed the dir "SUB21" if symlink can't be supported. type: behavior versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 02:43:21 2019 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 14 Feb 2019 07:43:21 +0000 Subject: [issue35991] potential double free in Modules/_randommodule.c line 295 and line 317 In-Reply-To: <1550125244.58.0.0376179706866.issue35991@roundup.psfhosted.org> Message-ID: <1550130201.13.0.83069666402.issue35991@roundup.psfhosted.org> Benjamin Peterson added the comment: New changeset bb3c05d7efca8d23bf39bc2640297ba2598899f3 by Benjamin Peterson (Zackery Spytz) in branch 'master': closes bpo-35991: Fix a potential double free in Modules/_randommodule.c. (GH-11849) https://github.com/python/cpython/commit/bb3c05d7efca8d23bf39bc2640297ba2598899f3 ---------- nosy: +benjamin.peterson resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 02:43:39 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 14 Feb 2019 07:43:39 +0000 Subject: [issue35991] potential double free in Modules/_randommodule.c line 295 and line 317 In-Reply-To: <1550125244.58.0.0376179706866.issue35991@roundup.psfhosted.org> Message-ID: <1550130219.46.0.947658749858.issue35991@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11883 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 02:44:49 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Thu, 14 Feb 2019 07:44:49 +0000 Subject: [issue35993] incorrect use of released memory in Python/pystate.c line 284 In-Reply-To: <1550126281.35.0.272027846904.issue35993@roundup.psfhosted.org> Message-ID: <1550130289.26.0.652435036559.issue35993@roundup.psfhosted.org> Change by St?phane Wirtel : ---------- assignee: -> matrixise nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 03:02:15 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 14 Feb 2019 08:02:15 +0000 Subject: [issue35991] potential double free in Modules/_randommodule.c line 295 and line 317 In-Reply-To: <1550125244.58.0.0376179706866.issue35991@roundup.psfhosted.org> Message-ID: <1550131335.24.0.414614847039.issue35991@roundup.psfhosted.org> miss-islington added the comment: New changeset e20893596f4ecbca90be6caecbf8c22c9629376d by Miss Islington (bot) in branch '3.7': closes bpo-35991: Fix a potential double free in Modules/_randommodule.c. (GH-11849) https://github.com/python/cpython/commit/e20893596f4ecbca90be6caecbf8c22c9629376d ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 03:03:18 2019 From: report at bugs.python.org (Berry Schoenmakers) Date: Thu, 14 Feb 2019 08:03:18 +0000 Subject: [issue35606] Add prod() function to the math module In-Reply-To: <1546025352.75.0.868813504694.issue35606@roundup.psfhosted.org> Message-ID: <1550131398.22.0.895039104962.issue35606@roundup.psfhosted.org> Berry Schoenmakers added the comment: Nice to see the arrival of the prod() function. Just as for the built-in pow(x, y[, z]) function it would be very useful to have an optional argument z for computing products modulo z. Typical use case in cryptography would be: prod((pow(x, y, z) for x, y in zip(g, s)), z) to compute the product of all (potentially many) g[i]**s[i]'s modulo z. And, just as with the use of pow(), the intermediate values for prod() may in general grow quickly, hence modular reduction is essential to limit time and space usage. ---------- nosy: +lschoe _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 03:16:01 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Thu, 14 Feb 2019 08:16:01 +0000 Subject: [issue35993] incorrect use of released memory in Python/pystate.c line 284 In-Reply-To: <1550126281.35.0.272027846904.issue35993@roundup.psfhosted.org> Message-ID: <1550132161.48.0.344185025786.issue35993@roundup.psfhosted.org> Change by St?phane Wirtel : ---------- keywords: +patch pull_requests: +11884 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 03:16:51 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Thu, 14 Feb 2019 08:16:51 +0000 Subject: [issue35993] incorrect use of released memory in Python/pystate.c line 284 In-Reply-To: <1550126281.35.0.272027846904.issue35993@roundup.psfhosted.org> Message-ID: <1550132211.2.0.641032346213.issue35993@roundup.psfhosted.org> St?phane Wirtel added the comment: What do you think of this solution? ---------- nosy: +vstinner stage: patch review -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 03:22:28 2019 From: report at bugs.python.org (Peixing Xin) Date: Thu, 14 Feb 2019 08:22:28 +0000 Subject: [issue35994] In WalkTests of test_os.py, sub2_tree missed the dir "SUB21" if symlink can't be supported. In-Reply-To: <1550129555.65.0.532598908006.issue35994@roundup.psfhosted.org> Message-ID: <1550132548.99.0.84986232264.issue35994@roundup.psfhosted.org> Change by Peixing Xin : ---------- keywords: +patch pull_requests: +11885 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 03:26:29 2019 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 14 Feb 2019 08:26:29 +0000 Subject: [issue35606] Add prod() function to the math module In-Reply-To: <1546025352.75.0.868813504694.issue35606@roundup.psfhosted.org> Message-ID: <1550132789.17.0.373603831957.issue35606@roundup.psfhosted.org> Mark Dickinson added the comment: @Berry: I'd suggest opening a separate issue for that discussion; this issue's already closed, so it's likely that few people will notice your message. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 03:45:46 2019 From: report at bugs.python.org (lidayan) Date: Thu, 14 Feb 2019 08:45:46 +0000 Subject: [issue35995] logging.handlers.SMTPHandler Message-ID: <1550133946.82.0.233218933413.issue35995@roundup.psfhosted.org> New submission from lidayan <840286247 at qq.com>: SSL encrypted socket on SMTPHandler error Traceback (most recent call last): File "/usr/local/Cellar/python/3.7.2_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/logging/handlers.py", line 1008, in emit smtp = smtplib.SMTP(self.mailhost, port, timeout=self.timeout) File "/usr/local/Cellar/python/3.7.2_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/smtplib.py", line 251, in __init__ (code, msg) = self.connect(host, port) File "/usr/local/Cellar/python/3.7.2_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/smtplib.py", line 338, in connect (code, msg) = self.getreply() File "/usr/local/Cellar/python/3.7.2_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/smtplib.py", line 391, in getreply + str(e)) smtplib.SMTPServerDisconnected: Connection unexpectedly closed: timed out ---------- components: Library (Lib) messages: 335511 nosy: lidayan priority: normal severity: normal status: open title: logging.handlers.SMTPHandler versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 03:46:58 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Thu, 14 Feb 2019 08:46:58 +0000 Subject: [issue35995] logging.handlers.SMTPHandler In-Reply-To: <1550133946.82.0.233218933413.issue35995@roundup.psfhosted.org> Message-ID: <1550134018.65.0.240962310466.issue35995@roundup.psfhosted.org> St?phane Wirtel added the comment: You have a timeout, maybe you have an issue with your SMTP server. But in this case, it's not an issue with Python. ---------- nosy: +matrixise resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 03:47:46 2019 From: report at bugs.python.org (lidayan) Date: Thu, 14 Feb 2019 08:47:46 +0000 Subject: [issue35995] use SSL encrypted socket on logging.handlers.SMTPHandler In-Reply-To: <1550133946.82.0.233218933413.issue35995@roundup.psfhosted.org> Message-ID: <1550134066.56.0.0410849173273.issue35995@roundup.psfhosted.org> Change by lidayan <840286247 at qq.com>: ---------- title: logging.handlers.SMTPHandler -> use SSL encrypted socket on logging.handlers.SMTPHandler _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 04:06:42 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Thu, 14 Feb 2019 09:06:42 +0000 Subject: [issue35983] tp_dealloc trashcan shouldn't be called for subclasses In-Reply-To: <1550055751.42.0.717332216151.issue35983@roundup.psfhosted.org> Message-ID: <1550135202.89.0.332354146983.issue35983@roundup.psfhosted.org> Jeroen Demeyer added the comment: > Jeroen, could you share your example? I am learning the C-API of Python and this example could be interesting. Either use the Cython code I posted above or run the testcase I added in PR 11841. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 04:27:13 2019 From: report at bugs.python.org (Zackery Spytz) Date: Thu, 14 Feb 2019 09:27:13 +0000 Subject: [issue35991] potential double free in Modules/_randommodule.c line 295 and line 317 In-Reply-To: <1550125244.58.0.0376179706866.issue35991@roundup.psfhosted.org> Message-ID: <1550136433.93.0.0780989766249.issue35991@roundup.psfhosted.org> Change by Zackery Spytz : ---------- components: +Extension Modules nosy: +ZackerySpytz versions: +Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 04:57:04 2019 From: report at bugs.python.org (Hinko Kocevar) Date: Thu, 14 Feb 2019 09:57:04 +0000 Subject: [issue35988] Python interpreter segfault In-Reply-To: <1550069169.56.0.128755825216.issue35988@roundup.psfhosted.org> Message-ID: <1550138224.27.0.0777996221744.issue35988@roundup.psfhosted.org> Hinko Kocevar added the comment: Thank you for the valuable information about the OOM beast.. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 05:09:42 2019 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 14 Feb 2019 10:09:42 +0000 Subject: [issue15753] No-argument super in method with variable arguments raises SystemError In-Reply-To: <1345549960.82.0.102703520127.issue15753@psf.upfronthosting.co.za> Message-ID: <1550138982.76.0.163839221278.issue15753@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 05:10:51 2019 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 14 Feb 2019 10:10:51 +0000 Subject: [issue20523] global .pdbrc on windows 7 not reachable out of the box In-Reply-To: <1391637453.5.0.977818995818.issue20523@psf.upfronthosting.co.za> Message-ID: <1550139051.09.0.479178724909.issue20523@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 05:22:44 2019 From: report at bugs.python.org (lidayan) Date: Thu, 14 Feb 2019 10:22:44 +0000 Subject: [issue35995] use SSL encrypted socket on logging.handlers.SMTPHandler In-Reply-To: <1550133946.82.0.233218933413.issue35995@roundup.psfhosted.org> Message-ID: <1550139764.49.0.718821582749.issue35995@roundup.psfhosted.org> Change by lidayan <840286247 at qq.com>: ---------- pull_requests: +11886 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 05:35:06 2019 From: report at bugs.python.org (Berry Schoenmakers) Date: Thu, 14 Feb 2019 10:35:06 +0000 Subject: [issue35606] Add prod() function to the math module In-Reply-To: <1546025352.75.0.868813504694.issue35606@roundup.psfhosted.org> Message-ID: <1550140506.62.0.135421555931.issue35606@roundup.psfhosted.org> Berry Schoenmakers added the comment: Thanks for the suggestion, Mark. I was not so sure, and the Nosy List for this issue is already quite extensive, so considered you guys as an appropriate audience for my first comment on this platform. But I will also look into opening a separate issue later today. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 05:42:17 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Thu, 14 Feb 2019 10:42:17 +0000 Subject: [issue20523] global .pdbrc on windows 7 not reachable out of the box In-Reply-To: <1391637453.5.0.977818995818.issue20523@psf.upfronthosting.co.za> Message-ID: <1550140937.13.0.759296265207.issue20523@roundup.psfhosted.org> Change by St?phane Wirtel : ---------- pull_requests: +11887 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 05:53:06 2019 From: report at bugs.python.org (Jakub Wilk) Date: Thu, 14 Feb 2019 10:53:06 +0000 Subject: [issue1054041] Python doesn't exit with proper resultcode on SIGINT Message-ID: <1550141586.89.0.578464702031.issue1054041@roundup.psfhosted.org> Jakub Wilk added the comment: This issue was reported because with the current behavior, "the script will not properly exit on C-c". Exiting with code 128+SIGINT will not fix this. Please re-raise the signal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 06:01:35 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 14 Feb 2019 11:01:35 +0000 Subject: [issue1054041] Python doesn't exit with proper resultcode on SIGINT Message-ID: <1550142095.49.0.555632081593.issue1054041@roundup.psfhosted.org> Antoine Pitrou added the comment: I'm assuming the calling shell uses waitpid() and then WIFSIGNALED()? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 06:17:21 2019 From: report at bugs.python.org (lidayan) Date: Thu, 14 Feb 2019 11:17:21 +0000 Subject: [issue35995] use SSL encrypted socket on logging.handlers.SMTPHandler In-Reply-To: <1550133946.82.0.233218933413.issue35995@roundup.psfhosted.org> Message-ID: <1550143041.22.0.815181281354.issue35995@roundup.psfhosted.org> Change by lidayan <840286247 at qq.com>: ---------- pull_requests: +11888 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 06:39:48 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 14 Feb 2019 11:39:48 +0000 Subject: [issue35132] python-gdb error: Python Exception Type does not have a target In-Reply-To: <1541068819.38.0.788709270274.issue35132@psf.upfronthosting.co.za> Message-ID: <1550144388.11.0.973138767141.issue35132@roundup.psfhosted.org> STINNER Victor added the comment: > Distro: Linux Mint 18.2 Sonya Hum, Dylan: what is your gdb version? On Fedora 29 with gdb 8.2-6.fc29, it seems like .target() is useless: $ gdb ./python GNU gdb (GDB) Fedora 8.2-6.fc29 ... (gdb) python print([field.name for field in gdb.lookup_type('PyUnicodeObject').target().fields()]) ['_base', 'data'] (gdb) python print([field.name for field in gdb.lookup_type('PyUnicodeObject').fields()]) ['_base', 'data'] I tested on a Python compiled manually from source, I ran my test in the directory of Python source code. I also tested on /usr/bin/python3 (system Python), same behavior. ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 06:42:40 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 14 Feb 2019 11:42:40 +0000 Subject: [issue35132] python-gdb error: Python Exception Type does not have a target In-Reply-To: <1541068819.38.0.788709270274.issue35132@psf.upfronthosting.co.za> Message-ID: <1550144560.18.0.109299940711.issue35132@roundup.psfhosted.org> STINNER Victor added the comment: Python 3.6 no longer accept bugfixes, only security fixes: http://devguide.python.org/#status-of-python-branches You can try faulthandler has a workaround. For example, install faulthandler signal handler using faulthandler.register(signal.SIGUSR1) and then send a SIGUSR1 signal to the blocked process. You might want to write the output into a file if you don't have access the program stdout: use the 'file' parameter of faulthandler.register(). See also faulthandler.dump_traceback_later() to use a timeout. https://docs.python.org/dev/library/faulthandler.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 06:51:09 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Thu, 14 Feb 2019 11:51:09 +0000 Subject: [issue35995] use SSL encrypted socket on logging.handlers.SMTPHandler In-Reply-To: <1550133946.82.0.233218933413.issue35995@roundup.psfhosted.org> Message-ID: <1550145069.72.0.394591527788.issue35995@roundup.psfhosted.org> Emmanuel Arias added the comment: hmmm do you have some code to reproduce it? ---------- nosy: +eamanu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 06:52:20 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Thu, 14 Feb 2019 11:52:20 +0000 Subject: [issue33043] Add a 'Contributing to Docs' link at the bottom of docs.python.org In-Reply-To: <1520703028.47.0.467229070634.issue33043@psf.upfronthosting.co.za> Message-ID: <1550145140.04.0.784464250677.issue33043@roundup.psfhosted.org> Change by Emmanuel Arias : ---------- nosy: +eamanu type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 06:56:42 2019 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 14 Feb 2019 11:56:42 +0000 Subject: [issue35992] Metaclasses interfere with __class_getitem__ In-Reply-To: <1550124852.78.0.300044847884.issue35992@roundup.psfhosted.org> Message-ID: <1550145402.97.0.827184791239.issue35992@roundup.psfhosted.org> Change by Ivan Levkivskyi : ---------- keywords: +patch pull_requests: +11889 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 06:57:56 2019 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 14 Feb 2019 11:57:56 +0000 Subject: [issue35992] Metaclasses interfere with __class_getitem__ In-Reply-To: <1550124852.78.0.300044847884.issue35992@roundup.psfhosted.org> Message-ID: <1550145476.97.0.167835193378.issue35992@roundup.psfhosted.org> Ivan Levkivskyi added the comment: Yes, I think this is a bug. Created a PR with a possible simple fix. ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 07:10:24 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Thu, 14 Feb 2019 12:10:24 +0000 Subject: [issue35995] use SSL encrypted socket on logging.handlers.SMTPHandler In-Reply-To: <1550133946.82.0.233218933413.issue35995@roundup.psfhosted.org> Message-ID: <1550146224.52.0.104325271167.issue35995@roundup.psfhosted.org> St?phane Wirtel added the comment: I re-open this issue because after the change of the subject, maybe there is an issue with the code of logging.handler.SMTPHandler + TLS. ---------- resolution: rejected -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 07:20:27 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Thu, 14 Feb 2019 12:20:27 +0000 Subject: [issue35995] use SSL encrypted socket on logging.handlers.SMTPHandler In-Reply-To: <1550133946.82.0.233218933413.issue35995@roundup.psfhosted.org> Message-ID: <1550146827.21.0.526339970748.issue35995@roundup.psfhosted.org> St?phane Wirtel added the comment: @lidayan I have checked the code of your PR, and I think there is an issue with your code. 1. When you specify the secure flag to the SMTPHandler, it's because you will start the TLS connection if the SMTP server supports the STARTTLS. Firstly in plaintext mode and if STARTTLS is supported then we move to the TLS encryption. 2. If you use SSL + SMTP, it's not the same behavior because you support that your SMTP server will support a socket + ssl. For my part, I suggest you the creation of a SMTPSSLHandler and use the SMTP_SSL class. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 07:22:44 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 14 Feb 2019 12:22:44 +0000 Subject: [issue35995] use SSL encrypted socket on logging.handlers.SMTPHandler In-Reply-To: <1550133946.82.0.233218933413.issue35995@roundup.psfhosted.org> Message-ID: <1550146964.76.0.0617129617769.issue35995@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 07:26:24 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Thu, 14 Feb 2019 12:26:24 +0000 Subject: [issue35995] use SSL encrypted socket on logging.handlers.SMTPHandler In-Reply-To: <1550133946.82.0.233218933413.issue35995@roundup.psfhosted.org> Message-ID: <1550147184.8.0.689462905309.issue35995@roundup.psfhosted.org> St?phane Wirtel added the comment: Here is my suggestion class SMTPSSLHander(SMTPHandler): def emit(self, record): """ Emit a record. Format the record and send it to the specified addressees. """ try: import smtplib from email.message import EmailMessage import email.utils port = self.mailport if not port: port = smtplib.SMTP_SSL_PORT keyfile = self.secure[0] if len(self.secure) > 0 else None certfile = self.secure[1] if len(self.secure) > 1 else None smtp = smtplib.SMTP_SSL(self.mailhost, port, timeout=self.timeout, keyfile=keyfile, certfile=certfile) if self.username: smtp.login(self.username, self.password) msg = EmailMessage() msg['From'] = self.fromaddr msg['To'] = ','.join(self.toaddrs) msg['Subject'] = self.getSubject(record) msg['Date'] = email.utils.localtime() msg.set_content(self.format(record)) smtp.send_message(msg) smtp.quit() except Exception: self.handleError(record) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 07:28:04 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Thu, 14 Feb 2019 12:28:04 +0000 Subject: [issue35995] use SSL encrypted socket on logging.handlers.SMTPHandler In-Reply-To: <1550133946.82.0.233218933413.issue35995@roundup.psfhosted.org> Message-ID: <1550147284.38.0.0745622677641.issue35995@roundup.psfhosted.org> St?phane Wirtel added the comment: I propose to create a SMTPSSLHandler class and submit a PR. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 07:28:55 2019 From: report at bugs.python.org (Magnien Sebastien) Date: Thu, 14 Feb 2019 12:28:55 +0000 Subject: [issue35962] Slight error in words in [ 2.4.1. String and Bytes literals ] In-Reply-To: <1549879959.7.0.265215879488.issue35962@roundup.psfhosted.org> Message-ID: <1550147335.27.0.667951636139.issue35962@roundup.psfhosted.org> Magnien Sebastien added the comment: I'm all up for it; however I only ever worked on small solo projects. I don't really know where to start. Must I clone the whole python repo, or is there maybe a doc repo? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 07:35:39 2019 From: report at bugs.python.org (Julien Palard) Date: Thu, 14 Feb 2019 12:35:39 +0000 Subject: [issue35995] use SSL encrypted socket on logging.handlers.SMTPHandler In-Reply-To: <1550133946.82.0.233218933413.issue35995@roundup.psfhosted.org> Message-ID: <1550147739.22.0.462771763366.issue35995@roundup.psfhosted.org> Julien Palard added the comment: lidayan If I understand correctly, you're trying to connect to an SMTP server that does *not* support STARTTLS, only implicit TLS on port 465? ---------- nosy: +mdk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 07:43:20 2019 From: report at bugs.python.org (Julien Palard) Date: Thu, 14 Feb 2019 12:43:20 +0000 Subject: [issue35995] use SSL encrypted socket on logging.handlers.SMTPHandler In-Reply-To: <1550133946.82.0.233218933413.issue35995@roundup.psfhosted.org> Message-ID: <1550148200.79.0.0795629432535.issue35995@roundup.psfhosted.org> Julien Palard added the comment: @lidayan, if you're trying implicit TLS, have you tried giving a username an an empty tuple to the secure parameter? It looks like the empty tuple means "implicit TLS", see the docstring https://github.com/python/cpython/blob/7fea5ad9f081247927bc851605f3a6269cbcd84d/Lib/logging/handlers.py#L959 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 08:11:13 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Thu, 14 Feb 2019 13:11:13 +0000 Subject: [issue35962] Slight error in words in [ 2.4.1. String and Bytes literals ] In-Reply-To: <1549879959.7.0.265215879488.issue35962@roundup.psfhosted.org> Message-ID: <1550149873.7.0.708632699666.issue35962@roundup.psfhosted.org> R?mi Lapeyre added the comment: Hi Magnien, if you have already used Git, everything should be familiar. You have to clone the whole project, but the documentation leaves in the `Doc` folder. There is a lot of information that you can get at https://devguide.python.org/documenting/ If you get lost, please open the PR and tag me in the discussion, I will try and help you. ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 08:12:38 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Thu, 14 Feb 2019 13:12:38 +0000 Subject: [issue35962] Slight error in words in [ 2.4.1. String and Bytes literals ] In-Reply-To: <1549879959.7.0.265215879488.issue35962@roundup.psfhosted.org> Message-ID: <1550149958.74.0.6092490512.issue35962@roundup.psfhosted.org> R?mi Lapeyre added the comment: You will find the line you want to change in `Doc/reference/lexical_analysis.rst` ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 08:28:18 2019 From: report at bugs.python.org (Julien Palard) Date: Thu, 14 Feb 2019 13:28:18 +0000 Subject: [issue35995] use SSL encrypted socket on logging.handlers.SMTPHandler In-Reply-To: <1550133946.82.0.233218933413.issue35995@roundup.psfhosted.org> Message-ID: <1550150898.96.0.301422908375.issue35995@roundup.psfhosted.org> Julien Palard added the comment: lidayan (Ignore my latest comment I was reading your implementation, not the actual one...). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 08:28:51 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Thu, 14 Feb 2019 13:28:51 +0000 Subject: [issue35993] incorrect use of released memory in Python/pystate.c line 284 In-Reply-To: <1550126281.35.0.272027846904.issue35993@roundup.psfhosted.org> Message-ID: <1550150931.53.0.0591958757463.issue35993@roundup.psfhosted.org> Change by Emmanuel Arias : ---------- nosy: +eamanu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 08:46:32 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 14 Feb 2019 13:46:32 +0000 Subject: [issue35934] Add socket.create_server() utility function In-Reply-To: <1549566902.79.0.677687282333.issue35934@roundup.psfhosted.org> Message-ID: <1550151992.73.0.484457172516.issue35934@roundup.psfhosted.org> Change by STINNER Victor : ---------- title: Add socket.bind_socket() utility function -> Add socket.create_server() utility function _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 08:58:54 2019 From: report at bugs.python.org (SilentGhost) Date: Thu, 14 Feb 2019 13:58:54 +0000 Subject: [issue35962] Slight error in words in [ 2.4.1. String and Bytes literals ] In-Reply-To: <1549879959.7.0.265215879488.issue35962@roundup.psfhosted.org> Message-ID: <1550152734.48.0.748093167264.issue35962@roundup.psfhosted.org> SilentGhost added the comment: I don't think that's what the sentence say at all. It says, that a backslash can be used to escape a newline character (not "n"). This refers only to triple-quoted literals and is described in the first row of the table of escape sequences below. ---------- nosy: +SilentGhost -remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 08:59:33 2019 From: report at bugs.python.org (SilentGhost) Date: Thu, 14 Feb 2019 13:59:33 +0000 Subject: [issue35962] Slight error in words in [ 2.4.1. String and Bytes literals ] In-Reply-To: <1549879959.7.0.265215879488.issue35962@roundup.psfhosted.org> Message-ID: <1550152773.67.0.118061458449.issue35962@roundup.psfhosted.org> Change by SilentGhost : ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 09:20:10 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Thu, 14 Feb 2019 14:20:10 +0000 Subject: [issue35190] collections.abc.Sequence cannot be used to test whether a class provides a particular interface (doc issue) In-Reply-To: <1541688086.42.0.788709270274.issue35190@psf.upfronthosting.co.za> Message-ID: <1550154010.45.0.926713960438.issue35190@roundup.psfhosted.org> Cheryl Sabella added the comment: The previous comment is a self-reference. I believe the intention was to mark this as a duplicate of #17561. ---------- nosy: +cheryl.sabella _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 09:20:33 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Thu, 14 Feb 2019 14:20:33 +0000 Subject: [issue35190] collections.abc.Sequence cannot be used to test whether a class provides a particular interface (doc issue) In-Reply-To: <1541688086.42.0.788709270274.issue35190@psf.upfronthosting.co.za> Message-ID: <1550154033.91.0.0923406353606.issue35190@roundup.psfhosted.org> Change by Cheryl Sabella : ---------- Removed message: https://bugs.python.org/msg335533 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 09:20:39 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Thu, 14 Feb 2019 14:20:39 +0000 Subject: [issue35934] Add socket.create_server() utility function In-Reply-To: <1549566902.79.0.677687282333.issue35934@roundup.psfhosted.org> Message-ID: <1550154039.0.0.0854957066019.issue35934@roundup.psfhosted.org> Cheryl Sabella added the comment: The previous comment is a self-reference. I believe the intention was to mark this as a duplicate of #17561. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 09:39:51 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 14 Feb 2019 14:39:51 +0000 Subject: [issue35934] Add socket.create_server() utility function In-Reply-To: <1549566902.79.0.677687282333.issue35934@roundup.psfhosted.org> Message-ID: <1550155191.5.0.8406031972.issue35934@roundup.psfhosted.org> Giampaolo Rodola' added the comment: Correct. Sorry for the typo. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 11:05:46 2019 From: report at bugs.python.org (Paul Ganssle) Date: Thu, 14 Feb 2019 16:05:46 +0000 Subject: [issue32417] fromutc does not respect datetime subclasses In-Reply-To: <1514052939.19.0.213398074469.issue32417@psf.upfronthosting.co.za> Message-ID: <1550160346.72.0.491986788902.issue32417@roundup.psfhosted.org> Change by Paul Ganssle : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 11:26:25 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 14 Feb 2019 16:26:25 +0000 Subject: [issue35190] collections.abc.Sequence cannot be used to test whether a class provides a particular interface (doc issue) In-Reply-To: <1541688086.42.0.788709270274.issue35190@psf.upfronthosting.co.za> Message-ID: <1550161585.58.0.461962533128.issue35190@roundup.psfhosted.org> Josh Rosenberg added the comment: Wait, why should #25737 be closed? This bug is a docs issue; collections.abc shouldn't claim that all the ABCs do duck-typing checks since Sequence doesn't. But #25737 is specific: array.array *should* be registered as a Sequence, but isn't; that requires a code fix (to make array perform the registration), not a doc fix. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 11:29:33 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 14 Feb 2019 16:29:33 +0000 Subject: [issue25737] array is not a Sequence In-Reply-To: <1448537649.86.0.885493348949.issue25737@psf.upfronthosting.co.za> Message-ID: <1550161773.61.0.851562821201.issue25737@roundup.psfhosted.org> Josh Rosenberg added the comment: This should not be closed as a duplicate. Yes, array.array isn't automatically a Sequence, but since it isn't, the array module should be modified to explicitly do the equivalent of: import _collections_abc _collections_abc.Sequence.register(array) so it's properly registered manually. ---------- nosy: +josh.r resolution: duplicate -> status: closed -> open superseder: issubclass without registration only works for "one-trick pony" collections ABCs. -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 11:29:37 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 14 Feb 2019 16:29:37 +0000 Subject: [issue25737] array is not a Sequence In-Reply-To: <1448537649.86.0.885493348949.issue25737@psf.upfronthosting.co.za> Message-ID: <1550161777.69.0.358439190589.issue25737@roundup.psfhosted.org> Change by Josh Rosenberg : ---------- versions: +Python 3.7, Python 3.8 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 11:30:18 2019 From: report at bugs.python.org (Paul Ganssle) Date: Thu, 14 Feb 2019 16:30:18 +0000 Subject: =?utf-8?b?W2lzc3VlMzUzNjRdIERhdGV0aW1lIOKAnGZyb210aW1lc3RhbXAoKeKAnSBp?= =?utf-8?q?gnores_inheritance_if_timezone_is_not_None?= In-Reply-To: <1543598741.31.0.788709270274.issue35364@psf.upfronthosting.co.za> Message-ID: <1550161818.91.0.408199660829.issue35364@roundup.psfhosted.org> Change by Paul Ganssle : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 11:31:34 2019 From: report at bugs.python.org (Steve Dower) Date: Thu, 14 Feb 2019 16:31:34 +0000 Subject: [issue35976] Enable Windows projects to build with platform ARM32 In-Reply-To: <1549989417.75.0.745284008446.issue35976@roundup.psfhosted.org> Message-ID: <1550161894.68.0.72953317239.issue35976@roundup.psfhosted.org> Steve Dower added the comment: New changeset 8a1657b93469580ef345c7c91738587f3d76e87d by Steve Dower (Paul Monson) in branch 'master': bpo-35976: Enable Windows projects to build with platform ARM32 (GH-11825) https://github.com/python/cpython/commit/8a1657b93469580ef345c7c91738587f3d76e87d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 11:31:48 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 14 Feb 2019 16:31:48 +0000 Subject: [issue25737] array is not a Sequence In-Reply-To: <1448537649.86.0.885493348949.issue25737@psf.upfronthosting.co.za> Message-ID: <1550161908.86.0.896685061159.issue25737@roundup.psfhosted.org> Josh Rosenberg added the comment: Correction: It should actually be registered as a subclass of MutableSequence (which should make it a virtual subclass of Sequence too; list is only registered on MutableSequence as well). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 11:33:48 2019 From: report at bugs.python.org (Berker Peksag) Date: Thu, 14 Feb 2019 16:33:48 +0000 Subject: [issue35889] sqlite3.Row doesn't have useful repr In-Reply-To: <1549112536.04.0.744689521798.issue35889@roundup.psfhosted.org> Message-ID: <1550162028.64.0.243922317801.issue35889@roundup.psfhosted.org> Berker Peksag added the comment: While the proposed formats look nice for artificial inputs, the Row object can have more than two fields and the value of a field can be much longer than that. So, in practice the new repr can make the situation worse than the current repr. I think wrapping the output of row.keys() (https://docs.python.org/3/library/sqlite3.html#sqlite3.Row.keys) with something like reprlib.recursive_repr() would work better for Row objects with several fields. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 11:34:07 2019 From: report at bugs.python.org (Berker Peksag) Date: Thu, 14 Feb 2019 16:34:07 +0000 Subject: [issue35889] sqlite3.Row doesn't have useful repr In-Reply-To: <1549112536.04.0.744689521798.issue35889@roundup.psfhosted.org> Message-ID: <1550162047.97.0.295040449512.issue35889@roundup.psfhosted.org> Change by Berker Peksag : ---------- pull_requests: -11846 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 11:34:12 2019 From: report at bugs.python.org (Berker Peksag) Date: Thu, 14 Feb 2019 16:34:12 +0000 Subject: [issue35889] sqlite3.Row doesn't have useful repr In-Reply-To: <1549112536.04.0.744689521798.issue35889@roundup.psfhosted.org> Message-ID: <1550162052.12.0.341710641197.issue35889@roundup.psfhosted.org> Change by Berker Peksag : ---------- pull_requests: -11845 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 11:34:16 2019 From: report at bugs.python.org (Berker Peksag) Date: Thu, 14 Feb 2019 16:34:16 +0000 Subject: [issue35889] sqlite3.Row doesn't have useful repr In-Reply-To: <1549112536.04.0.744689521798.issue35889@roundup.psfhosted.org> Message-ID: <1550162056.91.0.228678431882.issue35889@roundup.psfhosted.org> Change by Berker Peksag : ---------- pull_requests: -11844 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 11:37:04 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Feb 2019 16:37:04 +0000 Subject: [issue35459] Use PyDict_GetItemWithError() instead of PyDict_GetItem() In-Reply-To: <1544525657.6.0.788709270274.issue35459@psf.upfronthosting.co.za> Message-ID: <1550162224.82.0.312806520868.issue35459@roundup.psfhosted.org> Serhiy Storchaka added the comment: Eric requested to run the benchmark suite. Here are results. I do not know how to interpret them. Likely all differences are random. ---------- Added file: https://bugs.python.org/file48137/pydict-getitem-compare.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 11:42:48 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Feb 2019 16:42:48 +0000 Subject: [issue35460] Add PyDict_GetItemStringWithError In-Reply-To: <1544526024.8.0.788709270274.issue35460@psf.upfronthosting.co.za> Message-ID: <1550162568.22.0.857370102598.issue35460@roundup.psfhosted.org> Serhiy Storchaka added the comment: See also issue35459. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 11:47:40 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Feb 2019 16:47:40 +0000 Subject: [issue35846] Incomplete documentation for re.sub In-Reply-To: <1548749168.19.0.209945761228.issue35846@roundup.psfhosted.org> Message-ID: <1550162860.38.0.0895040401877.issue35846@roundup.psfhosted.org> Serhiy Storchaka added the comment: This is a duplicate of issue28450. ---------- nosy: +serhiy.storchaka resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Misleading/inaccurate documentation about unknown escape sequences in regular expressions _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 11:48:24 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Thu, 14 Feb 2019 16:48:24 +0000 Subject: [issue35145] sqlite3: optionally autoconvert table_info's DATETIME fields In-Reply-To: <1541160984.12.0.788709270274.issue35145@psf.upfronthosting.co.za> Message-ID: <1550162904.4.0.938963065369.issue35145@roundup.psfhosted.org> St?phane Wirtel added the comment: Hi @jondo, Of course you can submit a PR and we can help you with a review if we have time because we are volunteers and it's in function of our free time. Have a nice day, ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 11:52:09 2019 From: report at bugs.python.org (Steve Dower) Date: Thu, 14 Feb 2019 16:52:09 +0000 Subject: [issue35976] Enable Windows projects to build with platform ARM32 In-Reply-To: <1549989417.75.0.745284008446.issue35976@roundup.psfhosted.org> Message-ID: <1550163129.99.0.646742382007.issue35976@roundup.psfhosted.org> Steve Dower added the comment: Thanks, Paul! Hopefully when you rebase the main change on top of this it will be easier to see the actual impact. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 11:59:26 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Feb 2019 16:59:26 +0000 Subject: [issue35874] Clarify that the (...) convertor to PyArg_ParseTuple... accepts any sequence. In-Reply-To: <1549011809.83.0.066679441781.issue35874@roundup.psfhosted.org> Message-ID: <1550163566.01.0.336996830202.issue35874@roundup.psfhosted.org> Serhiy Storchaka added the comment: Passing non-tuple can lead to reference counting error. See issue6083. I think that accepting a non-tuple should be deprecated, and finally disallowed. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 12:50:24 2019 From: report at bugs.python.org (cdods) Date: Thu, 14 Feb 2019 17:50:24 +0000 Subject: [issue34506] Traceback logged when SSL handshake fails In-Reply-To: <1535269470.94.0.56676864532.issue34506@psf.upfronthosting.co.za> Message-ID: <1550166624.07.0.468605079129.issue34506@roundup.psfhosted.org> cdods added the comment: Any update on this one? Still happening on 3.7.1 ---------- assignee: -> christian.heimes components: +SSL nosy: +cdods, christian.heimes type: -> behavior versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 13:04:09 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 14 Feb 2019 18:04:09 +0000 Subject: [issue35577] side_effect mocked method lose reference to instance In-Reply-To: <1545664740.73.0.712150888896.issue35577@roundup.psfhosted.org> Message-ID: <1550167449.72.0.301070443858.issue35577@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Thanks for the report. I think this is design by choice that self is not passed to the side_effect directly set on the mock [0]. Changing this would break existing tests like [1] . You can use the approach by @remi.lapeyre which directly replaces the function on the target inside the context manager at [2] passing self to the side_effect callable. [0] https://github.com/python/cpython/blob/8a1657b93469580ef345c7c91738587f3d76e87d/Lib/unittest/mock.py#L1043 [1] https://github.com/python/cpython/blob/8a1657b93469580ef345c7c91738587f3d76e87d/Lib/unittest/test/testmock/testmock.py#L664 [2] https://github.com/python/cpython/blob/8a1657b93469580ef345c7c91738587f3d76e87d/Lib/unittest/mock.py#L1376 ---------- nosy: +cjw296, mariocj89, xtreak versions: -Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 13:21:46 2019 From: report at bugs.python.org (Eryk Sun) Date: Thu, 14 Feb 2019 18:21:46 +0000 Subject: [issue25737] array is not a Sequence In-Reply-To: <1448537649.86.0.885493348949.issue25737@psf.upfronthosting.co.za> Message-ID: <1550168506.3.0.749418722273.issue25737@roundup.psfhosted.org> Eryk Sun added the comment: I had closed this issue because I thought issue 23864 would be resolved by extending the existing behavior. Three years later, still with no resolution, Guido commented on that issue that the current behavior shouldn't be extended and only the documentation should be fixed. In apparent contradiction, we now have the Collection ABC (Sized, Iterable, Container), which does implement a __subclasshook__. >>> issubclass(array.array, abc.Collection) True Anyway, it was obviously a mistake to close this specific issue in favor of the general design problem. This problem can be easily solved via registration. The general design problem is dead in the water. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 13:22:39 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 14 Feb 2019 18:22:39 +0000 Subject: [issue35633] test_eintr fails on AIX since fcntl functions were modified In-Reply-To: <1546366148.3.0.0239151726659.issue35633@roundup.psfhosted.org> Message-ID: <1550168559.64.0.309740123159.issue35633@roundup.psfhosted.org> miss-islington added the comment: New changeset b94d4bed67c60834b1a5a0936b8c13934cf3b872 by Miss Islington (bot) (Michael Felt) in branch 'master': bpo-35633: test_lockf() fails with "PermissionError: [Errno 13] Permission denied" on AIX (GH-11424) https://github.com/python/cpython/commit/b94d4bed67c60834b1a5a0936b8c13934cf3b872 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 13:22:39 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 14 Feb 2019 18:22:39 +0000 Subject: [issue35189] PEP 475: fnctl functions are not retried if interrupted by a signal (EINTR) In-Reply-To: <1541681130.38.0.788709270274.issue35189@psf.upfronthosting.co.za> Message-ID: <1550168559.69.0.934248547966.issue35189@roundup.psfhosted.org> miss-islington added the comment: New changeset b94d4bed67c60834b1a5a0936b8c13934cf3b872 by Miss Islington (bot) (Michael Felt) in branch 'master': bpo-35633: test_lockf() fails with "PermissionError: [Errno 13] Permission denied" on AIX (GH-11424) https://github.com/python/cpython/commit/b94d4bed67c60834b1a5a0936b8c13934cf3b872 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 13:22:48 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 14 Feb 2019 18:22:48 +0000 Subject: [issue35633] test_eintr fails on AIX since fcntl functions were modified In-Reply-To: <1546366148.3.0.0239151726659.issue35633@roundup.psfhosted.org> Message-ID: <1550168568.67.0.127490015353.issue35633@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11890 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 13:22:48 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 14 Feb 2019 18:22:48 +0000 Subject: [issue35189] PEP 475: fnctl functions are not retried if interrupted by a signal (EINTR) In-Reply-To: <1541681130.38.0.788709270274.issue35189@psf.upfronthosting.co.za> Message-ID: <1550168568.73.0.192998322787.issue35189@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11891 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 13:25:02 2019 From: report at bugs.python.org (Mariatta Wijaya) Date: Thu, 14 Feb 2019 18:25:02 +0000 Subject: [issue35633] test_eintr fails on AIX since fcntl functions were modified In-Reply-To: <1546366148.3.0.0239151726659.issue35633@roundup.psfhosted.org> Message-ID: <1550168702.3.0.248545432456.issue35633@roundup.psfhosted.org> Mariatta Wijaya added the comment: Thanks all! ---------- nosy: +Mariatta resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 13:41:41 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 14 Feb 2019 18:41:41 +0000 Subject: [issue35633] test_eintr fails on AIX since fcntl functions were modified In-Reply-To: <1546366148.3.0.0239151726659.issue35633@roundup.psfhosted.org> Message-ID: <1550169701.51.0.655202187808.issue35633@roundup.psfhosted.org> miss-islington added the comment: New changeset 7e618f3154404613cd9774fb8ffb5b48e7233a9e by Miss Islington (bot) in branch '3.7': bpo-35633: test_lockf() fails with "PermissionError: [Errno 13] Permission denied" on AIX (GH-11424) https://github.com/python/cpython/commit/7e618f3154404613cd9774fb8ffb5b48e7233a9e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 13:41:41 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 14 Feb 2019 18:41:41 +0000 Subject: [issue35189] PEP 475: fnctl functions are not retried if interrupted by a signal (EINTR) In-Reply-To: <1541681130.38.0.788709270274.issue35189@psf.upfronthosting.co.za> Message-ID: <1550169701.58.0.614222465235.issue35189@roundup.psfhosted.org> miss-islington added the comment: New changeset 7e618f3154404613cd9774fb8ffb5b48e7233a9e by Miss Islington (bot) in branch '3.7': bpo-35633: test_lockf() fails with "PermissionError: [Errno 13] Permission denied" on AIX (GH-11424) https://github.com/python/cpython/commit/7e618f3154404613cd9774fb8ffb5b48e7233a9e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 14:11:17 2019 From: report at bugs.python.org (Eddie Elizondo) Date: Thu, 14 Feb 2019 19:11:17 +0000 Subject: [issue35810] Object Initialization does not incref Heap-allocated Types In-Reply-To: <1548275752.94.0.463880453345.issue35810@roundup.psfhosted.org> Message-ID: <1550171477.77.0.120386218466.issue35810@roundup.psfhosted.org> Eddie Elizondo added the comment: > Please open a thread on python-dev Done! https://mail.python.org/pipermail/python-dev/2019-February/156322.html > Yes. You should add a new "Changes in the C API" Done as well, I also included examples for the scenarios that will need fixing to avoid having immortal types: https://github.com/python/cpython/pull/11661 Looking forward to seeing this through! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 14:31:02 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 14 Feb 2019 19:31:02 +0000 Subject: [issue1054041] Python doesn't exit with proper resultcode on SIGINT Message-ID: <1550172662.39.0.697576457513.issue1054041@roundup.psfhosted.org> Gregory P. Smith added the comment: jwilk: Confirmed. The exit code is not enough, we must trigger the SIG_DFL handler. to reproduce: while true; do ./sig.py ; done with the attached sig.py. pass a parameter to sig.py to have it exit 130 instead of triggering SIG_DFL... ---------- Added file: https://bugs.python.org/file48138/sig.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 14:34:36 2019 From: report at bugs.python.org (Berry Schoenmakers) Date: Thu, 14 Feb 2019 19:34:36 +0000 Subject: [issue35996] Optional modulus argument for new math.prod() function Message-ID: <1550172876.35.0.867721234262.issue35996@roundup.psfhosted.org> New submission from Berry Schoenmakers : It's nice to see the arrival of the prod() function, see PR11359. Just as for the built-in pow(x, y[, z]) function it would be very useful to have an optional argument z for computing integer products modulo z. Typical use case in cryptography would be: prod((pow(x, y, z) for x, y in zip(g, s)), z) to compute the product of all (potentially many) g[i]**s[i]'s modulo z. And, just as with the use of pow(), the intermediate values for prod() may in general grow quickly, hence modular reduction is essential to limit time and space usage. Maybe an interesting option to add at this stage? ---------- components: Library (Lib) messages: 335557 nosy: lschoe, rhettinger priority: normal severity: normal status: open title: Optional modulus argument for new math.prod() function type: performance versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 14:48:07 2019 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 14 Feb 2019 19:48:07 +0000 Subject: [issue34971] add support for tls/ssl sessions in asyncio In-Reply-To: <1539420460.92.0.788709270274.issue34971@psf.upfronthosting.co.za> Message-ID: <1550173687.39.0.634517737776.issue34971@roundup.psfhosted.org> Yury Selivanov added the comment: Christian, do you think the sessions support shouldn't be added to asyncio in 3.8? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 14:51:11 2019 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 14 Feb 2019 19:51:11 +0000 Subject: [issue34433] cancel all other pending child futures In-Reply-To: <1534684420.56.0.56676864532.issue34433@psf.upfronthosting.co.za> Message-ID: <1550173871.23.0.883787445827.issue34433@roundup.psfhosted.org> Yury Selivanov added the comment: This is a backwards incompatible change, unfortunately. Wait for the new TaskGroups API that will resolve this issue. ---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 15:20:24 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Feb 2019 20:20:24 +0000 Subject: [issue31829] Portability issues with pickle In-Reply-To: <1508521289.37.0.213398074469.issue31829@psf.upfronthosting.co.za> Message-ID: <1550175624.27.0.668450235495.issue31829@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- pull_requests: +11892 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 15:36:32 2019 From: report at bugs.python.org (muhzi) Date: Thu, 14 Feb 2019 20:36:32 +0000 Subject: [issue35997] ImportError: dlopen failed: cannot locate symbol "PyBool_Type" Message-ID: <1550176592.88.0.291433310272.issue35997@roundup.psfhosted.org> New submission from muhzi : I cross compiled python for android x86_64, and the interpreter works fine, no problems. But when I compiled some other extension and try to import it. I get an import error as such the imported shared library fails to locate the symbol "PyBool_Type". ImportError: dlopen failed: cannot locate symbol "PyBool_Type" referenced by .... The extension was compiled with -I && -L flags pointing to the Python installation include and lib folders. ---------- components: Cross-Build, Regular Expressions messages: 335560 nosy: Alex.Willmer, ezio.melotti, mrabarnett, muhzi, xdegaye priority: normal severity: normal status: open title: ImportError: dlopen failed: cannot locate symbol "PyBool_Type" type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 15:44:33 2019 From: report at bugs.python.org (Brett Cannon) Date: Thu, 14 Feb 2019 20:44:33 +0000 Subject: [issue35887] Doc string for updating the frozen version of importlib in _bootstrap.py incorrect In-Reply-To: <1549071736.85.0.965218389814.issue35887@roundup.psfhosted.org> Message-ID: <1550177073.57.0.21231962151.issue35887@roundup.psfhosted.org> Change by Brett Cannon : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 15:46:37 2019 From: report at bugs.python.org (Brett Cannon) Date: Thu, 14 Feb 2019 20:46:37 +0000 Subject: [issue12317] inspect.getabsfile() is not documented In-Reply-To: <1308351508.86.0.88677303291.issue12317@psf.upfronthosting.co.za> Message-ID: <1550177197.47.0.419238504397.issue12317@roundup.psfhosted.org> Change by Brett Cannon : ---------- nosy: -brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 15:49:07 2019 From: report at bugs.python.org (Brett Cannon) Date: Thu, 14 Feb 2019 20:49:07 +0000 Subject: [issue35321] None _frozen_importlib.__spec__.origin attribute In-Reply-To: <1543274371.24.0.788709270274.issue35321@psf.upfronthosting.co.za> Message-ID: <1550177347.18.0.302020836987.issue35321@roundup.psfhosted.org> Brett Cannon added the comment: Can this be closed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 15:51:11 2019 From: report at bugs.python.org (Brett Cannon) Date: Thu, 14 Feb 2019 20:51:11 +0000 Subject: [issue35843] importlib.util docs for namespace packages innaccurate In-Reply-To: <1548698590.94.0.426601552573.issue35843@roundup.psfhosted.org> Message-ID: <1550177471.44.0.335874963709.issue35843@roundup.psfhosted.org> Change by Brett Cannon : ---------- nosy: +barry, eric.smith, eric.snow, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 15:58:27 2019 From: report at bugs.python.org (Brett Cannon) Date: Thu, 14 Feb 2019 20:58:27 +0000 Subject: [issue35661] Store the venv prompt in pyvenv.cfg In-Reply-To: <1546649882.91.0.811189740909.issue35661@roundup.psfhosted.org> Message-ID: <1550177907.94.0.966480293045.issue35661@roundup.psfhosted.org> Brett Cannon added the comment: I think upgrading the scripts to read from pyvenv.cfg is a separate issue per activation script (e.g. an issue for PowerShell, an issue for fish, etc.) as this could be done piecemeal. One benefit to doing this is it would help move towards the activation scripts becoming static and thus skipping the string substitution when writing the files to disk. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 16:06:18 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Thu, 14 Feb 2019 21:06:18 +0000 Subject: [issue35997] ImportError: dlopen failed: cannot locate symbol "PyBool_Type" In-Reply-To: <1550176592.88.0.291433310272.issue35997@roundup.psfhosted.org> Message-ID: <1550178378.78.0.573539501365.issue35997@roundup.psfhosted.org> St?phane Wirtel added the comment: Can you see the symbols when you use nm or readelf? ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 16:07:38 2019 From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=) Date: Thu, 14 Feb 2019 21:07:38 +0000 Subject: [issue35321] None _frozen_importlib.__spec__.origin attribute In-Reply-To: <1543274371.24.0.788709270274.issue35321@psf.upfronthosting.co.za> Message-ID: <1550178458.52.0.0555504882273.issue35321@roundup.psfhosted.org> G?ry added the comment: Yes, closed. ---------- stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 16:11:18 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Thu, 14 Feb 2019 21:11:18 +0000 Subject: [issue35997] ImportError: dlopen failed: cannot locate symbol "PyBool_Type" In-Reply-To: <1550176592.88.0.291433310272.issue35997@roundup.psfhosted.org> Message-ID: <1550178678.75.0.994714813155.issue35997@roundup.psfhosted.org> St?phane Wirtel added the comment: if you have compiled python with --enable-shared you will get a lib/libpython3.Xdm.so file and you can use nm -D lib/libpython3.Xdm.so | grep PyBool_Type nm --debug-syms lib/libpython3.8dm.so | grep PyBool 0000000000077696 T PyBool_FromLong 0000000000328d20 D PyBool_Type I think it's a problem with your compilation. Could you explain how do you cross-compile for android? Thank you ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 16:18:18 2019 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 14 Feb 2019 21:18:18 +0000 Subject: [issue24658] open().write() fails on 2 GB+ data (OS X) In-Reply-To: <1437188368.42.0.0977367912313.issue24658@psf.upfronthosting.co.za> Message-ID: <1550179098.95.0.524045322531.issue24658@roundup.psfhosted.org> Barry A. Warsaw added the comment: Nosying myself since I just landed here based on an internal $work bug report. We're seeing it with reads. I'll try to set aside some work time to review the PRs. ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 16:18:55 2019 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 14 Feb 2019 21:18:55 +0000 Subject: [issue24658] open().write() and .read() fails on 2 GB+ data (OS X) In-Reply-To: <1437188368.42.0.0977367912313.issue24658@psf.upfronthosting.co.za> Message-ID: <1550179135.03.0.377277694483.issue24658@roundup.psfhosted.org> Change by Barry A. Warsaw : ---------- title: open().write() fails on 2 GB+ data (OS X) -> open().write() and .read() fails on 2 GB+ data (OS X) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 16:26:10 2019 From: report at bugs.python.org (muhzi) Date: Thu, 14 Feb 2019 21:26:10 +0000 Subject: [issue35997] ImportError: dlopen failed: cannot locate symbol "PyBool_Type" In-Reply-To: <1550176592.88.0.291433310272.issue35997@roundup.psfhosted.org> Message-ID: <1550179570.18.0.494911783361.issue35997@roundup.psfhosted.org> muhzi added the comment: Yes, the symbols are there. And here is how I cross compiled Python: export CC="${ANDROID_TARGET}${ANDROID_API}-clang" export CXX="$CC++" # environment variables for binary utils.. export AR="$BIN_UTILS_PREFIX-ar" export LD="$BIN_UTILS_PREFIX-ld" export AS="$BIN_UTILS_PREFIX-as" export STRIP="$BIN_UTILS_PREFIX-strip" export RANLIB="$BIN_UTILS_PREFIX-ranlib" export READELF="$BIN_UTILS_PREFIX-readelf" # compiler and linker flags export CFLAGS="-fPIE -fPIC" export LDFLAGS="-fuse-ld=lld -Wl,--rpath=../lib" export CONFIG_SITE="config.site" CONFIG_BUILD="$(uname -m)-linux-gnu" CONFIG_ARGS="--enable-shared --disable-ipv6" CONFIG_PREFIX="$PYTHON_PATH/output/$ARCH-android" $PYTHON_PATH/configure --host=$ANDROID_TARGET --build=$CONFIG_BUILD --prefix=$CONFIG_PREFIX $CONFIG_ARGS make -C $PYTHON_PATH make -C $PYTHON_PATH install ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 16:37:50 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Thu, 14 Feb 2019 21:37:50 +0000 Subject: [issue35997] ImportError: dlopen failed: cannot locate symbol "PyBool_Type" In-Reply-To: <1550176592.88.0.291433310272.issue35997@roundup.psfhosted.org> Message-ID: <1550180270.37.0.928181191147.issue35997@roundup.psfhosted.org> St?phane Wirtel added the comment: Thank you, but I think there is missing info with your script. Do you have a shell script to share? What are the values of: ANDROID_TARGET ANDROID_API CC++ BIN_UTILS_PREFIX etc... For example, if I want to use a docker image on my Fedora, how can I compile Python for Android from my Fedora or Debian x86? Thank you ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 16:40:24 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Thu, 14 Feb 2019 21:40:24 +0000 Subject: [issue24658] open().write() and .read() fails on 2 GB+ data (OS X) In-Reply-To: <1437188368.42.0.0977367912313.issue24658@psf.upfronthosting.co.za> Message-ID: <1550180424.98.0.0448613082297.issue24658@roundup.psfhosted.org> St?phane Wirtel added the comment: Hi @barry normally this issue is fixed for 3.x but I need to finish my PR for 2.7. I think to fix for 2.7 in the next weeks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 16:54:09 2019 From: report at bugs.python.org (muhzi) Date: Thu, 14 Feb 2019 21:54:09 +0000 Subject: [issue35997] ImportError: dlopen failed: cannot locate symbol "PyBool_Type" In-Reply-To: <1550176592.88.0.291433310272.issue35997@roundup.psfhosted.org> Message-ID: <1550181249.73.0.82975431178.issue35997@roundup.psfhosted.org> muhzi added the comment: OK, I uploaded it. I give the path for NDK then it determines those values for the target architecture, in my case I use it for x86_64. ---------- Added file: https://bugs.python.org/file48139/xcompile-py3.sh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 16:55:42 2019 From: report at bugs.python.org (muhzi) Date: Thu, 14 Feb 2019 21:55:42 +0000 Subject: [issue35997] ImportError: dlopen failed: cannot locate symbol "PyBool_Type" In-Reply-To: <1550176592.88.0.291433310272.issue35997@roundup.psfhosted.org> Message-ID: <1550181342.17.0.637865841789.issue35997@roundup.psfhosted.org> Change by muhzi : Removed file: https://bugs.python.org/file48139/xcompile-py3.sh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 16:55:59 2019 From: report at bugs.python.org (muhzi) Date: Thu, 14 Feb 2019 21:55:59 +0000 Subject: [issue35997] ImportError: dlopen failed: cannot locate symbol "PyBool_Type" In-Reply-To: <1550176592.88.0.291433310272.issue35997@roundup.psfhosted.org> Message-ID: <1550181359.47.0.975879183326.issue35997@roundup.psfhosted.org> Change by muhzi : Added file: https://bugs.python.org/file48140/xcompile-py3.sh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 17:34:33 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Thu, 14 Feb 2019 22:34:33 +0000 Subject: [issue35848] readinto is not a method on io.TextIOBase In-Reply-To: <1548753520.89.0.970608711782.issue35848@roundup.psfhosted.org> Message-ID: <1550183673.63.0.708673078393.issue35848@roundup.psfhosted.org> Cheryl Sabella added the comment: Steve, Would you be interested in creating a Github pull request with the documentation changes? ---------- components: +Documentation -IO nosy: +cheryl.sabella _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 17:57:27 2019 From: report at bugs.python.org (Indra Talip) Date: Thu, 14 Feb 2019 22:57:27 +0000 Subject: [issue28009] core logic of uuid.getnode() is broken for netstat In-Reply-To: <1473290315.48.0.840701308825.issue28009@psf.upfronthosting.co.za> Message-ID: <1550185047.06.0.653372330925.issue28009@roundup.psfhosted.org> Indra Talip added the comment: The current code and proposed changes use 'netstat -ia' to find the node however if netstat needs to perform a reverse DNS query to resolve some interfaces this makes using uuid1 *really* slow especially when reverse DNS queries aren't set up correctly or timeout. mac = _find_mac_netstat('netstat', '-ia', b'Address', lambda i: i) Would it be possible to change the netstat call to add 'n' to the nestat options, i.e. _find_mac_netstat('netstat', '-ian', ...) to prevent netstat from attempting to resolve addresses? ---------- nosy: +italip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 18:34:13 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 14 Feb 2019 23:34:13 +0000 Subject: [issue12317] inspect.getabsfile() is not documented In-Reply-To: <1308351508.86.0.88677303291.issue12317@psf.upfronthosting.co.za> Message-ID: <1550187253.59.0.297952286769.issue12317@roundup.psfhosted.org> Change by Giampaolo Rodola' : ---------- nosy: -giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 18:35:28 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 14 Feb 2019 23:35:28 +0000 Subject: [issue30410] Documentation for sys.stdout encoding does not reflect the new Windows behavior in Python 3.6+ In-Reply-To: <1495270729.75.0.717879181788.issue30410@psf.upfronthosting.co.za> Message-ID: <1550187328.19.0.0369711201925.issue30410@roundup.psfhosted.org> miss-islington added the comment: New changeset 5723263a3a39a05b6a2f567e0e7771792e6e2f5b by Miss Islington (bot) (Lysandros Nikolaou) in branch 'master': bpo-30410: Documentation of sys.stdin/out/err update to reflect change in 3.6 (GH-10264) https://github.com/python/cpython/commit/5723263a3a39a05b6a2f567e0e7771792e6e2f5b ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 18:35:48 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 14 Feb 2019 23:35:48 +0000 Subject: [issue30410] Documentation for sys.stdout encoding does not reflect the new Windows behavior in Python 3.6+ In-Reply-To: <1495270729.75.0.717879181788.issue30410@psf.upfronthosting.co.za> Message-ID: <1550187348.98.0.958942334418.issue30410@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11893 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 18:36:54 2019 From: report at bugs.python.org (Mariatta Wijaya) Date: Thu, 14 Feb 2019 23:36:54 +0000 Subject: [issue30410] Documentation for sys.stdout encoding does not reflect the new Windows behavior in Python 3.6+ In-Reply-To: <1495270729.75.0.717879181788.issue30410@psf.upfronthosting.co.za> Message-ID: <1550187414.79.0.708983280988.issue30410@roundup.psfhosted.org> Mariatta Wijaya added the comment: Fixed in 3.8 and 3.7. Thanks! ---------- nosy: +Mariatta resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 18:45:23 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 14 Feb 2019 23:45:23 +0000 Subject: [issue30410] Documentation for sys.stdout encoding does not reflect the new Windows behavior in Python 3.6+ In-Reply-To: <1495270729.75.0.717879181788.issue30410@psf.upfronthosting.co.za> Message-ID: <1550187923.36.0.416142387676.issue30410@roundup.psfhosted.org> miss-islington added the comment: New changeset b8bcec35e01cac018f6ccfc8323d35886340efe0 by Miss Islington (bot) in branch '3.7': bpo-30410: Documentation of sys.stdin/out/err update to reflect change in 3.6 (GH-10264) https://github.com/python/cpython/commit/b8bcec35e01cac018f6ccfc8323d35886340efe0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 19:00:40 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Fri, 15 Feb 2019 00:00:40 +0000 Subject: [issue35078] Allow customization of CSS class name of a month in calendar module In-Reply-To: <1540652698.56.0.788709270274.issue35078@psf.upfronthosting.co.za> Message-ID: <1550188840.04.0.577613341602.issue35078@roundup.psfhosted.org> Cheryl Sabella added the comment: Issue 30095 enhanced the `HTMLCalendar` code to allow easier customization of the CSS classes. This PR extends that to the existing `LocaleHTMLCalendar`. Adding @doerwalter to the nosy list as he merged #30095. ---------- nosy: +cheryl.sabella, doerwalter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 20:48:13 2019 From: report at bugs.python.org (Eryk Sun) Date: Fri, 15 Feb 2019 01:48:13 +0000 Subject: [issue1054041] Python doesn't exit with proper resultcode on SIGINT Message-ID: <1550195293.27.0.426543121794.issue1054041@roundup.psfhosted.org> Eryk Sun added the comment: Gregory's last example reminded me that CMD checks for STATUS_CONTROL_C_EXIT for more than simply printing "^C". It also breaks out of a FOR loop when interactive and prompts to continue when executing a batch script. Normally CMD also gets a console control event when the user presses Ctrl+C, so it knows about the Ctrl+C regardless of the child's exit status. One exception is when we start a process with a new console via CMD's `start` command. In this case CMD doesn't get a Ctrl+C event, since it's attached to a different console. Another exception is a simulated keyboard interrupt (e.g. from C raise SIGINT or Python _thread.interrupt_main). In these cases, CMD depends on the exit status value to determine whether the process was terminated by the default Ctrl+C handler. I've demonstrated this in the files winsig.bat and winsig.py. Put both in the same directory and run winsig.bat. ---------- Added file: https://bugs.python.org/file48141/winsig.bat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 20:48:56 2019 From: report at bugs.python.org (Eryk Sun) Date: Fri, 15 Feb 2019 01:48:56 +0000 Subject: [issue1054041] Python doesn't exit with proper resultcode on SIGINT Message-ID: <1550195336.68.0.62592375903.issue1054041@roundup.psfhosted.org> Change by Eryk Sun : Added file: https://bugs.python.org/file48142/winsig.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 22:12:40 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 15 Feb 2019 03:12:40 +0000 Subject: [issue35996] Optional modulus argument for new math.prod() function In-Reply-To: <1550172876.35.0.867721234262.issue35996@roundup.psfhosted.org> Message-ID: <1550200360.19.0.0989869627069.issue35996@roundup.psfhosted.org> Raymond Hettinger added the comment: I don't think even Mathematica has found a need for this: https://reference.wolfram.com/language/ref/Product.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 22:30:04 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 15 Feb 2019 03:30:04 +0000 Subject: [issue35996] Optional modulus argument for new math.prod() function In-Reply-To: <1550172876.35.0.867721234262.issue35996@roundup.psfhosted.org> Message-ID: <1550201404.39.0.676075784713.issue35996@roundup.psfhosted.org> Raymond Hettinger added the comment: One other issue is that the arguments to prod() need not be integers, so a modulus argument wouldn't make sense in those contexts. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 23:47:39 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Fri, 15 Feb 2019 04:47:39 +0000 Subject: [issue35996] Optional modulus argument for new math.prod() function In-Reply-To: <1550172876.35.0.867721234262.issue35996@roundup.psfhosted.org> Message-ID: <1550206059.17.0.139062927666.issue35996@roundup.psfhosted.org> Josh Rosenberg added the comment: "One other issue is that the arguments to prod() need not be integers, so a modulus argument wouldn't make sense in those contexts." The arguments to pow don't need to be integers either, yet the optional third argument is only really relevant to integers. Not saying we should do this, but we definitely allow optional arguments that are only meaningful for certain input types in other cases. The best argument for this change I can come up with from other Python functions is the push for an efficient math.comb (#35431); if we didn't want to bother supporting minimizing intermediate values, math.comb could be implemented directly in terms of math.factorial instead of trying to pre-cancel values. But even that's not a strong argument for this, given the relative frequency with which each feature is needed (the binomial coefficient coming up much more often than modular reduction of huge products). ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 14 23:59:06 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 15 Feb 2019 04:59:06 +0000 Subject: [issue35996] Optional modulus argument for new math.prod() function In-Reply-To: <1550172876.35.0.867721234262.issue35996@roundup.psfhosted.org> Message-ID: <1550206746.68.0.371780332162.issue35996@roundup.psfhosted.org> Raymond Hettinger added the comment: Put me down for -1. In 40 years of programming, I've needed a modulus on a product exactly zero times. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 00:04:51 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 15 Feb 2019 05:04:51 +0000 Subject: [issue35994] In WalkTests of test_os.py, sub2_tree missed the dir "SUB21" if symlink can't be supported. In-Reply-To: <1550129555.65.0.532598908006.issue35994@roundup.psfhosted.org> Message-ID: <1550207091.9.0.749052826755.issue35994@roundup.psfhosted.org> miss-islington added the comment: New changeset 3e028b2d40370dc986b6f3146a7ae927bc119f97 by Miss Islington (bot) (pxinwr) in branch 'master': bpo-35994: add sub dir for sub2_tree in os.walk test if symlink is not supported (GH-11853) https://github.com/python/cpython/commit/3e028b2d40370dc986b6f3146a7ae927bc119f97 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 00:05:09 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 15 Feb 2019 05:05:09 +0000 Subject: [issue35994] In WalkTests of test_os.py, sub2_tree missed the dir "SUB21" if symlink can't be supported. In-Reply-To: <1550129555.65.0.532598908006.issue35994@roundup.psfhosted.org> Message-ID: <1550207109.41.0.229215434494.issue35994@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11894 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 00:23:12 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 15 Feb 2019 05:23:12 +0000 Subject: [issue35994] In WalkTests of test_os.py, sub2_tree missed the dir "SUB21" if symlink can't be supported. In-Reply-To: <1550129555.65.0.532598908006.issue35994@roundup.psfhosted.org> Message-ID: <1550208192.07.0.275131711062.issue35994@roundup.psfhosted.org> miss-islington added the comment: New changeset 04a39399ef13197e433757fe13108ad472461094 by Miss Islington (bot) in branch '3.7': bpo-35994: add sub dir for sub2_tree in os.walk test if symlink is not supported (GH-11853) https://github.com/python/cpython/commit/04a39399ef13197e433757fe13108ad472461094 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 00:24:31 2019 From: report at bugs.python.org (wangjiangqiang) Date: Fri, 15 Feb 2019 05:24:31 +0000 Subject: [issue35993] incorrect use of released memory in Python/pystate.c line 284 In-Reply-To: <1550126281.35.0.272027846904.issue35993@roundup.psfhosted.org> Message-ID: <1550208271.04.0.0789323583908.issue35993@roundup.psfhosted.org> wangjiangqiang <767563655 at qq.com> added the comment: Just create a temporary node points to the next node before release the current node. change the loop condition if necessary. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 00:24:59 2019 From: report at bugs.python.org (Zachary Ware) Date: Fri, 15 Feb 2019 05:24:59 +0000 Subject: [issue35994] In WalkTests of test_os.py, sub2_tree missed the dir "SUB21" if symlink can't be supported. In-Reply-To: <1550129555.65.0.532598908006.issue35994@roundup.psfhosted.org> Message-ID: <1550208299.62.0.688028851976.issue35994@roundup.psfhosted.org> Zachary Ware added the comment: Thanks for the patch! ---------- nosy: +zach.ware -miss-islington resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 02:27:14 2019 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 15 Feb 2019 07:27:14 +0000 Subject: [issue31829] Portability issues with pickle In-Reply-To: <1508521289.37.0.213398074469.issue31829@psf.upfronthosting.co.za> Message-ID: <1550215634.9.0.105542067933.issue31829@roundup.psfhosted.org> Benjamin Peterson added the comment: The proposed PR looks big. Are these actual bug fixes or features? "Portability improvements" sounds like a feature. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 02:41:36 2019 From: report at bugs.python.org (Michael Felt) Date: Fri, 15 Feb 2019 07:41:36 +0000 Subject: [issue28009] core logic of uuid.getnode() is broken for netstat In-Reply-To: <1550185047.06.0.653372330925.issue28009@roundup.psfhosted.org> Message-ID: Michael Felt added the comment: On 14/02/2019 23:57, Indra Talip wrote: > Indra Talip added the comment: > > The current code and proposed changes use 'netstat -ia' to find the node however if netstat needs to perform a reverse DNS query to resolve some interfaces this makes using uuid1 *really* slow especially when reverse DNS queries aren't set up correctly or timeout. > mac = _find_mac_netstat('netstat', '-ia', b'Address', lambda i: i) > > Would it be possible to change the netstat call to add 'n' to the nestat options, i.e. _find_mac_netstat('netstat', '-ian', ...) to prevent netstat from attempting to resolve addresses? Sounds like an excellent idea. Gives me a reason to get started again. Thx! > ---------- > nosy: +italip > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 02:52:17 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 15 Feb 2019 07:52:17 +0000 Subject: [issue1054041] Python doesn't exit with proper resultcode on SIGINT Message-ID: <1550217137.27.0.253904228333.issue1054041@roundup.psfhosted.org> Change by Gregory P. Smith : ---------- pull_requests: +11895 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 03:07:56 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Feb 2019 08:07:56 +0000 Subject: [issue31829] Portability issues with pickle In-Reply-To: <1508521289.37.0.213398074469.issue31829@psf.upfronthosting.co.za> Message-ID: <1550218076.22.0.255439546061.issue31829@roundup.psfhosted.org> Serhiy Storchaka added the comment: I have simplified the PR. Removed the complex code for detecting pickles written to files in text mode on Windows and for adding optional marks for correct detecting. Currently it does only two things: * Escapes \r, \0 and \x1a (end-of-file on Windows) when pickle unicode. This allows pickles dumped to a file in binary mode (or on non-Windows, or in Python 3) be correctly loaded from a file opened from a file in text mode on Windows. Currently, dumping to a file in text mode works most time, except on Windows, when the unicode string ends with \r or contains \x1a (not sure about \0, it was added just for the case). Since the data is only corrupted in special cases, this likely is not tested, and the user code can open files in text (default) mode without noticing a bug, until once a malicious user will provide a bad Unicode string. * Produces a deprecation warning or even a ValueError in cases when writing to a file in text mode can cause problems. This will help to notice the problem earlier. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 03:09:06 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Feb 2019 08:09:06 +0000 Subject: [issue31829] Portability issues with pickle In-Reply-To: <1508521289.37.0.213398074469.issue31829@psf.upfronthosting.co.za> Message-ID: <1550218146.57.0.436755896197.issue31829@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- versions: +Python 3.8 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 03:26:12 2019 From: report at bugs.python.org (Berry Schoenmakers) Date: Fri, 15 Feb 2019 08:26:12 +0000 Subject: [issue35996] Optional modulus argument for new math.prod() function In-Reply-To: <1550172876.35.0.867721234262.issue35996@roundup.psfhosted.org> Message-ID: <1550219172.47.0.204498578791.issue35996@roundup.psfhosted.org> Berry Schoenmakers added the comment: I had the same reservations but after rethinking it several times concluded that the modulus argument would fit really well. Indeed, Mathematica doesn't support the Modulus option for the Product[] function. But they don't even support it for the Power[] function, one needs to use PowerMod[] for that. Python has the extra option for its built-in pow(), and sensibly restricts this to the case of integer arguments only. To do modular arithmetic, even with big numbers, in Python is really nice and easy using the % operator. And it's all pretty efficient as well. The only exception where efficiency becomes an issue is the pow() function. To maintain that balance with the new prod() function around, the modulus argument would do the job. We can continue to do all modular arithmetic in a natural way, yielding programs that are perfectly readable and with very decent performance, now with prod() in the language as well. Taking larger modular products is a common thing to do in modern crypto, and Python is a popular platform for this. Next to the example of prod_i g[i]**s[i] mod z, which is like a Pedersen multi-commitment, it also arises when computing Lagrange coefficients (used in Shamir secret sharing) and related determinants for Vandermonde matrices. One would also be able to things like prod(range(1, n), n) == n - 1 for Wilson's primality test. (Extending the factorial() function with a modulus argument would be taking things too far, probably, but the modular version would now be available anyway via prod().) So, my feeling is that there are sufficiently many use cases around. And, I'm kind of assuming that it's not too much effort to add a modulus argument to prod(), but maybe that's not really the case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 03:29:22 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Feb 2019 08:29:22 +0000 Subject: [issue34235] PyArg_ParseTupleAndKeywords: support required keyword arguments In-Reply-To: <1532610257.0.0.56676864532.issue34235@psf.upfronthosting.co.za> Message-ID: <1550219362.36.0.100998694698.issue34235@roundup.psfhosted.org> Serhiy Storchaka added the comment: I thought about this variant. The problem is that you need to scan the format string to the end to determine whether arguments following $ are optional or not. This adds performance penalty for all existing uses of PyArg_ParseTupleAndKeywords() with $. Your PR changes the current behavior, and this is unacceptable too, because it can lead to crashes and other errors in existing code. It is possible to add this feature without breakage and performance loss. Just allow $ to be used twice, for required and optional arguments. Then PyArg_ParseTupleAndKeywords(args, kwds, "O$O|O$O", kwlist, &a, &c, &b, &d) will define four parameters in the following order: required positional-or-keyword, required keyword-only, optional positional-or-keyword, optional keyword-only. My doubts are that this order is different from the order of parameters as defined in Python functions: required positional-or-keyword, optional positional-or-keyword, required keyword-only, optional keyword-only. I afraid this can cause confusions. Although, the first order (all required parameters are first) is more efficient for processing. So perhaps for compatibility, performance, and the simplicity of the implementation we will accept it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 03:39:27 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Feb 2019 08:39:27 +0000 Subject: [issue35808] Let's retire pgen In-Reply-To: <1548221537.82.0.492786218381.issue35808@roundup.psfhosted.org> Message-ID: <1550219967.91.0.888959963466.issue35808@roundup.psfhosted.org> Serhiy Storchaka added the comment: I didn't look at the PR yet, but this is a wonderful idea. I planned to do this just after rewriting generators of token-related data and code in Python (issue30455), but Pablo has overfoot me. Great! ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 03:47:32 2019 From: report at bugs.python.org (Christian Tismer) Date: Fri, 15 Feb 2019 08:47:32 +0000 Subject: [issue35810] Object Initialization does not incref Heap-allocated Types In-Reply-To: <1548275752.94.0.463880453345.issue35810@roundup.psfhosted.org> Message-ID: <1550220452.66.0.523826564492.issue35810@roundup.psfhosted.org> Christian Tismer added the comment: Thanks for including me here! We have indeed converted everything to new style types but saw no refcount problems, yet. This will probably come after the patch. We will add an issue to the tracker for Python 3.8. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 04:42:56 2019 From: report at bugs.python.org (Michael Sullivan) Date: Fri, 15 Feb 2019 09:42:56 +0000 Subject: [issue34235] PyArg_ParseTupleAndKeywords: support required keyword arguments In-Reply-To: <1532610257.0.0.56676864532.issue34235@psf.upfronthosting.co.za> Message-ID: <1550223776.37.0.304354364906.issue34235@roundup.psfhosted.org> Michael Sullivan added the comment: The point about a performance penalty is fair---my PR does add a search for the '@' (which I spelled as '`' in my example above) sigil whenever it encounters a '|'. (Though I'm not sure how big the impact would be? Format strings are small so a quick scan through it should be pretty fast. Could be measured.) I am missing how my PR changes the current behavior, though? As far as I can tell it should behave exactly the same unless there is a '@' in the format string. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 04:56:24 2019 From: report at bugs.python.org (INADA Naoki) Date: Fri, 15 Feb 2019 09:56:24 +0000 Subject: [issue28673] pyro4 with more than 15 threads often crashes 2.7.12 In-Reply-To: <1478939498.33.0.0967391900201.issue28673@psf.upfronthosting.co.za> Message-ID: <1550224584.01.0.951599072575.issue28673@roundup.psfhosted.org> INADA Naoki added the comment: I think this issue is fixed by #21963. ---------- resolution: -> fixed stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 04:57:37 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 15 Feb 2019 09:57:37 +0000 Subject: [issue35899] '_is_sunder' function in 'enum' module fails on empty string In-Reply-To: <1549376859.01.0.998806898699.issue35899@roundup.psfhosted.org> Message-ID: <1550224657.45.0.0511241303617.issue35899@roundup.psfhosted.org> St?phane Wirtel added the comment: Hi Brennan, Normally, you wanted to work on this issue and you have waited for one week after the last message of Maxwell. Do you want to work on this issue and submit your PR? Have a nice day, St?phane ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 05:12:18 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 15 Feb 2019 10:12:18 +0000 Subject: [issue35998] ./python -m test test_asyncio fails Message-ID: <1550225538.04.0.738886867119.issue35998@roundup.psfhosted.org> New submission from St?phane Wirtel : ====================================================================== ERROR: test_start_tls_server_1 (test.test_asyncio.test_sslproto.SelectorStartTLSTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/stephane/src/github.com/python/cpython-original/Lib/test/test_asyncio/test_sslproto.py", line 510, in test_start_tls_server_1 self.loop.run_until_complete(run_main()) File "/home/stephane/src/github.com/python/cpython-original/Lib/asyncio/base_events.py", line 589, in run_until_complete return future.result() File "/home/stephane/src/github.com/python/cpython-original/Lib/test/test_asyncio/test_sslproto.py", line 503, in run_main await asyncio.wait_for( File "/home/stephane/src/github.com/python/cpython-original/Lib/asyncio/tasks.py", line 461, in wait_for raise exceptions.TimeoutError() asyncio.exceptions.TimeoutError my current revision: 3e028b2d40370dc986b6f3146a7ae927bc119f97 system: fedora 29 compiled with gcc gcc (GCC) 8.2.1 20181215 (Red Hat 8.2.1-6) No issue on Travis, but this test fails on my computer and I cleaned my repo with git clean -dfqx ---------- files: stdout.txt messages: 335596 nosy: matrixise priority: normal severity: normal status: open title: ./python -m test test_asyncio fails versions: Python 3.8 Added file: https://bugs.python.org/file48143/stdout.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 05:12:33 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 15 Feb 2019 10:12:33 +0000 Subject: [issue35998] ./python -m test test_asyncio fails In-Reply-To: <1550225538.04.0.738886867119.issue35998@roundup.psfhosted.org> Message-ID: <1550225553.28.0.744088051561.issue35998@roundup.psfhosted.org> St?phane Wirtel added the comment: here is the stderr.txt ---------- Added file: https://bugs.python.org/file48144/stderr.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 05:27:51 2019 From: report at bugs.python.org (Stefan Ring) Date: Fri, 15 Feb 2019 10:27:51 +0000 Subject: [issue29712] --enable-optimizations does not work with --enable-shared In-Reply-To: <1488555923.14.0.550158164587.issue29712@psf.upfronthosting.co.za> Message-ID: <1550226471.67.0.75450179858.issue29712@roundup.psfhosted.org> Stefan Ring added the comment: I was having the same problem, and I just found out what it was: Because of -Wl,-rpath=..., this path gets baked into the binary, and LD_LIBRARY_PATH is ignored. So if you have a previous build lying around there, it will mess up the build. ---------- nosy: +Ringding _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 06:15:47 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Feb 2019 11:15:47 +0000 Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org> Message-ID: <1550229347.12.0.203539516088.issue35746@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +11896 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 06:20:32 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Feb 2019 11:20:32 +0000 Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org> Message-ID: <1550229632.52.0.637443813266.issue35746@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +11897 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 06:21:56 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Feb 2019 11:21:56 +0000 Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org> Message-ID: <1550229716.84.0.972450034624.issue35746@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +11898 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 06:25:34 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Feb 2019 11:25:34 +0000 Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org> Message-ID: <1550229934.02.0.327185950006.issue35746@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +11899 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 06:25:49 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Feb 2019 11:25:49 +0000 Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org> Message-ID: <1550229949.89.0.90570988144.issue35746@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 355f16fd4beb36d6a18f7d0982581c93de015c17 by Victor Stinner in branch 'master': bpo-35746: Credit Colin Read and Nicolas Edet (GH-11863) https://github.com/python/cpython/commit/355f16fd4beb36d6a18f7d0982581c93de015c17 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 06:34:01 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Feb 2019 11:34:01 +0000 Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org> Message-ID: <1550230441.79.0.38746190388.issue35746@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +11900 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 06:34:20 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Feb 2019 11:34:20 +0000 Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org> Message-ID: <1550230460.16.0.956266358887.issue35746@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 826a8b708165796151ad4135b0ddbd79da6d39f1 by Victor Stinner in branch '2.7': bpo-35746: Credit Colin Read and Nicolas Edet (GH-11866) https://github.com/python/cpython/commit/826a8b708165796151ad4135b0ddbd79da6d39f1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 06:35:39 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Feb 2019 11:35:39 +0000 Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org> Message-ID: <1550230539.7.0.876717680052.issue35746@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +11901 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 06:44:19 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Feb 2019 11:44:19 +0000 Subject: [issue34656] [CVE-2018-20406] memory exhaustion in Modules/_pickle.c:1393 In-Reply-To: <1536813527.13.0.956365154283.issue34656@psf.upfronthosting.co.za> Message-ID: <1550231059.02.0.0550367189028.issue34656@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +11902 stage: resolved -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 06:46:03 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Feb 2019 11:46:03 +0000 Subject: [issue34656] [CVE-2018-20406] memory exhaustion in Modules/_pickle.c:1393 In-Reply-To: <1536813527.13.0.956365154283.issue34656@psf.upfronthosting.co.za> Message-ID: <1550231163.2.0.859653531006.issue34656@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +11903 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 06:55:24 2019 From: report at bugs.python.org (Defert) Date: Fri, 15 Feb 2019 11:55:24 +0000 Subject: [issue35999] multpirocessing.Process alive after SIGTERM on parent Message-ID: <1550231724.21.0.67060075553.issue35999@roundup.psfhosted.org> New submission from Defert : Hello, Using the multiprocessing.Process class on Python 3.5 (untested with other versions), child processes are not killed when the main process is killed. The doc mentions a "daemon" flag (https://python.readthedocs.io/en/latest/library/multiprocessing.html#multiprocessing.Process.daemon), which says "When a process exits, it attempts to terminate all of its daemonic child processes." However this does not seem to be the case, when the parent process is killed, all children remain alive whatever the value of the daemon flag is. Test code: from multiprocessing import Process from time import sleep from os import getpid def log(daemon_mode): while True: print('worker %i %s' % (getpid(), daemon_mode)) sleep(3) print('parent pid %i' % getpid()) a = Process(target=log, args=(0,), daemon=False) a.start() b = Process(target=log, args=(1,), daemon=True) b.start() while True: sleep(60) ###### To be run with: user at host~# python3 test.py & [1] 14749 parent pid 14749 worker 14751 1 worker 14750 0 user at host:~# user at host:~# kill 14749 [1]+ Terminated python3 test.py user at host:~# worker 14751 1 worker 14750 0 ---------- components: Library (Lib) messages: 335601 nosy: lids priority: normal severity: normal status: open title: multpirocessing.Process alive after SIGTERM on parent versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 07:03:53 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Fri, 15 Feb 2019 12:03:53 +0000 Subject: [issue35986] print() documentation typo? In-Reply-To: <1550060813.07.0.324151562751.issue35986@roundup.psfhosted.org> Message-ID: <1550232233.69.0.379830653739.issue35986@roundup.psfhosted.org> Cheryl Sabella added the comment: This was fixed with https://github.com/python/python-docs-theme/pull/25 by @matrixise. ---------- nosy: +cheryl.sabella resolution: remind -> third party stage: -> resolved status: open -> closed versions: +Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 07:04:03 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Feb 2019 12:04:03 +0000 Subject: [issue34791] xml package does not obey sys.flags.ignore_environment In-Reply-To: <1537807650.53.0.956365154283.issue34791@psf.upfronthosting.co.za> Message-ID: <1550232243.82.0.727787433082.issue34791@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +11904 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 07:04:43 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Feb 2019 12:04:43 +0000 Subject: [issue34791] xml package does not obey sys.flags.ignore_environment In-Reply-To: <1537807650.53.0.956365154283.issue34791@psf.upfronthosting.co.za> Message-ID: <1550232283.02.0.468584672149.issue34791@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +11905 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 07:13:45 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 15 Feb 2019 12:13:45 +0000 Subject: [issue35986] print() documentation typo? In-Reply-To: <1550060813.07.0.324151562751.issue35986@roundup.psfhosted.org> Message-ID: <1550232825.88.0.250003271717.issue35986@roundup.psfhosted.org> St?phane Wirtel added the comment: Thanks @cheryl but we need to have a new package of python-docs-theme. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 07:19:33 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Feb 2019 12:19:33 +0000 Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org> Message-ID: <1550233173.4.0.235889563006.issue35746@roundup.psfhosted.org> STINNER Victor added the comment: New changeset fe42122d41834746e841b5927154be041fb7afbb by Victor Stinner in branch '3.7': bpo-35746: Credit Colin Read and Nicolas Edet (GH-11864) https://github.com/python/cpython/commit/fe42122d41834746e841b5927154be041fb7afbb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 07:21:45 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Feb 2019 12:21:45 +0000 Subject: [issue35411] FTP tests of test_urllib2net fail on Travis CI: 425 Security: Bad IP connecting. In-Reply-To: <1543961289.76.0.788709270274.issue35411@psf.upfronthosting.co.za> Message-ID: <1550233305.63.0.726903666713.issue35411@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +11906 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 07:22:08 2019 From: report at bugs.python.org (Dan Snider) Date: Fri, 15 Feb 2019 12:22:08 +0000 Subject: [issue36000] __debug__ is a keyword but not a keyword Message-ID: <1550233328.67.0.392552434895.issue36000@roundup.psfhosted.org> New submission from Dan Snider : keyword.py is used by stuff like the idle colorizer to help determine if an identifier is considered a keyword but it doesn't identify __debug__ despite the fact that the parser treats it exactly the same as None, True, and False. I could not find a more recent issue to bring this back up than #34464 and there it was suggested a issue be made so here it is. As mentioned on that previous issue, currently keyword.py builds the list automatically by scanning "Python/graminit.c" but since there is no "__debug__" token to be found in that file it doesn't get added to kwlist. There is a file that groups the keywords True, False, None, and __debug__: ast.c. But there's no reason for it to be that complicated when nothing would break by for example adding on line 54 of keyword.py the statement "kwlist += ['__debug__']? Actually, I'm interested in knowing why __debug__ is a keyword in the first place. I'm terrible at searching apparently so there might be more but from what I can tell, the only thing the docs have to say about __debug__ really is the following tautology: "The value for the built-in variable [__debug__] is determined when the interpreter starts." ---------- components: Library (Lib) messages: 335605 nosy: bup priority: normal severity: normal status: open title: __debug__ is a keyword but not a keyword type: enhancement versions: Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 07:40:41 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Fri, 15 Feb 2019 12:40:41 +0000 Subject: [issue36000] __debug__ is a keyword but not a keyword In-Reply-To: <1550233328.67.0.392552434895.issue36000@roundup.psfhosted.org> Message-ID: <1550234441.68.0.519688234303.issue36000@roundup.psfhosted.org> Steven D'Aprano added the comment: I'm not sure that __debug__ is a proper keyword. Unlike None, if you monkey-patch builtins, you can modify it: py> builtins.__dict__['__debug__'] = 'Surprise!' py> __debug__ 'Surprise!' py> builtins.__dict__['None'] = 'Surprise!' py> None py> And it is not listed here: https://docs.python.org/3.7/reference/lexical_analysis.html#keywords So __debug__ appears to me to be in a strange grey area, part regular name and part keyword, but not quite either. ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 07:44:26 2019 From: report at bugs.python.org (neil pop) Date: Fri, 15 Feb 2019 12:44:26 +0000 Subject: [issue36001] LIBFFI_INCLUDEDIR is not detected when set into a profile nor in ./configure LIBFFI_INCLUDEDIR="path/to/libffi/include" Message-ID: <1550234666.59.0.236804774599.issue36001@roundup.psfhosted.org> New submission from neil pop : Hello, I tried making python 3.7.2 on linux mint without libffi set into my LIBFFI_INCLUDEDIR (usr/local/include) but set into my bashsrc which is basically a profile with export LIBFFI_INCLUDEDIR="-Ipath/to/libff/include" however when i try making python after configuring it (i tried also passing that LIBFFI_INCLUDEDIR as an argument for the config part) then i get cannot build ctypes as there is no ffi.h header detected. So what i did is that i modified the python setup at line 1989: ffi_inc = [sysconfig.get_config_var("LIBFFI_INCLUDEDIR")] to ffi_inc = ["path/to/libffi/include"] and ran the configure then the make and voil?, ctypes are now compiled. So i was wondering is there a way to setup LIBFFI_INCLUDEDIR so it get returned by sysconfig.get_config_var("LIBFFI_INCLUDEDIR") (since it clearly doesn't) ? Cheers, Elisa ---------- components: ctypes messages: 335607 nosy: neil pop priority: normal severity: normal status: open title: LIBFFI_INCLUDEDIR is not detected when set into a profile nor in ./configure LIBFFI_INCLUDEDIR="path/to/libffi/include" type: compile error versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 07:58:37 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 15 Feb 2019 12:58:37 +0000 Subject: [issue36000] __debug__ is a keyword but not a keyword In-Reply-To: <1550233328.67.0.392552434895.issue36000@roundup.psfhosted.org> Message-ID: <1550235517.3.0.896051248416.issue36000@roundup.psfhosted.org> Change by St?phane Wirtel : ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 08:00:21 2019 From: report at bugs.python.org (Ma Lin) Date: Fri, 15 Feb 2019 13:00:21 +0000 Subject: [issue33376] [pysqlite] Duplicate rows can be returned after rolling back a transaction In-Reply-To: <1524874511.54.0.682650639539.issue33376@psf.upfronthosting.co.za> Message-ID: <1550235621.46.0.508727565621.issue33376@roundup.psfhosted.org> Change by Ma Lin : ---------- nosy: +Ma Lin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 08:10:30 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Feb 2019 13:10:30 +0000 Subject: [issue35411] FTP tests of test_urllib2net fail on Travis CI: 425 Security: Bad IP connecting. In-Reply-To: <1543961289.76.0.788709270274.issue35411@psf.upfronthosting.co.za> Message-ID: <1550236230.58.0.0769717901401.issue35411@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +11907 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 08:11:16 2019 From: report at bugs.python.org (mattip) Date: Fri, 15 Feb 2019 13:11:16 +0000 Subject: [issue35688] "pip install --user numpy" fails on Python from the Windows Store In-Reply-To: <1546987520.17.0.731862977401.issue35688@roundup.psfhosted.org> Message-ID: <1550236276.89.0.837877976112.issue35688@roundup.psfhosted.org> mattip added the comment: Closing. It seems the days of modifying os.environ['PATH'] on windows are over, and packages need to adopt to calling AddDllDirectory. As long as python is built with ctypes, this is easy enough to adopt, even though there are some caveats. See the issue from anaconda https://github.com/ContinuumIO/anaconda-issues/issues/10628 ---------- resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 08:17:18 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Feb 2019 13:17:18 +0000 Subject: [issue33570] OpenSSL 1.1.1 / TLS 1.3 cipher suite changes In-Reply-To: <1526648438.42.0.682650639539.issue33570@psf.upfronthosting.co.za> Message-ID: <1550236638.08.0.688624481917.issue33570@roundup.psfhosted.org> STINNER Victor added the comment: New changeset c49f63c1761ce03df7850b9e0b31a18c432dac64 by Victor Stinner (stratakis) in branch '2.7': [2.7] bpo-33570: TLS 1.3 ciphers for OpenSSL 1.1.1 (GH-6976) (GH-8760) (GH-10607) https://github.com/python/cpython/commit/c49f63c1761ce03df7850b9e0b31a18c432dac64 ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 08:29:15 2019 From: report at bugs.python.org (Martijn Pieters) Date: Fri, 15 Feb 2019 13:29:15 +0000 Subject: [issue36002] configure --enable-optimizations with clang fails to detect llvm-profdata Message-ID: <1550237355.31.0.735770966924.issue36002@roundup.psfhosted.org> New submission from Martijn Pieters : This is probably a automake bug. When running CC=clang CXX=clang++ ./configure --enable-optimizations, configure tests for a non-existing -llvm-profdata binary: checking for --enable-optimizations... yes checking for --with-lto... no checking for -llvm-profdata... no configure: error: llvm-profdata is required for a --enable-optimizations build but could not be found. The generated configure script looks for "$target_alias-llvm-profdata", and $target_alias is an empty string. This problem is not visible on Macs, where additional checks for "/usr/bin/xcrun -find llvm-profdata" locate the binary. The work-around would be to specify a target when configuring. ---------- components: Build messages: 335610 nosy: mjpieters priority: normal severity: normal status: open title: configure --enable-optimizations with clang fails to detect llvm-profdata versions: Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 08:43:25 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Fri, 15 Feb 2019 13:43:25 +0000 Subject: [issue35986] print() documentation typo? In-Reply-To: <1550060813.07.0.324151562751.issue35986@roundup.psfhosted.org> Message-ID: <1550238205.45.0.723604847518.issue35986@roundup.psfhosted.org> Cheryl Sabella added the comment: Yes, but I thought that would be up to @theacodes to release a new version of python-docs-theme to PyPI? Since the last release was 6 months ago and the previous one to that was February 2018, I was hoping the new release would come soon. In any event, I didn't think there was anything else that could be done on this issue, which is why I closed it. Is there something that needs to be updated in the CPython repository? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 08:44:39 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Fri, 15 Feb 2019 13:44:39 +0000 Subject: [issue36003] set better defaults for TCPServer options Message-ID: <1550238279.45.0.385319342978.issue36003@roundup.psfhosted.org> New submission from Giampaolo Rodola' : socketserver.TCPServer provides the following defaults: allow_reuse_address = False request_queue_size = 5 Proposal is to: * have "allow_reuse_address = True" on POSIX in order to immediately reuse previous sockets which were bound on the same address and remained in TIME_WAIT state * have "request_queue_size = None" so that it's up to socket.listen() to choose a default reasonable value (usually 128) ---------- components: Library (Lib) keywords: easy messages: 335612 nosy: asvetlov, giampaolo.rodola, neologix, yselivanov priority: normal severity: normal status: open title: set better defaults for TCPServer options type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 08:45:36 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 15 Feb 2019 13:45:36 +0000 Subject: [issue35986] print() documentation typo? In-Reply-To: <1550060813.07.0.324151562751.issue35986@roundup.psfhosted.org> Message-ID: <1550238336.87.0.252922776984.issue35986@roundup.psfhosted.org> St?phane Wirtel added the comment: not in the CPython repo, just ask to regenerate the PyPI package. thanks ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 09:17:16 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Fri, 15 Feb 2019 14:17:16 +0000 Subject: [issue36003] set better defaults for TCPServer options In-Reply-To: <1550238279.45.0.385319342978.issue36003@roundup.psfhosted.org> Message-ID: <1550240236.9.0.215511051772.issue36003@roundup.psfhosted.org> Giampaolo Rodola' added the comment: Update: because "request_queue_size" is passed to server_activate() method which can be subclassed, a better default for not breaking backward compatibility is 0 (not None). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 09:24:18 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Feb 2019 14:24:18 +0000 Subject: [issue28043] Sane defaults for SSLContext options and ciphers In-Reply-To: <1473419921.81.0.961538270346.issue28043@psf.upfronthosting.co.za> Message-ID: <1550240658.64.0.588358872797.issue28043@roundup.psfhosted.org> STINNER Victor added the comment: New changeset b8eaec697a2b5d9d2def2950a0aa50e8ffcf1059 by Victor Stinner (stratakis) in branch '2.7': [2.7] bpo-28043: improved default settings for SSLContext (GH-10608) https://github.com/python/cpython/commit/b8eaec697a2b5d9d2def2950a0aa50e8ffcf1059 ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 09:28:36 2019 From: report at bugs.python.org (Paul Ganssle) Date: Fri, 15 Feb 2019 14:28:36 +0000 Subject: [issue36004] Add datetime.fromisocalendar Message-ID: <1550240916.35.0.451510247621.issue36004@roundup.psfhosted.org> New submission from Paul Ganssle : Datetime has many methods that "serializes" an instance to some other format - toordinal, timestamp, isoformat, etc. Most methods that "serialize" a datetime have a corresponding method that "deserializes" that method, or another way to reverse the operation: - strftime / strptime - timestamp / fromtimestamp - isoformat / fromisoformat - toordinal / fromordinal - timetuple / datetime(*thetuple[0:6]) However, as I found out when implementing `dateutil.parser.isoparse`, there is no simple way to invert `isocalendar()`. I have an implementation as part of dateutil.parser.isoparse: https://github.com/dateutil/dateutil/blob/master/dateutil/parser/isoparser.py#L297 If there are no objections, I'd like to add an implementation in CPython itself. Thinking the name should be `fromisocalendar`. ---------- components: Library (Lib) messages: 335616 nosy: belopolsky, lemburg, p-ganssle priority: low severity: normal status: open title: Add datetime.fromisocalendar type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 09:31:05 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 15 Feb 2019 14:31:05 +0000 Subject: [issue36004] Add datetime.fromisocalendar In-Reply-To: <1550240916.35.0.451510247621.issue36004@roundup.psfhosted.org> Message-ID: <1550241065.46.0.644961714859.issue36004@roundup.psfhosted.org> St?phane Wirtel added the comment: +1 ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 09:41:19 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Fri, 15 Feb 2019 14:41:19 +0000 Subject: [issue36003] set better defaults for TCPServer options In-Reply-To: <1550238279.45.0.385319342978.issue36003@roundup.psfhosted.org> Message-ID: <1550241679.44.0.500371821916.issue36003@roundup.psfhosted.org> Change by Giampaolo Rodola' : ---------- keywords: +patch pull_requests: +11908 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 09:45:20 2019 From: report at bugs.python.org (Charalampos Stratakis) Date: Fri, 15 Feb 2019 14:45:20 +0000 Subject: [issue32947] Support OpenSSL 1.1.1 In-Reply-To: <1519559680.67.0.467229070634.issue32947@psf.upfronthosting.co.za> Message-ID: <1550241920.98.0.364027651745.issue32947@roundup.psfhosted.org> Change by Charalampos Stratakis : ---------- pull_requests: +11910 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 09:48:23 2019 From: report at bugs.python.org (Dylan Cali) Date: Fri, 15 Feb 2019 14:48:23 +0000 Subject: [issue35132] python-gdb error: Python Exception Type does not have a target In-Reply-To: <1541068819.38.0.788709270274.issue35132@psf.upfronthosting.co.za> Message-ID: <1550242103.51.0.217043642179.issue35132@roundup.psfhosted.org> Dylan Cali added the comment: > Hum, Dylan: what is your gdb version? $ gdb --version GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1 > On Fedora 29 with gdb 8.2-6.fc29, it seems like .target() is useless I can confirm removing the .target() call in libpython.py resolved the issue for me with no ill effects > You can try faulthandler has a workaround. I'll give this a try, thank you ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 10:31:23 2019 From: report at bugs.python.org (Charalampos Stratakis) Date: Fri, 15 Feb 2019 15:31:23 +0000 Subject: [issue29136] Add OP_NO_TLSv1_3 In-Reply-To: <1483391244.76.0.29431388133.issue29136@psf.upfronthosting.co.za> Message-ID: <1550244683.76.0.175170868583.issue29136@roundup.psfhosted.org> Change by Charalampos Stratakis : ---------- pull_requests: +11911 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 11:29:43 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Feb 2019 16:29:43 +0000 Subject: [issue36005] [2.7] test_ssl failures on ARMv7 Ubuntu 2.7 with OpenSSL 1.1.1a Message-ID: <1550248183.17.0.361168114847.issue36005@roundup.psfhosted.org> New submission from STINNER Victor : Extract of pythoninfo: ssl.HAS_SNI: True ssl.OPENSSL_VERSION: OpenSSL 1.1.1a 20 Nov 2018 ssl.OPENSSL_VERSION_INFO: (1, 1, 1, 1, 15) ssl.OP_ALL: -0x7fffffac ssl.OP_NO_TLSv1_1: 0x10000000 https://buildbot.python.org/all/#/builders/92/builds/325 Many tests with TLS errors. A few examples: ERROR: test_connect (test.test_ssl.NetworkedTests) ... SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:727) ERROR: test_protocol_sslv23 (test.test_ssl.ThreadedTests) Connecting to an SSLv23 server with various client options ---------------------------------------------------------------------- ... self._sslobj.do_handshake() SSLError: [SSL: TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert protocol version (_ssl.c:727) ERROR: test_networked_good_cert (test.test_httplib.HTTPSTest) ... SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:727) ERROR: test_context_argument (test.test_urllibnet.urlopen_HttpsTests) ... IOError: [Errno socket error] [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:727) -- There are other failures which may be unrelated: ERROR: test_fileno (test.test_urllib2net.OtherNetworkTests) ... HTTPError: HTTP Error 404: Not Found This buildbot build contains 5 changes: [2.7] bpo-33570: TLS 1.3 ciphers for OpenSSL 1.1.1 (GH-6976) (GH-8760) (GH-10607)(3 hours ago) bpo-35746: Credit Colin Read and Nicolas Edet (GH-11866)(5 hours ago) Doc sidebar: 3.6 has moved to security-fix mode. (GH-11810)(5 days ago) [2.7] Fix url to core-mentorship mailing list (GH-11775). (GH-11778)(9 days ago) bpo-25592: Improve documentation of distutils data_files (GH-9767) (GH-11734)(13 days ago) I bet that it's a regression caused by: https://github.com/python/cpython/commit/c49f63c1761ce03df7850b9e0b31a18c432dac64 ---------- components: Tests messages: 335619 nosy: vstinner priority: normal severity: normal status: open title: [2.7] test_ssl failures on ARMv7 Ubuntu 2.7 with OpenSSL 1.1.1a type: security versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 11:30:00 2019 From: report at bugs.python.org (nr) Date: Fri, 15 Feb 2019 16:30:00 +0000 Subject: [issue35928] socket makefile read-write discards received data In-Reply-To: <1549542632.16.0.548779418887.issue35928@roundup.psfhosted.org> Message-ID: <1550248200.45.0.203661085202.issue35928@roundup.psfhosted.org> Change by nr : ---------- keywords: +patch pull_requests: +11912 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 11:31:43 2019 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 15 Feb 2019 16:31:43 +0000 Subject: [issue35996] Optional modulus argument for new math.prod() function In-Reply-To: <1550172876.35.0.867721234262.issue35996@roundup.psfhosted.org> Message-ID: <1550248303.29.0.531775864957.issue35996@roundup.psfhosted.org> Change by Mark Dickinson : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 11:37:37 2019 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 15 Feb 2019 16:37:37 +0000 Subject: [issue35880] math.sin has no backward error; this isn't documented In-Reply-To: <1549021657.57.0.382503652198.issue35880@roundup.psfhosted.org> Message-ID: <1550248657.13.0.91995728874.issue35880@roundup.psfhosted.org> Mark Dickinson added the comment: @jneb: Please could you clarify what sort of addition to the documentation you're proposing? Again, it's not clear what you mean by "backward error" here, or what sort of addition would be useful given the divergence of math function behaviours across platforms. Any documentation addition should cover more than just sin here; sin isn't at all special. Setting to pending. ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 11:42:21 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Feb 2019 16:42:21 +0000 Subject: [issue36005] [2.7] test_ssl failures on ARMv7 Ubuntu 2.7 with OpenSSL 1.1.1a In-Reply-To: <1550248183.17.0.361168114847.issue36005@roundup.psfhosted.org> Message-ID: <1550248941.39.0.799401305846.issue36005@roundup.psfhosted.org> STINNER Victor added the comment: It seems like this worker was offline for 1 month: build 324 was 1 month ago, whereas build 325 was 3 hours ago. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 11:42:41 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Feb 2019 16:42:41 +0000 Subject: [issue36005] [2.7] test_ssl failures on ARMv7 Ubuntu 2.7 with OpenSSL 1.1.1a In-Reply-To: <1550248183.17.0.361168114847.issue36005@roundup.psfhosted.org> Message-ID: <1550248961.07.0.383545748318.issue36005@roundup.psfhosted.org> Change by STINNER Victor : ---------- nosy: +cstratak, gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 11:43:43 2019 From: report at bugs.python.org (Davin Potts) Date: Fri, 15 Feb 2019 16:43:43 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1550249023.29.0.311308284749.issue35813@roundup.psfhosted.org> Davin Potts added the comment: These questions (originally asked in comments on GH-11816) seemed more appropriate to discuss here: Why should the user want to use `SharedMemory` directly? Why not just go through the manager? Also, perhaps a naive question: don't you _always_ need a `start()`ed manager in order for the processes to communicate? Doesn't `SharedMemoryServer` has to be involved? I think it helps to discuss the last question first. A SharedMemoryManager is *not* needed for two processes to share information across a shared memory block, nor is a SharedMemoryServer required. The docs have examples demonstrating this but here is another meant to showcase exactly this: Start up a Python shell and do the following: >>> from multiprocessing import shared_memory >>> shm = shared_memory.SharedMemory(name=None, size=10) >>> shm.buf[:5] = b'Feb15' >>> shm.name # Note this name and use it in the next steps 'psm_26792_26631' Start up a second Python shell in a new window and do the following: >>> from multiprocessing import shared_memory >>> also_shm = shared_memory.SharedMemory(name='psm_26792_26631') # Use that same name >>> bytes(also_shm.buf[:5]) b'Feb15' If also_shm.buf is further modified in the second shell, those changes will be visible on shm.buf in the first shell. The same is true of the reverse. The key point is that there is no sending of messages between the processes at all. In stark contrast, SyncManager offers and supports objects held in "distributed shared memory" where messages must be sent from one process to another to access or manipulate data; those objects held in "distributed shared memory" *must* have a SyncManager+Server to enable their use. That is not needed at all for SharedMemory because access to and manipulation of the data is performed directly without the cost-delay of messaging. This begs a new question, "so what is the SharedMemoryManager used for then?" The docs answer: To assist with the life-cycle management of shared memory especially across distinct processes, a BaseManager subclass, SharedMemoryManager, is also provided. Because shared memory blocks are not "owned" by a single process, they are not destroyed/freed when a process exits. A SharedMemoryManager is used to ensure the free-ing of a shared memory block when it is no longer needed. New SharedMemory instances may be created via a SharedMemoryManager (in which case their birth-to-death life-cycle is being managed) or they may be created directly as seen in the above example. Returning to the first question, "Why should the user want to use `SharedMemory` directly?", there are more use cases than these two: 1. In process 1, a shared memory block is created by calling SharedMemoryManager.SharedMemory(). In process 2, we need to attach to that existing shared memory block and can do so by referring to its name. This is accomplished as in the above example by simply calling SharedMemory(name='uniquename'). We do not want to attach to it via a second SharedMemoryManager because only one manager should oversee the life-cycle of a single shared memory block. 2. Sometimes direct management of the life-cycle of a shared memory block is desirable. For example, on systems supporting POSIX shared memory, it is a feature that shared memory blocks outlive processes. Some services choose to speed a service restart by preserving state data in shared memory, saving the newly restarted service from rebuilding it. The SharedMemoryManager provides one life-cycle strategy but can not cover all scenarios so the option to directly manage it is important. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 12:18:26 2019 From: report at bugs.python.org (Charalampos Stratakis) Date: Fri, 15 Feb 2019 17:18:26 +0000 Subject: [issue33570] OpenSSL 1.1.1 / TLS 1.3 cipher suite changes In-Reply-To: <1526648438.42.0.682650639539.issue33570@psf.upfronthosting.co.za> Message-ID: <1550251106.64.0.432807242208.issue33570@roundup.psfhosted.org> Change by Charalampos Stratakis : ---------- pull_requests: +11913 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 12:25:35 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Feb 2019 17:25:35 +0000 Subject: [issue35998] ./python -m test test_asyncio fails In-Reply-To: <1550225538.04.0.738886867119.issue35998@roundup.psfhosted.org> Message-ID: <1550251535.55.0.974540265011.issue35998@roundup.psfhosted.org> Change by STINNER Victor : ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 12:25:40 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Feb 2019 17:25:40 +0000 Subject: [issue35998] ./python -m test test_asyncio fails In-Reply-To: <1550225538.04.0.738886867119.issue35998@roundup.psfhosted.org> Message-ID: <1550251540.98.0.379540293021.issue35998@roundup.psfhosted.org> Change by STINNER Victor : ---------- components: +Tests, asyncio nosy: +asvetlov, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 12:27:47 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Feb 2019 17:27:47 +0000 Subject: [issue32947] Support OpenSSL 1.1.1 In-Reply-To: <1519559680.67.0.467229070634.issue32947@psf.upfronthosting.co.za> Message-ID: <1550251667.39.0.616100224387.issue32947@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 2149a9ad7a9d39d7d680ec0fb602042c91057484 by Victor Stinner (stratakis) in branch '2.7': [2.7] bpo-32947: Fixes for TLS 1.3 and OpenSSL 1.1.1 (GH-8761) (GH-11876) https://github.com/python/cpython/commit/2149a9ad7a9d39d7d680ec0fb602042c91057484 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 12:28:06 2019 From: report at bugs.python.org (nr) Date: Fri, 15 Feb 2019 17:28:06 +0000 Subject: [issue5038] urrlib2/httplib doesn't reset file position between requests In-Reply-To: <1232730438.9.0.904675957675.issue5038@psf.upfronthosting.co.za> Message-ID: <1550251686.72.0.50659702243.issue5038@roundup.psfhosted.org> nr added the comment: PR 11843 should fix the issue in master, I didn't check python 2.6 or prior versions. The problem is that in the first request sent to HTTP service the POST data is sent correctly. After that the HTTP server responds with 401 and the request is resent but the mmap file pointer is pointing now to the end of the file because it has been fully read in the requests before. The PR just seeks to the beginning of the file after the file has been read and sends the request with auth credentials including POST body. ---------- nosy: +nr _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 12:33:29 2019 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 15 Feb 2019 17:33:29 +0000 Subject: [issue35997] ImportError: dlopen failed: cannot locate symbol "PyBool_Type" In-Reply-To: <1550176592.88.0.291433310272.issue35997@roundup.psfhosted.org> Message-ID: <1550252009.48.0.12143578828.issue35997@roundup.psfhosted.org> Xavier de Gaye added the comment: It is not yet possible to cross-compile python extensions. The reason is that _init_posix() in Lib/sysconfig.py still reads the sysconfigdata module of the native compiler instead of the sysconfigdata of the cross-built one. See the patch in issue #28833. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 12:38:23 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Fri, 15 Feb 2019 17:38:23 +0000 Subject: [issue35998] ./python -m test test_asyncio fails In-Reply-To: <1550225538.04.0.738886867119.issue35998@roundup.psfhosted.org> Message-ID: <1550252303.97.0.565901739185.issue35998@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Not sure if it's related but there was a similar report on failure in freebsd bots with tls1.3 : issue35031 . Can you please add SSL info with ./python -m test.pythoninfo | grep ssl ? Test runs fine on my ubuntu 16.04 machine with below info $ ./python -m test.pythoninfo | grep ssl ssl.HAS_SNI: True ssl.OPENSSL_VERSION: OpenSSL 1.0.2g 1 Mar 2016 ssl.OPENSSL_VERSION_INFO: (1, 0, 2, 7, 15) ssl.OP_ALL: 0x800003ff ssl.OP_NO_TLSv1_1: 0x10000000 ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 12:45:20 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 15 Feb 2019 17:45:20 +0000 Subject: [issue36005] [2.7] test_ssl failures on ARMv7 Ubuntu 2.7 with OpenSSL 1.1.1a In-Reply-To: <1550248183.17.0.361168114847.issue36005@roundup.psfhosted.org> Message-ID: <1550252720.83.0.568477870109.issue36005@roundup.psfhosted.org> Change by Gregory P. Smith : ---------- superseder: -> test_httplib test_nntplib test_ssl fail on ARMv7 Debian buster buildbot _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 12:45:37 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 15 Feb 2019 17:45:37 +0000 Subject: [issue36005] [2.7] test_ssl failures on ARMv7 Ubuntu 2.7 with OpenSSL 1.1.1a In-Reply-To: <1550248183.17.0.361168114847.issue36005@roundup.psfhosted.org> Message-ID: <1550252737.58.0.0508220613877.issue36005@roundup.psfhosted.org> Change by Gregory P. Smith : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 12:47:02 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 15 Feb 2019 17:47:02 +0000 Subject: [issue36005] [2.7] test_ssl failures on ARMv7 Ubuntu 2.7 with OpenSSL 1.1.1a In-Reply-To: <1550248183.17.0.361168114847.issue36005@roundup.psfhosted.org> Message-ID: <1550252822.23.0.680291352751.issue36005@roundup.psfhosted.org> Gregory P. Smith added the comment: The buildbot was only offline for a few days while I upgraded the OS. do not look at the _delta_ between builds in the buildbot to determine a failure across that change as it went from ubuntu 14.04 to debian buster. 2.7 doesn't change often. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 12:48:55 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 15 Feb 2019 17:48:55 +0000 Subject: [issue36005] [2.7] test_ssl failures on ARMv7 Ubuntu 2.7 with OpenSSL 1.1.1a In-Reply-To: <1550248183.17.0.361168114847.issue36005@roundup.psfhosted.org> Message-ID: <1550252935.8.0.259723931486.issue36005@roundup.psfhosted.org> Gregory P. Smith added the comment: i duped this to the existing issue that was filed after the OS upgrade under the assumption it is the same thing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 12:53:42 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Feb 2019 17:53:42 +0000 Subject: [issue35998] test_asyncio: test_start_tls_server_1() TimeoutError on Fedora 29 In-Reply-To: <1550225538.04.0.738886867119.issue35998@roundup.psfhosted.org> Message-ID: <1550253222.08.0.707217529353.issue35998@roundup.psfhosted.org> Change by STINNER Victor : ---------- title: ./python -m test test_asyncio fails -> test_asyncio: test_start_tls_server_1() TimeoutError on Fedora 29 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 12:56:16 2019 From: report at bugs.python.org (Charalampos Stratakis) Date: Fri, 15 Feb 2019 17:56:16 +0000 Subject: [issue35998] test_asyncio: test_start_tls_server_1() TimeoutError on Fedora 29 In-Reply-To: <1550225538.04.0.738886867119.issue35998@roundup.psfhosted.org> Message-ID: <1550253376.59.0.859409772549.issue35998@roundup.psfhosted.org> Charalampos Stratakis added the comment: Fedora 29 has openssl 1.1.1 which seems to be related. ---------- nosy: +cstratak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 13:00:30 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Feb 2019 18:00:30 +0000 Subject: [issue35925] test_httplib test_nntplib test_ssl fail on ARMv7 Debian buster buildbot In-Reply-To: <1549503926.32.0.191493141556.issue35925@roundup.psfhosted.org> Message-ID: <1550253630.27.0.367777911435.issue35925@roundup.psfhosted.org> STINNER Victor added the comment: Does test_ssl pass on the master branch? ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 13:00:48 2019 From: report at bugs.python.org (nr) Date: Fri, 15 Feb 2019 18:00:48 +0000 Subject: [issue35928] socket makefile read-write discards received data In-Reply-To: <1549542632.16.0.548779418887.issue35928@roundup.psfhosted.org> Message-ID: <1550253648.33.0.919252993572.issue35928@roundup.psfhosted.org> nr added the comment: Added PR 11878, this will pass both this bug report and PR 3918 regression, the commit Ammar noted, it is an addition to this change. ---------- nosy: +nr _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 13:01:31 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Feb 2019 18:01:31 +0000 Subject: [issue33570] OpenSSL 1.1.1 / TLS 1.3 cipher suite changes In-Reply-To: <1526648438.42.0.682650639539.issue33570@psf.upfronthosting.co.za> Message-ID: <1550253691.77.0.900465433768.issue33570@roundup.psfhosted.org> STINNER Victor added the comment: New changeset c3c49ec56890d9d591f8fd1609c8436019f28f96 by Victor Stinner (stratakis) in branch '2.7': [2.7] bpo-33570: Enable OpenSSL 1.1.1 testing within the multissltests (GH-11879) https://github.com/python/cpython/commit/c3c49ec56890d9d591f8fd1609c8436019f28f96 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 13:08:32 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Fri, 15 Feb 2019 18:08:32 +0000 Subject: [issue36006] [good first issue] Align version changed for truncate in io module Message-ID: <1550254112.89.0.985997369649.issue36006@roundup.psfhosted.org> New submission from Cheryl Sabella : In the documentation page for the io module, under the truncate method, there is a version changed directive which is not properly aligned. https://docs.python.org/3/library/io.html#io.IOBase.truncate ---------- assignee: docs at python components: Documentation keywords: easy messages: 335633 nosy: cheryl.sabella, docs at python priority: normal severity: normal stage: needs patch status: open title: [good first issue] Align version changed for truncate in io module type: enhancement versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 13:22:29 2019 From: report at bugs.python.org (Chih-Hsuan Yen) Date: Fri, 15 Feb 2019 18:22:29 +0000 Subject: [issue32947] Support OpenSSL 1.1.1 In-Reply-To: <1519559680.67.0.467229070634.issue32947@psf.upfronthosting.co.za> Message-ID: <1550254949.4.0.819650361256.issue32947@roundup.psfhosted.org> Change by Chih-Hsuan Yen : ---------- nosy: -yan12125 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 13:24:52 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Fri, 15 Feb 2019 18:24:52 +0000 Subject: [issue36006] [good first issue] Align version changed for truncate in io module In-Reply-To: <1550254112.89.0.985997369649.issue36006@roundup.psfhosted.org> Message-ID: <1550255092.36.0.637123203827.issue36006@roundup.psfhosted.org> Emmanuel Arias added the comment: I take it ---------- nosy: +eamanu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 13:46:12 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Fri, 15 Feb 2019 18:46:12 +0000 Subject: [issue36006] [good first issue] Align version changed for truncate in io module In-Reply-To: <1550254112.89.0.985997369649.issue36006@roundup.psfhosted.org> Message-ID: <1550256372.94.0.920437454916.issue36006@roundup.psfhosted.org> Change by Emmanuel Arias : ---------- keywords: +patch pull_requests: +11914 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 13:49:11 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Fri, 15 Feb 2019 18:49:11 +0000 Subject: [issue35998] test_asyncio: test_start_tls_server_1() TimeoutError on Fedora 29 In-Reply-To: <1550225538.04.0.738886867119.issue35998@roundup.psfhosted.org> Message-ID: <1550256551.86.0.0255669540058.issue35998@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: I can confirm that this fails on a fresh fedora 29 VM as of commit 355f16f. The changes in PR 10011 make this test pass. SSL version and OS details $ cat /etc/fedora-release Fedora release 29 (Twenty Nine) $ uname -a Linux fedora-s-1vcpu-1gb-blr1-01 4.20.7-200.fc29.x86_64 #1 SMP Wed Feb 6 19:16:42 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux $ ./python -m test.pythoninfo | grep ssl ssl.HAS_SNI: True ssl.OPENSSL_VERSION: OpenSSL 1.1.1a FIPS 20 Nov 2018 ssl.OPENSSL_VERSION_INFO: (1, 1, 1, 1, 15) ssl.OP_ALL: 0x80000054 ssl.OP_NO_TLSv1_1: 0x10000000 # Test failure with tracemalloc $ ./python -X tracemalloc -m unittest -v test.test_asyncio.test_sslproto.SelectorStartTLSTests test_buf_feed_data (test.test_asyncio.test_sslproto.SelectorStartTLSTests) ... ok test_create_connection_ssl_failed_certificate (test.test_asyncio.test_sslproto.SelectorStartTLSTests) ... ok test_create_connection_ssl_slow_handshake (test.test_asyncio.test_sslproto.SelectorStartTLSTests) ... ok test_handshake_timeout (test.test_asyncio.test_sslproto.SelectorStartTLSTests) ... ok test_start_tls_client_buf_proto_1 (test.test_asyncio.test_sslproto.SelectorStartTLSTests) ... ok test_start_tls_client_corrupted_ssl (test.test_asyncio.test_sslproto.SelectorStartTLSTests) ... ok test_start_tls_client_reg_proto_1 (test.test_asyncio.test_sslproto.SelectorStartTLSTests) ... ok test_start_tls_server_1 (test.test_asyncio.test_sslproto.SelectorStartTLSTests) ... /root/cpython/Lib/asyncio/sslproto.py:321: ResourceWarning: unclosed transport _warn(f"unclosed transport {self!r}", ResourceWarning, source=self) Object allocated at (most recent call last): File "/root/cpython/Lib/asyncio/sslproto.py", lineno 446 self._app_transport = _SSLProtocolTransport(self._loop, self) ERROR test_start_tls_slow_client_cancel (test.test_asyncio.test_sslproto.SelectorStartTLSTests) ... Unhandled error in exception handler context: {'message': 'Future exception was never retrieved', 'exception': ConnectionResetError(104, 'Connection reset by peer'), 'future': } Traceback (most recent call last): File "/root/cpython/Lib/asyncio/base_events.py", line 1653, in call_exception_handler self._exception_handler(self, context) File "/root/cpython/Lib/test/test_asyncio/functional.py", line 22, in loop_exception_handler self.loop.default_exception_handler(context) AttributeError: 'NoneType' object has no attribute 'default_exception_handler' /root/cpython/Lib/asyncio/base_events.py:675: ResourceWarning: unclosed timer = events.TimerHandle(when, callback, args, self, context) Object allocated at (most recent call last): File "/root/cpython/Lib/asyncio/base_events.py", lineno 1360 sock = socket.socket(af, socktype, proto) ok test_start_tls_wrong_args (test.test_asyncio.test_sslproto.SelectorStartTLSTests) ... ok ====================================================================== ERROR: test_start_tls_server_1 (test.test_asyncio.test_sslproto.SelectorStartTLSTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/root/cpython/Lib/test/test_asyncio/test_sslproto.py", line 510, in test_start_tls_server_1 self.loop.run_until_complete(run_main()) File "/root/cpython/Lib/asyncio/base_events.py", line 589, in run_until_complete return future.result() File "/root/cpython/Lib/test/test_asyncio/test_sslproto.py", line 503, in run_main await asyncio.wait_for( File "/root/cpython/Lib/asyncio/tasks.py", line 461, in wait_for raise exceptions.TimeoutError() asyncio.exceptions.TimeoutError ---------------------------------------------------------------------- Ran 10 tests in 63.797s FAILED (errors=1) # With PR 10011 applied to Fedora $ ./python -X tracemalloc -m unittest -v test.test_asyncio.test_sslproto.SelectorStartTLSTests test_buf_feed_data (test.test_asyncio.test_sslproto.SelectorStartTLSTests) ... ok test_create_connection_ssl_failed_certificate (test.test_asyncio.test_sslproto.SelectorStartTLSTests) ... ok test_create_connection_ssl_slow_handshake (test.test_asyncio.test_sslproto.SelectorStartTLSTests) ... ok test_handshake_timeout (test.test_asyncio.test_sslproto.SelectorStartTLSTests) ... ok test_start_tls_client_buf_proto_1 (test.test_asyncio.test_sslproto.SelectorStartTLSTests) ... ok test_start_tls_client_corrupted_ssl (test.test_asyncio.test_sslproto.SelectorStartTLSTests) ... ok test_start_tls_client_reg_proto_1 (test.test_asyncio.test_sslproto.SelectorStartTLSTests) ... ok test_start_tls_server_1 (test.test_asyncio.test_sslproto.SelectorStartTLSTests) ... ok test_start_tls_slow_client_cancel (test.test_asyncio.test_sslproto.SelectorStartTLSTests) ... ok test_start_tls_wrong_args (test.test_asyncio.test_sslproto.SelectorStartTLSTests) ... ok ---------------------------------------------------------------------- Ran 10 tests in 3.734s OK ---------- nosy: +pablogsal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 13:52:06 2019 From: report at bugs.python.org (Mariatta Wijaya) Date: Fri, 15 Feb 2019 18:52:06 +0000 Subject: [issue36006] [good first issue] Align version changed for truncate in io module In-Reply-To: <1550254112.89.0.985997369649.issue36006@roundup.psfhosted.org> Message-ID: <1550256726.17.0.331689162861.issue36006@roundup.psfhosted.org> Mariatta Wijaya added the comment: Thanks! ---------- nosy: +Mariatta resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 14:02:42 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 15 Feb 2019 19:02:42 +0000 Subject: [issue36006] [good first issue] Align version changed for truncate in io module In-Reply-To: <1550254112.89.0.985997369649.issue36006@roundup.psfhosted.org> Message-ID: <1550257362.98.0.906471970182.issue36006@roundup.psfhosted.org> miss-islington added the comment: New changeset 522630a7462f606300f1e6e6818de191d9dc3fdf by Miss Islington (bot) (Emmanuel Arias) in branch 'master': bpo-36006: Fix versionchanged directive alignment in io module documentation (GH-11881) https://github.com/python/cpython/commit/522630a7462f606300f1e6e6818de191d9dc3fdf ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 14:02:54 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 15 Feb 2019 19:02:54 +0000 Subject: [issue36006] [good first issue] Align version changed for truncate in io module In-Reply-To: <1550254112.89.0.985997369649.issue36006@roundup.psfhosted.org> Message-ID: <1550257374.61.0.187924045525.issue36006@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11915 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 14:09:40 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 15 Feb 2019 19:09:40 +0000 Subject: [issue36006] [good first issue] Align version changed for truncate in io module In-Reply-To: <1550254112.89.0.985997369649.issue36006@roundup.psfhosted.org> Message-ID: <1550257780.67.0.331045752834.issue36006@roundup.psfhosted.org> miss-islington added the comment: New changeset 05f41363d4876a63acd8016cbf56b4f4e809e41f by Miss Islington (bot) in branch '3.7': bpo-36006: Fix versionchanged directive alignment in io module documentation (GH-11881) https://github.com/python/cpython/commit/05f41363d4876a63acd8016cbf56b4f4e809e41f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 14:10:41 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 15 Feb 2019 19:10:41 +0000 Subject: [issue35925] test_httplib test_nntplib test_ssl fail on ARMv7 Debian buster buildbot In-Reply-To: <1549503926.32.0.191493141556.issue35925@roundup.psfhosted.org> Message-ID: <1550257841.38.0.400368487152.issue35925@roundup.psfhosted.org> Gregory P. Smith added the comment: Not on this debian buster bot. look back a couple comments, there is a workaround. it seems to be an OpenSSL configuration issue / test expectations issue. I think we should ultimately get our test suite so that it passes in default OS distro OpenSSL configs. That could mean any of an altered environment for some tests, or skipping some tests in such an environment, or changing some tests to fit within modern OpenSSL desired ciphersuite/protocol setting constrains constraints - or a mix of all three. ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 14:17:27 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 15 Feb 2019 19:17:27 +0000 Subject: [issue35925] test_httplib test_nntplib test_ssl fail on ARMv7 Debian buster buildbot In-Reply-To: <1549503926.32.0.191493141556.issue35925@roundup.psfhosted.org> Message-ID: <1550258247.86.0.922443750188.issue35925@roundup.psfhosted.org> Change by Gregory P. Smith : ---------- nosy: +benjamin.peterson, ned.deily priority: normal -> release blocker stage: -> needs patch type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 14:17:44 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 15 Feb 2019 19:17:44 +0000 Subject: [issue35925] test_httplib test_nntplib test_ssl fail on ARMv7 Debian buster bot (OpenSSL 1.1.1a) In-Reply-To: <1549503926.32.0.191493141556.issue35925@roundup.psfhosted.org> Message-ID: <1550258264.66.0.201690364992.issue35925@roundup.psfhosted.org> Change by Gregory P. Smith : ---------- title: test_httplib test_nntplib test_ssl fail on ARMv7 Debian buster buildbot -> test_httplib test_nntplib test_ssl fail on ARMv7 Debian buster bot (OpenSSL 1.1.1a) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 14:18:54 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 15 Feb 2019 19:18:54 +0000 Subject: [issue35925] test_httplib test_nntplib test_ssl fail on ARMv7 Debian buster bot (OpenSSL 1.1.1a) In-Reply-To: <1549503926.32.0.191493141556.issue35925@roundup.psfhosted.org> Message-ID: <1550258334.4.0.278536050981.issue35925@roundup.psfhosted.org> Gregory P. Smith added the comment: release managers are free to defer this blocker. i'm just marking it as such for the purposes of making sure it is a conscious decision. The problem is more likely with our test suite vs the environment than it is with CPython itself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 14:19:43 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Fri, 15 Feb 2019 19:19:43 +0000 Subject: [issue36004] Add datetime.fromisocalendar In-Reply-To: <1550240916.35.0.451510247621.issue36004@roundup.psfhosted.org> Message-ID: <1550258383.57.0.038089282948.issue36004@roundup.psfhosted.org> Emmanuel Arias added the comment: +1 ---------- nosy: +eamanu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 14:22:35 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 15 Feb 2019 19:22:35 +0000 Subject: [issue35925] test_httplib test_nntplib test_ssl fail on ARMv7 Debian buster bot (OpenSSL 1.1.1a) In-Reply-To: <1549503926.32.0.191493141556.issue35925@roundup.psfhosted.org> Message-ID: <1550258555.24.0.826317154212.issue35925@roundup.psfhosted.org> Gregory P. Smith added the comment: FWIW I've just manually confirmed that running Python 2.7's test_ssl with OPENSSL_CONF=/invalid-path set passes on the debian buster buildbot host. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 14:40:39 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Fri, 15 Feb 2019 19:40:39 +0000 Subject: [issue35931] pdb: "debug print(" crashes with SyntaxError In-Reply-To: <1549555371.45.0.73616044825.issue35931@roundup.psfhosted.org> Message-ID: <1550259639.15.0.0260242090722.issue35931@roundup.psfhosted.org> Emmanuel Arias added the comment: ping reviewer :-) I test this PR and work fine on Ubuntu 18.04 ---------- nosy: +eamanu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 15:47:37 2019 From: report at bugs.python.org (Brennan D Baraban) Date: Fri, 15 Feb 2019 20:47:37 +0000 Subject: [issue35899] '_is_sunder' function in 'enum' module fails on empty string In-Reply-To: <1549376859.01.0.998806898699.issue35899@roundup.psfhosted.org> Message-ID: <1550263657.23.0.858574794865.issue35899@roundup.psfhosted.org> Brennan D Baraban <375 at holbertonschool.com> added the comment: Yes, I will submit a new PR today. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 15:52:56 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 15 Feb 2019 20:52:56 +0000 Subject: [issue35931] pdb: "debug print(" crashes with SyntaxError In-Reply-To: <1549555371.45.0.73616044825.issue35931@roundup.psfhosted.org> Message-ID: <1550263976.53.0.673915862054.issue35931@roundup.psfhosted.org> miss-islington added the comment: New changeset 4327705cfab3eb09073ec828570bbd8f789e1611 by Miss Islington (bot) (Daniel Hahler) in branch 'master': bpo-35931: Gracefully handle SyntaxError in pdb debug command (GH-11782) https://github.com/python/cpython/commit/4327705cfab3eb09073ec828570bbd8f789e1611 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 15:53:12 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 15 Feb 2019 20:53:12 +0000 Subject: [issue35931] pdb: "debug print(" crashes with SyntaxError In-Reply-To: <1549555371.45.0.73616044825.issue35931@roundup.psfhosted.org> Message-ID: <1550263992.47.0.72430104373.issue35931@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11916 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 16:19:48 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 15 Feb 2019 21:19:48 +0000 Subject: [issue35931] pdb: "debug print(" crashes with SyntaxError In-Reply-To: <1549555371.45.0.73616044825.issue35931@roundup.psfhosted.org> Message-ID: <1550265588.44.0.133445510207.issue35931@roundup.psfhosted.org> miss-islington added the comment: New changeset 6f352199e4447764bc472e34352d0dff4db8a52d by Miss Islington (bot) in branch '3.7': bpo-35931: Gracefully handle SyntaxError in pdb debug command (GH-11782) https://github.com/python/cpython/commit/6f352199e4447764bc472e34352d0dff4db8a52d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 16:20:40 2019 From: report at bugs.python.org (Zachary Ware) Date: Fri, 15 Feb 2019 21:20:40 +0000 Subject: [issue35931] pdb: "debug print(" crashes with SyntaxError In-Reply-To: <1549555371.45.0.73616044825.issue35931@roundup.psfhosted.org> Message-ID: <1550265640.96.0.319961011604.issue35931@roundup.psfhosted.org> Zachary Ware added the comment: Thanks for the patch! ---------- nosy: +zach.ware resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 16:30:34 2019 From: report at bugs.python.org (Eric Snow) Date: Fri, 15 Feb 2019 21:30:34 +0000 Subject: [issue22213] Make pyvenv style virtual environments easier to configure when embedding Python In-Reply-To: <1550080616.84.0.256720824268.issue22213@roundup.psfhosted.org> Message-ID: Eric Snow added the comment: On Wed, Feb 13, 2019 at 10:56 AM Steve Dower wrote: > Nick, Victor, Eric, (others?) - are you interested in having a virtual whiteboard session to brainstorm how the "perfect" initialization looks? And probably a follow-up to brainstorm how to get there without breaking the world? I don't think we're going to get to be in the same room anytime before the language summit, and it would be awesome to have something concrete to discuss there. Count me in. This is a pretty important topic and doing this would help accelerate our efforts by giving us a clearer common understanding and objective. FWIW, I plan on spending at least 5 minutes of my 25 minute PyCon talk on our efforts to fix up the C-API, and this runtime initialization stuff is an important piece. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 16:37:32 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 15 Feb 2019 21:37:32 +0000 Subject: [issue35996] Optional modulus argument for new math.prod() function In-Reply-To: <1550172876.35.0.867721234262.issue35996@roundup.psfhosted.org> Message-ID: <1550266652.66.0.138483233076.issue35996@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 16:48:44 2019 From: report at bugs.python.org (daniel hahler) Date: Fri, 15 Feb 2019 21:48:44 +0000 Subject: [issue35931] pdb: "debug print(" crashes with SyntaxError In-Reply-To: <1549555371.45.0.73616044825.issue35931@roundup.psfhosted.org> Message-ID: <1550267324.23.0.376076570105.issue35931@roundup.psfhosted.org> daniel hahler added the comment: Thanks for the review and backport! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 17:11:52 2019 From: report at bugs.python.org (Eric Snow) Date: Fri, 15 Feb 2019 22:11:52 +0000 Subject: [issue22213] Make pyvenv style virtual environments easier to configure when embedding Python In-Reply-To: <1550102948.01.0.552595371281.issue22213@roundup.psfhosted.org> Message-ID: Eric Snow added the comment: On Wed, Feb 13, 2019 at 5:09 PM Steve Dower wrote: > This is why I'm keen to design the ideal *user* API first (that is, write the examples of how you would use it) and then figure out how we can make it fit. > It's kind of the opposite approach from what you've been doing to adapt the existing code to suit particular needs. That makes sense. :) > For example, imagine instead of all the PySet*() functions followed by Py_Initialize() you could do this: > > PyObject *runtime = PyRuntime_Create(); FYI, we already have a _PyRuntimeState struct (see Include/internal/pycore_pystate.h) which is where I pulled in a lot of the static globals last year. Now there is one process-global _PyRuntime (created in Python/pylifecycle.c) in place of all those globals. Note that _PyRuntimeState is in parallel with PyInterpreterState, so not a PyObject. > /* optional calls */ > PyRuntime_SetAllocators(runtime, &my_malloc, &my_realloc, &my_free); > PyRuntime_SetHashSeed(runtime, 12345); Note that one motivation behind PEP 432 (and its config structs) is to keep all the config together. Having the one struct means you always clearly see what your options are. Another motivation is to keep the config (dense with public fields) separate from the actual run state (opaque). Having a bunch of config functions (and global variables in the status quo) means a lot more surface area to deal with when embedding, as opposed to 2 config structs + a few initialization functions (and a couple of helpers) like in PEP 432. I don't know that you consciously intended to move away from the dense config struct route, so I figured I'd be clear. :) > /* sets this as the current runtime via a thread local */ > auto old_runtime = PyRuntime_Activate(runtime); > assert(old_runtime == NULL) Hmm, there are two ways we could go with this: keep using TLS (or static global in the case of _PyRuntime) or update the C-API to require explicitly passing the context (e.g. runtime, interp, tstate, or some wrapper) into all the functions that need it. Of course, changing that would definitely need some kind of compatibility shim to avoid requiring massive changes to every extension out there, which would mean effectively 2 C-APIs mirroring each other. So sticking with TLS is simpler. Personally, I'd prefer going the explicit argument route. > > /* pretend triple quoting works in C for a minute ;) */ > const char *init_code = """ > [snip] > """; > > PyObject *globals = PyDict_New(); > /* only UTF-8 support at this stage */ > PyDict_SetItemString(globals, "argv0", PyUnicode_FromString(argv[0])); > PyRuntime_Initialize(runtime, init_code, globals); Nice. I like that this keeps the init code right by where it's used, while also making it much more concise and easier to follow (since it's Python code). > PyEval_EvalString("open('file.txt', 'w', encoding='gb18030').close()"); I definitely like the approach of directly embedding the Python code like this. :) Are there any downsides? > Maybe it's a terrible idea? Nah, we definitely want to maximize simplicity and your example offers a good shift in that direction. :) > Honestly I'd be inclined to do other big changes at the same time (make PyObject opaque and interface driven, for example). Definitely! Those aren't big blockers on cleaning up initialization though, are they? > My point is that if the goal is to "move the existing internals around" then that's all we'll ever achieve. If we can say "the goal is to make this example work" then we'll be able to do much more. Yep. I suppose part of the problem is that the embedding use cases aren't understood (or even recognized) well enough. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 17:20:57 2019 From: report at bugs.python.org (Eric Snow) Date: Fri, 15 Feb 2019 22:20:57 +0000 Subject: [issue35459] Use PyDict_GetItemWithError() instead of PyDict_GetItem() In-Reply-To: <1544525657.6.0.788709270274.issue35459@psf.upfronthosting.co.za> Message-ID: <1550269257.77.0.694297783949.issue35459@roundup.psfhosted.org> Eric Snow added the comment: Thanks, Serhiy. While the benchmark suite is our best tool available for measuring performance, I'm not sure what slowdown is significant in those results. @Victor, any thoughts? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 17:29:06 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 15 Feb 2019 22:29:06 +0000 Subject: [issue35984] test__xxsubinterpreters leaked [3, 4, 3] memory blocks, sum=1 In-Reply-To: <1550056203.45.0.644918745906.issue35984@roundup.psfhosted.org> Message-ID: <1550269746.01.0.910961827664.issue35984@roundup.psfhosted.org> miss-islington added the comment: New changeset 36433221f06d649dbd7e13f5fec948be8ffb90af by Miss Islington (bot) (Alexey Izbyshev) in branch 'master': bpo-35984: _xxsubinterpreters: Fix memory leak in _channel_send() (GH-11845) https://github.com/python/cpython/commit/36433221f06d649dbd7e13f5fec948be8ffb90af ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 17:35:12 2019 From: report at bugs.python.org (Eric Snow) Date: Fri, 15 Feb 2019 22:35:12 +0000 Subject: [issue35984] test__xxsubinterpreters leaked [3, 4, 3] memory blocks, sum=1 In-Reply-To: <1550056203.45.0.644918745906.issue35984@roundup.psfhosted.org> Message-ID: <1550270112.47.0.73363762609.issue35984@roundup.psfhosted.org> Eric Snow added the comment: Thanks, Alexey. I've merged the PR. As to finding and fixing leaks, I'd welcome any help you have to offer. :) Feel free to open an separate issue. One issue covering all the ones you find should be enough. If you find any non-trivial leaks or other issues then they should probably get separate issues. Thanks again! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 17:43:18 2019 From: report at bugs.python.org (Eric Snow) Date: Fri, 15 Feb 2019 22:43:18 +0000 Subject: [issue35810] Object Initialization does not incref Heap-allocated Types In-Reply-To: <1548275752.94.0.463880453345.issue35810@roundup.psfhosted.org> Message-ID: <1550270598.12.0.224563359219.issue35810@roundup.psfhosted.org> Change by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 17:48:04 2019 From: report at bugs.python.org (Anthony Sottile) Date: Fri, 15 Feb 2019 22:48:04 +0000 Subject: [issue36007] python3.8 a1 - docs build requires sphinx 1.7 but uses a 1.8 feature Message-ID: <1550270884.67.0.140749638005.issue36007@roundup.psfhosted.org> New submission from Anthony Sottile : doctest `:skipif:` was added in https://github.com/sphinx-doc/sphinx/issues/5273 Used here: https://github.com/python/cpython/blame/36433221f06d649dbd7e13f5fec948be8ffb90af/Doc/library/turtle.rst#L252-L253 Sphinx minimum version configured here: https://github.com/python/cpython/blob/36433221f06d649dbd7e13f5fec948be8ffb90af/Doc/conf.py#L44-L45 Should this be upped to 1.8 or should the :skipif: be removed? My guess is the former, I'd be happy to contribute a patch I hit this while packaging 3.8.0a1 for deadsnakes ---------- assignee: docs at python components: Build, Documentation messages: 335654 nosy: Anthony Sottile, docs at python priority: normal severity: normal status: open title: python3.8 a1 - docs build requires sphinx 1.7 but uses a 1.8 feature versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 18:16:57 2019 From: report at bugs.python.org (Mariatta Wijaya) Date: Fri, 15 Feb 2019 23:16:57 +0000 Subject: [issue36007] python3.8 a1 - docs build requires sphinx 1.7 but uses a 1.8 feature In-Reply-To: <1550270884.67.0.140749638005.issue36007@roundup.psfhosted.org> Message-ID: <1550272617.33.0.709582144211.issue36007@roundup.psfhosted.org> Mariatta Wijaya added the comment: Let's up the sphinx version. Thanks. ---------- nosy: +Mariatta _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 18:29:08 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Fri, 15 Feb 2019 23:29:08 +0000 Subject: [issue32808] subprocess.check_output opens an unwanted command line window after fall creator update In-Reply-To: <1518173531.96.0.467229070634.issue32808@psf.upfronthosting.co.za> Message-ID: <1550273348.67.0.000405707749619.issue32808@roundup.psfhosted.org> Change by Cheryl Sabella : ---------- resolution: -> works for me stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 18:34:33 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Fri, 15 Feb 2019 23:34:33 +0000 Subject: [issue23077] PEP 1: Allow Provisional status for PEPs In-Reply-To: <1418861338.72.0.949069550217.issue23077@psf.upfronthosting.co.za> Message-ID: <1550273673.69.0.708385685389.issue23077@roundup.psfhosted.org> Cheryl Sabella added the comment: Closing as third party since this moved to the PEP repository. ---------- resolution: -> third party stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 18:34:44 2019 From: report at bugs.python.org (Anthony Sottile) Date: Fri, 15 Feb 2019 23:34:44 +0000 Subject: [issue36007] python3.8 a1 - docs build requires sphinx 1.7 but uses a 1.8 feature In-Reply-To: <1550270884.67.0.140749638005.issue36007@roundup.psfhosted.org> Message-ID: <1550273684.44.0.0786720693241.issue36007@roundup.psfhosted.org> Change by Anthony Sottile : ---------- keywords: +patch pull_requests: +11917 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 18:36:05 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Fri, 15 Feb 2019 23:36:05 +0000 Subject: [issue30449] Improve __slots__ datamodel documentation In-Reply-To: <1495587707.13.0.0998591622446.issue30449@psf.upfronthosting.co.za> Message-ID: <1550273765.34.0.969358328894.issue30449@roundup.psfhosted.org> Change by Cheryl Sabella : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 18:39:45 2019 From: report at bugs.python.org (Eric Snow) Date: Fri, 15 Feb 2019 23:39:45 +0000 Subject: [issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h In-Reply-To: <1549069628.87.0.454232469964.issue35886@roundup.psfhosted.org> Message-ID: <1550273985.73.0.719194794555.issue35886@roundup.psfhosted.org> Eric Snow added the comment: Thanks, Victor! python-dev: https://mail.python.org/pipermail/python-dev/2019-February/156344.html Also, my PR already has a What's New entry in the porting section. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 18:41:18 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 15 Feb 2019 23:41:18 +0000 Subject: [issue36007] python3.8 a1 - docs build requires sphinx 1.7 but uses a 1.8 feature In-Reply-To: <1550270884.67.0.140749638005.issue36007@roundup.psfhosted.org> Message-ID: <1550274078.04.0.712802568778.issue36007@roundup.psfhosted.org> miss-islington added the comment: New changeset a16ab00c0b8e126ab82e7cb5098af3ea32d315ff by Miss Islington (bot) (Anthony Sottile) in branch 'master': bpo-36007: Bump minimum sphinx version to 1.8 (GH-11887) https://github.com/python/cpython/commit/a16ab00c0b8e126ab82e7cb5098af3ea32d315ff ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 18:41:42 2019 From: report at bugs.python.org (Mariatta Wijaya) Date: Fri, 15 Feb 2019 23:41:42 +0000 Subject: [issue36007] python3.8 a1 - docs build requires sphinx 1.7 but uses a 1.8 feature In-Reply-To: <1550270884.67.0.140749638005.issue36007@roundup.psfhosted.org> Message-ID: <1550274102.71.0.866878694921.issue36007@roundup.psfhosted.org> Mariatta Wijaya added the comment: Thanks! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 18:51:48 2019 From: report at bugs.python.org (Mariatta Wijaya) Date: Fri, 15 Feb 2019 23:51:48 +0000 Subject: [issue36007] python3.8 a1 - docs build requires sphinx 1.7 but uses a 1.8 feature In-Reply-To: <1550270884.67.0.140749638005.issue36007@roundup.psfhosted.org> Message-ID: <1550274708.23.0.720741154895.issue36007@roundup.psfhosted.org> Change by Mariatta Wijaya : ---------- versions: -Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 19:08:41 2019 From: report at bugs.python.org (Paul Ganssle) Date: Sat, 16 Feb 2019 00:08:41 +0000 Subject: [issue36004] Add datetime.fromisocalendar In-Reply-To: <1550240916.35.0.451510247621.issue36004@roundup.psfhosted.org> Message-ID: <1550275721.87.0.329226988111.issue36004@roundup.psfhosted.org> Change by Paul Ganssle : ---------- keywords: +patch pull_requests: +11918 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 19:09:02 2019 From: report at bugs.python.org (Davin Potts) Date: Sat, 16 Feb 2019 00:09:02 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1550275742.41.0.859781562817.issue35813@roundup.psfhosted.org> Davin Potts added the comment: Regarding the API of the SharedMemory class, its flags, mode, and read_only parameters are not universally enforced or simply not implemented on all platforms that offer POSIX Shared Memory or Windows Named Shared Memory. A simplified API for the SharedMemory class that behaves consistently across all platforms would avoid confusion for users. For users who have specific need of flags/mode/read_only controls on a platform that they know does indeed respect that control, they should still have a mechanism to leverage those controls. I propose a simpler, consistent-across-platforms API like: SharedMemory(name=None, create=False, size=0) *name* and *size* retain their purpose though the former now defaults to None. *create* is set to False to indicate no new shared memory block is to be created because we only wish to attach to an already existing shared memory block. When set to True, a new shared memory block will be created unless one already exists with the supplied unique name, in which case that block will be attached to and used. Example of attaching to an already existing shared memory block: SharedMemory(name='uniquename') Example of creating a new shared memory block where any new name will do: SharedMemory(create=True, size=128) Example of creating/attaching a shared memory block with a specific name: SharedMemory(name='specialsnowflake', create=True, size=4096) Even with its simplified API, SharedMemory will continue to be powered by PosixSharedMemory on systems where "POSIX Shared Memory" is implemented and powered by NamedSharedMemory on Windows systems. The API for PosixSharedMemory will remain essentially unchanged from its current form: PosixSharedMemory(name=None, flags=None, mode=0o600, size=0, read_only=False) The API for NamedSharedMemory will be updated to no longer attempt to mirror its POSIX counterpart: NamedSharedMemory(name=None, create=False, size=0, read_only=False) To be clear: the inconsistencies motivating this proposed API change is *not* only arising from differences between Windows and POSIX-supporting systems. For example, among systems implementing POSIX shared memory, the mode flag (which promises control over whether user/group/others can read/write to a shared memory block) is often but not always ignored; it differs from one OS to the next. Alternatives/variations to this proposed API change: * Leave the current APIs alone where all 3 classes have identical APIs. Feedback in discussions and from those experimenting with the code suggests this is creating confusion. * Change all 3 classes to have the matching APIs again. This unnecessarily thwarts the ability of users to exploit functionality that they know to be there on specific target platforms that they care about. * Do not expose flags/mode/read_only as part of the input paramemters to PosixSharedMemory/NamedSharedMemory but do expose them as class attributes instead. This arguably makes things unnecessarily complicated. This is not a simple topic but its complexity can be treated in a more straightforward way. * Use a parameter name other than 'create' (e.g. 'attach_only') in the newly proposed API. * Make all input parameters keyword-only for greater flexibility in the API in the future. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 19:15:42 2019 From: report at bugs.python.org (Paul Ganssle) Date: Sat, 16 Feb 2019 00:15:42 +0000 Subject: [issue36004] Add datetime.fromisocalendar In-Reply-To: <1550240916.35.0.451510247621.issue36004@roundup.psfhosted.org> Message-ID: <1550276142.97.0.28206630108.issue36004@roundup.psfhosted.org> Paul Ganssle added the comment: I have a first-pass PR, a few questions to address: 1. Should it take three arguments or a single 3-tuple? (I've gone with 3 arguments) 2. Since all three arguments are required, should we make them positional-only? 3. Should we allow time components in the `datetime` flavor of this? If so, I think we would also want datetime.isocalendar() to return a longer tuple, which would be backwards incompatible. 4. Should we add a `tz` argument in the datetime flavor? I think for questions 3 and 4 the answer is no, modelling after .toordinal/.fromordinal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 19:19:38 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Sat, 16 Feb 2019 00:19:38 +0000 Subject: [issue21018] [patch] added missing documentation about escaping characters for configparser In-Reply-To: <1395464420.76.0.68706986346.issue21018@psf.upfronthosting.co.za> Message-ID: <1550276378.83.0.268870498138.issue21018@roundup.psfhosted.org> Change by Cheryl Sabella : ---------- versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 19:25:41 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Sat, 16 Feb 2019 00:25:41 +0000 Subject: [issue27181] Add geometric mean to `statistics` module In-Reply-To: <1464901494.08.0.0111988914026.issue27181@psf.upfronthosting.co.za> Message-ID: <1550276741.49.0.0730480380823.issue27181@roundup.psfhosted.org> Cheryl Sabella added the comment: Updating the version in case this wanted to be considered for 3.8. ---------- versions: +Python 3.8 -Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 19:53:55 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Sat, 16 Feb 2019 00:53:55 +0000 Subject: [issue36008] [good first issue] Update documentation for 3.8 Message-ID: <1550278435.56.0.94881175235.issue36008@roundup.psfhosted.org> New submission from Cheryl Sabella : Please save this issue for a new contributor. If you have previously made a pull request to CPython, consider leaving this issue for someone else. Thanks! Similar to what PR 9501 did for updating references in the docs from 3.6 to 3.7, an update needs to be done for 3.8. ---------- assignee: docs at python components: Documentation keywords: easy messages: 335663 nosy: cheryl.sabella, docs at python priority: normal severity: normal stage: needs patch status: open title: [good first issue] Update documentation for 3.8 type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 20:10:29 2019 From: report at bugs.python.org (Zhiming Wang) Date: Sat, 16 Feb 2019 01:10:29 +0000 Subject: [issue33618] Support TLS 1.3 In-Reply-To: <1527086323.78.0.682650639539.issue33618@psf.upfronthosting.co.za> Message-ID: <1550279429.92.0.718094926285.issue33618@roundup.psfhosted.org> Change by Zhiming Wang : ---------- nosy: +zmwangx _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 21:09:01 2019 From: report at bugs.python.org (Mariatta Wijaya) Date: Sat, 16 Feb 2019 02:09:01 +0000 Subject: [issue36008] [good first issue] Update documentation for 3.8 In-Reply-To: <1550278435.56.0.94881175235.issue36008@roundup.psfhosted.org> Message-ID: <1550282941.46.0.0148307319916.issue36008@roundup.psfhosted.org> Mariatta Wijaya added the comment: Assigning this to me, to be worked on the mentored sprint at PyCon US Cleveland. Thanks. ---------- assignee: docs at python -> Mariatta nosy: +Mariatta _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 21:31:58 2019 From: report at bugs.python.org (muhzi) Date: Sat, 16 Feb 2019 02:31:58 +0000 Subject: [issue35997] ImportError: dlopen failed: cannot locate symbol "PyBool_Type" In-Reply-To: <1550176592.88.0.291433310272.issue35997@roundup.psfhosted.org> Message-ID: <1550284318.99.0.870590806084.issue35997@roundup.psfhosted.org> muhzi added the comment: Ah! I used the option -Bsymbolic while linking the extension to make it work and it did, but I figure it is not ideal. I will be checking that patch! ---------- components: +Extension Modules -Regular Expressions _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 23:16:23 2019 From: report at bugs.python.org (Chih-Hsuan Yen) Date: Sat, 16 Feb 2019 04:16:23 +0000 Subject: [issue33618] Support TLS 1.3 In-Reply-To: <1527086323.78.0.682650639539.issue33618@psf.upfronthosting.co.za> Message-ID: <1550290583.77.0.316848909208.issue33618@roundup.psfhosted.org> Change by Chih-Hsuan Yen : ---------- nosy: -yan12125 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 15 23:57:24 2019 From: report at bugs.python.org (Michael Sullivan) Date: Sat, 16 Feb 2019 04:57:24 +0000 Subject: [issue34235] PyArg_ParseTupleAndKeywords: support required keyword arguments In-Reply-To: <1532610257.0.0.56676864532.issue34235@psf.upfronthosting.co.za> Message-ID: <1550293044.01.0.425180251536.issue34235@roundup.psfhosted.org> Michael Sullivan added the comment: A downside of the "allow $ twice" approach is that it means splitting up the positional arguments, and a lot of the processing loop is built around the assumption that the index into the keyword list and the index into the argument tuple coincide (for positional arguments). It can certainly be done, but I worry it'll be an invasive change ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 00:32:31 2019 From: report at bugs.python.org (Eryk Sun) Date: Sat, 16 Feb 2019 05:32:31 +0000 Subject: [issue35688] "pip install --user numpy" fails on Python from the Windows Store In-Reply-To: <1546987520.17.0.731862977401.issue35688@roundup.psfhosted.org> Message-ID: <1550295151.83.0.833008326959.issue35688@roundup.psfhosted.org> Eryk Sun added the comment: It may suit the needs of NumPy and SciPy to use an assembly for DLL dependencies. With an assembly it's possible for two DLLs with the same name to load in a process and possible for a DLL to extend the assembly search path with up to nine relative paths at load time. The target directory can be up to two levels above the DLL directory (e.g. "..\..\assembly_dir"). An assembly can thus be packaged as a common dependency for other packages, and packages can depend on different versions of the assembly. For example, let's make a package that changes the _tkinter.pyd extension module to use a private assembly, which consists of the two DLL dependencies, "tcl86t.dll" and "tk86t.dll". Begin by copying "DLLs\_tkinter.pyd" to a package directory such as "Lib\site-packages\mytk". Modify the embedded #2 manifest in "_tkinter.pyd" (use mt.exe, or a GUI resource editor) to include a dependency on an assembly named "amd64_tcl_tk_8.6.6.0": Next, add the following component configuration file beside the extension module, named "_tkinter.pyd.2.config": This extends the assembly probing path that's used by the Fusion loader in the session server (csrss.exe). The Fusion loader probes for the assembly in four locations per directory. It checks for the assembly both as a DLL and as a manifest file, both in the directory and in a subdirectory that's named for the assembly. We'll be using a subdirectory with a manifest. "..\__winsxs__" resolves to "site-packages\__winsxs__". Create this directory and a subdirectory named "amd64_tcl_tk_8.6.6.0". To this, add the two DLL dependencies -- tcl86t.dll and tk86t.dll -- plus the following manifest file named "amd64_tcl_tk_8.6.6.0.manifest": That's all it takes. If configured properly, you should be able to import the extension module via `from mytk import _tkinter`. This will work in a virtual environment. However, I haven't checked whether the loader handles private assemblies in the same way in a store app. That's off my radar. > packages need to adopt to calling AddDllDirectory. As long as > python is built with ctypes, this is easy enough to adopt, even > though there are some caveats Avoid using ctypes.windll in libraries. It caches the ctypes.WinDLL instance, which caches function pointers. Projects that use the same DLLs thus can interfere with each other by setting incompatible prototypes. It also doesn't allow us to enable use_last_error to get reliable error handling. Also, the DLL_DIRECTORY_COOKIE return value is a pointer type, not a 32-bit integer. Even if we're not using it to cleanup afterwards (i.e. AddDllDirectory; LoadLibraryExW; RemoveDllDirectory), which we should be doing, we need the full 64-bit value to reliably check for failure (NULL). By some fluke, the low DWORD of the cookie could be 0. Here are the ctypes definitions using a private WinDLL instance and an errcheck function: import ctypes from ctypes import wintypes kernel32 = ctypes.WinDLL('kernel32', use_last_error=True) LOAD_LIBRARY_SEARCH_DEFAULT_DIRS = 0x00001000 DLL_DIRECTORY_COOKIE = wintypes.LPVOID def _errcheck_zero(result, func, args): if not result: raise ctypes.WinError(ctypes.get_last_error()) return args kernel32.AddDllDirectory.errcheck = _errcheck_zero kernel32.AddDllDirectory.restype = DLL_DIRECTORY_COOKIE kernel32.AddDllDirectory.argtypes = (wintypes.LPCWSTR,) kernel32.RemoveDllDirectory.errcheck = _errcheck_zero kernel32.RemoveDllDirectory.argtypes = (DLL_DIRECTORY_COOKIE,) kernel32.LoadLibraryExW.errcheck = _errcheck_zero kernel32.LoadLibraryExW.restype = wintypes.HMODULE kernel32.LoadLibraryExW.argtypes = ( wintypes.LPCWSTR, wintypes.HANDLE, wintypes.DWORD) Don't call SetDefaultDllDirectories. Use LoadLibraryExW(path, None, LOAD_LIBRARY_SEARCH_DEFAULT_DIRS). ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 01:12:24 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 Feb 2019 06:12:24 +0000 Subject: [issue15248] Better explain "TypeError: 'tuple' object is not callable" In-Reply-To: <1341379722.78.0.0866285571225.issue15248@psf.upfronthosting.co.za> Message-ID: <1550297544.2.0.509796653197.issue15248@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset 62e4481238b82f111ffb1104a4b97099dd83ae2b by Serhiy Storchaka in branch 'master': bpo-15248: Emit a compiler warning when missed a comma before tuple or list. (GH-11757) https://github.com/python/cpython/commit/62e4481238b82f111ffb1104a4b97099dd83ae2b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 01:13:36 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 Feb 2019 06:13:36 +0000 Subject: [issue15248] Better explain "TypeError: 'tuple' object is not callable" In-Reply-To: <1341379722.78.0.0866285571225.issue15248@psf.upfronthosting.co.za> Message-ID: <1550297616.38.0.161570355983.issue15248@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 01:23:00 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 Feb 2019 06:23:00 +0000 Subject: [issue34235] PyArg_ParseTupleAndKeywords: support required keyword arguments In-Reply-To: <1532610257.0.0.56676864532.issue34235@psf.upfronthosting.co.za> Message-ID: <1550298180.11.0.433660322019.issue34235@roundup.psfhosted.org> Serhiy Storchaka added the comment: > I am missing how my PR changes the current behavior, though? Sorry, I misunderstood your changes to the documentation. Other option is to introduce a special symbol that makes the following parameters required if used after (or instead of) $. Like in "O|O$@O|O" or "O|O at O|O". It does not look nice too. I think we should try several different ways and choose the one that has simple implementation, minimal performance penalty and looks less confusing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 01:29:30 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 Feb 2019 06:29:30 +0000 Subject: [issue35798] duplicate SyntaxWarning: "is" with a literal In-Reply-To: <1548083625.41.0.59098075844.issue35798@roundup.psfhosted.org> Message-ID: <1550298570.32.0.510422867435.issue35798@roundup.psfhosted.org> Serhiy Storchaka added the comment: This warning is not special. I'll add a helper for testing that all syntax warnings are emitted only once later. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 01:29:48 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 Feb 2019 06:29:48 +0000 Subject: [issue35798] duplicate SyntaxWarning: "is" with a literal In-Reply-To: <1548083625.41.0.59098075844.issue35798@roundup.psfhosted.org> Message-ID: <1550298588.63.0.738370808257.issue35798@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset 4583525835baf8fc7bd49a60725d1e8c49ef92b3 by Serhiy Storchaka in branch 'master': bpo-35798: Fix duplicate SyntaxWarning: "is" with a literal. (GH-11639) https://github.com/python/cpython/commit/4583525835baf8fc7bd49a60725d1e8c49ef92b3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 02:06:10 2019 From: report at bugs.python.org (Brennan D Baraban) Date: Sat, 16 Feb 2019 07:06:10 +0000 Subject: [issue35899] '_is_sunder' function in 'enum' module fails on empty string In-Reply-To: <1549376859.01.0.998806898699.issue35899@roundup.psfhosted.org> Message-ID: <1550300770.58.0.476912277939.issue35899@roundup.psfhosted.org> Change by Brennan D Baraban <375 at holbertonschool.com>: ---------- keywords: +patch pull_requests: +11919 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 02:13:24 2019 From: report at bugs.python.org (Martin Panter) Date: Sat, 16 Feb 2019 07:13:24 +0000 Subject: [issue5038] urrlib2/httplib doesn't reset file position between requests In-Reply-To: <1232730438.9.0.904675957675.issue5038@psf.upfronthosting.co.za> Message-ID: <1550301204.07.0.981227468533.issue5038@roundup.psfhosted.org> Martin Panter added the comment: For 3.7+ (where iterable objects are supported), I suggest: 1. Document the problem as a limitation of handlers like AbstractBasicAuthHandler, and consider raising an exception instead of trying to upload a file or iterable a second time. 2. Clarify the behaviour for different types of the ?urllib.request? data parameter. I understand ?file-like objects? means objects with a ?read? attribute, and the ?read? method is called in preference to iteration or treating the parameter as a ?bytes? object. Despite the bug title, I don?t think the library should mess with the file position. Certainly not when making a single request. But it should already be possible for the caller to supply a custom iterable object that resets the file position: class FileReiterator: def __iter__(self): self.file.seek(0) while True: chunk = self.file.read(self.chunksize) yield chunk if len(chunk) < self.chunksize: break ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 02:23:55 2019 From: report at bugs.python.org (Ned Deily) Date: Sat, 16 Feb 2019 07:23:55 +0000 Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org> Message-ID: <1550301835.91.0.27331618172.issue35746@roundup.psfhosted.org> Ned Deily added the comment: New changeset 2a3af94b7e4d7851986043348128e312ddbb2451 by Ned Deily (Victor Stinner) in branch '3.6': bpo-35746: Credit Colin Read and Nicolas Edet (GH-11865) https://github.com/python/cpython/commit/2a3af94b7e4d7851986043348128e312ddbb2451 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 02:33:22 2019 From: report at bugs.python.org (Ned Deily) Date: Sat, 16 Feb 2019 07:33:22 +0000 Subject: [issue24658] open().write() and .read() fails on 2 GB+ data (OS X) In-Reply-To: <1437188368.42.0.0977367912313.issue24658@psf.upfronthosting.co.za> Message-ID: <1550302402.96.0.871854494653.issue24658@roundup.psfhosted.org> Change by Ned Deily : ---------- assignee: ned.deily -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 03:04:16 2019 From: report at bugs.python.org (Alexander Mohr) Date: Sat, 16 Feb 2019 08:04:16 +0000 Subject: [issue36009] weakref.ReferenceType is not a valid typing type Message-ID: <1550304256.68.0.492420733825.issue36009@roundup.psfhosted.org> New submission from Alexander Mohr : For valid types which encapsulate other types, like typing.List or typing.Tuple, you can declare what's contained in them like so: foo: typing.List[int] = [] Unfortunately weakref.ReferenceType does not allow you to do this. You get the error: >>> foo: weakref.ReferenceType[typing.Any] = None Traceback (most recent call last): File "", line 1, in TypeError: 'type' object is not subscriptable so either ReferenceType should be fixed or a new type made available. ---------- components: Library (Lib) messages: 335674 nosy: thehesiod priority: normal severity: normal status: open title: weakref.ReferenceType is not a valid typing type type: behavior versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 03:09:38 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sat, 16 Feb 2019 08:09:38 +0000 Subject: [issue36009] weakref.ReferenceType is not a valid typing type In-Reply-To: <1550304256.68.0.492420733825.issue36009@roundup.psfhosted.org> Message-ID: <1550304578.96.0.202520986336.issue36009@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +gvanrossum, levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 03:30:42 2019 From: report at bugs.python.org (Alexander Mohr) Date: Sat, 16 Feb 2019 08:30:42 +0000 Subject: [issue36009] weakref.ReferenceType is not a valid typing type In-Reply-To: <1550304256.68.0.492420733825.issue36009@roundup.psfhosted.org> Message-ID: <1550305842.57.0.713341381101.issue36009@roundup.psfhosted.org> Alexander Mohr added the comment: I'm not a typing expert, but from what I understand you could do: class Bar: pass foo: Callable[[], Bar] = weakref.ref(Bar()) but you lose the typing weakref.ref. OTOH if you simply do: foo: weakref.ref = weakref.ref(Bar()) you lose the info of Bar ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 04:14:22 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 16 Feb 2019 09:14:22 +0000 Subject: [issue35904] Add statistics.fmean(seq) In-Reply-To: <1549411161.36.0.783593325223.issue35904@roundup.psfhosted.org> Message-ID: <1550308462.39.0.506046991113.issue35904@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- keywords: +patch pull_requests: +11920 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 04:21:57 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Cardona?=) Date: Sat, 16 Feb 2019 09:21:57 +0000 Subject: [issue34971] add support for tls/ssl sessions in asyncio In-Reply-To: <1539420460.92.0.788709270274.issue34971@psf.upfronthosting.co.za> Message-ID: <1550308917.68.0.634504994284.issue34971@roundup.psfhosted.org> R?mi Cardona added the comment: Anything I can do to get the ball rolling? Let me know who to get in touch with and *how*, and I will. Thanks ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 04:44:34 2019 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 Feb 2019 09:44:34 +0000 Subject: [issue35848] readinto is not a method on io.TextIOBase In-Reply-To: <1548753520.89.0.970608711782.issue35848@roundup.psfhosted.org> Message-ID: <1550310274.81.0.0874717338304.issue35848@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch pull_requests: +11921 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 04:45:08 2019 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 16 Feb 2019 09:45:08 +0000 Subject: [issue34028] Python 3.7.0 wont compile with SSL Support 1.1.0 > alledged missing X509_VERIFY_PARAM_set1_host() support In-Reply-To: <1530609211.5.0.56676864532.issue34028@psf.upfronthosting.co.za> Message-ID: <1550310308.12.0.827765289889.issue34028@roundup.psfhosted.org> Change by Chris Jerdonek : ---------- nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 04:48:09 2019 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 16 Feb 2019 09:48:09 +0000 Subject: [issue35949] Move PyThreadState into Include/internal/pycore_pystate.h In-Reply-To: <1549677619.84.0.322696563838.issue35949@roundup.psfhosted.org> Message-ID: <1550310489.5.0.93932202289.issue35949@roundup.psfhosted.org> Stefan Behnel added the comment: >From Cython's point of view, the important fields in PyThreadState are the tracing/profiling and exception related ones. We're not using anything else. Users can explicitly opt out of the access to the exception fields by defining a C macro, at the expense of a bit of performance. I doubt that anyone is really doing that, though, because, why would they? I'm not sure if we could avoid direct field access for profiling and tracing at all. You can look at the code, it's a whole bunch of macros that mimic what CPython does in ceval: https://github.com/cython/cython/blob/master/Cython/Utility/Profile.c I should note that both features are not enabled by default. Users have to explicitly enable profiling support via a directive, and even doubly opt in to tracing by enabling a compiler directive and a C macro. So production code will often not rely on these fields, but developers would want to use them and some might keep profiling support enabled also in their production code. My guess is that tracing is most often used for test coverage analysis. ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 05:00:46 2019 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 16 Feb 2019 10:00:46 +0000 Subject: [issue35949] Move PyThreadState into Include/internal/pycore_pystate.h In-Reply-To: <1549677619.84.0.322696563838.issue35949@roundup.psfhosted.org> Message-ID: <1550311246.09.0.972429399145.issue35949@roundup.psfhosted.org> Stefan Behnel added the comment: Oh, and I forgot the new trashcan support. Cython will also start to use that in its next release, so that adds the trashcan related attributes to the list. https://github.com/cython/cython/pull/2842/files ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 05:48:06 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 16 Feb 2019 10:48:06 +0000 Subject: [issue35892] Fix awkwardness of statistics.mode() for multimodal datasets In-Reply-To: <1549219885.57.0.86866159357.issue35892@roundup.psfhosted.org> Message-ID: <1550314086.65.0.76940261769.issue35892@roundup.psfhosted.org> Raymond Hettinger added the comment: I would stick with "first_tie=False". That caters to the common case, avoids API complications, and does something similar to what other stats packages are doing. ----- API Survey ---- Maple: """This function is only guaranteed to return one potential mode - in cases where multiple modes exist, only the first detected mode is guaranteed to be returned.""" -- https://www.maplesoft.com/support/help/maple/view.aspx?path=Statistics%2fMode R: 'R does not have a standard in-built function to calculate mode.' -- https://www.tutorialspoint.com/r/r_mean_median_mode.htm Matlab: "When there are multiple values occurring equally frequently, mode returns the smallest of those values. ... If A is an empty 0-by-0 matrix, mode(A) returns NaN." -- https://www.mathworks.com/help/matlab/ref/mode.html Mathematica: "The mode of a set of data is implemented in the Wolfram Language as Commonest[data]. ... When several elements occur with equal frequency, Commonest[list,?] picks first the ones that occur first in list." -- http://mathworld.wolfram.com/Mode.html and https://reference.wolfram.com/language/ref/Commonest.html SciPy: "If there is more than one such value, only the smallest is returned." -- https://docs.scipy.org/doc/scipy-0.19.1/reference/generated/scipy.stats.mode.html SAS: "Most frequent value (if not unique, the smallest mode)" -- https://documentation.sas.com/?docsetId=qcug&docsetTarget=qcug_capability_sect225.htm&docsetVersion=14.2&locale=en ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 06:28:23 2019 From: report at bugs.python.org (Francis MB) Date: Sat, 16 Feb 2019 11:28:23 +0000 Subject: [issue35892] Fix awkwardness of statistics.mode() for multimodal datasets In-Reply-To: <1549219885.57.0.86866159357.issue35892@roundup.psfhosted.org> Message-ID: <1550316503.14.0.841116202842.issue35892@roundup.psfhosted.org> Francis MB added the comment: Good point Raymond! Only a minor observation on the packages API: [1] SciPy: scipy.stats.mode(a, axis=0, nan_policy='propagate') "Returns an array of the modal (most common) **value** in the passed array." --> Here it claims to return just ONE value And use of different policies on parameters : nan_policy : {?propagate?, ?raise?, ?omit?}, optional Defines how to handle when input contains nan. ?propagate? returns nan, ?raise? throws an error, ?omit? performs the calculations ignoring nan values. Default is ?propagate?. Equivalent one could say 'multivalue_policy' [2] Matlab: Mode: "Most frequent **values** in array" ...returns the sample mode of A, which is the most frequently occurring *value* in A...." IMHO it seems inconsistent *values* vs. *value* (or a doc-bug ?). An a question: Does it that mean that mode in that case really should potentially return an array of values, e.g. all the values with equal frequency? In that case the user has the chance to get the first, the last or just all, ... ---- [1] https://docs.scipy.org/doc/scipy-0.19.1/reference/generated/scipy.stats.mode.html [2] https://la.mathworks.com/help/matlab/ref/mode.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 07:11:58 2019 From: report at bugs.python.org (Ivan Levkivskyi) Date: Sat, 16 Feb 2019 12:11:58 +0000 Subject: [issue36009] weakref.ReferenceType is not a valid typing type In-Reply-To: <1550304256.68.0.492420733825.issue36009@roundup.psfhosted.org> Message-ID: <1550319118.24.0.416147284085.issue36009@roundup.psfhosted.org> Ivan Levkivskyi added the comment: This question appeared several times before, and the conclusion is that we are not going to do this. There are many cases in standard library that are generic in stubs (and by nature) but are not declared as such at runtime, so we simply can't provide a typing equivalent for all of them. In Python 3.7 you can just use from __future__ import annotations for those, and/or use the recipes described here https://mypy.readthedocs.io/en/latest/common_issues.html#using-classes-that-are-generic-in-stubs-but-not-at-runtime Maybe at some point we will start using `Generic` in standard library, but for now I am closing this as wontfix. ---------- resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 08:26:06 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 Feb 2019 13:26:06 +0000 Subject: [issue35798] duplicate SyntaxWarning: "is" with a literal In-Reply-To: <1548083625.41.0.59098075844.issue35798@roundup.psfhosted.org> Message-ID: <1550323566.56.0.530165351275.issue35798@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- pull_requests: +11922 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 08:31:17 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 16 Feb 2019 13:31:17 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1550323877.26.0.305147360834.issue35813@roundup.psfhosted.org> Giampaolo Rodola' added the comment: > Because shared memory blocks are not "owned" by a single process, they are not destroyed/freed when a process exits. 1) it seems SharedMemory.close() does not destroy the memory region (I'm able to re-attach to it via name). If I'm not mistaken only the manager can do that. As such it probably makes sense to have an unlink() or destroy() methods. Maybe SharedMemory should support the with statement. 2) it seems SharedMemory is only supposed to handle `memoryview`s. I suggest to turn SharedMemory.buf in a read-onl property: >>> sm = shared_memory.SharedMemory(None, size=23) >>> sm.buf = [1,2,3] >>> sm.close() File "/home/giampaolo/svn/cpython-shm/Lib/multiprocessing/shared_memory.py", line 166, in close self.buf.release() AttributeError: 'list' object has no attribute 'release' 3) it seems "size" kwarg cannot be zero (current default). Suggestion: either choose default != 0 or make it a mandatory arg: >>> shared_memory.SharedMemory(name=None) ValueError: cannot mmap an empty file >>> shared_memory.SharedMemory(name=None, size=0) ValueError: cannot mmap an empty file >>> shared_memory.SharedMemory(name=None, size=1) PosixSharedMemory('psm_32161_20838', size=1) >>> 4) I wonder if we should have multiprocessing.active_memory_children() or something, similar to multiprocessing.active_children() so that one can do: @atexit.register def cleanup(): for x in multiprocessing.active_memory_children(): x.close() # or unlink/destroy I guess that would be useful for people not using a manager. Also, I'm not sure if active_memory_children() can return meaningful results with a brand new process (I suppose it can't). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 08:31:38 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Sat, 16 Feb 2019 13:31:38 +0000 Subject: [issue36008] [good first issue] Update documentation for 3.8 In-Reply-To: <1550278435.56.0.94881175235.issue36008@roundup.psfhosted.org> Message-ID: <1550323898.41.0.0922114085266.issue36008@roundup.psfhosted.org> Cheryl Sabella added the comment: Awesome! Thanks. If I find anything else, I'll flag it accordingly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 08:36:18 2019 From: report at bugs.python.org (Windson Yang) Date: Sat, 16 Feb 2019 13:36:18 +0000 Subject: [issue35892] Fix awkwardness of statistics.mode() for multimodal datasets In-Reply-To: <1549219885.57.0.86866159357.issue35892@roundup.psfhosted.org> Message-ID: <1550324178.22.0.167415276112.issue35892@roundup.psfhosted.org> Windson Yang added the comment: IMHO, we don't need to add the option. We can return the smallest value from the **table** instead of the code below. if len(table) == 1: return table[0][0] [1] https://github.com/python/cpython/blob/master/Lib/statistics.py#L502 ---------- nosy: +Windson Yang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 09:10:18 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sat, 16 Feb 2019 14:10:18 +0000 Subject: [issue36000] __debug__ is a keyword but not a keyword In-Reply-To: <1550233328.67.0.392552434895.issue36000@roundup.psfhosted.org> Message-ID: <1550326218.31.0.577928873676.issue36000@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: See also issue34464 ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 09:15:36 2019 From: report at bugs.python.org (Kumar Akshay) Date: Sat, 16 Feb 2019 14:15:36 +0000 Subject: [issue29466] pickle does not serialize Exception __cause__ field In-Reply-To: <1486406196.69.0.481594976881.issue29466@psf.upfronthosting.co.za> Message-ID: <1550326536.24.0.756479482176.issue29466@roundup.psfhosted.org> Kumar Akshay added the comment: Hey, can I work on this? ---------- nosy: +kakshay _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 09:20:20 2019 From: report at bugs.python.org (jt) Date: Sat, 16 Feb 2019 14:20:20 +0000 Subject: [issue36010] Please provide a .zip Windows release of Python that is not crippled/for embedding only Message-ID: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org> New submission from jt : It would be really useful if you could provide a .zip Windows release of Python that is not crippled/for embedding only. The reason is simply is that right now, I am having constant pain & trouble with it writing an automated build script for Windows (.bat) that works on a Python-free machine. Specifically the installer has: 1.) no usable functionality in an automated build environment (%PATH% is very unnecessary or even undesirable to set up for a Python install only temporarily downloaded for a build) 2.) possibly conflicts with existing installs (making an automated build break/affect other Python installs/leaving other side effects, which is extremely undesirable and ugly) 3.) can break into a completely unusable state when interrupted (where the install doesn't complete, but running it again also doesn't, needing complicated special logic to nuke it) NONE of these would be an issue if there was just a .zip. And there is, of course, in form of the embedded install - but that one is useless to me for an automated build because I need pip, and it doesn't support running pip. ---------- components: Installation, Windows messages: 335687 nosy: jt, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Please provide a .zip Windows release of Python that is not crippled/for embedding only versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 09:20:45 2019 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 16 Feb 2019 14:20:45 +0000 Subject: [issue22213] Make pyvenv style virtual environments easier to configure when embedding Python In-Reply-To: <1408275761.36.0.915361061447.issue22213@psf.upfronthosting.co.za> Message-ID: <1550326845.67.0.479548221973.issue22213@roundup.psfhosted.org> Nick Coghlan added the comment: Steve, you're describing the goals of PEP 432 - design the desired API, then write the code to implement it. So while Victor's goal was specifically to get PEP 540 implemented, mine was just to make it so working on the startup sequence was less awful (and in particular, to make it possible to rewrite getpath.c in Python at some point). Unfortunately, it turns out that redesigning a going-on-thirty-year-old startup sequence takes a while, as we first have to discover what all the global settings actually *are* :) https://www.python.org/dev/peps/pep-0432/#invocation-of-phases describes an older iteration of the draft API design that was reasonably accurate at the point where Eric merged the in-development refactoring as a private API (see https://bugs.python.org/issue22257 and https://www.python.org/dev/peps/pep-0432/#implementation-strategy for details). However, that initial change was basically just a skeleton - we didn't migrate many of the settings over to the new system at that point (although we did successfully split the import system initialization into two parts, so you can enable builtin and frozen imports without necessarily enabling external ones). The significant contribution that Victor then made was to actually start migrating settings into the new structure, adapting it as needed based on the goals of PEP 540. Eric updated quite a few more internal APIs as he worked on improving the subinterpreter support. Between us, we also made a number of improvements to https://docs.python.org/3/c-api/init.html based on what we learned in the process of making those changes. So I'm completely open to changing the details of the API that PEP 432 is proposing, but the main lesson we've learned from what we've done so far is that CPython's long history of embedding support *does* constrain what we can do in practice, so it's necessary to account for feasibility of implementation when considering what we want to offer. Ideally, the next step would be to update PEP 432 with a status report on what was learned in the development of Python 3.7 with the new configuration structures, and what the internal startup APIs actually look like now. Even though I reviewed quite a few of Victor and Eric's PR, even I don't have a clear overall picture of where we are now, and I suspect Victor and Eric are in a similar situation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 09:48:49 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 16 Feb 2019 14:48:49 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1550328529.6.0.0916738536291.issue35813@roundup.psfhosted.org> Giampaolo Rodola' added the comment: > Because shared memory blocks are not "owned" by a single process... > [...] > I propose a simpler, consistent-across-platforms API like: > SharedMemory(name=None, create=False, size=0) Maybe something like this instead? SharedMemory(name=None, attach_if_exists=False, size=0) The use case I'm thinking about is 2 distinct processes/apps which agree on a common fixed name. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 09:59:40 2019 From: report at bugs.python.org (Jeremy Kloth) Date: Sat, 16 Feb 2019 14:59:40 +0000 Subject: [issue36010] Please provide a .zip Windows release of Python that is not crippled/for embedding only In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org> Message-ID: <1550329180.63.0.602872464889.issue36010@roundup.psfhosted.org> Jeremy Kloth added the comment: For a "tool-style" installation of Python, see the 'PCBuild\find_python.bat' script in the Python source tree, specifically the nuget section. Ultimately, it is just: > nuget install pythonx86 -ExcludeVersion -OutputDirectory "some\path" which will create an installation of the latest python at "some\path\pythonx86". ---------- nosy: +jkloth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 10:32:21 2019 From: report at bugs.python.org (jt) Date: Sat, 16 Feb 2019 15:32:21 +0000 Subject: [issue36010] Please provide a .zip Windows release of Python that is not crippled/for embedding only In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org> Message-ID: <1550331141.33.0.176697198104.issue36010@roundup.psfhosted.org> jt added the comment: Is nuget a standard windows utility? What happens if that process is interrupted? What happens if I install it twice to different folders? What happens if I want a specific python version? Don't get me wrong maybe it can do all these things, but why on earth do I need this? I can even produce this .zip myself, just the regular installer run with /Q and then copy it, but I need to do that for each new release and everyone else who might need it will also need to do that. Is it really that much work to do this centrally once so it's available for everyone? After all the embeddable install is already available in such a way, it's just that being the stripped down embeddable version its use is limited ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 11:21:01 2019 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 16 Feb 2019 16:21:01 +0000 Subject: [issue22213] Make pyvenv style virtual environments easier to configure when embedding Python In-Reply-To: <1408275761.36.0.915361061447.issue22213@psf.upfronthosting.co.za> Message-ID: <1550334061.0.0.552084661769.issue22213@roundup.psfhosted.org> Nick Coghlan added the comment: Note also that Eric and I haven't failed to agree with Victor on an API, as Victor hasn't actually written a concrete proposal *for* a public API (neither as a PR updating PEP 432, nor as a separate PEP). The current implementation does NOT follow the PEP as written, because _Py_CoreConfig ended up with all the settings in it, when it's supposed to be just the bare minimum needed to get the interpreter to a point where it can run Python code that only accesses builtin and frozen modules. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 11:21:02 2019 From: report at bugs.python.org (Jeremy Kloth) Date: Sat, 16 Feb 2019 16:21:02 +0000 Subject: [issue36010] Please provide a .zip Windows release of Python that is not crippled/for embedding only In-Reply-To: <1550331141.33.0.176697198104.issue36010@roundup.psfhosted.org> Message-ID: Jeremy Kloth added the comment: On Sat, Feb 16, 2019 at 8:32 AM jt wrote: > Is nuget a standard windows utility? No, but if your script can download a zip of Python, it could download the nuget executable. > What happens if that process is interrupted? Same as interrupting an unzip operation. > What happens if I install it twice to different folders? NuGet installs are basically just an unzip process, so you simply have 2 different folders containing a Python installation. > What happens if I want a specific python version? Use '-Version ' as an option to 'nuget install'. can be any of the versions listed on https://www.nuget.org/packages/python/. > Don't get me wrong maybe it can do all these things, but why on earth do I need this? I can even produce this .zip myself, just the regular installer run with /Q and then copy it, but I need to do that for each new release and everyone else who might need it will also need to do that. > > Is it really that much work to do this centrally once so it's available for everyone? After all the embeddable install is already available in such a way, it's just that being the stripped down embeddable version its use is limited It is available to all and is provided by the Windows release manager, see https://www.nuget.org/packages/python/. ---------- nosy: +jeremy.kloth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 11:25:02 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 16 Feb 2019 16:25:02 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1550334302.2.0.0777164361939.issue35813@roundup.psfhosted.org> Giampaolo Rodola' added the comment: Hopefully my last iteration: =) 1) As for SharedMemoryManager, I believe it should live in multiprocessing.managers, not shared_memory.py. It's a subclass of Manager and behaves like a manager (start(), shutdown(), get_server(), etc.), so IMO that's its natural place. 2) Same for SharedMemoryServer (which is a subclass of multiprocessing.managers.Server). SharedMemoryTracker appears to be just a support class for it, so IMO it should either be private or not documented. 3) ShareableList name is kinda inconsistent with other classes (they all have a "Shared" prefix). I'd call it SharedList instead. 4) Ideally the (public) APIs I have in mind are: multiprocessing.managers.SharedMemoryManager multiprocessing.managers._SharedMemoryTracker multiprocessing.managers.SharedMemoryServer (not documented) multiprocessing.shared_memory.SharedMemory multiprocessing.shared_memory.SharedList multiprocessing.shared_memory.WindowsNamedSharedMemory (maybe) multiprocessing.shared_memory.PosixSharedMemory (maybe) AFAIU there are 2 distinct use-cases at play: - two separate apps agreeing on a specific fixed memory *name* to attach to, which will use SharedMemory/List directly - one single app using a manager and a worker, which will use SharedMemoryManager, and get SharedMemory/List directly from it (see https://github.com/python/cpython/pull/11816/files#r257458137) IMO the 2 different namespaces would reflect and enforce this separation of use cases. 4) I have some reservations about SharedMemory's "flags" and "mode" args. * flags (O_CREAT, O_EXCL, O_CREX, O_TRUNC, O_RDONLY): it seems it may conflict with "read_only" arg. I wonder if we could achieve the same goal with more high-level named args instead (e.g. "create" / "attach_if_exists"). If in doubt, I would recommend to simply drop it for now. * mode: same considerations as above. Doc says "Its specification is not enforceable on all platforms" which makes me think it's probably better to drop it (also not sure why it defaults to 384). Hope this helps. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 11:30:59 2019 From: report at bugs.python.org (Mayank Asthana) Date: Sat, 16 Feb 2019 16:30:59 +0000 Subject: [issue35975] Put back the ability to parse files where async/await aren't keywords In-Reply-To: <1549931018.54.0.209945896308.issue35975@roundup.psfhosted.org> Message-ID: <1550334659.45.0.468462517984.issue35975@roundup.psfhosted.org> Change by Mayank Asthana : ---------- nosy: +masthana _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 11:40:16 2019 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 16 Feb 2019 16:40:16 +0000 Subject: [issue35810] Object Initialization does not incref Heap-allocated Types In-Reply-To: <1548275752.94.0.463880453345.issue35810@roundup.psfhosted.org> Message-ID: <1550335216.38.0.0767040648576.issue35810@roundup.psfhosted.org> Nick Coghlan added the comment: Having types created through the stable ABI potentially be deallocated when their instances are deallocated is indeed a major problem, and fixing that seems worth the risk of some types that were designed to handle that become immortal. ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 11:41:28 2019 From: report at bugs.python.org (Davin Potts) Date: Sat, 16 Feb 2019 16:41:28 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1550335288.11.0.688508575185.issue35813@roundup.psfhosted.org> Davin Potts added the comment: @giampaolo: > 1) it seems SharedMemory.close() does not destroy the memory region > (I'm able to re-attach to it via name). If I'm not mistaken only > the manager can do that. Correct, close() does not and should not destroy the memory region because other processes may still be using it. Only a call to unlink() triggers the destruction of the memory region and so unlink() should only be called once across all the processes with access to that shared memory block. The unlink() method is available on the SharedMemory class. No manager is required. This is also captured in the docs. > 2) I suggest to turn SharedMemory.buf in a read-onl property Good idea! I will make this change today, updating GH-11816. > 3) it seems "size" kwarg cannot be zero (current default) >From the docs: When attaching to an existing shared memory block, set to 0 (which is the default). This permits attaching to an existing shared memory block by name without needing to also already know its size. > 4) I wonder if we should have multiprocessing.active_memory_children() or something I also think this would be helpful but... > I'm not sure if active_memory_children() can return meaningful results with a brand new process (I suppose it can't). You are right. As an aside, I think it interesting that in the implementation of "System V Shared Memory", its specification called for something like a system-wide registry where all still-allocated shared memory blocks were listed. Despite the substantial influence System V Shared Memory had on the more modern implementations of "POSIX Shared Memory" and Windows' "Named Shared Memory", neither chose to make it part of their specification. By encouraging the use of SharedMemoryManager to track and ensure cleanup, we are providing a reliable and cross-platform supportable best practice. If something more low-level is needed by a user, they can choose to manage cleanup themselves. This seems to parallel how we might encourage, "when opening a file, always use a with statement", yet users can still choose to call open() and later close() when they wish. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 11:47:11 2019 From: report at bugs.python.org (Davin Potts) Date: Sat, 16 Feb 2019 16:47:11 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1550335631.54.0.637912843268.issue35813@roundup.psfhosted.org> Davin Potts added the comment: @giampaolo: > Maybe something like this instead? > SharedMemory(name=None, attach_if_exists=False, size=0) I think this misses the use case when wanting to ensure we only attach to an existing shared memory block and if it does not exist, we should raise an exception because we can not continue. (If the shared memory block should already be there but it is not, this means something bad happened earlier and we might not know how to recover here.) I believe the two dominant use cases to address are: 1) I want to create a shared memory block (either with or without a pre-conceived name). 2) I want to attach to an existing shared memory block by its unique name. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 11:51:05 2019 From: report at bugs.python.org (jt) Date: Sat, 16 Feb 2019 16:51:05 +0000 Subject: [issue36010] Please provide a .zip Windows release of Python that is not crippled/for embedding only In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org> Message-ID: <1550335865.58.0.816741180606.issue36010@roundup.psfhosted.org> jt added the comment: So is that a no for a regular .zip release here? https://www.python.org/downloads/windows/ Don't get me wrong I'm all for options, I just don't get why there is no simple tool-less binary archive for Windows. Why are the only options different variants of installers or additional tools? Why do I need to fetch another tool just to fetch Python? If this is the final decision then I recommend at least mentioning NuGet prominently on here: https://www.python.org/downloads/windows/ (as an alternative to the so-so regular windows installer, since while that one works well enough for a manual install, for an automated one it's just not that ideal) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 12:17:53 2019 From: report at bugs.python.org (mattip) Date: Sat, 16 Feb 2019 17:17:53 +0000 Subject: [issue35688] "pip install --user numpy" fails on Python from the Windows Store In-Reply-To: <1546987520.17.0.731862977401.issue35688@roundup.psfhosted.org> Message-ID: <1550337473.07.0.331707037629.issue35688@roundup.psfhosted.org> mattip added the comment: @eryksun thanks for the details. I didn't realize assemblyBinding was supported by the generic runtime framework, the documentation https://docs.microsoft.com/en-us/dotnet/framework/deployment/how-the-runtime-locates-assemblies seems to suggest it is a dotnet feature. How can we confirm it is supported for older windows versions (XP) as well as app store installed apps? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 12:25:39 2019 From: report at bugs.python.org (Davin Potts) Date: Sat, 16 Feb 2019 17:25:39 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1550337939.23.0.705969149397.issue35813@roundup.psfhosted.org> Davin Potts added the comment: @giampaolo: > 1) As for SharedMemoryManager, I believe it should live in multiprocessing.managers, not shared_memory.py. I am happy to see it live in multiprocessing.managers so long as we can provide a clean way of handling what happens on a platform where we can not support shared memory blocks. (We have implementations for PosixSharedMemory and NamedSharedMemory which together cover Windows, Linux, MacOS, the *BSDs, and possibly others but that does not cover everything.) @Neil has already raised this question of what do we want the behavior to be on these unsupported platforms on import? If everything dependent upon shared memory blocks remains inside shared_memory.py, then we could raise a ModuleNotFoundError or ImportError or similar when attempting to `import shared_memory`. If we move SharedMemoryManager to live in multiprocessing.managers, we need to decide how to handle (and communicate to the user appropriately) its potential absence. So far, I am unable to find a good example of another module where they have chosen to split up such code rather than keeping it all bottled up inside a single module, but perhaps I have missed something? > 2) Same for SharedMemoryServer (which is a subclass of multiprocessing.managers.Server). Same thing as above. If we decide how to handle the unsupported platforms on import, we can re-organize appropriately. > 3) ShareableList name is kinda inconsistent with other classes (they all have a "Shared" prefix). I'd call it SharedList instead. Oooh, interesting. I am happy to see a name change here. To share how I came up with its current name: I had thought to deliberately break the naming pattern here to make it stand out. The others, SharedMemory, SharedMemoryManager, and SharedMemoryServer, are all focused on the shared memory block itself which is something of a more primitive concept (like accessing SharedMemory.buf as a memoryview) compared to working with something like a list (a less primitive, more widely familiar concept). Likewise, I thought a dict backed by shared memory might be called a ShareableDict and other things like a NumPy array backed by shared memory might be called a ShareableNDArray or similar. I was hoping to find a different pattern for the names of these objects-backed-by-shared-memory-blocks, but I am uncertain I found the best name. > 4) I have some reservations about SharedMemory's "flags" and "mode" args. It sounds like you are agreeing with what I advocated in msg335660 (up above). Great! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 12:30:42 2019 From: report at bugs.python.org (Jeremy Kloth) Date: Sat, 16 Feb 2019 17:30:42 +0000 Subject: [issue36010] Please provide a .zip Windows release of Python that is not crippled/for embedding only In-Reply-To: <1550335865.58.0.816741180606.issue36010@roundup.psfhosted.org> Message-ID: Jeremy Kloth added the comment: > Why do I need to fetch another tool just to fetch Python? Well, you still need a tool to fetch the zip and you need another tool to unzip it. If not, how are you bootstrapping your script for those uses? > If this is the final decision then I recommend at least mentioning NuGet prominently on here: https://www.python.org/downloads/windows/ As far as final say goes, I have no control, but it does seem somewhat reasonable. > (as an alternative to the so-so regular windows installer, since while that one works well enough for a manual install, for an automated one it's just not that ideal) So are you just looking for an automated regular installer where the end result shows up in the Installed Apps list, or a scriptable build-tool package? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 12:36:56 2019 From: report at bugs.python.org (jt) Date: Sat, 16 Feb 2019 17:36:56 +0000 Subject: [issue36010] Please provide a .zip Windows release of Python that is not crippled/for embedding only In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org> Message-ID: <1550338616.88.0.552959522812.issue36010@roundup.psfhosted.org> jt added the comment: > Well, you still need a tool to fetch the zip and you need another tool to unzip it Windows 10 actually has everything necessary around, so I don't! That's kind of the beauty of it, the other point being that every dev knows how to deal with a .zip (more than know NuGet, i would assume) > So are you just looking for an automated regular installer where the end result shows up in the Installed Apps list, or a scriptable build-tool package? Actually I would explicitly NOT want it to show up in Installed Apps, or any other sort of advanced script. Sorry if I haven't been clear on that, I want to avoid any such side effects as much as possible. What I want is the TARGET FOLDER result of running the regular windows installer. If you haven't noticed, this folder can be copied onto a system where it was never "installed" and with a simple .bat script (or powershell, ...) that sets %PATH% and %PYTHONPATH% you can use it in-place with no further install required. That's why I'm asking for this, there doesn't seem to be even any need to install Python, and since for an automated build I want to minimize side effects, why would I want anything more than a .zip in that case? I can only see downsides ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 12:38:46 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 16 Feb 2019 17:38:46 +0000 Subject: [issue36010] Please provide a .zip Windows release of Python that is not crippled/for embedding only In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org> Message-ID: <1550338726.57.0.198358815284.issue36010@roundup.psfhosted.org> Steve Dower added the comment: > So is that a no for a regular .zip release here? https://www.python.org/downloads/windows/ Correct, it's a no. The main reason is because people use it wrong and get into trouble, and we don't want to support that. (More after the docs link below) > If this is the final decision then I recommend at least mentioning NuGet prominently on here: https://www.python.org/downloads/windows/ Agreed. It's already documented at https://docs.python.org/3/using/windows.html and perhaps that's the better page to feature prominently on the download page? Basically, the breakdown of packages we want to provide are: * easy for "light interactive use" (Windows Store) * full developer kit (regular installer) * app-local redistributable (embeddable package) * zero-impact CI install (nuget package) * "install" from source (PC/layout script) (Note the last is currently undocumented outside of the script itself, but I'm planning to write something soon.) Adding more than this to our support burden is not desirable until we have more [highly responsive] volunteers (not even core committers, we're just at a point where technical support staff would be helpful). ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 12:44:35 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 16 Feb 2019 17:44:35 +0000 Subject: [issue35892] Fix awkwardness of statistics.mode() for multimodal datasets In-Reply-To: <1549219885.57.0.86866159357.issue35892@roundup.psfhosted.org> Message-ID: <1550339075.39.0.98591180817.issue35892@roundup.psfhosted.org> Raymond Hettinger added the comment: > We can return the smallest value from the **table** instead > of the code below. Internally, that does too much work and then throws most of it away. The difference between Counter(data).most_common()[1] and Counter(data).most_common(1) is that the former materializes the entire items iterator into a list and does a full sort, while the latter is memory friendly and makes a single pass with min(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 12:47:39 2019 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 16 Feb 2019 17:47:39 +0000 Subject: [issue35971] Documentation should warn about code injection from current working directory In-Reply-To: <1549921560.53.0.488831977782.issue35971@roundup.psfhosted.org> Message-ID: <1550339259.7.0.667623393192.issue35971@roundup.psfhosted.org> Nick Coghlan added the comment: Folks use "python -m myproject.mymodule" to run code that they're working on all the time - it's currently the only way to get sys.path right for cases like that (otherwise you're exposed to the double import trap, where you can get two copies of a submodule under different names). We even use it to run CPython's own test suite as "./python -m test". That said, over in https://bugs.python.org/issue33053#msg314192 I came up with a plausible migration path away from doing that implicitly - we'd just have to introduce a spelling for doing it explicitly instead, and relative imports give us a precedent for that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 13:01:40 2019 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 16 Feb 2019 18:01:40 +0000 Subject: [issue35962] Slight error in words in [ 2.4.1. String and Bytes literals ] In-Reply-To: <1549879959.7.0.265215879488.issue35962@roundup.psfhosted.org> Message-ID: <1550340100.65.0.788295884263.issue35962@roundup.psfhosted.org> Nick Coghlan added the comment: I agree the current text is ambiguous given how often folks refer to the newline escape sequence as a "newline", but it isn't wrong - it's just talking about escaping literal newlines in your source code like: >>> "This is a \ ... single-line string" 'This is a single-line string' When this paragraph is being updated, it would be good to add a cross-reference down to the table of escape sequences later in the section. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 13:24:46 2019 From: report at bugs.python.org (jt) Date: Sat, 16 Feb 2019 18:24:46 +0000 Subject: [issue36010] Please provide a .zip Windows release of Python that is not crippled/for embedding only In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org> Message-ID: <1550341486.54.0.0747635543494.issue36010@roundup.psfhosted.org> jt added the comment: Okay, I just tested switching to the NuGet package and appear to have hit some sort of issue: C:\myproject\tools\windows\.python-win\python\tools\python.exe: No module named venv Traceback (most recent call last): File "C:\myproject\tools\windows\\windows-build.py", line 129, in do_build() File "C:\myproject\tools\windows\\windows-build.py", line 60, in do_build ".python-win", "spen-venv") File "C:\myproject\tools\windows\.python-win\python\tools\Lib\subprocess.py", line 395, in check_output **kwargs).stdout File "C:\myproject\tools\windows\.python-win\python\tools\Lib\subprocess.py", line 487, in run output=stdout, stderr=stderr) subprocess.CalledProcessError: Command '['C:\\myproject\\tools\\windows\\.python-win\\python\\tools\\python.exe', '-m', 'venv', 'C:\\myproject\\tools\\windows\\.python-win\\spen-venv']' returned non-zero exit status 1. Is this expected with the NuGet variant? Can I somehow install 'venv' on top? I didn't have this issue with the install obtained by running the Windows Installer with /Q ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 13:36:12 2019 From: report at bugs.python.org (Christian Korneck) Date: Sat, 16 Feb 2019 18:36:12 +0000 Subject: [issue36011] ssl - tls verify on Windows 10 fails Message-ID: <1550342172.09.0.390948819907.issue36011@roundup.psfhosted.org> New submission from Christian Korneck : Hello, I have the impression that there's a general issue with how the Python stdlib module `ssl` uses the Windows certificate store to read the "bundle" of trusted Root CA certificates. At a first look, I couldn't find this issue documented elsewhere, so I'm trying to describe it below (apologies if its a duplicate). This issue leads to that on a standard Windows 10 installation with a standard Python 2.x or 3.x installation TLS verification for many webservers fails out of the box, including for common domains/webservers with a highly correct TLS setup like https://google.de or https://www.verisign.com/ . In short: On a vanilla Win 10 with a vanilla Python 2/3 installation, HTTPS connections to "commonly trusted" domain names fail out of the box. Example with Python 2.7.15: >>> import urllib2 >>> response = urllib2.urlopen("https://google.de") [...] ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:726) Expected Behavior: TLS verify succeeds Actual Behavior: TLS verify fails Affected Python version/environment: I believe every Python version that uses the Windows certificate store is affected (since 3.4 / 2.7.9). However, I've only tested 2.7.11, 2.7.15, 3.7.2 (all 64 bit). I did test on Windows 10 1803, 1809, Windows Server 2019 1809 (all Pro x64 with latest patchlevel, i.e. the Jan 2019 cumulative update). All tested Python versions on all tested Windows 10 versions show the same behavior. -------- Details: 1.) Background - Factor1: Python's "ssl" std lib Since Python 3.4 / 2.7.9 the ssl lib uses the Windows certificate store to get a "bundle" of the trusted root CA certificates. (Some Python libraries like requests bring their own ca bundle though, usually through certifi. These libs are not affected). However, the ssl lib is not using the Windows SCHANNEL library but instead bundles its own copy of openssl. - Factor2: Windows 10 behavior Windows provides a certificate store, a vendor managed and updated "bundle" of Trusted Root CA certificates and a library for TLS operations called SCHANNEL (the native Windows openssl equivalent). On Windows 10, the list of pre-installed Trusted Root CA certificates is very minimal. On Windows 10 1809 only 12 Root CAs are known by the certificate store. In comparison certifi (Mozilla cabundle) currently lists 134 trusted RootCAs. Many widely trusted RootCAs are missing out of the box in the Windows certstore. Instead there's an online download mechanism used by the SCHANNEL library to download additional trusted root CA certificates from a Microsoft server when they are needed for the first time. Example: The certificate currently used for https://google.de was signed by an IntermediateCA which was signed by the RootCA "GlobalSign Root CA - R2". The cert for this RootCA is not out of the box present in the Windows certstore and therefore not trusted. When I make a HTTPS connection to this domain with a client that uses the SCHANNEL library (i.e. Microsoft Edge or Internet Explorer browser), the connection succeeds and is shown as "trusted". Afterwards the previously missing RootCA certificate appears in the windows certstore. (The Windows certstores can get inspected with the GUIs certml.msc (Machine store) and certmgr.msc (User store)). 2.) Behavior - install a vanilla Windows 10 1809 with default settings - install a vanilla Python 2.7.15 and/or 3.7.2 In Python: c:\python27\python.exe Python 2.7.15 (v2.7.15:ca079a3ea3, Apr 30 2018, 16:30:26) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import socket, ssl >>> context = ssl.SSLContext(ssl.PROTOCOL_TLS) >>> context.verify_mode = ssl.CERT_REQUIRED >>> context.check_hostname = True # by default there are no cacerts in the context >>> len(context.get_ca_certs()) 0 >>> context.load_default_certs() >>> len(context.get_ca_certs()) # after loading the cacerts from the Windows cert store "ROOT", we are seeing some - but it's only 12 root cacerts in a vanilla Windows 10 (compared to 134 in the certifi / mozilla cabundle!) 12 >>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) >>> ssl_sock = context.wrap_socket(s, server_hostname='www.google.de') >>> ssl_sock.connect(('www.google.de', 443)) Traceback (most recent call last): File "", line 1, in File "c:\python27\lib\ssl.py", line 882, in connect self._real_connect(addr, False) File "c:\python27\lib\ssl.py", line 873, in _real_connect self.do_handshake() File "c:\python27\lib\ssl.py", line 846, in do_handshake self._sslobj.do_handshake() ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:726) >>> ssl_sock.close() This first attempt to make a HTTPS connection to https://google.de failed because the required RootCA for this domain is not part of the very minimal Windows out-of-the-box ca bundle. Now let's make a https request against this domain with an application that uses the Windows SCHANNEL library (for example by typing https://google.de/ into the address bar in Internet Explorer / Edge browser). I will use the experimental pySchannelSSL here: $ git clone https://github.com/lsowen/pySchannelSSL.git $ "c:\Program Files\Python37\python.exe" Python 3.7.2 (tags/v3.7.2:9a3ffc0492, Dec 23 2018, 23:09:28) [MSC v.1916 64 bit (AMD64)] on win32 >>> import pySchannelSSL.httpshandler >>> h = pySchannelSSL.httpshandler.SSLConnection("google.de", port=443) >>> h.connect() >>> h.close() As part of processing the above request, the Windows SCHANNEL library has magically fetched the missing trusted RootCA certificate from a Microsoft server and has stored it permanently in the Windows "Trusted Root CAs" certstore. We can verify this with: >>> import socket, ssl >>> context = ssl.SSLContext(ssl.PROTOCOL_TLS) >>> context.load_default_certs() >>> len(context.get_ca_certs()) 15 Note that in our first attempt there were only 12 root cacerts in the Windows certstore. Now it's 15. And the only difference is that in between we've made an SCHANNEL-based https connection to the google.de domain. (You can also see the additional root certificates via the certificates mmc consoles certlm.msc and certmgr.msc). >From now on all non-SCHANNEL based HTTPS connections via the Python 2/3 ssl standard lib work, as SCHANNEL has permanently placed the RootCA cert in the windows certstore: c:\python27\python.exe Python 2.7.15 (v2.7.15:ca079a3ea3, Apr 30 2018, 16:30:26) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import socket, ssl >>> context = ssl.SSLContext(ssl.PROTOCOL_TLS) >>> context.verify_mode = ssl.CERT_REQUIRED >>> context.check_hostname = True >>> context.load_default_certs() >>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) >>> ssl_sock = context.wrap_socket(s, server_hostname='www.google.de') # got a certificate verify failed error here in the first try, this time the verify is successfull >>> ssl_sock.connect(('www.google.de', 443)) >>> ssl_sock.close() 3.) Conclusion I believe the way how the Python "ssl" stdlib uses the Windows Certificate Store is not ideal. Windows seems to expects all TLS connections to be made through the SCHANNEL library. The Trusted Root CA store in Windows 10 only seems to function as some sort of cache for SCHANNEL but is not as a complete source of truth. Maybe letting the "ssl" stdlib make a minimal SCHANNEL call before handing over to openssl could provide a minimal invasive fix? (Side note: I would still advocate for not bypassing the Windows certstore, as having a certstore per application is a security issue and big pain for deploying/updating own "Intranet" RootCA certificates). -------- Best, Chris ---------- assignee: christian.heimes components: SSL, Windows messages: 335708 nosy: chris-k, christian.heimes, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: ssl - tls verify on Windows 10 fails versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 13:44:11 2019 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 16 Feb 2019 18:44:11 +0000 Subject: [issue35925] test_httplib test_nntplib test_ssl fail on ARMv7 Debian buster bot (OpenSSL 1.1.1a) In-Reply-To: <1549503926.32.0.191493141556.issue35925@roundup.psfhosted.org> Message-ID: <1550342651.67.0.131340470469.issue35925@roundup.psfhosted.org> Benjamin Peterson added the comment: I agree that we need to be more resistant to system configuration, but it doesn't seem worth holding 2.7 up for. ---------- priority: release blocker -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 13:55:21 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 16 Feb 2019 18:55:21 +0000 Subject: [issue33089] Add multi-dimensional Euclidean distance function to the math module In-Reply-To: <1521226258.78.0.467229070634.issue33089@psf.upfronthosting.co.za> Message-ID: <1550343321.4.0.809820771497.issue33089@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- pull_requests: +11923 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 14:00:48 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 16 Feb 2019 19:00:48 +0000 Subject: [issue33089] Add multi-dimensional Euclidean distance function to the math module In-Reply-To: <1521226258.78.0.467229070634.issue33089@psf.upfronthosting.co.za> Message-ID: <1550343648.33.0.46707678319.issue33089@roundup.psfhosted.org> miss-islington added the comment: New changeset 3ff5962d2e9af2c35d09d39465397c6fa6e9965c by Miss Islington (bot) (Raymond Hettinger) in branch 'master': bpo-33089: Add math.dist() and math.hypot() to Whatsnew (GH-11896) https://github.com/python/cpython/commit/3ff5962d2e9af2c35d09d39465397c6fa6e9965c ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 14:19:41 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 16 Feb 2019 19:19:41 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1550344781.18.0.31184384487.issue35813@roundup.psfhosted.org> Giampaolo Rodola' added the comment: > The unlink() method is available on the SharedMemory class. No manager is required. This is also captured in the docs. I missed that, sorry. >> 3) it seems "size" kwarg cannot be zero (current default) > From the docs: When attaching to an existing shared memory block, set to 0 Mmm... this makes the API a bit weird because it's a arg which is optional only for existing memory object, not new ones. I see that internally *size* is passed to ftruncate(). Can't you just avoid calling ftruncate() if size is not passed (None)? Also, what happens if you alter the size of an existing object with a smaller value? Is the memory region overwritten? a = shared_memory.SharedMemory(None, size=10) b = shared_memory.SharedMemory(a.name, size=4) >> Maybe something like this instead? >> SharedMemory(name=None, attach_if_exists=False, size=0) > I think this misses the use case when wanting to ensure we only attach to an existing shared memory block and if it does not exist, we should raise an exception because we can not continue. It appears this is already covered: >>> SharedMemory(name="non-existent") Traceback (most recent call last): ... _posixshmem.ExistentialError: No shared memory exists with the specified name > I believe the two dominant use cases to address are: > 1) I want to create a shared memory block (either with or without a pre-conceived name). > 2) I want to attach to an existing shared memory block by its unique name. Don't you also want to "create if it doesn't exist, else attach" as a single, atomic operation? It seems to me the only way to achieve that would be this, but it's racy: try: m = shared_memory.SharedMemory("foo", size=10) # create except ExistentialError: m = shared_memory.SharedMemory("foo") # attach (race condition) Note that here I'm entering into an unknown territory, because I'm not sure if there are or should be sync primitives to "wait for another memory to join me" etc. Just mentioning it for the sake of mental lucubration. =) > If we move SharedMemoryManager to live in multiprocessing.managers, we need to decide how to handle (and communicate to the user appropriately) its potential absence. How about: # managers.py try: from .shared_memory import SharedMemory, SharedList except ImportError: pass else: class SharedMemoryManager: ... class SharedMemoryServer: ... del SharedMemory, SharedList >> 4) I have some reservations about SharedMemory's "flags" and "mode" args. > It sounds like you are agreeing with what I advocated in msg335660 (up above). Great! If you mean drop those 2 args entirely then it probably there's no point in exposing WindowsNamedSharedMemory and PosixSharedMemory . If you mean to keep them then it seems "read_only=True" would conflict with "flags=O_RDWR". The fact that the Windows counterpart uses different constants makes me think this bitwise stuff should probably be handled internally, and exposed via friendly named-args like "read_only" / "attach_if_exists" or similar (but it's still not clear what those named args should be exactly). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 14:56:56 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 16 Feb 2019 19:56:56 +0000 Subject: [issue32492] C Fast path for namedtuple's property/itemgetter pair In-Reply-To: <1515089143.43.0.467229070634.issue32492@psf.upfronthosting.co.za> Message-ID: <1550347016.22.0.316845041025.issue32492@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- pull_requests: +11924 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 15:02:26 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 16 Feb 2019 20:02:26 +0000 Subject: [issue32492] C Fast path for namedtuple's property/itemgetter pair In-Reply-To: <1515089143.43.0.467229070634.issue32492@psf.upfronthosting.co.za> Message-ID: <1550347346.03.0.965724354.issue32492@roundup.psfhosted.org> miss-islington added the comment: New changeset 63fa1cfece4912110ce3a0ff11fb3ade3ff5e756 by Miss Islington (bot) (Raymond Hettinger) in branch 'master': bpo-32492: Add missing whatsnew entries for itemgetter and namedtuple (GH-11897) https://github.com/python/cpython/commit/63fa1cfece4912110ce3a0ff11fb3ade3ff5e756 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 15:13:01 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Sat, 16 Feb 2019 20:13:01 +0000 Subject: [issue29202] Improve dict iteration In-Reply-To: <1483869036.69.0.874318106576.issue29202@psf.upfronthosting.co.za> Message-ID: <1550347981.47.0.787624161139.issue29202@roundup.psfhosted.org> Cheryl Sabella added the comment: I can convert this to a pull request if there is still interest in the change. ---------- nosy: +cheryl.sabella versions: +Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 15:15:18 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 16 Feb 2019 20:15:18 +0000 Subject: [issue36012] Investigate slow writes to class variables Message-ID: <1550348118.4.0.228746523417.issue36012@roundup.psfhosted.org> New submission from Raymond Hettinger : Benchmark show what writes to class variables are anomalously slow. class A(object): pass A.x = 1 # This write is 3 to 5 times slower than other writes. FWIW, the same operation for old-style classes in Python 2.7 was several times faster. We should investigate to understand why the writes are so slow. There might be a good reason or there might be an opportunity for optimization. ------------------------------------------------- $ python3.8 Tools/scripts/var_access_benchmark.py Variable and attribute read access: 4.3 ns read_local 4.6 ns read_nonlocal 14.5 ns read_global 19.0 ns read_builtin 18.4 ns read_classvar_from_class 16.2 ns read_classvar_from_instance 24.7 ns read_instancevar 19.7 ns read_instancevar_slots 19.5 ns read_namedtuple 26.4 ns read_boundmethod Variable and attribute write access: 4.4 ns write_local 5.1 ns write_nonlocal 18.2 ns write_global 103.9 ns write_classvar <== Outlier 35.4 ns write_instancevar 25.6 ns write_instancevar_slots ---------- components: Interpreter Core messages: 335714 nosy: nascheme, pablogsal, rhettinger, vstinner priority: low severity: normal status: open title: Investigate slow writes to class variables type: performance versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 15:20:53 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 16 Feb 2019 20:20:53 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1550348453.1.0.118232458789.issue35813@roundup.psfhosted.org> Giampaolo Rodola' added the comment: As for *flags* argument "man shm_open" mentions 5 possible flags: - O_RDONLY, OR_RDWR: these can be served by existing *read_only* arg - O_CREAT, O_EXCL: dictates whether to raise error if file exists; could be served via *attach_if_exists* arg, if added, or internally if not added - O_TRUNC: related to *size* argument (it seems it should be set when size=0) As such I think "flags" should not be exposed. As for Windows, *read_only* is currently exposed but ignored, and no other flags are contemplated. It seems you can implement *read_only* by passing FILE_MAP_READ or FILE_MAP_WRITE to OpenFileMappingW() here: https://github.com/python/cpython/blob/1e5341eb171d7d2b988880020cfcc0a64021326d/Lib/multiprocessing/shared_memory.py#L98 Not sure how to reliably check if a file mapping already exists, but possibly POSIX and Windows should behave the same in this regard (and some test cases to exercise all the possible combinations would be good to have). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 15:30:47 2019 From: report at bugs.python.org (Ned Deily) Date: Sat, 16 Feb 2019 20:30:47 +0000 Subject: [issue32492] C Fast path for namedtuple's property/itemgetter pair In-Reply-To: <1515089143.43.0.467229070634.issue32492@psf.upfronthosting.co.za> Message-ID: <1550349047.66.0.739135973455.issue32492@roundup.psfhosted.org> Change by Ned Deily : ---------- nosy: -ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 15:32:50 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 16 Feb 2019 20:32:50 +0000 Subject: [issue35884] Add variable access benchmark to Tools/Scripts In-Reply-To: <1549052380.12.0.716539002961.issue35884@roundup.psfhosted.org> Message-ID: <1550349170.64.0.375951329759.issue35884@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- pull_requests: +11925 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 15:42:26 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 16 Feb 2019 20:42:26 +0000 Subject: [issue33234] Improve list() pre-sizing for inputs with known lengths In-Reply-To: <1522964813.15.0.682650639539.issue33234@psf.upfronthosting.co.za> Message-ID: <1550349746.33.0.665189144708.issue33234@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- pull_requests: +11926 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 15:46:14 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 16 Feb 2019 20:46:14 +0000 Subject: [issue29202] Improve dict iteration In-Reply-To: <1483869036.69.0.874318106576.issue29202@psf.upfronthosting.co.za> Message-ID: <1550349974.91.0.0271921718089.issue29202@roundup.psfhosted.org> Raymond Hettinger added the comment: > I can convert this to a pull request if there is still interest in the change. Yes, please do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 15:47:50 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 16 Feb 2019 20:47:50 +0000 Subject: [issue33234] Improve list() pre-sizing for inputs with known lengths In-Reply-To: <1522964813.15.0.682650639539.issue33234@psf.upfronthosting.co.za> Message-ID: <1550350070.71.0.948510982587.issue33234@roundup.psfhosted.org> miss-islington added the comment: New changeset e182318e6a473e6e9341f1aab8e49f2b1035c674 by Miss Islington (bot) (Raymond Hettinger) in branch 'master': bpo-33234: Add another attribution in Whatsnew (GH-11899) https://github.com/python/cpython/commit/e182318e6a473e6e9341f1aab8e49f2b1035c674 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 15:51:05 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 16 Feb 2019 20:51:05 +0000 Subject: [issue35884] Add variable access benchmark to Tools/Scripts In-Reply-To: <1549052380.12.0.716539002961.issue35884@roundup.psfhosted.org> Message-ID: <1550350265.09.0.482859565897.issue35884@roundup.psfhosted.org> miss-islington added the comment: New changeset 43766f82ddec84fad7a321eeec2e1cbff6ee44d2 by Miss Islington (bot) (Raymond Hettinger) in branch 'master': bpo-35884: Add missing FIFO queue benchmark (GH-11898) https://github.com/python/cpython/commit/43766f82ddec84fad7a321eeec2e1cbff6ee44d2 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 15:51:57 2019 From: report at bugs.python.org (Davin Potts) Date: Sat, 16 Feb 2019 20:51:57 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1550350317.77.0.966927320879.issue35813@roundup.psfhosted.org> Davin Potts added the comment: @giampaolo: > Also, what happens if you alter the size of an existing object with a smaller value? Is the memory region overwritten? Attaching to an existing shared memory block with a size=N which is smaller than its allocated size (say it was created with size=M and N Can't you just avoid calling ftruncate() if size is not passed (None)? It looks like it does skip calling ftruncate() if size is 0. From posixshmem.c: if (size) { DPRINTF("calling ftruncate, fd = %d, size = %ld\n", self->fd, size); if (-1 == ftruncate(self->fd, (off_t)size)) { >> I think this misses the ... > It appears this is already covered: Sorry for any confusion; I was interpreting your proposed parameter name, attach_if_exists, in the following way: * attach_if_exists=True: If exists, attach to it otherwise create one * attach_if_exists=False: Create a new one but do not attach to an existing with the same name I did not see a way to indicate a desire to *only* attach without creation. I need a way to test to see if a shared memory block already exists or not without risk of creating one. At least this is how I was interpreting "attach if exists". > Don't you also want to "create if it doesn't exist, else attach" as a single, atomic operation? Yes, I do! This was part of my description for the parameter named "create" in msg335660: When set to True, a new shared memory block will be created unless one already exists with the supplied unique name, in which case that block will be attached to and used. > I'm not sure if there are or should be sync primitives to "wait for another memory to join me" etc. In the case of shared memory, I do not think so. I think such signaling between processes, when needed, can be accomplished by our existing signaling mechanisms (like, via the Proxy Objects for Event or Semaphore). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 15:55:21 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 16 Feb 2019 20:55:21 +0000 Subject: [issue27181] Add geometric mean to `statistics` module In-Reply-To: <1464901494.08.0.0111988914026.issue27181@psf.upfronthosting.co.za> Message-ID: <1550350521.26.0.975032780795.issue27181@roundup.psfhosted.org> Raymond Hettinger added the comment: > Updating the version in case this wanted to be considered for 3.8. Yes. It would be nice to get this wrapped-up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 15:57:42 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 16 Feb 2019 20:57:42 +0000 Subject: [issue1054041] Python doesn't exit with proper resultcode on SIGINT Message-ID: <1550350662.55.0.833919984654.issue1054041@roundup.psfhosted.org> Gregory P. Smith added the comment: New changeset 38f11cc3f62db11a4a24354bd06273322ac91afa by Gregory P. Smith in branch 'master': bpo-1054041: Exit properly after an uncaught ^C. (#11862) https://github.com/python/cpython/commit/38f11cc3f62db11a4a24354bd06273322ac91afa ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 16:07:10 2019 From: report at bugs.python.org (Michael Felt) Date: Sat, 16 Feb 2019 21:07:10 +0000 Subject: [issue35773] test_bdb fails on AIX bot (regression) In-Reply-To: <1547812678.96.0.834885366728.issue35773@roundup.psfhosted.org> Message-ID: <1550351230.34.0.575477769623.issue35773@roundup.psfhosted.org> Michael Felt added the comment: OK. I have narrowed it down to this: when LANG=en_US.8859-15 the test fails. root at x064:[/home/root]grep LANG /etc/environment LANG=en_US And now it passes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 16:08:03 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 16 Feb 2019 21:08:03 +0000 Subject: [issue1054041] Python doesn't exit with proper resultcode on SIGINT Message-ID: <1550351283.49.0.963847848115.issue1054041@roundup.psfhosted.org> Gregory P. Smith added the comment: This is in for 3.8. On earlier or unpatched Python versions: application owners have a workaround f they do not mind skipping a clean application shutdown (destructors) on posix platforms: catch KeyboardInterrupt, reset SIGINT to SIG_DFL, kill(getpid(), SIGINT). If you somehow need the python destructor cleanup (never guaranteed, so unwise to _depend_ on it) you could do that in a C atexit handler. On Windows the workaround is easier without altering clean shutdown, catch KeyboardInterrupt and sys.exit(0xC000013A - 2**32). ---------- assignee: -> gregory.p.smith resolution: -> fixed stage: patch review -> commit review status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 16:16:08 2019 From: report at bugs.python.org (Ned Deily) Date: Sat, 16 Feb 2019 21:16:08 +0000 Subject: [issue27181] Add geometric mean to `statistics` module In-Reply-To: <1464901494.08.0.0111988914026.issue27181@psf.upfronthosting.co.za> Message-ID: <1550351768.07.0.82689347927.issue27181@roundup.psfhosted.org> Change by Ned Deily : ---------- nosy: -ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 16:27:18 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Sat, 16 Feb 2019 21:27:18 +0000 Subject: [issue29202] Improve dict iteration In-Reply-To: <1483869036.69.0.874318106576.issue29202@psf.upfronthosting.co.za> Message-ID: <1550352438.71.0.335712313185.issue29202@roundup.psfhosted.org> Change by Cheryl Sabella : ---------- pull_requests: +11927 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 17:00:08 2019 From: report at bugs.python.org (Jeff Robbins) Date: Sat, 16 Feb 2019 22:00:08 +0000 Subject: [issue35580] Windows IocpProactor: CreateIoCompletionPort 4th arg 0xffffffff -- why is this value the default? In-Reply-To: <1545694904.74.0.712150888896.issue35580@roundup.psfhosted.org> Message-ID: <1550354408.88.0.612194192388.issue35580@roundup.psfhosted.org> Jeff Robbins added the comment: I don't understand why 0 would be safer. Since asyncio can only service this IOCP from its single threaded event loop, I would have thought 1 would express the intent better. Why not convey to the OS what we're up to, in case that helps it do a better job or reduces resource footprint? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 17:37:47 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 16 Feb 2019 22:37:47 +0000 Subject: [issue36010] Please provide a .zip Windows release of Python that is not crippled/for embedding only In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org> Message-ID: <1550356667.45.0.703853278357.issue36010@roundup.psfhosted.org> Steve Dower added the comment: The whole point of a venv is to give you a separate directory with a "stand alone" Python. As that's what you just installed with nuget, there's no point in creating a venv - just pip install directly into it. Alternatively, you can pip install virtualenv and use that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 17:52:05 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 16 Feb 2019 22:52:05 +0000 Subject: [issue35892] Fix awkwardness of statistics.mode() for multimodal datasets In-Reply-To: <1549219885.57.0.86866159357.issue35892@roundup.psfhosted.org> Message-ID: <1550357525.69.0.0324711953548.issue35892@roundup.psfhosted.org> Raymond Hettinger added the comment: I've been thinking about this a bit more. ISTM that for now, it's best to get mode() working for everyday use, returning just the first mode encountered. This keeps the signature simple (Iterable -> Scalar). In the future, if needed, there is room to add separate functions with their own clean signatures and use cases. For example, having a separate multimode() that always returns a list would be clearer and easier to use than setting a flag on the current scalar valued mode() function. Another example would be mode_estimate() that returns a scalar float that estimates the mode given data sampled from a continuous variable. This warrants its own function because the signature, use cases, options, and implementation method are all completely different from a mode based on counting. Categorical, binned, or ordinal data: mode(data: Iterable, *, first_tie=False) -> object multimode(data: Iterable) -> List[object] Continuous data: mode(data: Iterable[Real]) -> Real ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 17:54:20 2019 From: report at bugs.python.org (Paul Moore) Date: Sat, 16 Feb 2019 22:54:20 +0000 Subject: [issue36010] Please provide a .zip Windows release of Python that is not crippled/for embedding only In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org> Message-ID: <1550357660.86.0.340440986124.issue36010@roundup.psfhosted.org> Paul Moore added the comment: > The whole point of a venv is to give you a separate directory with a "stand alone" Python. As that's what you just installed with nuget, there's no point in creating a venv However, shipping a copy of Python with a non-optional element of the stdlib omitted seems at a minimum user-unfriendly, and possibly even outright broken. (We've had similar discussions in the past over Linux distros splitting parts of the stdlib into optional "devel" packages). Is there a technical reason why the venv module cannot work with the nuget package? If not, then I'd suggest that we simply include it, and don't pre-judge what people might want to do with it. If there *is* a technical problem, let's document the limitation, and note in the venv docs that it may not be present in all installations. (I'm specifically interested in venv here because there's a possibility that at some point, virtualenv will change to use the core venv functionality under the hood on Python 3+, and if that happens, your suggestion to use virtualenv would no longer work). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 18:03:17 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 16 Feb 2019 23:03:17 +0000 Subject: [issue36010] Please provide a .zip Windows release of Python that is not crippled/for embedding only In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org> Message-ID: <1550358197.26.0.551555704183.issue36010@roundup.psfhosted.org> Steve Dower added the comment: There certainly used to be a problem where venv was totally reliant on Python being in the registry to work properly. I'm not sure if that's still the case - possibly with the new redirector in 3.7.2+ it's fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 18:07:40 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Sat, 16 Feb 2019 23:07:40 +0000 Subject: [issue36013] test_signal fails in AMD64 Debian PGO 3.x Message-ID: <1550358460.35.0.479267905916.issue36013@roundup.psfhosted.org> New submission from Pablo Galindo Salgado : test_signal fails in AMD64 Debian PGO 3.x: == Tests result: FAILURE then FAILURE == 406 tests OK. 10 slowest tests: - test_concurrent_futures: 2 min 37 sec - test_multiprocessing_spawn: 2 min 3 sec - test_multiprocessing_forkserver: 1 min 28 sec - test_multiprocessing_fork: 1 min 17 sec - test_gdb: 46 sec 874 ms - test_asyncio: 46 sec 166 ms - test_tools: 37 sec 582 ms - test_io: 35 sec 518 ms - test_tokenize: 34 sec 631 ms - test_subprocess: 34 sec 302 ms 1 test failed: test_signal 13 tests skipped: test_devpoll test_ioctl test_kqueue test_msilib test_ossaudiodev test_startfile test_tix test_tk test_ttk_guionly test_winconsoleio test_winreg test_winsound test_zipfile64 https://buildbot.python.org/all/#/builders/47/builds/2251/steps/4/logs/stdio test_valid_signals (test.test_signal.WindowsSignalTests) ... skipped 'Windows specific' ====================================================================== FAIL: test_keyboard_interrupt_communicated_to_shell (test.test_signal.PosixTests) KeyboardInterrupt exits such that shells detect a ^C. ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.nondebug/build/Lib/test/test_signal.py", line 121, in test_keyboard_interrupt_communicated_to_shell self.assertNotIn(b"TESTFAIL", process.stdout) AssertionError: b'TESTFAIL' unexpectedly found in b'TESTFAIL using bash 4.4.12(1)-release\n' ---------------------------------------------------------------------- This may be related to PR11862 ---------- components: Tests messages: 335729 nosy: gregory.p.smith, pablogsal priority: normal severity: normal status: open title: test_signal fails in AMD64 Debian PGO 3.x versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 18:10:22 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Sat, 16 Feb 2019 23:10:22 +0000 Subject: [issue31869] commentary on ssl.PROTOCOL_TLS In-Reply-To: <1508947295.4.0.213398074469.issue31869@psf.upfronthosting.co.za> Message-ID: <1550358622.83.0.750165517299.issue31869@roundup.psfhosted.org> Cheryl Sabella added the comment: Mariatta, This might be another good issue for the mentored sprint, although it's applying a change to the 2.7 branch, so maybe it just needs Miss Islington? ---------- assignee: docs at python -> Mariatta nosy: +Mariatta _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 18:18:23 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Sat, 16 Feb 2019 23:18:23 +0000 Subject: [issue29757] The loop in utility `socket.create_connection()` swallows previous errors In-Reply-To: <1488984317.87.0.296010902983.issue29757@psf.upfronthosting.co.za> Message-ID: <1550359103.64.0.849044114551.issue29757@roundup.psfhosted.org> Change by Cheryl Sabella : ---------- stage: -> patch review type: -> enhancement versions: +Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 18:27:54 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Sat, 16 Feb 2019 23:27:54 +0000 Subject: [issue15757] ./configure --with-pydebug on FreeBSD results in -O2 -pipe eventually ending up in CFLAGS. In-Reply-To: <1345584581.07.0.102502771699.issue15757@psf.upfronthosting.co.za> Message-ID: <1550359674.41.0.452709342198.issue15757@roundup.psfhosted.org> Change by Cheryl Sabella : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 18:28:34 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 16 Feb 2019 23:28:34 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1550359714.34.0.14469022576.issue35813@roundup.psfhosted.org> Giampaolo Rodola' added the comment: > It looks like it does skip calling ftruncate() if size is 0. From posixshmem.c: Let me rephrase: are we forced to specify a value (aka call ftruncate()) on create ? If we are as I think, could size have a reasonable default value instead of 0? Basically I'm wondering if we can relieve the common user from thinking about what size to use, mostly because it's sort of a low level detail. Could it perhaps default to mmap.PAGESIZE? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 18:32:01 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 16 Feb 2019 23:32:01 +0000 Subject: [issue36013] test_signal fails in AMD64 Debian PGO 3.x In-Reply-To: <1550358460.35.0.479267905916.issue36013@roundup.psfhosted.org> Message-ID: <1550359921.09.0.648048554309.issue36013@roundup.psfhosted.org> Gregory P. Smith added the comment: This means either that the bash minimum version needs upping to a patch level or that the test is actually flaky and both I and all of the CI got lucky when running it (i'm not actually sure if any of the CI actually ran this test or just skipped it - the test.regrtest output on CI is never verbose so I can't tell). if i can't untangle bash versions, the other alternative is to just not bother with a shell based test for this as it is too complicated due to depending on exact behaviors of a shell testing an interactive feature in fake interactive mode. changing the child process to just "raise KeyboardInterrupt" as is done in the equivalent Windows test is sufficient. ---------- assignee: -> gregory.p.smith stage: -> needs patch type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 18:34:44 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Sat, 16 Feb 2019 23:34:44 +0000 Subject: [issue36012] Investigate slow writes to class variables In-Reply-To: <1550348118.4.0.228746523417.issue36012@roundup.psfhosted.org> Message-ID: <1550360084.44.0.674129423506.issue36012@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: It seems 50% of the overhead (50ns) is due to two reasons: - 30-40% is due to the call to update_slot(type, name) after the item is set in the class dictionary. - 70-60% is due to all the extra work from _PyObject_GenericSetAttrWithDict until it ends calling _PyObjectDict_SetItem with the slot. If in the code of typeobject.c:type_setattro you change: res = _PyObject_GenericSetAttrWithDict((PyObject *)type, name, value, NULL); by PyObject* dictptr = _PyObject_GetDictPtr(type); res = _PyObjectDict_SetItem(type, dictptr, name, value); and delete the update_slot(type, name) call afterwards, the times are reduced to 50ns. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 18:34:53 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Sat, 16 Feb 2019 23:34:53 +0000 Subject: [issue28235] In xml.etree.ElementTree docs there is no parser argument in fromstring() In-Reply-To: <1474457056.95.0.329737294315.issue28235@psf.upfronthosting.co.za> Message-ID: <1550360093.5.0.475630654899.issue28235@roundup.psfhosted.org> Cheryl Sabella added the comment: @py.user, would you be able to convert your patch to a Github pull request? Thanks! ---------- nosy: +cheryl.sabella type: behavior -> enhancement versions: +Python 3.8 -Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 18:46:59 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Sat, 16 Feb 2019 23:46:59 +0000 Subject: [issue33898] pathlib issues with Windows device paths In-Reply-To: <1529361630.0.0.56676864532.issue33898@psf.upfronthosting.co.za> Message-ID: <1550360819.92.0.270585975252.issue33898@roundup.psfhosted.org> Change by Cheryl Sabella : ---------- versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 18:48:14 2019 From: report at bugs.python.org (Rohit travels and tours) Date: Sat, 16 Feb 2019 23:48:14 +0000 Subject: [issue36013] test_signal fails in AMD64 Debian PGO 3.x In-Reply-To: <1550358460.35.0.479267905916.issue36013@roundup.psfhosted.org> Message-ID: <1550360894.03.0.260942100878.issue36013@roundup.psfhosted.org> Change by Rohit travels and tours : Added file: https://bugs.python.org/file48145/19592 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 18:57:16 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Sat, 16 Feb 2019 23:57:16 +0000 Subject: [issue36013] test_signal fails in AMD64 Debian PGO 3.x In-Reply-To: <1550358460.35.0.479267905916.issue36013@roundup.psfhosted.org> Message-ID: <1550361436.71.0.305708521588.issue36013@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: I scheduled a rebuild to check if the failure is consistent. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 19:14:59 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Sun, 17 Feb 2019 00:14:59 +0000 Subject: [issue36013] test_signal fails in AMD64 Debian PGO 3.x In-Reply-To: <1550358460.35.0.479267905916.issue36013@roundup.psfhosted.org> Message-ID: <1550362499.54.0.215786093372.issue36013@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: I have tested in Ubuntu with the same version of bash 4.4.12(1)-release and the test succeeds: root at d7d8cf5d89bf:/src# echo $BASH_VERSION 4.4.12(1)-release root at d7d8cf5d89bf:/src# ./python -m test test_signal -m test_keyboard_interrupt_communicated_to_shell Run tests sequentially 0:00:00 load avg: 0.77 [1/1] test_signal b'4.4.12(1)-release\n' [4, 4] == Tests result: SUCCESS == 1 test OK. Total duration: 74 ms Tests result: SUCCESS ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 19:15:04 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 17 Feb 2019 00:15:04 +0000 Subject: [issue36013] test_signal fails in AMD64 Debian PGO 3.x In-Reply-To: <1550358460.35.0.479267905916.issue36013@roundup.psfhosted.org> Message-ID: <1550362504.83.0.342367339254.issue36013@roundup.psfhosted.org> Gregory P. Smith added the comment: testing on my end with various bash versions shows that bash 4.3.0 and 4.4.0 and 5.0.0 all work fine on my linux and macos systems. caveat, i'm launching regrtest from a login shell (in case that influences child bash processes behavior). i'm going to abandon bash for this test. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 19:19:03 2019 From: report at bugs.python.org (Mariatta Wijaya) Date: Sun, 17 Feb 2019 00:19:03 +0000 Subject: [issue31869] commentary on ssl.PROTOCOL_TLS In-Reply-To: <1508947295.4.0.213398074469.issue31869@psf.upfronthosting.co.za> Message-ID: <1550362743.55.0.689290472304.issue31869@roundup.psfhosted.org> Mariatta Wijaya added the comment: Thanks. Yep this is good for the mentored sprint. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 19:22:53 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Sun, 17 Feb 2019 00:22:53 +0000 Subject: [issue36013] test_signal fails in AMD64 Debian PGO 3.x In-Reply-To: <1550358460.35.0.479267905916.issue36013@roundup.psfhosted.org> Message-ID: <1550362973.03.0.357501867166.issue36013@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: Could it be a race condition the signal delivery? Technically, the process sends itself a signal and never waits for it, it just exits. The signal can arrive after the process has exited normally. Or I am missing something obvious in this reasoning? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 19:27:34 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 17 Feb 2019 00:27:34 +0000 Subject: [issue36013] test_signal fails in AMD64 Debian PGO 3.x In-Reply-To: <1550358460.35.0.479267905916.issue36013@roundup.psfhosted.org> Message-ID: <1550363254.04.0.859496386996.issue36013@roundup.psfhosted.org> Change by Gregory P. Smith : ---------- keywords: +patch pull_requests: +11928 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 20:21:36 2019 From: report at bugs.python.org (Eryk Sun) Date: Sun, 17 Feb 2019 01:21:36 +0000 Subject: [issue35688] "pip install --user numpy" fails on Python from the Windows Store In-Reply-To: <1546987520.17.0.731862977401.issue35688@roundup.psfhosted.org> Message-ID: <1550366496.11.0.850095815901.issue35688@roundup.psfhosted.org> Eryk Sun added the comment: > I didn't realize assemblyBinding was supported by the generic runtime > framework, the documentation https://docs.microsoft.com/en-us/dotnet/ > framework/deployment/how-the-runtime-locates-assemblies seems to > suggest it is a dotnet feature. Native private assemblies are supported in XP, but the probing element [1] of an assemblyBnding isn't available until Windows 7, which restricts this to Python 3.6+. Alternatively, we could implement our own $ORIGIN-like support for Windows. Embed relative paths as a resource in the PYD file. If found, Python would internally call AddDllDirectory for each directory, load the extension with the flag LOAD_LIBRARY_SEARCH_DEFAULT_DIRS, and then remove the directories via RemoveDllDirectory. This wouldn't solve the problem of DLL name and version conflicts, however. For that, the import tables would have to be modified in every DLL. I think there's an existing project that implements something like that for Unix. Even if we're able to load two versions of a DLL in a process, they may still conflict with each other over resources (e.g. a named pipe). DLLs have to be designed to support multiple instances per process. See Authoring a DLL for a Side-by-Side Assembly [2]. [1]: https://docs.microsoft.com/en-us/windows/desktop/SbsCs/application-configuration-files [2]: https://docs.microsoft.com/en-us/windows/desktop/SbsCs/authoring-a-dll-for-a-side-by-side-assembly ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 20:22:43 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 17 Feb 2019 01:22:43 +0000 Subject: [issue36013] test_signal fails in AMD64 Debian PGO 3.x In-Reply-To: <1550358460.35.0.479267905916.issue36013@roundup.psfhosted.org> Message-ID: <1550366563.8.0.363951381361.issue36013@roundup.psfhosted.org> Gregory P. Smith added the comment: New changeset 414c625a7ea58943f0b1bc79d095d667d78db013 by Gregory P. Smith in branch 'master': bpo-36013: delete fragile interactive shell SIGINT test (GH-11902) https://github.com/python/cpython/commit/414c625a7ea58943f0b1bc79d095d667d78db013 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 20:23:17 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 17 Feb 2019 01:23:17 +0000 Subject: [issue36013] test_signal fails in AMD64 Debian PGO 3.x In-Reply-To: <1550358460.35.0.479267905916.issue36013@roundup.psfhosted.org> Message-ID: <1550366597.73.0.250671215011.issue36013@roundup.psfhosted.org> Change by Gregory P. Smith : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 20:29:25 2019 From: report at bugs.python.org (jt) Date: Sun, 17 Feb 2019 01:29:25 +0000 Subject: [issue36010] Please provide a .zip Windows release of Python that is not crippled/for embedding only In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org> Message-ID: <1550366965.77.0.834156936042.issue36010@roundup.psfhosted.org> jt added the comment: > As that's what you just installed with nuget, there's no point in creating a venv - just pip install directly into it. This is not a pip install script or anything, it is more complex code that relies on venv. It is not written to run in this build environment only, even if that is where I use it right now - so technically I could make it not use the venv in this case but I'd rather avoid the code complexity. Why should I be required to add that branching? I made this ticket precisely because the Windows Installer is a hassle, and the embeddable version isn't a properly complete Python. So as far as I'm concerned, I'll add to the vote that it would be very preferable to add venv to NuGet, and potential other missing modules people might expect to be around. Because otherwise this is kind of the embeddable issue all over again... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 20:34:39 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Sun, 17 Feb 2019 01:34:39 +0000 Subject: [issue32108] configparser bug: section is emptied if you assign a section to itself In-Reply-To: <1511286370.98.0.213398074469.issue32108@psf.upfronthosting.co.za> Message-ID: <1550367279.56.0.798040846194.issue32108@roundup.psfhosted.org> Change by Cheryl Sabella : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 20:43:55 2019 From: report at bugs.python.org (jt) Date: Sun, 17 Feb 2019 01:43:55 +0000 Subject: [issue36010] Please provide a .zip Windows release of Python that is not crippled/for embedding only In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org> Message-ID: <1550367835.57.0.841570243079.issue36010@roundup.psfhosted.org> jt added the comment: Sorry I could have added more detailed use cases, so I'll append them here: The use case for venv in this particular script is that it's written to also work outside of CI, so it doesn't assume it runs in a "clean" python like this. And I would rather have the exact same process run in CI than outside without too much unnecessary differences like avoiding venv use specifically Another use case for use of venv in CI is the python-for-android project I contribute to, which uses it for cross compilation and similar and for testing inside CI, will also require venv. Currently I don't think it works on Windows due to some hardcoded Unix tool paths, but there are plans to port it and then this would also be an issue ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 20:45:00 2019 From: report at bugs.python.org (Steve Dower) Date: Sun, 17 Feb 2019 01:45:00 +0000 Subject: [issue36010] Please provide a .zip Windows release of Python that is not crippled/for embedding only In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org> Message-ID: <1550367900.31.0.699493074788.issue36010@roundup.psfhosted.org> Steve Dower added the comment: It would be a great help if you could copy the ensurepip and venv directories from a regular install into an extracted Nuget package and let us know whether your scenario works. As you can see from the discussion, there were problems originally that may have been fixed (since Python 3.5). If they are, or if we have some idea of what doesn't work properly now, it'll be much easier to decide what to do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 21:07:58 2019 From: report at bugs.python.org (Manjusaka) Date: Sun, 17 Feb 2019 02:07:58 +0000 Subject: [issue28235] In xml.etree.ElementTree docs there is no parser argument in fromstring() In-Reply-To: <1474457056.95.0.329737294315.issue28235@psf.upfronthosting.co.za> Message-ID: <1550369278.46.0.777122600899.issue28235@roundup.psfhosted.org> Change by Manjusaka : ---------- pull_requests: +11929 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 21:12:00 2019 From: report at bugs.python.org (Manjusaka) Date: Sun, 17 Feb 2019 02:12:00 +0000 Subject: [issue28235] In xml.etree.ElementTree docs there is no parser argument in fromstring() In-Reply-To: <1474457056.95.0.329737294315.issue28235@psf.upfronthosting.co.za> Message-ID: <1550369520.77.0.371094058454.issue28235@roundup.psfhosted.org> Manjusaka added the comment: I have already make a pull request on GitHub ---------- nosy: +Manjusaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 21:27:07 2019 From: report at bugs.python.org (Windson Yang) Date: Sun, 17 Feb 2019 02:27:07 +0000 Subject: [issue35892] Fix awkwardness of statistics.mode() for multimodal datasets In-Reply-To: <1549219885.57.0.86866159357.issue35892@roundup.psfhosted.org> Message-ID: <1550370427.75.0.594882495912.issue35892@roundup.psfhosted.org> Windson Yang added the comment: I only tested stats.mode() from scipy, data = 'BBAAC' should also return 'A'. But in your code **return return Counter(seq).most_common(1)[0][0]** will return B. Did I miss something? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 21:53:16 2019 From: report at bugs.python.org (Yasser Alshalaan) Date: Sun, 17 Feb 2019 02:53:16 +0000 Subject: [issue36012] Investigate slow writes to class variables In-Reply-To: <1550348118.4.0.228746523417.issue36012@roundup.psfhosted.org> Message-ID: <1550371996.63.0.0719436066864.issue36012@roundup.psfhosted.org> Yasser Alshalaan added the comment: can you include your python 2.7 runs? for me it looks similar ---------- nosy: +Yasser Alshalaan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 23:47:32 2019 From: report at bugs.python.org (wabba) Date: Sun, 17 Feb 2019 04:47:32 +0000 Subject: [issue36014] test_help_with_metavar broken Message-ID: <1550378852.92.0.619862991077.issue36014@roundup.psfhosted.org> New submission from wabba : The test_help_with_metavar test appears to be broken. It fails with an assertion error: AssertionError: 'usag[55 chars]_name [-h] [--proxy ]\[113 chars]4>\n' != 'usag[55 chars]_name\n [-h] [--proxy \n' If I change "this_is_spammy_prog_with_a_long_name_sorry_about_the_name [-h] [--proxy ]" to "this_is_spammy_prog_with_a_long_name_sorry_about_the_name [-h] [--proxy ]" i.e. move the part starting with '[-h]' onto the same line, the test passes. What is the correct output expected here? I would think the [-h] should be on the same line, but maybe this is intended behavior and the problem is with my system. No other unit test is failing for me though. ---------- components: Tests messages: 335748 nosy: wabba priority: normal severity: normal status: open title: test_help_with_metavar broken versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 16 23:57:10 2019 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 17 Feb 2019 04:57:10 +0000 Subject: [issue22213] Make pyvenv style virtual environments easier to configure when embedding Python In-Reply-To: <1408275761.36.0.915361061447.issue22213@psf.upfronthosting.co.za> Message-ID: <1550379430.23.0.597634810957.issue22213@roundup.psfhosted.org> Nick Coghlan added the comment: Since I haven't really written them down anywhere else, noting some items I'm aware of from the Python 3.7 internals work that haven't made their way back into the PEP 432 public API proposal yet: * If we only had to care about the pure embedding case, this would be a lot easier. We don't though: we also care about "CPython interpreter variants" that end up calling Py_Main, and hence respect all the CPython environment variables, command line arguments, and in-process global variables. So what Victor ended up having to implement was data structs for all three of those configuration sources, and then helper functions to write them into the consolidated config structs (as well as writing them back to the in-process global variables). * Keeping the Py_Initialize and Py_Main APIs working mean that there are several API preconfiguration functions that need a way to auto-initialize the core runtime state with sensible defaults * the current private implementation uses the PyCoreConfig/PyMainInterpreterConfig naming scheme. Based on some of Eric's work, the PEP currently suggests PyRuntimeConfig PyMainInterpreterConfig, but I don't think any of us are especially in love with the latter name. Our inability to find a good name for it may also be a sign that it needs to be broken up into three distinct pieces (PySystemInterfaceConfig, PyCompilerConfig, PyMainModuleConfig) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 00:09:10 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sun, 17 Feb 2019 05:09:10 +0000 Subject: [issue36014] test_help_with_metavar broken In-Reply-To: <1550378852.92.0.619862991077.issue36014@roundup.psfhosted.org> Message-ID: <1550380150.84.0.932237887383.issue36014@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Tests were added with 842985f6c70484ed7b8fc30d0bc05aec73236a98 and passes on master and 3.7.1 . Can you please add the full traceback and the command you used to run the test? Also the output of python version as below to try reproducing it python -m test.pythoninfo | grep 'sys.version:' ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 00:12:57 2019 From: report at bugs.python.org (wabba) Date: Sun, 17 Feb 2019 05:12:57 +0000 Subject: [issue36014] test_help_with_metavar broken In-Reply-To: <1550378852.92.0.619862991077.issue36014@roundup.psfhosted.org> Message-ID: <1550380377.86.0.89428314753.issue36014@roundup.psfhosted.org> wabba added the comment: Output from running "python3 -m test.pythoninfo | grep 'sys.version:'": sys.version: 3.7.2 (default, Feb 17 2019, 11:51:43) [GCC 4.8.5 20150623 (Red Hat 4.8.5-28)] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 00:14:54 2019 From: report at bugs.python.org (wabba) Date: Sun, 17 Feb 2019 05:14:54 +0000 Subject: [issue36014] test_help_with_metavar broken In-Reply-To: <1550378852.92.0.619862991077.issue36014@roundup.psfhosted.org> Message-ID: <1550380494.37.0.76239300759.issue36014@roundup.psfhosted.org> wabba added the comment: Btw, I am running 3.7.2 because that's the latest version offered on https://www.python.org/downloads/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 00:18:09 2019 From: report at bugs.python.org (wabba) Date: Sun, 17 Feb 2019 05:18:09 +0000 Subject: [issue36014] test_help_with_metavar broken In-Reply-To: <1550378852.92.0.619862991077.issue36014@roundup.psfhosted.org> Message-ID: <1550380689.18.0.436378885503.issue36014@roundup.psfhosted.org> wabba added the comment: Ah sorry, forgot the traceback and command: Command: python3 Lib/test/test_argparse.py test (__main__.TestActionRegistration) ... ok test_failures_many_groups_listargs (__main__.TestActionUserDefined) ... ok test_failures_many_groups_sysargs (__main__.TestActionUserDefined) ... ok ... ... ====================================================================== FAIL: test_help_with_metavar (__main__.TestWrappingMetavar) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_argparse.py", line 5152, in test_help_with_metavar ''')) AssertionError: 'usag[55 chars]_name [-h] [--proxy ]\[113 chars]4>\n' != 'usag[55 chars]_name\n [-h] [--proxy \n' - usage: this_is_spammy_prog_with_a_long_name_sorry_about_the_name [-h] [--proxy ] ? ---------------------------------------- + usage: this_is_spammy_prog_with_a_long_name_sorry_about_the_name + [-h] [--proxy ] optional arguments: -h, --help show this help message and exit --proxy ---------------------------------------------------------------------- Ran 1574 tests in 4.558s FAILED (failures=1) Traceback (most recent call last): File "Lib/test/test_argparse.py", line 5164, in test_main() File "Lib/test/test_argparse.py", line 5156, in test_main support.run_unittest(__name__) File "/usr/local/lib/python3.7/test/support/__init__.py", line 1991, in run_unittest _run_suite(suite) File "/usr/local/lib/python3.7/test/support/__init__.py", line 1910, in _run_suite raise TestFailed(err) test.support.TestFailed: Traceback (most recent call last): File "Lib/test/test_argparse.py", line 5152, in test_help_with_metavar ''')) AssertionError: 'usag[55 chars]_name [-h] [--proxy ]\[113 chars]4>\n' != 'usag[55 chars]_name\n [-h] [--proxy \n' - usage: this_is_spammy_prog_with_a_long_name_sorry_about_the_name [-h] [--proxy ] ? ---------------------------------------- + usage: this_is_spammy_prog_with_a_long_name_sorry_about_the_name + [-h] [--proxy ] optional arguments: -h, --help show this help message and exit --proxy I first encountered this error when running "make test" when installing python 3.7.2, then tried running this test manually with the command above. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 00:30:05 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sun, 17 Feb 2019 05:30:05 +0000 Subject: [issue36014] test_help_with_metavar broken In-Reply-To: <1550378852.92.0.619862991077.issue36014@roundup.psfhosted.org> Message-ID: <1550381405.14.0.617538323206.issue36014@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Thanks for the details. I couldn't reproduce this on a clean v3.7.2 build on Mac. There were also no changes to argparse.py between 3.7.0 and 3.7.2 so I don't know why it's failing on your environment. ? cpython git:(9a3ffc0492) git log v3.7.0..v3.7.2 Lib/argparse.py | cat ? cpython git:(9a3ffc0492) ./python.exe -m test.pythoninfo | grep 'sys.version:' sys.version: 3.7.2 (tags/v3.7.2:9a3ffc0492, Feb 17 2019, 10:47:33) [Clang 7.0.2 (clang-700.1.81)] ? cpython git:(9a3ffc0492) ./python.exe -m unittest -v test.test_argparse.TestWrappingMetavar.test_help_with_metavar test_help_with_metavar (test.test_argparse.TestWrappingMetavar) ... ok ---------------------------------------------------------------------- Ran 1 test in 0.004s OK ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 01:23:31 2019 From: report at bugs.python.org (Alexander Mohr) Date: Sun, 17 Feb 2019 06:23:31 +0000 Subject: [issue36009] weakref.ReferenceType is not a valid typing type In-Reply-To: <1550304256.68.0.492420733825.issue36009@roundup.psfhosted.org> Message-ID: <1550384611.4.0.622692222348.issue36009@roundup.psfhosted.org> Alexander Mohr added the comment: doing the __future__ doesn't help anything as it is an invalid type ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 01:39:18 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 Feb 2019 06:39:18 +0000 Subject: [issue35942] posixmodule.c:path_converter() returns an invalid exception message for broken PathLike objects In-Reply-To: <1549643679.09.0.475002054663.issue35942@roundup.psfhosted.org> Message-ID: <1550385558.96.0.943154032591.issue35942@roundup.psfhosted.org> Serhiy Storchaka added the comment: The custom `__fspath__()` handling is used in `path_converter` for better error reporting. The error message can include names of the function and the argument. PyOS_FSPath() can not provides this information. I agree that error reporting about incorrect type of the __fspath__() result should be improved. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 01:50:54 2019 From: report at bugs.python.org (wabba) Date: Sun, 17 Feb 2019 06:50:54 +0000 Subject: [issue36014] test_help_with_metavar broken In-Reply-To: <1550378852.92.0.619862991077.issue36014@roundup.psfhosted.org> Message-ID: <1550386254.99.0.181558116177.issue36014@roundup.psfhosted.org> wabba added the comment: Figured it out. My shell had the COLUMNS environment variable set, and python was inheriting it in os.environ. The failing test case assumes an 80-column screen. Anyway, looks like it has been fixed for 3.8 here: https://github.com/python/cpython/commit/74102c9a5f2327c4fc47feefa072854a53551d1f#diff-837b312b1f3508216ace6adb46492836 Closing this item. ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 02:18:34 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 Feb 2019 07:18:34 +0000 Subject: [issue35951] os.renames() creates directories if original name doesn't exist In-Reply-To: <1549732242.93.0.821054504106.issue35951@roundup.psfhosted.org> Message-ID: <1550387914.48.0.87493444635.issue35951@roundup.psfhosted.org> Serhiy Storchaka added the comment: I agree with Giampaolo. The proposed change does not solve the problem completely. And since it seems that it can not be solved completely, I suggest to just better document the current behavior. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 02:58:12 2019 From: report at bugs.python.org (nr) Date: Sun, 17 Feb 2019 07:58:12 +0000 Subject: [issue5038] urrlib2/httplib doesn't reset file position between requests In-Reply-To: <1232730438.9.0.904675957675.issue5038@psf.upfronthosting.co.za> Message-ID: <1550390292.21.0.382152095623.issue5038@roundup.psfhosted.org> Change by nr : ---------- pull_requests: +11930 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 02:59:22 2019 From: report at bugs.python.org (Tal Einat) Date: Sun, 17 Feb 2019 07:59:22 +0000 Subject: [issue35500] Align expected and actual calls on mock.assert_called_with error message In-Reply-To: <1544813146.35.0.788709270274.issue35500@psf.upfronthosting.co.za> Message-ID: <1550390362.59.0.781995367322.issue35500@roundup.psfhosted.org> Tal Einat added the comment: Thanks everyone for seeing this through! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 03:06:16 2019 From: report at bugs.python.org (nr) Date: Sun, 17 Feb 2019 08:06:16 +0000 Subject: [issue5038] urrlib2/httplib doesn't reset file position between requests In-Reply-To: <1232730438.9.0.904675957675.issue5038@psf.upfronthosting.co.za> Message-ID: <1550390776.22.0.99838733024.issue5038@roundup.psfhosted.org> nr added the comment: I added a new pull request. Martin, you are right I realized when looking through the code that just setting the file pointer to zero inside http lib might interfere with requests that don't have authentication enabled. The new pull requests does number 2.) of your suggestion for both Basic and Digest authentication. Can you please review the code? Thank you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 03:10:41 2019 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 17 Feb 2019 08:10:41 +0000 Subject: [issue35951] os.renames() creates directories if original name doesn't exist In-Reply-To: <1549732242.93.0.821054504106.issue35951@roundup.psfhosted.org> Message-ID: <1550391041.93.0.983727902432.issue35951@roundup.psfhosted.org> Chris Jerdonek added the comment: > And since it seems that it can not be solved completely, You may be right only to document, but you didn't note any problems with the possibility I suggested. A cleanup pruning step could be done on failure that is similar to the cleanup pruning step on success. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 03:40:05 2019 From: report at bugs.python.org (mattip) Date: Sun, 17 Feb 2019 08:40:05 +0000 Subject: [issue35688] "pip install --user numpy" fails on Python from the Windows Store In-Reply-To: <1546987520.17.0.731862977401.issue35688@roundup.psfhosted.org> Message-ID: <1550392805.1.0.281343308234.issue35688@roundup.psfhosted.org> mattip added the comment: I think the original problem we had with the AddDllDirectory approach was that once set, it seems to mitigate searching the os.environ['PATH'] for dll loading. Is that accurate? Would RemoveDllDirectory restore the ability to find DLLs along the system PATH? > This wouldn't solve the problem of DLL name and version conflicts, however Right, so far we are discussing the easier problem of adding search paths, not their order. This does become an issue for users who modify their system path in order to overcome the first problem, and end up pulling in the wrong version of a support DLL. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 03:50:24 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 17 Feb 2019 08:50:24 +0000 Subject: [issue36012] Investigate slow writes to class variables In-Reply-To: <1550348118.4.0.228746523417.issue36012@roundup.psfhosted.org> Message-ID: <1550393424.59.0.935371401294.issue36012@roundup.psfhosted.org> Raymond Hettinger added the comment: > can you include your python 2.7 runs? for me it looks similar It will give similar results unless you switch to old-style classes (edit out the inheritance from object). class A: pass A.x = 1 --------------------------------------- $ python2.7 var_access_benchmark.py Variable and attribute read access: 6.7 ns read_local 10.9 ns read_global 18.9 ns read_builtin 24.4 ns read_classvar_from_class 30.2 ns read_classvar_from_instance 22.7 ns read_instancevar 25.5 ns read_instancevar_slots 99.3 ns read_namedtuple 40.9 ns read_boundmethod Variable and attribute write access: 8.2 ns write_local 18.7 ns write_global 32.9 ns write_classvar <== Not formerly an outlier 32.5 ns write_instancevar 31.2 ns write_instancevar_slots ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 03:58:38 2019 From: report at bugs.python.org (SilentGhost) Date: Sun, 17 Feb 2019 08:58:38 +0000 Subject: [issue36001] LIBFFI_INCLUDEDIR is not detected when set into a profile nor in ./configure LIBFFI_INCLUDEDIR="path/to/libffi/include" In-Reply-To: <1550234666.59.0.236804774599.issue36001@roundup.psfhosted.org> Message-ID: <1550393918.36.0.00298512827267.issue36001@roundup.psfhosted.org> Change by SilentGhost : ---------- nosy: +amaury.forgeotdarc, belopolsky, meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 04:02:48 2019 From: report at bugs.python.org (SilentGhost) Date: Sun, 17 Feb 2019 09:02:48 +0000 Subject: [issue35999] multpirocessing.Process alive after SIGTERM on parent In-Reply-To: <1550231724.21.0.67060075553.issue35999@roundup.psfhosted.org> Message-ID: <1550394168.61.0.311746144393.issue35999@roundup.psfhosted.org> Change by SilentGhost : ---------- nosy: +davin, pitrou type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 04:10:34 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 17 Feb 2019 09:10:34 +0000 Subject: [issue35892] Fix awkwardness of statistics.mode() for multimodal datasets In-Reply-To: <1549219885.57.0.86866159357.issue35892@roundup.psfhosted.org> Message-ID: <1550394634.55.0.212858769047.issue35892@roundup.psfhosted.org> Raymond Hettinger added the comment: > Did I miss something? Yes. It doesn't really matter which mode is returned as long as it is deterministically chosen. We're proposing to return the first mode rather than the smallest mode. Scipy returns the smallest mode because that is convenient given that the underlying operation is np.unique() which returns unique values in sorted order [1]. We want to return the first mode encountered because that is convenient given that the underlying operation is max() which returns the first maximum value it encounters. Another advantage of return-first rather than return-smallest is that our mode() would work for data values that are hashable but not orderable (i.e. frozensets). [1] https://github.com/scipy/scipy/blob/v0.19.1/scipy/stats/stats.py#L378-L443 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 04:12:24 2019 From: report at bugs.python.org (Michael Felt) Date: Sun, 17 Feb 2019 09:12:24 +0000 Subject: [issue35773] test_bdb fails on AIX bot (regression) In-Reply-To: <1547812678.96.0.834885366728.issue35773@roundup.psfhosted.org> Message-ID: <1550394744.68.0.0863608828144.issue35773@roundup.psfhosted.org> Michael Felt added the comment: Some record keeping - to keep track of when this regression first appeared on the bot: buildername POWER6 AIX 3.x Builder buildnumber 718 Build codebase Build event push Change github_distinct true Change got_revision a37f52436f9aa4b9292878b72f3ff1480e2606c3 Git owners ["Christian Heimes "] Build project python/cpython Build repository https://github.com/python/cpython Build revision a37f52436f9aa4b9292878b72f3ff1480e2606c3 Build scheduler 3.x Scheduler And the last build without this error: buildnumber 717 Build codebase Build event push Change github_distinct true Change got_revision c9f872b0bdce5888f1879fa74e098bf4a05430c5 Git owners ["Victor Stinner "] Build project python/cpython Build repository https://github.com/python/cpython Build revision c9f872b0bdce5888f1879fa74e098bf4a05430c5 Build scheduler 3.x Scheduler I am hoping, with this info - someone who understands the commit process better than I can help me see the difference between these two builds. I have tried git diff c9f872b0bdce5888f1879fa74e098bf4a05430c5 a37f52436f9aa4b9292878b72f3ff1480e2606c3 And this only seems to be a change in something related to ssl (bpo-35746) - so I am not really understanding what (else) has happened. The behavior seems to be language handling related, and not really bdb or ssl which is where the test and git diff points at. Ideas and/or suggestions welcome. (p.s., no longer showing as a bot error as I have changed my LANG setting) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 05:05:55 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 Feb 2019 10:05:55 +0000 Subject: [issue35852] Fixed tests regenerating using CRLF when running it on Windows In-Reply-To: <1548779221.97.0.25499601133.issue35852@roundup.psfhosted.org> Message-ID: <1550397955.69.0.0368311912354.issue35852@roundup.psfhosted.org> Serhiy Storchaka added the comment: PR 11697 keeps existing CRLFs in unmodified part, by writes bare LFs for auto-generated part. The result can contain mixed newlines. The current code looks correct to me. Just git should be configured to convert LF to platform specific newlines in source files. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 05:16:06 2019 From: report at bugs.python.org (nr) Date: Sun, 17 Feb 2019 10:16:06 +0000 Subject: [issue5038] urrlib2/httplib doesn't reset file position between requests In-Reply-To: <1232730438.9.0.904675957675.issue5038@psf.upfronthosting.co.za> Message-ID: <1550398566.67.0.0774390994752.issue5038@roundup.psfhosted.org> nr added the comment: I will fix the build errors first. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 05:29:44 2019 From: report at bugs.python.org (Kobi Gana) Date: Sun, 17 Feb 2019 10:29:44 +0000 Subject: [issue20116] urlparse.parse_qs should take argument for query separator In-Reply-To: <1388777959.1.0.144368039339.issue20116@psf.upfronthosting.co.za> Message-ID: <1550399384.44.0.873004684849.issue20116@roundup.psfhosted.org> Kobi Gana added the comment: Hi all, Please take the next case: The url - http://hostname.domain/mypage.asp?fields=id&query=%22((release%3D{id%3D1004});(sprint%3D{id%3D1040});(team%3D{id%3D1004});(severity%3D{id%3D%27list_node.severity.urgent%27});!phase%3D{id+IN+%27phase.defect.closed%27,%27phase.defect.duplicate%27,%27phase.defect.rejected%27})%22 The Query as string - fields=id&query=%22((release%3D{id%3D1004});(sprint%3D{id%3D1040});(team%3D{id%3D1004});(severity%3D{id%3D%27list_node.severity.urgent%27});!phase%3D{id+IN+%27phase.defect.closed%27,%27phase.defect.duplicate%27,%27phase.defect.rejected%27})%22 The expected pairs - 1. fields=id 2. query=%22((release%3D{id%3D1004});(sprint%3D{id%3D1040});(team%3D{id%3D1004});(severity%3D{id%3D%27list_node.severity.urgent%27});!phase%3D{id+IN+%27phase.defect.closed%27,%27phase.defect.duplicate%27,%27phase.defect.rejected%27})%22 The actual output - 1. ('fields', 'id') 2. ('query', '"((release={id=1004})') 3. ('(sprint={id=1040})', '') 4. ('(team={id=1004})', '') 5. ("(severity={id='list_node.severity.urgent'})", '') 6. ('!phase={id IN \'phase.defect.closed\',\'phase.defect.duplicate\',\'phase.defect.rejected\'})"', '') ---------- nosy: +Kobi Gana Added file: https://bugs.python.org/file48146/parse_querystring.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 06:12:33 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 Feb 2019 11:12:33 +0000 Subject: [issue35951] os.renames() creates directories if original name doesn't exist In-Reply-To: <1549732242.93.0.821054504106.issue35951@roundup.psfhosted.org> Message-ID: <1550401953.39.0.438614693472.issue35951@roundup.psfhosted.org> Serhiy Storchaka added the comment: There are possible race conditions. Other process can create the same target directory (if it does not exist yet) by calling os.makedirs() for example. It will be impolite to remove the directory just after the second process checked that it exists (or even after it created it). Also, the created directory will left if the program crash before deleting it. os.renames() to non-existing directory can not be atomic. It can interfere with other processes or threads. We should just document this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 06:20:42 2019 From: report at bugs.python.org (gary ruben) Date: Sun, 17 Feb 2019 11:20:42 +0000 Subject: [issue33935] shutil.copyfile throws incorrect SameFileError on Google Drive File Stream In-Reply-To: <1529627906.69.0.56676864532.issue33935@psf.upfronthosting.co.za> Message-ID: <1550402442.44.0.106612676748.issue33935@roundup.psfhosted.org> gary ruben added the comment: I wanted to add a datapoint to this. I also experience this problem in Windows but not with Google Drive File Stream. In my case it is also being triggered by Jupyter, which was where Deniz first noticed it, but I was saving the notebook to my Z: drive, which is a mapping of a network drive that is backed up with Windows' Sync Center; nothing to do with Google's file stream, but a standard Windows feature that triggers the same bug. For the moment, I find that Deniz's workaround lets me continue to use Jupyter in conjunction with that drive path. ---------- nosy: +gary ruben _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 06:51:01 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Sun, 17 Feb 2019 11:51:01 +0000 Subject: [issue33935] shutil.copyfile throws incorrect SameFileError on Google Drive File Stream In-Reply-To: <1529627906.69.0.56676864532.issue33935@psf.upfronthosting.co.za> Message-ID: <1550404261.96.0.889291213469.issue33935@roundup.psfhosted.org> Giampaolo Rodola' added the comment: @eryksun > Using the VSN and file index as if they're the same as POSIX st_dev and st_ino is technically wrong. There is no guarantee that this tuple uniquely identifies a file in Windows. I agree. FWIW, I faced the same issue on pyftpdlib and ended up not supporting Windows: https://github.com/giampaolo/pyftpdlib/blob/eef8a5650cd611da1df5fce16974ce90f43f4dc0/pyftpdlib/filesystems.py#L596-L605 It seems to me the problem here is os.path.samefile(): https://github.com/python/cpython/blob/0185f34ddcf07b78feb6ac666fbfd4615d26b028/Lib/genericpath.py#L87-L98 @steve.dower > For Windows it would be best (though slower) to pass the paths through os._getfinalpathname before comparison. It seems this is how samefile() was originally implemented but it was changed: https://github.com/python/cpython/commit/490b32a3976d84eaf1d6ca8cdcb00eac0ce5055b https://bugs.python.org/issue11939 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 07:03:00 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 17 Feb 2019 12:03:00 +0000 Subject: [issue34720] Fix test_importlib.test_bad_traverse for AIX In-Reply-To: <1537272185.7.0.956365154283.issue34720@psf.upfronthosting.co.za> Message-ID: <1550404980.15.0.0215886611322.issue34720@roundup.psfhosted.org> miss-islington added the comment: New changeset 1bf8845f74013c5f1cc5f49a11e52c652a1fb9dd by Miss Islington (bot) (Michael Felt) in branch 'master': bpo-34720: Fix test_importlib.test_bad_traverse for AIX (GH-9391) https://github.com/python/cpython/commit/1bf8845f74013c5f1cc5f49a11e52c652a1fb9dd ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 07:59:08 2019 From: report at bugs.python.org (jt) Date: Sun, 17 Feb 2019 12:59:08 +0000 Subject: [issue36010] Please provide a .zip Windows release of Python that is not crippled/for embedding only In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org> Message-ID: <1550408348.82.0.0930857647816.issue36010@roundup.psfhosted.org> jt added the comment: Ok, so I just tested this by 1. Installing Python 3.7.2 with the regular installer 2. Copying out "Lib\venv" and "Lib\ensurepip" into another folder 3. Uninstalling Python 3.7.2 (there is now no user-available install of Python on this system) 4. Installing Python via NuGet and copying in venv & ensurepip 5. Creating a virtualenv with subprocess.check_output([sys.executable, "-m", "venv", ...path...]) using the NuGet python 6. Installing things with pip inside that venv That worked fine for me, I installed Cython and some other packages of mine with no issue. Is there anything else I should test? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 08:32:12 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Sun, 17 Feb 2019 13:32:12 +0000 Subject: [issue33944] Deprecate and remove pth files In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za> Message-ID: <1550410332.47.0.727460228905.issue33944@roundup.psfhosted.org> Cheryl Sabella added the comment: Hello all, There was a lot of traction on this discussion a month ago and I was wondering if any updates/expectations should be set? Specifically: 1. There is a PR for a doc change that Terry approved, but wanted another core dev to look at. If there is agreement on the doc change, then perhaps it can be merged for 3.8? If not, then perhaps it can be closed? 2. There was discussion about creating a PEP and I believe Barry, Jason, and possibly Nick said they wanted to work on it. Has more work been done on that? I'm not trying to push anyone, but I saw on other threads about the virtual whiteboard group being created to get some traction on ideas before PyCon, so I just wanted to put this back on the radar in case you wanted it to generate discussion at the language summit. 3. I realize that PEPs are needed for any change and even to define what that change might look like, but is there any value in adding PendingDeprecationWarnings for 3.8 if that's a possible action that will happen? As I understand it, it would be easier to remove that warning later instead of delaying any actions from it. Thanks! ---------- nosy: +cheryl.sabella _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 08:36:32 2019 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 17 Feb 2019 13:36:32 +0000 Subject: [issue35884] Add variable access benchmark to Tools/Scripts In-Reply-To: <1549052380.12.0.716539002961.issue35884@roundup.psfhosted.org> Message-ID: <1550410592.4.0.570682013713.issue35884@roundup.psfhosted.org> Change by Stefan Behnel : ---------- pull_requests: +11931 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 09:12:18 2019 From: report at bugs.python.org (jt) Date: Sun, 17 Feb 2019 14:12:18 +0000 Subject: [issue36010] Please provide a .zip Windows release of Python that is not crippled/for embedding only In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org> Message-ID: <1550412738.51.0.0258238146742.issue36010@roundup.psfhosted.org> jt added the comment: Okay there is one issue that looks like it might be venv related, which is that upgrading pip itself doesn't seem to work for some reason (while installing other packages in the venv worked fine): Could not install packages due to an EnvironmentError: [WinError 5] Access is denied: 'C:\\Users\\Jonas\\AppData\\Local\\Temp\\pip-uninstall-l4qh2ucu\\myproject\\tools\\windows\\.python-win\\spen-venv\\scripts\\pip.exe' Consider using the `--user` option or check the permissions. Traceback (most recent call last): File "C:\myproject\tools\windows\\windows-build.py", line 136, in do_build() File "C:\myproject\tools\windows\\windows-build.py", line 74, in do_build os.path.dirname(__file__), ".python-win", "spen-venv" File "C:\myproject\tools\windows\.python-win\python\tools\Lib\subprocess.py", line 395, in check_output **kwargs).stdout File "C:\myproject\tools\windows\.python-win\python\tools\Lib\subprocess.py", line 487, in run output=stdout, stderr=stderr) subprocess.CalledProcessError: Command '['C:\\myproject\\tools\\windows\\.python-win\\spen-venv\\Scripts\\pip', 'install', '--upgrade', 'pip']' returned non-zero exit status 1. C:\myproject> I would expect that to work even without --user so I'm not sure what is going on ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 09:23:43 2019 From: report at bugs.python.org (Addons Zz) Date: Sun, 17 Feb 2019 14:23:43 +0000 Subject: [issue35852] Fixed tests regenerating using CRLF when running it on Windows In-Reply-To: <1548779221.97.0.25499601133.issue35852@roundup.psfhosted.org> Message-ID: <1550413423.48.0.480799071305.issue35852@roundup.psfhosted.org> Change by Addons Zz : ---------- stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 09:31:39 2019 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 17 Feb 2019 14:31:39 +0000 Subject: [issue36012] Investigate slow writes to class variables In-Reply-To: <1550348118.4.0.228746523417.issue36012@roundup.psfhosted.org> Message-ID: <1550413899.89.0.237498164642.issue36012@roundup.psfhosted.org> Change by Stefan Behnel : ---------- keywords: +patch pull_requests: +11932 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 09:36:15 2019 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 17 Feb 2019 14:36:15 +0000 Subject: [issue36012] Investigate slow writes to class variables In-Reply-To: <1550348118.4.0.228746523417.issue36012@roundup.psfhosted.org> Message-ID: <1550414175.14.0.562286002494.issue36012@roundup.psfhosted.org> Stefan Behnel added the comment: It turns out that "update_slot()" is always called, even when we are not updating a slot name (which is always a special dunder-name). The linear search for names in "update_slots()" is a huge waste of time here, and short-circuiting out of it when the name does not start with "_" cuts the overall update time by 50%. I pushed a PR. Another improvement would be a sub-linear algorithm for searching the slot name, but that's a bigger change. ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 09:39:30 2019 From: report at bugs.python.org (yjq) Date: Sun, 17 Feb 2019 14:39:30 +0000 Subject: [issue34148] Fatal read error on socket transport In-Reply-To: <1531923784.93.0.56676864532.issue34148@psf.upfronthosting.co.za> Message-ID: <1550414370.54.0.303858058895.issue34148@roundup.psfhosted.org> yjq added the comment: Other people also found this in a year. And asvetlov already pull requests. But no one cares about this at all! https://community.home-assistant.io/t/announcement-appdaemon-3-0/47394/56 https://github.com/aio-libs/aiokafka/issues/344 https://github.com/conjure-up/conjure-up/issues/1513 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 10:03:22 2019 From: report at bugs.python.org (nr) Date: Sun, 17 Feb 2019 15:03:22 +0000 Subject: [issue5038] urrlib2/httplib doesn't reset file position between requests In-Reply-To: <1232730438.9.0.904675957675.issue5038@psf.upfronthosting.co.za> Message-ID: <1550415802.16.0.338505503893.issue5038@roundup.psfhosted.org> nr added the comment: the pull request now passed the build checks, please review the code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 10:19:53 2019 From: report at bugs.python.org (Christian Korneck) Date: Sun, 17 Feb 2019 15:19:53 +0000 Subject: [issue36010] Please provide a .zip Windows release of Python that is not crippled/for embedding only In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org> Message-ID: <1550416793.79.0.809731693913.issue36010@roundup.psfhosted.org> Christian Korneck added the comment: for Python 2.7 you can extract the MSI installer (much like a zip file): mkdir "c:\targetdir" msiexec /a "c:\python-2.7.8.amd64.msi" /quiet /norestart TARGETDIR=c:\targetdir msiexec is part of all Windows editions (except for nanoserver). Side note: extracting the MSI does not enable pip. If you need pip, run this on your targetdir: c:\targetdir\python.exe -m ensurepip alternatively, you could perform an unattended installation: msiexec /i "c:\python-2.7.8.amd64.msi" /quiet /norestart Unattended installation also works for Python 3.7: "c:\python-3.7.2-amd64.exe" /quiet InstallAllUsers=1 PrependPath=1 These options worked fine for me in windows containers for CI stuff with servercore. The unattended installation of Python 3.7 also worked fine for me in nanoserver. ---------- nosy: +chris-k _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 11:47:45 2019 From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=) Date: Sun, 17 Feb 2019 16:47:45 +0000 Subject: [issue35153] Allow to set headers in xmlrpc.client.ServerProxy In-Reply-To: <1541244371.62.0.788709270274.issue35153@psf.upfronthosting.co.za> Message-ID: <1550422065.26.0.0590937200735.issue35153@roundup.psfhosted.org> C?dric Krier added the comment: I have another use case to be able to set headers to xmlrpc: http://www.roundup-tracker.org/docs/xmlrpc.html#advanced-python-client-adding-anti-csrf-headers ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 12:07:51 2019 From: report at bugs.python.org (Paul Moore) Date: Sun, 17 Feb 2019 17:07:51 +0000 Subject: [issue36010] Please provide a .zip Windows release of Python that is not crippled/for embedding only In-Reply-To: <1550412738.51.0.0258238146742.issue36010@roundup.psfhosted.org> Message-ID: Paul Moore added the comment: On Sun, 17 Feb 2019 at 14:12, jt wrote: > subprocess.CalledProcessError: Command '['C:\\myproject\\tools\\windows\\.python-win\\spen-venv\\Scripts\\pip', 'install', '--upgrade', 'pip']' returned non-zero exit status 1. > C:\myproject> > > I would expect that to work even without --user so I'm not sure what is going on That's normal behaviour. You can't upgrade pip in-place with the wrapper, the correct command is python -m pip install --upgrade pip Paul ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 12:44:38 2019 From: report at bugs.python.org (nr) Date: Sun, 17 Feb 2019 17:44:38 +0000 Subject: [issue20116] urlparse.parse_qs should take argument for query separator In-Reply-To: <1388777959.1.0.144368039339.issue20116@psf.upfronthosting.co.za> Message-ID: <1550425478.73.0.64914030936.issue20116@roundup.psfhosted.org> nr added the comment: W3C allows both constructs, ampersand and semicolon. https://www.w3.org/TR/html401/appendix/notes.html#h-B.2.2 Especially servlet containers and servers running CGI programs often use semicolons as a separator. I would say to parse either ampersands OR semicolons and keep a priority to ampersands. For example the query strings: ?fields=id&query=%22((release%3D{id%3D1004});(sprint%3D{id%3D1040});(team%3D{id%3D1004});(severity%3D{id%3D%27list_node.severity.urgent%27});!phase%3D{id+IN+%27phase.defect.closed%27,%27phase.defect.duplicate%27,%27phase.defect.rejected%27})%22 ?fruits=lemon;lime&family=citrus should be parsed with & separators only. The modified example without & character: ?fruits=lemon;family=citrus can be parsed with semicolon as a separator because it contains both '=' and ';' but no '&' characters. ---------- nosy: +nr _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 13:07:49 2019 From: report at bugs.python.org (Paul Ganssle) Date: Sun, 17 Feb 2019 18:07:49 +0000 Subject: [issue36004] Add datetime.fromisocalendar In-Reply-To: <1550240916.35.0.451510247621.issue36004@roundup.psfhosted.org> Message-ID: <1550426869.92.0.150074464655.issue36004@roundup.psfhosted.org> Paul Ganssle added the comment: The attached PR is more or less fully ready, I think the correct answers to 1, 3 and 4 are that we should go with 3 separate arguments and we should not allow either time components or tz components, at least in this version. In the future, I don't think it will be backwards incompatible to add in these features if they are desired (though I imagine they won't be terribly in demand, and it's pretty easy to work around). The only real remaining question is number 2. Right now I am allowing keyword arguments, but the only real value I see in doing that is that PEP 570 (positional-only parameters) is not done yet and it's kind of annoying to implement "positional only parameters" in the pure Python version. If anyone feels strongly about this, let me know, otherwise I'll switch the implementation over to positional-only parameters. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 14:02:34 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Sun, 17 Feb 2019 19:02:34 +0000 Subject: [issue17561] Add socket.bind_socket() convenience function In-Reply-To: <1364402909.97.0.467946240817.issue17561@psf.upfronthosting.co.za> Message-ID: <1550430154.32.0.188545624234.issue17561@roundup.psfhosted.org> Change by Giampaolo Rodola' : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 14:20:24 2019 From: report at bugs.python.org (Riccardo Magliocchetti) Date: Sun, 17 Feb 2019 19:20:24 +0000 Subject: [issue36015] streamhandler canont represent streams with an integer as name Message-ID: <1550431224.14.0.504793638163.issue36015@roundup.psfhosted.org> New submission from Riccardo Magliocchetti : When debugging uwsgi logging issues with python3.7 i got this on python 3.7.2: Traceback (most recent call last): File "/usr/lib/python3.7/logging/__init__.py", line 269, in _after_at_fork_weak_calls _at_fork_weak_calls('release') File "/usr/lib/python3.7/logging/__init__.py", line 261, in _at_fork_weak_calls method_name, "method:", err, file=sys.stderr) File "/usr/lib/python3.7/logging/__init__.py", line 1066, in __repr__ name = name + ' ' TypeError: unsupported operand type(s) for +: 'int' and 'str' AFAICS uwsgi creates sys.stderr as an unbuffered file with PyFile_FromFd() and sets it to sys dict. ---------- components: Library (Lib) messages: 335784 nosy: Riccardo Magliocchetti priority: normal severity: normal status: open title: streamhandler canont represent streams with an integer as name type: crash versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 14:20:57 2019 From: report at bugs.python.org (Riccardo Magliocchetti) Date: Sun, 17 Feb 2019 19:20:57 +0000 Subject: [issue36015] streamhandler canont represent streams with an integer as name In-Reply-To: <1550431224.14.0.504793638163.issue36015@roundup.psfhosted.org> Message-ID: <1550431257.69.0.297592079397.issue36015@roundup.psfhosted.org> Change by Riccardo Magliocchetti : ---------- keywords: +patch pull_requests: +11933 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 14:27:53 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 17 Feb 2019 19:27:53 +0000 Subject: [issue35892] Fix awkwardness of statistics.mode() for multimodal datasets In-Reply-To: <1549219885.57.0.86866159357.issue35892@roundup.psfhosted.org> Message-ID: <1550431673.6.0.733016047475.issue35892@roundup.psfhosted.org> Raymond Hettinger added the comment: The attraction to having a first_tie=False flag is that it is backwards compatible with the current API. However on further reflection, people would almost never want the existing behavior of raising an exception rather than returning a useful result. So, we could make first_tie the default behavior and not have a flag at all. We would also add a separate multimode() function with a clean signature, always returning a list. FWIW, MS Excel evolved to this solution as well (it has MODE.SGNL and MODE.MULT). This would give us a clean, fast API with no flags: mode(Iterable) -> scalar multimode(Iterable) -> list ISTM this is an all round win: * Fixes the severe usability problems with mode(). Currently, it can't be used without a try/except. The except-clause can't distinguish between an empty data condition and no unique mode condition, nor can the except clause access the dataset counts to get to a useful answer. * It makes mode() memory friendly and faster. Currently, mode() has to convert the counter items into a list() and run a full sort. However, if we only need the first mode, we can feed the items iterator to max() and make only a single pass, never having to create a list. However, there would be an incompatibility in the API change. It is possible that a person really does want an exception instead of a value when there are multiple modes. In that case, this would break their code so that they have to switch to multimode() as a remediation. OTOH, it is also possible that people have existing code that uses mode() but their code has a latent bug because they weren't using a try/except and haven't yet encountered a multi-modal dataset. So here are some options: * Change mode() to return the first tie instead of raising an exception. This is a behavior change but leaves you with the cleanest API going forward. * Add a Deprecation warning to the current behavior of mode() when it finds multimodal data. Then change the behavior in Python 3.9. This is uncomfortable for one release, but does get us to the cleanest API and best performance. * Change mode() to have a flag where first_tie defaults to False. This is backwards compatible, but it doesn't fix latent bugs, it leaves us with on-going API complexities, and the default case remains the least usable option. * Leave mode() as-is and just document its limitations. For any of those options, we should still add a separate multimode() function. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 14:54:05 2019 From: report at bugs.python.org (jt) Date: Sun, 17 Feb 2019 19:54:05 +0000 Subject: [issue36010] Please provide a .zip Windows release of Python that is not crippled/for embedding only In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org> Message-ID: <1550433245.39.0.14782264222.issue36010@roundup.psfhosted.org> jt added the comment: > alternatively, you could perform an unattended installation: I know, I already listed the downsides above. (Basically outside of a container it's a bad way to do things because it has too many side effects, and it likes to break when interrupted after which you will need to repair/reinstall, then uninstall again, only then you can do a clean install... it is quite annoying.) It's not that it's not working, it's just not a very good option in some scenarios which is why I made the ticket > That's normal behaviour. You can't upgrade pip in-place with the wrapper Oh, right! Thanks, that explains it. In that case I suppose it works perfectly fine? Does that mean there's a chance venv & ensurepip will be added to the NuGet version? Because then I'm definitely switching over to that one for good ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 15:20:35 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Sun, 17 Feb 2019 20:20:35 +0000 Subject: [issue36016] Allow gc.getobjects to return the objects tracked by a specific generation Message-ID: <1550434835.07.0.108252572436.issue36016@roundup.psfhosted.org> New submission from Pablo Galindo Salgado : gc.get_objects() return all the objects tracked by the garbage collector. This is useful, but right now there is no way of knowing in which generation each object is currently on. This information can be beneficial to understand better the state of the garbage collector in a particular moment in time. This will allow knowing what are the oldest object tracked by the collector, gathering more fine-grained statistics about how generations are filled, better debugging and better insights about the internal structure of the generations. To allow this, I propose a new optional parameter to gc.get_objects, allowing the user to specify the generation to get the objects from. ---------- components: Interpreter Core messages: 335787 nosy: pablogsal priority: normal severity: normal status: open title: Allow gc.getobjects to return the objects tracked by a specific generation versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 15:21:59 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Sun, 17 Feb 2019 20:21:59 +0000 Subject: [issue36016] Allow gc.getobjects to return the objects tracked by a specific generation In-Reply-To: <1550434835.07.0.108252572436.issue36016@roundup.psfhosted.org> Message-ID: <1550434919.93.0.133831474204.issue36016@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- keywords: +patch pull_requests: +11935 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 15:22:27 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Sun, 17 Feb 2019 20:22:27 +0000 Subject: [issue36016] Allow gc.getobjects to return the objects tracked by a specific generation In-Reply-To: <1550434835.07.0.108252572436.issue36016@roundup.psfhosted.org> Message-ID: <1550434947.49.0.0916287037346.issue36016@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- nosy: +nascheme _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 15:35:15 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Sun, 17 Feb 2019 20:35:15 +0000 Subject: [issue36016] Allow gc.getobjects to return the objects tracked by a specific generation In-Reply-To: <1550434835.07.0.108252572436.issue36016@roundup.psfhosted.org> Message-ID: <1550435715.6.0.776279539557.issue36016@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 16:15:28 2019 From: report at bugs.python.org (Mathijs Brands) Date: Sun, 17 Feb 2019 21:15:28 +0000 Subject: [issue36017] test_grp Message-ID: <1550438128.14.0.0187482999284.issue36017@roundup.psfhosted.org> Change by Mathijs Brands : ---------- components: Tests nosy: mjbrands priority: normal severity: normal status: open title: test_grp type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 16:26:41 2019 From: report at bugs.python.org (Mathijs Brands) Date: Sun, 17 Feb 2019 21:26:41 +0000 Subject: [issue36017] test_grp Message-ID: <1550438801.86.0.404382548135.issue36017@roundup.psfhosted.org> New submission from Mathijs Brands : # Choose a non-existent gid. fakegid = 4127 while fakegid in bygids: fakegid = (fakegid * 3) % 0x10000 self.assertRaises(KeyError, grp.getgrgid, fakegid) When a Linux system is configured to use LDAP for user and group information, there is no guarantee that grp.getgrall will actually return a complete list of all configured groups. In my case, grp.getgrall only returns 58 groups, while there are actually tens of thousands of groups (every user has their own group, which generally only has one member). The groups return by grp.getgrall are the 'system' groups (things like daemon, wheel, etc). In our case 4127 is an existing group and grp.getgrid can query information for it (and does not thrown the expected KeyError, since it is a valid group). Perhaps this unit test should not rely on getgrall, but relying on getgrid on the test for getgrid itself is also problematic. I have seen this LDAP setup, where getgrall does not return the full set of groups, at two different parties with lots of users (and Novell eDirectory). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 16:35:36 2019 From: report at bugs.python.org (Neil Schemenauer) Date: Sun, 17 Feb 2019 21:35:36 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1550439336.69.0.682349467142.issue35813@roundup.psfhosted.org> Neil Schemenauer added the comment: Some thoughts on this API. I think we need the "create with exclusive behavior" option, even though we don't know how to implement it on Windows right now. To me, there are two cases when calling SharedMemory: 1) You want to create a new shared memory object. In this case, if your chosen name conflicts with an existing name, you should get an error. If you don't, you could be sharing data between unrelated processes. Chaos will ensue. 2) You want to attach to an existing shared memory object. You have a name, passed to you by some means. In this case, you don't want to create a new object if it doesn't exist. You should get an error. I thought there might be a 3rd case where you have "co-equal" processes and any one of them could create and the others would attach. That dosen't seem safe though, if you can't ensure a unique name is used. You might attach to some unrelated shared memory object due to a name conflict. So, I think the API should not support this case. To support 1 & 2, we could just have 'create'. When true, it would act like O_CREX. When false, you would get an error if the name doesn't already exist. Regarding 'size', I think it is a bit weird how it currently works. Maybe 'size' should only be valid if you are creating a new shared memory object. If you are attaching to an existing one, size would be found from the existing object (if that's possible on all platforms). SharedMemory could grow a "resize()" method that lets you enlarge the underlying memory object. I don't know if that's useful in practice so maybe better to leave it out and keep the API simple. Should 'size' be a property that always does fstat() to find the size of the underlying file? Or, should it be the size passed in (for create=True) or the size of the file when the mmap is created. I'm not sure but maybe it is better to not always do the fstat(). The 'read_only' keyword doesn't make sense if you care creating a new object and need to call ftruncate() on it. I think the OS will not allow that. Maybe 'read_only' should not be allowed if you are creating. Or, you should have a method that takes a read-write object and makes it read-only. On Linux at least, shm_open() is just a thin layer over open(). So the shared memory file is really just a regular file that is stored in /var/run/shm. If you realize that, it seems SharedMemory() is much like tempfile.NamedTemporaryFile(). E.g. if you create a NamedTemporaryFile under /var/run/shm it will behave like the file descriptor created by SharedMemory(). SharedMemory() objects have the difference that they don't clean themselves up. Also, they don't set the close-on-fork flag on the file descriptor. Maybe they should? It seems unclear to me how you should avoid cluttering /var/run/shm with shared memory objects that people forget to cleanup. I guess the plan is that people need to call unlink() at the right time. That seems error prone though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 18:13:55 2019 From: report at bugs.python.org (Ivan Levkivskyi) Date: Sun, 17 Feb 2019 23:13:55 +0000 Subject: [issue35992] Metaclasses interfere with __class_getitem__ In-Reply-To: <1550124852.78.0.300044847884.issue35992@roundup.psfhosted.org> Message-ID: <1550445235.19.0.0826588080454.issue35992@roundup.psfhosted.org> Ivan Levkivskyi added the comment: New changeset ac28147e78c45a6217d348ce90ca5281d91f676f by Ivan Levkivskyi in branch 'master': bpo-35992: Use PySequence_GetItem only if sq_item is not NULL (GH-11857) https://github.com/python/cpython/commit/ac28147e78c45a6217d348ce90ca5281d91f676f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 18:14:07 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 17 Feb 2019 23:14:07 +0000 Subject: [issue35992] Metaclasses interfere with __class_getitem__ In-Reply-To: <1550124852.78.0.300044847884.issue35992@roundup.psfhosted.org> Message-ID: <1550445247.19.0.0347443866697.issue35992@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11936 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 18:33:09 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 17 Feb 2019 23:33:09 +0000 Subject: [issue35992] Metaclasses interfere with __class_getitem__ In-Reply-To: <1550124852.78.0.300044847884.issue35992@roundup.psfhosted.org> Message-ID: <1550446389.03.0.309194342658.issue35992@roundup.psfhosted.org> miss-islington added the comment: New changeset a7f929db605326da452fbdeebfe341afa9316d25 by Miss Islington (bot) in branch '3.7': bpo-35992: Use PySequence_GetItem only if sq_item is not NULL (GH-11857) https://github.com/python/cpython/commit/a7f929db605326da452fbdeebfe341afa9316d25 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 18:35:10 2019 From: report at bugs.python.org (Ivan Levkivskyi) Date: Sun, 17 Feb 2019 23:35:10 +0000 Subject: [issue35992] Metaclasses interfere with __class_getitem__ In-Reply-To: <1550124852.78.0.300044847884.issue35992@roundup.psfhosted.org> Message-ID: <1550446510.52.0.713531096253.issue35992@roundup.psfhosted.org> Change by Ivan Levkivskyi : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 19:00:59 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 18 Feb 2019 00:00:59 +0000 Subject: [issue36018] Add a Normal Distribution class to the statistics module Message-ID: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org> New submission from Raymond Hettinger : Attached is a class that I've found useful for doing practical statistics work with normal distributions. It provides a nice, high-level API that makes short-work of everyday statistical problems. ------ Examples -------- # Simple scaling and translation temperature_february = NormalDist(5, 2.5) # Celsius print(temperature_february * (9/5) + 32) # Fahrenheit # Classic probability problems # https://blog.prepscholar.com/sat-standard-deviation # The mean score on a SAT exam is 1060 with a standard deviation of 195 # What percentage of students score between 1100 and 1200? sat = NormalDist(1060, 195) fraction = sat.cdf(1200) - sat.cdf(1100) print(f'{fraction * 100 :.1f}% score between 1100 and 1200') # Combination of normal distributions by summing variances birth_weights = NormalDist.from_samples([2.5, 3.1, 2.1, 2.4, 2.7, 3.5]) drug_effects = NormalDist(0.4, 0.15) print(birth_weights + drug_effects) # Statistical calculation estimates using simulations # Estimate the distribution of X * Y / Z n = 100_000 X = NormalDist(350, 15).examples(n) Y = NormalDist(47, 17).examples(n) Z = NormalDist(62, 6).examples(n) print(NormalDist.from_samples(x * y / z for x, y, z in zip(X, Y, Z))) # Naive Bayesian Classifier # https://en.wikipedia.org/wiki/Naive_Bayes_classifier#Sex_classification height_male = NormalDist.from_samples([6, 5.92, 5.58, 5.92]) height_female = NormalDist.from_samples([5, 5.5, 5.42, 5.75]) weight_male = NormalDist.from_samples([180, 190, 170, 165]) weight_female = NormalDist.from_samples([100, 150, 130, 150]) foot_size_male = NormalDist.from_samples([12, 11, 12, 10]) foot_size_female = NormalDist.from_samples([6, 8, 7, 9]) prior_male = 0.5 prior_female = 0.5 posterior_male = prior_male * height_male.pdf(6) * weight_male.pdf(130) * foot_size_male.pdf(8) posterior_female = prior_female * height_female.pdf(6) * weight_female.pdf(130) * foot_size_female.pdf(8) print('Predict', 'male' if posterior_male > posterior_female else 'female') ---------- assignee: steven.daprano components: Library (Lib) files: gauss.py messages: 335792 nosy: rhettinger, steven.daprano priority: normal severity: normal status: open title: Add a Normal Distribution class to the statistics module type: enhancement versions: Python 3.8 Added file: https://bugs.python.org/file48147/gauss.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 19:41:35 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 18 Feb 2019 00:41:35 +0000 Subject: [issue36019] test_urllib fail in s390x buildbots Message-ID: <1550450495.08.0.90804425705.issue36019@roundup.psfhosted.org> New submission from Pablo Galindo Salgado : test_urllib fail in s390x buildbots. It does not seem like a temporary failure as they keep failing consistently. Some failed builds: https://buildbot.python.org/all/#builders/126/builds/1010 https://buildbot.python.org/all/#builders/122/builds/1026 https://buildbot.python.org/all/#builders/119/builds/1060 https://buildbot.python.org/all/#builders/21/builds/2332 ====================================================================== ERROR: test_close (test.test_urllib2net.CloseSocketTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/test/test_urllib2net.py", line 89, in test_close response = _urlopen_with_retry(url) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/test/test_urllib2net.py", line 27, in wrapped return _retry_thrice(func, exc, *args, **kwargs) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/test/test_urllib2net.py", line 23, in _retry_thrice raise last_exc File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/test/test_urllib2net.py", line 19, in _retry_thrice return func(*args, **kwargs) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 222, in urlopen return opener.open(url, data, timeout) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 531, in open response = meth(req, response) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 641, in http_response 'http', request, response, code, msg, hdrs) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 569, in error return self._call_chain(*args) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 503, in _call_chain result = func(*args) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 649, in http_error_default raise HTTPError(req.full_url, code, msg, hdrs, fp) urllib.error.HTTPError: HTTP Error 403: Forbidden ====================================================================== ERROR: test_custom_headers (test.test_urllib2net.OtherNetworkTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/test/test_urllib2net.py", line 181, in test_custom_headers opener.open(request) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 531, in open response = meth(req, response) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 641, in http_response 'http', request, response, code, msg, hdrs) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 569, in error return self._call_chain(*args) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 503, in _call_chain result = func(*args) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 649, in http_error_default raise HTTPError(req.full_url, code, msg, hdrs, fp) urllib.error.HTTPError: HTTP Error 403: Forbidden ====================================================================== ERROR: test_http_basic (test.test_urllib2net.TimeoutTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/test/test_urllib2net.py", line 264, in test_http_basic u = _urlopen_with_retry(url) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/test/test_urllib2net.py", line 27, in wrapped return _retry_thrice(func, exc, *args, **kwargs) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/test/test_urllib2net.py", line 23, in _retry_thrice raise last_exc File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/test/test_urllib2net.py", line 19, in _retry_thrice return func(*args, **kwargs) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 222, in urlopen return opener.open(url, data, timeout) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 531, in open response = meth(req, response) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 641, in http_response 'http', request, response, code, msg, hdrs) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 569, in error return self._call_chain(*args) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 503, in _call_chain result = func(*args) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 649, in http_error_default raise HTTPError(req.full_url, code, msg, hdrs, fp) urllib.error.HTTPError: HTTP Error 403: Forbidden ====================================================================== ERROR: test_http_default_timeout (test.test_urllib2net.TimeoutTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/test/test_urllib2net.py", line 274, in test_http_default_timeout u = _urlopen_with_retry(url) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/test/test_urllib2net.py", line 27, in wrapped return _retry_thrice(func, exc, *args, **kwargs) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/test/test_urllib2net.py", line 23, in _retry_thrice raise last_exc File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/test/test_urllib2net.py", line 19, in _retry_thrice return func(*args, **kwargs) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 222, in urlopen return opener.open(url, data, timeout) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 531, in open response = meth(req, response) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 641, in http_response 'http', request, response, code, msg, hdrs) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 569, in error return self._call_chain(*args) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 503, in _call_chain result = func(*args) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 649, in http_error_default raise HTTPError(req.full_url, code, msg, hdrs, fp) urllib.error.HTTPError: HTTP Error 403: Forbidden ====================================================================== ERROR: test_http_no_timeout (test.test_urllib2net.TimeoutTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/test/test_urllib2net.py", line 286, in test_http_no_timeout u = _urlopen_with_retry(url, timeout=None) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/test/test_urllib2net.py", line 27, in wrapped return _retry_thrice(func, exc, *args, **kwargs) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/test/test_urllib2net.py", line 23, in _retry_thrice raise last_exc File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/test/test_urllib2net.py", line 19, in _retry_thrice return func(*args, **kwargs) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 222, in urlopen return opener.open(url, data, timeout) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 531, in open response = meth(req, response) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 641, in http_response 'http', request, response, code, msg, hdrs) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 569, in error return self._call_chain(*args) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 503, in _call_chain result = func(*args) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 649, in http_error_default raise HTTPError(req.full_url, code, msg, hdrs, fp) urllib.error.HTTPError: HTTP Error 403: Forbidden /home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/test/support/__init__.py:1539: ResourceWarning: unclosed gc.collect() ResourceWarning: Enable tracemalloc to get the object allocation traceback /home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/test/support/__init__.py:1539: ResourceWarning: unclosed gc.collect() ResourceWarning: Enable tracemalloc to get the object allocation traceback /home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/test/support/__init__.py:1539: ResourceWarning: unclosed gc.collect() ResourceWarning: Enable tracemalloc to get the object allocation traceback /home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/test/support/__init__.py:1539: ResourceWarning: unclosed gc.collect() ResourceWarning: Enable tracemalloc to get the object allocation traceback test test_urllib2net failed ====================================================================== ERROR: test_http_timeout (test.test_urllib2net.TimeoutTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/test/test_urllib2net.py", line 295, in test_http_timeout u = _urlopen_with_retry(url, timeout=120) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/test/test_urllib2net.py", line 27, in wrapped return _retry_thrice(func, exc, *args, **kwargs) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/test/test_urllib2net.py", line 23, in _retry_thrice raise last_exc File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/test/test_urllib2net.py", line 19, in _retry_thrice return func(*args, **kwargs) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 222, in urlopen return opener.open(url, data, timeout) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 531, in open response = meth(req, response) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 641, in http_response 'http', request, response, code, msg, hdrs) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 569, in error return self._call_chain(*args) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 503, in _call_chain result = func(*args) File "/home/dje/cpython-buildarea/3.7.edelsohn-rhel-z/build/Lib/urllib/request.py", line 649, in http_error_default raise HTTPError(req.full_url, code, msg, hdrs, fp) urllib.error.HTTPError: HTTP Error 403: Forbidden ---------------------------------------------------------------------- Ran 15 tests in 1.006s FAILED (errors=6, skipped=1) 3 tests failed again: test_urllib2 test_urllib2net test_urllibnet ---------- components: Tests messages: 335793 nosy: David.Edelsohn, pablogsal priority: normal severity: normal status: open title: test_urllib fail in s390x buildbots versions: Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 19:50:38 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 18 Feb 2019 00:50:38 +0000 Subject: [issue36018] Add a Normal Distribution class to the statistics module In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org> Message-ID: <1550451038.18.0.317137377594.issue36018@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- nosy: +mark.dickinson, tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 19:52:41 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 18 Feb 2019 00:52:41 +0000 Subject: [issue36018] Add a Normal Distribution class to the statistics module In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org> Message-ID: <1550451161.42.0.744115399183.issue36018@roundup.psfhosted.org> Change by Raymond Hettinger : Added file: https://bugs.python.org/file48148/gauss_demo.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 19:59:21 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 18 Feb 2019 00:59:21 +0000 Subject: [issue36012] Investigate slow writes to class variables In-Reply-To: <1550348118.4.0.228746523417.issue36012@roundup.psfhosted.org> Message-ID: <1550451561.47.0.223699703112.issue36012@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: This are the timings that I am measuring with PR 11907: Variable and attribute read access: 5.7 ns read_local 5.9 ns read_nonlocal 16.2 ns read_global 24.5 ns read_builtin 20.9 ns read_classvar_from_class 20.0 ns read_classvar_from_instance 29.7 ns read_instancevar 24.7 ns read_instancevar_slots 22.9 ns read_namedtuple 36.8 ns read_boundmethod Variable and attribute write access: 6.9 ns write_local 6.9 ns write_nonlocal 26.7 ns write_global 65.4 ns write_classvar <----- Down from 120.6 ns 49.5 ns write_instancevar 34.5 ns write_instancevar_slots ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 20:32:29 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 18 Feb 2019 01:32:29 +0000 Subject: [issue36012] Investigate slow writes to class variables In-Reply-To: <1550348118.4.0.228746523417.issue36012@roundup.psfhosted.org> Message-ID: <1550453549.82.0.520821804312.issue36012@roundup.psfhosted.org> Raymond Hettinger added the comment: Wow, I didn't expect to get an immediate win this of this magnitude :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 17 22:53:25 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 18 Feb 2019 03:53:25 +0000 Subject: [issue35904] Add statistics.fmean(seq) In-Reply-To: <1549411161.36.0.783593325223.issue35904@roundup.psfhosted.org> Message-ID: <1550462005.16.0.208755684556.issue35904@roundup.psfhosted.org> Raymond Hettinger added the comment: > Yes please! I'm happy with the name fmean Okay, the PR is ready. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 00:50:26 2019 From: report at bugs.python.org (Davin Potts) Date: Mon, 18 Feb 2019 05:50:26 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1550469026.61.0.818974797538.issue35813@roundup.psfhosted.org> Davin Potts added the comment: > I think we need the "create with exclusive behavior" option, even > though we don't know how to implement it on Windows right now. A fix to avoid the potential race condition on Windows is now part of GH-11816. > To support 1 & 2, we could just have 'create'. When true, it would > act like O_CREX. When false, you would get an error if the name > doesn't already exist. I am good with this and now it can be supported. > a 3rd case where you have "co-equal" processes and any one of them > could create and the others would attach. There are some practical use cases motivating this. Rather than debate the merits of those use cases, given the concern raised, perhaps we should forego supporting this 3rd case for now. > Regarding 'size', I think it is a bit weird how it currently works. > Maybe 'size' should only be valid if you are creating a new shared > memory object. This would avoid potential confusion in the details of how attempts to resize do/don't work on different platforms. I would prefer to not need to explain that on MacOS, requesting a smaller size is disallowed. This defers such issues until considering a "resize()" method as you suggest. I like this. > Should 'size' be a property that always does fstat() to find the > size of the underlying file? The potential exists for non-Python code to attach to these same shared memory blocks and alter their size via ftruncate() (only on certain Unix platforms). We could choose to not support such "external" changes and let size be a fixed value from the time of instantiation. But I would like to believe we can be more effective and safely use fstat() behind our reporting of 'size'. > It seems unclear to me how you should avoid cluttering /var/run/shm > with shared memory objects that people forget to cleanup. This is the primary purpose of the SharedMemoryManager. Admittedly, we will not convince everyone to use it when they should, just like we are not able to convince everyone to use NamedTemporaryFile for their temp files. To update the proposed change to the API: * We go with this simpler API: SharedMemory(name=None, create=False, size=0) * 'size' is ignored when create=False * create=True acts like O_CREX and create=False only attaches to existing shared memory blocks Remaining question: do PosixSharedMemory and WindowsNamedSharedMemory mirror this simplified API or do we expose the added functionality each offers, permitting informed users to use things like 'mode' when they know it is enforced on a particular platform? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 02:21:17 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Mon, 18 Feb 2019 07:21:17 +0000 Subject: [issue34817] Ellipsis docs has extra dot in the markdown that makes it look like .... (four dots) In-Reply-To: <1538032499.31.0.545547206417.issue34817@psf.upfronthosting.co.za> Message-ID: <1550474477.36.0.230388586351.issue34817@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 02:41:37 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Mon, 18 Feb 2019 07:41:37 +0000 Subject: [issue35126] Mistake in FAQ about converting number to string. In-Reply-To: <1541005659.07.0.788709270274.issue35126@psf.upfronthosting.co.za> Message-ID: <1550475697.72.0.78049399273.issue35126@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: This is a good first issue. Python 3 docs uses `{:.3f}".format(1.0/3.0)` that was changed as part of 04d8a245f162b33e6c861ba0869918d9262be63e. Python 2 docs could be changed too to use floats that makes the example correct. ---------- nosy: +Mariatta, cheryl.sabella _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 03:04:18 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 18 Feb 2019 08:04:18 +0000 Subject: [issue35899] '_is_sunder' function in 'enum' module fails on empty string In-Reply-To: <1549376859.01.0.998806898699.issue35899@roundup.psfhosted.org> Message-ID: <1550477058.64.0.00704771588614.issue35899@roundup.psfhosted.org> St?phane Wirtel added the comment: Thank you for your contribution. Have a nice day, ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 03:29:05 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 18 Feb 2019 08:29:05 +0000 Subject: [issue35126] Mistake in FAQ about converting number to string. In-Reply-To: <1541005659.07.0.788709270274.issue35126@psf.upfronthosting.co.za> Message-ID: <1550478545.32.0.286425400443.issue35126@roundup.psfhosted.org> St?phane Wirtel added the comment: I am working on this issue. ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 03:43:50 2019 From: report at bugs.python.org (SilentGhost) Date: Mon, 18 Feb 2019 08:43:50 +0000 Subject: [issue36015] streamhandler canont represent streams with an integer as name In-Reply-To: <1550431224.14.0.504793638163.issue36015@roundup.psfhosted.org> Message-ID: <1550479430.19.0.974623834961.issue36015@roundup.psfhosted.org> Change by SilentGhost : ---------- nosy: +vinay.sajip type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 04:01:52 2019 From: report at bugs.python.org (Kobi Gana) Date: Mon, 18 Feb 2019 09:01:52 +0000 Subject: [issue20116] urlparse.parse_qs should take argument for query separator In-Reply-To: <1550425478.73.0.64914030936.issue20116@roundup.psfhosted.org> Message-ID: Kobi Gana added the comment: We are on the same page and we should also consider marked this as defect. Thanks On Sun, Feb 17, 2019 at 7:44 PM nr wrote: > > nr added the comment: > > W3C allows both constructs, ampersand and semicolon. > https://www.w3.org/TR/html401/appendix/notes.html#h-B.2.2 > > Especially servlet containers and servers running CGI programs often use > semicolons as a separator. > > I would say to parse either ampersands OR semicolons and keep a priority > to ampersands. > > For example the query strings: > > > ?fields=id&query=%22((release%3D{id%3D1004});(sprint%3D{id%3D1040});(team%3D{id%3D1004});(severity%3D{id%3D%27list_node.severity.urgent%27});!phase%3D{id+IN+%27phase.defect.closed%27,%27phase.defect.duplicate%27,%27phase.defect.rejected%27})%22 > > ?fruits=lemon;lime&family=citrus > > should be parsed with & separators only. > > The modified example without & character: > ?fruits=lemon;family=citrus > > can be parsed with semicolon as a separator because it contains both '=' > and ';' but no '&' characters. > > ---------- > nosy: +nr > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 04:17:17 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 18 Feb 2019 09:17:17 +0000 Subject: [issue35126] Mistake in FAQ about converting number to string. In-Reply-To: <1541005659.07.0.788709270274.issue35126@psf.upfronthosting.co.za> Message-ID: <1550481437.07.0.331011649233.issue35126@roundup.psfhosted.org> Change by St?phane Wirtel : ---------- keywords: +patch pull_requests: +11937 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 04:18:45 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 18 Feb 2019 09:18:45 +0000 Subject: [issue35126] Mistake in FAQ about converting number to string. In-Reply-To: <1541005659.07.0.788709270274.issue35126@psf.upfronthosting.co.za> Message-ID: <1550481525.89.0.186999413217.issue35126@roundup.psfhosted.org> St?phane Wirtel added the comment: Hi @xtreak, I have just submitted a PR but where I explain the change with Python2/3 and the division operator. Have a nice day, ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 05:18:26 2019 From: report at bugs.python.org (palotasb-conti) Date: Mon, 18 Feb 2019 10:18:26 +0000 Subject: [issue36020] HAVE_SNPRINTF and MSVC std::snprintf support Message-ID: <1550485106.18.0.506219958256.issue36020@roundup.psfhosted.org> New submission from palotasb-conti : Abstract: pyerrors.h defines snprintf as a macro on MSVC even on versions of MSVC where this workaround causes bugs. snprintf is defined as _snprintf in pyerrors.h, see: https://github.com/python/cpython/blob/ac28147e78c45a6217d348ce90ca5281d91f676f/Include/pyerrors.h#L326-L330 The conditions for this should exclude _MSC_VER >= 1900 where (std::)snprintf is correctly defined. Since this is not the case, subsequent user code that tries to use std::snprintf will fail with an err (_snprintf is not a member of namespace std). ---------- components: Windows messages: 335803 nosy: palotasb-conti, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: HAVE_SNPRINTF and MSVC std::snprintf support type: compile error versions: Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 05:46:48 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 18 Feb 2019 10:46:48 +0000 Subject: [issue35942] posixmodule.c:path_converter() returns an invalid exception message for broken PathLike objects In-Reply-To: <1549643679.09.0.475002054663.issue35942@roundup.psfhosted.org> Message-ID: <1550486808.03.0.302517374465.issue35942@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: New changeset 09fbcd6085e18b534fd4161844ff39f77eb4a082 by Pablo Galindo in branch 'master': bpo-35942: Improve the error message if __fspath__ returns invalid types in path_converter (GH-11831) https://github.com/python/cpython/commit/09fbcd6085e18b534fd4161844ff39f77eb4a082 ---------- nosy: +pablogsal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 05:46:48 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 18 Feb 2019 10:46:48 +0000 Subject: [issue35942] posixmodule.c:path_converter() returns an invalid exception message for broken PathLike objects In-Reply-To: <1549643679.09.0.475002054663.issue35942@roundup.psfhosted.org> Message-ID: <1550486808.89.0.634163957069.issue35942@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11938 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 05:50:35 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 18 Feb 2019 10:50:35 +0000 Subject: [issue20215] socketserver.TCPServer can not listen IPv6 address In-Reply-To: <1389319382.42.0.481013787618.issue20215@psf.upfronthosting.co.za> Message-ID: <1550487035.17.0.032764363701.issue20215@roundup.psfhosted.org> Change by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 06:00:53 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Feb 2019 11:00:53 +0000 Subject: [issue36021] [Security][Windows] webbrowser: WindowsDefault uses os.startfile() and so can be abused to run arbitrary commands Message-ID: <1550487653.15.0.496398912417.issue36021@roundup.psfhosted.org> New submission from STINNER Victor : The webbrowser module uses WindowsDefault which calls os.startfile() and so can be abused to run arbitrary commands. WindowsDefault should do log a warning or raise an error if the URL is unsafe. I'm not sure how to build a list of safe URL schemes. At least, we can explicitly exclude "C:\WINDOWS\system32\calc.exe" which doesn't contain "://". The union of all "uses_*" constants of urllib.parser give me this sorted list of URL schemes: ['', 'file', 'ftp', 'git', 'git+ssh', 'gopher', 'hdl', 'http', 'https', 'imap', 'mailto', 'mms', 'news', 'nfs', 'nntp', 'prospero', 'rsync', 'rtsp', 'rtspu', 'sftp', 'shttp', 'sip', 'sips', 'snews', 'svn', 'svn+ssh', 'tel', 'telnet', 'wais', 'ws', 'wss'] Would it make sense to ensure that urllib.parser can parse an email to check if the URL looks valid? ---------- components: Library (Lib) messages: 335805 nosy: vstinner priority: normal severity: normal status: open title: [Security][Windows] webbrowser: WindowsDefault uses os.startfile() and so can be abused to run arbitrary commands type: security versions: Python 2.7, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 06:01:44 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Feb 2019 11:01:44 +0000 Subject: [issue36021] [Security][Windows] webbrowser: WindowsDefault uses os.startfile() and so can be abused to run arbitrary commands In-Reply-To: <1550487653.15.0.496398912417.issue36021@roundup.psfhosted.org> Message-ID: <1550487704.46.0.288433016779.issue36021@roundup.psfhosted.org> STINNER Victor added the comment: Vulnerability reported by Nassim Asrir to the PSRT. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 06:02:48 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 18 Feb 2019 11:02:48 +0000 Subject: [issue35704] On AIX, test_unpack_archive_xztar fails with default MAXDATA settings In-Reply-To: <1547111571.31.0.315459583294.issue35704@roundup.psfhosted.org> Message-ID: <1550487768.86.0.980335143968.issue35704@roundup.psfhosted.org> miss-islington added the comment: New changeset ef110b18074300e2302a68a2a476ae35bead7916 by Miss Islington (bot) (Michael Felt) in branch 'master': bpo-35704: Prevent test_shutil fail result when AIX is 32-bit and MAXDATA < 0x20000000 (GH-11500) https://github.com/python/cpython/commit/ef110b18074300e2302a68a2a476ae35bead7916 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 06:04:27 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 18 Feb 2019 11:04:27 +0000 Subject: [issue36020] HAVE_SNPRINTF and MSVC std::snprintf support In-Reply-To: <1550485106.18.0.506219958256.issue36020@roundup.psfhosted.org> Message-ID: <1550487867.17.0.355148983333.issue36020@roundup.psfhosted.org> Change by St?phane Wirtel : ---------- keywords: +patch pull_requests: +11939 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 06:04:46 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 18 Feb 2019 11:04:46 +0000 Subject: [issue36020] HAVE_SNPRINTF and MSVC std::snprintf support In-Reply-To: <1550485106.18.0.506219958256.issue36020@roundup.psfhosted.org> Message-ID: <1550487886.76.0.882480720471.issue36020@roundup.psfhosted.org> St?phane Wirtel added the comment: @palotasb-conti I don't have MSVC because on I work on Linux. Could tell me if this PR fixes your issue? Thank you ---------- nosy: +matrixise stage: patch review -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 06:05:07 2019 From: report at bugs.python.org (Michael Felt) Date: Mon, 18 Feb 2019 11:05:07 +0000 Subject: [issue35633] test_eintr fails on AIX since fcntl functions were modified In-Reply-To: <1546366148.3.0.0239151726659.issue35633@roundup.psfhosted.org> Message-ID: <1550487907.07.0.235969116041.issue35633@roundup.psfhosted.org> Change by Michael Felt : ---------- pull_requests: +11940 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 06:05:55 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 18 Feb 2019 11:05:55 +0000 Subject: [issue35942] posixmodule.c:path_converter() returns an invalid exception message for broken PathLike objects In-Reply-To: <1549643679.09.0.475002054663.issue35942@roundup.psfhosted.org> Message-ID: <1550487955.12.0.333361130953.issue35942@roundup.psfhosted.org> miss-islington added the comment: New changeset a01065a3588d3f0d0c57ea35107aa97e722fe2b2 by Miss Islington (bot) in branch '3.7': bpo-35942: Improve the error message if __fspath__ returns invalid types in path_converter (GH-11831) https://github.com/python/cpython/commit/a01065a3588d3f0d0c57ea35107aa97e722fe2b2 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 06:06:35 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 18 Feb 2019 11:06:35 +0000 Subject: [issue36020] HAVE_SNPRINTF and MSVC std::snprintf support In-Reply-To: <1550485106.18.0.506219958256.issue36020@roundup.psfhosted.org> Message-ID: <1550487995.97.0.724541829971.issue36020@roundup.psfhosted.org> St?phane Wirtel added the comment: @steve.dower, @zach.ware I don't have a Windows machine, I could install an official VM of Windows and install MSVC but I don't have time, I am working for my customer but I could check my PR later (I will wait for the feedback of AppVeyor). Thank you for your feedback, ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 06:07:28 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 18 Feb 2019 11:07:28 +0000 Subject: [issue36020] HAVE_SNPRINTF and MSVC std::snprintf support In-Reply-To: <1550485106.18.0.506219958256.issue36020@roundup.psfhosted.org> Message-ID: <1550488048.65.0.500057421548.issue36020@roundup.psfhosted.org> St?phane Wirtel added the comment: For the version of MSVC, I have found this link: https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 06:09:25 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Feb 2019 11:09:25 +0000 Subject: [issue36019] test_urllib fail in s390x buildbots In-Reply-To: <1550450495.08.0.90804425705.issue36019@roundup.psfhosted.org> Message-ID: <1550488165.39.0.556251553557.issue36019@roundup.psfhosted.org> STINNER Victor added the comment: These random network failure occur with http://www.example.com/: https://github.com/python/cpython/pull/10608#issuecomment-464085852 I don't think that it's a good idea to use a public server for our tests. I would be better to use pythontest.net instead. ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 06:09:37 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Feb 2019 11:09:37 +0000 Subject: [issue36019] test_urllib fail in s390x buildbots: http://www.example.com/ In-Reply-To: <1550450495.08.0.90804425705.issue36019@roundup.psfhosted.org> Message-ID: <1550488177.0.0.812340352055.issue36019@roundup.psfhosted.org> Change by STINNER Victor : ---------- title: test_urllib fail in s390x buildbots -> test_urllib fail in s390x buildbots: http://www.example.com/ _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 06:12:10 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 18 Feb 2019 11:12:10 +0000 Subject: [issue36021] [Security][Windows] webbrowser: WindowsDefault uses os.startfile() and so can be abused to run arbitrary commands In-Reply-To: <1550487653.15.0.496398912417.issue36021@roundup.psfhosted.org> Message-ID: <1550488330.81.0.975760182765.issue36021@roundup.psfhosted.org> St?phane Wirtel added the comment: @victor, the problem is with os.startfile or with WindowsDefault? just to know if we need to fix os.startfile or WindowsDefault. ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 06:13:16 2019 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 18 Feb 2019 11:13:16 +0000 Subject: [issue35704] On AIX, test_unpack_archive_xztar fails with default MAXDATA settings In-Reply-To: <1547111571.31.0.315459583294.issue35704@roundup.psfhosted.org> Message-ID: <1550488396.33.0.390901427703.issue35704@roundup.psfhosted.org> Change by Nick Coghlan : ---------- pull_requests: +11941 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 06:15:56 2019 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 18 Feb 2019 11:15:56 +0000 Subject: [issue36015] streamhandler canont represent streams with an integer as name In-Reply-To: <1550431224.14.0.504793638163.issue36015@roundup.psfhosted.org> Message-ID: <1550488556.24.0.370219573304.issue36015@roundup.psfhosted.org> Vinay Sajip added the comment: I'm not sure this is a problem with logging. The code immediately preceding the failure is: name = getattr(self.stream, 'name', '') if name: name += ' ' So, the failure occurs because the stream has a name attribute which is not a string. Even if sys.stderr itself is an unbuffered file, why is its 'name' attribute not a string? I don't imagine the name would be actually used for I/O, and having it set to an integer is a surprise. I propose to close this (and the associated PR) unless a good reason is given why we have to support non-string names here. ---------- resolution: -> not a bug status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 06:17:46 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 18 Feb 2019 11:17:46 +0000 Subject: [issue36019] test_urllib fail in s390x buildbots: http://www.example.com/ In-Reply-To: <1550450495.08.0.90804425705.issue36019@roundup.psfhosted.org> Message-ID: <1550488666.62.0.00668037621396.issue36019@roundup.psfhosted.org> St?phane Wirtel added the comment: Use a public server or pythontest.net server (it's a public server on the Internet). could we the http requests? I use this practice for the unit test with an external web service, but for the integration tests, I prefer to use the real web service. ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 06:18:41 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 18 Feb 2019 11:18:41 +0000 Subject: [issue36019] test_urllib fail in s390x buildbots: http://www.example.com/ In-Reply-To: <1550450495.08.0.90804425705.issue36019@roundup.psfhosted.org> Message-ID: <1550488721.26.0.0654404115044.issue36019@roundup.psfhosted.org> St?phane Wirtel added the comment: sorry, error with my copy/paste/fixing_words: but my sentence was "could we mock the http requests?" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 06:21:59 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 18 Feb 2019 11:21:59 +0000 Subject: [issue36020] HAVE_SNPRINTF and MSVC std::snprintf support In-Reply-To: <1550485106.18.0.506219958256.issue36020@roundup.psfhosted.org> Message-ID: <1550488919.42.0.958954460165.issue36020@roundup.psfhosted.org> St?phane Wirtel added the comment: Hi, Do you suggest if this VM is correct for the tests? I will try to check with this one. https://developer.microsoft.com/en-us/windows/downloads/virtual-machines ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 06:23:38 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 18 Feb 2019 11:23:38 +0000 Subject: [issue35704] On AIX, test_unpack_archive_xztar fails with default MAXDATA settings In-Reply-To: <1547111571.31.0.315459583294.issue35704@roundup.psfhosted.org> Message-ID: <1550489018.93.0.135547856561.issue35704@roundup.psfhosted.org> miss-islington added the comment: New changeset 02c04f26dfa637db7091b7e16036a980bbf40893 by Miss Islington (bot) (Nick Coghlan) in branch 'master': bpo-35704: Include correct NEWS entry (GH-11914) https://github.com/python/cpython/commit/02c04f26dfa637db7091b7e16036a980bbf40893 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 06:24:29 2019 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 18 Feb 2019 11:24:29 +0000 Subject: [issue35704] On AIX, test_unpack_archive_xztar fails with default MAXDATA settings In-Reply-To: <1547111571.31.0.315459583294.issue35704@roundup.psfhosted.org> Message-ID: <1550489069.68.0.655559155364.issue35704@roundup.psfhosted.org> Change by Nick Coghlan : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 06:26:27 2019 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 18 Feb 2019 11:26:27 +0000 Subject: [issue34720] Fix test_importlib.test_bad_traverse for AIX In-Reply-To: <1537272185.7.0.956365154283.issue34720@psf.upfronthosting.co.za> Message-ID: <1550489187.85.0.627168610026.issue34720@roundup.psfhosted.org> Change by Nick Coghlan : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 06:28:37 2019 From: report at bugs.python.org (Riccardo Magliocchetti) Date: Mon, 18 Feb 2019 11:28:37 +0000 Subject: [issue36015] streamhandler canont represent streams with an integer as name In-Reply-To: <1550431224.14.0.504793638163.issue36015@roundup.psfhosted.org> Message-ID: <1550489317.33.0.704266520327.issue36015@roundup.psfhosted.org> Riccardo Magliocchetti added the comment: Yeah, I'm not sure the pr is just papering over the real issue :) Need to check what io.open sets on name. IF it setting the fd as name instead of creating a string that would be still be a bug in Python to me. Could you please wait a bit for me to check that before closing? ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 06:29:28 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Feb 2019 11:29:28 +0000 Subject: [issue36022] logging.config should not use eval() Message-ID: <1550489368.54.0.864409036165.issue36022@roundup.psfhosted.org> New submission from STINNER Victor : For logging "handlers", _install_handlers() of logging.config uses eval(): def _install_handlers(cp, formatters): """Install and return handlers""" hlist = cp["handlers"]["keys"] ... for hand in hlist: ... klass = section["class"] try: klass = eval(klass, vars(logging)) except (AttributeError, NameError): klass = _resolve(klass) args = section.get("args", '()') args = eval(args, vars(logging)) kwargs = section.get("kwargs", '{}') kwargs = eval(kwargs, vars(logging)) h = klass(*args, **kwargs) ... ... return handlers eval() is considered harmful regarding security: it executes arbitrary Python code. Would it be possible to rewrite this function without eval? I'm not sure of the format of the handler "class". Is it something like "module.submod.attr"? If yes, maybe a regex to validate the class would help? Maybe a loop using getattr() would be safer? Maybe ast.literal_eval() would be enough? At least for args and kwargs? $ python3 Python 3.7.2 (default, Jan 16 2019, 19:49:22) >>> import ast # Legit positional and keyword arguments are accepted >>> ast.literal_eval("(1, 2)") (1, 2) >>> ast.literal_eval("{'x': 1, 'y': 2}") {'x': 1, 'y': 2} # eval() executes arbitrary Python code >>> eval('__import__("os").system("echo hello")') hello 0 # literal_eval() doesn't execute system() >>> ast.literal_eval('__import__("os").system("echo hello")') Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.7/ast.py", line 91, in literal_eval return _convert(node_or_string) File "/usr/lib64/python3.7/ast.py", line 90, in _convert return _convert_signed_num(node) File "/usr/lib64/python3.7/ast.py", line 63, in _convert_signed_num return _convert_num(node) File "/usr/lib64/python3.7/ast.py", line 55, in _convert_num raise ValueError('malformed node or string: ' + repr(node)) ValueError: malformed node or string: <_ast.Call object at 0x7f60a400c780> ---------- messages: 335820 nosy: vinay.sajip, vstinner priority: normal severity: normal status: open title: logging.config should not use eval() type: security versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 06:29:37 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Feb 2019 11:29:37 +0000 Subject: [issue36022] [Security] logging.config should not use eval() In-Reply-To: <1550489368.54.0.864409036165.issue36022@roundup.psfhosted.org> Message-ID: <1550489377.48.0.347412903907.issue36022@roundup.psfhosted.org> Change by STINNER Victor : ---------- title: logging.config should not use eval() -> [Security] logging.config should not use eval() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 06:33:49 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Feb 2019 11:33:49 +0000 Subject: [issue36022] [Security] logging.config should not use eval() In-Reply-To: <1550489368.54.0.864409036165.issue36022@roundup.psfhosted.org> Message-ID: <1550489629.06.0.617228042317.issue36022@roundup.psfhosted.org> STINNER Victor added the comment: The issue has been reported by Alexandre D'Hondt to th PSRT. I only selected Python 3.8 version, since currently, logging.config explicitly *documents* that eval() is used. Example: https://docs.python.org/3/library/logging.config.html#logging.config.listen This issue is not a security vulnerability: you shouldn't let your users modify your logging configuration. Alex Gaynor asked: "Does anyone know whether the logging config is considered to be equally privileged to the code using it or not?" Paul McMillan wrote: "This does not qualify for a CVE. Allowing someone else to configure your logging endpoints would result in significant harm to your app in any language. For instance, in many applications you could turn the log level to debug, and then capture things like database credentials. Additionally, this behavior is extremely clearly documented with a callout warning, and is thus expected behavior." (Quotes from private PSRT list.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 06:38:39 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 18 Feb 2019 11:38:39 +0000 Subject: [issue35942] posixmodule.c:path_converter() returns an invalid exception message for broken PathLike objects In-Reply-To: <1549643679.09.0.475002054663.issue35942@roundup.psfhosted.org> Message-ID: <1550489919.76.0.174749091556.issue35942@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 06:40:56 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 18 Feb 2019 11:40:56 +0000 Subject: [issue36015] streamhandler canont represent streams with an integer as name In-Reply-To: <1550431224.14.0.504793638163.issue36015@roundup.psfhosted.org> Message-ID: <1550490056.21.0.177378250898.issue36015@roundup.psfhosted.org> Ronald Oussoren added the comment: In Python 3.7.2: >>> open(2, 'a') <_io.TextIOWrapper name=2 mode='a' encoding='UTF-8'> >>> m = _ >>> m.name 2 >>> type(_) That is, when opening a file descriptor the name is set to the value of that file descriptor as an integer. BTW. The implementation of PyFile_FromFd is a thin wrapper around the open function. ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 07:00:10 2019 From: report at bugs.python.org (palotasb-conti) Date: Mon, 18 Feb 2019 12:00:10 +0000 Subject: [issue36020] HAVE_SNPRINTF and MSVC std::snprintf support In-Reply-To: <1550485106.18.0.506219958256.issue36020@roundup.psfhosted.org> Message-ID: <1550491210.46.0.685552718295.issue36020@roundup.psfhosted.org> palotasb-conti added the comment: @matrixise: It works on my machine. ;) I would also add a check for `defined(_MSC_VER)` before `_MSC_VER < 1900` because the `MS_WIN32` does not seem to imply that the `_MSC_VER` macro is defined [1]. The correct check could be either #if defined(MS_WIN32) && !defined(HAVE_SNPRINTF) && defined(_MSC_VER) && _MSC_VER < 1900 or #if defined(MS_WIN32) && !defined(HAVE_SNPRINTF) && (!defined(_MSC_VER) || _MSC_VER < 1900) I don't know whether (MS_WIN32 && !defined(_MSC_VER)) means that there is an `(std::)snprintf` function available or if it needs to be redefined to _snprintf -- or even is such a configuration exists and is supported by Python. If I had to guess though, then the first version should be correct since the macro was already defined for MS_WIN32 regardless of _MSC_VER. The VMs seem OK to me for testing. [1] see https://github.com/python/cpython/blob/8a1657b93469580ef345c7c91738587f3d76e87d/PC/pyconfig.h#L68,L84 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 07:03:41 2019 From: report at bugs.python.org (palotasb-conti) Date: Mon, 18 Feb 2019 12:03:41 +0000 Subject: [issue36020] HAVE_SNPRINTF and MSVC std::snprintf support In-Reply-To: <1550485106.18.0.506219958256.issue36020@roundup.psfhosted.org> Message-ID: <1550491421.6.0.562853688184.issue36020@roundup.psfhosted.org> palotasb-conti added the comment: I have the following internal, almost-minimal test case for this bug. It also relies on Boost Python, but that could be eliminated to produce a similar test case. # CMakeLists.txt cmake_minimum_required(VERSION 3.0) project(python-boost-mcve) set(Boost_USE_STATIC_LIBS ON) find_package(Boost COMPONENTS python36 REQUIRED) find_package(Python3 COMPONENTS Development REQUIRED) add_library(python-boost-mcve) target_link_libraries(python-boost-mcve PUBLIC Python3::Python Boost::python36) target_sources(python-boost-mcve PUBLIC "${CMAKE_CURRENT_SOURCE_DIR}/python-boost-mcve.cpp") // python-boost-mcve.cpp // 1. This is a bug with MSVC Python #if !defined(_MSC_VER) || _MSC_VER < 1900 # error "The MCVE requires Visual Studio 14.0 or higher" #endif // 2. An MSVC system header is required to reproduce the error for some reason, // perhaps it sets some macro. This needs to be BEFORE #include // 3. Boost Python is required to include the system (MSVC) Python headers that // define _snprintf as a macro under the circumstances // #define HAVE_SNPRINTF // Define this macro as a workaround to fix the compile error #include // 4. Now we can observe that the following function won't compile #include void test() { char buf[2]; std::snprintf(buf, 1, "x"); // error C2039: '_snprintf': is not a member of 'std' [python-boost-mcve.vcxproj] } ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 07:06:20 2019 From: report at bugs.python.org (palotasb-conti) Date: Mon, 18 Feb 2019 12:06:20 +0000 Subject: [issue36020] HAVE_SNPRINTF and MSVC std::snprintf support In-Reply-To: <1550485106.18.0.506219958256.issue36020@roundup.psfhosted.org> Message-ID: <1550491580.56.0.164482088356.issue36020@roundup.psfhosted.org> palotasb-conti added the comment: For the record, I am basing the version check code on Boost also: https://www.boost.org/doc/libs/1_65_1/boost/convert/detail/config.hpp ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 07:20:42 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Mon, 18 Feb 2019 12:20:42 +0000 Subject: [issue36022] [Security] logging.config should not use eval() In-Reply-To: <1550489368.54.0.864409036165.issue36022@roundup.psfhosted.org> Message-ID: <1550492442.79.0.066463032979.issue36022@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Some discussion in issue15452 about using ast.literal_eval instead of eval which I think is the similar to this report. ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 07:36:15 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Feb 2019 12:36:15 +0000 Subject: [issue36021] [Security][Windows] webbrowser: WindowsDefault uses os.startfile() and so can be abused to run arbitrary commands In-Reply-To: <1550487653.15.0.496398912417.issue36021@roundup.psfhosted.org> Message-ID: <1550493375.55.0.0766168837189.issue36021@roundup.psfhosted.org> STINNER Victor added the comment: > just to know if we need to fix os.startfile or WindowsDefault. webbrowser shouldn't call os.startfile with a path to a program on the local hard drive. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 07:43:28 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Mon, 18 Feb 2019 12:43:28 +0000 Subject: [issue35537] use os.posix_spawn in subprocess In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za> Message-ID: <1550493808.44.0.804064487676.issue35537@roundup.psfhosted.org> Change by Joannah Nanjekye : ---------- pull_requests: +11942 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 07:44:18 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Feb 2019 12:44:18 +0000 Subject: [issue36019] test_urllib fail in s390x buildbots: http://www.example.com/ In-Reply-To: <1550450495.08.0.90804425705.issue36019@roundup.psfhosted.org> Message-ID: <1550493858.87.0.310762210026.issue36019@roundup.psfhosted.org> STINNER Victor added the comment: > could we mock the http requests? No, the tests are functional tests which use deliberate HTTP request to public servers. I suggest to use a server that we control rather multiple "third-party" servers. I'm trying to keep a list of external services used by Python test suite: https://pythondev.readthedocs.io/infra.html#services-used-by-unit-tests ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 08:06:28 2019 From: report at bugs.python.org (twisteroid ambassador) Date: Mon, 18 Feb 2019 13:06:28 +0000 Subject: [issue35945] Cannot distinguish between subtask cancellation and running task cancellation In-Reply-To: <1549660576.62.0.347711337086.issue35945@roundup.psfhosted.org> Message-ID: <1550495188.15.0.35802053828.issue35945@roundup.psfhosted.org> twisteroid ambassador added the comment: There is a way to distinguish whether a task is being cancelled from the "inside" or "outside", like this: async def task1func(): task2 = asyncio.create_task(task2func()) try: await asyncio.wait((task2,)) except asyncio.CancelledError: print('task1 is being cancelled from outside') # Optionally cancel task2 here, since asyncio.wait() shields task2 from # being cancelled from the outside raise assert task2.done() if task2.cancelled(): print('task2 was cancelled') # Note that task1 is not cancelled here, so if you want to cancel # task1 as well, do this: # raise asyncio.CancelledError task2_result = task2.result() # Use your result here ---------- nosy: +twisteroid ambassador _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 08:08:20 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Mon, 18 Feb 2019 13:08:20 +0000 Subject: [issue35954] Incoherent type conversion in configparser In-Reply-To: <1549801714.53.0.77041525212.issue35954@roundup.psfhosted.org> Message-ID: <1550495300.54.0.93046387613.issue35954@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- keywords: +patch pull_requests: +11943 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 08:08:32 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Mon, 18 Feb 2019 13:08:32 +0000 Subject: [issue35954] Incoherent type conversion in configparser In-Reply-To: <1549801714.53.0.77041525212.issue35954@roundup.psfhosted.org> Message-ID: <1550495312.75.0.551456795329.issue35954@roundup.psfhosted.org> R?mi Lapeyre added the comment: > Btw: The name "read_dict" [1] as well as its docstring say exactly the opposite of what it does. It acts as a "save_dict". Maybe that can be fixed on the go ... The name `read_dict` is correct, it reads from the dict given as parameter and changing the name would break existing code. I opened a new PR with the change to convert keys to strings in __getitem__, I did not wrap `key = str(key)` in a try-except as it's not done in read_dict(). This way both __getitem__ and read_dict() will fail the same way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 08:13:28 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Mon, 18 Feb 2019 13:13:28 +0000 Subject: [issue36023] Import configparser.ConfigParser repr Message-ID: <1550495608.73.0.630456699978.issue36023@roundup.psfhosted.org> New submission from R?mi Lapeyre : This is the current repr of the configparser.ConfigParser instances: >>> import configparser >>> config = configparser.ConfigParser() >>> config['sec'] = {} >>> config I think this could be improved to read: ---------- components: Library (Lib) messages: 335831 nosy: remi.lapeyre priority: normal severity: normal status: open title: Import configparser.ConfigParser repr type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 08:26:46 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Feb 2019 13:26:46 +0000 Subject: [issue34294] re module: wrong capturing groups In-Reply-To: <1533042665.14.0.56676864532.issue34294@psf.upfronthosting.co.za> Message-ID: <1550496406.66.0.208484824004.issue34294@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset 4a7f44a2ed49ff1e87db062e7177a56c6e4bbdb0 by Serhiy Storchaka (animalize) in branch 'master': bpo-34294: re module, fix wrong capturing groups in rare cases. (GH-11546) https://github.com/python/cpython/commit/4a7f44a2ed49ff1e87db062e7177a56c6e4bbdb0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 08:27:45 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 18 Feb 2019 13:27:45 +0000 Subject: [issue34294] re module: wrong capturing groups In-Reply-To: <1533042665.14.0.56676864532.issue34294@psf.upfronthosting.co.za> Message-ID: <1550496465.03.0.933293581096.issue34294@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11944 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 08:42:51 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Mon, 18 Feb 2019 13:42:51 +0000 Subject: [issue36023] Import configparser.ConfigParser repr In-Reply-To: <1550495608.73.0.630456699978.issue36023@roundup.psfhosted.org> Message-ID: <1550497371.07.0.766462295293.issue36023@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 08:47:06 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Mon, 18 Feb 2019 13:47:06 +0000 Subject: [issue36023] Improve configparser.ConfigParser repr In-Reply-To: <1550495608.73.0.630456699978.issue36023@roundup.psfhosted.org> Message-ID: <1550497626.05.0.939059452776.issue36023@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- title: Import configparser.ConfigParser repr -> Improve configparser.ConfigParser repr _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 08:48:26 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 18 Feb 2019 13:48:26 +0000 Subject: [issue34294] re module: wrong capturing groups In-Reply-To: <1533042665.14.0.56676864532.issue34294@psf.upfronthosting.co.za> Message-ID: <1550497706.24.0.234164178959.issue34294@roundup.psfhosted.org> miss-islington added the comment: New changeset 0e379d43acc25277f02262212932d3c589a2031b by Miss Islington (bot) in branch '3.7': bpo-34294: re module, fix wrong capturing groups in rare cases. (GH-11546) https://github.com/python/cpython/commit/0e379d43acc25277f02262212932d3c589a2031b ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 08:58:01 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 18 Feb 2019 13:58:01 +0000 Subject: [issue31829] Portability issues with pickle In-Reply-To: <1508521289.37.0.213398074469.issue31829@psf.upfronthosting.co.za> Message-ID: <1550498281.27.0.89613533194.issue31829@roundup.psfhosted.org> Antoine Pitrou added the comment: I am not particularly interested in making Python 2 or ancient pickle protocols easier to use, sorry ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 09:07:30 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Feb 2019 14:07:30 +0000 Subject: [issue31829] Portability issues with pickle In-Reply-To: <1508521289.37.0.213398074469.issue31829@psf.upfronthosting.co.za> Message-ID: <1550498850.41.0.0116253413163.issue31829@roundup.psfhosted.org> Serhiy Storchaka added the comment: This can help with migrating to Python 3. Python 2 programs often open files in text (default) mode for pickling and unpickling. With these changes you will get a warning when run the interpreter with the -3 option. You can also make the producer opening a file in binary mode for compatibility with Python 3, and be sure that the Python 2 consumer will read it correctly even from a file opened in text mode on Windows. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 09:10:13 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Feb 2019 14:10:13 +0000 Subject: [issue34294] re module: wrong capturing groups In-Reply-To: <1533042665.14.0.56676864532.issue34294@psf.upfronthosting.co.za> Message-ID: <1550499013.13.0.987249877518.issue34294@roundup.psfhosted.org> Serhiy Storchaka added the comment: Thank you for your PR Ma Lin! ---------- keywords: +3.7regression resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 09:14:25 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Feb 2019 14:14:25 +0000 Subject: [issue36023] Improve configparser.ConfigParser repr In-Reply-To: <1550495608.73.0.630456699978.issue36023@roundup.psfhosted.org> Message-ID: <1550499265.51.0.301927966369.issue36023@roundup.psfhosted.org> Serhiy Storchaka added the comment: Why only sections? ConfigParser contains a lot of other information. Section names you can get by calling the sections() method. >>> config.sections() ['sec'] ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 09:47:57 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Feb 2019 14:47:57 +0000 Subject: [issue35915] re.search extreme slowness (looks like hang/livelock), searching for patterns containing .* in a large string In-Reply-To: <1549469857.93.0.911634458861.issue35915@roundup.psfhosted.org> Message-ID: <1550501277.45.0.361719051571.issue35915@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 09:49:49 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Feb 2019 14:49:49 +0000 Subject: [issue9134] sre bug: lastmark_save/restore In-Reply-To: <1277932738.21.0.537266945796.issue9134@psf.upfronthosting.co.za> Message-ID: <1550501389.28.0.264147029387.issue9134@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- nosy: +Ma Lin versions: +Python 3.8 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 09:53:36 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Feb 2019 14:53:36 +0000 Subject: [issue35072] re.sub does not play nice with chr(92) In-Reply-To: <1540528576.04.0.788709270274.issue35072@psf.upfronthosting.co.za> Message-ID: <1550501616.85.0.423805060536.issue35072@roundup.psfhosted.org> Serhiy Storchaka added the comment: chr(92) is a single backspace character ('\\'). Since backspace has special meaning in the replacement string, it should be escaped. re.sub(r'\\\\', r'\\', stringy_thingy) ---------- nosy: +serhiy.storchaka stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 09:54:26 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Mon, 18 Feb 2019 14:54:26 +0000 Subject: [issue36023] Improve configparser.ConfigParser repr In-Reply-To: <1550499265.51.0.301927966369.issue36023@roundup.psfhosted.org> Message-ID: R?mi Lapeyre added the comment: > Why only sections? ConfigParser contains a lot of other information. Indeed, the defaults might be useful too. Other things like options can be sessions specific and could clutter the repr if added. Would defaults() and sections() be the right behavior between too little information and too much? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 09:59:42 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Feb 2019 14:59:42 +0000 Subject: [issue34315] Regex not evalauated correctly In-Reply-To: <1533189179.81.0.56676864532.issue34315@psf.upfronthosting.co.za> Message-ID: <1550501982.38.0.652880556863.issue34315@roundup.psfhosted.org> Serhiy Storchaka added the comment: The regular expression engine is not platform depended. Please check that you run the same code. ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 10:01:06 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Feb 2019 15:01:06 +0000 Subject: [issue23689] Memory leak in Modules/sre_lib.h In-Reply-To: <1426611380.23.0.46113718722.issue23689@psf.upfronthosting.co.za> Message-ID: <1550502066.07.0.457731795779.issue23689@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- nosy: +Ma Lin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 10:13:33 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Mon, 18 Feb 2019 15:13:33 +0000 Subject: [issue4356] Add "key" argument to "bisect" module functions In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za> Message-ID: <1550502813.23.0.362995259727.issue4356@roundup.psfhosted.org> R?mi Lapeyre added the comment: Hi everybody, I opened PR 11781 to add a key argument to functions in the bisect module. I agree with @dmtr's points that this addition is not a bad design. As far as I can tell, the key function is at called at most once per item as this example where an assertion would break shows: import bisect from collections import defaultdict class Test: def __init__(self, value): self.value = value cache = defaultdict(int) def key(e): cache[e] += 1 assert cache[e] <= 1 return e.value l = [Test(i) for i in range(10000)] bisect.bisect(l, Test(25), key=key) ? cpython git:(add-key-argument-to-bisect) ./python.exe Python 3.8.0a1+ (heads/add-key-argument-to-bisect:b7aaa1adad, Feb 7 2019, 17:33:24) [Clang 10.0.0 (clang-1000.10.44.4)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import bisect >>> from collections import defaultdict >>> >>> >>> class Test: ... def __init__(self, value): ... self.value = value ... >>> >>> cache = defaultdict(int) >>> >>> def key(e): ... cache[e] += 1 ... assert cache[e] <= 1 ... return e.value ... >>> >>> l = [Test(i) for i in range(10000)] >>> >>> bisect.bisect(l, Test(25), key=key) 26 This argument can be used where the objects are immutable and I have not been able to see changes in bisect speed using Victor Stinner perf module: (cpython-venv) ? cpython git:(add-key-argument-to-bisect) ? make distclean && ./configure --with-pydebug --with-openssl=$(brew --prefix openssl) && make -sj && python -m perf timeit --rigorous -s "from bisect import bisect" "bisect(range(1_000_000_000_000_000), 25)" -o $(git rev-parse --short HEAD).json (cpython-venv) ? cpython git:(add-key-argument-to-bisect) ? git checkout cd90f6a369 (cpython-venv) ? cpython git:(cd90f6a369) ? make distclean && ./configure --with-pydebug --with-openssl=$(brew --prefix openssl) && make -sj && python -m perf timeit --rigorous -s "from bisect import bisect" "bisect(range(1_000_000_000_000_000), 25)" -o $(git rev-parse --short HEAD).json (cpython-venv) ? cpython git:(cd90f6a369) ? python -m perf compare_to cd90f6a369.json b7aaa1adad.json Mean +- std dev: [cd90f6a369] 36.2 us +- 1.0 us -> [b7aaa1adad] 35.7 us +- 0.5 us: 1.01x faster (-1%) (cd90f6a369 was somtime faster than b7aaa1adad, sometime slower but they always were less than one std dev from one another) As I wrote in the discussion of the PR, I suspect the branch predictor to predict reliably the branching in the hot path (though I don't know much about that and would love some input). For the record, here is the performance when a key function is given: (cpython-venv) ? cpython git:(add-key-argument-to-bisect) ? python -m perf timeit --rigorous -s "from bisect import bisect" "bisect(range(1_000_000_000_000_000), 25, key=lambda e: e)" ......................................... Mean +- std dev: 59.3 us +- 1.0 us It seems to me that adding the key parameter is the best solution possible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 10:17:11 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Feb 2019 15:17:11 +0000 Subject: [issue28450] Misleading/inaccurate documentation about unknown escape sequences in regular expressions In-Reply-To: <1476529213.17.0.132534478532.issue28450@psf.upfronthosting.co.za> Message-ID: <1550503031.52.0.00413818286965.issue28450@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- keywords: +patch pull_requests: +11945 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 10:30:56 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 18 Feb 2019 15:30:56 +0000 Subject: [issue34572] C unpickling bypasses import thread safety In-Reply-To: <1535990001.55.0.56676864532.issue34572@psf.upfronthosting.co.za> Message-ID: <1550503856.85.0.0706506657685.issue34572@roundup.psfhosted.org> Antoine Pitrou added the comment: New changeset 4371c0a9c0848f7a0947d43f26f234842b41efdf by Antoine Pitrou (tjb900) in branch 'master': bpo-34572: change _pickle unpickling to use import rather than retrieving from sys.modules (GH-9047) https://github.com/python/cpython/commit/4371c0a9c0848f7a0947d43f26f234842b41efdf ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 10:31:09 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 18 Feb 2019 15:31:09 +0000 Subject: [issue34572] C unpickling bypasses import thread safety In-Reply-To: <1535990001.55.0.56676864532.issue34572@psf.upfronthosting.co.za> Message-ID: <1550503869.13.0.160358132793.issue34572@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11946 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 10:39:28 2019 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 18 Feb 2019 15:39:28 +0000 Subject: [issue36015] streamhandler canont represent streams with an integer as name In-Reply-To: <1550431224.14.0.504793638163.issue36015@roundup.psfhosted.org> Message-ID: <1550504368.68.0.373233259187.issue36015@roundup.psfhosted.org> Vinay Sajip added the comment: > That is, when opening a file descriptor the name is set to the value of that file descriptor as an integer. I see. But I wonder if there is anything that relies on the name being an integer? It seems pretty counter-intuitive for a 'name' attribute to be set to something other than a string. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 10:40:49 2019 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 18 Feb 2019 15:40:49 +0000 Subject: [issue36015] streamhandler cannot represent streams with an integer as name In-Reply-To: <1550431224.14.0.504793638163.issue36015@roundup.psfhosted.org> Message-ID: <1550504449.19.0.245978452994.issue36015@roundup.psfhosted.org> Change by Vinay Sajip : ---------- title: streamhandler canont represent streams with an integer as name -> streamhandler cannot represent streams with an integer as name _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 10:52:35 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 18 Feb 2019 15:52:35 +0000 Subject: [issue34572] C unpickling bypasses import thread safety In-Reply-To: <1535990001.55.0.56676864532.issue34572@psf.upfronthosting.co.za> Message-ID: <1550505155.04.0.920956605362.issue34572@roundup.psfhosted.org> Antoine Pitrou added the comment: New changeset 3129432845948fdcab1e05042e99a19e9e2c3c71 by Antoine Pitrou (Miss Islington (bot)) in branch '3.7': bpo-34572: change _pickle unpickling to use import rather than retrieving from sys.modules (GH-9047) (GH-11921) https://github.com/python/cpython/commit/3129432845948fdcab1e05042e99a19e9e2c3c71 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 10:53:12 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 18 Feb 2019 15:53:12 +0000 Subject: [issue34572] C unpickling bypasses import thread safety In-Reply-To: <1535990001.55.0.56676864532.issue34572@psf.upfronthosting.co.za> Message-ID: <1550505192.52.0.777850858334.issue34572@roundup.psfhosted.org> Antoine Pitrou added the comment: This is pushed to 3.7 and master now. Thank you Tim for the report and the fix! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 10:57:08 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 18 Feb 2019 15:57:08 +0000 Subject: [issue36021] [Security][Windows] webbrowser: WindowsDefault uses os.startfile() and so can be abused to run arbitrary commands In-Reply-To: <1550487653.15.0.496398912417.issue36021@roundup.psfhosted.org> Message-ID: <1550505428.44.0.984821707912.issue36021@roundup.psfhosted.org> Change by St?phane Wirtel : ---------- assignee: -> matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 11:25:21 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Feb 2019 16:25:21 +0000 Subject: [issue36024] ctypes: test_ctypes test_callbacks() crash on AArch64 Message-ID: <1550507121.83.0.763079263217.issue36024@roundup.psfhosted.org> New submission from STINNER Victor : Attached bug.py does crash *randomly* on AArch64. The code is extract from ctypes.test.test_as_parameter.AsParamPropertyWrapperTestCase.test_callbacks test. Example with Python 2.7.15 and Python 3.6.8 on RHEL8: # python2 bug.py Illegal instruction (core dumped) [root at cav-thunderx2s-cn88xx-01 ~]# python3 bug.py ... OK [root at cav-thunderx2s-cn88xx-01 ~]# python3 bug.py Illegal instruction (core dumped) I can reproduce the crash on Python 2.7.16rc compiled manually: ./configure --enable-unicode=ucs4 --with-system-ffi && make RHEL8 currently uses libffi-3.1-18.el8.aarch64. (I tried optimization levels -O0, -O1, -O2, -O3: I am always able to *randomly* trigger the crash.) Original bug report, Python 2 crash on RHEL8: https://bugzilla.redhat.com/show_bug.cgi?id=1652930 -- I don't know if it's related but I also saw the following error which has been reported in bpo-30991. FAIL: test_pass_by_value (ctypes.test.test_structures.StructureTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/root/src/python-3.6.2/Lib/ctypes/test/test_structures.py", line 416, in test_pass_by_value self.assertEqual(s.first, 0xdeadbeef) AssertionError: 195948557 != 3735928559 ---------- components: Library (Lib) files: bug.py messages: 335847 nosy: vstinner priority: normal severity: normal status: open title: ctypes: test_ctypes test_callbacks() crash on AArch64 versions: Python 2.7, Python 3.6 Added file: https://bugs.python.org/file48149/bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 11:22:44 2019 From: report at bugs.python.org (jt) Date: Mon, 18 Feb 2019 16:22:44 +0000 Subject: [issue36010] Please provide a .zip Windows release of Python that is not crippled/for embedding only In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org> Message-ID: <1550506964.33.0.970077445645.issue36010@roundup.psfhosted.org> jt added the comment: Just to add this, I now tested the proper pip upgrade approach, and it worked fine, like everything else I tried before (installing & using Cython, any other packages, ...). If there's anything else I should test, let me know! NuGet with venv/ensurepip would be awesome and make my life easier, so to me this would be a really cool addition ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 11:33:52 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Feb 2019 16:33:52 +0000 Subject: [issue36024] ctypes: test_ctypes test_callbacks() crash on AArch64 In-Reply-To: <1550507121.83.0.763079263217.issue36024@roundup.psfhosted.org> Message-ID: <1550507632.09.0.923194378044.issue36024@roundup.psfhosted.org> STINNER Victor added the comment: > I can reproduce the crash on Python 2.7.16rc compiled manually: > ./configure --enable-unicode=ucs4 --with-system-ffi && make I can also reproduce the crash on Python 3.7.2 compiled manually with: ./configure --with-pydebug && make (_ctypes uses system libffi) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 11:41:05 2019 From: report at bugs.python.org (Jeremy Kloth) Date: Mon, 18 Feb 2019 16:41:05 +0000 Subject: [issue36010] Please provide a .zip Windows release of Python that is not crippled/for embedding only In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org> Message-ID: <1550508065.68.0.680531675668.issue36010@roundup.psfhosted.org> Jeremy Kloth added the comment: Thank you for your testing of the venv and pip workflows. At this point, I believe that all that remains would be for Steve Dower to incorporate the `IncludeVEnv=true` parameter into the nupkg build process. I personally do not see a problem with including them (given your successful test results), but it is Steve's call as Windows' RM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 11:50:46 2019 From: report at bugs.python.org (Christian Korneck) Date: Mon, 18 Feb 2019 16:50:46 +0000 Subject: [issue36011] ssl - tls verify on Windows fails In-Reply-To: <1550342172.09.0.390948819907.issue36011@roundup.psfhosted.org> Message-ID: <1550508646.46.0.163565845406.issue36011@roundup.psfhosted.org> Christian Korneck added the comment: quick addition: It looks like all recent Windows versions (Win8/Server 2012, Win8.1/Server 2012R2, Win10 (older versions)/Server 2016, Win10-1809/Server 2019 behave the same (= only very few RootCAs are pre-installed out of the box, additional ones are added on the fly when HTTPS requests are being made via the SCHANNEL api). Possible workaround for Windows admins: Import the RootCA certs from "certifi" into the Windows local machine Trusted RootCA store. To do so, first download and convert the certifi cabundle (https://certifi.io) to a pfx container, i.e. with something like: wget -O certs.pem https://mkcert.org/generate/ openssl pkcs12 -export -nokeys -out certs.pfx -in certs.pem Then import the pfx via the certlm.msc GUI or the certutil.exe cmdline tool. This imports all certs at once. This can also be centralized for a larger number of machines via an Active Directory Group Policy (Local Machine -> Windows Settings -> Security Settings -> PKI). This isn't ideal as it puts the admin into the responsibility to update the certstore/GPO whenever there's a change in the certifi cabundle, but works well for me besides that. ---------- title: ssl - tls verify on Windows 10 fails -> ssl - tls verify on Windows fails _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 11:56:52 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Feb 2019 16:56:52 +0000 Subject: [issue36024] ctypes: test_ctypes test_callbacks() crash on AArch64 In-Reply-To: <1550507121.83.0.763079263217.issue36024@roundup.psfhosted.org> Message-ID: <1550509012.25.0.668555833682.issue36024@roundup.psfhosted.org> STINNER Victor added the comment: bug2.py: example simplified a little bit more. Changes: * unittest is no longer used * move local variables to globals, to make sure that memory is not released in any way during function calls ---------- Added file: https://bugs.python.org/file48150/bug2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 12:03:19 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Feb 2019 17:03:19 +0000 Subject: [issue35954] Incoherent type conversion in configparser In-Reply-To: <1549801714.53.0.77041525212.issue35954@roundup.psfhosted.org> Message-ID: <1550509399.14.0.966303956907.issue35954@roundup.psfhosted.org> Serhiy Storchaka added the comment: Other methods do not convert key to string too. What is a use case for having a non-string section name? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 12:09:48 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Feb 2019 17:09:48 +0000 Subject: [issue36024] ctypes: test_ctypes test_callbacks() crash on AArch64 In-Reply-To: <1550507121.83.0.763079263217.issue36024@roundup.psfhosted.org> Message-ID: <1550509788.48.0.196384542067.issue36024@roundup.psfhosted.org> STINNER Victor added the comment: Sadly, even with debug symbols on RHEL8 and gcc -g -O0 -fno-omit-frame-pointer, gdb is unable to retrieve the backtrace when the crash occurs :-( Program received signal SIGILL, Illegal instruction. 0x0000ffffbe7a0058 in ?? () (gdb) where #0 0x0000ffffbe7a0058 in ?? () #1 0x0000ffffffffe8a0 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 12:22:05 2019 From: report at bugs.python.org (Paul Ganssle) Date: Mon, 18 Feb 2019 17:22:05 +0000 Subject: [issue36025] Breaking change in PyDate_FromTimeStamp API Message-ID: <1550510525.68.0.55104762284.issue36025@roundup.psfhosted.org> New submission from Paul Ganssle : The PyO3 test suite has been breaking since the alpha release of Python 3.8 because PyDateTimeAPI->Date_FromTimeStamp has had a breaking change in its API: https://github.com/PyO3/pyo3/issues/352 I believe this happened when `datetime.date.fromtimestamp` and `datetime.datetime.fromtimestamp` were converted over to using the argument clinic. The function `date_from_local_object` was renamed to `date_fromtimestamp`, without a corresponding change to the PyDateTimeCAPI struct. ---------- assignee: p-ganssle components: Library (Lib) messages: 335854 nosy: belopolsky, p-ganssle, petr.viktorin, serhiy.storchaka priority: normal severity: normal status: open title: Breaking change in PyDate_FromTimeStamp API versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 12:25:19 2019 From: report at bugs.python.org (Florian Weimer) Date: Mon, 18 Feb 2019 17:25:19 +0000 Subject: [issue36024] ctypes: test_ctypes test_callbacks() crash on AArch64 In-Reply-To: <1550507121.83.0.763079263217.issue36024@roundup.psfhosted.org> Message-ID: <1550510719.1.0.411174077007.issue36024@roundup.psfhosted.org> Change by Florian Weimer : ---------- nosy: +fweimer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 12:25:19 2019 From: report at bugs.python.org (Paul Ganssle) Date: Mon, 18 Feb 2019 17:25:19 +0000 Subject: [issue36025] Breaking change in PyDate_FromTimeStamp API In-Reply-To: <1550510525.68.0.55104762284.issue36025@roundup.psfhosted.org> Message-ID: <1550510719.15.0.349712252997.issue36025@roundup.psfhosted.org> Change by Paul Ganssle : ---------- keywords: +patch pull_requests: +11947 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 12:46:45 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Feb 2019 17:46:45 +0000 Subject: [issue36024] ctypes: test_ctypes test_callbacks() crash on AArch64 In-Reply-To: <1550507121.83.0.763079263217.issue36024@roundup.psfhosted.org> Message-ID: <1550512005.43.0.187693779212.issue36024@roundup.psfhosted.org> STINNER Victor added the comment: # gdb -args ./python ../bug2.py GNU gdb (GDB) Red Hat Enterprise Linux 8.2-5.el8 (gdb) run ... Program received signal SIGILL, Illegal instruction. 0x0000ffffbded0058 in ?? () (gdb) disassemble $pc,$pc+10 Dump of assembler code from 0xffffbded0058 to 0xffffbded0062: => 0x0000ffffbded0058: ldr x16, 0xffffbded0064 0x0000ffffbded005c: adr x17, 0xffffbded006c 0x0000ffffbded0060: br x16 End of assembler dump. (gdb) print *(void**)0xffffbded0064 $1 = (void *) 0xffffbdea4f64 According to /proc/95475/maps, 0xffffbded0064 lives in this memory mapping: ffffbded0000-ffffbdee0000 r-xs 00000000 fd:00 34943874 /tmp/ffiQhRWVt (deleted) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 12:53:33 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Mon, 18 Feb 2019 17:53:33 +0000 Subject: [issue35867] NameError is not caught at Task execution In-Reply-To: <1548940597.02.0.134680701167.issue35867@roundup.psfhosted.org> Message-ID: <1550512413.76.0.152753529907.issue35867@roundup.psfhosted.org> Emmanuel Arias added the comment: I test it and this have the same behavior on 3.7 and 3.8... I will work on this ---------- nosy: +eamanu versions: +Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 13:06:04 2019 From: report at bugs.python.org (SylvainDe) Date: Mon, 18 Feb 2019 18:06:04 +0000 Subject: [issue36026] Different error message when sys.settrace is used (regressions) Message-ID: <1550513164.21.0.815390267137.issue36026@roundup.psfhosted.org> New submission from SylvainDe : Context: -------- Follow-up from https://bugs.python.org/issue35965 which was closed when we assumed the issue was on the coverage side. After nedbat investigation, it seems like the issue comes from call to "sys.settrace". Issue: ------ A test relying on "self.assertRaisesRegex" with raising code "set.add(0)" started to lead to a different error message recently on the CI jobs. Indeed, instead of "descriptor '\w+' requires a 'set' object but received a 'int'" the raised exception was: "descriptor 'add' for 'set' objects doesn't apply to 'int' object" More surprisingly, the behavior was different: - depending on whether "self.assertRaisesRegex" was used as a context manager - on the Python version - when coverage was used. Nedbat was able to pinpoint the root cause for this: the usage of "sys.settrace". This can be hilighted using simple unit-tests: ====================================================================================================== import unittest import sys def trace(frame, event, arg): return trace DESCRIPT_REQUIRES_TYPE_RE = r"descriptor '\w+' requires a 'set' object but received a 'int'" DO_SET_TRACE = True class SetAddIntRegexpTests(unittest.TestCase): def test_assertRaisesRegex(self): if DO_SET_TRACE: sys.settrace(trace) self.assertRaisesRegex(TypeError, DESCRIPT_REQUIRES_TYPE_RE, set.add, 0) def test_assertRaisesRegex_contextman(self): if DO_SET_TRACE: sys.settrace(trace) with self.assertRaisesRegex(TypeError, DESCRIPT_REQUIRES_TYPE_RE): set.add(0) if __name__ == '__main__': unittest.main() ====================================================================================================== Here are the results from the original bug: On some versions, both tests pass: Python 3.6 and before Python 3.7.0a4+ (heads/master:4666ec5, Jan 26 2018, 04:14:24) - [GCC 4.8.4] - ('CPython', 'heads/master', '4666ec5')) On some versions, only test_assertRaisesRegex_contextman fails which was the confusing part: Python 3.7.1 (default, Dec 5 2018, 18:09:53) [GCC 5.4.0 20160609] - ('CPython', '', '') Python 3.7.2+ (heads/3.7:3fcfef3, Feb 9 2019, 07:30:09) [GCC 5.4.0 20160609] - ('CPython', 'heads/3.7', '3fcfef3') On some versions, both tests fail: Python 3.8.0a1+ (heads/master:8a03ff2, Feb 9 2019, 07:30:26) [GCC 5.4.0 20160609] - ('CPython', 'heads/master', '8a03ff2') First analysis: --------------- Using some git bisect magic, I was able to pinpoint the commits leading to each behavior change. - test_assertRaisesRegex_contextman starts to fail from: https://bugs.python.org/issue34126 https://github.com/python/cpython/commit/56868f940e0cc0b35d33c0070107ff3bed2d8766 - test_assertRaisesRegex starts to fail as well from: https://bugs.python.org/issue34125 https://github.com/python/cpython/commit/e89de7398718f6e68848b6340830aeb90b7d582c >From my point of view, it looks like we have 2 regressions. Please let me know if this needs to be split into 2 independant issues. ---------- files: issue36_git_bisect_script_and_results.txt messages: 335857 nosy: SylvainDe priority: normal severity: normal status: open title: Different error message when sys.settrace is used (regressions) Added file: https://bugs.python.org/file48151/issue36_git_bisect_script_and_results.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 13:09:47 2019 From: report at bugs.python.org (nr) Date: Mon, 18 Feb 2019 18:09:47 +0000 Subject: [issue35941] ssl.enum_certificates() regression In-Reply-To: <1549637009.73.0.764067041861.issue35941@roundup.psfhosted.org> Message-ID: <1550513387.76.0.366236554831.issue35941@roundup.psfhosted.org> Change by nr : ---------- keywords: +patch pull_requests: +11948 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 13:10:02 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Mon, 18 Feb 2019 18:10:02 +0000 Subject: [issue36026] Different error message when sys.settrace is used (regressions) In-Reply-To: <1550513164.21.0.815390267137.issue36026@roundup.psfhosted.org> Message-ID: <1550513402.97.0.181835251179.issue36026@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 13:11:30 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Mon, 18 Feb 2019 18:11:30 +0000 Subject: [issue36026] Different error message when sys.settrace is used (regressions) In-Reply-To: <1550513164.21.0.815390267137.issue36026@roundup.psfhosted.org> Message-ID: <1550513490.12.0.0569957526358.issue36026@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +serhiy.storchaka, vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 13:14:10 2019 From: report at bugs.python.org (paul j3) Date: Mon, 18 Feb 2019 18:14:10 +0000 Subject: [issue36014] test_help_with_metavar broken In-Reply-To: <1550378852.92.0.619862991077.issue36014@roundup.psfhosted.org> Message-ID: <1550513650.83.0.541354385868.issue36014@roundup.psfhosted.org> Change by paul j3 : ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 13:14:38 2019 From: report at bugs.python.org (Paul Ganssle) Date: Mon, 18 Feb 2019 18:14:38 +0000 Subject: [issue36025] Breaking change in PyDate_FromTimeStamp API In-Reply-To: <1550510525.68.0.55104762284.issue36025@roundup.psfhosted.org> Message-ID: <1550513678.72.0.151837484281.issue36025@roundup.psfhosted.org> Paul Ganssle added the comment: I've put *a* fix in there by introducing a new wrapper function. Ideally we would just point the C API at the argument clinic-generated function, but because it takes a single positional argument the argument clinic outputs a METH_O function instead of METH_VARARGS. I think these are the options: 1. Modify the argument clinic spec to force METH_VARARGS for a single positional argument taking an object - if that's possible. 2. Maintain a wrapper function for the C API that just unpacks the tuple and passes it to the date_fromtimestamp function that the argument clinic is *also* wrapping. 3. Revert the argument clinic change and manually manage the date_fromtimestamp function as a METH_VARARGS classmethod. I don't know enough about the argument clinic to know if #1 is feasible, if it is and someone can point me in the right direction, I can update my PR. If not, I think I mildly prefer #2, since maintaining a thin wrapper that unpacks a tuple is not terribly difficult compared to maintaining the method definition stuff. Since this was an accidental break in the C API, I've marked it as a release blocker. ---------- nosy: +lukasz.langa priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 13:17:50 2019 From: report at bugs.python.org (Paul Ganssle) Date: Mon, 18 Feb 2019 18:17:50 +0000 Subject: [issue35186] distutils.command.upload uses deprecated platform.dist with bdist_rpm In-Reply-To: <1541642171.78.0.788709270274.issue35186@psf.upfronthosting.co.za> Message-ID: <1550513870.46.0.662716902407.issue35186@roundup.psfhosted.org> Change by Paul Ganssle : ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 13:18:18 2019 From: report at bugs.python.org (Paul Ganssle) Date: Mon, 18 Feb 2019 18:18:18 +0000 Subject: [issue35186] distutils.command.upload uses deprecated platform.dist with bdist_rpm In-Reply-To: <1541642171.78.0.788709270274.issue35186@psf.upfronthosting.co.za> Message-ID: <1550513898.68.0.527959670435.issue35186@roundup.psfhosted.org> Change by Paul Ganssle : ---------- versions: -Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 13:19:14 2019 From: report at bugs.python.org (Paul Ganssle) Date: Mon, 18 Feb 2019 18:19:14 +0000 Subject: [issue35186] distutils.command.upload uses deprecated platform.dist with bdist_rpm In-Reply-To: <1541642171.78.0.788709270274.issue35186@psf.upfronthosting.co.za> Message-ID: <1550513954.36.0.407177175007.issue35186@roundup.psfhosted.org> Change by Paul Ganssle : ---------- stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 14:31:38 2019 From: report at bugs.python.org (Eric Snow) Date: Mon, 18 Feb 2019 19:31:38 +0000 Subject: [issue35949] Move PyThreadState into Include/internal/pycore_pystate.h In-Reply-To: <1549677619.84.0.322696563838.issue35949@roundup.psfhosted.org> Message-ID: <1550518298.84.0.28382414974.issue35949@roundup.psfhosted.org> Eric Snow added the comment: @Stefan, is it a problem for Cython if the relevant fields are exposed via C-API functions rather than directly on PyThreadState? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 14:58:42 2019 From: report at bugs.python.org (Florian Weimer) Date: Mon, 18 Feb 2019 19:58:42 +0000 Subject: [issue36024] ctypes: test_ctypes test_callbacks() crash on AArch64 In-Reply-To: <1550507121.83.0.763079263217.issue36024@roundup.psfhosted.org> Message-ID: <1550519922.63.0.15366267139.issue36024@roundup.psfhosted.org> Florian Weimer added the comment: We believe this is a libffi bug. On certain aarch64 implementations, it is necessary to flush both the writable mapping and the executable mapping. I have a patch which I confirmed to work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 15:02:52 2019 From: report at bugs.python.org (Florian Weimer) Date: Mon, 18 Feb 2019 20:02:52 +0000 Subject: [issue36024] ctypes: test_ctypes test_callbacks() crash on AArch64 In-Reply-To: <1550507121.83.0.763079263217.issue36024@roundup.psfhosted.org> Message-ID: <1550520172.75.0.242082191824.issue36024@roundup.psfhosted.org> Florian Weimer added the comment: Filed as an libffi issue: https://github.com/libffi/libffi/issues/470 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 15:10:59 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 18 Feb 2019 20:10:59 +0000 Subject: [issue36027] Consider adding modular multiplicative inverse to the math module Message-ID: <1550520659.43.0.126744170658.issue36027@roundup.psfhosted.org> New submission from Raymond Hettinger : Having gcd() in the math module has been nice. Here is another number theory basic that I've needed every now and then: def multinv(modulus, value): '''Multiplicative inverse in a given modulus >>> multinv(191, 138) 18 >>> 18 * 138 % 191 1 >>> multinv(191, 38) 186 >>> 186 * 38 % 191 1 >>> multinv(120, 23) 47 >>> 47 * 23 % 120 1 ''' # https://en.wikipedia.org/wiki/Modular_multiplicative_inverse # http://en.wikipedia.org/wiki/Extended_Euclidean_algorithm x, lastx = 0, 1 a, b = modulus, value while b: a, q, b = b, a // b, a % b x, lastx = lastx - q * x, x result = (1 - lastx * modulus) // value if result < 0: result += modulus assert 0 <= result < modulus and value * result % modulus == 1 return result ---------- components: Library (Lib) messages: 335862 nosy: mark.dickinson, pablogsal, rhettinger, skrah, tim.peters priority: low severity: normal status: open title: Consider adding modular multiplicative inverse to the math module type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 15:15:14 2019 From: report at bugs.python.org (Au Vo) Date: Mon, 18 Feb 2019 20:15:14 +0000 Subject: [issue36028] Integer Division discrepancy with decimal Message-ID: <1550520914.92.0.84005909816.issue36028@roundup.psfhosted.org> New submission from Au Vo : In Python3, there is a discrepancy of integer division with decimal. Considering these two examples: 4/ .4 ==10.0. But 4//.4== 9.0 Furthermore: 2//.2 == 9.0 3//.3 ==10.0 5//.5 ==10.0 6//.6 ==10.0 All answers should be 10.0? The problem is in Python3 and not in Python2. Python2 produces 10.0 as the answers for all of the above calculation. Is it a rounding out issue? ---------- messages: 335863 nosy: Au Vo priority: normal severity: normal status: open title: Integer Division discrepancy with decimal type: behavior versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 15:17:00 2019 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 18 Feb 2019 20:17:00 +0000 Subject: [issue35949] Move PyThreadState into Include/internal/pycore_pystate.h In-Reply-To: <1549677619.84.0.322696563838.issue35949@roundup.psfhosted.org> Message-ID: <1550521020.37.0.920240699316.issue35949@roundup.psfhosted.org> Stefan Behnel added the comment: Well ? yes. The exception fields are performance critical, and we try hard to make them visible to the C compiler so that swapping around exception state eats up as little CPU time as possible. You could argue that profiling and tracing are less critical, but any nanosecond that is avoided while not tracing a function adds up to making the rest of the program faster, so I'd argue that that's performance critical, too. Profiling definitely is, because it should have as little impact on the code profile as possible. There is a huge difference between having the CPU pre-fetch a pointer and looking at the value, compared to calling into a C function and guessing what the result might be. The trashcan is only used during deallocation, so ? well, I guess it could be replaced by a different API, but that's a bit tricky due to the bracket nature of the current macros. I also just noticed that "Py_EnterRecursiveCall" and "Py_LeaveRecursiveCall" are on your list. We use them in our inlined call helper functions, which mostly duplicate CPython functionality. Looking at these macros now, I find it a bit annoying that they call "PyThreadState_GET()" directly, rather than accepting one as input. Looking up the current thread-state is a non-local, atomic operation that can be surprisingly costly, and I've invested quite some work into reducing these lookups in Cython. Although it's probably not too bad around a call into an external function? So, yeah, we do care about the thread state being readily available. :) Could you explain what benefit you are expecting from hiding the thread state? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 15:33:23 2019 From: report at bugs.python.org (Eric Snow) Date: Mon, 18 Feb 2019 20:33:23 +0000 Subject: [issue35949] Move PyThreadState into Include/internal/pycore_pystate.h In-Reply-To: <1550521020.37.0.920240699316.issue35949@roundup.psfhosted.org> Message-ID: Eric Snow added the comment: Thanks for clarifying. :) On Mon, Feb 18, 2019 at 1:17 PM Stefan Behnel wrote: > The exception fields are performance critical, and we try hard to make them visible to the C compiler so that swapping around exception state eats up as little CPU time as possible. > > You could argue that profiling and tracing are less critical, but any nanosecond that is avoided while not tracing a function adds up to making the rest of the program faster, so I'd argue that that's performance critical, too. Profiling definitely is, because it should have as little impact on the code profile as possible. There is a huge difference between having the CPU pre-fetch a pointer and looking at the value, compared to calling into a C function and guessing what the result might be. Yeah, I had a feeling that was the case. :) There might be decent approaches to avoiding a performance hit on this, but I'm not sure it's worth the extra complexity. And I'm not terribly motivated to make the effort personally. :) > The trashcan is only used during deallocation, so ? well, I guess it could be replaced by a different API, but that's a bit tricky due to the bracket nature of the current macros. Yep, definitely tricky. > I also just noticed that "Py_EnterRecursiveCall" and "Py_LeaveRecursiveCall" are on your list. We use them in our inlined call helper functions, which mostly duplicate CPython functionality. Looking at these macros now, I find it a bit annoying that they call "PyThreadState_GET()" directly, rather than accepting one as input. Looking up the current thread-state is a non-local, atomic operation that can be surprisingly costly, and I've invested quite some work into reducing these lookups in Cython. Although it's probably not too bad around a call into an external function? Hmm, perhaps that's something we could address separately? > Could you explain what benefit you are expecting from hiding the thread state? This isn't so much about the thread state specifically or about necessarily hiding *all* the thread state. Rather it's about a general effort to reduce the amount of private API we are exposing publicly. In this case I was looking at PyInterpreterState (#35886) and opening a similar issue at the same time for PyThreadState made sense. Given your response it's clear that usage of PyThreadState doesn't match the documentation very well. That would be worth addressing one way or another, so I'm glad we're having this conversation. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 15:35:46 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 18 Feb 2019 20:35:46 +0000 Subject: [issue36028] Integer Division discrepancy with decimal In-Reply-To: <1550520914.92.0.84005909816.issue36028@roundup.psfhosted.org> Message-ID: <1550522146.13.0.225842407925.issue36028@roundup.psfhosted.org> Raymond Hettinger added the comment: I get the same results in both Python 2 and Python 3. Python 2.7.15 (v2.7.15:ca079a3ea3, Apr 29 2018, 20:59:26) [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin Type "copyright", "credits" or "license()" for more information. >>> 4 / 0.4 10.0 >>> 4 // 0.4 9.0 >>> 4 % 0.4 0.3999999999999998 >>> divmod(4, 0.4) (9.0, 0.3999999999999998) Python 3.7.2 (v3.7.2:9a3ffc0492, Dec 24 2018, 02:44:43) [Clang 6.0 (clang-600.0.57)] on darwin Type "help", "copyright", "credits" or "license()" for more information. >>> 4 / 0.4 10.0 >>> 4 // 0.4 9.0 >>> 4 % 0.4 0.3999999999999998 >>> divmod(4, 0.4) (9.0, 0.3999999999999998) ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 15:45:41 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Mon, 18 Feb 2019 20:45:41 +0000 Subject: [issue36028] Integer Division discrepancy with decimal In-Reply-To: <1550520914.92.0.84005909816.issue36028@roundup.psfhosted.org> Message-ID: <1550522741.73.0.903921524578.issue36028@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 16:01:16 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 18 Feb 2019 21:01:16 +0000 Subject: [issue36028] Integer Division discrepancy with decimal In-Reply-To: <1550520914.92.0.84005909816.issue36028@roundup.psfhosted.org> Message-ID: <1550523676.99.0.815466235305.issue36028@roundup.psfhosted.org> Raymond Hettinger added the comment: I'm thinking this due to having two different algorithms in play, one of which has multiple intermediate roundings. * For starters, 0.4 is not exactly representable. It is stored as the binary fraction 3602879701896397 / 9007199254740992 represented in hex as 0x1.999999999999ap-2 * The / true division operator is implemented in Objects/floatobject.c:float_div() with a single, straight division of C doubles: "a = a / b;" That is giving 10.0 when rounded. * The // floor division operator is implemented in Objects/floatobject.c:float_floor_div() which in turn calls float_divmod(). The latter has a number of steps that can each have a round-off and can make adjustments to preserve sign logic invariants: mod = fmod(vx, wx); /* fmod is typically exact, so vx-mod is *mathematically* an exact multiple of wx. But this is fp arithmetic, and fp vx - mod is an approximation; the result is that div may not be an exact integral value after the division, although it will always be very close to one. */ div = (vx - mod) / wx; if (mod) { /* ensure the remainder has the same sign as the denominator */ if ((wx < 0) != (mod < 0)) { mod += wx; div -= 1.0; } } else { /* the remainder is zero, and in the presence of signed zeroes fmod returns different results across platforms; ensure it has the same sign as the denominator. */ mod = copysign(0.0, wx); } /* snap quotient to nearest integral value */ if (div) { floordiv = floor(div); if (div - floordiv > 0.5) floordiv += 1.0; } else { /* div is zero - get the same sign as the true quotient */ floordiv = copysign(0.0, vx / wx); /* zero w/ sign of vx/wx */ } I don't see how to fix the discrepancy without having float_div() depend on the much slower logic in float_divmod(). ---------- nosy: +mark.dickinson, skrah, tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 16:49:49 2019 From: report at bugs.python.org (Riccardo Magliocchetti) Date: Mon, 18 Feb 2019 21:49:49 +0000 Subject: [issue36015] streamhandler cannot represent streams with an integer as name In-Reply-To: <1550431224.14.0.504793638163.issue36015@roundup.psfhosted.org> Message-ID: <1550526589.19.0.527632765083.issue36015@roundup.psfhosted.org> Riccardo Magliocchetti added the comment: Looking at Modules/_io/fileio.c::_io_FileIO___init___impl it seems an int for nameobj is just fine. Not sure I am looking at the right code though :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 16:58:27 2019 From: report at bugs.python.org (abcdef) Date: Mon, 18 Feb 2019 21:58:27 +0000 Subject: [issue34203] documentation: recommend Python 3 over 2 in faq In-Reply-To: <1532397328.96.0.56676864532.issue34203@psf.upfronthosting.co.za> Message-ID: <1550527107.48.0.24190468274.issue34203@roundup.psfhosted.org> abcdef added the comment: Thank you. I understand this is fixed now and I'm marking the ticket as closed. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 17:33:30 2019 From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=) Date: Mon, 18 Feb 2019 22:33:30 +0000 Subject: [issue36029] Use consistent case for HTTP header fields Message-ID: <1550529210.49.0.526576386821.issue36029@roundup.psfhosted.org> New submission from G?ry : Use consistent case for HTTP header fields, according to [RFC 7231](https://tools.ietf.org/html/rfc7231). ---------- components: Library (Lib) messages: 335870 nosy: brett.cannon, eric.araujo, ezio.melotti, maggyero, mdk, ncoghlan, willingc priority: normal severity: normal status: open title: Use consistent case for HTTP header fields type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 17:34:44 2019 From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=) Date: Mon, 18 Feb 2019 22:34:44 +0000 Subject: [issue36029] Use consistent case for HTTP header fields In-Reply-To: <1550529210.49.0.526576386821.issue36029@roundup.psfhosted.org> Message-ID: <1550529284.99.0.258164603574.issue36029@roundup.psfhosted.org> Change by G?ry : ---------- keywords: +patch pull_requests: +11949 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 17:35:26 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 18 Feb 2019 22:35:26 +0000 Subject: [issue36010] Please provide a .zip Windows release of Python that is not crippled/for embedding only In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org> Message-ID: <1550529326.84.0.671097508695.issue36010@roundup.psfhosted.org> Steve Dower added the comment: Yeah, I'm okay with it for 3.7.3 and future releases. The only change should need to be for the nuget preset in PC/layout/support/options.py ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 17:46:41 2019 From: report at bugs.python.org (Tim Peters) Date: Mon, 18 Feb 2019 22:46:41 +0000 Subject: [issue36028] Integer Division discrepancy with decimal In-Reply-To: <1550520914.92.0.84005909816.issue36028@roundup.psfhosted.org> Message-ID: <1550530001.56.0.77942594815.issue36028@roundup.psfhosted.org> Tim Peters added the comment: "Multiple roundings" in the float code is a red herring - that's just implementation details trying to cheaply get the same effect as computing with infinite precision. Here with actual unbounded precision: >>> from fractions import Fraction >>> y = Fraction(0.4) >>> y Fraction(3602879701896397, 9007199254740992) >>> q = 4 / y >>> q Fraction(36028797018963968, 3602879701896397) >>> int(q) 9 >>> 4 - 9 * y Fraction(3602879701896395, 9007199254740992) >>> float(_) 0.3999999999999998 >>> So exactly the same results as divmod(4, 0.4) returned. The underlying problem here is that the infinitely precise result of 4.0 / 0.4 is NOT an integer, in turn stemming from that the float 0.4 is not four tenths. So I recommend to close this as not-a-bug, but I'm not doing that now because I want clarification on what the OP meant by saying the results differ between Pythons 2 and 3. I see no differences here between Pythons 2.7.11 and 3.7.2 on 64-bit Windows (not in 4.0 vs 0.4, or in any of the other cases the OP mentioned). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 18:13:26 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Mon, 18 Feb 2019 23:13:26 +0000 Subject: [issue36026] Different error message when sys.settrace is used (regressions) In-Reply-To: <1550513164.21.0.815390267137.issue36026@roundup.psfhosted.org> Message-ID: <1550531606.57.0.753918658038.issue36026@roundup.psfhosted.org> Steven D'Aprano added the comment: Do I correctly understand the reported problem here? set.add(0) correctly raises TypeError in each case, but: (1) the exception message changes between versions; (2) and also changes depending on whether or not sys.trace is active. I don't think the exception message (as opposed to the exception type) is part of the public API. This means it can change without warning, at any time, so long as it is sensible and human readable. Unless there is something documenting the precise wording used in this case, guaranteeing that it will be kept stable, I don't think this should be considered a regression or a bug. Do you disagree? ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 18:29:07 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Mon, 18 Feb 2019 23:29:07 +0000 Subject: [issue36028] Integer Division discrepancy with float In-Reply-To: <1550520914.92.0.84005909816.issue36028@roundup.psfhosted.org> Message-ID: <1550532547.24.0.488804072552.issue36028@roundup.psfhosted.org> Steven D'Aprano added the comment: Changing the title from referring to "decimal" to "float", since this has nothing to do with the decimal module or Decimal type. Like Raymond and Tim, I too cannot reproduce the claimed difference in behaviour between Python 2.7 and 3.x. Au Vo, there are many resources on the web explaining why floats such as 0.4 do not equal exactly four tenths. One of the best (but not the easiest to understand) is What Every Computer Scientist Should Know About Floating-Point Arithmetic https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html A more accessible (to me at least) resource is Bruce Dawson's blog: https://randomascii.wordpress.com/category/floating-point/page/1/ although it is written from the perspective of a C programmer. There's also a Python FAQ about it: https://docs.python.org/3/faq/design.html#why-are-floating-point-calculations-so-inaccurate ---------- nosy: +steven.daprano title: Integer Division discrepancy with decimal -> Integer Division discrepancy with float _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 18:32:02 2019 From: report at bugs.python.org (SylvainDe) Date: Mon, 18 Feb 2019 23:32:02 +0000 Subject: [issue36026] Different error message when sys.settrace is used (regressions) In-Reply-To: <1550513164.21.0.815390267137.issue36026@roundup.psfhosted.org> Message-ID: <1550532722.45.0.738448336181.issue36026@roundup.psfhosted.org> SylvainDe added the comment: This is mostly true and I agree that error messages are not part of the API. However, I'd like to add the following points: - the error message was more meaningful before - the fact that having system.settrace used or not changes the behaviour makes me think this is not intentional. - the fact that the behaviour for unit test.assertRaisesRegexp is different depending on whether it is used as a context manager makes me think this is not intentional. From the documentation it seems like the 2 should behave the same way. Thus, even if this eventually deserves to be closed as a non-issue, I'd rather go on the safe side and double check if this is the desirable behaviour or if something went wrong with the commits previously mentioned. Maybe Jeroen Demeyer (jdemeyer) would have more hindsight about this. Does that look like an acceptable trade off? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 18:33:18 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Mon, 18 Feb 2019 23:33:18 +0000 Subject: [issue36027] Consider adding modular multiplicative inverse to the math module In-Reply-To: <1550520659.43.0.126744170658.issue36027@roundup.psfhosted.org> Message-ID: <1550532798.8.0.121447876633.issue36027@roundup.psfhosted.org> Change by Steven D'Aprano : ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 18:42:51 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Mon, 18 Feb 2019 23:42:51 +0000 Subject: [issue36018] Add a Normal Distribution class to the statistics module In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org> Message-ID: <1550533371.11.0.242317744266.issue36018@roundup.psfhosted.org> Steven D'Aprano added the comment: I like this idea! Should the "examples" method be re-named "samples"? That's the word used in the docstring, and it matches the from_samples method. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 19:01:47 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Tue, 19 Feb 2019 00:01:47 +0000 Subject: [issue35904] Add statistics.fmean(seq) In-Reply-To: <1549411161.36.0.783593325223.issue35904@roundup.psfhosted.org> Message-ID: <1550534507.38.0.09465865957.issue35904@roundup.psfhosted.org> Steven D'Aprano added the comment: PR looks good to me, thanks Raymond. Just at the moment I'm having problems with my internet connection leading to technical difficulties with Github. Hopefully I can resolve this soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 20:31:39 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 19 Feb 2019 01:31:39 +0000 Subject: [issue36028] Integer Division discrepancy with float In-Reply-To: <1550520914.92.0.84005909816.issue36028@roundup.psfhosted.org> Message-ID: <1550539899.11.0.56089459789.issue36028@roundup.psfhosted.org> Raymond Hettinger added the comment: The open question in my mind is which is the least surprising definition of a//b. Should it be math.floor(a/b) or divmod(a,b)[0]? The advantage of the former is that floor(a/b) is arguably the definition of floor division. The advantage of the latter is that a//b, a%b, and divmod(a,b) are consistent with one another. FWIW, it looks like NumPy and PyPy made the same design choice as CPython: >>> a = numpy.array([4.0, 4.0, 4.0], dtype=numpy.float64) >>> b = numpy.array([0.4, 0.5, 0.6], dtype=numpy.float64) >>> a / b array([10. , 8. , 6.66666667]) >>> a // b array([9., 8., 6.]) $ pypy3 Python 3.5.3 (fdd60ed87e941677e8ea11acf9f1819466521bf2, Apr 26 2018, 01:25:35) [PyPy 6.0.0 with GCC 4.2.1 Compatible Apple LLVM 9.1.0 (clang-902.0.39.1)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>>> 4.0 / 0.4 10.0 >>>> 4.0 // 0.4 9.0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 21:27:03 2019 From: report at bugs.python.org (Windson Yang) Date: Tue, 19 Feb 2019 02:27:03 +0000 Subject: [issue35892] Fix awkwardness of statistics.mode() for multimodal datasets In-Reply-To: <1549219885.57.0.86866159357.issue35892@roundup.psfhosted.org> Message-ID: <1550543223.85.0.410823348435.issue35892@roundup.psfhosted.org> Windson Yang added the comment: I think right now we can > Change mode() to return the first tie instead of raising an exception. This is a behavior change but leaves you with the cleanest API going forward. as well as > Add a Deprecation warning to the current behavior of mode() when it finds multimodal data. In Python 3.9, we change the behavior. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 22:06:17 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 19 Feb 2019 03:06:17 +0000 Subject: [issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character In-Reply-To: <1188943421.22.0.776458935296.issue1104@psf.upfronthosting.co.za> Message-ID: <1550545577.0.0.363315861784.issue1104@roundup.psfhosted.org> miss-islington added the comment: New changeset d5409eb6c26c6bca2686762ce0fd5223bb845e8a by Miss Islington (bot) (Tzu-ping Chung) in branch '2.7': [2.7] bpo-1104: msilib.SummaryInfo.GetProperty() truncates the string by one character (GH-4517) (GH-11749) https://github.com/python/cpython/commit/d5409eb6c26c6bca2686762ce0fd5223bb845e8a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 22:14:43 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 19 Feb 2019 03:14:43 +0000 Subject: [issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character In-Reply-To: <1188943421.22.0.776458935296.issue1104@psf.upfronthosting.co.za> Message-ID: <1550546083.1.0.867646932925.issue1104@roundup.psfhosted.org> Change by Steve Dower : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 22:27:28 2019 From: report at bugs.python.org (Eryk Sun) Date: Tue, 19 Feb 2019 03:27:28 +0000 Subject: [issue33935] shutil.copyfile throws incorrect SameFileError on Google Drive File Stream In-Reply-To: <1529627906.69.0.56676864532.issue33935@psf.upfronthosting.co.za> Message-ID: <1550546848.14.0.155565185689.issue33935@roundup.psfhosted.org> Eryk Sun added the comment: Here's a WebDAV example: net use Z: \\live.sysinternals.com\tools Both st_dev (volume serial number) and st_ino (file number) are 0 for all files on this drive. _getfinalpathname also fails since WebDAV doesn't support the default FILE_NAME_NORMALIZED flag (i.e. replace 8.3 short names in the path with normal names). We need realpath(), which will reasonably handle cases where _getfinalpathname fails. See issue 14094. samefile() has to go back into ntpath.py in Windows. The generic implementation relies on the POSIX guarantee that the tuple (st_dev, st_ino) uniquely identifies a file, which Windows doesn't provide. I suggest the following for samefile(). If either st_ino or st_dev is different, return False. If they're equal and non-zero, return True. Otherwise compare the final paths. If st_ino is zero, compare the entire paths. If st_ino is non-zero, then compare only the drives. (This supports the unusual case of hardlinks on a volume that has no serial number.) The final paths can come from realpath() if issue 14094 is resolved. For example: def samefile(fn1, fn2): """Test whether two file names reference the same file""" s1 = os.stat(fn1) s2 = os.stat(fn2) if s1.st_ino != s2.st_ino or s1.st_dev != s2.st_dev: return False if s1.st_ino and s1.st_dev: return True rp1, rp2 = realpath(fn1), realpath(fn2) if s1.st_ino: return splitdrive(rp1)[0] == splitdrive(rp2)[0] return rp1 == rp2 For sameopenfile(), it's trivial to extend _getfinalpathname to support the argument as a file-descriptor, in which case it simply calls _get_osfhandle to get the handle instead of opening the file via CreateFileW. This loses the flexibility of realpath(), but below I propose extending the range of paths supported by _getfinalpathname. --- Note that the root directory in FAT32 is file number 0. For NTFS, the file number is never 0. The high word of the 64-bit file reference number is a sequence number that begins at 1. For local drives the volume serial number shouldn't be zero. It's possible to manually change it to zero, but that's intentional mischief. There's a small chance that two drives have the same serial number, and an even smaller chance that we get an (st_dev, st_ino) match that's a false positive. I'm not happy with that, however small the probability, but I don't know a simple way to address the problem. For local storage, Windows does have a device number that's similar to POSIX st_dev. It's actually three numbers -- device type (16-bit), device number (32-bit), and partition number (32-bit) -- that taken together constitute an 80-bit ID. The problem is that we have to query IOCTL_STORAGE_GET_DEVICE_NUMBER directly using a handle for the volume device. Getting a handle for the volume can be expensive since we may be starting from a file handle or have a volume that's mounted as a filesystem junction. Plus this lacks generality since it's not implemented by MUP (Multiple UNC Provider, the proxy device for UNC providers) -- not even for a local SMB share such as "\\localhost\C$". To improve reliability for corner cases, _getfinalpathname could be extended to try all path types, with and without normalization. Start with the DOS name. Next try the GUID name (i.e. a device that supports the mountpoint manager but isn't auto-mounted as a DOS drive or file-system junction) and finally the NT name (i.e. a device that doesn't support the mountpoint manager, such as an ImDisk virtual disk, the named-pipe file system, or mailslot file system). For an NT path, _getfinalpathname can try to manually resolve a normal mountpoint via QueryDosDeviceW, but limit this to just drive-letter names and well-known global names from "HKLM\System\CurrentControlSet\Control\Session Manager\DOS Devices" (e.g. PIPE, MAILSLOT). If there's no normal mountpoint, prefix the NT path with the "\\?\GLOBALROOT" link. For example a file named "\spam" on the devices "\Device\ImDisk0" (a ramdisk, say it's mounted as R:), "\Device\NamedPipe", and "\Device\NtOnly" would resolve to "\\?\R:\spam", "\\?\PIPE\spam", and "\\?\GLOBALROOT\Device\NtOnly\spam". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 18 22:53:33 2019 From: report at bugs.python.org (Tim Peters) Date: Tue, 19 Feb 2019 03:53:33 +0000 Subject: [issue36028] Integer Division discrepancy with float In-Reply-To: <1550520914.92.0.84005909816.issue36028@roundup.psfhosted.org> Message-ID: <1550548413.95.0.748950141296.issue36028@roundup.psfhosted.org> Tim Peters added the comment: Thanks, Steven! I'll go on to suggest that the best intro to these issues for Python programmers is in Python's own tutorial: https://docs.python.org/3/tutorial/floatingpoint.html Raymond, `divmod(a, b)[0]` IS the mathematical `floor(a/b)`, where the latter is computed (as if) with infinite precision. Rounding `a/b` to a float _before_ taking the floor is quite different, and was never seriously considered for Python. For one thing, the result is ill-defined unless you control the rounding mode used by HW float division (4.0 / 0.4 == 10.0 only if the rounding mode is to-nearest/even or to-plus-infinity; it's 1 ULP less if to-minus-infinity or to-zero; then taking the floor gives 10 in the former cases but 9 in the latter). It makes scant sense for the result of // to depend on rounding mode: the very name - "floor division" - implies rounding is forced. More fundamentally, a = (a // b)*b + (a % b) is the invariant Guido was most keen to preserve. In any conforming C implementation (by the standard today, but by best practice at the time), fmod(4.0, 0.4) == 0.3999999999999998 on a box with 754 doubles, and Python had no interest in building its own idea of "mod" entirely from scratch. Given that, 4 // 0.4 has to return 9. That said, C's fmod makes more sense for floats than Python's % (which latter makes more sense for integers than C's integer %), because fmod is always exact. Python's float % cannot be, because it retains the sign of the modulus: in, e.g., 1 % -1e100, there is no mathematical integer `n` such that the mathematical 1 + n*-1e100 is both negative and representable as a float. >>> 1 % -1e100 -1e+100 # negative, but not exactly 1 + 1*-1e100 >>> math.fmod(1, -1e100) 1.0 # is exactly 1 + 0*-1e100, but not negative In any case, none of this is going to change after 30 years ;-) For Python 3 I had thought Guido agreed to change a % b for floats to return an exact result (exactly equal to the mathematical a - q*b for some mathematical integer q) such that abs(a % b) <= abs(b)/2, which is most useful most often for floats. But that didn't happen. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 00:11:23 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 19 Feb 2019 05:11:23 +0000 Subject: [issue35689] IDLE: Docstrings and test for colorizer In-Reply-To: <1546987852.48.0.500936785043.issue35689@roundup.psfhosted.org> Message-ID: <1550553083.05.0.584556121256.issue35689@roundup.psfhosted.org> Terry J. Reedy added the comment: New changeset ee0f927bd8dba805a04963dbec1ad49fe830b842 by Terry Jan Reedy (Cheryl Sabella) in branch 'master': bpo-35689: IDLE: Add docstrings and unittests for colorizer.py (GH-11472) https://github.com/python/cpython/commit/ee0f927bd8dba805a04963dbec1ad49fe830b842 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 00:11:55 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 19 Feb 2019 05:11:55 +0000 Subject: [issue35689] IDLE: Docstrings and test for colorizer In-Reply-To: <1546987852.48.0.500936785043.issue35689@roundup.psfhosted.org> Message-ID: <1550553115.04.0.166038392756.issue35689@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11950 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 00:14:49 2019 From: report at bugs.python.org (Au Vo) Date: Tue, 19 Feb 2019 05:14:49 +0000 Subject: [issue36028] Integer Division discrepancy with float In-Reply-To: <1550520914.92.0.84005909816.issue36028@roundup.psfhosted.org> Message-ID: <1550553289.15.0.841541769212.issue36028@roundup.psfhosted.org> Au Vo added the comment: Thanks for the quick turnaround. I have done a little bit more thorough investigation and it does indeed the floating point that causes the behavior. The screenshot attached is done via Python3 from trinket.io. I will submit a screenshot of the Python 2 screenshot from trinket.io for comparison. Even though floating point is the underlying concept, Python 2 and 3 do not converge in the result. On the side note, The behavior could be more easily expressed as follows: 2// .2 == 9.0 2000000000/.2 == 9999999999.0 ---------- Added file: https://bugs.python.org/file48152/Screen Shot 2019-02-18 at 9.07.37 PM.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 00:17:35 2019 From: report at bugs.python.org (Au Vo) Date: Tue, 19 Feb 2019 05:17:35 +0000 Subject: [issue36028] Integer Division discrepancy with float In-Reply-To: <1550520914.92.0.84005909816.issue36028@roundup.psfhosted.org> Message-ID: <1550553455.11.0.145333248561.issue36028@roundup.psfhosted.org> Au Vo added the comment: Here is the Python2 screenshot from trinket.io. There are discrepancies with 1,2,4,8,9, with 9 is given in Python2 and 10 is given in Python3. Again, sorry that Trinket.io does not specify which version of Python3 it implements. ---------- versions: +Python 2.7 -Python 3.8 Added file: https://bugs.python.org/file48153/Screen Shot 2019-02-18 at 9.08.19 PM.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 00:21:59 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 19 Feb 2019 05:21:59 +0000 Subject: [issue35689] IDLE: Docstrings and test for colorizer In-Reply-To: <1546987852.48.0.500936785043.issue35689@roundup.psfhosted.org> Message-ID: <1550553719.62.0.329037091442.issue35689@roundup.psfhosted.org> Terry J. Reedy added the comment: Thank you for writing this. I was NOT looking forward to tackling tests for this module. I have thought about merging delegator and colorizer into one module, possibly with percolator included, and adding a module docstring that explains how they work together. This would still be only a few hundred lines. (And multiple htests in one file are not an issue.) What do you think? There is a suggestion in percolater that Percolater could subclass Delegator. I have not seriously looked at that idea yet. In the first code comment I mentioned a follow-up code change. Did you have anything in mind to work on or did you pick this for the fun and challenge? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 00:30:57 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 19 Feb 2019 05:30:57 +0000 Subject: [issue35689] IDLE: Docstrings and test for colorizer In-Reply-To: <1546987852.48.0.500936785043.issue35689@roundup.psfhosted.org> Message-ID: <1550554257.22.0.377996450883.issue35689@roundup.psfhosted.org> miss-islington added the comment: New changeset 99e9c36b29a194d59ee4b0d8b82a72f5b0d409dd by Miss Islington (bot) in branch '3.7': bpo-35689: IDLE: Add docstrings and unittests for colorizer.py (GH-11472) https://github.com/python/cpython/commit/99e9c36b29a194d59ee4b0d8b82a72f5b0d409dd ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 00:34:15 2019 From: report at bugs.python.org (Tim Peters) Date: Tue, 19 Feb 2019 05:34:15 +0000 Subject: [issue36027] Consider adding modular multiplicative inverse to the math module In-Reply-To: <1550520659.43.0.126744170658.issue36027@roundup.psfhosted.org> Message-ID: <1550554455.13.0.54003501046.issue36027@roundup.psfhosted.org> Tim Peters added the comment: - Some form of this would be most welcome! - If it's spelled this way, put the modulus argument last? "Everyone expects" the modulus to come last, whether in code: x = (a+b) % m x = a*b % m x = pow(a, b, m) or in math: a^(k*(p-1)) = (a^(p-1))^k = 1^k = 1 (mod p) - Years ago Guido signed off on spelling this pow(value, -1, modulus) which currently raises an exception. Presumably pow(value, -n, modulus) for int n > 1 would mean the same as pow(pow(value, -1, modulus), n, modulus), if it were accepted at all. I'd be happy to stop with -1. - An alternative could be to supply egcd(a, b) returning (g, x, y) such that a*x + b*y == g == gcd(a, b) But I'm not sure anyone would use that _except_ to compute modular inverse. So probably not. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 01:13:32 2019 From: report at bugs.python.org (Ma Lin) Date: Tue, 19 Feb 2019 06:13:32 +0000 Subject: [issue23689] Memory leak in Modules/sre_lib.h In-Reply-To: <1426611380.23.0.46113718722.issue23689@psf.upfronthosting.co.za> Message-ID: <1550556812.05.0.784538747142.issue23689@roundup.psfhosted.org> Ma Lin added the comment: Try to allocate SRE_REPEAT on state's stack, the performance has not changed significantly. It passes the other tests, except this one (test_stack_overflow): https://github.com/python/cpython/blob/v3.8.0a1/Lib/test/test_re.py#L1225-L1230 I'll try to fix issue35859, issue9134 first. ---------- versions: +Python 3.8 -Python 2.7, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 01:13:46 2019 From: report at bugs.python.org (Ma Lin) Date: Tue, 19 Feb 2019 06:13:46 +0000 Subject: [issue23689] Memory leak in Modules/sre_lib.h In-Reply-To: <1426611380.23.0.46113718722.issue23689@psf.upfronthosting.co.za> Message-ID: <1550556826.11.0.0579040778169.issue23689@roundup.psfhosted.org> Change by Ma Lin : ---------- pull_requests: +11951 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 01:28:49 2019 From: report at bugs.python.org (Carol Willing) Date: Tue, 19 Feb 2019 06:28:49 +0000 Subject: [issue36022] [Security] logging.config should not use eval() In-Reply-To: <1550489368.54.0.864409036165.issue36022@roundup.psfhosted.org> Message-ID: <1550557729.13.0.868095037294.issue36022@roundup.psfhosted.org> Carol Willing added the comment: Assigning this to @Mariatta, to be worked on the mentored sprint at PyCon US Cleveland. ---------- assignee: -> Mariatta nosy: +Mariatta, willingc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 01:30:19 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 Feb 2019 06:30:19 +0000 Subject: [issue35798] duplicate SyntaxWarning: "is" with a literal In-Reply-To: <1548083625.41.0.59098075844.issue35798@roundup.psfhosted.org> Message-ID: <1550557819.66.0.993799600063.issue35798@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset e7a4bb554edb72fc6619d23241d59162d06f249a by Serhiy Storchaka in branch 'master': bpo-35798: Add test.support.check_syntax_warning(). (#11895) https://github.com/python/cpython/commit/e7a4bb554edb72fc6619d23241d59162d06f249a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 01:32:50 2019 From: report at bugs.python.org (Carol Willing) Date: Tue, 19 Feb 2019 06:32:50 +0000 Subject: [issue35957] Indentation explanation is unclear In-Reply-To: <1549819617.52.0.344509790006.issue35957@roundup.psfhosted.org> Message-ID: <1550557970.23.0.478801538306.issue35957@roundup.psfhosted.org> Carol Willing added the comment: Assigning this to @Mariatta, to be worked on the mentored sprint at PyCon US Cleveland. Verify behavior and update documentation. ---------- assignee: docs at python -> Mariatta nosy: +Mariatta, willingc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 01:48:00 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 Feb 2019 06:48:00 +0000 Subject: [issue35798] duplicate SyntaxWarning: "is" with a literal In-Reply-To: <1548083625.41.0.59098075844.issue35798@roundup.psfhosted.org> Message-ID: <1550558880.75.0.234122129441.issue35798@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 01:48:16 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 Feb 2019 06:48:16 +0000 Subject: [issue35798] duplicate SyntaxWarning: "is" with a literal In-Reply-To: <1548083625.41.0.59098075844.issue35798@roundup.psfhosted.org> Message-ID: <1550558896.58.0.955039053373.issue35798@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 02:04:28 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 Feb 2019 07:04:28 +0000 Subject: [issue36025] Breaking change in PyDate_FromTimeStamp API In-Reply-To: <1550510525.68.0.55104762284.issue36025@roundup.psfhosted.org> Message-ID: <1550559868.11.0.21460326599.issue36025@roundup.psfhosted.org> Serhiy Storchaka added the comment: I prefer option 2. Your PR LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 02:23:43 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 19 Feb 2019 07:23:43 +0000 Subject: [issue36027] Consider adding modular multiplicative inverse to the math module In-Reply-To: <1550520659.43.0.126744170658.issue36027@roundup.psfhosted.org> Message-ID: <1550561023.91.0.702144955046.issue36027@roundup.psfhosted.org> Raymond Hettinger added the comment: > If it's spelled this way, put the modulus argument last? Yes, that makes sense. > Years ago Guido signed off on spelling this > > pow(value, -1, modulus) +1 ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 02:41:26 2019 From: report at bugs.python.org (Michael Felt) Date: Tue, 19 Feb 2019 07:41:26 +0000 Subject: [issue34757] Placeholder for discussion on Combined patches for AIX - to resolve failig tests In-Reply-To: <1537467095.33.0.956365154283.issue34757@psf.upfronthosting.co.za> Message-ID: <1550562086.47.0.0745253050609.issue34757@roundup.psfhosted.org> Michael Felt added the comment: The PR's have been merged. Many thanks. Closing this issue and looking forward. ---------- stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 02:43:12 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 Feb 2019 07:43:12 +0000 Subject: [issue36026] Different error message when sys.settrace is used (regressions) In-Reply-To: <1550513164.21.0.815390267137.issue36026@roundup.psfhosted.org> Message-ID: <1550562192.55.0.923943303047.issue36026@roundup.psfhosted.org> Serhiy Storchaka added the comment: Looks this is due to the method calls optimization (issue26110). We now avoid to create a temporary bound method, and an error with different message is raised on this path. >>> set.add(0) Traceback (most recent call last): File "", line 1, in TypeError: descriptor 'add' requires a 'set' object but received a 'int' >>> set.add.__get__(0) Traceback (most recent call last): File "", line 1, in TypeError: descriptor 'add' for 'set' objects doesn't apply to 'int' object ---------- nosy: +inada.naoki, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 03:02:44 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Tue, 19 Feb 2019 08:02:44 +0000 Subject: [issue36030] add internal API function to create tuple without items array initialization Message-ID: <1550563364.86.0.164811838679.issue36030@roundup.psfhosted.org> New submission from Sergey Fedoseev : PyTuple_New() fills items array with NULLs to make usage of Py_DECREF() safe even when array is not fully filled with real items. There are multiple cases when this initialization step can be avoided to improve performance. For example it gives such speed-up for PyList_AsTuple(): Before: $ python -m perf timeit -s "l = [None] * 10**6" "tuple(l)" ..................... Mean +- std dev: 4.43 ms +- 0.01 ms After: $ python -m perf timeit -s "l = [None] * 10**6" "tuple(l)" ..................... Mean +- std dev: 4.11 ms +- 0.03 ms ---------- messages: 335897 nosy: sir-sigurd priority: normal severity: normal status: open title: add internal API function to create tuple without items array initialization type: performance versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 03:05:28 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Tue, 19 Feb 2019 08:05:28 +0000 Subject: [issue36030] add internal API function to create tuple without items array initialization In-Reply-To: <1550563364.86.0.164811838679.issue36030@roundup.psfhosted.org> Message-ID: <1550563528.37.0.68773494402.issue36030@roundup.psfhosted.org> Change by Sergey Fedoseev : ---------- keywords: +patch pull_requests: +11952 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 03:06:56 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 19 Feb 2019 08:06:56 +0000 Subject: [issue36030] add internal API function to create tuple without items array initialization In-Reply-To: <1550563364.86.0.164811838679.issue36030@roundup.psfhosted.org> Message-ID: <1550563616.68.0.503917398924.issue36030@roundup.psfhosted.org> Change by St?phane Wirtel : ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 03:12:20 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 19 Feb 2019 08:12:20 +0000 Subject: [issue35126] Mistake in FAQ about converting number to string. In-Reply-To: <1541005659.07.0.788709270274.issue35126@psf.upfronthosting.co.za> Message-ID: <1550563940.08.0.702922526861.issue35126@roundup.psfhosted.org> Change by St?phane Wirtel : ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 03:16:01 2019 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 19 Feb 2019 08:16:01 +0000 Subject: [issue36028] Integer Division discrepancy with float In-Reply-To: <1550520914.92.0.84005909816.issue36028@roundup.psfhosted.org> Message-ID: <1550564161.94.0.657358496305.issue36028@roundup.psfhosted.org> Mark Dickinson added the comment: [Au Vo] > Python2 produces 10.0 as the answers for all of the above calculation. Can you double check this, and confirm which Python version and operating system you're using? Like others, I'm not seeing any difference between Python 2 and Python 3, and as far as I'm aware the implementation of `//` for floats hasn't changed between Python 2 and Python 3. There's no behavioural bug here: all operations are producing perfectly correctly rounded results, which is about as good as one could possibly hope for. And as Tim says: > In any case, none of this is going to change after 30 years ;-) It's surprising, sure, but it's correct, and I can't imagine any fudge that would make the two results match without introducing a horde of other weird corner cases. [Tim] > For Python 3 I had thought Guido agreed to change a % b for floats to > return an exact result (exactly equal to the mathematical a - q*b for > some mathematical integer q) such that abs(a % b) <= abs(b)/2, which > is most useful most often for floats. But that didn't happen. If it's any consolation, we do at least have `math.remainder` in Python 3.7, which does exactly this. Closing this issue. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 03:24:05 2019 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 19 Feb 2019 08:24:05 +0000 Subject: [issue36028] Integer Division discrepancy with float In-Reply-To: <1550520914.92.0.84005909816.issue36028@roundup.psfhosted.org> Message-ID: <1550564645.16.0.242324435365.issue36028@roundup.psfhosted.org> Mark Dickinson added the comment: > Can you double check this, and confirm which Python version and operating system you're using? Sorry; I missed the screenshots. It looks as though you labelled those the wrong way around, BTW: I think "Screen Shot 2019-02-18 at 9.07.37 PM.png" is the Python 2 one, and it looks as though Trinket does indeed give a result of 10 for 1 // 0.1. Unfortunately, there's little information about how Trinket is implemented. Is it CPython-based? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 03:27:21 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Tue, 19 Feb 2019 08:27:21 +0000 Subject: [issue35954] Incoherent type conversion in configparser In-Reply-To: <1549801714.53.0.77041525212.issue35954@roundup.psfhosted.org> Message-ID: <1550564841.98.0.0806945923021.issue35954@roundup.psfhosted.org> R?mi Lapeyre added the comment: Other methods validate explicitly their arguments with _validate_value_types for example. Here it raises KeyError which does not seem to be the appropriate exception. ConfigParser implementing the mapping protocol it seems weird to me to have >>> a = 123 >>> config[a] = {} >>> config[a] KeyError: 123 I would have prefered a TypeError to be raised on __setitem__ but this is now documented behavior. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 03:27:37 2019 From: report at bugs.python.org (SylvainDe) Date: Tue, 19 Feb 2019 08:27:37 +0000 Subject: [issue36026] Different error message when sys.settrace is used (regressions) In-Reply-To: <1550513164.21.0.815390267137.issue36026@roundup.psfhosted.org> Message-ID: <1550564857.32.0.852123348743.issue36026@roundup.psfhosted.org> Change by SylvainDe : ---------- type: -> behavior versions: +Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 03:35:20 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Tue, 19 Feb 2019 08:35:20 +0000 Subject: [issue36031] add internal API function to effectively convert just created list to tuple Message-ID: <1550565320.39.0.769773111251.issue36031@roundup.psfhosted.org> New submission from Sergey Fedoseev : There are several cases in CPython sources when PyList_AsTuple() is used with just created list and immediately after that this list is Py_DECREFed. This operation can be performed more effectively since refcount of items is not changed. For example it gives such speed-up for BUILD_TUPLE_UNPACK: Before: $ python -m perf timeit -s "l = [None]*10**6" "(*l,)" ..................... Mean +- std dev: 8.75 ms +- 0.10 ms After: $ python -m perf timeit -s "l = [None]*10**6" "(*l,)" ..................... Mean +- std dev: 5.41 ms +- 0.07 ms ---------- messages: 335901 nosy: sir-sigurd priority: normal severity: normal status: open title: add internal API function to effectively convert just created list to tuple type: performance versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 03:35:53 2019 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 19 Feb 2019 08:35:53 +0000 Subject: [issue36028] Integer Division discrepancy with float In-Reply-To: <1550520914.92.0.84005909816.issue36028@roundup.psfhosted.org> Message-ID: <1550565353.71.0.781117925376.issue36028@roundup.psfhosted.org> Mark Dickinson added the comment: > Unfortunately, there's little information about how Trinket is implemented. Is it CPython-based? >From a little playing around, Trinket only provides a subset of Python (one might say "batteries not included"), and it's not clear what its basis is. None of `sys.version_info`, `sys.platform`, `sys.float_info`, `sys.float_repr_style`, `int.bit_length` or `math.fmod` was available in my Python 2 tests. 1 % 0.1 gives 0.1, but 1 // 0.1 gives 10, so the invariant that Tim mentions is broken on Trinket. @Au Vo: it looks as though you should take this up with the Trinket developers. It looks like a problem with their Python-subset implementation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 03:36:33 2019 From: report at bugs.python.org (INADA Naoki) Date: Tue, 19 Feb 2019 08:36:33 +0000 Subject: [issue36026] Different error message when sys.settrace is used In-Reply-To: <1550513164.21.0.815390267137.issue36026@roundup.psfhosted.org> Message-ID: <1550565393.76.0.846624666543.issue36026@roundup.psfhosted.org> INADA Naoki added the comment: > Thus, even if this eventually deserves to be closed as a non-issue, I'd rather go on the safe side and double check if this is the desirable behaviour or if something went wrong with the commits previously mentioned. As Serhiy mentioned, this error message is raised from optimization path. Nothing went wrong. Error messages are vary depending on internal C code paths. So this is not an bug or issue. People must not rely on error message. On the other hand, I don't oppose to making error messages more consistent. It improve code health, like fixing typos in C comment which Python user doesn't see. ---------- components: +Interpreter Core title: Different error message when sys.settrace is used (regressions) -> Different error message when sys.settrace is used type: behavior -> versions: -Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 03:38:57 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Tue, 19 Feb 2019 08:38:57 +0000 Subject: [issue36031] add internal API function to effectively convert just created list to tuple In-Reply-To: <1550565320.39.0.769773111251.issue36031@roundup.psfhosted.org> Message-ID: <1550565537.01.0.634572447191.issue36031@roundup.psfhosted.org> Change by Sergey Fedoseev : ---------- keywords: +patch pull_requests: +11953 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 03:40:08 2019 From: report at bugs.python.org (SylvainDe) Date: Tue, 19 Feb 2019 08:40:08 +0000 Subject: [issue36026] Different error message when sys.settrace is used In-Reply-To: <1550513164.21.0.815390267137.issue36026@roundup.psfhosted.org> Message-ID: <1550565608.6.0.0457949541304.issue36026@roundup.psfhosted.org> SylvainDe added the comment: Thanks for the investigation. I'm fine with the explanation provided. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 03:45:34 2019 From: report at bugs.python.org (Amit Amely) Date: Tue, 19 Feb 2019 08:45:34 +0000 Subject: [issue36032] Wrong output in tutorial (3.1.2. Strings) Message-ID: <1550565934.5.0.314572203435.issue36032@roundup.psfhosted.org> New submission from Amit Amely : This is the tutorial text: >>> prefix = 'Py' >>> prefix 'thon' # can't concatenate a variable and a string literal ... SyntaxError: invalid syntax >>> ('un' * 3) 'ium' ... SyntaxError: invalid syntax This is the actual result: >>> prefix = 'Py' >>> prefix 'thon' # can't concatenate a variable and a string literal File "", line 1 prefix 'thon' # can't concatenate a variable and a string literal ^ SyntaxError: invalid syntax ---------- assignee: docs at python components: Documentation messages: 335905 nosy: Amit Amely, docs at python priority: normal severity: normal status: open title: Wrong output in tutorial (3.1.2. Strings) versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 03:49:31 2019 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 19 Feb 2019 08:49:31 +0000 Subject: [issue36028] Integer Division discrepancy with float In-Reply-To: <1550520914.92.0.84005909816.issue36028@roundup.psfhosted.org> Message-ID: <1550566171.85.0.667057869613.issue36028@roundup.psfhosted.org> Change by Mark Dickinson : ---------- resolution: not a bug -> third party _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 03:52:34 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 Feb 2019 08:52:34 +0000 Subject: [issue36031] add internal API function to effectively convert just created list to tuple In-Reply-To: <1550565320.39.0.769773111251.issue36031@roundup.psfhosted.org> Message-ID: <1550566354.0.0.505674297727.issue36031@roundup.psfhosted.org> Serhiy Storchaka added the comment: Could you provide more real world examples? Optimizing just one artificial example does not look impressive. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 03:54:47 2019 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 19 Feb 2019 08:54:47 +0000 Subject: [issue36028] Integer Division discrepancy with float In-Reply-To: <1550520914.92.0.84005909816.issue36028@roundup.psfhosted.org> Message-ID: <1550566487.31.0.376786285833.issue36028@roundup.psfhosted.org> Mark Dickinson added the comment: >From a little more digging, it seems that Trinket's Python 2 is based on Skulpt (so is a JavaScript implementation of a subset of Python), while the Python 3 "trinket" connects to an Ubuntu Linux server running CPython 3.6.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 03:56:47 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 19 Feb 2019 08:56:47 +0000 Subject: [issue36029] Use consistent case for HTTP header fields In-Reply-To: <1550529210.49.0.526576386821.issue36029@roundup.psfhosted.org> Message-ID: <1550566607.6.0.626202713189.issue36029@roundup.psfhosted.org> St?phane Wirtel added the comment: Thank you for your contribution and your issue, it's really appreciated. I had a doubt about this point and I wanted to verify about the HTTP headers. But in the previous version of this RFC7230: https://www.w3.org/Protocols/rfc2616/rfc2616.html Here is the section 4.2 "Message Headers" of this previous RFC: https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2 where you have "Field names are case-insensitive". We can see the RFC2616 was replaced by multiple RFCs (7230-7237) and in the RFC 7230, there is a section 3.2 where there is the description of the header fields. In the section 3.2 of RFC7230: 3.2. Header Fields " Each header field consists of a case-insensitive field name followed by a colon (":"), optional leading whitespace, the field value, and optional trailing whitespace. " https://tools.ietf.org/html/rfc7230#section-3.2 So in this case, it's case-insensitive. I think we can close this issue and the associated Pull Request. Have a nice day and thank you, ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 03:58:28 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 Feb 2019 08:58:28 +0000 Subject: [issue36032] Wrong output in tutorial (3.1.2. Strings) In-Reply-To: <1550565934.5.0.314572203435.issue36032@roundup.psfhosted.org> Message-ID: <1550566708.0.0.887735084388.issue36032@roundup.psfhosted.org> Serhiy Storchaka added the comment: The output in tutorial is correct. "..." means omitted output (we don't want to clutter examples with insignificant details). ---------- nosy: +serhiy.storchaka resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 04:03:15 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 19 Feb 2019 09:03:15 +0000 Subject: [issue35689] IDLE: Docstrings and test for colorizer In-Reply-To: <1546987852.48.0.500936785043.issue35689@roundup.psfhosted.org> Message-ID: <1550566995.94.0.804295272071.issue35689@roundup.psfhosted.org> Change by Terry J. Reedy : ---------- nosy: -miss-islington resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 04:03:39 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 Feb 2019 09:03:39 +0000 Subject: [issue35859] Capture behavior depends on the order of an alternation In-Reply-To: <1548857774.3.0.1614070954.issue35859@roundup.psfhosted.org> Message-ID: <1550567019.75.0.494147041118.issue35859@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- pull_requests: -11700 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 04:03:45 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 Feb 2019 09:03:45 +0000 Subject: [issue35859] Capture behavior depends on the order of an alternation In-Reply-To: <1548857774.3.0.1614070954.issue35859@roundup.psfhosted.org> Message-ID: <1550567025.7.0.525106736821.issue35859@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- pull_requests: -11701 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 04:14:59 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 19 Feb 2019 09:14:59 +0000 Subject: [issue36031] add internal API function to effectively convert just created list to tuple In-Reply-To: <1550565320.39.0.769773111251.issue36031@roundup.psfhosted.org> Message-ID: <1550567699.58.0.382851682294.issue36031@roundup.psfhosted.org> Change by St?phane Wirtel : ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 04:26:06 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 19 Feb 2019 09:26:06 +0000 Subject: [issue35126] Mistake in FAQ about converting number to string. In-Reply-To: <1541005659.07.0.788709270274.issue35126@psf.upfronthosting.co.za> Message-ID: <1550568366.13.0.869230237098.issue35126@roundup.psfhosted.org> miss-islington added the comment: New changeset c611db4942a07c81f54e6584615bbddc51034a77 by Miss Islington (bot) (St?phane Wirtel) in branch '2.7': [2.7] bpo-35126: Fix a mistake in FAQ about converting number to string (GH-11911) https://github.com/python/cpython/commit/c611db4942a07c81f54e6584615bbddc51034a77 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 04:26:58 2019 From: report at bugs.python.org (INADA Naoki) Date: Tue, 19 Feb 2019 09:26:58 +0000 Subject: [issue36026] Different error message when sys.settrace is used In-Reply-To: <1550513164.21.0.815390267137.issue36026@roundup.psfhosted.org> Message-ID: <1550568418.99.0.436620978118.issue36026@roundup.psfhosted.org> INADA Naoki added the comment: Is this make sense? >>> set.add(0) Traceback (most recent call last): File "", line 1, in TypeError: descriptor 'add' for type 'set' doesn't apply to type 'int' >>> set.add.__get__(0) Traceback (most recent call last): File "", line 1, in TypeError: descriptor 'add' for type 'set' doesn't apply to type 'int' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 04:27:54 2019 From: report at bugs.python.org (Amit Amely) Date: Tue, 19 Feb 2019 09:27:54 +0000 Subject: [issue36032] Wrong output in tutorial (3.1.2. Strings) In-Reply-To: <1550566708.0.0.887735084388.issue36032@roundup.psfhosted.org> Message-ID: Amit Amely added the comment: But it also contains an error message part which has nothing to do with this example (marked in dark green) This only works with two literals though, not with variables or expressions: >>> prefix = 'Py'>>> prefix 'thon' # can't concatenate a variable and a string literal ...SyntaxError: invalid syntax>>> ('un' * 3) 'ium' ...SyntaxError: invalid syntax If you want to concatenate variables or a variable and a literal, use +: On Tue, Feb 19, 2019 at 10:58 AM Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > The output in tutorial is correct. "..." means omitted output (we don't > want to clutter examples with insignificant details). > > ---------- > nosy: +serhiy.storchaka > resolution: -> not a bug > stage: -> resolved > status: open -> closed > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 04:29:24 2019 From: report at bugs.python.org (INADA Naoki) Date: Tue, 19 Feb 2019 09:29:24 +0000 Subject: [issue36026] Different error message when sys.settrace is used In-Reply-To: <1550513164.21.0.815390267137.issue36026@roundup.psfhosted.org> Message-ID: <1550568564.28.0.840596608913.issue36026@roundup.psfhosted.org> Change by INADA Naoki : ---------- keywords: +patch pull_requests: +11954 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 04:34:26 2019 From: report at bugs.python.org (SylvainDe) Date: Tue, 19 Feb 2019 09:34:26 +0000 Subject: [issue36026] Different error message when sys.settrace is used In-Reply-To: <1550513164.21.0.815390267137.issue36026@roundup.psfhosted.org> Message-ID: <1550568866.02.0.234291649066.issue36026@roundup.psfhosted.org> SylvainDe added the comment: This looks good to me :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 04:41:03 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 Feb 2019 09:41:03 +0000 Subject: [issue36026] Different error message when sys.settrace is used In-Reply-To: <1550513164.21.0.815390267137.issue36026@roundup.psfhosted.org> Message-ID: <1550569263.69.0.0950113752427.issue36026@roundup.psfhosted.org> Serhiy Storchaka added the comment: I consider this as a minor regression in 3.7, unless there were reasons to change error messages. I think that in this case the change that restores error messages should be backported to 3.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 04:41:24 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 19 Feb 2019 09:41:24 +0000 Subject: [issue36032] Wrong output in tutorial (3.1.2. Strings) In-Reply-To: <1550565934.5.0.314572203435.issue36032@roundup.psfhosted.org> Message-ID: <1550569284.95.0.0622690069698.issue36032@roundup.psfhosted.org> St?phane Wirtel added the comment: @serhiy I think Amit wants to say there is no triple point in these examples of the tutorial. ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 04:42:54 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 19 Feb 2019 09:42:54 +0000 Subject: [issue36032] Wrong output in tutorial (3.1.2. Strings) In-Reply-To: <1550565934.5.0.314572203435.issue36032@roundup.psfhosted.org> Message-ID: <1550569374.79.0.338048993514.issue36032@roundup.psfhosted.org> St?phane Wirtel added the comment: and when you execute the examples, the REPL does not generate the triple points. For me, the examples of the tuto are correct and we don't need to add '...' in the examples. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 05:04:25 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Tue, 19 Feb 2019 10:04:25 +0000 Subject: [issue36031] add internal API function to effectively convert just created list to tuple In-Reply-To: <1550565320.39.0.769773111251.issue36031@roundup.psfhosted.org> Message-ID: <1550570665.07.0.653356225616.issue36031@roundup.psfhosted.org> Sergey Fedoseev added the comment: Does this look like more real world example? Before: $ python -m perf timeit -s "t = (1, 2, 3)" "(*t, 4, 5)" ..................... Mean +- std dev: 95.7 ns +- 2.3 ns After: $ python -m perf timeit -s "t = (1, 2, 3)" "(*t, 4, 5)" ..................... Mean +- std dev: 85.1 ns +- 0.6 ns ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 05:11:15 2019 From: report at bugs.python.org (INADA Naoki) Date: Tue, 19 Feb 2019 10:11:15 +0000 Subject: [issue36026] Different error message when sys.settrace is used In-Reply-To: <1550513164.21.0.815390267137.issue36026@roundup.psfhosted.org> Message-ID: <1550571075.85.0.739220690334.issue36026@roundup.psfhosted.org> INADA Naoki added the comment: @Serhiy Error messages are not changed in 3.7. They are different from 3.6. Optimization in 3.7 changed "code path", not error message. So it's difficult to fix this without breaking existing behavior. Python 3.6.7 (default, Dec 18 2018, 17:32:18) [GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.39.2)] on darwin >>> set.add(0) Traceback (most recent call last): File "", line 1, in TypeError: descriptor 'add' requires a 'set' object but received a 'int' >>> set.add.__get__(0) Traceback (most recent call last): File "", line 1, in TypeError: descriptor 'add' for 'set' objects doesn't apply to 'int' object ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 05:24:08 2019 From: report at bugs.python.org (INADA Naoki) Date: Tue, 19 Feb 2019 10:24:08 +0000 Subject: [issue36026] Different error message when sys.settrace is used In-Reply-To: <1550513164.21.0.815390267137.issue36026@roundup.psfhosted.org> Message-ID: <1550571848.45.0.307141808962.issue36026@roundup.psfhosted.org> INADA Naoki added the comment: BTW, should we have different error message for class methods and instance mehtods? * method: "descriptor 'X' for 'Y' objects doesn't apply to a 'Z' object" * classmethod: "descriptor 'X' for 'Y' types doesn't apply to a 'Z' type" Currently, classmethod notice about subtype, but instance method doesn't notice about subtype. Should we notice about subtype in both error message? Could someone write short, clear, and consistent error message? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 05:32:33 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Feb 2019 10:32:33 +0000 Subject: [issue36024] ctypes: test_ctypes test_callbacks() crash on AArch64 with SELinux enabled In-Reply-To: <1550507121.83.0.763079263217.issue36024@roundup.psfhosted.org> Message-ID: <1550572353.77.0.401774768539.issue36024@roundup.psfhosted.org> STINNER Victor added the comment: Florian Weimer wrote a fix for libffi, so the bug is in libffi and not Python/ctypes. I close the issue. There are enough open issues to track this bug :-) https://github.com/libffi/libffi/issues/470 ---------- resolution: -> third party stage: -> resolved status: open -> closed title: ctypes: test_ctypes test_callbacks() crash on AArch64 -> ctypes: test_ctypes test_callbacks() crash on AArch64 with SELinux enabled _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 05:33:24 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 19 Feb 2019 10:33:24 +0000 Subject: [issue36021] [Security][Windows] webbrowser: WindowsDefault uses os.startfile() and so can be abused to run arbitrary commands In-Reply-To: <1550487653.15.0.496398912417.issue36021@roundup.psfhosted.org> Message-ID: <1550572404.94.0.990537826394.issue36021@roundup.psfhosted.org> Change by St?phane Wirtel : ---------- keywords: +patch pull_requests: +11955 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 05:35:09 2019 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 19 Feb 2019 10:35:09 +0000 Subject: [issue36027] Consider adding modular multiplicative inverse to the math module In-Reply-To: <1550520659.43.0.126744170658.issue36027@roundup.psfhosted.org> Message-ID: <1550572509.95.0.528577833216.issue36027@roundup.psfhosted.org> Mark Dickinson added the comment: +1 for the pow(value, -1, modulus) spelling. It should raise `ValueError` if `value` and `modulus` are not relatively prime. It would feel odd to me _not_ to extend this to `pow(value, n, modulus)` for all negative `n`, again valid only only if `value` is relatively prime to `modulus`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 05:41:11 2019 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 19 Feb 2019 10:41:11 +0000 Subject: [issue36027] Consider adding modular multiplicative inverse to the math module In-Reply-To: <1550520659.43.0.126744170658.issue36027@roundup.psfhosted.org> Message-ID: <1550572871.94.0.520372433591.issue36027@roundup.psfhosted.org> Mark Dickinson added the comment: Here's an example of some code in the standard library that would have benefited from the availability of `pow(x, n, m)` for arbitrary negative n: https://github.com/python/cpython/blob/e7a4bb554edb72fc6619d23241d59162d06f249a/Lib/_pydecimal.py#L957-L960 if self._exp >= 0: exp_hash = pow(10, self._exp, _PyHASH_MODULUS) else: exp_hash = pow(_PyHASH_10INV, -self._exp, _PyHASH_MODULUS) where: _PyHASH_10INV = pow(10, _PyHASH_MODULUS - 2, _PyHASH_MODULUS) With the proposed addition, that just becomes `pow(10, self._exp, _PyHASH_MODULUS)`, and the `_PyHASH_10INV` constant isn't needed any more. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 05:44:18 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Feb 2019 10:44:18 +0000 Subject: [issue36030] add internal API function to create tuple without items array initialization In-Reply-To: <1550563364.86.0.164811838679.issue36030@roundup.psfhosted.org> Message-ID: <1550573058.79.0.780957913515.issue36030@roundup.psfhosted.org> STINNER Victor added the comment: Sergey Fedoseev wrote similar change for list: bpo-34151. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 05:44:58 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 19 Feb 2019 10:44:58 +0000 Subject: [issue29515] socket module missing IPPROTO_IPV6, IPPROTO_IPV4 on Windows In-Reply-To: <1486664862.54.0.729311605676.issue29515@psf.upfronthosting.co.za> Message-ID: <1550573098.98.0.829612204377.issue29515@roundup.psfhosted.org> Giampaolo Rodola' added the comment: It turns out having this fix would be useful for proceeding with issue17561, which right now cannot support dual-stack IPv4/6 on Windows because IPPROTO_IPV6 is missing, see my comment: https://github.com/python/cpython/pull/11784#issuecomment-465078646 ---------- dependencies: +Add socket.bind_socket() convenience function nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 05:46:00 2019 From: report at bugs.python.org (Rodolfo Alonso) Date: Tue, 19 Feb 2019 10:46:00 +0000 Subject: [issue36033] logging.makeLogRecord should update "rv" using a dict defined with bytes instead of strings Message-ID: <1550573160.5.0.804221686367.issue36033@roundup.psfhosted.org> New submission from Rodolfo Alonso : When using Pycharm to execute unit/functional tests (OpenStack development), oslo_privsep.daemon._ClientChannel.out_of_band retrieves the record from the input arguments. Pycharm arguments are stored in a dictionary using bytes instead of strings. When logging.makeLogRecord tries to update "rv", the value in "dict" parameter (using bytes) doesn't update "rv" values. ---------- messages: 335925 nosy: ralonsoh priority: normal severity: normal status: open title: logging.makeLogRecord should update "rv" using a dict defined with bytes instead of strings type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 06:08:26 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 Feb 2019 11:08:26 +0000 Subject: [issue35942] posixmodule.c:path_converter() returns an invalid exception message for broken PathLike objects In-Reply-To: <1549643679.09.0.475002054663.issue35942@roundup.psfhosted.org> Message-ID: <1550574506.09.0.595287439258.issue35942@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- pull_requests: +11956 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 06:08:26 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 Feb 2019 11:08:26 +0000 Subject: [issue15248] Better explain "TypeError: 'tuple' object is not callable" In-Reply-To: <1341379722.78.0.0866285571225.issue15248@psf.upfronthosting.co.za> Message-ID: <1550574506.18.0.940533407683.issue15248@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- pull_requests: +11957 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 06:23:24 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 Feb 2019 11:23:24 +0000 Subject: [issue35942] posixmodule.c:path_converter() returns an invalid exception message for broken PathLike objects In-Reply-To: <1549643679.09.0.475002054663.issue35942@roundup.psfhosted.org> Message-ID: <1550575404.61.0.554937232896.issue35942@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- pull_requests: +11958 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 06:24:56 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 Feb 2019 11:24:56 +0000 Subject: [issue35942] posixmodule.c:path_converter() returns an invalid exception message for broken PathLike objects In-Reply-To: <1549643679.09.0.475002054663.issue35942@roundup.psfhosted.org> Message-ID: <1550575496.39.0.207072827529.issue35942@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- pull_requests: -11956 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 06:26:25 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Feb 2019 11:26:25 +0000 Subject: [issue36026] Different error message when sys.settrace is used In-Reply-To: <1550513164.21.0.815390267137.issue36026@roundup.psfhosted.org> Message-ID: <1550575585.35.0.276678494879.issue36026@roundup.psfhosted.org> Change by STINNER Victor : ---------- nosy: -vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 06:27:22 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Feb 2019 11:27:22 +0000 Subject: [issue36012] Investigate slow writes to class variables In-Reply-To: <1550348118.4.0.228746523417.issue36012@roundup.psfhosted.org> Message-ID: <1550575642.88.0.0101608060328.issue36012@roundup.psfhosted.org> Change by STINNER Victor : ---------- nosy: -vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 06:30:14 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Feb 2019 11:30:14 +0000 Subject: [issue33944] Deprecate and remove pth files In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za> Message-ID: <1550575814.73.0.127450509758.issue33944@roundup.psfhosted.org> STINNER Victor added the comment: > 3. I realize that PEPs are needed for any change and even to define what that change might look like, but is there any value in adding PendingDeprecationWarnings for 3.8 if that's a possible action that will happen? As I understand it, it would be easier to remove that warning later instead of delaying any actions from it. We cannot modify Python before a PEP is approved. It's too early to see that a PEP removing support for .pth file will be approved or not. There are too many constraints and use cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 06:35:52 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Feb 2019 11:35:52 +0000 Subject: [issue1054041] Python doesn't exit with proper resultcode on SIGINT Message-ID: <1550576152.63.0.788573048941.issue1054041@roundup.psfhosted.org> STINNER Victor added the comment: > if (PyOS_setsig(SIGINT, SIG_DFL) == SIG_ERR) { > perror("signal"); /* Impossible in normal environments. */ In my experience, Python is were impossible things happen. Would it be possible to write a better error message to explain what happened? I expect that if PyOS_setsig() fails, the user cannot do much for that. It may be a bug in the libc and so cannot be fixed easily. Maybe we should simply ignore the error? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 06:44:02 2019 From: report at bugs.python.org (Michael Felt) Date: Tue, 19 Feb 2019 11:44:02 +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: <1550576642.01.0.638366941782.issue27632@roundup.psfhosted.org> Michael Felt added the comment: As far as 'master' is concerned, this has been resolved, so I'll close it myself. ---------- stage: -> resolved status: open -> closed versions: +Python 3.8 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 06:44:09 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 19 Feb 2019 11:44:09 +0000 Subject: [issue29515] socket module missing IPPROTO_IPV6, IPPROTO_IPV4 on Windows In-Reply-To: <1486664862.54.0.729311605676.issue29515@psf.upfronthosting.co.za> Message-ID: <1550576649.83.0.594739425385.issue29515@roundup.psfhosted.org> Giampaolo Rodola' added the comment: @eryksun I tried your patch (https://bugs.python.org/issue29515#msg287477) on Windows 10 and it looks good. It introduces the following new constants: IPPROTO_IGMP IPPROTO_GGP IPPROTO_PUP IPPROTO_IDP IPPROTO_ND IPPROTO_MAX IPPROTO_HOPOPTS IPPROTO_IPV4 IPPROTO_IPV6 IPPROTO_ROUTING IPPROTO_FRAGMENT IPPROTO_ESP IPPROTO_AH IPPROTO_ICMPV6 IPPROTO_NONE IPPROTO_DSTOPTS IPPROTO_EGP IPPROTO_PIM IPPROTO_SCTP ...plus these Windows-only ones for which I had to add an additional PyModule_AddIntMacro() call: IPPROTO_ICLFXBM IPPROTO_ST IPPROTO_CBT IPPROTO_IGP IPPROTO_RDP IPPROTO_PGM IPPROTO_L2TP Up 'till now only these ones were exposed: IPPROTO_ICMP IPPROTO_TCP IPPROTO_UDP IPPROTO_RAW I think we can proceed with this. Care to provide a patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 06:45:06 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Feb 2019 11:45:06 +0000 Subject: [issue29757] The loop in utility `socket.create_connection()` swallows previous errors In-Reply-To: <1488984317.87.0.296010902983.issue29757@psf.upfronthosting.co.za> Message-ID: <1550576706.89.0.312171380718.issue29757@roundup.psfhosted.org> STINNER Victor added the comment: I propose the close the issue as WONTFIX. I don't see how the current behavior is an issue. I expect a very large traceback just because a server is down/reject connections. I'm not sure that I want that by default. > ## The problem > So currently the loop in `socket.create_connection()` ignores all intermediate errors and reports only the last connection failure, which might be irrelevant. For instance, when both IPv4 & IPv6 networks are supported, usually the last address is a IPv6 address and it frequently fails with an irrelevant error - the actual cause have already been ignored. It's not so hard to reimplement create_connection(): it's a loop on getaddrinfo(). So you can decide how to deal with errors. -- I recall that Yury Selivanov, Nathnaniel Smith and Guido van Rossum discussed the idea of "MultiError": an object which contains multiple exceptions, object which would render properly all exceptions when a traceback is displayed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 06:46:54 2019 From: report at bugs.python.org (Michael Felt) Date: Tue, 19 Feb 2019 11:46:54 +0000 Subject: [issue35773] test_bdb fails on AIX bot (regression) In-Reply-To: <1547812678.96.0.834885366728.issue35773@roundup.psfhosted.org> Message-ID: <1550576814.01.0.422546048987.issue35773@roundup.psfhosted.org> Michael Felt added the comment: Again - after switching the env variable LANG to the 'default' everything works as expected. Leaving it open as a regression - because everything was working with a non-default setting. When I have more time I'll do a git bisect to try and establish the change where it went wrong. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 06:47:35 2019 From: report at bugs.python.org (INADA Naoki) Date: Tue, 19 Feb 2019 11:47:35 +0000 Subject: [issue36032] Wrong output in tutorial (3.1.2. Strings) In-Reply-To: <1550565934.5.0.314572203435.issue36032@roundup.psfhosted.org> Message-ID: <1550576855.88.0.561666134817.issue36032@roundup.psfhosted.org> INADA Naoki added the comment: @Amit Please confirm docs.python.org before submitting issue. #33460 fixed it already. ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 06:48:46 2019 From: report at bugs.python.org (INADA Naoki) Date: Tue, 19 Feb 2019 11:48:46 +0000 Subject: [issue36032] Wrong output in tutorial (3.1.2. Strings) In-Reply-To: <1550565934.5.0.314572203435.issue36032@roundup.psfhosted.org> Message-ID: <1550576926.04.0.40356654618.issue36032@roundup.psfhosted.org> INADA Naoki added the comment: Uh! You meant Python 2.7!! It doesn't make sense to improve Python 2.7 tutorial. If you're reading Python 2 tutorial, please read 3.7 tutorial instead!!! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 06:49:13 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 Feb 2019 11:49:13 +0000 Subject: [issue15248] Better explain "TypeError: 'tuple' object is not callable" In-Reply-To: <1341379722.78.0.0866285571225.issue15248@psf.upfronthosting.co.za> Message-ID: <1550576953.34.0.914918415257.issue15248@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset 8e79e6e56f516385ccb761e407dfff3a39253180 by Serhiy Storchaka in branch 'master': Fix syntax warnings in tests introduced in bpo-15248. (GH-11932) https://github.com/python/cpython/commit/8e79e6e56f516385ccb761e407dfff3a39253180 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 06:49:21 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 19 Feb 2019 11:49:21 +0000 Subject: [issue15248] Better explain "TypeError: 'tuple' object is not callable" In-Reply-To: <1341379722.78.0.0866285571225.issue15248@psf.upfronthosting.co.za> Message-ID: <1550576961.67.0.199728207547.issue15248@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11959 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 06:50:30 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 Feb 2019 11:50:30 +0000 Subject: [issue15248] Better explain "TypeError: 'tuple' object is not callable" In-Reply-To: <1341379722.78.0.0866285571225.issue15248@psf.upfronthosting.co.za> Message-ID: <1550577030.71.0.435984764149.issue15248@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- pull_requests: +11960 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 06:50:38 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 Feb 2019 11:50:38 +0000 Subject: [issue35942] posixmodule.c:path_converter() returns an invalid exception message for broken PathLike objects In-Reply-To: <1549643679.09.0.475002054663.issue35942@roundup.psfhosted.org> Message-ID: <1550577038.43.0.159515655692.issue35942@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- pull_requests: +11961 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 06:52:37 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 Feb 2019 11:52:37 +0000 Subject: [issue35942] posixmodule.c:path_converter() returns an invalid exception message for broken PathLike objects In-Reply-To: <1549643679.09.0.475002054663.issue35942@roundup.psfhosted.org> Message-ID: <1550577157.52.0.94149421957.issue35942@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset 8d01eb49fc7ff914feeb2e2090d1d6ef15c932ab by Serhiy Storchaka in branch 'master': Fix syntax warnings in tests introduced in bpo-35942. (GH-11934) https://github.com/python/cpython/commit/8d01eb49fc7ff914feeb2e2090d1d6ef15c932ab ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 06:55:22 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 19 Feb 2019 11:55:22 +0000 Subject: [issue35942] posixmodule.c:path_converter() returns an invalid exception message for broken PathLike objects In-Reply-To: <1549643679.09.0.475002054663.issue35942@roundup.psfhosted.org> Message-ID: <1550577322.46.0.00807989145428.issue35942@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11962 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 06:56:01 2019 From: report at bugs.python.org (Michael Felt) Date: Tue, 19 Feb 2019 11:56:01 +0000 Subject: [issue36034] Suprise halt caused by -Werror=implicit-function-declaration in ./Modules/posixmodule.c Message-ID: <1550577361.99.0.890870320024.issue36034@roundup.psfhosted.org> New submission from Michael Felt : On a system using an older version of gcc (v5.7.4) I get an error: (also AIX 6.1) gcc -pthread -Wno-unused-result -Wsign-compare -g -O0 -Wall -O -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -I./Include/internal -I. -I./Include -DPy_BUILD_CORE_BUILTIN -DPy_BUILD_CORE -I./Include/internal -c ./Modules/posixmodule.c -o Modules/posixmodule.o ./Modules/posixmodule.c: In function 'os_preadv_impl': ./Modules/posixmodule.c:8765:9: error: implicit declaration of function 'preadv' [-Werror=implicit-function-declaration] ./Modules/posixmodule.c: In function 'os_pwritev_impl': ./Modules/posixmodule.c:9336:9: error: implicit declaration of function 'pwritev' [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors On another system - same code base (commit e7a4bb554edb72fc6619d23241d59162d06f249a) no "error" status. (AIX 7.2) Not knowing gcc I have no idea which is correct - maybe they both are because the second system (where I am a guest) has an explicit declaration of these routines. Is there a flag I can add to gcc to get the "in-line" pre-processing output so I can look for differences with regard to these two functions? Thanks for hint. ---------- messages: 335936 nosy: Michael.Felt priority: normal severity: normal status: open title: Suprise halt caused by -Werror=implicit-function-declaration in ./Modules/posixmodule.c type: compile error versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 07:09:57 2019 From: report at bugs.python.org (=?utf-8?q?J=C3=B6rg_Stucke?=) Date: Tue, 19 Feb 2019 12:09:57 +0000 Subject: [issue36035] pathlib.Path().rglob() breaks with broken symlinks Message-ID: <1550578197.02.0.381973172531.issue36035@roundup.psfhosted.org> New submission from J?rg Stucke : When using rglob() to iterate over the files of a directory containing a broken symlink (a link pointing to itself) rglob breaks with "[Errno 40] Too many levels of symbolic links" (OS: Linux). Steps to reproduce: mkdir tmp touch foo ls -s foo tmp/foo cd tmp file foo foo: broken symbolic link to foo python3 >>> from pathlib import Path >>> for f in Path().rglob("*"): print(x) foo Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python3.8/pathlib.py", line 1105, in rglob for p in selector.select_from(self): File "/usr/local/lib/python3.8/pathlib.py", line 552, in _select_from for starting_point in self._iterate_directories(parent_path, is_dir, scandir): File "/usr/local/lib/python3.8/pathlib.py", line 536, in _iterate_directories entry_is_dir = entry.is_dir() OSError: [Errno 40] Too many levels of symbolic links: './foo' What is more, stat(), is_dir(), is_file() and exists() also do not like those broken links: >>> Path("foo").is_file() Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python3.8/pathlib.py", line 1361, in is_file return S_ISREG(self.stat().st_mode) File "/usr/local/lib/python3.8/pathlib.py", line 1151, in stat return self._accessor.stat(self) OSError: [Errno 40] Too many levels of symbolic links: 'foo' Is this intended behaviour or is this a bug? I guess it's not intended, since it makes it impossible to iterate over such a directory with rglob(). I could not find anything similar in the bug tracker, but https://bugs.python.org/issue26012 seems to be related. Tested with Python 3.8.0a1, 3.6.7 and 3.5.2 (OS: Linux Mint 19) ---------- components: Library (Lib) messages: 335937 nosy: J?rg Stucke priority: normal severity: normal status: open title: pathlib.Path().rglob() breaks with broken symlinks type: behavior versions: Python 3.5, Python 3.6, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 07:10:36 2019 From: report at bugs.python.org (Michael Felt) Date: Tue, 19 Feb 2019 12:10:36 +0000 Subject: [issue36034] Suprise halt caused by -Werror=implicit-function-declaration in ./Modules/posixmodule.c In-Reply-To: <1550577361.99.0.890870320024.issue36034@roundup.psfhosted.org> Message-ID: <1550578236.97.0.0530000657276.issue36034@roundup.psfhosted.org> Michael Felt added the comment: correction - gcc version is v4.7.4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 07:16:41 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 19 Feb 2019 12:16:41 +0000 Subject: [issue35942] posixmodule.c:path_converter() returns an invalid exception message for broken PathLike objects In-Reply-To: <1549643679.09.0.475002054663.issue35942@roundup.psfhosted.org> Message-ID: <1550578601.74.0.146965226891.issue35942@roundup.psfhosted.org> miss-islington added the comment: New changeset a8834905df853510f38d4e2d628bed8229fd7482 by Miss Islington (bot) in branch '3.7': Fix syntax warnings in tests introduced in bpo-35942. (GH-11934) https://github.com/python/cpython/commit/a8834905df853510f38d4e2d628bed8229fd7482 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 07:23:22 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 19 Feb 2019 12:23:22 +0000 Subject: [issue36035] pathlib.Path().rglob() breaks with broken symlinks In-Reply-To: <1550578197.02.0.381973172531.issue36035@roundup.psfhosted.org> Message-ID: <1550579002.69.0.197460772031.issue36035@roundup.psfhosted.org> St?phane Wirtel added the comment: I confirm this issue with python 3.7 but your script is wrong (you declare f and use x in your script) /tmp$ mkdir demo /tmp$ cd demo/ /t/demo$ mkdir tmp /t/demo$ touch foo /t/demo$ ln -s foo tmp/foo /t/demo$ cd tmp/ /t/d/tmp$ file foo foo: broken symbolic link to foo /t/d/tmp$ python3 mar 19 f?v 2019 13:20:15 CET Python 3.7.2 (default, Jan 16 2019, 19:49:22) [GCC 8.2.1 20181215 (Red Hat 8.2.1-6)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from pathlib import Path >>> for p in Path().rglob('*'): ... print(p) ... foo Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.7/pathlib.py", line 1105, in rglob for p in selector.select_from(self): File "/usr/lib64/python3.7/pathlib.py", line 552, in _select_from for starting_point in self._iterate_directories(parent_path, is_dir, scandir): File "/usr/lib64/python3.7/pathlib.py", line 536, in _iterate_directories entry_is_dir = entry.is_dir() OSError: [Errno 40] Too many levels of symbolic links: './foo' >>> ---------- nosy: +matrixise versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 07:23:33 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 19 Feb 2019 12:23:33 +0000 Subject: [issue36035] pathlib.Path().rglob() breaks with broken symlinks In-Reply-To: <1550578197.02.0.381973172531.issue36035@roundup.psfhosted.org> Message-ID: <1550579013.21.0.996382993738.issue36035@roundup.psfhosted.org> Change by St?phane Wirtel : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 07:33:09 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 19 Feb 2019 12:33:09 +0000 Subject: [issue36021] [Security][Windows] webbrowser: WindowsDefault uses os.startfile() and so can be abused to run arbitrary commands In-Reply-To: <1550487653.15.0.496398912417.issue36021@roundup.psfhosted.org> Message-ID: <1550579589.87.0.884221970118.issue36021@roundup.psfhosted.org> St?phane Wirtel added the comment: @vstinner, all the tests pass on AppVeyor and Travis, I check if the resource is local (file://) or not, and if the given path is a file (c:\\windows\\system32\\calc.exe), I check if this one is an executable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 07:43:50 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 19 Feb 2019 12:43:50 +0000 Subject: [issue36021] [Security][Windows] webbrowser: WindowsDefault uses os.startfile() and so can be abused to run arbitrary commands In-Reply-To: <1550487653.15.0.496398912417.issue36021@roundup.psfhosted.org> Message-ID: <1550580230.19.0.369204910392.issue36021@roundup.psfhosted.org> St?phane Wirtel added the comment: After a small test, os.access() on a text file is True, and it's wrong in my case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 07:53:41 2019 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 19 Feb 2019 12:53:41 +0000 Subject: [issue31506] Improve the error message logic for object_new & object_init In-Reply-To: <1505727849.07.0.595214817996.issue31506@psf.upfronthosting.co.za> Message-ID: <1550580821.24.0.0406159142577.issue31506@roundup.psfhosted.org> Nick Coghlan added the comment: Paolo: it still won't be completely clear, since there's still the subtle issue that __new__ is a static method rather than a class method, so the correct calls up to the base class are respectively: super(Singleton, cls).__new__(cls) # Static method, cls needs to be passed explicitly super(Singleton, self).__init__() # Bound method, self filled in automatically ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 08:06:20 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Tue, 19 Feb 2019 13:06:20 +0000 Subject: [issue36036] Add method to get user defined command line arguments in unittest.main Message-ID: <1550581580.85.0.535660142284.issue36036@roundup.psfhosted.org> New submission from R?mi Lapeyre : Hi, I'm working on issue 18765 (running pdb.post_mortem() on failing test cases) where I need to control the behavior of a TestCase based on some outside input. For this issue, I want to add a new --pdb option to turn this feature on when enabled. As of today, it seems to me that the command line arguments given to the TestProgram are not accessible from the TestCase. Would adding a new parameter to TestCase be breaking backward compatibility? If so, what would be a better way to access command line arguments from TestCase? In addition to this, I have the need for another project to change the behavior of TestCases based on a custom command line argument. I propose to add a new method `getCustomArguments` that will take the parser as input so the user can define it's own arguments by subclassing TestProgram What do you think about this? ---------- files: 0001-WIP.patch keywords: patch messages: 335944 nosy: remi.lapeyre priority: normal severity: normal status: open title: Add method to get user defined command line arguments in unittest.main Added file: https://bugs.python.org/file48154/0001-WIP.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 08:06:29 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Tue, 19 Feb 2019 13:06:29 +0000 Subject: [issue36036] Add method to get user defined command line arguments in unittest.main In-Reply-To: <1550581580.85.0.535660142284.issue36036@roundup.psfhosted.org> Message-ID: <1550581589.86.0.923306144018.issue36036@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- components: +Library (Lib) versions: +Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 08:23:53 2019 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 19 Feb 2019 13:23:53 +0000 Subject: [issue31506] Improve the error message logic for object_new & object_init In-Reply-To: <1505727849.07.0.595214817996.issue31506@psf.upfronthosting.co.za> Message-ID: <1550582633.04.0.0611690483128.issue31506@roundup.psfhosted.org> Nick Coghlan added the comment: New changeset 5105483acb3aca318304bed056dcfd7e188fe4b5 by Nick Coghlan (Sanyam Khurana) in branch 'master': bpo-31506: Clarify error messages for object.__new__ and object.__init__ (GH-11641) https://github.com/python/cpython/commit/5105483acb3aca318304bed056dcfd7e188fe4b5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 08:24:24 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 19 Feb 2019 13:24:24 +0000 Subject: [issue31506] Improve the error message logic for object_new & object_init In-Reply-To: <1505727849.07.0.595214817996.issue31506@psf.upfronthosting.co.za> Message-ID: <1550582664.28.0.804878041539.issue31506@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11963 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 08:47:15 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 19 Feb 2019 13:47:15 +0000 Subject: [issue31506] Improve the error message logic for object_new & object_init In-Reply-To: <1505727849.07.0.595214817996.issue31506@psf.upfronthosting.co.za> Message-ID: <1550584035.64.0.96804585763.issue31506@roundup.psfhosted.org> miss-islington added the comment: New changeset 64ca72822338e0ba6e4f14d0a1cd3a9dcfa6c9ac by Miss Islington (bot) in branch '3.7': bpo-31506: Clarify error messages for object.__new__ and object.__init__ (GH-11641) https://github.com/python/cpython/commit/64ca72822338e0ba6e4f14d0a1cd3a9dcfa6c9ac ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 08:48:34 2019 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 19 Feb 2019 13:48:34 +0000 Subject: [issue31506] Improve the error message logic for object_new & object_init In-Reply-To: <1505727849.07.0.595214817996.issue31506@psf.upfronthosting.co.za> Message-ID: <1550584114.18.0.88389234135.issue31506@roundup.psfhosted.org> Nick Coghlan added the comment: The revised behaviour now makes the error messages consistent with each other: >>> class TooManyArgs(): ... def __new__(cls): ... super().__new__(cls, 1) ... >>> TooManyArgs() Traceback (most recent call last): File "", line 1, in File "", line 3, in __new__ TypeError: object.__new__() takes exactly one argument (the type to instantiate) >>> class NotEnoughArgs(): ... def __new__(cls): ... super().__new__() ... >>> NotEnoughArgs() Traceback (most recent call last): File "", line 1, in File "", line 3, in __new__ TypeError: object.__new__(): not enough arguments >>> class TooManyInitArgs(): ... def __init__(self): ... super().__init__(1, 2, 3) ... >>> TooManyInitArgs() Traceback (most recent call last): File "", line 1, in File "", line 3, in __init__ TypeError: object.__init__() takes exactly one argument (the instance to initialize) >>> class NotEnoughInitArgs(): ... def __init__(self): ... object.__init__() ... >>> NotEnoughInitArgs() Traceback (most recent call last): File "", line 1, in File "", line 3, in __init__ TypeError: descriptor '__init__' of 'object' object needs an argument ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 09:05:00 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 19 Feb 2019 14:05:00 +0000 Subject: [issue36021] [Security][Windows] webbrowser: WindowsDefault uses os.startfile() and so can be abused to run arbitrary commands In-Reply-To: <1550487653.15.0.496398912417.issue36021@roundup.psfhosted.org> Message-ID: <1550585100.19.0.157376239593.issue36021@roundup.psfhosted.org> St?phane Wirtel added the comment: @vstinner Could we imagine to create a whitelist just for the html file? like that, we could open an html file and reject an executable file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 09:05:07 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 19 Feb 2019 14:05:07 +0000 Subject: [issue36021] [Security][Windows] webbrowser: WindowsDefault uses os.startfile() and so can be abused to run arbitrary commands In-Reply-To: <1550487653.15.0.496398912417.issue36021@roundup.psfhosted.org> Message-ID: <1550585107.76.0.235028382871.issue36021@roundup.psfhosted.org> Change by St?phane Wirtel : ---------- nosy: +mdk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 09:17:24 2019 From: report at bugs.python.org (Charalampos Stratakis) Date: Tue, 19 Feb 2019 14:17:24 +0000 Subject: [issue35925] test_httplib test_nntplib test_ssl fail on ARMv7 Debian buster bot (OpenSSL 1.1.1a) In-Reply-To: <1549503926.32.0.191493141556.issue35925@roundup.psfhosted.org> Message-ID: <1550585844.15.0.707496472202.issue35925@roundup.psfhosted.org> Charalampos Stratakis added the comment: Getting those failures on RHEL8 as well, which can be worked around by setting the env OPENSSL_CONF=/non-existing-file ====================================================================== ERROR: test_protocol_sslv23 (test.test_ssl.ThreadedTests) Connecting to an SSLv23 server with various client options ---------------------------------------------------------------------- Traceback (most recent call last): File "/root/cpython/_install/lib/python2.7/test/test_ssl.py", line 2370, in test_protocol_sslv23 try_protocol_combo(ssl.PROTOCOL_SSLv23, ssl.PROTOCOL_TLSv1, 'TLSv1') File "/root/cpython/_install/lib/python2.7/test/test_ssl.py", line 2103, in try_protocol_combo chatty=False, connectionchatty=False) File "/root/cpython/_install/lib/python2.7/test/test_ssl.py", line 2031, in server_params_test s.connect((HOST, server.port)) File "/root/cpython/_install/lib/python2.7/ssl.py", line 864, in connect self._real_connect(addr, False) File "/root/cpython/_install/lib/python2.7/ssl.py", line 855, in _real_connect self.do_handshake() File "/root/cpython/_install/lib/python2.7/ssl.py", line 828, in do_handshake self._sslobj.do_handshake() SSLError: [SSL: TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert protocol version (_ssl.c:727) ====================================================================== ERROR: test_protocol_tlsv1_1 (test.test_ssl.ThreadedTests) Connecting to a TLSv1.1 server with various client options. ---------------------------------------------------------------------- Traceback (most recent call last): File "/root/cpython/_install/lib/python2.7/test/test_ssl.py", line 2444, in test_protocol_tlsv1_1 try_protocol_combo(ssl.PROTOCOL_SSLv23, ssl.PROTOCOL_TLSv1_1, 'TLSv1.1') File "/root/cpython/_install/lib/python2.7/test/test_ssl.py", line 2103, in try_protocol_combo chatty=False, connectionchatty=False) File "/root/cpython/_install/lib/python2.7/test/test_ssl.py", line 2031, in server_params_test s.connect((HOST, server.port)) File "/root/cpython/_install/lib/python2.7/ssl.py", line 864, in connect self._real_connect(addr, False) File "/root/cpython/_install/lib/python2.7/ssl.py", line 855, in _real_connect self.do_handshake() File "/root/cpython/_install/lib/python2.7/ssl.py", line 828, in do_handshake self._sslobj.do_handshake() SSLError: [SSL: TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert protocol version (_ssl.c:727) ---------- nosy: +cstratak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 09:19:42 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Feb 2019 14:19:42 +0000 Subject: [issue36037] test_ssl fails on RHEL8 strict OpenSSL configuration Message-ID: <1550585982.05.0.862846003108.issue36037@roundup.psfhosted.org> New submission from STINNER Victor : RHEL8 uses a strict crypto policy by default. For example, SSLContext uses TLS 1.2 as the minimum version by default. Attached PR fix test_ssl for RHEL8. The PR is not specific to RHEL8. It should also fix test_ssl on Debian: see bpo-35925 and bpo-36005. test_ssl failures on RHEL8: ====================================================================== ERROR: test_PROTOCOL_TLS (test.test_ssl.ThreadedTests) Connecting to an SSLv23 server with various client options ---------------------------------------------------------------------- Traceback (most recent call last): File "/root/cpython-master/Lib/test/test_ssl.py", line 3079, in test_PROTOCOL_TLS try_protocol_combo(ssl.PROTOCOL_TLS, ssl.PROTOCOL_TLSv1, 'TLSv1') File "/root/cpython-master/Lib/test/test_ssl.py", line 2623, in try_protocol_combo stats = server_params_test(client_context, server_context, File "/root/cpython-master/Lib/test/test_ssl.py", line 2549, in server_params_test s.connect((HOST, server.port)) File "/root/cpython-master/Lib/ssl.py", line 1150, in connect self._real_connect(addr, False) File "/root/cpython-master/Lib/ssl.py", line 1141, in _real_connect self.do_handshake() File "/root/cpython-master/Lib/ssl.py", line 1117, in do_handshake self._sslobj.do_handshake() ssl.SSLError: [SSL: TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert protocol version (_ssl.c:1055) ====================================================================== ERROR: test_protocol_tlsv1_1 (test.test_ssl.ThreadedTests) Connecting to a TLSv1.1 server with various client options. ---------------------------------------------------------------------- Traceback (most recent call last): File "/root/cpython-master/Lib/test/test_ssl.py", line 3150, in test_protocol_tlsv1_1 try_protocol_combo(ssl.PROTOCOL_TLS, ssl.PROTOCOL_TLSv1_1, 'TLSv1.1') File "/root/cpython-master/Lib/test/test_ssl.py", line 2623, in try_protocol_combo stats = server_params_test(client_context, server_context, File "/root/cpython-master/Lib/test/test_ssl.py", line 2549, in server_params_test s.connect((HOST, server.port)) File "/root/cpython-master/Lib/ssl.py", line 1150, in connect self._real_connect(addr, False) File "/root/cpython-master/Lib/ssl.py", line 1141, in _real_connect self.do_handshake() File "/root/cpython-master/Lib/ssl.py", line 1117, in do_handshake self._sslobj.do_handshake() ssl.SSLError: [SSL: TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert protocol version (_ssl.c:1055) ====================================================================== FAIL: test_min_max_version (test.test_ssl.ContextTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/root/cpython-master/Lib/test/test_ssl.py", line 1093, in test_min_max_version self.assertIn( AssertionError: not found in {, } ---------------------------------------------------------------------- Ran 150 tests in 3.318s FAILED (failures=1, errors=2, skipped=9) ---------- assignee: christian.heimes components: SSL, Tests messages: 335950 nosy: christian.heimes, vstinner priority: normal severity: normal status: open title: test_ssl fails on RHEL8 strict OpenSSL configuration versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 09:23:17 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Feb 2019 14:23:17 +0000 Subject: [issue36037] test_ssl fails on RHEL8 strict OpenSSL configuration In-Reply-To: <1550585982.05.0.862846003108.issue36037@roundup.psfhosted.org> Message-ID: <1550586197.62.0.000100521865523.issue36037@roundup.psfhosted.org> Change by STINNER Victor : ---------- keywords: +patch pull_requests: +11964 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 09:32:04 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Feb 2019 14:32:04 +0000 Subject: [issue36037] test_ssl fails on RHEL8 strict OpenSSL configuration In-Reply-To: <1550585982.05.0.862846003108.issue36037@roundup.psfhosted.org> Message-ID: <1550586724.65.0.987529132021.issue36037@roundup.psfhosted.org> STINNER Victor added the comment: On Python 2.7.16rc, similar tests are failing on RHEL8: ERROR: test_protocol_sslv23 (test.test_ssl.ThreadedTests) ERROR: test_protocol_tlsv1_1 (test.test_ssl.ThreadedTests) ... But right now, Python 2.7 doesn't give access to minimum_version/maximum_version :-( Not even to read these versions. So I'm not sure how to skip or fix these tests, without backporting code for these attributes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 09:33:18 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Feb 2019 14:33:18 +0000 Subject: [issue36037] test_ssl fails on RHEL8 strict OpenSSL configuration In-Reply-To: <1550585982.05.0.862846003108.issue36037@roundup.psfhosted.org> Message-ID: <1550586798.13.0.0844480708623.issue36037@roundup.psfhosted.org> Change by STINNER Victor : ---------- nosy: +cstratak, gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 09:39:24 2019 From: report at bugs.python.org (Berry Schoenmakers) Date: Tue, 19 Feb 2019 14:39:24 +0000 Subject: [issue36027] Consider adding modular multiplicative inverse to the math module In-Reply-To: <1550520659.43.0.126744170658.issue36027@roundup.psfhosted.org> Message-ID: <1550587164.58.0.382920510296.issue36027@roundup.psfhosted.org> Berry Schoenmakers added the comment: Agreed, extending pow(value, n, modulus) to negative n would be a great addition! To have modinv(value, modulus) next to that also makes a lot of sense to me, as this would avoid lots of confusion among users who are not so experienced with modular arithmetic. I know from working with generations of students and programmers how easy it is to make mistakes here (including lots of mistakes that I made myself;) One would implement pow() for negative n, anyway, by first computing the modular inverse and then raising it to the power -n. So, to expose the modinv() function to the outside world won't cost much effort. Modular powers, in particular, are often very confusing. Like for a prime modulus p, all of pow(a, -1,p), pow(a, p-2, p), pow(a, -p, p) are equal to eachother, but a common mistake is to take pow(a, p-1, p) instead. For a composite modulus things get much trickier still, as the exponent is then reduced in terms of the Euler phi function. And, even if you are not confused by these things, it's still a bit subtle that you have to use pow(a, -1,p) instead of pow(a, p-2, p) to let the modular inverse be computed efficiently. With modinv() available separately, one would expect --and get-- an efficient implementation with minimal overhead (e.g., not implemented via a complete extended-gcd). ---------- nosy: +lschoe _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 09:41:06 2019 From: report at bugs.python.org (Louis Michael) Date: Tue, 19 Feb 2019 14:41:06 +0000 Subject: [issue36038] ^ used in inaccurate example in regex-howto Message-ID: <1550587266.8.0.644762310509.issue36038@roundup.psfhosted.org> New submission from Louis Michael : at https://docs.python.org/3/howto/regex.html#regex-howto and https://docs.python.org/3.8/howto/regex.html#regex-howto https://docs.python.org/3.7/howto/regex.html#regex-howto https://docs.python.org/3.6/howto/regex.html#regex-howto https://docs.python.org/3.5/howto/regex.html#regex-howto https://docs.python.org/3.4/howto/regex.html#regex-howto https://docs.python.org/2.7/howto/regex.html#regex-howto The following paragraph seems to have a small issue: " You can match the characters not listed within the class by complementing the set. This is indicated by including a '^' as the first character of the class; '^' outside a character class will simply match the '^' character. For example, [^5] will match any character except '5'. " ^ does not simply match ^ outside a character class since is a special character that represents the start of the string. I think the paragraph should read: You can match the characters not listed within the class by complementing the set. This is indicated by including a '^' as the first character of the class; '^' will act differently outside a character class as explained later. For example, [^5] will match any character except '5'. ---------- assignee: docs at python components: Documentation messages: 335953 nosy: docs at python, eric.araujo, ezio.melotti, louism, mdk, willingc priority: normal severity: normal status: open title: ^ used in inaccurate example in regex-howto type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 09:47:59 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Tue, 19 Feb 2019 14:47:59 +0000 Subject: [issue35126] Mistake in FAQ about converting number to string. In-Reply-To: <1541005659.07.0.788709270274.issue35126@psf.upfronthosting.co.za> Message-ID: <1550587679.31.0.35830373659.issue35126@roundup.psfhosted.org> Change by Cheryl Sabella : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 09:52:02 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 19 Feb 2019 14:52:02 +0000 Subject: [issue36021] [Security][Windows] webbrowser: WindowsDefault uses os.startfile() and so can be abused to run arbitrary commands In-Reply-To: <1550487653.15.0.496398912417.issue36021@roundup.psfhosted.org> Message-ID: <1550587922.74.0.569723101442.issue36021@roundup.psfhosted.org> St?phane Wirtel added the comment: @vstinner I have a whitelist where the HTML files (.html, .html, .dhtml, .xhtml, ...) are allowed. For the rest, I do not execute os.startfile() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 09:58:49 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Feb 2019 14:58:49 +0000 Subject: [issue36037] test_ssl fails on RHEL8 strict OpenSSL configuration In-Reply-To: <1550585982.05.0.862846003108.issue36037@roundup.psfhosted.org> Message-ID: <1550588329.81.0.265168142234.issue36037@roundup.psfhosted.org> STINNER Victor added the comment: > RHEL8 uses a strict crypto policy by default. For example, SSLContext uses TLS 1.2 as the minimum version by default. Ah, I forgot to mention that a workaround is to use OPENSSL_CONF=/ environment variable to ignore RHEL crypto policy (don't load system OpenSSL configuration). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 10:32:02 2019 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 19 Feb 2019 15:32:02 +0000 Subject: [issue36027] Consider adding modular multiplicative inverse to the math module In-Reply-To: <1550520659.43.0.126744170658.issue36027@roundup.psfhosted.org> Message-ID: <1550590322.49.0.739872280444.issue36027@roundup.psfhosted.org> Mark Dickinson added the comment: > it's still a bit subtle that you have to use pow(a, -1,p) instead of pow(a, p-2, p) to let the modular inverse be computed efficiently That's not 100% clear: the binary powering algorithm used to compute `pow(a, p-2, p)` is fairly efficient; the extended gcd algorithm used to compute the inverse may or may not end up being comparable. I certainly wouldn't be surprised to see `pow(a, p-2, p)` beat a pure Python xgcd for computing the inverse. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 10:50:06 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Feb 2019 15:50:06 +0000 Subject: [issue36021] [Security][Windows] webbrowser: WindowsDefault uses os.startfile() and so can be abused to run arbitrary commands In-Reply-To: <1550487653.15.0.496398912417.issue36021@roundup.psfhosted.org> Message-ID: <1550591406.05.0.521348929805.issue36021@roundup.psfhosted.org> STINNER Victor added the comment: Parsing an URL and deciding if an URL is "safe" or not is hard. For example, PR 11931 denies "file://" URLs, but I don't see the issue with opening such URL: file:///home/vstinner/prog/GIT/github.io/output/index.html (local path to a HTML file) The problem here is that os.startfile() can be abused to run arbitrary command. Another option would be to behave as Unix classes: run directly as specific browser like Chrome or Firefox. Maybe the registry can help? I found interesting keys: "HKEY_CURRENT_USER\Software\Classes\BSURL\shell\open\command" "HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice\Progid" "HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\https\UserChoice\Progid" "HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\ftp\UserChoice\Progid" "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.htm\UserChoice\Progid" "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.html\UserChoice\Progid" "HKEY_CURRENT_USER\Software\Clients\StartmenuInternet\" ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 10:50:45 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 19 Feb 2019 15:50:45 +0000 Subject: [issue36019] test_urllib fail in s390x buildbots: http://www.example.com/ In-Reply-To: <1550450495.08.0.90804425705.issue36019@roundup.psfhosted.org> Message-ID: <1550591445.59.0.818927208333.issue36019@roundup.psfhosted.org> St?phane Wirtel added the comment: ok for me if you prefer to use a function test with pythontest.net ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 10:52:17 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Feb 2019 15:52:17 +0000 Subject: [issue36021] [Security][Windows] webbrowser: WindowsDefault uses os.startfile() and so can be abused to run arbitrary commands In-Reply-To: <1550487653.15.0.496398912417.issue36021@roundup.psfhosted.org> Message-ID: <1550591537.65.0.703743627185.issue36021@roundup.psfhosted.org> STINNER Victor added the comment: PR 11931 experimented other tests: return os.path.isfile(path) and os.access(path, os.X_OK) and: is_exe = False with open(path, 'rb') as fp: s = fp.read(2) is_exe = s != b'MZ' return os.path.isfile(path) and is_exe I'm not sure that it's safe. Windows support a wide range of programs: .COM, .EXE, .VBS, .BAT, etc. It's hard to get a complete list. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 11:01:29 2019 From: report at bugs.python.org (SilentGhost) Date: Tue, 19 Feb 2019 16:01:29 +0000 Subject: [issue36033] logging.makeLogRecord should update "rv" using a dict defined with bytes instead of strings In-Reply-To: <1550573160.5.0.804221686367.issue36033@roundup.psfhosted.org> Message-ID: <1550592089.67.0.0557211379849.issue36033@roundup.psfhosted.org> Change by SilentGhost : ---------- components: +Library (Lib) nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 11:04:13 2019 From: report at bugs.python.org (Pander) Date: Tue, 19 Feb 2019 16:04:13 +0000 Subject: [issue34053] Support localization of unicode descriptions In-Reply-To: <1530787930.49.0.56676864532.issue34053@psf.upfronthosting.co.za> Message-ID: <1550592253.1.0.516407672369.issue34053@roundup.psfhosted.org> Pander added the comment: As discussed on python-ideas, created scripts at https://github.com/OpenTaal/python-unicodedata_l10n that provide a starting point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 11:05:09 2019 From: report at bugs.python.org (Lukas Geiger) Date: Tue, 19 Feb 2019 16:05:09 +0000 Subject: [issue36039] Replace append loops with list comprehensions Message-ID: <1550592309.68.0.760031675356.issue36039@roundup.psfhosted.org> New submission from Lukas Geiger : Lib uses loops to append to a new list in quite a few places. I think it would be better to replace those with list comprehensions. Benefits of this change: - List comprehensions are generally more readable than appending to a newly created list - List comprehensions are also a lot faster. Toy example: In [1]: %%timeit ...: l = [] ...: for i in range(5000): ...: l.append(i) 375 ?s ? 1.73 ?s per loop (mean ? std. dev. of 7 runs, 1000 loops each) In [2]: %%timeit ...: l = [i for i in range(5000)] 168 ?s ? 1.08 ?s per loop (mean ? std. dev. of 7 runs, 10000 loops each) Possible drawbacks: - Refactoring can always introduce bugs and makes it harder to get meaningful output from git blame. In this case I think the diff is very manageable, making the changes easy to review. Personally, I think the codebase would benefit from this change both in terms of some small performance gains and maintainability. I'd be happy to make a PR to fix this. ---------- components: Library (Lib) messages: 335961 nosy: lgeiger priority: normal severity: normal status: open title: Replace append loops with list comprehensions type: performance versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 11:11:39 2019 From: report at bugs.python.org (Paul Ganssle) Date: Tue, 19 Feb 2019 16:11:39 +0000 Subject: [issue36039] Replace append loops with list comprehensions In-Reply-To: <1550592309.68.0.760031675356.issue36039@roundup.psfhosted.org> Message-ID: <1550592699.46.0.363796212864.issue36039@roundup.psfhosted.org> Paul Ganssle added the comment: I think I'm -1 on a general project or policy to replace all for-append loops with list comprehensions, but I'm generally positive about individual improvements to the code base, on a case-by-case basis. I can't speak for anyone but myself, but I imagine that if you can identify a few places where this sort of change would make a significant performance improvement, it would be well-received. ---------- nosy: +p-ganssle _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 11:12:30 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 19 Feb 2019 16:12:30 +0000 Subject: [issue36019] test_urllib fail in s390x buildbots: http://www.example.com/ In-Reply-To: <1550450495.08.0.90804425705.issue36019@roundup.psfhosted.org> Message-ID: <1550592750.32.0.138253972629.issue36019@roundup.psfhosted.org> St?phane Wirtel added the comment: Here is the list of the external resources that we use in the tests. test_issue16464 (test.test_urllib2.MiscTests) ... skipped "Resource 'http://www.example.com/' is not available" test_close (test.test_urllib2net.CloseSocketTest) ... skipped "Resource 'http://www.example.com/' is not available" test_custom_headers (test.test_urllib2net.OtherNetworkTests) ... skipped "Resource 'http://www.example.com' is not available" test_sites_no_connection_close (test.test_urllib2net.OtherNetworkTests) ... skipped 'XXX: http://www.imdb.com is gone' test_http_basic (test.test_urllib2net.TimeoutTest) ... skipped "Resource 'http://www.example.com' is not available" test_http_default_timeout (test.test_urllib2net.TimeoutTest) ... skipped "Resource 'http://www.example.com' is not available" test_http_no_timeout (test.test_urllib2net.TimeoutTest) ... skipped "Resource 'http://www.example.com' is not available" test_http_timeout (test.test_urllib2net.TimeoutTest) ... skipped "Resource 'http://www.example.com' is not available" in the failed tests: test_urllib2 test_urllib2net test_urllibnet ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 11:16:32 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Feb 2019 16:16:32 +0000 Subject: [issue36037] test_ssl fails on RHEL8 strict OpenSSL configuration In-Reply-To: <1550585982.05.0.862846003108.issue36037@roundup.psfhosted.org> Message-ID: <1550592992.11.0.26385571539.issue36037@roundup.psfhosted.org> STINNER Victor added the comment: Python 2.7 and 3.6 have no SSLContext.minimum_version attribute (even with OpenSSL 1.1.1). I think that we will workaround this issue in Fedora and RHEL8 spec file (recipe to build RPM packages) using "export OPENSSL_CONF=/non-existing-file". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 11:18:55 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Feb 2019 16:18:55 +0000 Subject: [issue35153] Allow to set headers in xmlrpc.client.ServerProxy In-Reply-To: <1541244371.62.0.788709270274.issue35153@psf.upfronthosting.co.za> Message-ID: <1550593135.98.0.0355696686791.issue35153@roundup.psfhosted.org> STINNER Victor added the comment: New changeset beda52ed36e701e45f22903fc4d3bec0d085b25b by Victor Stinner (C?dric Krier) in branch 'master': bpo-35153: Add headers parameter to xmlrpc.client.ServerProxy (GH-10308) https://github.com/python/cpython/commit/beda52ed36e701e45f22903fc4d3bec0d085b25b ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 11:19:33 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Feb 2019 16:19:33 +0000 Subject: [issue35153] Allow to set headers in xmlrpc.client.ServerProxy In-Reply-To: <1541244371.62.0.788709270274.issue35153@psf.upfronthosting.co.za> Message-ID: <1550593173.37.0.00605343838468.issue35153@roundup.psfhosted.org> Change by STINNER Victor : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 11:22:17 2019 From: report at bugs.python.org (=?utf-8?q?J=C3=B6rg_Stucke?=) Date: Tue, 19 Feb 2019 16:22:17 +0000 Subject: [issue36035] pathlib.Path().rglob() breaks with broken symlinks In-Reply-To: <1550578197.02.0.381973172531.issue36035@roundup.psfhosted.org> Message-ID: <1550593337.95.0.86561348794.issue36035@roundup.psfhosted.org> J?rg Stucke added the comment: A possible solution for python 3.7+ could be to add "ELOOP" to _IGNORED_ERROS in pathlib but I'm not exactly sure of the side effects. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 11:23:12 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Feb 2019 16:23:12 +0000 Subject: [issue36021] [Security][Windows] webbrowser: WindowsDefault uses os.startfile() and so can be abused to run arbitrary commands In-Reply-To: <1550487653.15.0.496398912417.issue36021@roundup.psfhosted.org> Message-ID: <1550593392.23.0.0743168399033.issue36021@roundup.psfhosted.org> STINNER Victor added the comment: > After a small test, os.access() on a text file is True, and it's wrong in my case. os.access(path, os.X_OK) is specific to Unix. It doesn't make sense on Windows. os.access() is implemented with GetFileAttributesW() on Windows. The mode argument is more or less ignored. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 11:28:24 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Feb 2019 16:28:24 +0000 Subject: [issue35925] test_httplib test_nntplib test_ssl fail on ARMv7 Debian buster bot (OpenSSL 1.1.1a) In-Reply-To: <1549503926.32.0.191493141556.issue35925@roundup.psfhosted.org> Message-ID: <1550593704.29.0.924079313688.issue35925@roundup.psfhosted.org> STINNER Victor added the comment: I wrote a fix for bpo-36037 "test_ssl fails on RHEL8 strict OpenSSL configuration" which should fix test_ssl on Debian as well, but my change doesn't apply to Python 2.7 nor 3.6 since these Python versions lack SSLContext.minimum_version attribute (introduced in Python 3.7). https://docs.python.org/dev/library/ssl.html#ssl.SSLContext.minimum_version For Python 2.7 and 3.6, "export OPENSSL_CONF=/non-existing-file" is a workaround. Benjamin: > I agree that we need to be more resistant to system configuration, but it doesn't seem worth holding 2.7 up for. My fix requires SSLContext.minimum_version, but I'm not sure that it's ok to backport the attribute to Python 2.7 since Python 3.6 doesn't have it. IMHO "export OPENSSL_CONF=/non-existing-file" workaround is acceptable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 11:29:31 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 19 Feb 2019 16:29:31 +0000 Subject: [issue36019] test_urllib fail in s390x buildbots: http://www.example.com/ In-Reply-To: <1550450495.08.0.90804425705.issue36019@roundup.psfhosted.org> Message-ID: <1550593771.63.0.954661000199.issue36019@roundup.psfhosted.org> Change by St?phane Wirtel : ---------- keywords: +patch pull_requests: +11965 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 11:30:19 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 19 Feb 2019 16:30:19 +0000 Subject: [issue36019] test_urllib fail in s390x buildbots: http://www.example.com/ In-Reply-To: <1550450495.08.0.90804425705.issue36019@roundup.psfhosted.org> Message-ID: <1550593819.94.0.0995126801366.issue36019@roundup.psfhosted.org> St?phane Wirtel added the comment: @vstinner and @pablogsal I started to work on this issue, the PR is in WIP mode. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 11:32:05 2019 From: report at bugs.python.org (Berry Schoenmakers) Date: Tue, 19 Feb 2019 16:32:05 +0000 Subject: [issue36027] Consider adding modular multiplicative inverse to the math module In-Reply-To: <1550520659.43.0.126744170658.issue36027@roundup.psfhosted.org> Message-ID: <1550593925.9.0.734386966568.issue36027@roundup.psfhosted.org> Berry Schoenmakers added the comment: > ... to see `pow(a, p-2, p)` beat a pure Python xgcd for computing the inverse. OK, I'm indeed assuming that modinv() is implemented efficiently, in CPython, like pow() is. Then, it should be considerably faster, maybe like this: >>> timeit.timeit("gmpy2.invert(1023,p)", "import gmpy2; p=2**61-1") 0.18928535383349754 >>> timeit.timeit("gmpy2.invert(1023,p)", "import gmpy2; p=2**127-1") 0.290736872836419 >>> timeit.timeit("gmpy2.invert(1023,p)", "import gmpy2; p=2**521-1") 0.33174844290715555 >>> timeit.timeit("gmpy2.powmod(1023,p-2,p)", "import gmpy2; p=2**61-1") 0.8771009990597349 >>> timeit.timeit("gmpy2.powmod(1023,p-2,p)", "import gmpy2; p=2**127-1") 3.460449585430979 >>> timeit.timeit("gmpy2.powmod(1023,p-2,p)", "import gmpy2; p=2**521-1") 84.38728888797652 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 11:35:05 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 19 Feb 2019 16:35:05 +0000 Subject: [issue36039] Replace append loops with list comprehensions In-Reply-To: <1550592309.68.0.760031675356.issue36039@roundup.psfhosted.org> Message-ID: <1550594105.45.0.900327285623.issue36039@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Agreed with @p-ganssle . Similar issue33152 in the past for the refactoring in timeit module to use list comprehension. Large refactorings like this could also make git blame little more difficult in places where this has less benefit like smaller lists for common cases. I think it's much better to identify hot code paths with potentially large lists that could benefit from this along with a benchmark that could be accepted by the core dev/maintainer of the module. ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 11:35:21 2019 From: report at bugs.python.org (Julien Palard) Date: Tue, 19 Feb 2019 16:35:21 +0000 Subject: [issue36038] ^ used in inaccurate example in regex-howto In-Reply-To: <1550587266.8.0.644762310509.issue36038@roundup.psfhosted.org> Message-ID: <1550594121.67.0.564320949914.issue36038@roundup.psfhosted.org> Julien Palard added the comment: Hi, thanks for reporting! It's a duplicate of https://bugs.python.org/issue35584, so I'm closing it, but if you feed like opening a PR on it, it would be appreciated. Bests. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Wrong statement about ^ in howto/regex.rst _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 11:35:47 2019 From: report at bugs.python.org (Julien Palard) Date: Tue, 19 Feb 2019 16:35:47 +0000 Subject: [issue35584] Wrong statement about ^ in howto/regex.rst In-Reply-To: <1545775848.12.0.712150888896.issue35584@roundup.psfhosted.org> Message-ID: <1550594147.4.0.684870629696.issue35584@roundup.psfhosted.org> Change by Julien Palard : ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 11:39:28 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Tue, 19 Feb 2019 16:39:28 +0000 Subject: [issue36039] Replace append loops with list comprehensions In-Reply-To: <1550592309.68.0.760031675356.issue36039@roundup.psfhosted.org> Message-ID: <1550594368.94.0.363761905069.issue36039@roundup.psfhosted.org> R?mi Lapeyre added the comment: In some places, using a lot is also a deliberate choice to improve readability. I think the boy scout rule is more appropriate for such changes. ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 11:41:14 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Feb 2019 16:41:14 +0000 Subject: [issue36040] Python\ast.c(3875): warning C4244: 'initializing': conversion from 'Py_ssize_t' to 'int' Message-ID: <1550594474.58.0.925484616574.issue36040@roundup.psfhosted.org> New submission from STINNER Victor : Example on AMD64 Windows8.1 Non-Debug 3.x buildbot: https://buildbot.python.org/all/#/builders/12/builds/2024 2>d:\buildarea\3.x.ware-win81-release\build\python\ast.c(3875): warning C4244: 'initializing': conversion from 'Py_ssize_t' to 'int', possible loss of data [D:\buildarea\3.x.ware-win81-release\build\PCbuild\pythoncore.vcxproj] ---------- components: Windows messages: 335974 nosy: paul.moore, steve.dower, tim.golden, vstinner, zach.ware priority: normal severity: normal status: open title: Python\ast.c(3875): warning C4244: 'initializing': conversion from 'Py_ssize_t' to 'int' type: compile error versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 11:45:39 2019 From: report at bugs.python.org (Aaryn Tonita) Date: Tue, 19 Feb 2019 16:45:39 +0000 Subject: [issue36041] email: folding of quoted string in display_name violates RFC Message-ID: <1550594739.09.0.990893515193.issue36041@roundup.psfhosted.org> New submission from Aaryn Tonita : When using a policy for an EmailMessage that triggers folding (during serialization) of a fairly long display_name in an address field, the folding process removes the quotes from the display name breaking the semantics of the field. In particular, for a From address's display name like r'anything at anything.com ' + 'a' * MAX_LINE_LEN the folding puts anything at anything.com unquoted immediately after the From: header. For applications that do sender verification inside and then send it to an internal SMTP server that does not perform its own sender verification this could be considered a security issue since it enables sender spoofing. Receiving mail servers might be able to detect the broken header, but experiments show that the mail gets delivered. Simple demonstration (reproduced in attachment) of issue: SMTP_POLICY = email.policy.default.clone(linesep='\r\n', max_line_length=72) address = Address(display_name=r'anything at anything.com ' + 'a' * 72, addr_spec='dev at local.startmail.org') message = EmailMessage(policy=SMTP_POLICY) message['From'] = Address(display_name=display_name, addr_spec=addr_spec) # Trigger folding (via as_string()), then parse it back in. msg_string = message.as_string() msg_bytes = msg_string.encode('utf-8') msg_deserialized = BytesParser(policy=SMTP_POLICY).parsebytes(msg_bytes) # Verify badness from_hdr = msg_deserialized['From'] assert from_hdr != str(address) # But they should be equal... ---------- components: email files: address_folding_bug.py messages: 335975 nosy: aaryn.startmail, barry, r.david.murray priority: normal severity: normal status: open title: email: folding of quoted string in display_name violates RFC type: behavior versions: Python 3.5, Python 3.6, Python 3.7 Added file: https://bugs.python.org/file48155/address_folding_bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 11:49:13 2019 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 19 Feb 2019 16:49:13 +0000 Subject: [issue36027] Consider adding modular multiplicative inverse to the math module In-Reply-To: <1550520659.43.0.126744170658.issue36027@roundup.psfhosted.org> Message-ID: <1550594953.7.0.118041009846.issue36027@roundup.psfhosted.org> Mark Dickinson added the comment: > Then, it should be considerably faster Why would you expect that? Both algorithms involve a number of (bigint) operations that's proportional to log(p), so it's going to be down to the constants involved and the running times of the individual operations. Is there a clear reason for your expectation that the xgcd-based algorithm should be faster? Remember that Python has a subquadratic multiplication (via Karatsuba), but its division algorithm has quadratic running time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 11:53:10 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 19 Feb 2019 16:53:10 +0000 Subject: [issue33935] shutil.copyfile throws incorrect SameFileError on Google Drive File Stream In-Reply-To: <1529627906.69.0.56676864532.issue33935@psf.upfronthosting.co.za> Message-ID: <1550595190.4.0.392256255946.issue33935@roundup.psfhosted.org> Steve Dower added the comment: Would it make sense to add a parameter to _getfinalpathname that specifies the type of the path? For same[open]file(), we can probably just go to the most unreadable but broadly supported type, whereas the other functions that are actually going to return the path can work their way up through easiest-to-read options. I like the proposed logic for st_dev and st_ino, though I don't see any value in testing the drive name separately. At that point we've already gone to the filesystem driver, so any chances of doing it fast are gone and we may as well have simpler logic that goes straight to the full path. ---------- versions: -Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 11:57:54 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 19 Feb 2019 16:57:54 +0000 Subject: [issue36020] HAVE_SNPRINTF and MSVC std::snprintf support In-Reply-To: <1550485106.18.0.506219958256.issue36020@roundup.psfhosted.org> Message-ID: <1550595474.04.0.39608207219.issue36020@roundup.psfhosted.org> Steve Dower added the comment: We don't support older versions of MSVC at this point, so the version check seems unnecessary. If we need to alias these within the CPython sources for non-MSVC compilers, then we should do it in source files. In general, we never want to pollute the user's namespace with aliases like this - when we do, it should get a "_Py_" prefix and ideally be behind one of the Py_BUILD_CORE variables. So I'd rather see a change to remove those definitions from the header files and put them closer to where they belong. If that's too many places, they can go into an internal header with "_Py_" prefix and update all uses. ---------- versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 12:05:00 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 19 Feb 2019 17:05:00 +0000 Subject: [issue36021] [Security][Windows] webbrowser: WindowsDefault uses os.startfile() and so can be abused to run arbitrary commands In-Reply-To: <1550487653.15.0.496398912417.issue36021@roundup.psfhosted.org> Message-ID: <1550595900.62.0.0693052598991.issue36021@roundup.psfhosted.org> Steve Dower added the comment: The most I'd be okay with doing here is filtering for "://" in the webbrowser module, and not limiting "scheme" at all except that it must be a valid scheme. Windows allows apps and programs to extend protocol handling in HKEY_CLASSES_ROOT\PROTOCOLS\Handler and os.startfile() should respect this list, even while some browsers may handle more protocols that are not registered here. So there's really no way to limit the scheme sensibly. And yeah, anyone can take an arbitrary local or remote path and rewrite it as "file:///". That's a feature :) Perhaps we should add a warning to the docs that by default, webbrowser will open a URL with the user's associated program, and while this is generally the desirable behavior, if you want to enforce a particular browser then you should .get() it first? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 12:06:13 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Feb 2019 17:06:13 +0000 Subject: [issue36037] test_ssl fails on RHEL8 strict OpenSSL configuration In-Reply-To: <1550585982.05.0.862846003108.issue36037@roundup.psfhosted.org> Message-ID: <1550595973.88.0.888993450441.issue36037@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 3ef6344ee53f59ee86831ec36ed2c6f93a56229d by Victor Stinner in branch 'master': bpo-36037: Fix test_ssl for strict OpenSSL policy (GH-11940) https://github.com/python/cpython/commit/3ef6344ee53f59ee86831ec36ed2c6f93a56229d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 12:06:40 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 19 Feb 2019 17:06:40 +0000 Subject: [issue36037] test_ssl fails on RHEL8 strict OpenSSL configuration In-Reply-To: <1550585982.05.0.862846003108.issue36037@roundup.psfhosted.org> Message-ID: <1550596000.52.0.3564363598.issue36037@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11966 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 12:08:30 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 19 Feb 2019 17:08:30 +0000 Subject: [issue36040] Python\ast.c(3875): warning C4244: 'initializing': conversion from 'Py_ssize_t' to 'int' In-Reply-To: <1550594474.58.0.925484616574.issue36040@roundup.psfhosted.org> Message-ID: <1550596110.95.0.779849620667.issue36040@roundup.psfhosted.org> Steve Dower added the comment: Eh, just needs to change the local variable to Py_ssize_t. This applies to all platforms. Might be worth asserting that it is no bigger than the largest number of child tokens a node may have, but only if we have an arbitrary limit for that somewhere (I *believe* that's what it's doing here, but ast.c isn't a file that I understand well). ---------- keywords: +easy (C) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 12:08:49 2019 From: report at bugs.python.org (Au Vo) Date: Tue, 19 Feb 2019 17:08:49 +0000 Subject: [issue36028] Integer Division discrepancy with float In-Reply-To: <1550520914.92.0.84005909816.issue36028@roundup.psfhosted.org> Message-ID: <1550596129.68.0.551026895283.issue36028@roundup.psfhosted.org> Au Vo added the comment: thanks for the clarification. You have been a great help. Love Python and our supportive community! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 12:14:18 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 19 Feb 2019 17:14:18 +0000 Subject: [issue35941] ssl.enum_certificates() regression In-Reply-To: <1549637009.73.0.764067041861.issue35941@roundup.psfhosted.org> Message-ID: <1550596458.34.0.276220601321.issue35941@roundup.psfhosted.org> Steve Dower added the comment: The PR requires PEP 7 to be applied thoroughly, but I think the concept is sound enough. ---------- nosy: +nr _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 12:17:42 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 19 Feb 2019 17:17:42 +0000 Subject: [issue36011] ssl - tls verify on Windows fails In-Reply-To: <1550342172.09.0.390948819907.issue36011@roundup.psfhosted.org> Message-ID: <1550596662.69.0.950785041801.issue36011@roundup.psfhosted.org> Steve Dower added the comment: Thanks. This is a well-known and long-standing issue between OpenSSL and Windows, and the best workaround right now is to use the Mozilla certs directly. One day when OpenSSL is no longer part of the CPython public API, then we can consider switching to an HTTP implementation that uses the operating system support (which in my experimentation is 2-3x faster than using OpenSSL anyway, but a *big* breaking change for a lot of code). Until then, use the options provided by OpenSSL to enable it to verify what you need. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 12:19:55 2019 From: report at bugs.python.org (BTaskaya) Date: Tue, 19 Feb 2019 17:19:55 +0000 Subject: [issue36042] Setting __init_subclass__ and __class_getitem__ methods are in runtime doesnt make them class method. Message-ID: <1550596795.62.0.0325313661294.issue36042@roundup.psfhosted.org> New submission from BTaskaya : CPython only makes these methods class method when a class created. If you set __class_getitem__ method after the creation it doesn't work unless you use classmethod decorator manually. >>> class B: ... pass ... >>> def y(*a, **k): ... return a, k ... >>> B.__class_getitem__ = y >>> B[int] ((,), {}) >>> B.__class_getitem__ = classmethod(y) >>> B[int] ((, ), {}) ---------- messages: 335985 nosy: BTaskaya priority: normal severity: normal status: open title: Setting __init_subclass__ and __class_getitem__ methods are in runtime doesnt make them class method. type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 12:24:01 2019 From: report at bugs.python.org (BTaskaya) Date: Tue, 19 Feb 2019 17:24:01 +0000 Subject: [issue36042] Setting __init_subclass__ and __class_getitem__ methods are in runtime doesnt make them class method. In-Reply-To: <1550596795.62.0.0325313661294.issue36042@roundup.psfhosted.org> Message-ID: <1550597041.01.0.721949008719.issue36042@roundup.psfhosted.org> Change by BTaskaya : ---------- keywords: +patch pull_requests: +11967 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 12:24:21 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 19 Feb 2019 17:24:21 +0000 Subject: [issue36037] test_ssl fails on RHEL8 strict OpenSSL configuration In-Reply-To: <1550585982.05.0.862846003108.issue36037@roundup.psfhosted.org> Message-ID: <1550597060.99.0.728910505064.issue36037@roundup.psfhosted.org> miss-islington added the comment: New changeset e8bf04de4ba045029aa8964126d8cdd2d7c282a6 by Miss Islington (bot) in branch '3.7': bpo-36037: Fix test_ssl for strict OpenSSL policy (GH-11940) https://github.com/python/cpython/commit/e8bf04de4ba045029aa8964126d8cdd2d7c282a6 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 12:24:32 2019 From: report at bugs.python.org (Berry Schoenmakers) Date: Tue, 19 Feb 2019 17:24:32 +0000 Subject: [issue36027] Consider adding modular multiplicative inverse to the math module In-Reply-To: <1550520659.43.0.126744170658.issue36027@roundup.psfhosted.org> Message-ID: <1550597072.4.0.852159328905.issue36027@roundup.psfhosted.org> Berry Schoenmakers added the comment: > Is there a clear reason for your expectation that the xgcd-based algorithm should be faster? Yeah, good question. Maybe I'm assuming too much, like assuming that it should be faster;) It may depend a lot on the constants indeed, but ultimately the xgcd style should prevail. So the pow-based algorithm needs to do log(p) full-size muls, plus log(p) modular reductions. Karatsuba helps a bit to speed up the muls, but as far as I know it only kicks in for quite sizeable inputs. I forgot how Python is dealing with the modular reductions, but presumably that's done without divisions. The xgcd-based algorithm needs to do a division per iteration, but the numbers are getting smaller over the course of the algorithm. And, the worst-case behavior occurs for things involving Fibonacci numbers only. In any case, the overall bit complexity is quadratic, even if division is quadratic. There may be a few expensive divisions along the way, but these also reduce the numbers a lot in size, which leads to good amortized complexity for each iteration. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 12:29:16 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Feb 2019 17:29:16 +0000 Subject: [issue36037] test_ssl fails on RHEL8 strict OpenSSL configuration In-Reply-To: <1550585982.05.0.862846003108.issue36037@roundup.psfhosted.org> Message-ID: <1550597356.49.0.31942031125.issue36037@roundup.psfhosted.org> STINNER Victor added the comment: Ok, Python 3.7 and 3.8 (master) have been fixed. See bpo-35925 (and bpo-36005) for discussions on Python 2.7 and 3.6. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 12:29:59 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 19 Feb 2019 17:29:59 +0000 Subject: [issue36042] Setting __init_subclass__ and __class_getitem__ methods are in runtime doesnt make them class method. In-Reply-To: <1550596795.62.0.0325313661294.issue36042@roundup.psfhosted.org> Message-ID: <1550597399.69.0.699131591987.issue36042@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 12:41:38 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 19 Feb 2019 17:41:38 +0000 Subject: [issue36033] logging.makeLogRecord should update "rv" using a dict defined with bytes instead of strings In-Reply-To: <1550573160.5.0.804221686367.issue36033@roundup.psfhosted.org> Message-ID: <1550598098.39.0.4028727087.issue36033@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Sorry, I don't get the report. Can you please add a short reproducer script with a description of the current behavior and the expected behavior? ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 13:02:45 2019 From: report at bugs.python.org (Denton Liu) Date: Tue, 19 Feb 2019 18:02:45 +0000 Subject: [issue35155] Clarify Protocol Handlers in urllib.request Docs In-Reply-To: <1541286673.86.0.788709270274.issue35155@psf.upfronthosting.co.za> Message-ID: <1550599365.93.0.878666659161.issue35155@roundup.psfhosted.org> Denton Liu added the comment: If there aren't anymore comments, I think this PR is ready for a second round of reviews. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 13:16:41 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 19 Feb 2019 18:16:41 +0000 Subject: [issue35584] Wrong statement about ^ in howto/regex.rst In-Reply-To: <1545775848.12.0.712150888896.issue35584@roundup.psfhosted.org> Message-ID: <1550600201.49.0.386823248457.issue35584@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- assignee: docs at python -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 13:23:50 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 19 Feb 2019 18:23:50 +0000 Subject: [issue36019] test_urllib fail in s390x buildbots: http://www.example.com/ In-Reply-To: <1550450495.08.0.90804425705.issue36019@roundup.psfhosted.org> Message-ID: <1550600630.82.0.739647367831.issue36019@roundup.psfhosted.org> St?phane Wirtel added the comment: @vstinner I have fixed some URLs but we need to update pythontest.net for some tests. For example: test.test_urllib2.MiscTests.test_issue16464 raises a HTTP 405 and pythontest.net does not support the requested method. test_networked_trusted_by_default_cert (test.test_httplib.HTTPSTest) ... skipped "Resource 'www.python.org' is not available" test_logincapa (test.test_imaplib.RemoteIMAPTest) ... skipped "Resource 'cyrus.andrew.cmu.edu' is not available" test_logout (test.test_imaplib.RemoteIMAPTest) ... skipped "Resource 'cyrus.andrew.cmu.edu' is not available" test_logincapa (test.test_imaplib.RemoteIMAP_SSLTest) ... skipped "Resource 'cyrus.andrew.cmu.edu' is not available" test_logout (test.test_imaplib.RemoteIMAP_SSLTest) ... skipped "Resource 'cyrus.andrew.cmu.edu' is not available" test_logincapa (test.test_imaplib.RemoteIMAP_STARTTLSTest) ... skipped "Resource 'cyrus.andrew.cmu.edu' is not available" test_logout (test.test_imaplib.RemoteIMAP_STARTTLSTest) ... skipped "Resource 'cyrus.andrew.cmu.edu' is not available" skipped "Resource 'news.trigofacile.com' is not available" skipped "Resource 'nntp.aioe.org' is not available" test_connect (test.test_smtpnet.SmtpSSLTest) ... skipped "Resource 'smtp.gmail.com' is not available" test_connect_default_port (test.test_smtpnet.SmtpSSLTest) ... skipped "Resource 'smtp.gmail.com' is not available" test_connect_using_sslcontext (test.test_smtpnet.SmtpSSLTest) ... skipped "Resource 'smtp.gmail.com' is not available" test_connect_using_sslcontext_verified (test.test_smtpnet.SmtpSSLTest) ... skipped "Resource 'smtp.gmail.com' is not available" test_connect_starttls (test.test_smtpnet.SmtpTest) ... skipped "Resource 'smtp.gmail.com' is not available" test_get_server_certificate_ipv6 (test.test_ssl.NetworkedTests) ... skipped "Resource 'ipv6.google.com' is not available" test_idna (test.test_socket.GeneralModuleTests) ... skipped "Resource 'python.org' is not available" testAcceptTimeout (test.test_timeout.TCPTimeoutTestCase) ... skipped "Resource 'www.python.org.' is not available" testConnectTimeout (test.test_timeout.TCPTimeoutTestCase) ... skipped "Resource 'www.python.org.' is not available" testRecvTimeout (test.test_timeout.TCPTimeoutTestCase) ... skipped "Resource 'www.python.org.' is not available" testSend (test.test_timeout.TCPTimeoutTestCase) ... skipped "Resource 'www.python.org.' is not available" testSendall (test.test_timeout.TCPTimeoutTestCase) ... skipped "Resource 'www.python.org.' is not available" testSendto (test.test_timeout.TCPTimeoutTestCase) ... skipped "Resource 'www.python.org.' is not available" test_issue16464 (test.test_urllib2.MiscTests) ... skipped "Resource 'http://www.example.com/' is not available" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 13:25:57 2019 From: report at bugs.python.org (Neil Schemenauer) Date: Tue, 19 Feb 2019 18:25:57 +0000 Subject: [issue36012] Investigate slow writes to class variables In-Reply-To: <1550348118.4.0.228746523417.issue36012@roundup.psfhosted.org> Message-ID: <1550600757.71.0.329258669425.issue36012@roundup.psfhosted.org> Neil Schemenauer added the comment: Some profiling using 'perf'. This is for cpython 63fa1cfece4912110ce3a0ff11fb3ade3ff5e756. children self [...] + 97.27% 0.00% run_mod (inlined) + 88.53% 6.33% PyObject_SetAttr + 79.34% 6.80% type_setattro + 43.92% 43.92% update_slot + 26.87% 5.84% _PyObject_GenericSetAttrWithDict + 14.62% 6.52% insertdict + 8.80% 8.80% lookdict_unicode_nodummy + 6.57% 0.00% _Py_DECREF (inlined) + 5.19% 5.19% PyUnicode_InternInPlace + 3.57% 3.57% _PyObjectDict_SetItem + 3.38% 3.38% _PyType_Lookup + 1.71% 0.00% _Py_INCREF (inlined) + 1.42% 0.00% _Py_XDECREF (inlined) [...] After applying PR 11907: children self [...] + 94.76% 0.00% run_mod (inlined) + 75.22% 6.77% PyObject_SetAttr + 64.65% 13.08% type_setattro + 47.51% 11.96% _PyObject_GenericSetAttrWithDict + 22.99% 13.95% insertdict + 10.10% 10.10% lookdict_unicode_nodummy + 9.47% 9.47% PyUnicode_InternInPlace + 7.10% 7.10% _PyObjectDict_SetItem + 7.02% 7.02% _PyType_Lookup + 6.52% 0.00% _Py_DECREF (inlined) + 3.17% 0.00% _Py_INCREF (inlined) + 3.16% 0.00% _Py_XDECREF (inlined) + 2.59% 0.00% PyDict_SetItem (inlined) + 1.50% 0.00% is_dunder_name (inlined) [...] The PyUnicode_InternInPlace() can mostly be eliminated by testing PyUnicode_CHECK_INTERNED() first (we already have called PyUnicode_Check() on it). That only gives a 7% speedup on my machine though. The is_dunder_name() is a much bigger optimization. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 13:26:02 2019 From: report at bugs.python.org (Alexander Kapshuna) Date: Tue, 19 Feb 2019 18:26:02 +0000 Subject: [issue36043] FileCookieJar constructor don't accept PathLike Message-ID: <1550600762.69.0.583891908165.issue36043@roundup.psfhosted.org> New submission from Alexander Kapshuna : FileCookieJar and it's subclasses don't accept Paths and DirEntrys. Minimal code to reproduce: === import pathlib from http.cookiejar import FileCookieJar saved_cookies = pathlib.Path('my_cookies.txt') jar = FileCookieJar(saved_cookies) === Results in: "ValueError: filename must be string-like". Workaround is to convert Path explicitly or call load() which doesn't check for type, but it would be nice to see all APIs in standard library consistent. I also did quick and dirty patch which silently converts filename argument using os.fspath(). This way it won't break any existing code relying on FileCookieJar.filename being string. ---------- components: Library (Lib) files: cookiejar_straightforward_convert.patch keywords: patch messages: 335993 nosy: Alexander Kapshuna priority: normal severity: normal status: open title: FileCookieJar constructor don't accept PathLike type: enhancement versions: Python 3.6, Python 3.7, Python 3.8 Added file: https://bugs.python.org/file48156/cookiejar_straightforward_convert.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 13:27:48 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 19 Feb 2019 18:27:48 +0000 Subject: [issue36027] Consider adding modular multiplicative inverse to the math module In-Reply-To: <1550520659.43.0.126744170658.issue36027@roundup.psfhosted.org> Message-ID: <1550600868.25.0.514000814856.issue36027@roundup.psfhosted.org> Raymond Hettinger added the comment: > +1 for the pow(value, -1, modulus) spelling. It should raise > `ValueError` if `value` and `modulus` are not relatively prime. > It would feel odd to me _not_ to extend this to > `pow(value, n, modulus)` for all negative `n`, again > valid only only if `value` is relatively prime to `modulus`. I'll work up a PR using the simplest implementation. Once that's in with tests and docs, it's fair game for someone to propose algorithmic optimizations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 13:32:41 2019 From: report at bugs.python.org (Louis Michael) Date: Tue, 19 Feb 2019 18:32:41 +0000 Subject: [issue35584] Wrong statement about ^ in howto/regex.rst In-Reply-To: <1545775848.12.0.712150888896.issue35584@roundup.psfhosted.org> Message-ID: <1550601161.21.0.71372037296.issue35584@roundup.psfhosted.org> Change by Louis Michael : ---------- keywords: +patch pull_requests: +11968 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 13:34:16 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 19 Feb 2019 18:34:16 +0000 Subject: [issue29515] socket module missing IPPROTO_IPV6, IPPROTO_IPV4 on Windows In-Reply-To: <1486664862.54.0.729311605676.issue29515@psf.upfronthosting.co.za> Message-ID: <1550601256.71.0.638337753338.issue29515@roundup.psfhosted.org> Change by Gregory P. Smith : ---------- versions: +Python 3.8 -Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 13:35:45 2019 From: report at bugs.python.org (Neil Schemenauer) Date: Tue, 19 Feb 2019 18:35:45 +0000 Subject: [issue36012] Investigate slow writes to class variables In-Reply-To: <1550348118.4.0.228746523417.issue36012@roundup.psfhosted.org> Message-ID: <1550601345.16.0.40838180027.issue36012@roundup.psfhosted.org> Neil Schemenauer added the comment: BTW, 'perf report [...]' has a really neat annotated assembly view. Scroll to the function you are interested in and press 'a'. Press 't' to toggle the time units (left side numbers). I'm attaching a screenshot of the disassembly of the lookdict function. The time units are sample accounts. Each count is a point where the profiler woke up on that specific instruction. ---------- Added file: https://bugs.python.org/file48157/perf-screenshot.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 13:44:58 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 19 Feb 2019 18:44:58 +0000 Subject: [issue36043] FileCookieJar constructor don't accept PathLike In-Reply-To: <1550600762.69.0.583891908165.issue36043@roundup.psfhosted.org> Message-ID: <1550601898.02.0.35510983679.issue36043@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: This seems like a good change to me. GitHub PRs are accepted please see https://devguide.python.org/ . Since this is an enhancement it can only go as part of Python 3.8 if accepted. ---------- nosy: +xtreak versions: -Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 13:52:28 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 19 Feb 2019 18:52:28 +0000 Subject: [issue36043] FileCookieJar constructor don't accept PathLike In-Reply-To: <1550600762.69.0.583891908165.issue36043@roundup.psfhosted.org> Message-ID: <1550602348.27.0.587764215671.issue36043@roundup.psfhosted.org> St?phane Wirtel added the comment: @xtreak sorry, but I have already worked on this issue :/ can I publish my PR? ---------- nosy: +matrixise versions: +Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 13:54:44 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 19 Feb 2019 18:54:44 +0000 Subject: [issue36043] FileCookieJar constructor don't accept PathLike In-Reply-To: <1550600762.69.0.583891908165.issue36043@roundup.psfhosted.org> Message-ID: <1550602484.02.0.879375095252.issue36043@roundup.psfhosted.org> Change by St?phane Wirtel : ---------- pull_requests: +11969 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 13:55:40 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 19 Feb 2019 18:55:40 +0000 Subject: [issue36043] FileCookieJar constructor don't accept PathLike In-Reply-To: <1550600762.69.0.583891908165.issue36043@roundup.psfhosted.org> Message-ID: <1550602540.32.0.468744514555.issue36043@roundup.psfhosted.org> St?phane Wirtel added the comment: in fact, I have published my PR because I have already the tests and I have another approach for this issue. ---------- stage: patch review -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 14:04:09 2019 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 19 Feb 2019 19:04:09 +0000 Subject: [issue36033] logging.makeLogRecord should update "rv" using a dict defined with bytes instead of strings In-Reply-To: <1550573160.5.0.804221686367.issue36033@roundup.psfhosted.org> Message-ID: <1550603049.29.0.521233230626.issue36033@roundup.psfhosted.org> Vinay Sajip added the comment: If the arguments are retrieved from a byte source, why can't they be converted to strings before passing to logging? This may be an issue for OpenStack. It's not logging's job to convert bytes passed to APIs that expect strings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 14:08:53 2019 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 19 Feb 2019 19:08:53 +0000 Subject: [issue32363] Deprecate task.set_result() and task.set_exception() In-Reply-To: <1513594763.95.0.213398074469.issue32363@psf.upfronthosting.co.za> Message-ID: <1550603333.15.0.840002809486.issue32363@roundup.psfhosted.org> Chris Jerdonek added the comment: > Use Task.cancel() or use a Queue to communicate with the task. One reason why Task.cancel() is an incomplete replacement for Task.set_exception() is that you don't have an easy way to communicate why the task was ended. With set_exception() and set_result(), you could. Task.cancel(), though, doesn't let you e.g. specify a CancelledError subclass or "reason" string (see the related bpo-35674, "Add argument to .cancel() of Task and Future"). ---------- nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 14:10:01 2019 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 19 Feb 2019 19:10:01 +0000 Subject: [issue32363] Deprecate task.set_result() and task.set_exception() In-Reply-To: <1513594763.95.0.213398074469.issue32363@psf.upfronthosting.co.za> Message-ID: <1550603401.3.0.528169587741.issue32363@roundup.psfhosted.org> Chris Jerdonek added the comment: Correction: that should have been bpo-31033. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 14:14:14 2019 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 Feb 2019 19:14:14 +0000 Subject: [issue32363] Deprecate task.set_result() and task.set_exception() In-Reply-To: <1513594763.95.0.213398074469.issue32363@psf.upfronthosting.co.za> Message-ID: <1550603654.47.0.265700364416.issue32363@roundup.psfhosted.org> Yury Selivanov added the comment: > One reason why Task.cancel() is an incomplete replacement for Task.set_exception() is that you don't have an easy way to communicate why the task was ended. The result of the Task is bound to the result of the coroutine it wraps. If the coroutine raises an exception -- that's the exception of the Task object. If the coroutine returns a value -- that's the result value of the Task object. If the coroutine is cancelled via the "Task.cancel()" call -- asyncio.CancelledError is likely the result of the Task. Key rule: the wrapped coroutine dictates the result of the Task, not the other way around. The Task can signal cancellation, but even then, the final result is up to the coroutine. There's no clear reason to complicate the Task<->coroutine relationship by allowing to inject arbitrary exceptions into running coroutines. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 14:17:56 2019 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 19 Feb 2019 19:17:56 +0000 Subject: [issue32363] Deprecate task.set_result() and task.set_exception() In-Reply-To: <1513594763.95.0.213398074469.issue32363@psf.upfronthosting.co.za> Message-ID: <1550603876.3.0.487685408256.issue32363@roundup.psfhosted.org> Chris Jerdonek added the comment: A second reason why Task.cancel() seems to be an incomplete replacement: Task.set_exception() and Task.set_result() both give you a way to unconditionally end a task. With cancel() though, the docs say, "Task.cancel() does not guarantee that the Task will be cancelled." [1] The reason you might want to unconditionally end a task is if e.g. you already called Task.cancel() and it is still running after waiting a certain amount of time. [1]: https://docs.python.org/3/library/asyncio-task.html#asyncio.Task.cancel ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 14:26:43 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 19 Feb 2019 19:26:43 +0000 Subject: [issue35584] Wrong statement about ^ in howto/regex.rst In-Reply-To: <1545775848.12.0.712150888896.issue35584@roundup.psfhosted.org> Message-ID: <1550604403.42.0.0118948199812.issue35584@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- pull_requests: +11970 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 14:27:43 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 19 Feb 2019 19:27:43 +0000 Subject: [issue36021] [Security][Windows] webbrowser: WindowsDefault uses os.startfile() and so can be abused to run arbitrary commands In-Reply-To: <1550487653.15.0.496398912417.issue36021@roundup.psfhosted.org> Message-ID: <1550604463.85.0.190724358489.issue36021@roundup.psfhosted.org> St?phane Wirtel added the comment: @vstinner With the last commit, I don't test if the file is an executable but just if the extension is a .html file. For example, if you rename calc.exe by calc.html and you try to execute it in the default browser (via os.startfile()), you will get the content of the file in the browser. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 14:29:08 2019 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 19 Feb 2019 19:29:08 +0000 Subject: [issue32363] Deprecate task.set_result() and task.set_exception() In-Reply-To: <1513594763.95.0.213398074469.issue32363@psf.upfronthosting.co.za> Message-ID: <1550604548.41.0.137918521915.issue32363@roundup.psfhosted.org> Chris Jerdonek added the comment: > There's no clear reason to complicate the Task<->coroutine relationship by allowing to inject arbitrary exceptions into running coroutines. My comment was more about CancelledError rather than arbitrary exceptions. You didn't reply to the part of my response saying that Task.cancel() doesn't let you communicate why the task was ended, which is something the removed API's let you do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 14:32:21 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 19 Feb 2019 19:32:21 +0000 Subject: [issue35584] Wrong statement about ^ in howto/regex.rst In-Reply-To: <1545775848.12.0.712150888896.issue35584@roundup.psfhosted.org> Message-ID: <1550604741.78.0.347572197788.issue35584@roundup.psfhosted.org> miss-islington added the comment: New changeset 3bacf6126522a9b3bcb6be0c4f3ee6a895dfe772 by Miss Islington (bot) (Raymond Hettinger) in branch 'master': bpo-35584: Clarify role of caret in a class class (GH-11946) https://github.com/python/cpython/commit/3bacf6126522a9b3bcb6be0c4f3ee6a895dfe772 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 14:32:30 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 19 Feb 2019 19:32:30 +0000 Subject: [issue35584] Wrong statement about ^ in howto/regex.rst In-Reply-To: <1545775848.12.0.712150888896.issue35584@roundup.psfhosted.org> Message-ID: <1550604750.43.0.972876172776.issue35584@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11971 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 14:32:43 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 19 Feb 2019 19:32:43 +0000 Subject: [issue35584] Wrong statement about ^ in howto/regex.rst In-Reply-To: <1545775848.12.0.712150888896.issue35584@roundup.psfhosted.org> Message-ID: <1550604763.64.0.252606673305.issue35584@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11972 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 14:35:28 2019 From: report at bugs.python.org (Francis MB) Date: Tue, 19 Feb 2019 19:35:28 +0000 Subject: [issue35892] Fix awkwardness of statistics.mode() for multimodal datasets In-Reply-To: <1549219885.57.0.86866159357.issue35892@roundup.psfhosted.org> Message-ID: <1550604928.05.0.658249570744.issue35892@roundup.psfhosted.org> Francis MB added the comment: >> [...] This keeps the signature simple (Iterable -> Scalar). [...] >> >> Categorical, binned, or ordinal data: >> >> mode(data: Iterable, *, first_tie=False) -> object >> multimode(data: Iterable) -> List[object] This seems reasonable to me due legacy (although I really thing that multimode is just the real thing :-) ) >> Continuous data: >> mode(data: Iterable[Real]) -> Real What should return in that case: E.g.: mode([42.0, 42.0, 42.0, 1.0, 1.0, 1.0]) ? 42.0 ? or 1.0 ? or [42.0, 1.0] ? or do I have misunderstood something ? Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 14:38:31 2019 From: report at bugs.python.org (Michael Selik) Date: Tue, 19 Feb 2019 19:38:31 +0000 Subject: [issue36018] Add a Normal Distribution class to the statistics module In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org> Message-ID: <1550605111.59.0.639303690147.issue36018@roundup.psfhosted.org> Michael Selik added the comment: +1, This would be useful for quick analyses, avoiding the overhead of installing scipy and looking through its documentation. Given that it's in the statistics namespace, I think the name can be simply ``Normal`` rather than ``NormalDist``. Also, instead of ``.from_examples`` consider naming the classmethod ``.fit``. ---------- nosy: +selik _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 14:54:20 2019 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 Feb 2019 19:54:20 +0000 Subject: [issue32363] Deprecate task.set_result() and task.set_exception() In-Reply-To: <1513594763.95.0.213398074469.issue32363@psf.upfronthosting.co.za> Message-ID: <1550606060.54.0.648293204998.issue32363@roundup.psfhosted.org> Yury Selivanov added the comment: >> There's no clear reason to complicate the Task<->coroutine relationship by allowing to inject arbitrary exceptions into running coroutines. > My comment was more about CancelledError rather than arbitrary exceptions. You didn't reply to the part of my response saying that Task.cancel() doesn't let you communicate why the task was ended, [..] I didn't reply because you didn't clearly articulate why the cancellation reason is important :) AFAIK no other async framework allows you to do this. So what are those real-world cases that can explain why asyncio should support this functionality? > [..] which is something the removed API's let you do. Unfortunately they didn't. They never worked properly; IIRC Task.set_exception had never worked at all. The fact they were available at all was a simple oversight. > Task.set_exception() and Task.set_result() both give you a way to unconditionally end a task. With cancel() though, the docs say, "Task.cancel() does not guarantee that the Task will be cancelled." [1] Yes, because Task can only signal its coroutine that it was requested to be cancelled. The coroutine may choose to ignore that by swallowing CancelledError. > The reason you might want to unconditionally end a task is if e.g. you already called Task.cancel() and it is still running after waiting a certain amount of time. Well, if you want to unconditionally end tasks you shouldn't write coroutines that ignore CancelledErrors. If you do, then you clearly *do not want* the coroutine to be cancelled, and thus there's no use case for set_exception. Finally, asyncio has queues, which can be used to build two-way communication channels between coroutines and implement whatever advanced cancellation mechanism you want. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 14:55:24 2019 From: report at bugs.python.org (R. David Murray) Date: Tue, 19 Feb 2019 19:55:24 +0000 Subject: [issue36041] email: folding of quoted string in display_name violates RFC In-Reply-To: <1550594739.09.0.990893515193.issue36041@roundup.psfhosted.org> Message-ID: <1550606124.64.0.580455382319.issue36041@roundup.psfhosted.org> R. David Murray added the comment: Since Address itself renders it correctly (str(address)), the problem is going to take a bit of digging to find. I'm guessing the quoted_string atom is getting transformed incorrectly into something else at some point during the folding. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 14:57:46 2019 From: report at bugs.python.org (nr) Date: Tue, 19 Feb 2019 19:57:46 +0000 Subject: [issue35941] ssl.enum_certificates() regression In-Reply-To: <1549637009.73.0.764067041861.issue35941@roundup.psfhosted.org> Message-ID: <1550606266.44.0.409773735206.issue35941@roundup.psfhosted.org> nr added the comment: Adjusted the code to conform with PEP 7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 14:59:59 2019 From: report at bugs.python.org (Tim Peters) Date: Tue, 19 Feb 2019 19:59:59 +0000 Subject: [issue36027] Consider adding modular multiplicative inverse to the math module In-Reply-To: <1550520659.43.0.126744170658.issue36027@roundup.psfhosted.org> Message-ID: <1550606399.4.0.457137990535.issue36027@roundup.psfhosted.org> Tim Peters added the comment: Raymond, I doubt we can do better (faster) than straightforward egcd without heroic effort anyway. We can't even know whether a modular inverse exists without checking whether the gcd is 1, and egcd builds on what we have to do for the latter anyway. Even if we did know in advance that a modular inverse exists, using modular exponentiation to find it requires knowing the totient of the modulus, and computing the totient is believed to be no easier than factoring. The only "optimization" I'd be inclined to _try_ for Python's use is an extended binary gcd algorithm (which requires no bigint multiplies or divides, the latter of which is especially sluggish in Python): https://www.ucl.ac.uk/~ucahcjm/combopt/ext_gcd_python_programs.pdf For the rest: - I'd also prefer than negative exponents other than -1 be supported. It's just that -1 by itself gets 95% of the value. - It's fine by me if `pow(a, -1, m)` is THE way to spell modular inverse. Adding a distinct `modinv()` function too strikes me as redundnt clutter, but not damaging enough to be worth whining about. So -0 on that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 15:07:03 2019 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 19 Feb 2019 20:07:03 +0000 Subject: [issue32363] Deprecate task.set_result() and task.set_exception() In-Reply-To: <1513594763.95.0.213398074469.issue32363@psf.upfronthosting.co.za> Message-ID: <1550606823.5.0.00179606444249.issue32363@roundup.psfhosted.org> Chris Jerdonek added the comment: > Well, if you want to unconditionally end tasks you shouldn't write coroutines that ignore CancelledErrors. Well, of course. But code can have bugs, and maybe you didn't write the coroutine because it's from a library that you don't control. In that case, you should still be able to end the task. Also, maybe the coroutine doesn't have a bug but the cancellation is just taking longer than you have time for, so you want to end it early. > So what are those real-world cases that can explain why asyncio should support this functionality? The case I had in mind was the one I referenced above -- being able to distinguish a normal CancelledError from one where you had interrupt the cancellation (i.e. cancellation timing out). I would like the caller to be able to know when the latter are happening. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 15:22:58 2019 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 19 Feb 2019 20:22:58 +0000 Subject: [issue32363] Deprecate task.set_result() and task.set_exception() In-Reply-To: <1513594763.95.0.213398074469.issue32363@psf.upfronthosting.co.za> Message-ID: <1550607778.39.0.180683899459.issue32363@roundup.psfhosted.org> Andrew Svetlov added the comment: I agree with Yuri. `Task.set_exception()` (let's assume it works) is very dangerous: if cancellation exception doesn't bubble up from coroutine code there is a very high chance to get broken invariants and not-released resources. The same situation is possible with classic threads: killing a thread without unwinding a call stack leads to locked mutexes etc. Regarding distinguishing explicit cancellation from timeout exhausting: it can be done with current asyncio design by using a flag. Take a look on async_timeout context manager, __aexit__() implementation: https://github.com/aio-libs/async-timeout/blob/master/async_timeout/__init__.py#L88-L97 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 15:25:56 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 19 Feb 2019 20:25:56 +0000 Subject: [issue35584] Wrong statement about ^ in howto/regex.rst In-Reply-To: <1545775848.12.0.712150888896.issue35584@roundup.psfhosted.org> Message-ID: <1550607956.8.0.970389468842.issue35584@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset bb9ddee3d4e293f0717f8c167afdf5749ebf843d by Raymond Hettinger (Miss Islington (bot)) in branch '3.7': bpo-35584: Clarify role of caret in a class class (GH-11946) (GH-11947) https://github.com/python/cpython/commit/bb9ddee3d4e293f0717f8c167afdf5749ebf843d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 15:26:13 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 19 Feb 2019 20:26:13 +0000 Subject: [issue35584] Wrong statement about ^ in howto/regex.rst In-Reply-To: <1545775848.12.0.712150888896.issue35584@roundup.psfhosted.org> Message-ID: <1550607973.51.0.994651453001.issue35584@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 6ee41793d2204c54bdf8f477ae61d016a7eca932 by Raymond Hettinger (Miss Islington (bot)) in branch '2.7': bpo-35584: Clarify role of caret in a class class (GH-11946) (GH-11948) https://github.com/python/cpython/commit/6ee41793d2204c54bdf8f477ae61d016a7eca932 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 15:26:45 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 19 Feb 2019 20:26:45 +0000 Subject: [issue35584] Wrong statement about ^ in howto/regex.rst In-Reply-To: <1545775848.12.0.712150888896.issue35584@roundup.psfhosted.org> Message-ID: <1550608005.44.0.798645709247.issue35584@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 15:29:45 2019 From: report at bugs.python.org (Alexey Izbyshev) Date: Tue, 19 Feb 2019 20:29:45 +0000 Subject: [issue36034] Suprise halt caused by -Werror=implicit-function-declaration in ./Modules/posixmodule.c In-Reply-To: <1550577361.99.0.890870320024.issue36034@roundup.psfhosted.org> Message-ID: <1550608185.88.0.0973450009509.issue36034@roundup.psfhosted.org> Alexey Izbyshev added the comment: I don't know what you mean by "in-line" pre-processing output, but you can use -E option to get the normal preprocessor output. Line directives will tell you where those functions come from on a system where there is no compilation error. Of course, if those functions are defined in some other headers on AIX 6.1, it won't help you, so you might as well just grep /usr/include :) ---------- nosy: +izbyshev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 15:39:50 2019 From: report at bugs.python.org (Neil Schemenauer) Date: Tue, 19 Feb 2019 20:39:50 +0000 Subject: [issue36044] PROFILE_TASK for PGO build is not a good workload Message-ID: <1550608790.89.0.306917505619.issue36044@roundup.psfhosted.org> New submission from Neil Schemenauer : I was doing some 'perf' profiling runs of Python. I decided to try running PROFILE_TASK to see what the profile looks like. I was surprised that gc_collect dominated runtime: Children Self Symbol + 93.93% 6.00% [.] _PyEval_EvalFrameDefault + 76.19% 0.12% [.] function_code_fastcall + 70.65% 0.31% [.] _PyMethodDef_RawFastCallKeywords + 63.24% 0.13% [.] _PyCFunction_FastCallKeywords + 58.67% 0.36% [.] _PyEval_EvalCodeWithName + 57.45% 23.84% [.] collect + 52.89% 0.00% [.] gc_collect + 52.10% 0.08% [.] _PyFunction_FastCallDict + 41.99% 0.02% [.] _PyObject_Call_Prepend + 36.37% 0.18% [.] _PyFunction_FastCallKeywords + 20.94% 0.07% [.] _PyObject_FastCallDict + 19.64% 0.00% [.] PyObject_Call + 17.74% 0.11% [.] _PyObject_FastCallKeywords + 12.45% 0.00% [.] slot_tp_call + 12.27% 4.05% [.] dict_traverse + 11.45% 11.04% [.] visit_reachable + 11.18% 10.76% [.] visit_decref + 9.65% 0.11% [.] type_call + 8.80% 0.83% [.] func_traverse + 7.78% 0.08% [.] _PyMethodDescr_FastCallKeywords Part of the problem is that we run full cyclic GC for every test. I.e. cleanup_test_droppings() calls gc.collect(). Maybe we could make these calls conditional on the --pgo flag of regtest. Or, maybe we need to re-evaluate if running the unit test suite is the best way to generate PGO trace data. Based on a tiny bit of further investigation, it looks like gc_collect() is getting called quite a lot of times, in addition to cleanup_test_droppings(). Maybe there is some low-hanging fruit here for optimization. Full GC is pretty expensive. ---------- messages: 336018 nosy: nascheme priority: normal severity: normal status: open title: PROFILE_TASK for PGO build is not a good workload type: performance _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 15:43:46 2019 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 19 Feb 2019 20:43:46 +0000 Subject: [issue32363] Deprecate task.set_result() and task.set_exception() In-Reply-To: <1513594763.95.0.213398074469.issue32363@psf.upfronthosting.co.za> Message-ID: <1550609026.19.0.387576366388.issue32363@roundup.psfhosted.org> Chris Jerdonek added the comment: To stop the discussion from happening in two places (sorry, Yury), I started a broader discussion on Async-sig with thread starting here: https://mail.python.org/pipermail/async-sig/2019-February/000548.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 15:59:46 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 19 Feb 2019 20:59:46 +0000 Subject: [issue36044] PROFILE_TASK for PGO build is not a good workload In-Reply-To: <1550608790.89.0.306917505619.issue36044@roundup.psfhosted.org> Message-ID: <1550609986.72.0.470800281685.issue36044@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: Also, the test suite exercises a lot of branches (like passing incorrect types to function to check errors) that will hurt the branch prediction that PGO generates. ---------- nosy: +pablogsal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 17:17:41 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Tue, 19 Feb 2019 22:17:41 +0000 Subject: [issue36042] Setting __init_subclass__ and __class_getitem__ methods are in runtime doesnt make them class method. In-Reply-To: <1550596795.62.0.0325313661294.issue36042@roundup.psfhosted.org> Message-ID: <1550614661.15.0.20990672264.issue36042@roundup.psfhosted.org> R?mi Lapeyre added the comment: Is this an issue though? Shouldn't methods be defined in the class definition, we don't expect setting a function as an attribute to a class to transform it automatically to a method. Why would we special case __class_getitem__ and not __init_subclass__? ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 17:34:59 2019 From: report at bugs.python.org (Nic Watson) Date: Tue, 19 Feb 2019 22:34:59 +0000 Subject: [issue35945] Cannot distinguish between subtask cancellation and running task cancellation In-Reply-To: <1549660576.62.0.347711337086.issue35945@roundup.psfhosted.org> Message-ID: <1550615699.68.0.686857713556.issue35945@roundup.psfhosted.org> Nic Watson added the comment: Excellent answer by twisteroid Ambassador. Resolved ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 17:53:00 2019 From: report at bugs.python.org (Jens Troeger) Date: Tue, 19 Feb 2019 22:53:00 +0000 Subject: [issue30717] Add unicode grapheme cluster break algorithm In-Reply-To: <1497986122.28.0.540580196076.issue30717@psf.upfronthosting.co.za> Message-ID: <1550616780.09.0.406031958628.issue30717@roundup.psfhosted.org> Change by Jens Troeger : ---------- nosy: +_savage _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 17:53:17 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 19 Feb 2019 22:53:17 +0000 Subject: [issue36040] Python\ast.c(3875): warning C4244: 'initializing': conversion from 'Py_ssize_t' to 'int' In-Reply-To: <1550594474.58.0.925484616574.issue36040@roundup.psfhosted.org> Message-ID: <1550616797.5.0.648775033738.issue36040@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- keywords: +patch pull_requests: +11973 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 17:54:30 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 19 Feb 2019 22:54:30 +0000 Subject: [issue36040] Python\ast.c(3875): warning C4244: 'initializing': conversion from 'Py_ssize_t' to 'int' In-Reply-To: <1550594474.58.0.925484616574.issue36040@roundup.psfhosted.org> Message-ID: <1550616870.38.0.948890155132.issue36040@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: Fixed with commit https://github.com/python/cpython/commit/46a97920feaf4094436b2cdb32d2bd2fab3b59a5 ---------- nosy: +pablogsal resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 18:29:31 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 19 Feb 2019 23:29:31 +0000 Subject: [issue1054041] Python doesn't exit with proper resultcode on SIGINT Message-ID: <1550618971.22.0.440702368589.issue1054041@roundup.psfhosted.org> Gregory P. Smith added the comment: i'm curious if this _ever_ comes up so i'd like to leave it in at least through some betas. I don't believe it should be possible. If it is, it'd probably be a restricted execution environment that fails all signal() calls. all perror will do is emit an error message to that effect before continuing so we still exit with an error code as the final fallback. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 18:36:27 2019 From: report at bugs.python.org (Dan Rose) Date: Tue, 19 Feb 2019 23:36:27 +0000 Subject: [issue36045] Help function is not much help with async functions Message-ID: <1550619387.23.0.907293710235.issue36045@roundup.psfhosted.org> New submission from Dan Rose : It is very important when using a callable to know whether it is async or not. It is expected that `builtins.help` function should provide the information needed to properly use the function, but it omits whether it is an async function or not. ``` import asyncio def the_answer(): return 42 async def the_answer2(): await asyncio.sleep(100) return the_answer() ``` ``` >>> help(the_answer) Help on function the_answer in module __main__: the_answer() >>> help(the_answer2) Help on function the_answer2 in module __main__: the_answer2() ``` Note there is no way to tell whether the result of the function needs to be awaited. In the similar case of generator functions versus regular functions, one obvious solution is to add a type annotation. That doesn't work here, since PEP-0484 indicates that the correct annotation for a coroutine function is the type that is awaited, not the coroutine object created when the function is called. ``` import typing def non_answers() -> typing.Iterable[int]: yield from range(42) >>> help(non_answers) Help on function non_answers in module __main__: non_answers() -> Iterable[int] ``` One awkward workaround is to wrap the coroutine function in a regular function: ``` def the_answer3() -> typing.Awaitable[int]: return the_answer2() >>> help(the_answer3) Help on function the_answer3 in module __main__: the_answer3() -> Awaitable[int] ``` ---------- components: asyncio messages: 336025 nosy: Dan Rose, asvetlov, yselivanov priority: normal severity: normal status: open title: Help function is not much help with async functions versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 18:39:47 2019 From: report at bugs.python.org (Dan Rose) Date: Tue, 19 Feb 2019 23:39:47 +0000 Subject: [issue36045] builtins.help function is not much help with async functions In-Reply-To: <1550619387.23.0.907293710235.issue36045@roundup.psfhosted.org> Message-ID: <1550619587.54.0.314519775768.issue36045@roundup.psfhosted.org> Change by Dan Rose : ---------- title: Help function is not much help with async functions -> builtins.help function is not much help with async functions _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 18:40:31 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 19 Feb 2019 23:40:31 +0000 Subject: [issue36042] Setting __init_subclass__ and __class_getitem__ methods are in runtime doesnt make them class method. In-Reply-To: <1550596795.62.0.0325313661294.issue36042@roundup.psfhosted.org> Message-ID: <1550619631.05.0.603773151181.issue36042@roundup.psfhosted.org> Raymond Hettinger added the comment: > CPython only makes these methods class method when a class created. > If you set __class_getitem__ method after the creation it > doesn't work unless you use classmethod decorator manually. Give the intended use case for __class_getitem__ and that it was replacement for metaclass code with the same effect, the current behavior doesn't seem unreasonable. That said, I don't see any downside to allowing the method to attach after class creation. Assigning to Ivan to make the call on this one. ---------- assignee: -> levkivskyi components: +Interpreter Core nosy: +rhettinger type: behavior -> enhancement versions: +Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 18:55:41 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 19 Feb 2019 23:55:41 +0000 Subject: [issue36045] builtins.help function is not much help with async functions In-Reply-To: <1550619387.23.0.907293710235.issue36045@roundup.psfhosted.org> Message-ID: <1550620541.94.0.494450485935.issue36045@roundup.psfhosted.org> Raymond Hettinger added the comment: This would be a reasonable addition to help(). Would you like to make a PR? An "async def" can be detected with inspect.iscoroutinefunction(the_answer2). ---------- keywords: +easy nosy: +rhettinger stage: -> needs patch type: -> enhancement versions: +Python 3.8 -Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 19:02:14 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 20 Feb 2019 00:02:14 +0000 Subject: [issue36027] Support negative exponents in pow() where a modulus is specified. In-Reply-To: <1550520659.43.0.126744170658.issue36027@roundup.psfhosted.org> Message-ID: <1550620934.26.0.303864679472.issue36027@roundup.psfhosted.org> Raymond Hettinger added the comment: Changing the title to reflect a focus on building-out pow() instead of a function in the math module. ---------- title: Consider adding modular multiplicative inverse to the math module -> Support negative exponents in pow() where a modulus is specified. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 19:33:27 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 20 Feb 2019 00:33:27 +0000 Subject: [issue36018] Add a Normal Distribution class to the statistics module In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org> Message-ID: <1550622807.59.0.770038258094.issue36018@roundup.psfhosted.org> Raymond Hettinger added the comment: I'll work up a PR for this. We can continue to tease-out the best method names. I've has success with "examples" and "from_samples" when developing this code in the classroom. Both names had the virtue of being easily understood and never being misunderstood. Intellectually, the name fit() makes sense because we are using data to create best fit model parameters. So, technically this is probably the most accurate terminology. However, it doesn't match how I think about the problem though -- that is more along the lines of "use sampling data to make a random variable with a normal distribution". Another minor issue is that class methods are typically (but not always) recognizable by their from-prefix (e.g. dict.fromkeys, datetime.fromtimestamp, etc). "NormalDist" seems more self explanatory to me that just "Normal". Also, the noun form seems "more complete" than a dangling adjective (reading "normal" immediately raises the question "normal what?"). FWIW, MS Excel also calls their variant NORM.DIST (formerly spelled without the dot). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 19:41:35 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Wed, 20 Feb 2019 00:41:35 +0000 Subject: [issue35689] IDLE: Docstrings and test for colorizer In-Reply-To: <1546987852.48.0.500936785043.issue35689@roundup.psfhosted.org> Message-ID: <1550623295.79.0.438669233231.issue35689@roundup.psfhosted.org> Cheryl Sabella added the comment: > I have thought about merging delegator and colorizer into one module, possibly with percolator included, and adding a module docstring that explains how they work together. This would still be only a few hundred lines. (And multiple htests in one file are not an issue.) What do you think? undo also uses delegator.Delegator as a base class. It might be odd for it to come from colorizer.delegator. I like the idea of explaining how they all work together though. > I have not seriously looked at that idea yet. Neither have I. There are other things I'd like to get done (in this and other modules) before thinking about that one though. > In the first code comment I mentioned a follow-up code change. OK, I'll create an issue for that. I *really* want to rename the `any` function too. It took a lot of willpower to not touch it when writing the tests. :-) > Did you have anything in mind to work on or did you pick this for the fun and challenge? :-) Since the goal is to add tests for everything, I figured I'd tackle this one. But, I specifically thought it would be good to have tests in place in order to work on #29287. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 19:45:18 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 20 Feb 2019 00:45:18 +0000 Subject: [issue36012] Investigate slow writes to class variables In-Reply-To: <1550348118.4.0.228746523417.issue36012@roundup.psfhosted.org> Message-ID: <1550623518.58.0.478335021092.issue36012@roundup.psfhosted.org> Raymond Hettinger added the comment: Thanks Neil. The tooling does indeed look nice. I added your PyUnicode_InternInPlace() suggestion to the PR. At this point, the PR looks ready-to-go unless any of you think we've missed some low-hanging fruit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 19:47:32 2019 From: report at bugs.python.org (Bert JW Regeer) Date: Wed, 20 Feb 2019 00:47:32 +0000 Subject: [issue30717] Add unicode grapheme cluster break algorithm In-Reply-To: <1497986122.28.0.540580196076.issue30717@psf.upfronthosting.co.za> Message-ID: <1550623652.05.0.00560156425844.issue30717@roundup.psfhosted.org> Change by Bert JW Regeer : ---------- nosy: +Bert JW Regeer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 20:00:13 2019 From: report at bugs.python.org (INADA Naoki) Date: Wed, 20 Feb 2019 01:00:13 +0000 Subject: [issue12822] NewGIL should use CLOCK_MONOTONIC if possible. In-Reply-To: <1314085416.99.0.752578807259.issue12822@psf.upfronthosting.co.za> Message-ID: <1550624413.91.0.269865542729.issue12822@roundup.psfhosted.org> INADA Naoki added the comment: New changeset 001fee14e0f2ba5f41fb733adc69d5965925a094 by Inada Naoki in branch 'master': bpo-12822: use monotonic clock for condvar if possible (GH-11723) https://github.com/python/cpython/commit/001fee14e0f2ba5f41fb733adc69d5965925a094 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 20:00:28 2019 From: report at bugs.python.org (INADA Naoki) Date: Wed, 20 Feb 2019 01:00:28 +0000 Subject: [issue12822] NewGIL should use CLOCK_MONOTONIC if possible. In-Reply-To: <1314085416.99.0.752578807259.issue12822@psf.upfronthosting.co.za> Message-ID: <1550624428.34.0.71627240151.issue12822@roundup.psfhosted.org> Change by INADA Naoki : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 20:01:03 2019 From: report at bugs.python.org (INADA Naoki) Date: Wed, 20 Feb 2019 01:01:03 +0000 Subject: [issue23428] Use the monotonic clock for thread conditions on POSIX platforms In-Reply-To: <1423517667.9.0.82075564578.issue23428@psf.upfronthosting.co.za> Message-ID: <1550624463.35.0.169705526726.issue23428@roundup.psfhosted.org> Change by INADA Naoki : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.8 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 20:24:18 2019 From: report at bugs.python.org (Patrick McLean) Date: Wed, 20 Feb 2019 01:24:18 +0000 Subject: [issue36046] support dropping privileges when running subprocesses Message-ID: <1550625858.55.0.53498127684.issue36046@roundup.psfhosted.org> New submission from Patrick McLean : Currently when using python to automate system administration tasks, it is useful to drop privileges sometimes. Currently the only way to do this is via a preexec_fn, which has well-documented problems. It would be useful to be able to pass a user and groups arguments to subprocess.popen. ---------- components: Library (Lib) messages: 336033 nosy: patrick.mclean priority: normal severity: normal status: open title: support dropping privileges when running subprocesses type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 20:26:35 2019 From: report at bugs.python.org (Patrick McLean) Date: Wed, 20 Feb 2019 01:26:35 +0000 Subject: [issue36046] support dropping privileges when running subprocesses In-Reply-To: <1550625858.55.0.53498127684.issue36046@roundup.psfhosted.org> Message-ID: <1550625995.97.0.277366534708.issue36046@roundup.psfhosted.org> Change by Patrick McLean : ---------- keywords: +patch pull_requests: +11974 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 20:45:32 2019 From: report at bugs.python.org (Eryk Sun) Date: Wed, 20 Feb 2019 01:45:32 +0000 Subject: [issue33935] shutil.copyfile throws incorrect SameFileError on Google Drive File Stream In-Reply-To: <1529627906.69.0.56676864532.issue33935@psf.upfronthosting.co.za> Message-ID: <1550627132.9.0.438322301654.issue33935@roundup.psfhosted.org> Eryk Sun added the comment: > I don't see any value in testing the drive name separately. If the file number is non-zero, then the volume is the only question. I limited the comparison to just the drives in case the volume supports hardlinks. We can change the check to `s1.st_ino and s1.st_nlink > 1`, so we only incur the expense when necessary. Maybe that's never in practice, but I'd rather error on the side of caution. Anyway, it turns out we can't use splitdrive(). It doesn't handle UNC device paths the same way as regular UNC paths. It returns "\\?\UNC" as the drive for "\\?\UNC\server\share", whereas for a regular UNC path the drive is "\\server\share". > Would it make sense to add a parameter to _getfinalpathname that > specifies the type of the path? For same[open]file(), we can > probably just go to the most unreadable but broadly supported > type That's probably the simplest change we can make here, in addition to file-descriptor support. The non-normalized NT path (VOLUME_NAME_NT | FILE_NAME_OPENED) is the most broadly supported and cheapest path to get. It's just two system calls: NtQueryObject and NtQueryInformationFile. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 21:13:24 2019 From: report at bugs.python.org (Kubilay Kocak) Date: Wed, 20 Feb 2019 02:13:24 +0000 Subject: [issue35224] PEP 572: Assignment Expressions In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za> Message-ID: <1550628804.5.0.416856813267.issue35224@roundup.psfhosted.org> Change by Kubilay Kocak : ---------- nosy: +koobs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 21:32:25 2019 From: report at bugs.python.org (wang xuancong) Date: Wed, 20 Feb 2019 02:32:25 +0000 Subject: [issue36047] socket file handle does not support stream write Message-ID: <1550629945.15.0.290470169505.issue36047@roundup.psfhosted.org> New submission from wang xuancong : Python3 programmers have forgotten to convert/implement the socket file descriptor for IO stream operation. Would you please add it? Thanks! import socket s = socket.socket() s.connect('localhost', 5432) S = s.makefile() # on Python2, the following works print >>S, 'hello world' S.flush() # on Python3, the same thing does not work print('hello world', file=S, flush=True) It gives the following error: Traceback (most recent call last): File "", line 1, in io.UnsupportedOperation: not writable Luckily, the stream read operation works, S.readline() ---------- components: 2to3 (2.x to 3.x conversion tool) messages: 336035 nosy: xuancong84 priority: normal severity: normal status: open title: socket file handle does not support stream write type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 21:44:36 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Wed, 20 Feb 2019 02:44:36 +0000 Subject: [issue34793] Remove support for "with (await asyncio.lock):" In-Reply-To: <1537815811.02.0.545547206417.issue34793@psf.upfronthosting.co.za> Message-ID: <1550630676.36.0.854344501488.issue34793@roundup.psfhosted.org> Change by Emmanuel Arias : ---------- nosy: +eamanu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 21:44:52 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Wed, 20 Feb 2019 02:44:52 +0000 Subject: [issue36045] builtins.help function is not much help with async functions In-Reply-To: <1550619387.23.0.907293710235.issue36045@roundup.psfhosted.org> Message-ID: <1550630692.62.0.20513760768.issue36045@roundup.psfhosted.org> Change by Emmanuel Arias : ---------- nosy: +eamanu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 21:52:33 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Wed, 20 Feb 2019 02:52:33 +0000 Subject: [issue35885] configparser: indentation In-Reply-To: <1549061954.1.0.734541407213.issue35885@roundup.psfhosted.org> Message-ID: <1550631153.77.0.799209411038.issue35885@roundup.psfhosted.org> Emmanuel Arias added the comment: > I already have some example code for it Do you have a patch? ---------- nosy: +eamanu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 22:17:09 2019 From: report at bugs.python.org (twisteroid ambassador) Date: Wed, 20 Feb 2019 03:17:09 +0000 Subject: [issue35945] Cannot distinguish between subtask cancellation and running task cancellation In-Reply-To: <1549660576.62.0.347711337086.issue35945@roundup.psfhosted.org> Message-ID: <1550632629.03.0.0330963975257.issue35945@roundup.psfhosted.org> twisteroid ambassador added the comment: I wrote a recipe on this idea: https://gist.github.com/twisteroidambassador/f35c7b17d4493d492fe36ab3e5c92202 Untested, feel free to use it at your own risk. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 19 22:51:36 2019 From: report at bugs.python.org (Peixing Xin) Date: Wed, 20 Feb 2019 03:51:36 +0000 Subject: [issue31904] Python should support VxWorks RTOS In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za> Message-ID: <1550634696.66.0.627673481167.issue31904@roundup.psfhosted.org> Change by Peixing Xin : ---------- pull_requests: +11976 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 00:06:06 2019 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 20 Feb 2019 05:06:06 +0000 Subject: [issue35925] test_httplib test_nntplib test_ssl fail on ARMv7 Debian buster bot (OpenSSL 1.1.1a) In-Reply-To: <1549503926.32.0.191493141556.issue35925@roundup.psfhosted.org> Message-ID: <1550639166.39.0.337873905915.issue35925@roundup.psfhosted.org> Benjamin Peterson added the comment: It's okay with me if you want to backport minimum_version (and I suppose maximum_version). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 00:15:27 2019 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 20 Feb 2019 05:15:27 +0000 Subject: [issue32528] Change base class for futures.CancelledError In-Reply-To: <1515601875.1.0.467229070634.issue32528@psf.upfronthosting.co.za> Message-ID: <1550639727.64.0.910876661654.issue32528@roundup.psfhosted.org> Change by Chris Jerdonek : ---------- nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 00:24:19 2019 From: report at bugs.python.org (Eryk Sun) Date: Wed, 20 Feb 2019 05:24:19 +0000 Subject: [issue36021] [Security][Windows] webbrowser: WindowsDefault uses os.startfile() and so can be abused to run arbitrary commands In-Reply-To: <1550487653.15.0.496398912417.issue36021@roundup.psfhosted.org> Message-ID: <1550640259.67.0.529052401885.issue36021@roundup.psfhosted.org> Eryk Sun added the comment: > os.access(path, os.X_OK) is specific to Unix. It doesn't make sense > on Windows. It doesn't make sense with the current implementation of os.access, and not as St?phane used it. Even if we completely implemented os.access, the problem is that most files grant execute access to the owner, "Users", or "Authenticated Users". Typically we have to override inheritance to prevent granting execute access, or add an entry that denies execute access. However, it's not that it makes no sense in general. CreateProcess does require execute access on a file. This includes both DACL discretionary access and SACL mandatory access. ShellExecuteEx ultimately calls CreateProcess if it's running a "file:" URL, so execute access certainly matters in this case. For example, I've denied execute access on the following file: >>> os.startfile('file:///C:/Temp/test/test.exe') Traceback (most recent call last): File "", line 1, in PermissionError: [WinError 5] Access is denied: 'file:///C:/Temp/test/test.exe' On the other hand, if we're talking about data files and scripts, ShellExecute[Ex] doesn't check for execute access because it's generally used to "open" files. It wouldn't be a security barrier, anyway. It's easy enough for a program to call AssocQueryString to get the command-line template for a protocol or file type, manually replace template parameters, and execute the command directly via CreateProcess. > os.access() is implemented with GetFileAttributesW() on Windows. The > mode argument is more or less ignored. The readonly file attribute denies W_OK access, similar to how the [i]mmutable file attribute works in some Unix systems (e.g. Linux lsattr and chattr +i). ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 01:36:10 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 20 Feb 2019 06:36:10 +0000 Subject: [issue36031] add internal API function to effectively convert just created list to tuple In-Reply-To: <1550565320.39.0.769773111251.issue36031@roundup.psfhosted.org> Message-ID: <1550644570.43.0.056730157341.issue36031@roundup.psfhosted.org> Raymond Hettinger added the comment: -1 This technique has a low payoff (possibly even zero due to memcpy() overhead) but is likely to create future maintenance issues (risk of bugs due to the fragility of assuming a refcnt of one, awkwardness of maintenance if we have to alter the surrounding code). ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 01:43:05 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 Feb 2019 06:43:05 +0000 Subject: [issue36048] Deprecate implicit truncating when convert Python numbers to C integers Message-ID: <1550644985.32.0.26417547244.issue36048@roundup.psfhosted.org> New submission from Serhiy Storchaka : Currently, C API functions that convert a Python number to a C integer like PyLong_AsLong() and argument parsing functions like PyArg_ParseTuple() with integer converting format units like 'i' use the __int__() special method for converting objects which are not instances of int or int subclasses. This leads to dropping the fractional part if the object is not integral number (e.g. float, Decimal or Fraction). In some cases, there is a special check for float, but it does not prevent truncation for Decimal, Fraction and other numeric types. For example: >>> chr(65.5) Traceback (most recent call last): File "", line 1, in TypeError: integer argument expected, got float >>> chr(Decimal('65.5')) 'A' The proposed PR makes all these functions using __index__() instead of __int__() if available and emit a deprecation warning when __int__() is used for implicit conversion to a C integer. >>> chr(Decimal('65.5')) :1: DeprecationWarning: an integer is required (got type decimal.Decimal) 'A' In future versions only __index__() will be used for the implicit conversion, and __int__() will be used only in the int constructor. ---------- components: Interpreter Core messages: 336041 nosy: mark.dickinson, serhiy.storchaka, vstinner priority: normal severity: normal status: open title: Deprecate implicit truncating when convert Python numbers to C integers type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 01:45:44 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 06:45:44 +0000 Subject: [issue36021] [Security][Windows] webbrowser: WindowsDefault uses os.startfile() and so can be abused to run arbitrary commands In-Reply-To: <1550487653.15.0.496398912417.issue36021@roundup.psfhosted.org> Message-ID: <1550645144.06.0.754458508971.issue36021@roundup.psfhosted.org> St?phane Wirtel added the comment: Hi @eryk, @vstinner and @steve, I think I could not work on this issue today, but will continue to fix it asap (tomorrow or on this evening). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 01:47:28 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 20 Feb 2019 06:47:28 +0000 Subject: [issue36030] add internal API function to create tuple without items array initialization In-Reply-To: <1550563364.86.0.164811838679.issue36030@roundup.psfhosted.org> Message-ID: <1550645248.93.0.392576577054.issue36030@roundup.psfhosted.org> Raymond Hettinger added the comment: Zeroing memory is usually not expensive relative to the cost of filling it in. Also, the timing loop is unrealistic. We mostly care about small tuples. For long term maintenance of the project, I recommend filling the code with these unsafe variants which will segfault whenever someone follows the normal practice of decreffing when an error is encountered. This would be yet another special case a person would have to learn to do maintenance or code review for CPython. In general, there are a lot of small optimizations to be had if we were to forgo principles of loose coupling, defensive programming, and ease of maintenance. Once in a while, we find one that actually is worth it, but usually it is a best practice sprinkle these special cases all over the code (see MS Code Complete for more discussion on the long term costs of this kind of coding). ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 01:54:23 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 Feb 2019 06:54:23 +0000 Subject: [issue36048] Deprecate implicit truncating when convert Python numbers to C integers In-Reply-To: <1550644985.32.0.26417547244.issue36048@roundup.psfhosted.org> Message-ID: <1550645663.26.0.697729064933.issue36048@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- keywords: +patch pull_requests: +11977 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 01:56:34 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 Feb 2019 06:56:34 +0000 Subject: [issue33039] int() and math.trunc don't accept objects that only define __index__ In-Reply-To: <1520672231.04.0.467229070634.issue33039@psf.upfronthosting.co.za> Message-ID: <1550645794.05.0.184304206952.issue33039@roundup.psfhosted.org> Serhiy Storchaka added the comment: See also issue33039. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 01:57:13 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 Feb 2019 06:57:13 +0000 Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or operator.index() docos lie) In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za> Message-ID: <1550645833.19.0.91577596984.issue17576@roundup.psfhosted.org> Serhiy Storchaka added the comment: See also issue33039. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 02:10:16 2019 From: report at bugs.python.org (Dan Rose) Date: Wed, 20 Feb 2019 07:10:16 +0000 Subject: [issue36045] builtins.help function is not much help with async functions In-Reply-To: <1550619387.23.0.907293710235.issue36045@roundup.psfhosted.org> Message-ID: <1550646616.6.0.566402882778.issue36045@roundup.psfhosted.org> Dan Rose added the comment: Thanks for the suggestion, Raymond. I was toying with the idea of a PR, but wasn?t sure what the resolution should be, and it?s a rather subtle decision for my first contribution. It seems to me that this might be an oversight in PEP-0484, and the purest resolution is that either Generator and Coroutine should both be part of the type signature or neither should be. If the PEP is indeed correct, the help output *could* look like: async the_answer2() -> int Which would be equivalent to the (functionally identical) wrapper: the_answer3() -> Awaitable[int] Philosophically, does asyncness belong on the left or right of the arrow? Should it change just because of how the function is expressed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 02:38:48 2019 From: report at bugs.python.org (Dan Rose) Date: Wed, 20 Feb 2019 07:38:48 +0000 Subject: [issue36045] builtins.help function is not much help with async functions In-Reply-To: <1550619387.23.0.907293710235.issue36045@roundup.psfhosted.org> Message-ID: <1550648328.86.0.324402335541.issue36045@roundup.psfhosted.org> Dan Rose added the comment: Note to future self: whatever solution should also play nice with functools.partial ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 02:47:15 2019 From: report at bugs.python.org (Windson Yang) Date: Wed, 20 Feb 2019 07:47:15 +0000 Subject: [issue36047] socket file handle does not support stream write In-Reply-To: <1550629945.15.0.290470169505.issue36047@roundup.psfhosted.org> Message-ID: <1550648835.66.0.992212704801.issue36047@roundup.psfhosted.org> Windson Yang added the comment: >From the docs https://docs.python.org/3/library/socket.html#socket.socket.makefile, the default mode for makefile() is 'r' (only readable). In your example, just use S = s.makefile(mode='w') instead. ---------- nosy: +Windson Yang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 03:12:24 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 Feb 2019 08:12:24 +0000 Subject: [issue36048] Deprecate implicit truncating when convert Python numbers to C integers In-Reply-To: <1550644985.32.0.26417547244.issue36048@roundup.psfhosted.org> Message-ID: <1550650344.98.0.760810809703.issue36048@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 03:32:07 2019 From: report at bugs.python.org (Aaryn Tonita) Date: Wed, 20 Feb 2019 08:32:07 +0000 Subject: [issue36041] email: folding of quoted string in display_name violates RFC In-Reply-To: <1550594739.09.0.990893515193.issue36041@roundup.psfhosted.org> Message-ID: <1550651527.95.0.990753210222.issue36041@roundup.psfhosted.org> Aaryn Tonita added the comment: Hi David, the problem is in email._header_value_parser._refold_parse_tree. Specifically, when the parsetree renders too long, it recursively gets newparts = list(part) (the children). When it does this to a BareQuotedString node, the child nodes are unquoted and unescaped and it just happily serializes these. I thought I had attached a file that monkey patches the _refold_parse_tree function with a fixed version... let me try again. ---------- Added file: https://bugs.python.org/file48158/address_folding_bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 03:34:51 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 Feb 2019 08:34:51 +0000 Subject: [issue36048] Deprecate implicit truncating when convert Python numbers to C integers In-Reply-To: <1550644985.32.0.26417547244.issue36048@roundup.psfhosted.org> Message-ID: <1550651691.74.0.272897194699.issue36048@roundup.psfhosted.org> Serhiy Storchaka added the comment: Numerous explicit calls of PyNumber_Index() which are used to protect from passing non-integral types to PyLong_AsLong() and like can be removed after the end of the deprecation period. I tried to mark calls which can be removed with comments, but virtually all calls can be removed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 04:26:37 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 09:26:37 +0000 Subject: [issue36047] socket file handle does not support stream write In-Reply-To: <1550629945.15.0.290470169505.issue36047@roundup.psfhosted.org> Message-ID: <1550654797.93.0.697666787042.issue36047@roundup.psfhosted.org> St?phane Wirtel added the comment: I confirm that you don't use socket.makefile in write mode. Python 3.7.2 (default, Jan 16 2019, 19:49:22) [GCC 8.2.1 20181215 (Red Hat 8.2.1-6)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import socket >>> s = socket.socket() >>> s.connect('localhost', 5432) Traceback (most recent call last): File "", line 1, in TypeError: connect() takes exactly one argument (2 given) >>> s.connect(('localhost', 5432)) >>> S = s.makefile() >>> print('hello world', file=S, flush=True) Traceback (most recent call last): File "", line 1, in io.UnsupportedOperation: not writable >>> S = s.makefile(mode='w') >>> print('hello world', file=S, flush=True) >>> I close the issue. ---------- nosy: +matrixise resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 04:46:08 2019 From: report at bugs.python.org (Eddie Elizondo) Date: Wed, 20 Feb 2019 09:46:08 +0000 Subject: [issue35810] Object Initialization does not incref Heap-allocated Types In-Reply-To: <1548275752.94.0.463880453345.issue35810@roundup.psfhosted.org> Message-ID: <1550655968.57.0.222062745291.issue35810@roundup.psfhosted.org> Eddie Elizondo added the comment: Bump to get a review on the PR: https://github.com/python/cpython/pull/11661. I believe all comments have now been addressed as well as adding a porting to 3.8 guide. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 05:14:35 2019 From: report at bugs.python.org (Zahash Z) Date: Wed, 20 Feb 2019 10:14:35 +0000 Subject: [issue36049] No __repr__() for queue.PriorityQueue and queue.LifoQueue Message-ID: <1550657675.07.0.575320352135.issue36049@roundup.psfhosted.org> New submission from Zahash Z : There is no __repr__() method for the PriorityQueue class and LifoQueue class in the queue.py file This makes it difficult to check the elements of the queue. ---------- messages: 336053 nosy: Zahash Z priority: normal severity: normal status: open title: No __repr__() for queue.PriorityQueue and queue.LifoQueue type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 05:21:42 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 10:21:42 +0000 Subject: [issue36049] No __repr__() for queue.PriorityQueue and queue.LifoQueue In-Reply-To: <1550657675.07.0.575320352135.issue36049@roundup.psfhosted.org> Message-ID: <1550658102.62.0.00195368667809.issue36049@roundup.psfhosted.org> St?phane Wirtel added the comment: but the __repr__ would have a limitation because you can't show all the elements from your queue, for example, if your queue contains 1000 items, the __repr__ will show the total items or just the ten first ones? We need a compromise for that. ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 05:23:03 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 10:23:03 +0000 Subject: [issue36049] No __repr__() for queue.PriorityQueue and queue.LifoQueue In-Reply-To: <1550657675.07.0.575320352135.issue36049@roundup.psfhosted.org> Message-ID: <1550658183.34.0.339848581233.issue36049@roundup.psfhosted.org> St?phane Wirtel added the comment: and there is an other issue, we need to iterate over the elements of the deque() :/ not really performant, just for a repr(). for my part, -1 if we have to iterate over the elements. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 05:30:08 2019 From: report at bugs.python.org (Charalampos Stratakis) Date: Wed, 20 Feb 2019 10:30:08 +0000 Subject: [issue35925] test_httplib test_nntplib test_ssl fail on ARMv7 Debian buster bot (OpenSSL 1.1.1a) In-Reply-To: <1549503926.32.0.191493141556.issue35925@roundup.psfhosted.org> Message-ID: <1550658608.43.0.945071543445.issue35925@roundup.psfhosted.org> Charalampos Stratakis added the comment: SSLContext.minimum_version is added here on the master branch: https://github.com/python/cpython/commit/698dde16f60729d9e3f53c23a4ddb8e5ffe818bf But I'd be also reluctant to partially backport a new feature to fix the test suite. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 05:31:02 2019 From: report at bugs.python.org (Windson Yang) Date: Wed, 20 Feb 2019 10:31:02 +0000 Subject: [issue36049] No __repr__() for queue.PriorityQueue and queue.LifoQueue In-Reply-To: <1550657675.07.0.575320352135.issue36049@roundup.psfhosted.org> Message-ID: <1550658662.18.0.884021914693.issue36049@roundup.psfhosted.org> Windson Yang added the comment: Hello, Zahash Z. May I ask what is your expected behavior for the return value of __repr__() from PriorityQueue. I'm agreed with St?phane Wirtel, I don't think returning all the items would be a good idea, maybe we can improve it in another way. For instance, return the first and last element as well as the length. ---------- nosy: +Windson Yang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 05:32:51 2019 From: report at bugs.python.org (INADA Naoki) Date: Wed, 20 Feb 2019 10:32:51 +0000 Subject: [issue36042] Setting __init_subclass__ and __class_getitem__ methods are in runtime doesnt make them class method. In-Reply-To: <1550596795.62.0.0325313661294.issue36042@roundup.psfhosted.org> Message-ID: <1550658771.71.0.0499035926908.issue36042@roundup.psfhosted.org> INADA Naoki added the comment: __new__ is special function too. It is converted as staticmethod when class creation. Since manually converting to (static|class)method is allowed, I don't think automatic conversion should be applied when attach after class creation. $ python3 Python 3.7.2 (default, Feb 12 2019, 08:15:36) [Clang 10.0.0 (clang-1000.11.45.5)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> class C: ... def __new__(cls): ... pass ... >>> type(C.__dict__['__new__']) >>> class D: ... pass ... >>> D.__new__ = lambda cls: cls >>> type(D.__dict__['__new__']) ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 05:34:22 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Feb 2019 10:34:22 +0000 Subject: [issue10278] add time.monotonic() method In-Reply-To: <1288624210.23.0.0497533122542.issue10278@psf.upfronthosting.co.za> Message-ID: <1550658861.99.0.353460653944.issue10278@roundup.psfhosted.org> STINNER Victor added the comment: This issue has been followed by the PEP 418 which added time.monotonic(), time.perf_counter() and time.process_time(). ---------- title: add time.wallclock() method -> add time.monotonic() method _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 05:35:46 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Feb 2019 10:35:46 +0000 Subject: [issue23428] Use the monotonic clock for thread conditions on POSIX platforms In-Reply-To: <1423517667.9.0.82075564578.issue23428@psf.upfronthosting.co.za> Message-ID: <1550658946.45.0.685215479895.issue23428@roundup.psfhosted.org> STINNER Victor added the comment: INADA-san fixed bpo-12822 with: New changeset 001fee14e0f2ba5f41fb733adc69d5965925a094 by Inada Naoki in branch 'master': bpo-12822: use monotonic clock for condvar if possible (GH-11723) https://github.com/python/cpython/commit/001fee14e0f2ba5f41fb733adc69d5965925a094 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 05:36:02 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Feb 2019 10:36:02 +0000 Subject: [issue12822] NewGIL should use CLOCK_MONOTONIC if possible. In-Reply-To: <1314085416.99.0.752578807259.issue12822@psf.upfronthosting.co.za> Message-ID: <1550658962.69.0.239661990584.issue12822@roundup.psfhosted.org> STINNER Victor added the comment: Thanks INADA-san for fixing this old issue! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 05:37:19 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 10:37:19 +0000 Subject: [issue36049] No __repr__() for queue.PriorityQueue and queue.LifoQueue In-Reply-To: <1550657675.07.0.575320352135.issue36049@roundup.psfhosted.org> Message-ID: <1550659039.09.0.806582745586.issue36049@roundup.psfhosted.org> St?phane Wirtel added the comment: >>> from collections import deque >>> d = deque() >>> d.append('j') >>> d.appendleft('f') >>> d deque(['f', 'j']) >>> repr(d) "deque(['f', 'j'])" Maybe there is a solution, in the code of deque_repr, we convert the deque to a list. We could do the same thing and take the first and the last element. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 05:48:09 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Feb 2019 10:48:09 +0000 Subject: [issue36031] add internal API function to effectively convert just created list to tuple In-Reply-To: <1550565320.39.0.769773111251.issue36031@roundup.psfhosted.org> Message-ID: <1550659689.67.0.78252073009.issue36031@roundup.psfhosted.org> STINNER Victor added the comment: _PyList_ConvertToTuple(PyObject *v): assert(Py_REFCNT(v) == 1); I don't think that _PyList_ConvertToTuple() usage is common enough to justify this micro-optimization. IMHO "Py_REFCNT(v) == 1" assumption is too strong. Python internals can be very surprising, especially when borrowered references and the garbage collector comes into the game. I concur with Serhiy and Raymond: it's too risky with very low benefit. It is likely to have no significant impact on macro benchmarks like https://pyperformance.readthedocs.io/ ( https://speed.python.org/ ). ---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 05:48:50 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Wed, 20 Feb 2019 10:48:50 +0000 Subject: [issue35840] Control flow inconsistency on closed asyncio stream In-Reply-To: <1548662045.39.0.770532095049.issue35840@roundup.psfhosted.org> Message-ID: <1550659730.21.0.42566073191.issue35840@roundup.psfhosted.org> Change by Emmanuel Arias : ---------- nosy: +eamanu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 05:51:39 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Feb 2019 10:51:39 +0000 Subject: [issue36021] [Security][Windows] webbrowser: WindowsDefault uses os.startfile() and so can be abused to run arbitrary commands In-Reply-To: <1550487653.15.0.496398912417.issue36021@roundup.psfhosted.org> Message-ID: <1550659899.31.0.0985461302141.issue36021@roundup.psfhosted.org> STINNER Victor added the comment: > >>> os.startfile('file:///C:/Temp/test/test.exe') Oh, startfile() also runs a program for an URL using file:// scheme? If yes, it becomes even more complex to fix this file :-/ How do you decide if an URL start with file:// is safe? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 05:53:27 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Feb 2019 10:53:27 +0000 Subject: [issue36030] add internal API function to create tuple without items array initialization In-Reply-To: <1550563364.86.0.164811838679.issue36030@roundup.psfhosted.org> Message-ID: <1550660007.09.0.395402891937.issue36030@roundup.psfhosted.org> STINNER Victor added the comment: Raymond: > Also, the timing loop is unrealistic. We mostly care about small tuples. Sergey: can you please run benchmarks on small tuples? Example, 1, 5, 10, 20 and 100 items. Maybe not only tuple(list), but try some other operations? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 05:57:17 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Wed, 20 Feb 2019 10:57:17 +0000 Subject: [issue35812] Don't log an exception from the main coroutine in asyncio.run() In-Reply-To: <1548291532.01.0.358121522852.issue35812@roundup.psfhosted.org> Message-ID: <1550660237.54.0.80405706307.issue35812@roundup.psfhosted.org> Change by Emmanuel Arias : ---------- nosy: +eamanu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 05:58:41 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 10:58:41 +0000 Subject: [issue36049] No __repr__() for queue.PriorityQueue and queue.LifoQueue In-Reply-To: <1550657675.07.0.575320352135.issue36049@roundup.psfhosted.org> Message-ID: <1550660321.39.0.147205339105.issue36049@roundup.psfhosted.org> St?phane Wirtel added the comment: For this script, you could have the following output: from queue import Queue q = Queue() print(repr(q)) q.put('a') print(repr(q)) q.put('b') print(repr(q)) q.put('c') print(repr(q)) Queue() Queue('a') Queue('a','b') Queue('a'...'c') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 06:04:44 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 11:04:44 +0000 Subject: [issue36049] No __repr__() for queue.PriorityQueue and queue.LifoQueue In-Reply-To: <1550657675.07.0.575320352135.issue36049@roundup.psfhosted.org> Message-ID: <1550660684.23.0.572426977529.issue36049@roundup.psfhosted.org> St?phane Wirtel added the comment: New output for Queue, PriorityQueue and LifoQueue Queue() Queue('a') Queue('a','b') Queue('a'...'c') PriorityQueue() PriorityQueue('a') PriorityQueue('a','b') PriorityQueue('a'...'c') LifoQueue() LifoQueue('a') LifoQueue('a','b') LifoQueue('a'...'c') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 06:07:49 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 11:07:49 +0000 Subject: [issue36049] No __repr__() for queue.PriorityQueue and queue.LifoQueue In-Reply-To: <1550657675.07.0.575320352135.issue36049@roundup.psfhosted.org> Message-ID: <1550660869.29.0.938616550277.issue36049@roundup.psfhosted.org> Change by St?phane Wirtel : ---------- keywords: +patch pull_requests: +11978 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 06:09:13 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 11:09:13 +0000 Subject: [issue36049] No __repr__() for queue.PriorityQueue and queue.LifoQueue In-Reply-To: <1550657675.07.0.575320352135.issue36049@roundup.psfhosted.org> Message-ID: <1550660953.3.0.15352552611.issue36049@roundup.psfhosted.org> St?phane Wirtel added the comment: Just created a PR for this issue and I need to add the tests for the __repr__ method ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 06:10:59 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Feb 2019 11:10:59 +0000 Subject: [issue36048] Deprecate implicit truncating when convert Python numbers to C integers In-Reply-To: <1550644985.32.0.26417547244.issue36048@roundup.psfhosted.org> Message-ID: <1550661059.21.0.0376798356943.issue36048@roundup.psfhosted.org> STINNER Victor added the comment: I like the idea. Rejecting float but not decimal.Decimal is inconsistent. __index__ has been written explicitly for this purpose. I'm always confused and lost in subtle details of the Python and C API in how they handle numbers, so I wrote some notes for myself: https://pythondev.readthedocs.io/numbers.html Some functions accept only int, others use __int__, others __index__. Some functions silently truncate into 32 or 64-bit signed integer. Some other raise a OverflowError or ValueError... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 06:11:11 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Feb 2019 11:11:11 +0000 Subject: [issue36048] Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__ In-Reply-To: <1550644985.32.0.26417547244.issue36048@roundup.psfhosted.org> Message-ID: <1550661071.49.0.0608490377431.issue36048@roundup.psfhosted.org> Change by STINNER Victor : ---------- title: Deprecate implicit truncating when convert Python numbers to C integers -> Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__ _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 06:11:51 2019 From: report at bugs.python.org (Radek) Date: Wed, 20 Feb 2019 11:11:51 +0000 Subject: [issue34486] "RuntimeError: release unlocked lock" when starting a thread In-Reply-To: <1535119355.34.0.56676864532.issue34486@psf.upfronthosting.co.za> Message-ID: <1550661111.87.0.161986126809.issue34486@roundup.psfhosted.org> Radek added the comment: Any progress on this topic? I think I've encountered this (or similar) issue: >Traceback (most recent call last): > File "logging/__init__.py", line 1944, in shutdown > File "logging/__init__.py", line 813, in acquire > File "site-packages/utils/signals.py", line 58, in signal_wrapper > File "utils/utils.py", line 147, in sigterm_handler >SystemExit: 0 > >During handling of the above exception, another exception occurred: > >Traceback (most recent call last): > File "logging/__init__.py", line 1954, in shutdown > File "logging/__init__.py", line 821, in release >RuntimeError: cannot release un-acquired lock ---------- nosy: +radek_kujawa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 06:13:37 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Feb 2019 11:13:37 +0000 Subject: [issue36048] Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__ In-Reply-To: <1550644985.32.0.26417547244.issue36048@roundup.psfhosted.org> Message-ID: <1550661217.58.0.0927937361928.issue36048@roundup.psfhosted.org> STINNER Victor added the comment: See also bpo-34423: "Overflow when casting from double to time_t, and_PyTime_t" or "How to reduce precision loss when converting arbitrary number to int or float?". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 06:13:50 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Feb 2019 11:13:50 +0000 Subject: [issue34423] Overflow when casting from double to time_t, and_PyTime_t. In-Reply-To: <1534543009.21.0.56676864532.issue34423@psf.upfronthosting.co.za> Message-ID: <1550661230.81.0.794060597001.issue34423@roundup.psfhosted.org> STINNER Victor added the comment: See also bpo-36048: "Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 06:30:20 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Wed, 20 Feb 2019 11:30:20 +0000 Subject: [issue36030] add internal API function to create tuple without items array initialization In-Reply-To: <1550563364.86.0.164811838679.issue36030@roundup.psfhosted.org> Message-ID: <1550662220.42.0.204622151008.issue36030@roundup.psfhosted.org> Change by Sergey Fedoseev : ---------- pull_requests: +11979 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 06:31:46 2019 From: report at bugs.python.org (Zahash Z) Date: Wed, 20 Feb 2019 11:31:46 +0000 Subject: [issue36049] No __repr__() for queue.PriorityQueue and queue.LifoQueue In-Reply-To: <1550657675.07.0.575320352135.issue36049@roundup.psfhosted.org> Message-ID: <1550662306.51.0.781584692478.issue36049@roundup.psfhosted.org> Zahash Z added the comment: I raised this issue after creating a pull request and modifying the source code. so, people who want to create a pull request can sit back and relax cuz I got this ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 06:34:59 2019 From: report at bugs.python.org (Roundup Robot) Date: Wed, 20 Feb 2019 11:34:59 +0000 Subject: [issue36049] No __repr__() for queue.PriorityQueue and queue.LifoQueue In-Reply-To: <1550657675.07.0.575320352135.issue36049@roundup.psfhosted.org> Message-ID: <1550662499.21.0.727137819737.issue36049@roundup.psfhosted.org> Change by Roundup Robot : ---------- pull_requests: +11980 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 06:37:48 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Feb 2019 11:37:48 +0000 Subject: [issue36030] add internal API function to create tuple without items array initialization In-Reply-To: <1550563364.86.0.164811838679.issue36030@roundup.psfhosted.org> Message-ID: <1550662668.97.0.311478660512.issue36030@roundup.psfhosted.org> STINNER Victor added the comment: I prefer PyTuple_FromArray() API idea. It's safer by design than you "list to tuple" function stealing references to list items if refcnt(list)==1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 06:56:45 2019 From: report at bugs.python.org (INADA Naoki) Date: Wed, 20 Feb 2019 11:56:45 +0000 Subject: [issue22213] Make pyvenv style virtual environments easier to configure when embedding Python In-Reply-To: <1408275761.36.0.915361061447.issue22213@psf.upfronthosting.co.za> Message-ID: <1550663805.44.0.472974818819.issue22213@roundup.psfhosted.org> Change by INADA Naoki : ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 06:58:34 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Wed, 20 Feb 2019 11:58:34 +0000 Subject: [issue36049] No __repr__() for queue.PriorityQueue and queue.LifoQueue In-Reply-To: <1550657675.07.0.575320352135.issue36049@roundup.psfhosted.org> Message-ID: <1550663914.86.0.799760714444.issue36049@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 07:09:00 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Wed, 20 Feb 2019 12:09:00 +0000 Subject: [issue36049] No __repr__() for queue.PriorityQueue and queue.LifoQueue In-Reply-To: <1550657675.07.0.575320352135.issue36049@roundup.psfhosted.org> Message-ID: <1550664540.65.0.938341134666.issue36049@roundup.psfhosted.org> R?mi Lapeyre added the comment: Hi @matrixise, is it really an issue to iterate over all the elements of the deque? __repr__ won't be called on performance sensitive path and we already do this for repr([0]*10000), repr({i for i in range(10000)}) and repr({i:i for i in range(10000)}) ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 07:14:31 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 12:14:31 +0000 Subject: [issue36049] No __repr__() for queue.PriorityQueue and queue.LifoQueue In-Reply-To: <1550657675.07.0.575320352135.issue36049@roundup.psfhosted.org> Message-ID: <1550664871.25.0.0749575067655.issue36049@roundup.psfhosted.org> St?phane Wirtel added the comment: Yep, we have a problem, two PRs for the same issue. I have seen your issue in the bug tracker (not marked as "in progress") and I started to fix it where I have proposed some solutions and a PR. For the next time, maybe you should create the issue, indicate you are working on the issue and fix it. I am really sorry, I didn't see that you was working on your issue because there was no associated PR on the issue. And now, I understand because the title of your PR was "issue #36049; added __repr__() for the queue.PriorityQueue and queue.LifoQueue classes". Bedevere (a BOT) tries to map a PR with an issue if the title is correctly defined in Github. For example: "bpo-36049: Added __repr__() for the queue.PriorityQueue and queue.LifoQueue classes" Have a nice day, ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 07:17:49 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 12:17:49 +0000 Subject: [issue36049] No __repr__() for queue.PriorityQueue and queue.LifoQueue In-Reply-To: <1550657675.07.0.575320352135.issue36049@roundup.psfhosted.org> Message-ID: <1550665069.7.0.486222841137.issue36049@roundup.psfhosted.org> St?phane Wirtel added the comment: @remi.lapeyre In fact, I am not sure about the performance issue but in the code of _collectionsmodule.c#deque_repr we create a PySequence_List, it's a new list. So for me, but maybe I am wrong, we will iterate over the deque container for the creation of the new list. now, I think it's not a big issue (to confirm by @rhettinger) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 07:19:18 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 12:19:18 +0000 Subject: [issue36049] No __repr__() for queue.PriorityQueue and queue.LifoQueue In-Reply-To: <1550657675.07.0.575320352135.issue36049@roundup.psfhosted.org> Message-ID: <1550665158.06.0.0201634460703.issue36049@roundup.psfhosted.org> St?phane Wirtel added the comment: static PyObject * deque_repr(PyObject *deque) { PyObject *aslist, *result; ... aslist = PySequence_List(deque); ... if (((dequeobject *)deque)->maxlen >= 0) result = PyUnicode_FromFormat("%s(%R, maxlen=%zd)", _PyType_Name(Py_TYPE(deque)), aslist, ((dequeobject *)deque)->maxlen); else result = PyUnicode_FromFormat("%s(%R)", _PyType_Name(Py_TYPE(deque)), aslist); ... return result; } ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 07:34:18 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 12:34:18 +0000 Subject: [issue36021] [Security][Windows] webbrowser: WindowsDefault uses os.startfile() and so can be abused to run arbitrary commands In-Reply-To: <1550487653.15.0.496398912417.issue36021@roundup.psfhosted.org> Message-ID: <1550666058.18.0.339691148767.issue36021@roundup.psfhosted.org> St?phane Wirtel added the comment: Windows has the GetBinaryTypeW function, this one is used by pywin32, maybe I could develop a wrapper in os, like os.is_executable(path) for Unix-like, os.is_executable(path) could use os.access(path, os.X_OK) for Windows, the function would use GetBinaryTypeW. my 2 cents. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 07:36:56 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 12:36:56 +0000 Subject: [issue36020] HAVE_SNPRINTF and MSVC std::snprintf support In-Reply-To: <1550485106.18.0.506219958256.issue36020@roundup.psfhosted.org> Message-ID: <1550666216.57.0.940371476119.issue36020@roundup.psfhosted.org> St?phane Wirtel added the comment: Hi @steve I'm not used to this, can you guide me? Thanks ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 07:50:12 2019 From: report at bugs.python.org (Zahash Z) Date: Wed, 20 Feb 2019 12:50:12 +0000 Subject: [issue36049] No __repr__() for queue.PriorityQueue and queue.LifoQueue In-Reply-To: <1550657675.07.0.575320352135.issue36049@roundup.psfhosted.org> Message-ID: <1550667012.33.0.251098762829.issue36049@roundup.psfhosted.org> Change by Zahash Z : ---------- components: +Library (Lib) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 07:55:43 2019 From: report at bugs.python.org (Bruce Merry) Date: Wed, 20 Feb 2019 12:55:43 +0000 Subject: [issue36050] Why does http.client.HTTPResponse._safe_read use MAXAMOUNT Message-ID: <1550667343.87.0.589252473583.issue36050@roundup.psfhosted.org> New submission from Bruce Merry : While investigating poor HTTP read performance I discovered that reading all the data from a response with a content-length goes via _safe_read, which in turn reads in chunks of at most MAXAMOUNT (1MB) before stitching them together with b"".join. This can really hurt performance for responses larger than MAXAMOUNT, because (a) the data has to be copied an additional time; and (b) the join operation doesn't drop the GIL, so this limits multi-threaded scaling. I'm struggling to see any advantage in doing this chunking - it's not saving memory either (in fact it is wasting it). To give an idea of the performance impact, changing MAXAMOUNT to a very large value made a multithreaded test of mine go from 800MB/s to 2.5GB/s (which is limited by the network speed). ---------- components: Library (Lib) messages: 336081 nosy: bmerry priority: normal severity: normal status: open title: Why does http.client.HTTPResponse._safe_read use MAXAMOUNT versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 08:00:54 2019 From: report at bugs.python.org (Bruce Merry) Date: Wed, 20 Feb 2019 13:00:54 +0000 Subject: [issue36051] (Performance) Drop the GIL during large bytes.join operations? Message-ID: <1550667654.79.0.460473844528.issue36051@roundup.psfhosted.org> New submission from Bruce Merry : A common pattern in libraries doing I/O is to receive data in chunks, put them in a list, then join them all together using b"".join(chunks). For example, see http.client.HTTPResponse._safe_read. When the output is large, the memory copies can block the interpreter for a non-trivial amount of time, and prevent multi-threaded scaling. If the GIL could be dropped during the memcpys it could improve parallel I/O performance in some high-bandwidth scenarios (36050 mentions a case where I've run into this serialisation bottleneck in practice). Obviously it could hurt performance to drop the GIL for small cases. As far as I know numpy uses thresholds to decide when it's worth dropping the GIL and it seems to work fairly well. ---------- components: Interpreter Core messages: 336082 nosy: bmerry priority: normal severity: normal status: open title: (Performance) Drop the GIL during large bytes.join operations? versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 08:02:38 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 13:02:38 +0000 Subject: [issue35993] incorrect use of released memory in Python/pystate.c line 284 In-Reply-To: <1550126281.35.0.272027846904.issue35993@roundup.psfhosted.org> Message-ID: <1550667758.83.0.370079987876.issue35993@roundup.psfhosted.org> St?phane Wirtel added the comment: @eric Could you help me for the tests of my PR? Thank you ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 08:04:54 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 13:04:54 +0000 Subject: [issue35995] use SSL encrypted socket on logging.handlers.SMTPHandler In-Reply-To: <1550133946.82.0.233218933413.issue35995@roundup.psfhosted.org> Message-ID: <1550667894.68.0.104139262173.issue35995@roundup.psfhosted.org> St?phane Wirtel added the comment: @lidayan I think it's a misuse of the logging.handlers.SMTPHandler class. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 08:14:06 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Wed, 20 Feb 2019 13:14:06 +0000 Subject: [issue36049] No __repr__() for queue.PriorityQueue and queue.LifoQueue In-Reply-To: <1550657675.07.0.575320352135.issue36049@roundup.psfhosted.org> Message-ID: <1550668446.59.0.27723120099.issue36049@roundup.psfhosted.org> R?mi Lapeyre added the comment: Note: when repr do not round trip, I think it's common practice to use brackets: instead of: LifoQueue('a'...'c') Example with Regex from https://docs.python.org/3/howto/regex.html: >>> re.match(r'From\s+', 'From amk Thu May 14 19:12:10 1998') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 08:17:11 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 13:17:11 +0000 Subject: [issue36049] No __repr__() for queue.PriorityQueue and queue.LifoQueue In-Reply-To: <1550657675.07.0.575320352135.issue36049@roundup.psfhosted.org> Message-ID: <1550668631.61.0.441885361946.issue36049@roundup.psfhosted.org> St?phane Wirtel added the comment: Fixed ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 08:18:24 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Wed, 20 Feb 2019 13:18:24 +0000 Subject: [issue36051] (Performance) Drop the GIL during large bytes.join operations? In-Reply-To: <1550667654.79.0.460473844528.issue36051@roundup.psfhosted.org> Message-ID: <1550668704.57.0.862526116281.issue36051@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 09:10:16 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 Feb 2019 14:10:16 +0000 Subject: [issue36049] No __repr__() for queue.PriorityQueue and queue.LifoQueue In-Reply-To: <1550657675.07.0.575320352135.issue36049@roundup.psfhosted.org> Message-ID: <1550671816.02.0.599875025062.issue36049@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 09:20:00 2019 From: report at bugs.python.org (SilentGhost) Date: Wed, 20 Feb 2019 14:20:00 +0000 Subject: [issue36051] Drop the GIL during large bytes.join operations? In-Reply-To: <1550667654.79.0.460473844528.issue36051@roundup.psfhosted.org> Message-ID: <1550672400.42.0.583886836116.issue36051@roundup.psfhosted.org> Change by SilentGhost : ---------- title: (Performance) Drop the GIL during large bytes.join operations? -> Drop the GIL during large bytes.join operations? type: -> performance versions: +Python 3.8 -Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 09:24:07 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Wed, 20 Feb 2019 14:24:07 +0000 Subject: [issue36049] No __repr__() for queue.PriorityQueue and queue.LifoQueue In-Reply-To: <1550657675.07.0.575320352135.issue36049@roundup.psfhosted.org> Message-ID: <1550672647.46.0.11177027801.issue36049@roundup.psfhosted.org> R?mi Lapeyre added the comment: See also https://bugs.python.org/issue35889 which add repr to sqlite3.Row ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 09:27:25 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Feb 2019 14:27:25 +0000 Subject: [issue35993] incorrect use of released memory in Python/pystate.c line 284 In-Reply-To: <1550126281.35.0.272027846904.issue35993@roundup.psfhosted.org> Message-ID: <1550672845.19.0.467358393068.issue35993@roundup.psfhosted.org> STINNER Victor added the comment: New changeset b5409dacc4885146a27d06482b346e55fa12d2ec by Victor Stinner (St?phane Wirtel) in branch 'master': bpo-35993: Fix _PyInterpreterState_DeleteExceptMain() (GH-11852) https://github.com/python/cpython/commit/b5409dacc4885146a27d06482b346e55fa12d2ec ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 09:30:15 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Feb 2019 14:30:15 +0000 Subject: [issue35993] incorrect use of released memory in Python/pystate.c line 284 In-Reply-To: <1550126281.35.0.272027846904.issue35993@roundup.psfhosted.org> Message-ID: <1550673015.81.0.552823928253.issue35993@roundup.psfhosted.org> STINNER Victor added the comment: Thanks wangjiangqiang for the bug report and thanks St?phane Wirtel for the fix! ---------- components: +Interpreter Core resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 09:31:58 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Feb 2019 14:31:58 +0000 Subject: [issue36021] [Security][Windows] webbrowser: WindowsDefault uses os.startfile() and so can be abused to run arbitrary commands In-Reply-To: <1550487653.15.0.496398912417.issue36021@roundup.psfhosted.org> Message-ID: <1550673118.53.0.628114338441.issue36021@roundup.psfhosted.org> STINNER Victor added the comment: > Windows has the GetBinaryTypeW function, this one is used by pywin32, maybe I could develop a wrapper in os, like os.is_executable(path) I don't think that it would detect .BAT or .VBS scripts as executable, whereas we don't want to execut such scripts with webbrowser. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 09:32:02 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 14:32:02 +0000 Subject: [issue34464] There are inconsitencies in the treatment of True, False, None, and __debug__ keywords in the docs In-Reply-To: <1534964930.72.0.56676864532.issue34464@psf.upfronthosting.co.za> Message-ID: <1550673122.12.0.654538692006.issue34464@roundup.psfhosted.org> St?phane Wirtel added the comment: Hi @David, Maybe we could remove 3.6 from the list because 3.6 is in security mode and not bugfix. Is there a security issue with this bug? ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 09:39:26 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 14:39:26 +0000 Subject: [issue36021] [Security][Windows] webbrowser: WindowsDefault uses os.startfile() and so can be abused to run arbitrary commands In-Reply-To: <1550487653.15.0.496398912417.issue36021@roundup.psfhosted.org> Message-ID: <1550673566.94.0.488676900588.issue36021@roundup.psfhosted.org> St?phane Wirtel added the comment: Sure we don't want to execute these kinds of scripts but we could mix with GetBinaryTypeW and add a check on the extensions. for example and simplified protocode if is_executable(path) or is_script(path): raise ... os.startfile(path) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 09:40:09 2019 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 Feb 2019 14:40:09 +0000 Subject: [issue36041] email: folding of quoted string in display_name violates RFC In-Reply-To: <1550594739.09.0.990893515193.issue36041@roundup.psfhosted.org> Message-ID: <1550673609.93.0.101860937471.issue36041@roundup.psfhosted.org> R. David Murray added the comment: I'm afraid I don't have time to parse through the file you uploaded. Can you produce a pull request or a diff showing your fix? And ideally some added tests :) But whatever you can do is great, if you don't have time maybe someone else will pick it up (I unfortunately don't have time, though I should be able to do a review of a PR). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 09:48:53 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Feb 2019 14:48:53 +0000 Subject: [issue36021] [Security][Windows] webbrowser: WindowsDefault uses os.startfile() and so can be abused to run arbitrary commands In-Reply-To: <1550487653.15.0.496398912417.issue36021@roundup.psfhosted.org> Message-ID: <1550674133.61.0.409206569904.issue36021@roundup.psfhosted.org> STINNER Victor added the comment: > Sure we don't want to execute these kinds of scripts but we could mix with GetBinaryTypeW and add a check on the extensions. Windows has a convenient feature: if you ask to run "program", Windows tries to run "program.exe", "program.bat", etc. Example: --- C:\vstinner>del hello.txt C:\vstinner>type hello.bat echo "Hello from hello.bat" > /vstinner/hello.txt C:\vstinner>\vstinner\python\master\python Python 3.8.0a0 (heads/master:8f59ee01be, Jan 25 2019, 01:16:59) [MSC v.1915 64 bit (AMD64)] on win32 >>> import os >>> os.startfile(r"c:\vstinner\hello") >>> with open(r"c:\vstinner\hello.txt") as fp: print(fp.read()) ... "Hello from hello.bat" --- os.startfile(r"c:\vstinner\hello") <= "hello" filename has no extension ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 09:49:42 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 14:49:42 +0000 Subject: [issue36035] pathlib.Path().rglob() breaks with broken symlinks In-Reply-To: <1550578197.02.0.381973172531.issue36035@roundup.psfhosted.org> Message-ID: <1550674182.49.0.520458529823.issue36035@roundup.psfhosted.org> St?phane Wirtel added the comment: 3.5 is in security mode, we can remove 3.5 from the list for this issue. ---------- versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 10:02:06 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Feb 2019 15:02:06 +0000 Subject: [issue36021] [Security][Windows] webbrowser: WindowsDefault uses os.startfile() and so can be abused to run arbitrary commands In-Reply-To: <1550487653.15.0.496398912417.issue36021@roundup.psfhosted.org> Message-ID: <1550674926.64.0.0673196129735.issue36021@roundup.psfhosted.org> STINNER Victor added the comment: Maybe webbrowser must be changed to become *very strict*. For example, raise an error if the URL doesn't start with "http://" or "https://". But add an option to opt-in for "unsafe" URLs with a warning in the doc to explain the risk on Windows? Another option is to add an optional callback to validate the URL. As the 'verify' parameter of logging.config.listen(): https://docs.python.org/dev/library/logging.config.html#logging.config.listen "pydoc -b" runs a local HTTP server but it uses regular "http://" URLs, it doesn't use file://. Maybe only Windows should be modified, Unix is safe, no? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 10:09:57 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 15:09:57 +0000 Subject: [issue36021] [Security][Windows] webbrowser: WindowsDefault uses os.startfile() and so can be abused to run arbitrary commands In-Reply-To: <1550487653.15.0.496398912417.issue36021@roundup.psfhosted.org> Message-ID: <1550675397.96.0.729083925306.issue36021@roundup.psfhosted.org> St?phane Wirtel added the comment: +1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 10:14:07 2019 From: report at bugs.python.org (Eryk Sun) Date: Wed, 20 Feb 2019 15:14:07 +0000 Subject: [issue36021] [Security][Windows] webbrowser: WindowsDefault uses os.startfile() and so can be abused to run arbitrary commands In-Reply-To: <1550487653.15.0.496398912417.issue36021@roundup.psfhosted.org> Message-ID: <1550675647.71.0.999320226496.issue36021@roundup.psfhosted.org> Eryk Sun added the comment: > Windows has the GetBinaryTypeW function ShellExecute[Ex] doesn't check for a PE image. It uses the file extension, and a tangled web of registry settings to determine what to execute. If a file should run directly via CreateProcess, you'll find the template command starts with the target file ("%1" or "%L"). For example: >>> AssocQueryStringW(ASSOCF_INIT_IGNOREUNKNOWN, ASSOCSTR_COMMAND, ... '.exe', 'open', command, n) 0 >>> print(command.value) "%1" %* OTOH, a script requires an interpreter, e.g for .py files: >>> AssocQueryStringW(ASSOCF_INIT_IGNOREUNKNOWN, ASSOCSTR_COMMAND, ... '.py', 'open', command, n) 0 >>> print(command.value) "C:\WINDOWS\py.exe" "%L" %* Except .bat and .cmd scripts are executed directly via the %ComSpec% interpreter: >>> AssocQueryStringW(ASSOCF_INIT_IGNOREUNKNOWN, ASSOCSTR_COMMAND, ... '.bat', 'open', command, n) 0 >>> print(command.value) "%1" %* One bit of metadata we can check is the file's "PerceivedType": unknown=0, text, image, audio, video, compressed, document, system, application, game-media, contacts. If a file's type is unknown (0), system (7), or application (8), or if getting the type fails, we probably don't want to run it. For example: >>> _ = AssocGetPerceivedType(".txt", ptype, flags, None); print(ptype[0]) 1 >>> _ = AssocGetPerceivedType(".jpg", ptype, flags, None); print(ptype[0]) 2 >>> _ = AssocGetPerceivedType(".mp3", ptype, flags, None); print(ptype[0]) 3 >>> _ = AssocGetPerceivedType(".mp4", ptype, flags, None); print(ptype[0]) 4 >>> _ = AssocGetPerceivedType(".zip", ptype, flags, None); print(ptype[0]) 5 >>> _ = AssocGetPerceivedType(".html", ptype, flags, None); print(ptype[0]) 6 >>> _ = AssocGetPerceivedType(".sys", ptype, flags, None); print(ptype[0]) 7 >>> _ = AssocGetPerceivedType(".exe", ptype, flags, None); print(ptype[0]) 8 >>> _ = AssocGetPerceivedType(".com", ptype, flags, None); print(ptype[0]) 8 >>> _ = AssocGetPerceivedType(".bat", ptype, flags, None); print(ptype[0]) 8 >>> _ = AssocGetPerceivedType(".cmd", ptype, flags, None); print(ptype[0]) 8 Except for a small number of hard-code definitions, the PerceivedType has to be defined for a filetype, and it's optional. It gets set either in the file-extension key under [HKCU|HKLM]\Software\Classes, or in the SystemFileAssocations subkey, or probably in 10 other locations sprawled across the registry. Python's installer doesn't set the PerceivedType of .py files to the application type (8), but it should. Another bit of metadata is the MIME "Content Type". This is also optional information provided in a filetype definition. For example: >>> AssocQueryStringW(ASSOCF_INIT_IGNOREUNKNOWN, ASSOCSTR_CONTENTTYPE, ... '.exe', 'open', mtype, n) 0 >>> print(mtype.value) application/x-msdownload >>> AssocQueryStringW(ASSOCF_INIT_IGNOREUNKNOWN, ASSOCSTR_CONTENTTYPE, ... '.html', 'open', mtype, n) 0 >>> print(mtype.value) text/html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 10:18:58 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 Feb 2019 15:18:58 +0000 Subject: [issue34464] There are inconsitencies in the treatment of True, False, None, and __debug__ keywords in the docs In-Reply-To: <1534964930.72.0.56676864532.issue34464@psf.upfronthosting.co.za> Message-ID: <1550675938.99.0.0120479234941.issue34464@roundup.psfhosted.org> Serhiy Storchaka added the comment: __debug__ is not a keyword. And the error message has been changed in 3.8. But it is a special enough. You can not use this name in any assignment context: >>> __debug__ = 1 File "", line 1 SyntaxError: cannot assign to __debug__ >>> for __debug__ in []: pass ... File "", line 1 SyntaxError: cannot assign to __debug__ >>> with cm() as __debug__: pass ... File "", line 1 SyntaxError: cannot assign to __debug__ >>> class __debug__: pass ... File "", line 1 SyntaxError: cannot assign to __debug__ >>> def __debug__(): pass ... File "", line 1 SyntaxError: cannot assign to __debug__ >>> def foo(__debug__): pass ... File "", line 1 SyntaxError: cannot assign to __debug__ >>> import __debug__ File "", line 1 SyntaxError: cannot assign to __debug__ You can not even assign to an attribute named __debug__! >>> x.__debug__ = 1 File "", line 1 SyntaxError: cannot assign to __debug__ The assignment operator is the only exception here, and this looks like a bug. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 10:23:36 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 Feb 2019 15:23:36 +0000 Subject: [issue36052] Assignment operator allows to assign to __debug__ Message-ID: <1550676216.29.0.487544148429.issue36052@roundup.psfhosted.org> New submission from Serhiy Storchaka : All ways of assigning to __debug__ are forbidden: >>> __debug__ = 1 File "", line 1 SyntaxError: cannot assign to __debug__ >>> for __debug__ in []: pass ... File "", line 1 SyntaxError: cannot assign to __debug__ >>> with cm() as __debug__: pass ... File "", line 1 SyntaxError: cannot assign to __debug__ >>> class __debug__: pass ... File "", line 1 SyntaxError: cannot assign to __debug__ >>> def __debug__(): pass ... File "", line 1 SyntaxError: cannot assign to __debug__ >>> def foo(__debug__): pass ... File "", line 1 SyntaxError: cannot assign to __debug__ >>> import __debug__ File "", line 1 SyntaxError: cannot assign to __debug__ The only exception is the assignment operator. >>> (__debug__ := 'spam') 'spam' >>> globals()['__debug__'] 'spam' This looks like a bug. ---------- components: Interpreter Core messages: 336100 nosy: emilyemorehouse, gvanrossum, serhiy.storchaka priority: normal severity: normal status: open title: Assignment operator allows to assign to __debug__ type: behavior versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 10:24:05 2019 From: report at bugs.python.org (Pierre Glaser) Date: Wed, 20 Feb 2019 15:24:05 +0000 Subject: [issue35933] python doc does not say that the state kwarg in Pickler.save_reduce can be a tuple (and not only a dict) In-Reply-To: <1549562122.06.0.315178283617.issue35933@roundup.psfhosted.org> Message-ID: <1550676245.71.0.975518910576.issue35933@roundup.psfhosted.org> Change by Pierre Glaser : ---------- keywords: +patch pull_requests: +11981 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 10:28:31 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 20 Feb 2019 15:28:31 +0000 Subject: [issue36021] [Security][Windows] webbrowser: WindowsDefault uses os.startfile() and so can be abused to run arbitrary commands In-Reply-To: <1550487653.15.0.496398912417.issue36021@roundup.psfhosted.org> Message-ID: <1550676511.04.0.0365301790658.issue36021@roundup.psfhosted.org> Steve Dower added the comment: > Maybe webbrowser must be changed to become *very strict*. This is the only acceptable suggestion I've seen (since my suggestion ;) ) I'd propose making it very strict by *requiring* a browser to be detected. So remove the os.startfile default and always require Chrome/Edge/etc. to be found. If they're not, you get an exception. Personally, I'd hate this behaviour :) But for my cases I'd just switch to os.startfile unconditionally (as I only use this in my own scripts and not libraries). One other thing to factor in is that if you use os.startfile to launch a malicious program, it will first be scanned by any anti-malware or antivirus software, and likely also by Windows SmartScreen. So you're not exactly getting arbitrary execution. It also only runs in the context of the current user, so there's not necessarily any escalation here. All in all, I'd label this a vulnerability in applications that use webbrowser.open(), rather than in webbrowser.open() itself. The function is doing exactly what it is told, and if someone is passing untrusted input, then they'll get the exact untrusted output they expect. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 10:31:31 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 Feb 2019 15:31:31 +0000 Subject: [issue35933] python doc does not say that the state kwarg in Pickler.save_reduce can be a tuple (and not only a dict) In-Reply-To: <1549562122.06.0.315178283617.issue35933@roundup.psfhosted.org> Message-ID: <1550676691.85.0.839457025477.issue35933@roundup.psfhosted.org> Serhiy Storchaka added the comment: A slotted class will have a dict also when it inherits it from a non-slotted class. This is why the base class of slotted class should have slots if you do not want an instance dict. __getstate__ and __setstate__ for slotted classes are described in PEP 307. Unfortunately this was not copied to the module documentation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 10:39:07 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 15:39:07 +0000 Subject: [issue36052] Assignment operator allows to assign to __debug__ In-Reply-To: <1550676216.29.0.487544148429.issue36052@roundup.psfhosted.org> Message-ID: <1550677147.62.0.280070424627.issue36052@roundup.psfhosted.org> St?phane Wirtel added the comment: An idea for the fix? a direction where I could find the solution? ;-) ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 10:41:40 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 Feb 2019 15:41:40 +0000 Subject: [issue36052] Assignment operator allows to assign to __debug__ In-Reply-To: <1550676216.29.0.487544148429.issue36052@roundup.psfhosted.org> Message-ID: <1550677300.45.0.478742580345.issue36052@roundup.psfhosted.org> Serhiy Storchaka added the comment: You need to add for the target of the assignment operator the same check as for other targets. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 10:41:42 2019 From: report at bugs.python.org (Pierre Glaser) Date: Wed, 20 Feb 2019 15:41:42 +0000 Subject: [issue35933] python doc does not say that the state kwarg in Pickler.save_reduce can be a tuple (and not only a dict) In-Reply-To: <1549562122.06.0.315178283617.issue35933@roundup.psfhosted.org> Message-ID: <1550677302.32.0.102296500976.issue35933@roundup.psfhosted.org> Pierre Glaser added the comment: I added a PR with a small patch to document this behavior and reconcile _pickle.c and pickle.py Some explanations on why I am pushing this forward: Pickling instances of classes/subclasses with slots is done natively for pickle protocol >= 2. Mentioning this behavior in the docs should *not* make the user worry about implementing custom __getstate__ methods just to preserve slots. Here is the reason why I think this functionality (allowing state and slotstate) is worth documenting: pickle gives us a lot of flexibility for reducing thanks to the dispatch_table. But unpickling is rather rigid: if no __setstate__ exists, we have to deal with the default state updating procedure present in load_build. Might as well document all of it ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 10:46:30 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 Feb 2019 15:46:30 +0000 Subject: [issue35933] python doc does not say that the state kwarg in Pickler.save_reduce can be a tuple (and not only a dict) In-Reply-To: <1549562122.06.0.315178283617.issue35933@roundup.psfhosted.org> Message-ID: <1550677590.84.0.148148392799.issue35933@roundup.psfhosted.org> Serhiy Storchaka added the comment: See also issue26579 which propose to add a function or method for standard implementation of __getstate__ and use it consistently in custom __getstate__ implementations. I am not sure about API yet. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 10:54:36 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 Feb 2019 15:54:36 +0000 Subject: [issue36048] Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__ In-Reply-To: <1550644985.32.0.26417547244.issue36048@roundup.psfhosted.org> Message-ID: <1550678076.66.0.681479669046.issue36048@roundup.psfhosted.org> Serhiy Storchaka added the comment: I am not sure what to with the int constructor. Should it try __index__ before __int__? Or just make __index__ without __int__ setting the nb_int slot as was proposed by Nick in issue33039? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 10:58:21 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Wed, 20 Feb 2019 15:58:21 +0000 Subject: [issue36000] __debug__ is a keyword but not a keyword In-Reply-To: <1550233328.67.0.392552434895.issue36000@roundup.psfhosted.org> Message-ID: <1550678301.81.0.960474441854.issue36000@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 11:07:01 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 16:07:01 +0000 Subject: [issue36052] Assignment operator allows to assign to __debug__ In-Reply-To: <1550676216.29.0.487544148429.issue36052@roundup.psfhosted.org> Message-ID: <1550678821.69.0.426064228709.issue36052@roundup.psfhosted.org> St?phane Wirtel added the comment: ok, I will check for the assignment operator in the code. maybe in the AST (Python-ast.c) but I think not ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 11:07:20 2019 From: report at bugs.python.org (Aaryn Tonita) Date: Wed, 20 Feb 2019 16:07:20 +0000 Subject: [issue36041] email: folding of quoted string in display_name violates RFC In-Reply-To: <1550594739.09.0.990893515193.issue36041@roundup.psfhosted.org> Message-ID: <1550678840.82.0.368177579928.issue36041@roundup.psfhosted.org> Aaryn Tonita added the comment: Sure thing, I'll try to produce something tomorrow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 11:17:01 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 16:17:01 +0000 Subject: [issue36052] Assignment operator allows to assign to __debug__ In-Reply-To: <1550676216.29.0.487544148429.issue36052@roundup.psfhosted.org> Message-ID: <1550679421.75.0.719332334467.issue36052@roundup.psfhosted.org> St?phane Wirtel added the comment: ok, I found the commit of @emily 8f59ee01be3d83d5513a9a3f654a237d77d80d9a and will try to find the assignment operator := ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 11:37:07 2019 From: report at bugs.python.org (Piotr Karkut) Date: Wed, 20 Feb 2019 16:37:07 +0000 Subject: [issue36053] pkgutil.walk_packages jumps out from given path if there is package with the same name in sys.pah Message-ID: <1550680627.64.0.854320242724.issue36053@roundup.psfhosted.org> New submission from Piotr Karkut : When walk_packages encounter a package with a name that is available in sys.path, it will abandon the current package, and start walking the package from the sys.path. Consider this file layout: ``` PYTHONPATH/ ???package1/ | ???core | | ???some_package/ | | | ???__init__.py | | | ???mod.py | | ???__init__.py | ???__init__.py ???some_package/ | ???__init__.py | ???another_mod.py ???__init__.py ``` The result of walking package1 will be: ``` >> pkgutil.walk_packages('PYTHONPATH/package1') ModuleInfo(module_finder=FileFinder('PYTHONPATH/package1/core'), name='some_package', ispkg=True) ModuleInfo(module_finder=FileFinder('PYTHONPATH/some_package), name='another_mod', ispkg=False) ``` I'm not sure if it is a security issue, but it definitely should not jump off the given path. ---------- components: Library (Lib) messages: 336111 nosy: karkucik priority: normal severity: normal status: open title: pkgutil.walk_packages jumps out from given path if there is package with the same name in sys.pah type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 11:41:17 2019 From: report at bugs.python.org (Emily Morehouse) Date: Wed, 20 Feb 2019 16:41:17 +0000 Subject: [issue36052] Assignment operator allows to assign to __debug__ In-Reply-To: <1550676216.29.0.487544148429.issue36052@roundup.psfhosted.org> Message-ID: <1550680877.47.0.479089061407.issue36052@roundup.psfhosted.org> Emily Morehouse added the comment: You should look in Python/ast.c. The naming convention follows some form of "named expression" (e.g. NamedExpr, ast_for_namedexpr). I'll have more time to look later this week, but let me know if you have any questions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 11:42:04 2019 From: report at bugs.python.org (Piotr Karkut) Date: Wed, 20 Feb 2019 16:42:04 +0000 Subject: [issue36053] pkgutil.walk_packages jumps out from given path if there is package with the same name in sys.path In-Reply-To: <1550680627.64.0.854320242724.issue36053@roundup.psfhosted.org> Message-ID: <1550680924.48.0.799838210204.issue36053@roundup.psfhosted.org> Change by Piotr Karkut : ---------- title: pkgutil.walk_packages jumps out from given path if there is package with the same name in sys.pah -> pkgutil.walk_packages jumps out from given path if there is package with the same name in sys.path _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 11:44:14 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 16:44:14 +0000 Subject: [issue36052] Assignment operator allows to assign to __debug__ In-Reply-To: <1550676216.29.0.487544148429.issue36052@roundup.psfhosted.org> Message-ID: <1550681054.37.0.352625527742.issue36052@roundup.psfhosted.org> St?phane Wirtel added the comment: Hi @emily Thank you for your help. In fact, I have started to read Python-ast.c and ast.c, they are the main files for this kind of operations. Thank you again, ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 11:44:56 2019 From: report at bugs.python.org (Piotr Karkut) Date: Wed, 20 Feb 2019 16:44:56 +0000 Subject: [issue36053] pkgutil.walk_packages jumps out from given path if there is package with the same name in sys.path In-Reply-To: <1550680627.64.0.854320242724.issue36053@roundup.psfhosted.org> Message-ID: <1550681096.92.0.846419565503.issue36053@roundup.psfhosted.org> Change by Piotr Karkut : ---------- keywords: +patch pull_requests: +11982 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 11:47:01 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 Feb 2019 16:47:01 +0000 Subject: [issue36049] No __repr__() for queue.PriorityQueue and queue.LifoQueue In-Reply-To: <1550657675.07.0.575320352135.issue36049@roundup.psfhosted.org> Message-ID: <1550681221.93.0.846652702776.issue36049@roundup.psfhosted.org> Serhiy Storchaka added the comment: I guess you hurried to write the code. It has not yet been decided whether to expose the content of the queue in its repr at all. There is no public API for accessing the content of the queue without removing items from the queue, and I think it is intentional. What is your use case? Why you need to change the repr of queues? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 11:47:51 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 16:47:51 +0000 Subject: [issue36052] Assignment operator allows to assign to __debug__ In-Reply-To: <1550676216.29.0.487544148429.issue36052@roundup.psfhosted.org> Message-ID: <1550681271.64.0.323762770418.issue36052@roundup.psfhosted.org> Change by St?phane Wirtel : ---------- assignee: -> matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 11:50:19 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 Feb 2019 16:50:19 +0000 Subject: [issue36052] Assignment operator allows to assign to __debug__ In-Reply-To: <1550676216.29.0.487544148429.issue36052@roundup.psfhosted.org> Message-ID: <1550681419.46.0.344935137531.issue36052@roundup.psfhosted.org> Serhiy Storchaka added the comment: Look at compile.c. The code for restricting other assignments is located here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 11:52:38 2019 From: report at bugs.python.org (Zahash Z) Date: Wed, 20 Feb 2019 16:52:38 +0000 Subject: [issue36049] No __repr__() for queue.PriorityQueue and queue.LifoQueue In-Reply-To: <1550681221.93.0.846652702776.issue36049@roundup.psfhosted.org> Message-ID: Zahash Z added the comment: If you look at the queue.PriorityQueue class, there is self.queue = [ ]. That's because priority queue uses list data structure to implement the min heap data structure (on which priority queue is based on). So the list can be represented. There is no need to remove anything. On Wed, 20 Feb 2019, 10:17 pm Serhiy Storchaka, wrote: > > Serhiy Storchaka added the comment: > > I guess you hurried to write the code. It has not yet been decided whether > to expose the content of the queue in its repr at all. There is no public > API for accessing the content of the queue without removing items from the > queue, and I think it is intentional. > > What is your use case? Why you need to change the repr of queues? > > ---------- > nosy: +serhiy.storchaka > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 11:53:11 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Wed, 20 Feb 2019 16:53:11 +0000 Subject: [issue36052] Assignment operator allows to assign to __debug__ In-Reply-To: <1550676216.29.0.487544148429.issue36052@roundup.psfhosted.org> Message-ID: <1550681591.38.0.0806445301648.issue36052@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- keywords: +patch pull_requests: +11984 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 11:56:22 2019 From: report at bugs.python.org (Keir Lawson) Date: Wed, 20 Feb 2019 16:56:22 +0000 Subject: [issue36054] Way to detect CPU count inside docker container Message-ID: <1550681782.39.0.211832814896.issue36054@roundup.psfhosted.org> New submission from Keir Lawson : There appears to be no way to detect the number of CPUs allotted to a Python program within a docker container. With the following script: import os print("os.cpu_count(): " + str(os.cpu_count())) print("len(os.sched_getaffinity(0)): " + str(len(os.sched_getaffinity(0)))) when run in a container (from an Ubuntu 18.04 host) I get: docker run -v "$PWD":/src/ -w /src/ --cpus=1 python:3.7 python detect_cpus.py os.cpu_count(): 4 len(os.sched_getaffinity(0)): 4 Recent vesions of Java are able to correctly detect the CPU allocation: docker run -it --cpus 1 openjdk:10-jdk Feb 20, 2019 4:20:29 PM java.util.prefs.FileSystemPreferences$1 run INFO: Created user preferences directory. | Welcome to JShell -- Version 10.0.2 | For an introduction type: /help intro jshell> Runtime.getRuntime().availableProcessors() $1 ==> 1 ---------- components: Library (Lib) messages: 336117 nosy: keirlawson priority: normal severity: normal status: open title: Way to detect CPU count inside docker container type: performance versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 11:56:41 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 20 Feb 2019 16:56:41 +0000 Subject: [issue36049] No __repr__() for queue.PriorityQueue and queue.LifoQueue In-Reply-To: <1550657675.07.0.575320352135.issue36049@roundup.psfhosted.org> Message-ID: <1550681801.36.0.445257163732.issue36049@roundup.psfhosted.org> Raymond Hettinger added the comment: [Zahash Z] (Zahash Z)] > If you look at the queue.PriorityQueue class, there is > self.queue = [ ]. We really don't want to expose the internals here. They are subject to change and access to them is guarded by locks. > It has not yet been decided whether to expose the content > of the queue in its repr at all. There is no public API for > accessing the content of the queue without removing items > from the queue, and I think it is intentional. I agree with Serhiy. Let's close this feature request. It doesn't make sense for queues and is at odds with their design and intended uses. ---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 11:59:10 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 20 Feb 2019 16:59:10 +0000 Subject: [issue35956] Sort documentation could be improved for complex sorting In-Reply-To: <1549816419.03.0.97544553945.issue35956@roundup.psfhosted.org> Message-ID: <1550681950.36.0.144397406447.issue35956@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 12:01:17 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 17:01:17 +0000 Subject: [issue36052] Assignment operator allows to assign to __debug__ In-Reply-To: <1550676216.29.0.487544148429.issue36052@roundup.psfhosted.org> Message-ID: <1550682077.93.0.886312754429.issue36052@roundup.psfhosted.org> Change by St?phane Wirtel : ---------- pull_requests: +11985 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 12:01:19 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Wed, 20 Feb 2019 17:01:19 +0000 Subject: [issue36052] Assignment operator allows to assign to __debug__ In-Reply-To: <1550676216.29.0.487544148429.issue36052@roundup.psfhosted.org> Message-ID: <1550682079.25.0.274189949996.issue36052@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: When I started working on this I did not notice the extra comments here. I will close my PR so St?phane can do the PR. ---------- nosy: +pablogsal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 12:05:51 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 20 Feb 2019 17:05:51 +0000 Subject: [issue36039] Replace append loops with list comprehensions In-Reply-To: <1550592309.68.0.760031675356.issue36039@roundup.psfhosted.org> Message-ID: <1550682351.75.0.991080068336.issue36039@roundup.psfhosted.org> Raymond Hettinger added the comment: I concur with all the other -1 comments and will mark this a closed. FWIW, we generally discourage sweeping across the library with minor rewrites. Guido articulated a principle of "holistic refactoring" where we make code improvements while working on the module as a whole. This helps makes sure that code changes are made in the context of a thorough understanding of what the module is trying to do. This also helps us reduce maintenance-induced-bugs where minor code adjustments create new bugs that weren't there before. Thank you for taking a look at the source and please continue to do so. If you find a specific case that is problematic, feel free to post that one particular case. That said, a better use of time is to take one of the many open tracker issues, research it, and propose a fix. ---------- nosy: +rhettinger resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 12:06:48 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 Feb 2019 17:06:48 +0000 Subject: [issue36042] Setting __init_subclass__ and __class_getitem__ methods are in runtime doesnt make them class method. In-Reply-To: <1550596795.62.0.0325313661294.issue36042@roundup.psfhosted.org> Message-ID: <1550682408.63.0.606287260833.issue36042@roundup.psfhosted.org> Serhiy Storchaka added the comment: I don't like complicating the code and adding a performance penalty to support such uncommon case. The documentation for __class_getitem__ precisely describes the current behavior: "when defined in the class body, this method is implicitly a class method". Nothing should be changed here. The documentation for __init_subclass__ could be rewritten in similar words. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 12:07:16 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 17:07:16 +0000 Subject: [issue36049] No __repr__() for queue.PriorityQueue and queue.LifoQueue In-Reply-To: <1550657675.07.0.575320352135.issue36049@roundup.psfhosted.org> Message-ID: <1550682436.25.0.236830634062.issue36049@roundup.psfhosted.org> St?phane Wirtel added the comment: Hi @rhettinger Thank you for the review of this issue. ---------- resolution: rejected -> stage: resolved -> patch review status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 12:08:35 2019 From: report at bugs.python.org (Ivan Levkivskyi) Date: Wed, 20 Feb 2019 17:08:35 +0000 Subject: [issue36042] Setting __init_subclass__ and __class_getitem__ methods are in runtime doesnt make them class method. In-Reply-To: <1550596795.62.0.0325313661294.issue36042@roundup.psfhosted.org> Message-ID: <1550682515.42.0.826420528559.issue36042@roundup.psfhosted.org> Ivan Levkivskyi added the comment: I totally agree with Serhiy ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 12:09:53 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 17:09:53 +0000 Subject: [issue36052] Assignment operator allows to assign to __debug__ In-Reply-To: <1550676216.29.0.487544148429.issue36052@roundup.psfhosted.org> Message-ID: <1550682593.9.0.0288247567619.issue36052@roundup.psfhosted.org> St?phane Wirtel added the comment: Thank you Pablo, if I see you at PyCon, maybe we could drink a good beer ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 12:10:58 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 Feb 2019 17:10:58 +0000 Subject: [issue36049] No __repr__() for queue.PriorityQueue and queue.LifoQueue In-Reply-To: <1550657675.07.0.575320352135.issue36049@roundup.psfhosted.org> Message-ID: <1550682658.34.0.470389466654.issue36049@roundup.psfhosted.org> Serhiy Storchaka added the comment: If you treat the "queue" attribute as a part the public API, just use repr(q.queue) instead of repr(q). ---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 12:12:51 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 17:12:51 +0000 Subject: [issue36054] Way to detect CPU count inside docker container In-Reply-To: <1550681782.39.0.211832814896.issue36054@roundup.psfhosted.org> Message-ID: <1550682771.07.0.652815774235.issue36054@roundup.psfhosted.org> St?phane Wirtel added the comment: I would like to work on this issue. ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 12:14:30 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Wed, 20 Feb 2019 17:14:30 +0000 Subject: [issue36048] Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__ In-Reply-To: <1550644985.32.0.26417547244.issue36048@roundup.psfhosted.org> Message-ID: <1550682870.87.0.75275280823.issue36048@roundup.psfhosted.org> R?mi Lapeyre added the comment: > I am not sure what to with the int constructor. Should it try __index__ before __int__? Or just make __index__ without __int__ setting the nb_int slot as was proposed by Nick in issue33039? Shouldn't it try only __int__ since this will default to __index__ once #33039 is closed? ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 12:26:46 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 20 Feb 2019 17:26:46 +0000 Subject: [issue36049] No __repr__() for queue.PriorityQueue and queue.LifoQueue In-Reply-To: <1550657675.07.0.575320352135.issue36049@roundup.psfhosted.org> Message-ID: <1550683606.26.0.607329360352.issue36049@roundup.psfhosted.org> Raymond Hettinger added the comment: > It has not yet been decided whether to expose the content > of the queue in its repr at all. There is no public API for > accessing the content of the queue without removing items > from the queue, and I think it is intentional. I agree with Serhiy. Let's close this feature request. It doesn't make sense for queues and is at odds with their design and intended uses. There are a number of places where making a less opaque repr is helpful, but iterators and queues have a temporal aspect where this doesn't make sense. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 12:29:26 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 20 Feb 2019 17:29:26 +0000 Subject: [issue36012] Investigate slow writes to class variables In-Reply-To: <1550348118.4.0.228746523417.issue36012@roundup.psfhosted.org> Message-ID: <1550683766.9.0.178494277048.issue36012@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset d8b9e1fc2e45d2bc3f4a9737c375f2adb8a8c7de by Raymond Hettinger (Stefan Behnel) in branch 'master': bpo-36012: Avoid linear slot search for non-dunder methods (GH-11907) https://github.com/python/cpython/commit/d8b9e1fc2e45d2bc3f4a9737c375f2adb8a8c7de ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 12:29:55 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 20 Feb 2019 17:29:55 +0000 Subject: [issue36012] Investigate slow writes to class variables In-Reply-To: <1550348118.4.0.228746523417.issue36012@roundup.psfhosted.org> Message-ID: <1550683795.73.0.343487930216.issue36012@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 12:30:00 2019 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 Feb 2019 17:30:00 +0000 Subject: [issue34464] There are inconsitencies in the treatment of True, False, None, and __debug__ keywords in the docs In-Reply-To: <1534964930.72.0.56676864532.issue34464@psf.upfronthosting.co.za> Message-ID: <1550683800.42.0.927592868332.issue34464@roundup.psfhosted.org> Change by R. David Murray : ---------- versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 12:55:19 2019 From: report at bugs.python.org (Berry Schoenmakers) Date: Wed, 20 Feb 2019 17:55:19 +0000 Subject: [issue36027] Support negative exponents in pow() where a modulus is specified. In-Reply-To: <1550520659.43.0.126744170658.issue36027@roundup.psfhosted.org> Message-ID: <1550685319.72.0.0544943617576.issue36027@roundup.psfhosted.org> Berry Schoenmakers added the comment: In pure Python this seems to be the better option to compute inverses: def modinv(a, m): # assuming m > 0 b = m s, s1 = 1, 0 while b: a, (q, b) = b, divmod(a, b) s, s1 = s1, s - q * s1 if a != 1: raise ValueError('inverse does not exist') return s if s >= 0 else s + m Binary xgcd algorithms coded in pure Python run much slower. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 12:59:37 2019 From: report at bugs.python.org (Michael Felt) Date: Wed, 20 Feb 2019 17:59:37 +0000 Subject: [issue35828] test_multiprocessing_fork - crashes in PyDict_GetItem - segmentation error In-Reply-To: <1548421607.34.0.921297585279.issue35828@roundup.psfhosted.org> Message-ID: <1550685577.51.0.930856435194.issue35828@roundup.psfhosted.org> Michael Felt added the comment: I am still trying to get further with this, but I won't get far enough without some help on how to best dig deeper. For one, it should be leaving a core dump, but it never seems to leave the core dump in the working directory. I know it is doing core dump because the "errpt" system tells me it is. Further, anyone who can help me better understand messages such as: Warning -- Dangling processes: {, } All I can figure out is that the "parent" process has children that "die". Is there anything useful in the SpawnProcess name info? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 13:04:41 2019 From: report at bugs.python.org (Marcelo Marotta) Date: Wed, 20 Feb 2019 18:04:41 +0000 Subject: [issue36055] Division using math.pow and math.log approximation fails Message-ID: <1550685881.68.0.81295097869.issue36055@roundup.psfhosted.org> New submission from Marcelo Marotta : Steps to reproduce the error >>> import math >>> 1/math.log(math.pow(30,0.5),2) == 2/math.log(30,2) True >>> 1/math.log(math.pow(9,0.5),2) == 2/math.log(9,2) True >>> 1/math.log(math.pow(15,0.5),2) == 2/math.log(15,2) True >>> 1/math.log(math.pow(8,0.5),2) == 2/math.log(8,2) False >>> 2/math.log(8,2) 0.6666666666666666 >>> 1/math.log(math.pow(8,0.5),2) 0.6666666666666665 I reproduced the error in Python : Python 3.5.3 and Python 2.7.13 ---------- components: Library (Lib) messages: 336132 nosy: Marcelo Marotta priority: normal severity: normal status: open title: Division using math.pow and math.log approximation fails type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 13:11:00 2019 From: report at bugs.python.org (Michael Felt) Date: Wed, 20 Feb 2019 18:11:00 +0000 Subject: [issue35828] test_multiprocessing_fork - crashes in PyDict_GetItem - segmentation error In-Reply-To: <1548421607.34.0.921297585279.issue35828@roundup.psfhosted.org> Message-ID: <1550686260.28.0.609327490338.issue35828@roundup.psfhosted.org> Michael Felt added the comment: Another message that surprises me is: Warning -- multiprocessing.process._dangling was modified by test_multiprocessing_spawn Before: <_weakrefset.WeakSet object at 0x3076e810> After: <_weakrefset.WeakSet object at 0x3076e390> Normally speaking the address 0x30000000 and higher should be "out of bounds" aka a SEGV - unless special actions are taken to open a memory region above 0x2fffffff - for default AIX memory model. Just calling malloc(), afaik, does not do automatically create a new memory section (0x0000000-0x0fffffff is reserved for kernel CODE, 0x10000000-0x1fffffff is reserved for application CODE, and 0x20000000-0x2fffffff is .data,.bss, "empty aka not-active", .stack). The area between .end_bss and .stack is the area that sbrk() provides memory from (for calls to malloc(), e.g.) In short, is there something I do not know understand about Python object pointers that 0x30000000+ values are actually living in 0x20000000-0x2fffffff space? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 13:14:49 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Wed, 20 Feb 2019 18:14:49 +0000 Subject: [issue36055] Division using math.pow and math.log approximation fails In-Reply-To: <1550685881.68.0.81295097869.issue36055@roundup.psfhosted.org> Message-ID: <1550686489.61.0.395800472814.issue36055@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +mark.dickinson, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 13:16:19 2019 From: report at bugs.python.org (Michael Felt) Date: Wed, 20 Feb 2019 18:16:19 +0000 Subject: [issue35828] test_multiprocessing_fork - crashes in PyDict_GetItem - segmentation error In-Reply-To: <1548421607.34.0.921297585279.issue35828@roundup.psfhosted.org> Message-ID: <1550686579.72.0.774370711077.issue35828@roundup.psfhosted.org> Michael Felt added the comment: Also - this looks like a core dump was 'seen', but later removed. Warning -- files was modified by test_multiprocessing_forkserver Before: [] After: ['core'] What can I change so that ot does not cleanup the core file? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 13:23:20 2019 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 20 Feb 2019 18:23:20 +0000 Subject: [issue36055] Division using math.pow and math.log approximation fails In-Reply-To: <1550685881.68.0.81295097869.issue36055@roundup.psfhosted.org> Message-ID: <1550687000.0.0.263780613849.issue36055@roundup.psfhosted.org> Mark Dickinson added the comment: This isn't a bug: floating-point arithmetic is by its nature approximate, and two sequences of operations that would mathematically give the same result need not give the same result with floating-point. I'd recommend a read of this portion of the tutorial, which goes into some of the issues involved: https://docs.python.org/3/tutorial/floatingpoint.html Having said that, you'll get slightly better accuracy in general (one can't make specific guarantees, since everything's dependent on the platform's math library) if you use `math.sqrt(x)` instead of `math.pow(x, 0.5)`, and `math.log2(y)` instead of `math.log(y, 2)`. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 13:52:44 2019 From: report at bugs.python.org (SilentGhost) Date: Wed, 20 Feb 2019 18:52:44 +0000 Subject: [issue36046] support dropping privileges when running subprocesses In-Reply-To: <1550625858.55.0.53498127684.issue36046@roundup.psfhosted.org> Message-ID: <1550688764.99.0.417096358171.issue36046@roundup.psfhosted.org> Change by SilentGhost : ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 14:02:21 2019 From: report at bugs.python.org (Dylan Lloyd) Date: Wed, 20 Feb 2019 19:02:21 +0000 Subject: [issue36056] importlib does not support pathlib Message-ID: <1550689341.22.0.769543209454.issue36056@roundup.psfhosted.org> New submission from Dylan Lloyd : ``` ? python -c 'import pathlib; import importlib; importlib.import_module(pathlib.Path("poc.py"))' Traceback (most recent call last): File "", line 1, in File "~/.conda/envs/py3.6/lib/python3.6/importlib/__init__.py", line 117, in import_module if name.startswith('.'): AttributeError: 'PosixPath' object has no attribute 'startswith' ``` ---------- components: Library (Lib) messages: 336136 nosy: majuscule priority: normal severity: normal status: open title: importlib does not support pathlib versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 14:08:54 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Wed, 20 Feb 2019 19:08:54 +0000 Subject: [issue36056] importlib does not support pathlib In-Reply-To: <1550689341.22.0.769543209454.issue36056@roundup.psfhosted.org> Message-ID: <1550689734.5.0.389389982712.issue36056@roundup.psfhosted.org> R?mi Lapeyre added the comment: This is also present in 3.7 and 3.8. I would look at it and propose a patch tomorrow. ---------- nosy: +remi.lapeyre versions: +Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 14:13:46 2019 From: report at bugs.python.org (Berker Peksag) Date: Wed, 20 Feb 2019 19:13:46 +0000 Subject: [issue36056] importlib does not support pathlib In-Reply-To: <1550689341.22.0.769543209454.issue36056@roundup.psfhosted.org> Message-ID: <1550690026.35.0.114586567306.issue36056@roundup.psfhosted.org> Berker Peksag added the comment: Thanks for the report, but importlib.import_module() doesn't accept a path of a Python module: https://docs.python.org/3/library/importlib.html#importlib.import_module So, the correct way to use the API is: import importlib importlib.import_module('poc') Whether we should explicitly reject passing a file path to import_module() is up to the importlib maintainers. ---------- nosy: +berker.peksag, brett.cannon -remi.lapeyre resolution: -> not a bug stage: -> resolved status: open -> pending type: -> enhancement versions: -Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 14:14:06 2019 From: report at bugs.python.org (Berker Peksag) Date: Wed, 20 Feb 2019 19:14:06 +0000 Subject: [issue36056] importlib does not support pathlib In-Reply-To: <1550689341.22.0.769543209454.issue36056@roundup.psfhosted.org> Message-ID: <1550690046.15.0.140981710398.issue36056@roundup.psfhosted.org> Change by Berker Peksag : ---------- nosy: +remi.lapeyre status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 14:31:44 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 Feb 2019 19:31:44 +0000 Subject: [issue36056] importlib does not support pathlib In-Reply-To: <1550689341.22.0.769543209454.issue36056@roundup.psfhosted.org> Message-ID: <1550691104.51.0.504349820967.issue36056@roundup.psfhosted.org> Serhiy Storchaka added the comment: I concur with Berker. Since the argument of importlib.import_module() is not a path, pathlib.Path is not valid here. It is uncommon in Python to check the type of arguments explicitly. pathlib.Path is not more special than list or tkinter.Button. ---------- nosy: +serhiy.storchaka status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 14:35:08 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 20 Feb 2019 19:35:08 +0000 Subject: [issue36020] HAVE_SNPRINTF and MSVC std::snprintf support In-Reply-To: <1550485106.18.0.506219958256.issue36020@roundup.psfhosted.org> Message-ID: <1550691308.28.0.551771649598.issue36020@roundup.psfhosted.org> Steve Dower added the comment: Start by just deleting the definitions in pyerrors.h, and see where the build fails. Then either switch those to use PyOS_snprintf (best), or add the #ifndef checks in the source files (not header files) that need them. Be aware that we shouldn't backport the deletion from the headers to 3.7. Backporting the code changes to use the PyOS_* functions is fine though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 14:38:11 2019 From: report at bugs.python.org (Diego Rojas) Date: Wed, 20 Feb 2019 19:38:11 +0000 Subject: [issue3991] urllib.request.urlopen does not handle non-ASCII characters In-Reply-To: <1222627636.82.0.587488225038.issue3991@psf.upfronthosting.co.za> Message-ID: <1550691491.15.0.172869760962.issue3991@roundup.psfhosted.org> Change by Diego Rojas : ---------- components: +Extension Modules -Library (Lib), Unicode type: enhancement -> behavior versions: +Python 3.4, Python 3.5, Python 3.6, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 14:41:00 2019 From: report at bugs.python.org (Dylan Lloyd) Date: Wed, 20 Feb 2019 19:41:00 +0000 Subject: [issue36056] importlib does not support pathlib In-Reply-To: <1550689341.22.0.769543209454.issue36056@roundup.psfhosted.org> Message-ID: <1550691660.46.0.58820440589.issue36056@roundup.psfhosted.org> Dylan Lloyd added the comment: Whoops, yes, that of course makes sense. My mistake. Thanks! ---------- resolution: not a bug -> status: closed -> open type: enhancement -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 14:50:37 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Wed, 20 Feb 2019 19:50:37 +0000 Subject: [issue36030] add internal API function to create tuple without items array initialization In-Reply-To: <1550563364.86.0.164811838679.issue36030@roundup.psfhosted.org> Message-ID: <1550692237.93.0.0945179386033.issue36030@roundup.psfhosted.org> Sergey Fedoseev added the comment: Here's benchmarks for PyTuple_FromArray() PR: $ python -m perf timeit -s "l = [None]*0; tuple_ = tuple" "tuple_(l)" --duplicate=100 --compare-to=../cpython-master/venv/bin/python /home/sergey/tmp/cpython-master/venv/bin/python: ..................... 50.5 ns +- 1.0 ns /home/sergey/tmp/cpython-dev/venv/bin/python: ..................... 45.6 ns +- 1.2 ns Mean +- std dev: [/home/sergey/tmp/cpython-master/venv/bin/python] 50.5 ns +- 1.0 ns -> [/home/sergey/tmp/cpython-dev/venv/bin/python] 45.6 ns +- 1.2 ns: 1.11x faster (-10%) $ python -m perf timeit -s "l = [None]*1; tuple_ = tuple" "tuple_(l)" --duplicate=100 --compare-to=../cpython-master/venv/bin/python /home/sergey/tmp/cpython-master/venv/bin/python: ..................... 61.8 ns +- 1.1 ns /home/sergey/tmp/cpython-dev/venv/bin/python: ..................... 54.8 ns +- 0.8 ns Mean +- std dev: [/home/sergey/tmp/cpython-master/venv/bin/python] 61.8 ns +- 1.1 ns -> [/home/sergey/tmp/cpython-dev/venv/bin/python] 54.8 ns +- 0.8 ns: 1.13x faster (-11%) $ python -m perf timeit -s "l = [None]*5; tuple_ = tuple" "tuple_(l)" --duplicate=100 --compare-to=../cpython-master/venv/bin/python /home/sergey/tmp/cpython-master/venv/bin/python: ..................... 68.2 ns +- 1.3 ns /home/sergey/tmp/cpython-dev/venv/bin/python: ..................... 61.8 ns +- 1.5 ns Mean +- std dev: [/home/sergey/tmp/cpython-master/venv/bin/python] 68.2 ns +- 1.3 ns -> [/home/sergey/tmp/cpython-dev/venv/bin/python] 61.8 ns +- 1.5 ns: 1.10x faster (-9%) $ python -m perf timeit -s "l = [None]*10; tuple_ = tuple" "tuple_(l)" --duplicate=100 --compare-to=../cpython-master/venv/bin/python /home/sergey/tmp/cpython-master/venv/bin/python: ..................... 88.1 ns +- 2.3 ns /home/sergey/tmp/cpython-dev/venv/bin/python: ..................... 78.9 ns +- 3.1 ns Mean +- std dev: [/home/sergey/tmp/cpython-master/venv/bin/python] 88.1 ns +- 2.3 ns -> [/home/sergey/tmp/cpython-dev/venv/bin/python] 78.9 ns +- 3.1 ns: 1.12x faster (-10%) $ python -m perf timeit -s "l = [None]*100; tuple_ = tuple" "tuple_(l)" --duplicate=100 --compare-to=../cpython-master/venv/bin/python /home/sergey/tmp/cpython-master/venv/bin/python: ..................... 477 ns +- 7 ns /home/sergey/tmp/cpython-dev/venv/bin/python: ..................... 452 ns +- 6 ns Mean +- std dev: [/home/sergey/tmp/cpython-master/venv/bin/python] 477 ns +- 7 ns -> [/home/sergey/tmp/cpython-dev/venv/bin/python] 452 ns +- 6 ns: 1.05x faster (-5%) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 14:52:28 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 19:52:28 +0000 Subject: [issue36056] importlib does not support pathlib In-Reply-To: <1550689341.22.0.769543209454.issue36056@roundup.psfhosted.org> Message-ID: <1550692348.71.0.704242373748.issue36056@roundup.psfhosted.org> St?phane Wirtel added the comment: I close this issue, it's not a bug. ---------- nosy: +matrixise status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 14:53:36 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Wed, 20 Feb 2019 19:53:36 +0000 Subject: [issue35840] Control flow inconsistency on closed asyncio stream In-Reply-To: <1548662045.39.0.770532095049.issue35840@roundup.psfhosted.org> Message-ID: <1550692416.61.0.835102468426.issue35840@roundup.psfhosted.org> Emmanuel Arias added the comment: I think that this issue is just for Windows right? I add Windows to required a Windows' dev. ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 14:54:40 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 19:54:40 +0000 Subject: [issue36049] No __repr__() for queue.PriorityQueue and queue.LifoQueue In-Reply-To: <1550657675.07.0.575320352135.issue36049@roundup.psfhosted.org> Message-ID: <1550692480.5.0.277800668759.issue36049@roundup.psfhosted.org> St?phane Wirtel added the comment: Hi @rhettinger and @serhiy Really sorry, I did not see that I have re-opened the issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 15:02:12 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Wed, 20 Feb 2019 20:02:12 +0000 Subject: [issue3991] urllib.request.urlopen does not handle non-ASCII characters In-Reply-To: <1222627636.82.0.587488225038.issue3991@psf.upfronthosting.co.za> Message-ID: <1550692932.62.0.914154781422.issue3991@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 15:15:06 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 20:15:06 +0000 Subject: [issue36054] Way to detect CPU count inside docker container In-Reply-To: <1550681782.39.0.211832814896.issue36054@roundup.psfhosted.org> Message-ID: <1550693706.59.0.520095378981.issue36054@roundup.psfhosted.org> St?phane Wirtel added the comment: so, I have also tested with the last docker image of golang. > docker run --rm --cpus 1 -it golang /bin/bash here is the code of golang: package main import "fmt" import "runtime" func main() { cores := runtime.NumCPU() fmt.Printf("This machine has %d CPU cores.\n", cores) } Here is the output > ./demo This machine has 4 CPU cores. When I try with grep on /proc/cpuinfo I get this result > grep processor /proc/cpuinfo -c 4 I will test with openjdk because it's related to Java and see if I can get the result of 1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 15:15:54 2019 From: report at bugs.python.org (Brett Cannon) Date: Wed, 20 Feb 2019 20:15:54 +0000 Subject: [issue36029] Use consistent case for HTTP header fields In-Reply-To: <1550529210.49.0.526576386821.issue36029@roundup.psfhosted.org> Message-ID: <1550693754.34.0.267914793203.issue36029@roundup.psfhosted.org> Brett Cannon added the comment: As stated on the PR, changing the code isn't going to be worth it, but updating the docs would be nice. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 15:17:35 2019 From: report at bugs.python.org (Brett Cannon) Date: Wed, 20 Feb 2019 20:17:35 +0000 Subject: [issue29757] The loop in utility `socket.create_connection()` swallows previous errors In-Reply-To: <1488984317.87.0.296010902983.issue29757@psf.upfronthosting.co.za> Message-ID: <1550693855.06.0.878379312565.issue29757@roundup.psfhosted.org> Change by Brett Cannon : ---------- nosy: -brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 15:18:18 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Feb 2019 20:18:18 +0000 Subject: [issue36054] Way to detect CPU count inside docker container In-Reply-To: <1550681782.39.0.211832814896.issue36054@roundup.psfhosted.org> Message-ID: <1550693898.86.0.453345209085.issue36054@roundup.psfhosted.org> St?phane Wirtel added the comment: ok, I didn't see your test with openjdk:10, sorry ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 15:24:27 2019 From: report at bugs.python.org (Keir Lawson) Date: Wed, 20 Feb 2019 20:24:27 +0000 Subject: [issue36054] Way to detect CPU count inside docker container In-Reply-To: <1550681782.39.0.211832814896.issue36054@roundup.psfhosted.org> Message-ID: <1550694267.54.0.313145097492.issue36054@roundup.psfhosted.org> Keir Lawson added the comment: I believe this is related to this ticket: https://bugs.python.org/issue26692 Looking at Java's implementation it seems like they are checking if cgroups are enabled via /proc/self/cgroup and then if it is parsing the cgroup information out of the filesystem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 15:25:03 2019 From: report at bugs.python.org (Brett Cannon) Date: Wed, 20 Feb 2019 20:25:03 +0000 Subject: [issue36035] pathlib.Path().rglob() breaks with broken symlinks In-Reply-To: <1550578197.02.0.381973172531.issue36035@roundup.psfhosted.org> Message-ID: <1550694303.42.0.428933023263.issue36035@roundup.psfhosted.org> Brett Cannon added the comment: I consider this an enhancement since you do have a loop in your symlinks and so having it not exactly work isn't totally shocking. But that doesn't mean that if someone can come up with a reasonable solution to fixing this annoyance it woudn't be accepted or appreciated! ---------- nosy: +brett.cannon type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 15:26:03 2019 From: report at bugs.python.org (Brett Cannon) Date: Wed, 20 Feb 2019 20:26:03 +0000 Subject: [issue36035] pathlib.Path().rglob() breaks with broken symlinks In-Reply-To: <1550578197.02.0.381973172531.issue36035@roundup.psfhosted.org> Message-ID: <1550694363.8.0.830647591137.issue36035@roundup.psfhosted.org> Brett Cannon added the comment: And I don't know what a good solution would be. :) I.e. should some other exception be raised? Should it be ignored? I just don't know personally. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 16:01:42 2019 From: report at bugs.python.org (Berker Peksag) Date: Wed, 20 Feb 2019 21:01:42 +0000 Subject: [issue36056] importlib does not support pathlib In-Reply-To: <1550689341.22.0.769543209454.issue36056@roundup.psfhosted.org> Message-ID: <1550696502.72.0.850033541316.issue36056@roundup.psfhosted.org> Change by Berker Peksag : ---------- resolution: -> not a bug type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 16:21:11 2019 From: report at bugs.python.org (Alexey Izbyshev) Date: Wed, 20 Feb 2019 21:21:11 +0000 Subject: [issue36046] support dropping privileges when running subprocesses In-Reply-To: <1550625858.55.0.53498127684.issue36046@roundup.psfhosted.org> Message-ID: <1550697671.04.0.383700242871.issue36046@roundup.psfhosted.org> Change by Alexey Izbyshev : ---------- nosy: +izbyshev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 16:42:18 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 20 Feb 2019 21:42:18 +0000 Subject: =?utf-8?q?=5Bissue31982=5D_8=2E3=2E_collections_=E2=80=94_Container_datat?= =?utf-8?q?ypes?= In-Reply-To: <1510157451.94.0.213398074469.issue31982@psf.upfronthosting.co.za> Message-ID: <1550698938.91.0.0260996064421.issue31982@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- keywords: +patch pull_requests: +11986 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 16:49:26 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 20 Feb 2019 21:49:26 +0000 Subject: =?utf-8?q?=5Bissue31982=5D_8=2E3=2E_collections_=E2=80=94_Container_datat?= =?utf-8?q?ypes?= In-Reply-To: <1510157451.94.0.213398074469.issue31982@psf.upfronthosting.co.za> Message-ID: <1550699366.65.0.0181331978111.issue31982@roundup.psfhosted.org> miss-islington added the comment: New changeset 9b0c681e2d7e708a07e34d9c08e4424bdd4f5ebc by Miss Islington (bot) (Raymond Hettinger) in branch 'master': bpo-31982: Improve sequence of presentation in ChainMap docs (GH-11960) https://github.com/python/cpython/commit/9b0c681e2d7e708a07e34d9c08e4424bdd4f5ebc ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 16:49:59 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 20 Feb 2019 21:49:59 +0000 Subject: =?utf-8?q?=5Bissue31982=5D_8=2E3=2E_collections_=E2=80=94_Container_datat?= =?utf-8?q?ypes?= In-Reply-To: <1510157451.94.0.213398074469.issue31982@psf.upfronthosting.co.za> Message-ID: <1550699399.15.0.0852841682171.issue31982@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11987 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 17:23:38 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 20 Feb 2019 22:23:38 +0000 Subject: =?utf-8?q?=5Bissue31982=5D_8=2E3=2E_collections_=E2=80=94_Container_datat?= =?utf-8?q?ypes?= In-Reply-To: <1510157451.94.0.213398074469.issue31982@psf.upfronthosting.co.za> Message-ID: <1550701418.29.0.79440346567.issue31982@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 14baf06febb9194dd76f694ec359ce94708ed861 by Raymond Hettinger (Miss Islington (bot)) in branch '3.7': bpo-31982: Improve sequence of presentation in ChainMap docs (GH-11960) (GH-11961) https://github.com/python/cpython/commit/14baf06febb9194dd76f694ec359ce94708ed861 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 17:25:43 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 20 Feb 2019 22:25:43 +0000 Subject: =?utf-8?q?=5Bissue31982=5D_8=2E3=2E_collections_=E2=80=94_Container_datat?= =?utf-8?q?ypes?= In-Reply-To: <1510157451.94.0.213398074469.issue31982@psf.upfronthosting.co.za> Message-ID: <1550701543.6.0.34784990015.issue31982@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 18:54:25 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 20 Feb 2019 23:54:25 +0000 Subject: [issue18823] Idle: use pipes instead of sockets to talk with user subprocess In-Reply-To: <1377300904.13.0.124289838176.issue18823@psf.upfronthosting.co.za> Message-ID: <1550706865.81.0.105992633139.issue18823@roundup.psfhosted.org> Terry J. Reedy added the comment: #34313 reports problems with multiprocessing when using at least some versions of tkinter on some versions of macOS. ---------- versions: +Python 3.8 -Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 18:59:18 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 20 Feb 2019 23:59:18 +0000 Subject: [issue13659] Add a help() viewer for IDLE's Shell. In-Reply-To: <1324707815.11.0.534121320744.issue13659@psf.upfronthosting.co.za> Message-ID: <1550707158.05.0.210061443174.issue13659@roundup.psfhosted.org> Terry J. Reedy added the comment: #1529353 added squeezer, making this alternative unnecessary. Once squeezed, output can be opened in a text viewer. ---------- resolution: -> out of date stage: patch review -> resolved status: open -> closed superseder: -> Squeezer - squeeze large output in IDLE's shell _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 19:10:05 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 21 Feb 2019 00:10:05 +0000 Subject: [issue36057] Add docs and tests for ordering in Counter. [no behavior change] Message-ID: <1550707805.37.0.515933023482.issue36057@roundup.psfhosted.org> New submission from Raymond Hettinger : When dicts became ordered, counters became ordered as well. Update the docs and tests to reflect that fact. ---------- assignee: rhettinger components: Tests messages: 336156 nosy: rhettinger priority: normal severity: normal status: open title: Add docs and tests for ordering in Counter. [no behavior change] versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 19:12:32 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Thu, 21 Feb 2019 00:12:32 +0000 Subject: [issue36057] Add docs and tests for ordering in Counter. [no behavior change] In-Reply-To: <1550707805.37.0.515933023482.issue36057@roundup.psfhosted.org> Message-ID: <1550707952.84.0.370338467293.issue36057@roundup.psfhosted.org> Emmanuel Arias added the comment: Hi! I will take it :-) ---------- nosy: +eamanu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 19:14:30 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Thu, 21 Feb 2019 00:14:30 +0000 Subject: [issue36057] Add docs and tests for ordering in Counter. [no behavior change] In-Reply-To: <1550707805.37.0.515933023482.issue36057@roundup.psfhosted.org> Message-ID: <1550708070.8.0.228696996782.issue36057@roundup.psfhosted.org> Change by Emmanuel Arias : ---------- components: +Documentation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 19:17:42 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 21 Feb 2019 00:17:42 +0000 Subject: [issue36058] Improve file decoding before re.search Message-ID: <1550708262.6.0.970683874988.issue36058@roundup.psfhosted.org> New submission from Terry J. Reedy : Spin-off from #14929, which fixed crash. From msg161754: "The default extension is .py. The default encoding for .py files is utf-8. I think that is the default for what Idle writes. So I think this should be the default encoding (explicitly given) at least for .py files. >From msg161755: (but not sure about this) "Also, perhaps dialog box could have encodings field. People should be able to grep python code for any legal identifier, and this means proper decoding according to the encoding they actually use." ---------- assignee: terry.reedy components: IDLE messages: 336158 nosy: terry.reedy priority: normal severity: normal stage: test needed status: open title: Improve file decoding before re.search type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 19:18:44 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 21 Feb 2019 00:18:44 +0000 Subject: [issue14929] IDLE crashes on *Edit / Find in files ...* command In-Reply-To: <1338151641.58.0.68836434552.issue14929@psf.upfronthosting.co.za> Message-ID: <1550708324.15.0.489304506766.issue14929@roundup.psfhosted.org> Terry J. Reedy added the comment: Opened #36058 for followup. ---------- resolution: -> fixed stage: test needed -> resolved status: open -> closed superseder: -> Improve file decoding before re.search versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 19:19:11 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 21 Feb 2019 00:19:11 +0000 Subject: [issue36057] Add docs and tests for ordering in Counter. [no behavior change] In-Reply-To: <1550707805.37.0.515933023482.issue36057@roundup.psfhosted.org> Message-ID: <1550708351.2.0.0448448530998.issue36057@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- keywords: +patch pull_requests: +11988 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 19:20:07 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 21 Feb 2019 00:20:07 +0000 Subject: [issue36057] Add docs and tests for ordering in Counter. [no behavior change] In-Reply-To: <1550707805.37.0.515933023482.issue36057@roundup.psfhosted.org> Message-ID: <1550708407.16.0.442106636019.issue36057@roundup.psfhosted.org> Raymond Hettinger added the comment: > I will take it :-) Sorry, I've already assigned this to myself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 19:21:39 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 21 Feb 2019 00:21:39 +0000 Subject: [issue22704] Review extension enable options In-Reply-To: <1414023424.37.0.56141003135.issue22704@psf.upfronthosting.co.za> Message-ID: <1550708499.97.0.891389491057.issue22704@roundup.psfhosted.org> Terry J. Reedy added the comment: #27099 converted extensions to features always enabled for when they apply to. ---------- resolution: -> out of date stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 19:21:49 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Thu, 21 Feb 2019 00:21:49 +0000 Subject: [issue36057] Add docs and tests for ordering in Counter. [no behavior change] In-Reply-To: <1550707805.37.0.515933023482.issue36057@roundup.psfhosted.org> Message-ID: <1550708509.77.0.318059024669.issue36057@roundup.psfhosted.org> Emmanuel Arias added the comment: > Sorry, I've already assigned this to myself. Ah!! sorry sorry! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 19:26:29 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 21 Feb 2019 00:26:29 +0000 Subject: [issue36059] Update docs for OrderedDict to reflect that regular dicts are ordered Message-ID: <1550708789.68.0.789605857229.issue36059@roundup.psfhosted.org> New submission from Raymond Hettinger : Am working on a PR for this now. The goals are to clarify the distinction between OrderedDict and regular dict, to remove outdated examples that no longer are the best way to solve a problem, and to move, and to add examples where OrderedDict will continue to be relevant. ---------- assignee: rhettinger components: Documentation messages: 336163 nosy: rhettinger priority: normal severity: normal status: open title: Update docs for OrderedDict to reflect that regular dicts are ordered versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 19:30:26 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 21 Feb 2019 00:30:26 +0000 Subject: [issue22706] Idle extension configuration and key bindings In-Reply-To: <1414023453.7.0.681663520586.issue22706@psf.upfronthosting.co.za> Message-ID: <1550709026.94.0.888827654299.issue22706@roundup.psfhosted.org> Terry J. Reedy added the comment: #27099 (converting built-in extensions to features) made this less important. But it is still relevant to actual extensions. There is a dummy extension, zzdummy, for testing. ---------- stage: needs patch -> patch review versions: +Python 3.8 -Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 19:30:45 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 21 Feb 2019 00:30:45 +0000 Subject: [issue36060] Document how collections.ChainMap() determines iteration order Message-ID: <1550709045.44.0.467024509195.issue36060@roundup.psfhosted.org> New submission from Raymond Hettinger : Am working on a PR for this now. Prior to regular dicts becoming ordered, the was no expectation for ChainMap() to have any particular order. Now that such an expectation might exist, I need to document what ChainMap() does and perhaps why it does it. ---------- assignee: rhettinger components: Documentation messages: 336165 nosy: rhettinger priority: normal severity: normal status: open title: Document how collections.ChainMap() determines iteration order versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 19:31:27 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 21 Feb 2019 00:31:27 +0000 Subject: [issue36057] Add docs and tests for ordering in Counter. [no behavior change] In-Reply-To: <1550707805.37.0.515933023482.issue36057@roundup.psfhosted.org> Message-ID: <1550709087.63.0.0757046275965.issue36057@roundup.psfhosted.org> Raymond Hettinger added the comment: Emmanuel, feel free to review the PR and make suggestions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 19:32:40 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 21 Feb 2019 00:32:40 +0000 Subject: [issue22705] Idle extension configuration: add option-help option In-Reply-To: <1414023433.5.0.357242409854.issue22705@psf.upfronthosting.co.za> Message-ID: <1550709160.23.0.531360889153.issue22705@roundup.psfhosted.org> Terry J. Reedy added the comment: #27099 (converting built-in extensions to features) made this less important. But it is still relevant to actual extensions. There is a dummy extension, zzdummy, for testing. ---------- stage: needs patch -> patch review versions: +Python 3.8 -Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 19:33:04 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 21 Feb 2019 00:33:04 +0000 Subject: [issue1054041] Python doesn't exit with proper resultcode on SIGINT Message-ID: <1550709184.35.0.517090541614.issue1054041@roundup.psfhosted.org> Change by Gregory P. Smith : ---------- pull_requests: +11989 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 19:50:19 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 21 Feb 2019 00:50:19 +0000 Subject: [issue22629] Idle: update htest.py and htests In-Reply-To: <1413257630.76.0.367621064016.issue22629@psf.upfronthosting.co.za> Message-ID: <1550710219.18.0.234226856027.issue22629@roundup.psfhosted.org> Terry J. Reedy added the comment: As far as I can tell, the entire diff in @htest-34-2.diff was pushed. My comment about 'up to first line of grep' was correct alphabetically but confusing because files with a '# htest #' section were not completely alphabetical in the file. I need to review current code in light of this issue and a couple of others. ---------- versions: +Python 3.8 -Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 19:50:34 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Thu, 21 Feb 2019 00:50:34 +0000 Subject: [issue36035] pathlib.Path().rglob() breaks with broken symlinks In-Reply-To: <1550578197.02.0.381973172531.issue36035@roundup.psfhosted.org> Message-ID: <1550710234.39.0.609372484548.issue36035@roundup.psfhosted.org> Change by Emmanuel Arias : ---------- keywords: +patch pull_requests: +11990 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 20:08:46 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 21 Feb 2019 01:08:46 +0000 Subject: [issue22707] Idle: changed options should take effect immediately In-Reply-To: <1414023493.97.0.227461422456.issue22707@psf.upfronthosting.co.za> Message-ID: <1550711326.94.0.24156854151.issue22707@roundup.psfhosted.org> Terry J. Reedy added the comment: Turning extensions into features #27099 fixed many (all?) unnecessary delays but a few things should be checked, and the help texts reviewed. ---------- versions: +Python 3.8 -Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 20:10:36 2019 From: report at bugs.python.org (py.user) Date: Thu, 21 Feb 2019 01:10:36 +0000 Subject: [issue28235] In xml.etree.ElementTree docs there is no parser argument in fromstring() In-Reply-To: <1474457056.95.0.329737294315.issue28235@psf.upfronthosting.co.za> Message-ID: <1550711436.29.0.286671659739.issue28235@roundup.psfhosted.org> py.user added the comment: @Cheryl Sabella, I guess Manjusaka has done it already and this looks fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 20:47:47 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Thu, 21 Feb 2019 01:47:47 +0000 Subject: [issue22865] Document how to make pty.spawn not copy data In-Reply-To: <1415901686.09.0.50650588621.issue22865@psf.upfronthosting.co.za> Message-ID: <1550713667.38.0.536313201925.issue22865@roundup.psfhosted.org> Cheryl Sabella added the comment: @RadicalZephyr, are you interested in making a GitHub pull request with the recommended the documentation change? ---------- nosy: +cheryl.sabella versions: +Python 3.7, Python 3.8 -Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 20:59:30 2019 From: report at bugs.python.org (Shane Lee) Date: Thu, 21 Feb 2019 01:59:30 +0000 Subject: [issue36061] zipfile does not handle arcnames with non-ascii characters on Windows Message-ID: <1550714370.81.0.682374426913.issue36061@roundup.psfhosted.org> New submission from Shane Lee : Python 2.7.15 (probably affects newer versions as well) Given an archive with any number of files inside that have non-ascii characters in their filename `zipfile` will crash when extracting them to the file system. ``` Traceback (most recent call last): File "c:\dev\salt\salt\modules\archive.py", line 1081, in unzip zfile.extract(target, dest, password) File "c:\python27\lib\zipfile.py", line 1028, in extract return self._extract_member(member, path, pwd) File "c:\python27\lib\zipfile.py", line 1069, in _extract_member targetpath = os.path.join(targetpath, arcname) File "c:\python27\lib\ntpath.py", line 85, in join result_path = result_path + p_path UnicodeDecodeError: 'ascii' codec can't decode byte 0x82 in position 3: ordinal not in range(128) ``` ---------- components: Windows files: test.zip messages: 336172 nosy: Shane Lee, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: zipfile does not handle arcnames with non-ascii characters on Windows type: behavior versions: Python 2.7 Added file: https://bugs.python.org/file48159/test.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 21:08:56 2019 From: report at bugs.python.org (lidayan) Date: Thu, 21 Feb 2019 02:08:56 +0000 Subject: [issue35995] logging.handlers.SMTPHandler In-Reply-To: <1550134018.65.0.240962310466.issue35995@roundup.psfhosted.org> Message-ID: <5897D6DF-DA8A-4FDC-9B04-341D37A2C48E@qq.com> lidayan <840286247 at qq.com> added the comment: OK, I got it. > ? 2019?2?14??16:46?St?phane Wirtel ??? > > > St?phane Wirtel added the comment: > > You have a timeout, maybe you have an issue with your SMTP server. But in this case, it's not an issue with Python. > > ---------- > nosy: +matrixise > resolution: -> rejected > stage: -> resolved > status: open -> closed > > _______________________________________ > Python tracker > > _______________________________________ > ---------- title: use SSL encrypted socket on logging.handlers.SMTPHandler -> logging.handlers.SMTPHandler _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 21:19:01 2019 From: report at bugs.python.org (Roundup Robot) Date: Thu, 21 Feb 2019 02:19:01 +0000 Subject: [issue36061] zipfile does not handle arcnames with non-ascii characters on Windows In-Reply-To: <1550714370.81.0.682374426913.issue36061@roundup.psfhosted.org> Message-ID: <1550715541.9.0.500946078685.issue36061@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch pull_requests: +11991 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 21:23:45 2019 From: report at bugs.python.org (Graham Wideman) Date: Thu, 21 Feb 2019 02:23:45 +0000 Subject: [issue31136] raw strings cannot end with a backslash character r'\' In-Reply-To: <1502153449.52.0.763252325075.issue31136@psf.upfronthosting.co.za> Message-ID: <1550715825.27.0.121610048108.issue31136@roundup.psfhosted.org> Graham Wideman added the comment: Let us be clear here that this is NOT a case where the backslash escapes the subsequent quote. If it WAS such a case, then the sequence \' would leave only the quote in the output string. But it doesn't; it leaves the complete 2-character \' in the output string. So essentially this is a case of the character sequence \' being given a special status that causes that character pair to have a special meaning in preference to the meaning of the individual characters. So this IS a bug -- it may be "as designed", but that produces the bug in the name of this feature, "raw string", which is patently misleading and in violation of the principle of least surprise. This is a feature (as the FAQ explains) provided explicitly for developers of regular expression parsers. So at best, these r-strings should be called "regex-oriented" string literals, which can be used elsewhere, at risk of knowing this gotcha. ---------- nosy: +gwideman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 21:29:54 2019 From: report at bugs.python.org (Graham Wideman) Date: Thu, 21 Feb 2019 02:29:54 +0000 Subject: [issue31136] raw strings cannot end with a backslash character r'\' In-Reply-To: <1502153449.52.0.763252325075.issue31136@psf.upfronthosting.co.za> Message-ID: <1550716194.41.0.703761999796.issue31136@roundup.psfhosted.org> Graham Wideman added the comment: Demonstration: print("x" + r' \' ' + "x") produces x \' x Where is this behavior _ever_ useful? Or if there is some use case for this, how frequent is it compared to the frequency of users expecting either that backslash does nothing special, or that it would behave like an escape, and not appear in the output? I'm not here to suggest there's some easy fix for this. I just don't want this issue closing as "not a bug" and fail to register that this design is flawed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 21:38:09 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 21 Feb 2019 02:38:09 +0000 Subject: [issue33065] IDLE debugger: failure stepping through module loading In-Reply-To: <1520917336.65.0.467229070634.issue33065@psf.upfronthosting.co.za> Message-ID: <1550716689.08.0.961703470075.issue33065@roundup.psfhosted.org> Terry J. Reedy added the comment: A StackOverflow use got the same _ModuleLock message. https://stackoverflow.com/questions/54785596/debugger-in-python-freezes-over-own-built-modules ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 21:45:08 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Thu, 21 Feb 2019 02:45:08 +0000 Subject: [issue20687] Change in expectedFailure breaks testtools In-Reply-To: <1392834023.44.0.231798434214.issue20687@psf.upfronthosting.co.za> Message-ID: <1550717108.29.0.110897856537.issue20687@roundup.psfhosted.org> Cheryl Sabella added the comment: Larry suggested closing this as wontfix 5 years ago. Since testtools added code for this test and there hasn't been any other changes since, I'll close per his suggestion. ---------- nosy: +cheryl.sabella resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 22:04:15 2019 From: report at bugs.python.org (lidayan) Date: Thu, 21 Feb 2019 03:04:15 +0000 Subject: [issue35995] logging.handlers.SMTPHandler In-Reply-To: <5897D6DF-DA8A-4FDC-9B04-341D37A2C48E@qq.com> Message-ID: <0F594B6A-C92B-40C8-9A77-CE79E5B635D5@qq.com> lidayan <840286247 at qq.com> added the comment: And I have changed the code, please help to review, thanks > ? 2019?2?21??10:08???? <840286247 at qq.com> ??? > > OK, I got it. > > >> ? 2019?2?14??16:46?St?phane Wirtel ??? >> >> >> St?phane Wirtel added the comment: >> >> You have a timeout, maybe you have an issue with your SMTP server. But in this case, it's not an issue with Python. >> >> ---------- >> nosy: +matrixise >> resolution: -> rejected >> stage: -> resolved >> status: open -> closed >> >> _______________________________________ >> Python tracker >> >> _______________________________________ >> > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 22:20:43 2019 From: report at bugs.python.org (lidayan) Date: Thu, 21 Feb 2019 03:20:43 +0000 Subject: [issue35995] logging.handlers.SMTPHandler In-Reply-To: <1550133946.82.0.233218933413.issue35995@roundup.psfhosted.org> Message-ID: <1550719243.06.0.999928766518.issue35995@roundup.psfhosted.org> lidayan <840286247 at qq.com> added the comment: 1. When specify the secure flag to the SMTPHandler, means start TLS connection. 2. if SMTP Server not support plaintext mode, but firstly in plaintext mode it is a error ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 22:37:03 2019 From: report at bugs.python.org (=?utf-8?q?Carlos_Dam=C3=A1zio?=) Date: Thu, 21 Feb 2019 03:37:03 +0000 Subject: [issue35812] Don't log an exception from the main coroutine in asyncio.run() In-Reply-To: <1548291532.01.0.358121522852.issue35812@roundup.psfhosted.org> Message-ID: <1550720223.95.0.717776355862.issue35812@roundup.psfhosted.org> Carlos Dam?zio added the comment: Hey, Andrew. I'd like to work on the issue, if anyone else hasn't done it yet. ---------- nosy: +Carlos Dam?zio _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 23:01:04 2019 From: report at bugs.python.org (Eryk Sun) Date: Thu, 21 Feb 2019 04:01:04 +0000 Subject: [issue36035] pathlib.Path().rglob() breaks with broken symlinks In-Reply-To: <1550578197.02.0.381973172531.issue36035@roundup.psfhosted.org> Message-ID: <1550721664.47.0.431853728645.issue36035@roundup.psfhosted.org> Eryk Sun added the comment: In Windows, the error for a path reparse (e.g. symlink or junction) that can't be resolved is ERROR_CANT_RESOLVE_FILENAME. Another common error is ERROR_INVALID_REPARSE_DATA. This can occur if the reparse data is malformed or if the target device is invalid for the reparse type. For example, a junction is restricted to [bind-]mounting local volumes, so it's invalid if it targets a remote device. Windows errors to ignore should be added to _IGNORED_WINERRORS in Lib/pathlib.py. For example: _IGNORED_WINERRORS = ( # ... 1921, # ERROR_CANT_RESOLVE_FILENAME - similar to POSIX ELOOP 4392, # ERROR_INVALID_REPARSE_DATA - also for disallowed device targets ) ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 23:29:55 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 21 Feb 2019 04:29:55 +0000 Subject: [issue36059] Update docs for OrderedDict to reflect that regular dicts are ordered In-Reply-To: <1550708789.68.0.789605857229.issue36059@roundup.psfhosted.org> Message-ID: <1550723395.5.0.922177961606.issue36059@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- keywords: +patch pull_requests: +11992 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 20 23:30:57 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 21 Feb 2019 04:30:57 +0000 Subject: [issue36059] Update docs for OrderedDict to reflect that regular dicts are ordered In-Reply-To: <1550708789.68.0.789605857229.issue36059@roundup.psfhosted.org> Message-ID: <1550723457.58.0.742010146474.issue36059@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 00:25:04 2019 From: report at bugs.python.org (Davin Potts) Date: Thu, 21 Feb 2019 05:25:04 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1550726704.06.0.808688921006.issue35813@roundup.psfhosted.org> Davin Potts added the comment: The simpler API is now implemented in GH-11816 as discussed previously. Notably: > * We go with this simpler API: SharedMemory(name=None, create=False, size=0) > * 'size' is ignored when create=False > * create=True acts like O_CREX and create=False only attaches to existing shared memory blocks As part of this change, the PosixSharedMemory and WindowsNamedSharedMemory classes are no more; they have been consolidated into the SharedMemory class with a single, simpler, consistent-across-platforms API. On the SharedMemory class, 'size' is now stored by the __init__ and does not use fstat() as part of its property. Also, SharedMemoryManager (and its close friends) has been relocated to the multiprocessing.managers submodule, matching the organization @Giampaolo outlined previously: multiprocessing.managers.SharedMemoryManager multiprocessing.managers._SharedMemoryTracker multiprocessing.managers.SharedMemoryServer (not documented) multiprocessing.shared_memory.SharedMemory multiprocessing.shared_memory.SharedList multiprocessing.shared_memory.WindowsNamedSharedMemory (REMOVED) multiprocessing.shared_memory.PosixSharedMemory (REMOVED) I believe this addresses all of the significant discussion topics in a way that brings together all of the excellent points being made. Apologies if I have missed something -- I did not think so but I will go back through all of the discussions tomorrow to double-check. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 00:40:42 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 21 Feb 2019 05:40:42 +0000 Subject: [issue36061] zipfile does not handle arcnames with non-ascii characters on Windows In-Reply-To: <1550714370.81.0.682374426913.issue36061@roundup.psfhosted.org> Message-ID: <1550727642.36.0.0217432052701.issue36061@roundup.psfhosted.org> Serhiy Storchaka added the comment: You can not just add .decode('cp437') to arcname. 1. This will fail if the ZIP archive contains file names encoded with UTF-8. They are already unicode and contains non-ascii characters. For decode() they will be implicit encoded to str, that will fail. 2. This will fail when targetpath is a 8-bit string containing non-ascii characters. Currently this works (maybe incorrectly). 3. While cp437 is the only official encoding in ZIP archives if UTF-8 is not used, de facto different encodings (like cp866) are used on localized Windows. Fixing the problem without introducing other problems and breaking existing working code is hard. One possible solution is using Python 3. I suggest to close this issue as "won't fix". ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 01:25:11 2019 From: report at bugs.python.org (INADA Naoki) Date: Thu, 21 Feb 2019 06:25:11 +0000 Subject: [issue28328] statistics.geometric_mean has no tests. Defer to 3.7? In-Reply-To: <1475325234.65.0.257375698668.issue28328@psf.upfronthosting.co.za> Message-ID: <1550730311.58.0.587709423994.issue28328@roundup.psfhosted.org> Change by INADA Naoki : ---------- resolution: -> fixed stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 01:27:29 2019 From: report at bugs.python.org (INADA Naoki) Date: Thu, 21 Feb 2019 06:27:29 +0000 Subject: [issue29278] Python 3.6 build fails with parallel make In-Reply-To: <1484466246.11.0.873853911133.issue29278@psf.upfronthosting.co.za> Message-ID: <1550730449.62.0.118693968016.issue29278@roundup.psfhosted.org> Change by INADA Naoki : ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 01:30:09 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Thu, 21 Feb 2019 06:30:09 +0000 Subject: [issue36062] move index normalization from list_slice() to PyList_GetSlice() Message-ID: <1550730609.16.0.637453891919.issue36062@roundup.psfhosted.org> New submission from Sergey Fedoseev : list_slice() is used by PyList_GetSlice(), list_subscript() and for list copying. In list_subscript() slice indices are already normalized with PySlice_AdjustIndices(), so slice normalization currently performed in list_slice() is only needed for PyList_GetSlice(). Moving this normalization from list_slice() to PyList_GetSlice() provides minor speed-up for list copying and slicing: $ python -m perf timeit -s "copy = [].copy" "copy()" --duplicate=1000 --compare-to=../cpython-master/venv/bin/python /home/sergey/tmp/cpython-master/venv/bin/python: ..................... 26.5 ns +- 0.5 ns /home/sergey/tmp/cpython-dev/venv/bin/python: ..................... 25.7 ns +- 0.5 ns Mean +- std dev: [/home/sergey/tmp/cpython-master/venv/bin/python] 26.5 ns +- 0.5 ns -> [/home/sergey/tmp/cpython-dev/venv/bin/python] 25.7 ns +- 0.5 ns: 1.03x faster (-3%) $ python -m perf timeit -s "l = [1]" "l[:]" --duplicate=1000 --compare-to=../cpython-master/venv/bin/python /home/sergey/tmp/cpython-master/venv/bin/python: ..................... 71.5 ns +- 1.4 ns /home/sergey/tmp/cpython-dev/venv/bin/python: ..................... 70.2 ns +- 0.9 ns Mean +- std dev: [/home/sergey/tmp/cpython-master/venv/bin/python] 71.5 ns +- 1.4 ns -> [/home/sergey/tmp/cpython-dev/venv/bin/python] 70.2 ns +- 0.9 ns: 1.02x faster (-2%) ---------- messages: 336184 nosy: sir-sigurd priority: normal severity: normal status: open title: move index normalization from list_slice() to PyList_GetSlice() type: performance versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 01:34:52 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Thu, 21 Feb 2019 06:34:52 +0000 Subject: [issue36062] move index normalization from list_slice() to PyList_GetSlice() In-Reply-To: <1550730609.16.0.637453891919.issue36062@roundup.psfhosted.org> Message-ID: <1550730892.22.0.201154307309.issue36062@roundup.psfhosted.org> Change by Sergey Fedoseev : ---------- keywords: +patch pull_requests: +11993 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 01:34:58 2019 From: report at bugs.python.org (INADA Naoki) Date: Thu, 21 Feb 2019 06:34:58 +0000 Subject: [issue35822] _queue _queuemodule.c is missing inside the Setup file In-Reply-To: <1548374932.46.0.67529287669.issue35822@roundup.psfhosted.org> Message-ID: <1550730898.19.0.411061281775.issue35822@roundup.psfhosted.org> Change by INADA Naoki : ---------- resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 01:39:38 2019 From: report at bugs.python.org (Peixing Xin) Date: Thu, 21 Feb 2019 06:39:38 +0000 Subject: [issue31904] Python should support VxWorks RTOS In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za> Message-ID: <1550731178.83.0.850438530727.issue31904@roundup.psfhosted.org> Change by Peixing Xin : ---------- pull_requests: +11994 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 01:42:26 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 21 Feb 2019 06:42:26 +0000 Subject: [issue36060] Document how collections.ChainMap() determines iteration order In-Reply-To: <1550709045.44.0.467024509195.issue36060@roundup.psfhosted.org> Message-ID: <1550731346.13.0.148588334903.issue36060@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- keywords: +patch pull_requests: +11995 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 01:51:54 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 21 Feb 2019 06:51:54 +0000 Subject: [issue36062] move index normalization from list_slice() to PyList_GetSlice() In-Reply-To: <1550730609.16.0.637453891919.issue36062@roundup.psfhosted.org> Message-ID: <1550731914.8.0.606267161873.issue36062@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset ef1b88bf57aae93893d55f1b9c9639dbe9cc7786 by Serhiy Storchaka (Sergey Fedoseev) in branch 'master': bpo-36062: Minor speed-up for list slicing and copying. (GH-11967) https://github.com/python/cpython/commit/ef1b88bf57aae93893d55f1b9c9639dbe9cc7786 ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 01:57:02 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 21 Feb 2019 06:57:02 +0000 Subject: [issue36062] move index normalization from list_slice() to PyList_GetSlice() In-Reply-To: <1550730609.16.0.637453891919.issue36062@roundup.psfhosted.org> Message-ID: <1550732222.36.0.0201554378718.issue36062@roundup.psfhosted.org> Serhiy Storchaka added the comment: Nice! This is an example of good microoptimization. The performance gain is tiny (although measurable), but the cost is virtually zero: it does not increase code complexity and does not have side effects. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 01:59:15 2019 From: report at bugs.python.org (INADA Naoki) Date: Thu, 21 Feb 2019 06:59:15 +0000 Subject: [issue26787] test_distutils fails when configured --with-lto In-Reply-To: <1460874085.6.0.334729464026.issue26787@psf.upfronthosting.co.za> Message-ID: <1550732355.49.0.496112225444.issue26787@roundup.psfhosted.org> INADA Naoki added the comment: Fixed in bpo-35257 ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 02:47:17 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 21 Feb 2019 07:47:17 +0000 Subject: [issue33989] ms.key_compare is not initialized in all paths of list_sort_impl() In-Reply-To: <1530207786.09.0.56676864532.issue33989@psf.upfronthosting.co.za> Message-ID: <1550735237.27.0.381418914568.issue33989@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset ebc793d6acb9650b9f497808e059805892031d74 by Serhiy Storchaka (Zackery Spytz) in branch 'master': bpo-33989: Ensure that ms.key_compare is always initialized in list_sort_impl(). (GH-8710) https://github.com/python/cpython/commit/ebc793d6acb9650b9f497808e059805892031d74 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 02:47:27 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 21 Feb 2019 07:47:27 +0000 Subject: [issue33989] ms.key_compare is not initialized in all paths of list_sort_impl() In-Reply-To: <1530207786.09.0.56676864532.issue33989@psf.upfronthosting.co.za> Message-ID: <1550735247.63.0.849927476691.issue33989@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11996 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 03:05:26 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 21 Feb 2019 08:05:26 +0000 Subject: [issue33989] ms.key_compare is not initialized in all paths of list_sort_impl() In-Reply-To: <1530207786.09.0.56676864532.issue33989@psf.upfronthosting.co.za> Message-ID: <1550736326.75.0.835732627432.issue33989@roundup.psfhosted.org> miss-islington added the comment: New changeset 0e73ea26a55abc0ce2ee1153e5509bcaef4736cf by Miss Islington (bot) in branch '3.7': bpo-33989: Ensure that ms.key_compare is always initialized in list_sort_impl(). (GH-8710) https://github.com/python/cpython/commit/0e73ea26a55abc0ce2ee1153e5509bcaef4736cf ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 03:05:33 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 21 Feb 2019 08:05:33 +0000 Subject: [issue36059] Update docs for OrderedDict to reflect that regular dicts are ordered In-Reply-To: <1550708789.68.0.789605857229.issue36059@roundup.psfhosted.org> Message-ID: <1550736333.78.0.34626349411.issue36059@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 49fd6dd887df6ea18dbb1a3c0f599239ccd1cb42 by Raymond Hettinger in branch 'master': bpo-36059: Update OrderedDict() docs to reflect that regular dicts are now ordered (GH-11966) https://github.com/python/cpython/commit/49fd6dd887df6ea18dbb1a3c0f599239ccd1cb42 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 03:05:49 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 21 Feb 2019 08:05:49 +0000 Subject: [issue36059] Update docs for OrderedDict to reflect that regular dicts are ordered In-Reply-To: <1550708789.68.0.789605857229.issue36059@roundup.psfhosted.org> Message-ID: <1550736349.51.0.137580378547.issue36059@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +11997 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 03:14:44 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 21 Feb 2019 08:14:44 +0000 Subject: [issue33989] ms.key_compare is not initialized in all paths of list_sort_impl() In-Reply-To: <1530207786.09.0.56676864532.issue33989@psf.upfronthosting.co.za> Message-ID: <1550736884.91.0.839717862275.issue33989@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 03:18:53 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 21 Feb 2019 08:18:53 +0000 Subject: [issue36059] Update docs for OrderedDict to reflect that regular dicts are ordered In-Reply-To: <1550708789.68.0.789605857229.issue36059@roundup.psfhosted.org> Message-ID: <1550737133.69.0.385665844354.issue36059@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 300605990dc7441b19ab3fe7ea683094306d5ecd by Raymond Hettinger (Miss Islington (bot)) in branch '3.7': bpo-36059: Update OrderedDict() docs to reflect that regular dicts are now ordered (GH-11966) (GH-#11972) https://github.com/python/cpython/commit/300605990dc7441b19ab3fe7ea683094306d5ecd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 03:19:23 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 21 Feb 2019 08:19:23 +0000 Subject: [issue36059] Update docs for OrderedDict to reflect that regular dicts are ordered In-Reply-To: <1550708789.68.0.789605857229.issue36059@roundup.psfhosted.org> Message-ID: <1550737163.24.0.89090484587.issue36059@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 04:00:15 2019 From: report at bugs.python.org (Andrey Paramonov) Date: Thu, 21 Feb 2019 09:00:15 +0000 Subject: [issue30782] Allow limiting the number of concurrent tasks in asyncio.as_completed In-Reply-To: <1498525522.6.0.617023291854.issue30782@psf.upfronthosting.co.za> Message-ID: <1550739615.37.0.414891173344.issue30782@roundup.psfhosted.org> Andrey Paramonov added the comment: Might as_completed() be considered a low-level API, but as of Python 3.7 there are seemingly no ready alternatives to achieve proposed behavior. All of asyncio.gather(), asyncio.wait(), asyncio.as_completed() expect awaitables list of limited size; doing something like https://www.artificialworlds.net/blog/2017/06/12/making-100-million-requests-with-python-aiohttp is not straightforward. A function that takes iterator/async iterator of tasks and is itself generator/async generator is very much wanted, something in the spirit of (but more efficient?) ---- async def igather(tasks, limit=None): pending = set() while True: for task in islice(tasks, limit - len(pending) if limit else None): pending.add(task) if pending: done, pending = await asyncio.wait(pending, return_when=asyncio.FIRST_COMPLETED) for task in done: yield task else: break ---- It is an open question whether such function should yield results in the task submission order. Albeit useful, it's a bit harder to implement and (most importantly) has terrible worst-case memory behavior. See also: https://bugs.python.org/issue33533 https://github.com/h2non/paco/issues/38 ---------- nosy: +aparamon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 04:41:32 2019 From: report at bugs.python.org (Kostis Anagnostopoulos) Date: Thu, 21 Feb 2019 09:41:32 +0000 Subject: [issue29757] The loop in utility `socket.create_connection()` swallows previous errors In-Reply-To: <1488984317.87.0.296010902983.issue29757@psf.upfronthosting.co.za> Message-ID: <1550742092.61.0.436633285202.issue29757@roundup.psfhosted.org> Kostis Anagnostopoulos added the comment: The problem of not fixing this (and just add a suggestion in the docs saying that the user may re-implement this method) is that frequently this call is hidden at the core of many networking libraries. So monkey-patching is needed instead, which is not always nice or easy. > I just found an old bug in socket.create_connection(): > https://github.com/python/cpython/pull/3546 Regarding #3546, i'm surprised that a function-local variable keeps its contents alive, long after the frame of that function has gone. I thought that local-variables were deterministically (ref-countering) destructed. What is happening? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 04:41:35 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Thu, 21 Feb 2019 09:41:35 +0000 Subject: [issue36063] replace PyTuple_SetItem() with PyTuple_SET_ITEM() in long_divmod() Message-ID: <1550742095.78.0.510833916467.issue36063@roundup.psfhosted.org> New submission from Sergey Fedoseev : This change produces minor speed-up: $ python-other -m perf timeit -s "divmod_ = divmod" "divmod_(1, 1)" --duplicate=1000 --compare-to=../cpython-master/venv/bin/python python: ..................... 64.6 ns +- 4.8 ns python-other: ..................... 59.4 ns +- 3.2 ns Mean +- std dev: [python] 64.6 ns +- 4.8 ns -> [python-other] 59.4 ns +- 3.2 ns: 1.09x faster (-8%) ---------- messages: 336194 nosy: sir-sigurd priority: normal severity: normal status: open title: replace PyTuple_SetItem() with PyTuple_SET_ITEM() in long_divmod() type: performance versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 04:42:18 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Thu, 21 Feb 2019 09:42:18 +0000 Subject: [issue36063] replace PyTuple_SetItem() with PyTuple_SET_ITEM() in long_divmod() In-Reply-To: <1550742095.78.0.510833916467.issue36063@roundup.psfhosted.org> Message-ID: <1550742138.98.0.802096309884.issue36063@roundup.psfhosted.org> Change by Sergey Fedoseev : ---------- keywords: +patch pull_requests: +11998 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 04:44:59 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 21 Feb 2019 09:44:59 +0000 Subject: [issue20177] Derby #8: Convert 28 sites to Argument Clinic across 2 files In-Reply-To: <1389138574.32.0.892814928986.issue20177@psf.upfronthosting.co.za> Message-ID: <1550742299.51.0.218616426995.issue20177@roundup.psfhosted.org> Serhiy Storchaka added the comment: The modern workflow requires creating a PR on GitHub. Nikolaus, do you mind to convert your patch to a PR? ---------- nosy: +serhiy.storchaka versions: +Python 3.8 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 05:01:13 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 21 Feb 2019 10:01:13 +0000 Subject: [issue36063] replace PyTuple_SetItem() with PyTuple_SET_ITEM() in long_divmod() In-Reply-To: <1550742095.78.0.510833916467.issue36063@roundup.psfhosted.org> Message-ID: <1550743273.96.0.15853977633.issue36063@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset ea6207d593832fe50dbca39e94c138abbd5d266d by Serhiy Storchaka (Sergey Fedoseev) in branch 'master': bpo-36063: Minor performance tweak in long_divmod(). (GH-11915) https://github.com/python/cpython/commit/ea6207d593832fe50dbca39e94c138abbd5d266d ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 05:01:57 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 21 Feb 2019 10:01:57 +0000 Subject: [issue36063] replace PyTuple_SetItem() with PyTuple_SET_ITEM() in long_divmod() In-Reply-To: <1550742095.78.0.510833916467.issue36063@roundup.psfhosted.org> Message-ID: <1550743317.45.0.608294507954.issue36063@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 05:11:57 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Thu, 21 Feb 2019 10:11:57 +0000 Subject: [issue36052] Assignment operator allows to assign to __debug__ In-Reply-To: <1550676216.29.0.487544148429.issue36052@roundup.psfhosted.org> Message-ID: <1550743917.99.0.263175712146.issue36052@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: New changeset 3ad91673057d410bf9f8c53df6bb8aa18c4b68ca by Pablo Galindo (St?phane Wirtel) in branch 'master': bpo-36052: Raise a SyntaxError when assigning a value to __debug__ with := (GH-11958) https://github.com/python/cpython/commit/3ad91673057d410bf9f8c53df6bb8aa18c4b68ca ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 05:12:23 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Thu, 21 Feb 2019 10:12:23 +0000 Subject: [issue36052] Assignment operator allows to assign to __debug__ In-Reply-To: <1550676216.29.0.487544148429.issue36052@roundup.psfhosted.org> Message-ID: <1550743943.08.0.982845844063.issue36052@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 05:23:41 2019 From: report at bugs.python.org (Lye) Date: Thu, 21 Feb 2019 10:23:41 +0000 Subject: [issue36064] docs: urllib.request.Request not accepting iterables data type Message-ID: <1550744621.39.0.0634252256257.issue36064@roundup.psfhosted.org> New submission from Lye : I found out in the docs 3.6, in the class urllib.request.Request, for the input of 'data' data types, it says : "The supported object types include bytes, file-like objects, and iterables." But after testing it with data type dict for the 'data' input, I got error of: "can't concat str to bytes" It seems the docs should't say the 'data' data types support iterables. There more detail discussion is at : https://stackoverflow.com/questions/54802272/some-fundamental-concept-used-in-python-docs Hope this helps, thanks ! ---------- assignee: docs at python components: Documentation messages: 336198 nosy: docs at python, sylye priority: normal severity: normal status: open title: docs: urllib.request.Request not accepting iterables data type type: enhancement versions: Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 05:27:45 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Thu, 21 Feb 2019 10:27:45 +0000 Subject: [issue36064] docs: urllib.request.Request not accepting iterables data type In-Reply-To: <1550744621.39.0.0634252256257.issue36064@roundup.psfhosted.org> Message-ID: <1550744865.59.0.0887587978352.issue36064@roundup.psfhosted.org> St?phane Wirtel added the comment: Thank you for your issue but could you provide an example file? Have a nice day. For the new contributors, this issue is marked as easy. ---------- keywords: +easy nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 05:44:36 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Thu, 21 Feb 2019 10:44:36 +0000 Subject: [issue36064] docs: urllib.request.Request not accepting iterables data type In-Reply-To: <1550744621.39.0.0634252256257.issue36064@roundup.psfhosted.org> Message-ID: <1550745876.01.0.720628445869.issue36064@roundup.psfhosted.org> St?phane Wirtel added the comment: Hi Lye, I didn't read your link, sorry you don't need to provide an example. We can work with this example. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 05:45:51 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 21 Feb 2019 10:45:51 +0000 Subject: [issue33039] int() and math.trunc don't accept objects that only define __index__ In-Reply-To: <1520672231.04.0.467229070634.issue33039@psf.upfronthosting.co.za> Message-ID: <1550745951.71.0.125887474552.issue33039@roundup.psfhosted.org> Serhiy Storchaka added the comment: Is not this a duplicate of issue20092? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 05:53:34 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Thu, 21 Feb 2019 10:53:34 +0000 Subject: [issue36064] docs: urllib.request.Request not accepting iterables data type In-Reply-To: <1550744621.39.0.0634252256257.issue36064@roundup.psfhosted.org> Message-ID: <1550746414.75.0.284228790522.issue36064@roundup.psfhosted.org> St?phane Wirtel added the comment: Hi Lye, I am not sure it's a bug because I don't have any problem with your script. Here is your script. import urllib import urllib.request my_url = "https://api.foo.com" my_headers = { "Content-Type" : "application/x-www-form-urlencoded" } my_data = { "client_id" : "ppp", "client_secret" : "000", "grant_type" : "client_credentials" } req = urllib.request.Request(url=my_url, data=my_data, headers=my_headers) response = urllib.request.urlopen(req) html = response.read() print(html) and here is the result with the version 3.6 of Python: > docker run --rm -v $PWD:/src -it python:3.6 python /src/demo.py Traceback (most recent call last): File "/usr/local/lib/python3.6/urllib/request.py", line 1318, in do_open encode_chunked=req.has_header('Transfer-encoding')) ... File "/usr/local/lib/python3.6/socket.py", line 713, in create_connection sock.connect(sa) ConnectionRefusedError: [Errno 111] Connection refused During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/src/demo.py", line 12, in response = urllib.request.urlopen(req) ... File "/usr/local/lib/python3.6/urllib/request.py", line 1320, in do_open raise URLError(err) urllib.error.URLError: I don't get your error. and the version of this docker image is 3.6.8 > docker run --rm -v $PWD:/src -it python:3.6 python --version Python 3.6.8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 05:56:16 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Thu, 21 Feb 2019 10:56:16 +0000 Subject: [issue36064] docs: urllib.request.Request not accepting iterables data type In-Reply-To: <1550744621.39.0.0634252256257.issue36064@roundup.psfhosted.org> Message-ID: <1550746576.0.0.186883487447.issue36064@roundup.psfhosted.org> St?phane Wirtel added the comment: and I get the same result with the python:3.6.7 image docker > docker run --rm -v $PWD:/src -it python:3.6.7 python /src/demo.py Traceback (most recent call last): File "/usr/local/lib/python3.6/urllib/request.py", line 1318, in do_open encode_chunked=req.has_header('Transfer-encoding')) ... File "/usr/local/lib/python3.6/socket.py", line 713, in create_connection sock.connect(sa) ConnectionRefusedError: [Errno 111] Connection refused During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/src/demo.py", line 12, in response = urllib.request.urlopen(req) ... File "/usr/local/lib/python3.6/urllib/request.py", line 1320, in do_open raise URLError(err) urllib.error.URLError: I am really sorry but I can't reproduce your issue. What is your Linux distribution or OS? Thank you ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 05:56:30 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 21 Feb 2019 10:56:30 +0000 Subject: [issue12974] array module: deprecate '__int__' conversion support for array elements In-Reply-To: <1315961295.78.0.425877150438.issue12974@psf.upfronthosting.co.za> Message-ID: <1550746590.87.0.582866319581.issue12974@roundup.psfhosted.org> Serhiy Storchaka added the comment: See more general issue36048. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 05:57:22 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 21 Feb 2019 10:57:22 +0000 Subject: [issue36018] Add a Normal Distribution class to the statistics module In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org> Message-ID: <1550746642.4.0.617529514563.issue36018@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- keywords: +patch pull_requests: +11999 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 06:06:19 2019 From: report at bugs.python.org (Inada Naoki) Date: Thu, 21 Feb 2019 11:06:19 +0000 Subject: [issue36061] zipfile does not handle arcnames with non-ascii characters on Windows In-Reply-To: <1550714370.81.0.682374426913.issue36061@roundup.psfhosted.org> Message-ID: <1550747179.05.0.508595196298.issue36061@roundup.psfhosted.org> Change by Inada Naoki : ---------- resolution: -> wont fix stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 06:07:19 2019 From: report at bugs.python.org (Inada Naoki) Date: Thu, 21 Feb 2019 11:07:19 +0000 Subject: [issue31659] ssl module should not use textwrap for wrapping PEM format. In-Reply-To: <1506905254.99.0.213398074469.issue31659@psf.upfronthosting.co.za> Message-ID: <1550747239.6.0.520298793179.issue31659@roundup.psfhosted.org> Change by Inada Naoki : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 06:19:04 2019 From: report at bugs.python.org (Michael Felt) Date: Thu, 21 Feb 2019 11:19:04 +0000 Subject: [issue36034] Suprise halt caused by -Werror=implicit-function-declaration in ./Modules/posixmodule.c In-Reply-To: <1550608185.88.0.0973450009509.issue36034@roundup.psfhosted.org> Message-ID: <57cbd6da-b94f-49e0-2d38-1d3c67acf2ab@felt.demon.nl> Michael Felt added the comment: xlc has an option -qsource that creates output like this - first showing the code with macro, then showing the expansion >>>>> SOURCE SECTION <<<<< ... ?????? 16 |???????? dev = st.st_dev; ?????? 17 |???????? minor = minor(dev); ?????? 17 +???????? minor = (int)((dev)&0xFFFF); ?????? 18 |???????? major = major(dev); ?????? 18 +???????? major = (int)((unsigned)(dev)>>16); I'll check and see if -E processes the output in the same way. Thx. On 2/19/2019 9:29 PM, Alexey Izbyshev wrote: > Alexey Izbyshev added the comment: > > I don't know what you mean by "in-line" pre-processing output, but you can use -E option to get the normal preprocessor output. Line directives will tell you where those functions come from on a system where there is no compilation error. > > Of course, if those functions are defined in some other headers on AIX 6.1, it won't help you, so you might as well just grep /usr/include :) > > ---------- > nosy: +izbyshev > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 06:21:02 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 21 Feb 2019 11:21:02 +0000 Subject: [issue29757] The loop in utility `socket.create_connection()` swallows previous errors In-Reply-To: <1488984317.87.0.296010902983.issue29757@psf.upfronthosting.co.za> Message-ID: <1550748062.56.0.847735328571.issue29757@roundup.psfhosted.org> STINNER Victor added the comment: > I thought that local-variables were deterministically (ref-countering) destructed. What is happening? IT's a reference cycle. Exception => traceback => frame => exception. The 'err' variable kept the frame alive which kept the exception alive which kept everything alive. The GC is supposed to be able to break ref cycles, but GC collections are irregular and sometimes the GC fails to break complex cycles. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 06:24:21 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 21 Feb 2019 11:24:21 +0000 Subject: [issue36030] add internal API function to create tuple without items array initialization In-Reply-To: <1550563364.86.0.164811838679.issue36030@roundup.psfhosted.org> Message-ID: <1550748261.46.0.923600009009.issue36030@roundup.psfhosted.org> STINNER Victor added the comment: Please make PyTuple_FromArray private: rename to _PyTuple_FromArray. I would prefer to only add it to Include/internals/pycore_tupleobject.c. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 06:32:58 2019 From: report at bugs.python.org (Lye) Date: Thu, 21 Feb 2019 11:32:58 +0000 Subject: [issue36064] docs: urllib.request.Request not accepting iterables data type In-Reply-To: <1550744621.39.0.0634252256257.issue36064@roundup.psfhosted.org> Message-ID: <1550748778.14.0.249126474406.issue36064@roundup.psfhosted.org> Lye added the comment: Hi @matrixise, Sorry that the example in that stackoverflow site is a dummy API server. I tested my code in a real API server so I can produce the error. I have re-tested my code with that dummy site and yes you won't able to get that error. To reproduce that error, you may try a valid API server, like 'https://httpbin.org/post' . I just tested again by replacing : my_url = "https://api.foo.com" with my_url = "https://httpbin.org/post" and able to get the same error again. Apology for not using a real API server in my example :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 06:34:00 2019 From: report at bugs.python.org (Lye) Date: Thu, 21 Feb 2019 11:34:00 +0000 Subject: [issue36064] docs: urllib.request.Request not accepting iterables data type In-Reply-To: <1550744621.39.0.0634252256257.issue36064@roundup.psfhosted.org> Message-ID: <1550748840.28.0.279924479579.issue36064@roundup.psfhosted.org> Lye added the comment: And I tested in both : Centos 6.10 4.14.77-70.59.amzn1.x86_64 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 07:00:29 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 21 Feb 2019 12:00:29 +0000 Subject: [issue36064] docs: urllib.request.Request not accepting iterables data type In-Reply-To: <1550744621.39.0.0634252256257.issue36064@roundup.psfhosted.org> Message-ID: <1550750429.71.0.29589758022.issue36064@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: I guess key should be bytes instead of a dict with string key. Maybe the docs could be improved about the case where key in case of dict should be bytes. >>> from urllib.request import urlopen, Request >>> r = Request("http://httpbin.org/post", data={b'a': 'a'}) >>> resp = urlopen(r) >>> print(resp.read()) b'{\n "args": {}, \n "data": "", \n "files": {}, \n "form": {\n "a": ""\n }, \n "headers": {\n "Accept-Encoding": "identity", \n "Content-Length": "1", \n "Content-Type": "application/x-www-form-urlencoded", \n "Host": "httpbin.org", \n "User-Agent": "Python-urllib/3.8"\n }, \n "json": null, \n "origin": "123.201.136.26, 123.201.136.26", \n "url": "https://httpbin.org/post"\n}\n' See https://bugs.python.org/issue25439 for an open patch to ensure this is type checked. >>> from urllib.request import urlopen, Request >>> r = Request("http://httpbin.org/post", data={'a': 'a'}) Traceback (most recent call last): File "", line 1, in File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/urllib/request.py", line 332, in __init__ self.data = data File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/urllib/request.py", line 370, in data raise TypeError("Key should be type of bytes in POST data") TypeError: Key should be type of bytes in POST data Current code is not checking the type makes it pass during construction and then throw an error later like below : >>> from urllib.request import urlopen, Request >>> r = Request("http://httpbin.org/post", data={'a': 'a'}) >>> urlopen(r) Traceback (most recent call last): File "", line 1, in File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/urllib/request.py", line 222, in urlopen return opener.open(url, data, timeout) File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/urllib/request.py", line 525, in open response = self._open(req, data) File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/urllib/request.py", line 543, in _open '_open', req) File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/urllib/request.py", line 503, in _call_chain result = func(*args) File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/urllib/request.py", line 1345, in http_open return self.do_open(http.client.HTTPConnection, req) File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/urllib/request.py", line 1317, in do_open encode_chunked=req.has_header('Transfer-encoding')) File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/http/client.py", line 1229, in request self._send_request(method, url, body, headers, encode_chunked) File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/http/client.py", line 1275, in _send_request self.endheaders(body, encode_chunked=encode_chunked) File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/http/client.py", line 1224, in endheaders self._send_output(message_body, encode_chunked=encode_chunked) File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/http/client.py", line 1054, in _send_output + b'\r\n' TypeError: can't concat str to bytes ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 07:01:43 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Thu, 21 Feb 2019 12:01:43 +0000 Subject: [issue36035] pathlib.Path().rglob() breaks with broken symlinks In-Reply-To: <1550578197.02.0.381973172531.issue36035@roundup.psfhosted.org> Message-ID: <1550750503.42.0.10393888471.issue36035@roundup.psfhosted.org> Emmanuel Arias added the comment: Hello! I make the PR: https://github.com/python/cpython/pull/11964 But I need help to test it :-( Any could help me please? ---------- nosy: +eamanu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 07:09:22 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 21 Feb 2019 12:09:22 +0000 Subject: [issue35925] test_httplib test_nntplib test_ssl fail on ARMv7 Debian buster bot (OpenSSL 1.1.1a) In-Reply-To: <1549503926.32.0.191493141556.issue35925@roundup.psfhosted.org> Message-ID: <1550750962.46.0.641169345696.issue35925@roundup.psfhosted.org> STINNER Victor added the comment: After my change: commit 3ef6344ee53f59ee86831ec36ed2c6f93a56229d Author: Victor Stinner Date: Tue Feb 19 18:06:03 2019 +0100 bpo-36037: Fix test_ssl for strict OpenSSL policy (GH-11940) Two tests are still failing on the Debian buildbot worker: ERROR: test_networked_good_cert (test.test_httplib.HTTPSTest) ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: EE certificate key too weak (_ssl.c:1055) ERROR: setUpClass (test.test_nntplib.NetworkedNNTP_SSLTests) ssl.SSLError: [SSL: DH_KEY_TOO_SMALL] dh key too small (_ssl.c:1055) We should use different servers or contact admins of these servers to update their TLS configuration and/or certificate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 07:28:01 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Thu, 21 Feb 2019 12:28:01 +0000 Subject: [issue36064] docs: urllib.request.Request not accepting iterables data type In-Reply-To: <1550744621.39.0.0634252256257.issue36064@roundup.psfhosted.org> Message-ID: <1550752081.98.0.340103060391.issue36064@roundup.psfhosted.org> St?phane Wirtel added the comment: ok, I confirm this issue, now, with httpbin.org I get the same issue. and it's just when we try to send the stream to the server. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 07:38:27 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Thu, 21 Feb 2019 12:38:27 +0000 Subject: [issue36064] docs: urllib.request.Request not accepting iterables data type In-Reply-To: <1550744621.39.0.0634252256257.issue36064@roundup.psfhosted.org> Message-ID: <1550752707.61.0.0541130421261.issue36064@roundup.psfhosted.org> St?phane Wirtel added the comment: @xtreak ok because it's not related to the documentation, I have a fix for this issue but I am not sure about the title for this PR but what do you suggest? "Fix the encoding in _send_output when sending an iterable object via urllib.request.Request" ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 07:44:44 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Thu, 21 Feb 2019 12:44:44 +0000 Subject: [issue36064] docs: urllib.request.Request not accepting iterables data type In-Reply-To: <1550744621.39.0.0634252256257.issue36064@roundup.psfhosted.org> Message-ID: <1550753084.7.0.91452821658.issue36064@roundup.psfhosted.org> Change by St?phane Wirtel : ---------- keywords: +patch pull_requests: +12000 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 07:46:23 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Thu, 21 Feb 2019 12:46:23 +0000 Subject: [issue36064] docs: urllib.request.Request not accepting iterables data type In-Reply-To: <1550744621.39.0.0634252256257.issue36064@roundup.psfhosted.org> Message-ID: <1550753183.19.0.449916062108.issue36064@roundup.psfhosted.org> St?phane Wirtel added the comment: @xtreak I have just pushed a PR, if you think it's an issue related to the documentation, you can ignore my PR and in this case I will close it. now, it's not related to the doc, could you review it and give me your feedback? Thank you, ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 08:56:39 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Thu, 21 Feb 2019 13:56:39 +0000 Subject: [issue20582] socket.getnameinfo() does not document flags In-Reply-To: <1392042265.22.0.885252016144.issue20582@psf.upfronthosting.co.za> Message-ID: <1550757399.39.0.277997791367.issue20582@roundup.psfhosted.org> Change by Emmanuel Arias : ---------- keywords: +patch pull_requests: +12001 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 09:02:53 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 21 Feb 2019 14:02:53 +0000 Subject: [issue36064] docs: urllib.request.Request not accepting iterables data type In-Reply-To: <1550744621.39.0.0634252256257.issue36064@roundup.psfhosted.org> Message-ID: <1550757773.8.0.501644792823.issue36064@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: St?phane, I don't know much about urllib to review this. The reason I said it's better document this is that there was an extended discussion on issue25439 along with a PR about type checking breaking some behavior and ambiguity in what is allowed currently. This PR seems to encode str to bytes implicitly and it needs to be documented as such that this str is encoded to bytes under the hood. I am not sure of backporting it as a fix to stable releases. I think it's better to raise an error instead of doing something implicitly. I am adding Martin and Senthil to the issue who might have a better context. ---------- nosy: +martin.panter, orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 09:15:04 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Thu, 21 Feb 2019 14:15:04 +0000 Subject: [issue36064] docs: urllib.request.Request not accepting iterables data type In-Reply-To: <1550744621.39.0.0634252256257.issue36064@roundup.psfhosted.org> Message-ID: <1550758504.91.0.551366966238.issue36064@roundup.psfhosted.org> St?phane Wirtel added the comment: Thank you @xtreak for adding Martin and Senthil. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 09:20:08 2019 From: report at bugs.python.org (Ori Avtalion) Date: Thu, 21 Feb 2019 14:20:08 +0000 Subject: [issue36065] Add unified C API for accessing bytes and bytearray Message-ID: <1550758808.61.0.471799213148.issue36065@roundup.psfhosted.org> New submission from Ori Avtalion : It would be useful to have a shared API for consuming bytes and bytearrays. At present, I need to write very similar code twice. Some existing codebases only support bytes (perhaps forgetting bytearrays exist). Adding support for bytearray would be trivial if there was a shared API. These are the functions/macros that can have "BytesOrByteArray" equivalents: * PyBytes_Check * PyBytes_CheckExact * PyBytes_Size * PyBytes_GET_SIZE * PyBytes_AsString * PyBytes_AS_STRING * PyBytes_AsStringAndSize Here are some example implementations for the macros: #define PyBytesOrByteArray_Check(ob) (PyBytes_Check(ob) || PyByteArray_Check(ob)) #define PyBytesOrByteArray_AS_STRING(ob) (PyBytes_Check(ob) ? PyBytes_AS_STRING(ob) : PyByteArray_AS_STRING(ob)) #define PyBytesOrByteArray_GET_SIZE(ob) #define PyByteArray_GET_SIZE(self) (assert(PyBytesOrByteArray_Check(self)), Py_SIZE(self)) ---------- components: Interpreter Core messages: 336218 nosy: salty-horse priority: normal severity: normal status: open title: Add unified C API for accessing bytes and bytearray type: enhancement versions: Python 2.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 09:21:26 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Thu, 21 Feb 2019 14:21:26 +0000 Subject: [issue36065] Add unified C API for accessing bytes and bytearray In-Reply-To: <1550758808.61.0.471799213148.issue36065@roundup.psfhosted.org> Message-ID: <1550758886.5.0.304465096441.issue36065@roundup.psfhosted.org> St?phane Wirtel added the comment: I remove 2.7 because this branch is in bugfix mode, no new features. ---------- nosy: +matrixise, serhiy.storchaka, vstinner versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 09:23:02 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 21 Feb 2019 14:23:02 +0000 Subject: [issue36065] Add unified C API for accessing bytes and bytearray In-Reply-To: <1550758808.61.0.471799213148.issue36065@roundup.psfhosted.org> Message-ID: <1550758981.99.0.434587709115.issue36065@roundup.psfhosted.org> STINNER Victor added the comment: St?phane: Please don't add me to the nosy list of bugs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 09:23:05 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 21 Feb 2019 14:23:05 +0000 Subject: [issue36065] Add unified C API for accessing bytes and bytearray In-Reply-To: <1550758808.61.0.471799213148.issue36065@roundup.psfhosted.org> Message-ID: <1550758985.51.0.901080182029.issue36065@roundup.psfhosted.org> Change by STINNER Victor : ---------- nosy: -vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 09:29:45 2019 From: report at bugs.python.org (WloHu) Date: Thu, 21 Feb 2019 14:29:45 +0000 Subject: [issue36066] Add `empty` block to `for` and `while` loops. Message-ID: <1550759385.86.0.911138177234.issue36066@roundup.psfhosted.org> New submission from WloHu : ### Description Adding `empty` block to loops will extend them to form for-empty-else and while-empty-else. The idea is that `empty` block will execute when loop iteration wasn't performed because iterated element was empty. The idea is taken from Django framework' `{% empty %}` block (https://docs.djangoproject.com/en/2.1/ref/templates/builtins/#for-empty). ### Details There are combinations how this loop should work together with `else` block (`for` loop taken as example): 1. for-empty - `empty` block runs when iteration wasn't performed, i.e. ended naturally because of empty iterator; 2. for-else - `else` block runs when iteration ended naturally either because iterator was empty or exhausted, behavior the same as currently implemented; 3. for-empty-else - in this form there is split depending on the way in which loop ended naturally: -- empty iterator - only `empty` block is executed, -- non-empty iterator - only `else` block is executed. In 3rd case `else` block is not executed together with `empty` block because this can be done by using for-else form. The only reason to make this case work differently is code duplication in case when regardless of the way, in which loop ended naturally, there is common code we want to execute. E.g.: ``` for: ... empty: statement1 statement2 else: statement1 statement3 ``` However implementing the "common-avoid-duplication" case will be inconsisted with `try-except` which executes only 1st matching `except` block. ### Current alternative solutions In case when iterable object works well with "empty test" (e.g.: `list`, `set`) the most simple solution is: ``` if iterable: print("Empty") else: for item in iterable: print(item) else: print("Ended naturally - non-empty.") ``` Which looks good and is simple enough to avoid extending the language. However in general this would fail if `iterable` object is a generator which is always truthy and fails the expectations of "empty test". In such case special handling should be made to make it work in general. So far I see 3 options: - use helper variable `x = list(iterable)` and do "empty test" as shown above - this isn't an option for unbound `iterable` like stream or asynchronous message queue; - test generator for emptiness a.k.a. peek next element: ``` try: first = next(iterable) except StopIteration: print("Empty") else: for item in itertools.chain([first], iterable): print(item) else: print("Ended naturally - non-empty.") ``` - add `empty` flag inside loop: ``` empty = True for item in iterable: empty = False # Sadly executed for each `item`. print(item) else: if empty: print("Empty") else print("Ended naturally - non-empty.") ``` The two latter options aren't really idiomatic compared to proposed: ``` for item in iterable: print(item) empty: print("Empty") else: print("Ended naturally - non-empty.") ``` ### Enchancement pros and cons Pros: - more idiomatic solution to handle natural loop exhaustion for empty iterator, - shorter horizontal indentation compared to current alternatives, - quite consistent flow control splitting compared to `try-except`, - not so exotic as it's already implemented in Django (`{% empty %}`) and Jinja2 (`{% else %}`). Cons: - new keyword/token, - applies to even smaller number of usecases than for-else which is still considered exotic. ### Actual (my) usecase (shortened): ``` empty = True for message in messages: empty = False try: decoded = message.decode() except ...: ... ... # Handle different exception types. else: log.info("Success") break else: if empty: error_message = "No messages." else: error_message = "Failed to decode available messages." log.error(error_message) ``` ### One more thing to convince readers Considering that Python "went exotic" with for-else and while-else to solve `if not_found: print('Not found.')` case, adding `empty` seems like next inductive step in controling flow of loops. ### Alternative solution Enhance generators to work in "empty test" which peeks for next element behind the scenes. This will additionally solve annoying issue for testing empty generators, which currently must be handled as special case of iterable object. Moreover this solution doesn't require new language keywords. ---------- components: Interpreter Core messages: 336221 nosy: wlohu priority: normal severity: normal status: open title: Add `empty` block to `for` and `while` loops. type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 09:30:43 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Thu, 21 Feb 2019 14:30:43 +0000 Subject: [issue36065] Add unified C API for accessing bytes and bytearray In-Reply-To: <1550758808.61.0.471799213148.issue36065@roundup.psfhosted.org> Message-ID: <1550759443.99.0.575598919879.issue36065@roundup.psfhosted.org> Ronald Oussoren added the comment: What is your use case for this? Is that something that can use the buffer API instead of these low-level APIs? ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 09:41:42 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 21 Feb 2019 14:41:42 +0000 Subject: [issue36066] Add `empty` block to `for` and `while` loops. In-Reply-To: <1550759385.86.0.911138177234.issue36066@roundup.psfhosted.org> Message-ID: <1550760102.79.0.770358381586.issue36066@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: I would recommend posting this on python-ideas to get some feedback. This introduces new control flow and breaks some old assumptions as in third case empty block is executed and there might be code that depends upon current for-else behavior where else should be executed. Also reading the examples initially this seems to add little cognitive overhead too since there is now empty and else that are executed based on empty iterable, breaking out of the loop, natural ending of the loop which might make this little hard to teach too. ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 09:42:43 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Thu, 21 Feb 2019 14:42:43 +0000 Subject: [issue36066] Add `empty` block to `for` and `while` loops. In-Reply-To: <1550759385.86.0.911138177234.issue36066@roundup.psfhosted.org> Message-ID: <1550760163.37.0.706123861944.issue36066@roundup.psfhosted.org> St?phane Wirtel added the comment: This issue should be discussed on python-ideas https://mail.python.org/mailman/listinfo/python-ideas ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 09:46:57 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 21 Feb 2019 14:46:57 +0000 Subject: [issue36066] Add `empty` block to `for` and `while` loops. In-Reply-To: <1550759385.86.0.911138177234.issue36066@roundup.psfhosted.org> Message-ID: <1550760417.98.0.731379672397.issue36066@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Slightly similar proposal in the past : https://mail.python.org/pipermail/python-ideas/2016-March/038897.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 09:51:25 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Thu, 21 Feb 2019 14:51:25 +0000 Subject: [issue36066] Add `empty` block to `for` and `while` loops. In-Reply-To: <1550759385.86.0.911138177234.issue36066@roundup.psfhosted.org> Message-ID: <1550760685.96.0.923453317968.issue36066@roundup.psfhosted.org> St?phane Wirtel added the comment: yep and there was no followup. maybe we could close this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 09:53:16 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 21 Feb 2019 14:53:16 +0000 Subject: [issue36065] Add unified C API for accessing bytes and bytearray In-Reply-To: <1550758808.61.0.471799213148.issue36065@roundup.psfhosted.org> Message-ID: <1550760796.56.0.144358701358.issue36065@roundup.psfhosted.org> Serhiy Storchaka added the comment: The unified C API already exists. It is called the buffer protocol. https://docs.python.org/3/c-api/buffer.html#buffer-related-functions ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 10:15:17 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 21 Feb 2019 15:15:17 +0000 Subject: [issue36030] add internal API function to create tuple without items array initialization In-Reply-To: <1550563364.86.0.164811838679.issue36030@roundup.psfhosted.org> Message-ID: <1550762117.74.0.434276513857.issue36030@roundup.psfhosted.org> Serhiy Storchaka added the comment: Once I had wrote a similar patch that adds PyTuple_FromArray, but never published it because I did not found enough use cases for this function. Although I considered using it only for removing some code duplication, but Sergey shown that it can be used for small performance boost in some special cases. I am still not sure, but this argument makes this change a tiny bit more attractive. Leave this on Raymond. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 10:20:55 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 21 Feb 2019 15:20:55 +0000 Subject: [issue36030] add internal API function to create tuple without items array initialization In-Reply-To: <1550563364.86.0.164811838679.issue36030@roundup.psfhosted.org> Message-ID: <1550762455.69.0.957807423246.issue36030@roundup.psfhosted.org> STINNER Victor added the comment: > Once I had wrote a similar patch that adds PyTuple_FromArray, but never published it because I did not found enough use cases for this function. Although I considered using it only for removing some code duplication, but Sergey shown that it can be used for small performance boost in some special cases. I am still not sure, but this argument makes this change a tiny bit more attractive. Leave this on Raymond. The micro-benchmark results are not really impressive. I still like PR 11954 because it removes code (simply loops). _PyTuple_FromArray() has a well defined API and is safe (I'm saying that because PR 11927 adds an "unsafe" function). As soon as it's private, I'm fine with it. I'm more attracted by the code simplification than performance boost here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 10:30:08 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 21 Feb 2019 15:30:08 +0000 Subject: [issue36030] add internal API function to create tuple without items array initialization In-Reply-To: <1550563364.86.0.164811838679.issue36030@roundup.psfhosted.org> Message-ID: <1550763008.47.0.237566665231.issue36030@roundup.psfhosted.org> STINNER Victor added the comment: I reviewed PR 11954: I asked to rework the PR to only add _PyTuple_FromArray() and the "unrelated" micro-optimization. So it would be easier to see code simplification and the micro-optimization. If the micro-optimization doesn't make the code more complex and doesn't introduce subtle issue with the GC, I'm fine with taking 10 ns optimization ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 10:38:02 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 21 Feb 2019 15:38:02 +0000 Subject: [issue36067] subprocess terminate() "invalid handle" error when process is gone Message-ID: <1550763482.04.0.374893682062.issue36067@roundup.psfhosted.org> New submission from Giampaolo Rodola' : Happened in psutil: https://ci.appveyor.com/project/giampaolo/psutil/builds/22546914/job/rlp112gffyf2o30i ====================================================================== ERROR: psutil.tests.test_process.TestProcess.test_halfway_terminated_process ---------------------------------------------------------------------- Traceback (most recent call last): File "c:\projects\psutil\psutil\tests\test_process.py", line 85, in tearDown reap_children() File "c:\projects\psutil\psutil\tests\__init__.py", line 493, in reap_children subp.terminate() File "C:\Python35-x64\lib\subprocess.py", line 1092, in terminate _winapi.TerminateProcess(self._handle, 1) OSError: [WinError 6] The handle is invalid During the test case, the process was already gone (no PID). ---------- components: Library (Lib) messages: 336231 nosy: giampaolo.rodola priority: normal severity: normal stage: needs patch status: open title: subprocess terminate() "invalid handle" error when process is gone type: behavior versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 10:44:11 2019 From: report at bugs.python.org (Ori Avtalion) Date: Thu, 21 Feb 2019 15:44:11 +0000 Subject: [issue36065] Add unified C API for accessing bytes and bytearray In-Reply-To: <1550758808.61.0.471799213148.issue36065@roundup.psfhosted.org> Message-ID: <1550763851.01.0.78175386072.issue36065@roundup.psfhosted.org> Ori Avtalion added the comment: My use-case is modifying existing code that supports bytes to also support bytearray. https://github.com/mongodb/mongo-python-driver/blob/9902d239b4e557c2a657e8c8110f7751864cec95/bson/_cbsonmodule.c#L1112 The buffer protocol, which I didn't know of, feels slightly complicated for my use-case. For now I opted to adding these macros myself, only changing 3 lines. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 11:01:51 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 21 Feb 2019 16:01:51 +0000 Subject: [issue36065] Add unified C API for accessing bytes and bytearray In-Reply-To: <1550758808.61.0.471799213148.issue36065@roundup.psfhosted.org> Message-ID: <1550764911.22.0.407043625317.issue36065@roundup.psfhosted.org> Serhiy Storchaka added the comment: If you need to support only bytes and bytearray, but not other bytes-like object, this is a too special case. It is easy to write your own macros or functions that wrap existing C API. Other option -- duplicate the code and replace PyBytes_ with PyByteArray_. In all cases be aware abot differences between bytes and bytearray: bytarray can change its content and size, saved values of PyByteArray_AS_STRING(ob) and PyByteArray_GET_SIZE(self) can not be used after executing arbitrary code in destructors or releasing GIT. ---------- resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 11:52:48 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 21 Feb 2019 16:52:48 +0000 Subject: [issue36067] subprocess terminate() "invalid handle" error when process is gone In-Reply-To: <1550763482.04.0.374893682062.issue36067@roundup.psfhosted.org> Message-ID: <1550767968.68.0.591840501491.issue36067@roundup.psfhosted.org> Giampaolo Rodola' added the comment: I think this is somewhat similar to issue14252. The problem I see is that we should either raise ProcessLookupError or ignore the error (better). This concept of suppressing errors if process is gone is currently already established in 2 places: https://github.com/python/cpython/blob/bafa8487f77fa076de3a06755399daf81cb75598/Lib/subprocess.py#L1389 Basically what I propose is to extend the existing logic to also include ERROR_INVALID_HANDLE other than ERROR_ACCESS_DENIED. Not tested: def terminate(self): """Terminates the process.""" # Don't terminate a process that we know has already died. if self.returncode is not None: return try: _winapi.TerminateProcess(self._handle, 1) except WindowsError as err: if err.errno in (ERROR_ACCESS_DENIED, ERROR_INVALID_HANDLE): rc = _winapi.GetExitCodeProcess(self._handle) if rc == _winapi.STILL_ACTIVE: raise self.returncode = rc else: raise ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 11:53:02 2019 From: report at bugs.python.org (twisteroid ambassador) Date: Thu, 21 Feb 2019 16:53:02 +0000 Subject: [issue30782] Allow limiting the number of concurrent tasks in asyncio.as_completed In-Reply-To: <1498525522.6.0.617023291854.issue30782@psf.upfronthosting.co.za> Message-ID: <1550767982.66.0.149266310717.issue30782@roundup.psfhosted.org> twisteroid ambassador added the comment: I feel like once you lay out all the requirements: taking futures from an (async) generator, limiting the number of concurrent tasks, getting completed tasks to one consumer "as completed", and an implicit requirement that back pressure from the consumer should be handled (i.e. if whoever's iterating through "async for fut in as_completed(...)" is too slow, then the tasks should pause until it catches up), there are too many moving parts, and this should really be implemented using several tasks. So a straightforward implementation may look like this: async def better_as_completed(futs, limit): MAX_DONE_FUTS_HELD = 10 # or some small number sem = asyncio.Semaphore(limit) done_q = asyncio.Queue(MAX_DONE_FUTS_HELD) async def run_futs(): async for fut in futs: await sem.acquire() asyncio.create_task(run_one_fut(fut)) async with sem: await done_q.put(None) async def run_one_fut(fut): try: fut = asyncio.ensure_future(fut) await asyncio.wait((fut,)) await done_q.put(fut) finally: sem.release() asyncio.create_task(run_futs()) while True: next_fut = await done_q.get() if next_fut is None: return yield next_fut Add proper handling for cancellation and exceptions and whatnot, and it may become a usable implementation. And no, I do not feel like this should be added to asyncio.as_completed. ---------- nosy: +twisteroid ambassador _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 11:10:40 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Thu, 21 Feb 2019 16:10:40 +0000 Subject: [issue33039] int() and math.trunc don't accept objects that only define __index__ In-Reply-To: <1520672231.04.0.467229070634.issue33039@psf.upfronthosting.co.za> Message-ID: <1550765440.46.0.572272827082.issue33039@roundup.psfhosted.org> R?mi Lapeyre added the comment: Yes it is. Thanks for finding that @Serhiy. Since nobody objected to the change on the mailing list and people seem to agree in issue 20092: [R. David Murray] To summarize for anyone like me who didn't follow that issue: __index__ means the object can be losslessly converted to an int (is a true int), while __int__ may be an approximate conversion. Thus it makes sense for an object to have an __int__ but not __index__, but vice-versa does not make sense. I will post my patch tonight. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 11:11:02 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 21 Feb 2019 16:11:02 +0000 Subject: [issue36067] subprocess terminate() "invalid handle" error when process is gone In-Reply-To: <1550763482.04.0.374893682062.issue36067@roundup.psfhosted.org> Message-ID: <1550765462.46.0.530162425872.issue36067@roundup.psfhosted.org> STINNER Victor added the comment: I'm not sure of the purpose of this issue. It's expected to get an error if you try to send a signal to process which is already terminated. vstinner at apu$ python3 Python 3.7.2 (default, Jan 16 2019, 19:49:22) >>> import subprocess >>> proc=subprocess.Popen("/bin/true") >>> import os >>> os.waitpid(proc.pid, 0) (8171, 0) >>> proc.kill() ProcessLookupError: [Errno 3] No such process >>> proc.terminate() ProcessLookupError: [Errno 3] No such process Ignoring these errors would be very risky: if another process gets the same pid, you would send a signal to the wrong process. Ooops. If you only use the subprocess API, you don't have this issue: vstinner at apu$ python3 Python 3.7.2 (default, Jan 16 2019, 19:49:22) >>> import subprocess >>> proc=subprocess.Popen("/bin/true") >>> proc.wait() 0 >>> proc.kill() # do nothing >>> proc.terminate() # do nothing ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 12:09:12 2019 From: report at bugs.python.org (Alexander Kapshuna) Date: Thu, 21 Feb 2019 17:09:12 +0000 Subject: [issue36043] FileCookieJar constructor don't accept PathLike In-Reply-To: <1550600762.69.0.583891908165.issue36043@roundup.psfhosted.org> Message-ID: <1550768952.4.0.310756776242.issue36043@roundup.psfhosted.org> Alexander Kapshuna added the comment: Oh sorry, I just thought that everybody has forgotten about this part of library. Nevermind my patch then, your work is certainly better, matrixise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 12:12:18 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 21 Feb 2019 17:12:18 +0000 Subject: [issue36060] Document how collections.ChainMap() determines iteration order In-Reply-To: <1550709045.44.0.467024509195.issue36060@roundup.psfhosted.org> Message-ID: <1550769138.76.0.737120497349.issue36060@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 86f093f71a594dcaf21b67ba13dda72863e9bde9 by Raymond Hettinger in branch 'master': bpo-36060: Document how collections.ChainMap() determines iteration order (GH-11969) https://github.com/python/cpython/commit/86f093f71a594dcaf21b67ba13dda72863e9bde9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 12:12:44 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 21 Feb 2019 17:12:44 +0000 Subject: [issue36060] Document how collections.ChainMap() determines iteration order In-Reply-To: <1550709045.44.0.467024509195.issue36060@roundup.psfhosted.org> Message-ID: <1550769164.57.0.711885231569.issue36060@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +12002 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 12:17:08 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 21 Feb 2019 17:17:08 +0000 Subject: [issue36060] Document how collections.ChainMap() determines iteration order In-Reply-To: <1550709045.44.0.467024509195.issue36060@roundup.psfhosted.org> Message-ID: <1550769428.92.0.797810845455.issue36060@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 12:19:06 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 21 Feb 2019 17:19:06 +0000 Subject: [issue36057] Add docs and tests for ordering in Counter. [no behavior change] In-Reply-To: <1550707805.37.0.515933023482.issue36057@roundup.psfhosted.org> Message-ID: <1550769546.54.0.0329999595963.issue36057@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 407c7343266eb3e5a2f5c1f4913082c84f8dd8a0 by Raymond Hettinger in branch 'master': bpo-36057 Update docs and tests for ordering in collections.Counter [no behavior change] (#11962) https://github.com/python/cpython/commit/407c7343266eb3e5a2f5c1f4913082c84f8dd8a0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 12:19:14 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 21 Feb 2019 17:19:14 +0000 Subject: [issue36057] Add docs and tests for ordering in Counter. [no behavior change] In-Reply-To: <1550707805.37.0.515933023482.issue36057@roundup.psfhosted.org> Message-ID: <1550769554.19.0.560135615498.issue36057@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +12003 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 12:26:24 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 21 Feb 2019 17:26:24 +0000 Subject: [issue36067] subprocess terminate() "invalid handle" error when process is gone In-Reply-To: <1550763482.04.0.374893682062.issue36067@roundup.psfhosted.org> Message-ID: <1550769984.66.0.928588658591.issue36067@roundup.psfhosted.org> STINNER Victor added the comment: > _winapi.TerminateProcess(self._handle, 1) > OSError: [WinError 6] The handle is invalid Silently ignoring that would be dangerous. There is a risk that the handle is reused by another process and so that you terminate an unrelated process, no? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 12:31:03 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 21 Feb 2019 17:31:03 +0000 Subject: [issue36057] Add docs and tests for ordering in Counter. [no behavior change] In-Reply-To: <1550707805.37.0.515933023482.issue36057@roundup.psfhosted.org> Message-ID: <1550770263.9.0.530855710229.issue36057@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 12:35:15 2019 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 21 Feb 2019 17:35:15 +0000 Subject: [issue35995] logging.handlers.SMTPHandler In-Reply-To: <1550133946.82.0.233218933413.issue35995@roundup.psfhosted.org> Message-ID: <1550770515.02.0.983293477675.issue35995@roundup.psfhosted.org> Vinay Sajip added the comment: The existing implementation supports doing an SSL handshake using STARTTLS, which provides encryption for the actual email traffic. You are asking, it seems, to support a server that only listens on an already encrypted connection, and doesn't use STARTTLS. That would, in my book, be an *enhancement request* and not a bug. Your PR has removed the STARTTLS support - what is supposed to happen when connecting to a server that listens unencrypted and expects to use STARTTLS to initiate encypted traffic? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 12:39:45 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 21 Feb 2019 17:39:45 +0000 Subject: [issue36067] subprocess terminate() "invalid handle" error when process is gone In-Reply-To: <1550763482.04.0.374893682062.issue36067@roundup.psfhosted.org> Message-ID: <1550770785.36.0.529359092534.issue36067@roundup.psfhosted.org> Giampaolo Rodola' added the comment: On POSIX there is that risk, yes. As for Windows, the termination is based on the process handle instead of the PID, but I am not sure if that makes a difference. The risk of reusing the PID/handle is not related to this issue though. The solution I propose just ignores ERROR_INVALID_HANDLE and makes it an alias for "process is already gone". It does not involve preventing the termination of other process handles/PIDs (FWIW in order to do that in psutil I use PID + process' creation time to identify a process uniquely). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 12:47:48 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 21 Feb 2019 17:47:48 +0000 Subject: [issue36060] Document how collections.ChainMap() determines iteration order In-Reply-To: <1550709045.44.0.467024509195.issue36060@roundup.psfhosted.org> Message-ID: <1550771268.49.0.343373883064.issue36060@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 7121a6eeb7941f36fb9e7eae28ec24ecfa533e81 by Raymond Hettinger (Miss Islington (bot)) in branch '3.7': bpo-36060: Document how collections.ChainMap() determines iteration order (GH-11969) (GH-11978) https://github.com/python/cpython/commit/7121a6eeb7941f36fb9e7eae28ec24ecfa533e81 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 12:49:26 2019 From: report at bugs.python.org (Roundup Robot) Date: Thu, 21 Feb 2019 17:49:26 +0000 Subject: [issue22865] Document how to make pty.spawn not copy data In-Reply-To: <1415901686.09.0.50650588621.issue22865@psf.upfronthosting.co.za> Message-ID: <1550771366.79.0.325730537878.issue22865@roundup.psfhosted.org> Change by Roundup Robot : ---------- pull_requests: +12004 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 12:50:50 2019 From: report at bugs.python.org (Geoff Shannon) Date: Thu, 21 Feb 2019 17:50:50 +0000 Subject: [issue22865] Document how to make pty.spawn not copy data In-Reply-To: <1415901686.09.0.50650588621.issue22865@psf.upfronthosting.co.za> Message-ID: <1550771450.16.0.607316227685.issue22865@roundup.psfhosted.org> Geoff Shannon added the comment: It is submitted @cheryl.sabella. Thanks for reviving this, I had totally lost track of it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 13:15:48 2019 From: report at bugs.python.org (Neil Schemenauer) Date: Thu, 21 Feb 2019 18:15:48 +0000 Subject: [issue35810] Object Initialization does not incref Heap-allocated Types In-Reply-To: <1548275752.94.0.463880453345.issue35810@roundup.psfhosted.org> Message-ID: <1550772948.83.0.518409938357.issue35810@roundup.psfhosted.org> Neil Schemenauer added the comment: Hello Eddie, Thank you for putting what looks to be significant effort into this PR. It would be great if we can get this fixed. There is a real issue about breaking 3rd party extensions. So, we want to proceed with care. I wonder, if we are going to break extensions already, could we just remove the whole concept of heap allocated types? If you look through the CPython source code, I think you will find a lot of tricky code that deals with the Py_TPFLAGS_HEAPTYPE case. If we could remove heap types, we could remove all those cases. That would give some performance improvement but more importantly would simplify the implementation. If PyType_FromSpec() is now working correctly, could we just move everything that the currently a heap type to use that? Obviously we have to give 3rd party extensions a lot of time to get themselves updated. Maybe give a deprecation warning if Py_TPFLAGS_HEAPTYPE is used. You could have a configuration option for Python that enables or disables the Py_TPFLAGS_HEAPTYPE support. Once we think extensions have been given enough time to update themselves, we can remove Py_TPFLAGS_HEAPTYPE. Some other possible advantages of getting rid of heap types: - GC objects will always have the GC header allocated (because CPython controls the allocation of the chunk of memory for the type) - might be possible to eliminate GC headers and use bitmaps. I have been experimenting with the idea but it seems to require that we don't use heap types. Initially I was interested in the bitmap idea because of memory savings. After more tinkering, I think the big win will be in eliminating linked-list traversals. On modern CPUs, that's slow and iterating over a bitmap should be much faster. - I suspect heap types are difficult to support for PyPy. I haven't looked into that but it seems tricky when you have non-refcounting GC - type_is_gc() is ugly and would go away. Based on my profiling, PyObject_IS_GC() is pretty expensive. A lot of types have the tp_is_gc slot set (more than you would expect). - In the very long term, using PyType_FromSpec() could give us the freedom to change the structure layout of types. I don't have any specific ideas about that but it seems like a better design. ---------- nosy: +nascheme _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 13:20:39 2019 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 21 Feb 2019 18:20:39 +0000 Subject: [issue35812] Don't log an exception from the main coroutine in asyncio.run() In-Reply-To: <1548291532.01.0.358121522852.issue35812@roundup.psfhosted.org> Message-ID: <1550773239.83.0.883010017689.issue35812@roundup.psfhosted.org> Andrew Svetlov added the comment: Nevermind. Actually, I used a backport `asyncio.run()` to Python 3.6. I saw the problem because of the difference between `asyncio.all_task()` and `asyncio.Task.all_task()`. The former return only active tasks but the later returns done tasks also. ---------- resolution: -> not a bug _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 13:20:52 2019 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 21 Feb 2019 18:20:52 +0000 Subject: [issue35812] Don't log an exception from the main coroutine in asyncio.run() In-Reply-To: <1548291532.01.0.358121522852.issue35812@roundup.psfhosted.org> Message-ID: <1550773252.75.0.122547619419.issue35812@roundup.psfhosted.org> Change by Andrew Svetlov : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 13:38:41 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Thu, 21 Feb 2019 18:38:41 +0000 Subject: [issue36019] test_urllib fail in s390x buildbots: http://www.example.com/ In-Reply-To: <1550450495.08.0.90804425705.issue36019@roundup.psfhosted.org> Message-ID: <1550774321.07.0.368974944767.issue36019@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: Related failure: https://buildbot.python.org/all/#/builders/141/builds/1233 ---------------------------------------------------------------------- Ran 56 tests in 25.105s OK (skipped=1) Re-running test 'test_normalization' in verbose mode test_bug_834676 (test.test_normalization.NormalizationTest) ... ok test test_normalization failed test_main (test.test_normalization.NormalizationTest) ... fetching http://www.pythontest.net/unicode/11.0.0/NormalizationTest.txt ... FAIL ====================================================================== FAIL: test_main (test.test_normalization.NormalizationTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/urllib/request.py", line 1316, in do_open h.request(req.get_method(), req.selector, req.data, headers, socket.gaierror: [Errno -3] Temporary failure in name resolution During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_normalization.py", line 41, in test_main testdata = open_urlresource(TESTDATAURL, encoding="utf-8", urllib.error.URLError: During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_normalization.py", line 47, in test_main self.fail(f"Could not retrieve {TESTDATAURL}") AssertionError: Could not retrieve http://www.pythontest.net/unicode/11.0.0/NormalizationTest.txt ---------------------------------------------------------------------- Ran 2 tests in 20.044s FAILED (failures=1) Re-running test 'test_urllib2net' in verbose mode test_close (test.test_urllib2net.CloseSocketTest) ... skipped "Resource 'http://www.example.com/' is not available" test_custom_headers (test.test_urllib2net.OtherNetworkTests) ... skipped "Resource 'http://www.example.com' is not available" test_file (test.test_urllib2net.OtherNetworkTests) ... ok test_ftp (test.test_urllib2net.OtherNetworkTests) ... ok test_redirect_url_withfrag (test.test_urllib2net.OtherNetworkTests) ... skipped "Resource 'http://www.pythontest.net/redir/with_frag/' is not available" test_sites_no_connection_close (test.test_urllib2net.OtherNetworkTests) ... skipped 'XXX: http://www.imdb.com is gone' test_urlwithfrag (test.test_urllib2net.OtherNetworkTests) ... skipped "Resource 'http://www.pythontest.net/index.html#frag' is not available" test_ftp_basic (test.test_urllib2net.TimeoutTest) ... ok test_ftp_default_timeout (test.test_urllib2net.TimeoutTest) ... ok test_ftp_no_timeout (test.test_urllib2net.TimeoutTest) ... ok test_ftp_timeout (test.test_urllib2net.TimeoutTest) ... ok test_http_basic (test.test_urllib2net.TimeoutTest) ... ok test_http_default_timeout (test.test_urllib2net.TimeoutTest) ... ok test_http_no_timeout (test.test_urllib2net.TimeoutTest) ... ok /srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/support/__init__.py:1608: ResourceWarning: unclosed gc.collect() ResourceWarning: Enable tracemalloc to get the object allocation traceback /srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/support/__init__.py:1608: ResourceWarning: unclosed gc.collect() ResourceWarning: Enable tracemalloc to get the object allocation traceback test_http_timeout (test.test_urllib2net.TimeoutTest) ... ok ---------------------------------------------------------------------- Ran 15 tests in 686.335s OK (skipped=5) 1 test failed again: test_normalization Also, it seems that there are some socket leaks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 13:39:48 2019 From: report at bugs.python.org (Neil Schemenauer) Date: Thu, 21 Feb 2019 18:39:48 +0000 Subject: [issue35810] Object Initialization does not incref Heap-allocated Types In-Reply-To: <1548275752.94.0.463880453345.issue35810@roundup.psfhosted.org> Message-ID: <1550774388.77.0.866027004385.issue35810@roundup.psfhosted.org> Neil Schemenauer added the comment: Sorry, morning coffee didn't kick in yet I guess. ;-) My actual wish is to make all types heap allocated and eliminate the statically allocated ones. So, Py_TPFLAGS_HEAPTYPE would be set on all types in that world. That is a gigantic task, affecting near every Python extension type. Too huge for even a nutty person like me to imagine doing in the near term. So, sorry for potentially derailing discussion here. I agree with comments made by Stefan Behnel and Petr Viktorin. There is a small risk to cause problems (i.e. serious memory leaks in a previously working program). However, as Petr says, the extension in that case is broken and it is not hard to fix. Eddie has provided examples for what changes are needed. I think if we properly communicate the change then it is okay to merge the PR. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 13:44:13 2019 From: report at bugs.python.org (Joe Jevnik) Date: Thu, 21 Feb 2019 18:44:13 +0000 Subject: [issue36068] Make _tuplegetter objects serializable Message-ID: <1550774653.56.0.094424899165.issue36068@roundup.psfhosted.org> New submission from Joe Jevnik : The new _tuplegetter objects for accessing fields of a namedtuple are no longer serializable with pickle. Cloudpickle, a library which provides extensions to pickle to facilitate distributed computing in Python, depended on being able to pickle the members of namedtuple classes. While property isn't serializable, cloudpickle has support for properties allowing us to serialize the old property(itemgetter) members. The attached PR adds a __reduce__ method to _tuplegetter objects which will allow serialization without special support. Another option would be to expose `index` as a read-only attribute, allowing cloudpickle or other libraries to provide the pickle implementation as a third-party library. ---------- components: Library (Lib) messages: 336251 nosy: llllllllll priority: normal severity: normal status: open title: Make _tuplegetter objects serializable type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 13:46:07 2019 From: report at bugs.python.org (Joe Jevnik) Date: Thu, 21 Feb 2019 18:46:07 +0000 Subject: [issue36068] Make _tuplegetter objects serializable In-Reply-To: <1550774653.56.0.094424899165.issue36068@roundup.psfhosted.org> Message-ID: <1550774767.63.0.990289798506.issue36068@roundup.psfhosted.org> Change by Joe Jevnik : ---------- keywords: +patch pull_requests: +12006 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 13:46:17 2019 From: report at bugs.python.org (Marc Schlaich) Date: Thu, 21 Feb 2019 18:46:17 +0000 Subject: [issue35840] Control flow inconsistency on closed asyncio stream In-Reply-To: <1548662045.39.0.770532095049.issue35840@roundup.psfhosted.org> Message-ID: <1550774777.09.0.74039462388.issue35840@roundup.psfhosted.org> Marc Schlaich added the comment: No, I'm seeing the same issue on MacOS. Attached modified example. ---------- Added file: https://bugs.python.org/file48160/tcp_test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 13:51:10 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 21 Feb 2019 18:51:10 +0000 Subject: [issue36068] Make _tuplegetter objects serializable In-Reply-To: <1550774653.56.0.094424899165.issue36068@roundup.psfhosted.org> Message-ID: <1550775070.47.0.0702193329273.issue36068@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 14:13:47 2019 From: report at bugs.python.org (=?utf-8?q?Leonardo_M=C3=B6rlein?=) Date: Thu, 21 Feb 2019 19:13:47 +0000 Subject: [issue36069] asyncio: create_connection cannot handle IPv6 link-local addresses anymore (linux) Message-ID: <1550776427.72.0.170763876114.issue36069@roundup.psfhosted.org> New submission from Leonardo M?rlein : The tuple (host, port) is ("fe80::5054:01ff:fe04:3402%node4_client", 22) in https://github.com/python/cpython/blob/master/Lib/asyncio/base_events.py#L918. The substring "node4_client" identifies the interface, which is needed for link local connections. The function self._ensure_resolved() is called and resolves to infos[0][4] = ("fe80::5054:01ff:fe04:3402", 22, something, 93), where 93 is the resolved scope id (see sin6_scope_id from struct sockaddr_in6 from man ipv6). Afterwards the self.sock_connect() is called with address = infos[0][4]. In self.sock_connect() the function self._ensure_resolved() is called again. In https://github.com/python/cpython/blob/master/Lib/asyncio/base_events.py#L1282 the scope id is stripped from the tuple. The tuple (host, port) is now only ("fe80::5054:01ff:fe04:3402", 22) and therefore the scope id is lost. I wrote this quick fix, which is not really suitable as a real solution for the problem: lemoer at orange ~> diff /usr/lib/python3.7/asyncio/base_events.py{.bak,} --- /usr/lib/python3.7/asyncio/base_events.py.bak 2019-02-21 18:42:17.060122277 +0100 +++ /usr/lib/python3.7/asyncio/base_events.py 2019-02-21 18:49:36.886866750 +0100 @@ -942,8 +942,8 @@ sock = None continue if self._debug: - logger.debug("connect %r to %r", sock, address) - await self.sock_connect(sock, address) + logger.debug("connect %r to %r", sock, (host, port)) + await self.sock_connect(sock, (host, port)) except OSError as exc: if sock is not None: sock.close() ---------- components: asyncio messages: 336253 nosy: Leonardo M?rlein, asvetlov, yselivanov priority: normal severity: normal status: open title: asyncio: create_connection cannot handle IPv6 link-local addresses anymore (linux) versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 14:16:05 2019 From: report at bugs.python.org (=?utf-8?q?Leonardo_M=C3=B6rlein?=) Date: Thu, 21 Feb 2019 19:16:05 +0000 Subject: [issue36069] asyncio: create_connection cannot handle IPv6 link-local addresses anymore (linux) In-Reply-To: <1550776427.72.0.170763876114.issue36069@roundup.psfhosted.org> Message-ID: <1550776565.12.0.316669644081.issue36069@roundup.psfhosted.org> Leonardo M?rlein added the comment: The generated error is: OSError: [Errno 22] Invalid argument ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 14:28:28 2019 From: report at bugs.python.org (=?utf-8?q?Leonardo_M=C3=B6rlein?=) Date: Thu, 21 Feb 2019 19:28:28 +0000 Subject: [issue36069] asyncio: create_connection cannot handle IPv6 link-local addresses anymore (linux) In-Reply-To: <1550776427.72.0.170763876114.issue36069@roundup.psfhosted.org> Message-ID: <1550777308.73.0.550195698307.issue36069@roundup.psfhosted.org> Leonardo M?rlein added the comment: It seems to be a regression, as my python 3.6 version is not affected: lemoer at orange ~> python3.6 --version Python 3.6.8 My python 3.7 version is affected: lemoer at orange ~> python3.7 --version Python 3.7.2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 14:51:34 2019 From: report at bugs.python.org (Jeff Robbins) Date: Thu, 21 Feb 2019 19:51:34 +0000 Subject: [issue35662] Windows #define _PY_EMULATED_WIN_CV 0 bug In-Reply-To: <1546658725.61.0.827924851828.issue35662@roundup.psfhosted.org> Message-ID: <1550778694.13.0.315171909052.issue35662@roundup.psfhosted.org> Jeff Robbins added the comment: Steve, I did some more digging into why the native condition variable approach might be causing problems on Windows. Testing my fix revealed that there is at least one place in Modules\overlapped.c that either a) waits too long to call GetLastError(), or b) reveals an expectation that Py_END_ALLOW_THREADS won't change the results of GetLastError(). Py_BEGIN_ALLOW_THREADS ret = GetQueuedCompletionStatus(CompletionPort, &NumberOfBytes, &CompletionKey, &Overlapped, Milliseconds); save_err = GetLastError(); Py_END_ALLOW_THREADS err = ret ? ERROR_SUCCESS : GetLastError(); The problem in this code is that it allows *other* Windows API calls between the original Windows API call (in this case GetQueuedCompletionStatus()) and the call to GetLastError(). If those other Windows API calls change the thread-specific GetLastError state, the info we need is lost. To test for this possibility, I added a diagnostic test right after the code above if (!ret && (err != save_err)) { printf("GetQueuedCompletionStatus returned 0 but we lost the error=%d lost=%d Overlapped=%d\n", save_err, err, (long)Overlapped); } and ran a test that eventually produced this on the console: GetQueuedCompletionStatus returned 0 but we lost the error=258 lost=0 Overlapped=0 error 258 is WAIT_TIMEOUT. The next lines of code are looking for that "error" in order to decide if GetQueuedCompletionStatus failed, or merely timed out. if (Overlapped == NULL) { if (err == WAIT_TIMEOUT) Py_RETURN_NONE; else return SetFromWindowsErr(err); } So the impact of this problem is severe. Instead of returning None to the caller (in this case _poll in asyncio\windows_events.py), it will raise an error! while True: status = _overlapped.GetQueuedCompletionStatus(self._iocp, ms) if status is None: break And, to make things extra confusing, the error raised via SetFromWindowsErr(err) (where err == 0) ends up looking like this: OSError: [WinError 0] The operation completed successfully A valid WAIT_TIMEOUT thus gets converted to a Python error, but also loses the original Windows Error Code of 258, so you are left scratching your head about how a WinError 0 (ERROR_SUCCESS) could have crashed your call to, say, asyncio.run()? (See traceback below.) So either we need to make sure that all calls to GetLastError() are made immediately after the relevant Windows API call, without any intervening other Windows API calls, and thereby prevent case a) above, or as in case b), the GIL code (using either emulated or native condition variables from condvar.h) needs to preserve the Error state. Some code in Python\thread_nt.h in fact does this already, e.g. void * PyThread_get_key_value(int key) { /* because TLS is used in the Py_END_ALLOW_THREAD macro, * it is necessary to preserve the windows error state, because * it is assumed to be preserved across the call to the macro. * Ideally, the macro should be fixed, but it is simpler to * do it here. */ DWORD error = GetLastError(); void *result = TlsGetValue(key); SetLastError(error); return result; } Of course there might be *other* problems associated with using native condition variables on Windows, but this is the only one I've experienced after some fairly heavy use of Python 3.7.2 asyncio on Windows. traceback: ------------------------------------------------------------------------------------------------------------------------ asyncio.run(self.main()) File "C:\Users\jeffr\Documents\projects\Python-3.7.2\lib\asyncio\runners.py", line 43, in run return loop.run_until_complete(main) File "C:\Users\jeffr\Documents\projects\Python-3.7.2\lib\asyncio\base_events.py", line 571, in run_until_complete self.run_forever() File "C:\Users\jeffr\Documents\projects\Python-3.7.2\lib\asyncio\base_events.py", line 539, in run_forever self._run_once() File "C:\Users\jeffr\Documents\projects\Python-3.7.2\lib\asyncio\base_events.py", line 1739, in _run_once event_list = self._selector.select(timeout) File "C:\Users\jeffr\Documents\projects\Python-3.7.2\lib\asyncio\windows_events.py", line 405, in select self._poll(timeout) File "C:\Users\jeffr\Documents\projects\Python-3.7.2\lib\asyncio\windows_events.py", line 703, in _poll status = _overlapped.GetQueuedCompletionStatus(self._iocp, ms) OSError: [WinError 0] The operation completed successfully ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 15:33:03 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Thu, 21 Feb 2019 20:33:03 +0000 Subject: [issue22865] Document how to make pty.spawn not copy data In-Reply-To: <1415901686.09.0.50650588621.issue22865@psf.upfronthosting.co.za> Message-ID: <1550781183.0.0.156301071687.issue22865@roundup.psfhosted.org> Cheryl Sabella added the comment: Thanks @RadicalZephyr! @martin.panter, please review the PR when you get a chance. Thank you! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 15:59:55 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 21 Feb 2019 20:59:55 +0000 Subject: [issue36068] Make _tuplegetter objects serializable In-Reply-To: <1550774653.56.0.094424899165.issue36068@roundup.psfhosted.org> Message-ID: <1550782795.82.0.348273763461.issue36068@roundup.psfhosted.org> Raymond Hettinger added the comment: Thanks for noticing this. We really should have stuck with the original plan of subclassing property(). ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 16:00:43 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 21 Feb 2019 21:00:43 +0000 Subject: [issue36068] Make _tuplegetter objects serializable In-Reply-To: <1550774653.56.0.094424899165.issue36068@roundup.psfhosted.org> Message-ID: <1550782843.06.0.606251374313.issue36068@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset f36f89257b30e0bf88e8aaff6da14a9a96f57b9e by Raymond Hettinger (Joe Jevnik) in branch 'master': bpo-36068: Make _tuplegetter objects serializable (GH-11981) https://github.com/python/cpython/commit/f36f89257b30e0bf88e8aaff6da14a9a96f57b9e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 16:01:12 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 21 Feb 2019 21:01:12 +0000 Subject: [issue36068] Make _tuplegetter objects serializable In-Reply-To: <1550774653.56.0.094424899165.issue36068@roundup.psfhosted.org> Message-ID: <1550782872.05.0.438874381.issue36068@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 16:11:29 2019 From: report at bugs.python.org (Joe Jevnik) Date: Thu, 21 Feb 2019 21:11:29 +0000 Subject: [issue36068] Make _tuplegetter objects serializable In-Reply-To: <1550774653.56.0.094424899165.issue36068@roundup.psfhosted.org> Message-ID: <1550783489.26.0.433256743842.issue36068@roundup.psfhosted.org> Joe Jevnik added the comment: Thank you for reviewing this so quickly! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 16:14:11 2019 From: report at bugs.python.org (Ethan Furman) Date: Thu, 21 Feb 2019 21:14:11 +0000 Subject: [issue35899] '_is_sunder' function in 'enum' module fails on empty string In-Reply-To: <1549376859.01.0.998806898699.issue35899@roundup.psfhosted.org> Message-ID: <1550783651.47.0.230704781484.issue35899@roundup.psfhosted.org> Ethan Furman added the comment: The changes to `_is_sunder` and `_is_dunder` look good, but there is a problem with the underlying assumptions of what Enum should be doing: - nameless members are not to be allowed - non-alphanumeric characters are not supported In other words, while `_is_sunder` should not fail, neither should an empty string be allowed as a member name. This can be checked at line 154 (just add '' to the set) -- then double check that the error raised is a ValueError and not an IndexError. For the strange character portion, use some non-latin numbers and letters to make sure they work, but don't check for symbols such as exclamation points -- while they might work, we are not supporting such things, and having a test that checks to make sure they work suggests that we do support it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 16:26:57 2019 From: report at bugs.python.org (Eryk Sun) Date: Thu, 21 Feb 2019 21:26:57 +0000 Subject: [issue36067] subprocess terminate() "invalid handle" error when process is gone In-Reply-To: <1550763482.04.0.374893682062.issue36067@roundup.psfhosted.org> Message-ID: <1550784417.79.0.399750181004.issue36067@roundup.psfhosted.org> Eryk Sun added the comment: The subprocess Handle object is never finalized explicitly, so the Process handle should always be valid as long as we have a reference to the Popen instance. We can call TerminateProcess as many times as we want, and the handle will still be valid. If it's already terminated, NtTerminateProcess fails with STATUS_PROCESS_IS_TERMINATING, which maps to Windows ERROR_ACCESS_DENIED. If some other code mistakenly called CloseHandle on our handle. This is a serious bug that should never be silenced and always raise an exception if we can detect it. If the handle value hasn't been reused, NtTerminateProcess fails with STATUS_INVALID_HANDLE. If it now references a non-Process object, it fails with STATUS_OBJECT_TYPE_MISMATCH. Both of these map to Windows ERROR_INVALID_HANDLE. If the handle value was reused by a Process object (either via CreateProcess[AsUser] or OpenProcess) that lacks the PROCESS_TERMINATE (1) right (cannot be our original handle, since ours had all access), then it fails with STATUS_ACCESS_DENIED, which maps to Windows ERROR_ACCESS_DENIED. Otherwise if it has the PROCESS_TERMINATE right, then currently we'll end up terminating an unrelated process. As mentioned by Giampaolo, we could improve our chances of catching this bug by first verifying the PID via GetProcessId and the creation time from GetProcessTimes. We'd also have to store the creation time in _execute_child. Both functions would have to be added to _winapi. > The solution I propose just ignores ERROR_INVALID_HANDLE and > makes it an alias for "process is already gone". If we get ERROR_INVALID_HANDLE, we should not try to call GetExitCodeProcess. All we know is that it either wasn't a valid handle or was reused to reference a non-Process object. Maybe by the time we call GetExitCodeProcess it has since been reused again to reference a Process. That would silence the error and propagate a bug by setting an unrelated exit status. Otherwise, GetExitCodeProcess will just fail again with ERROR_INVALID_HANDLE. There's no point to this, and it's potentially making the problem worse. --- Also, unrelated but something I noticed. Using _active list in Windows shouldn't be necessary. Unlike Unix, a process in Windows doesn't have to be waited on by its parent to avoid a zombie. Keeping the handle open will actually create a zombie until the next _cleanup() call, which may be never if Popen() isn't called again. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 16:46:58 2019 From: report at bugs.python.org (Steve Dower) Date: Thu, 21 Feb 2019 21:46:58 +0000 Subject: [issue35662] Windows #define _PY_EMULATED_WIN_CV 0 bug In-Reply-To: <1546658725.61.0.827924851828.issue35662@roundup.psfhosted.org> Message-ID: <1550785618.09.0.77798480888.issue35662@roundup.psfhosted.org> Steve Dower added the comment: > reveals an expectation that Py_END_ALLOW_THREADS won't change the results of GetLastError() Fantastic work, Jeff! That's almost certainly the major problem there - Py_END_ALLOW_THREADS can totally change the error code, and we haven't ever done a full sweep to check it. Feel free to send a PR against issue29871 with your changes. If the tests are happy, then I am too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 16:47:47 2019 From: report at bugs.python.org (Steve Dower) Date: Thu, 21 Feb 2019 21:47:47 +0000 Subject: [issue29871] Enable optimized locks on Windows In-Reply-To: <1490146396.76.0.76409234296.issue29871@psf.upfronthosting.co.za> Message-ID: <1550785667.69.0.157663596214.issue29871@roundup.psfhosted.org> Steve Dower added the comment: > I assume you meant #35662 Yes indeed. I am apparently massively dyslexic when it comes to copying issue numbers into the bpo comment field :) Meanwhile, over on #35662, Jeff has a fix for at least one of the regressions. ---------- versions: +Python 3.8 -Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 16:50:42 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Thu, 21 Feb 2019 21:50:42 +0000 Subject: [issue35867] NameError is not caught at Task execution In-Reply-To: <1548940597.02.0.134680701167.issue35867@roundup.psfhosted.org> Message-ID: <1550785842.03.0.529177732355.issue35867@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: I do not think this is a bug. Any exception that is raised inside a task will be in the .exception() method when the task is finished. Here you are running the task without waiting for finalization. For example, if you change: async def cofunc1(self): await self.cofunc2() await self.task # <------------- print("\nwaitin' : where-t-f is the NameError hiding!?") await asyncio.sleep(6) print("Wait is over, let's exit\n") you will find the NameError immediately. If you do not want to await the task you can wait until self.task.done() is True and then check self.task.exception() for retrieving the exception (if any). What happens with BaseException is that is a very low-level exception that is handled differently compared with regular exceptions that derive from Exception. The reason is that control flow exceptions and things like KeyboardInterrupt need to be handled differently. This happens explicitly here: https://github.com/python/cpython/blob/master/Modules/_asynciomodule.c#L2675 ---------- nosy: +pablogsal resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 17:12:50 2019 From: report at bugs.python.org (Steve Dower) Date: Thu, 21 Feb 2019 22:12:50 +0000 Subject: [issue33944] Deprecate and remove pth files In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za> Message-ID: <1550787170.52.0.0286431064474.issue33944@roundup.psfhosted.org> Change by Steve Dower : ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 17:17:47 2019 From: report at bugs.python.org (Jeff Robbins) Date: Thu, 21 Feb 2019 22:17:47 +0000 Subject: [issue35662] Windows #define _PY_EMULATED_WIN_CV 0 bug In-Reply-To: <1546658725.61.0.827924851828.issue35662@roundup.psfhosted.org> Message-ID: <1550787467.33.0.667068852883.issue35662@roundup.psfhosted.org> Jeff Robbins added the comment: Steve, sorry to be dense, but I'm unfortunately ignorant as to what tests I ought to be running. The only test I have right now is much too complicated, and I'd rather be running some official regression test that reveals the problem without my app code, if possible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 17:21:58 2019 From: report at bugs.python.org (Martin Panter) Date: Thu, 21 Feb 2019 22:21:58 +0000 Subject: [issue34785] pty.spawn -- auto-termination after child process is dead (a zombie) In-Reply-To: <1537773919.52.0.956365154283.issue34785@psf.upfronthosting.co.za> Message-ID: <1550787718.79.0.714974353703.issue34785@roundup.psfhosted.org> Martin Panter added the comment: Suggest closing this assuming it is a duplicate, unless Jarry can give more information. ---------- resolution: -> duplicate status: open -> pending superseder: -> pty.spawn hangs on FreeBSD 9.3, 10.x _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 17:53:58 2019 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 21 Feb 2019 22:53:58 +0000 Subject: [issue22239] asyncio: nested event loop In-Reply-To: <1408557830.66.0.604610139339.issue22239@psf.upfronthosting.co.za> Message-ID: <1550789638.75.0.209329767548.issue22239@roundup.psfhosted.org> Change by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 18:03:53 2019 From: report at bugs.python.org (Martin Panter) Date: Thu, 21 Feb 2019 23:03:53 +0000 Subject: [issue22865] Document how to make pty.spawn not copy data In-Reply-To: <1415901686.09.0.50650588621.issue22865@psf.upfronthosting.co.za> Message-ID: <1550790233.98.0.269204935916.issue22865@roundup.psfhosted.org> Martin Panter added the comment: I'm not sure it is wise for the Python documentation to suggest inserting null bytes in general. This seems more like an application-specific hack. There is nothing in Python that handles these null bytes specially, and I expect they will be seen if the child reads the terminal in raw mode, or if the parent's output is redirected to a file, sent over the network or a real serial link. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 18:06:36 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 21 Feb 2019 23:06:36 +0000 Subject: [issue35904] Add statistics.fmean(seq) In-Reply-To: <1549411161.36.0.783593325223.issue35904@roundup.psfhosted.org> Message-ID: <1550790396.16.0.0174004610397.issue35904@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 47d9987247bcc45983a6d51fd1ae46d5d356d0f8 by Raymond Hettinger in branch 'master': bpo-35904: Add statistics.fmean() (GH-11892) https://github.com/python/cpython/commit/47d9987247bcc45983a6d51fd1ae46d5d356d0f8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 18:07:02 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 21 Feb 2019 23:07:02 +0000 Subject: [issue35904] Add statistics.fmean(seq) In-Reply-To: <1549411161.36.0.783593325223.issue35904@roundup.psfhosted.org> Message-ID: <1550790422.06.0.0652663685707.issue35904@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 18:25:38 2019 From: report at bugs.python.org (Nathan Woods) Date: Thu, 21 Feb 2019 23:25:38 +0000 Subject: [issue36070] Enclosing scope not visible from within list comprehension Message-ID: <1550791538.43.0.767407053529.issue36070@roundup.psfhosted.org> New submission from Nathan Woods : The following code works in an interactive shell or in a batch file, but not when executed as part of a unittest suite or pdb: from random import random out = [random() for ind in range(3)] It can be made to work using pdb interact, but this doesn't help with unittest. Tested in Python 3.7.2 ---------- messages: 336270 nosy: woodscn priority: normal severity: normal status: open title: Enclosing scope not visible from within list comprehension type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 18:32:21 2019 From: report at bugs.python.org (=?utf-8?q?Mihai_Capot=C4=83?=) Date: Thu, 21 Feb 2019 23:32:21 +0000 Subject: [issue35651] PEP 257 (active) references PEP 258 (rejected) as if it were active In-Reply-To: <1546536866.6.0.633154963858.issue35651@roundup.psfhosted.org> Message-ID: <1550791941.28.0.553517659165.issue35651@roundup.psfhosted.org> Change by Mihai Capot? : ---------- nosy: +mihaic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 18:35:15 2019 From: report at bugs.python.org (Zachary Ware) Date: Thu, 21 Feb 2019 23:35:15 +0000 Subject: [issue36070] Enclosing scope not visible from within list comprehension In-Reply-To: <1550791538.43.0.767407053529.issue36070@roundup.psfhosted.org> Message-ID: <1550792115.95.0.98547820803.issue36070@roundup.psfhosted.org> Zachary Ware added the comment: Can you attach a test file that shows the failure? ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 18:45:43 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 21 Feb 2019 23:45:43 +0000 Subject: [issue36046] support dropping privileges when running subprocesses In-Reply-To: <1550625858.55.0.53498127684.issue36046@roundup.psfhosted.org> Message-ID: <1550792743.56.0.561205345787.issue36046@roundup.psfhosted.org> Change by Gregory P. Smith : ---------- assignee: -> gregory.p.smith nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 19:05:55 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Fri, 22 Feb 2019 00:05:55 +0000 Subject: [issue36067] subprocess terminate() "invalid handle" error when process is gone In-Reply-To: <1550763482.04.0.374893682062.issue36067@roundup.psfhosted.org> Message-ID: <1550793955.01.0.437382158175.issue36067@roundup.psfhosted.org> Giampaolo Rodola' added the comment: Interesting. Because both errors/conditions are mapped to ERROR_INVALID_HANDLE we need the creation time. I can work on a patch for that. Potentially I can also include OSX, Linux and BSD* implementations for methods involving os.kill(pid). That would be a broader task though. That also raises the question if there are other methods other than kill()/terminate()/send_signal() that we want to make "safe" from the reused PID scenario. > Also, unrelated but something I noticed. Using _active list in Windows shouldn't be necessary. Unlike Unix, a process in Windows doesn't have to be waited on by its parent to avoid a zombie. Keeping the handle open will actually create a zombie until the next _cleanup() call, which may be never if Popen() isn't called again. Good catch. Looks like it deserves a ticket. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 19:34:06 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Fri, 22 Feb 2019 00:34:06 +0000 Subject: [issue28235] In xml.etree.ElementTree docs there is no parser argument in fromstring() In-Reply-To: <1474457056.95.0.329737294315.issue28235@psf.upfronthosting.co.za> Message-ID: <1550795646.16.0.853518286379.issue28235@roundup.psfhosted.org> Cheryl Sabella added the comment: New changeset e5458bdb6af81f9b98acecd8819c60016d3f1441 by Cheryl Sabella (Manjusaka) in branch 'master': bpo-28235: Fix xml.etree.ElementTree.fromstring docs (GH-11903) https://github.com/python/cpython/commit/e5458bdb6af81f9b98acecd8819c60016d3f1441 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 19:34:20 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 22 Feb 2019 00:34:20 +0000 Subject: [issue28235] In xml.etree.ElementTree docs there is no parser argument in fromstring() In-Reply-To: <1474457056.95.0.329737294315.issue28235@psf.upfronthosting.co.za> Message-ID: <1550795660.1.0.343566609086.issue28235@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +12007 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 19:45:34 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 22 Feb 2019 00:45:34 +0000 Subject: [issue28235] In xml.etree.ElementTree docs there is no parser argument in fromstring() In-Reply-To: <1474457056.95.0.329737294315.issue28235@psf.upfronthosting.co.za> Message-ID: <1550796334.42.0.549560557008.issue28235@roundup.psfhosted.org> miss-islington added the comment: New changeset b046f1badaaffb7e526b937fa2192c449b9076ed by Miss Islington (bot) in branch '3.7': bpo-28235: Fix xml.etree.ElementTree.fromstring docs (GH-11903) https://github.com/python/cpython/commit/b046f1badaaffb7e526b937fa2192c449b9076ed ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 19:50:39 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Fri, 22 Feb 2019 00:50:39 +0000 Subject: [issue28235] In xml.etree.ElementTree docs there is no parser argument in fromstring() In-Reply-To: <1474457056.95.0.329737294315.issue28235@psf.upfronthosting.co.za> Message-ID: <1550796639.92.0.143213751877.issue28235@roundup.psfhosted.org> Cheryl Sabella added the comment: Thank you @py.user for reporting this issue and for the original patch and thank you @Manjusaka for the PR! This was my first merge! Woot! :-) ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 19:57:38 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 22 Feb 2019 00:57:38 +0000 Subject: [issue35662] Windows #define _PY_EMULATED_WIN_CV 0 bug In-Reply-To: <1546658725.61.0.827924851828.issue35662@roundup.psfhosted.org> Message-ID: <1550797058.66.0.665017811217.issue35662@roundup.psfhosted.org> Steve Dower added the comment: The regular test suite ought to be enough - see devguide.python.org for the info. It was definitely failing in multiprocessing last time I tried this. You could also just push changes and start a PR, as that will run the tests automatically. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 22:04:54 2019 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 22 Feb 2019 03:04:54 +0000 Subject: [issue36070] Enclosing scope not visible from within list comprehension In-Reply-To: <1550791538.43.0.767407053529.issue36070@roundup.psfhosted.org> Message-ID: <1550804694.09.0.955126050041.issue36070@roundup.psfhosted.org> Eric V. Smith added the comment: I suspect Nathan is seeing this problem at class scope. This is a well known issue: >>> class C: ... from random import random ... out = [random() for ind in range(3)] ... Traceback (most recent call last): File "", line 1, in File "", line 3, in C File "", line 3, in NameError: name 'random' is not defined >>> It is not related to the list comprehension, but to the class scope. See the last paragraph of https://docs.python.org/3/reference/executionmodel.html#resolution-of-names But I agree with Zach about needing an example that fails. ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 22:34:27 2019 From: report at bugs.python.org (Paul Monson) Date: Fri, 22 Feb 2019 03:34:27 +0000 Subject: [issue36071] Add support for Windows ARM32 in ctypes/libffi Message-ID: <1550806467.14.0.829617126279.issue36071@roundup.psfhosted.org> Change by Paul Monson : ---------- components: Windows, ctypes nosy: Paul Monson, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Add support for Windows ARM32 in ctypes/libffi versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 21 23:23:14 2019 From: report at bugs.python.org (Paulie Pena) Date: Fri, 22 Feb 2019 04:23:14 +0000 Subject: [issue29871] Enable optimized locks on Windows In-Reply-To: <1490146396.76.0.76409234296.issue29871@psf.upfronthosting.co.za> Message-ID: <1550809394.46.0.185640951458.issue29871@roundup.psfhosted.org> Change by Paulie Pena : ---------- nosy: +paulie4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 00:02:18 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 22 Feb 2019 05:02:18 +0000 Subject: [issue36070] Enclosing scope not visible from within list comprehension In-Reply-To: <1550791538.43.0.767407053529.issue36070@roundup.psfhosted.org> Message-ID: <1550811738.06.0.856070881123.issue36070@roundup.psfhosted.org> Serhiy Storchaka added the comment: This is a duplicate of issue3692. ---------- nosy: +serhiy.storchaka resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> improper scope in list comprehension, when used in class declaration _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 00:34:29 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Fri, 22 Feb 2019 05:34:29 +0000 Subject: [issue36072] str.translate() behave differently for ASCII-only and other strings Message-ID: <1550813669.37.0.821443537849.issue36072@roundup.psfhosted.org> New submission from Sergey Fedoseev : In [186]: from itertools import cycle In [187]: class ContainerLike: ...: def __init__(self): ...: self.chars = cycle('12') ...: def __getitem__(self, key): ...: return next(self.chars) ...: In [188]: 'aaaaaa'.translate(ContainerLike()) Out[188]: '111111' In [189]: '??????'.translate(ContainerLike()) Out[189]: '121212 It seems that behavior was changed in https://github.com/python/cpython/commit/89a76abf20889551ec1ed64dee1a4161a435db5b. At least it should be documented. ---------- messages: 336279 nosy: sir-sigurd priority: normal severity: normal status: open title: str.translate() behave differently for ASCII-only and other strings _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 00:44:14 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Fri, 22 Feb 2019 05:44:14 +0000 Subject: [issue36072] str.translate() behaves differently for ASCII-only and other strings In-Reply-To: <1550813669.37.0.821443537849.issue36072@roundup.psfhosted.org> Message-ID: <1550814254.22.0.622429426748.issue36072@roundup.psfhosted.org> Change by Sergey Fedoseev : ---------- title: str.translate() behave differently for ASCII-only and other strings -> str.translate() behaves differently for ASCII-only and other strings _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 01:11:47 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 22 Feb 2019 06:11:47 +0000 Subject: [issue36072] str.translate() behaves differently for ASCII-only and other strings In-Reply-To: <1550813669.37.0.821443537849.issue36072@roundup.psfhosted.org> Message-ID: <1550815907.11.0.552160280114.issue36072@roundup.psfhosted.org> Serhiy Storchaka added the comment: You are using a mapping that returns different values for the same key. You should not expect a stable result for it. I do not think this needs a special mentioning in the documentation. Garbage in -- garbage out. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 01:26:04 2019 From: report at bugs.python.org (twisteroid ambassador) Date: Fri, 22 Feb 2019 06:26:04 +0000 Subject: [issue36069] asyncio: create_connection cannot handle IPv6 link-local addresses anymore (linux) In-Reply-To: <1550776427.72.0.170763876114.issue36069@roundup.psfhosted.org> Message-ID: <1550816764.38.0.898320157986.issue36069@roundup.psfhosted.org> twisteroid ambassador added the comment: Duplicate of issue35545, I believe. ---------- nosy: +twisteroid ambassador _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 01:28:58 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 22 Feb 2019 06:28:58 +0000 Subject: [issue20582] socket.getnameinfo() does not document flags In-Reply-To: <1392042265.22.0.885252016144.issue20582@psf.upfronthosting.co.za> Message-ID: <1550816938.41.0.392931673299.issue20582@roundup.psfhosted.org> Serhiy Storchaka added the comment: You can use the special role :manpage: for referring man pages. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 02:44:47 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Fri, 22 Feb 2019 07:44:47 +0000 Subject: [issue36073] sqlite crashes with converters mutating cursor Message-ID: <1550821487.87.0.741979609564.issue36073@roundup.psfhosted.org> New submission from Sergey Fedoseev : It's somewhat similar to bpo-10811, but for converter function: In [197]: import sqlite3 as sqlite ...: con = sqlite.connect(':memory:', detect_types=sqlite.PARSE_COLNAMES) ...: cur = con.cursor() ...: sqlite.converters['CURSOR_INIT'] = lambda x: cur.__init__(con) ...: ...: cur.execute('create table test(x foo)') ...: cur.execute('insert into test(x) values (?)', ('foo',)) ...: cur.execute('select x as "x [CURSOR_INIT]", x from test') ...: [1] 25718 segmentation fault python manage.py shell Similar to bpo-10811, proposed patch raises ProgrammingError instead of crashing. ---------- components: Extension Modules messages: 336283 nosy: sir-sigurd priority: normal severity: normal status: open title: sqlite crashes with converters mutating cursor type: crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 02:48:13 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Fri, 22 Feb 2019 07:48:13 +0000 Subject: [issue36073] sqlite crashes with converters mutating cursor In-Reply-To: <1550821487.87.0.741979609564.issue36073@roundup.psfhosted.org> Message-ID: <1550821693.89.0.577499953767.issue36073@roundup.psfhosted.org> Change by Sergey Fedoseev : ---------- keywords: +patch pull_requests: +12008 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 02:51:58 2019 From: report at bugs.python.org (Inada Naoki) Date: Fri, 22 Feb 2019 07:51:58 +0000 Subject: [issue32657] Mutable Objects in SMTP send_message Signature In-Reply-To: <1516833897.61.0.467229070634.issue32657@psf.upfronthosting.co.za> Message-ID: <1550821918.7.0.875441827215.issue32657@roundup.psfhosted.org> Change by Inada Naoki : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 02:52:16 2019 From: report at bugs.python.org (Inada Naoki) Date: Fri, 22 Feb 2019 07:52:16 +0000 Subject: [issue32657] Mutable Objects in SMTP send_message Signature In-Reply-To: <1516833897.61.0.467229070634.issue32657@psf.upfronthosting.co.za> Message-ID: <1550821936.18.0.188166048508.issue32657@roundup.psfhosted.org> Change by Inada Naoki : ---------- versions: +Python 3.8 -Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 02:53:44 2019 From: report at bugs.python.org (SilentGhost) Date: Fri, 22 Feb 2019 07:53:44 +0000 Subject: [issue36073] sqlite crashes with converters mutating cursor In-Reply-To: <1550821487.87.0.741979609564.issue36073@roundup.psfhosted.org> Message-ID: <1550822024.22.0.880355842082.issue36073@roundup.psfhosted.org> Change by SilentGhost : ---------- nosy: +ghaering versions: +Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 02:54:16 2019 From: report at bugs.python.org (Inada Naoki) Date: Fri, 22 Feb 2019 07:54:16 +0000 Subject: [issue33961] Inconsistency in exceptions for dataclasses.dataclass documentation In-Reply-To: <1529963695.74.0.56676864532.issue33961@psf.upfronthosting.co.za> Message-ID: <1550822056.43.0.952765818814.issue33961@roundup.psfhosted.org> Change by Inada Naoki : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 03:05:17 2019 From: report at bugs.python.org (=?utf-8?q?Leonardo_M=C3=B6rlein?=) Date: Fri, 22 Feb 2019 08:05:17 +0000 Subject: [issue36069] asyncio: create_connection cannot handle IPv6 link-local addresses anymore (linux) In-Reply-To: <1550776427.72.0.170763876114.issue36069@roundup.psfhosted.org> Message-ID: <1550822717.36.0.525468919219.issue36069@roundup.psfhosted.org> Leonardo M?rlein added the comment: Oh, you are correct. So this can be closed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 03:05:56 2019 From: report at bugs.python.org (=?utf-8?q?Leonardo_M=C3=B6rlein?=) Date: Fri, 22 Feb 2019 08:05:56 +0000 Subject: [issue36069] asyncio: create_connection cannot handle IPv6 link-local addresses anymore (linux) In-Reply-To: <1550776427.72.0.170763876114.issue36069@roundup.psfhosted.org> Message-ID: <1550822756.61.0.0605396245597.issue36069@roundup.psfhosted.org> Change by Leonardo M?rlein : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 03:24:09 2019 From: report at bugs.python.org (Inada Naoki) Date: Fri, 22 Feb 2019 08:24:09 +0000 Subject: [issue34981] Unable to install Python from web-based installer and executable installer In-Reply-To: <1539516777.52.0.788709270274.issue34981@psf.upfronthosting.co.za> Message-ID: <1550823849.07.0.618053103358.issue34981@roundup.psfhosted.org> Change by Inada Naoki : ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 03:36:14 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 22 Feb 2019 08:36:14 +0000 Subject: [issue36018] Add a Normal Distribution class to the statistics module In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org> Message-ID: <1550824574.37.0.695909778104.issue36018@roundup.psfhosted.org> Raymond Hettinger added the comment: Okay the PR is ready. If you all are mostly comfortable with it, it would great to get this in for the second alpha so that people have a chance to work with it. ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 03:44:51 2019 From: report at bugs.python.org (Christian Tismer) Date: Fri, 22 Feb 2019 08:44:51 +0000 Subject: [issue35810] Object Initialization does not incref Heap-allocated Types In-Reply-To: <1548275752.94.0.463880453345.issue35810@roundup.psfhosted.org> Message-ID: <1550825091.72.0.883480553732.issue35810@roundup.psfhosted.org> Christian Tismer added the comment: Neil, that is the absolute super-move! When all types are heap types, then I have no longer the problem that I cannot get at slots from builtin types, with all are static. I am very much for that change, because then I can make my stable ABI implementation of PySide much cleaner. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 04:14:20 2019 From: report at bugs.python.org (Kevin Mai-Hsuan Chia) Date: Fri, 22 Feb 2019 09:14:20 +0000 Subject: [issue36074] Result of `asyncio.Server.sockets` after `Server.close()` is not clear Message-ID: <1550826860.7.0.550984466305.issue36074@roundup.psfhosted.org> New submission from Kevin Mai-Hsuan Chia : It seems the result of `asyncio.Server.sockets` after `asyncio.Server.close()` is performed becomes `[]` instead of `None` since python 3.7. However, in the [document 3.7 and 3.8](https://docs.python.org/3.8/library/asyncio-eventloop.html#asyncio.Server.sockets), it states ``` List of socket.socket objects the server is listening on, or None if the server is closed. Changed in version 3.7: Prior to Python 3.7 Server.sockets used to return an internal list of server sockets directly. In 3.7 a copy of that list is returned. ``` For me, I think the comment `Changed in version 3.7: ...` only emphasizes the "copied list" is returned. IMO it will be more clear if the change from `None` to `[]` is mentioned in the comment as well. Sorry if this issue is not appropriate. Thanks! ---------- assignee: docs at python components: Documentation messages: 336287 nosy: docs at python, mhchia priority: normal severity: normal status: open title: Result of `asyncio.Server.sockets` after `Server.close()` is not clear type: enhancement versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 04:31:01 2019 From: report at bugs.python.org (Martin Panter) Date: Fri, 22 Feb 2019 09:31:01 +0000 Subject: [issue31162] urllib.request.urlopen CERTIFICATE_VERIFY_FAILED error In-Reply-To: <1502290158.78.0.927502362928.issue31162@psf.upfronthosting.co.za> Message-ID: <1550827861.12.0.398318987151.issue31162@roundup.psfhosted.org> Change by Martin Panter : ---------- resolution: -> not a bug status: open -> pending title: urllib.request.urlopen error -> urllib.request.urlopen CERTIFICATE_VERIFY_FAILED error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 04:38:39 2019 From: report at bugs.python.org (Saba Kauser) Date: Fri, 22 Feb 2019 09:38:39 +0000 Subject: [issue36075] python 2to3 conversion tool is generating file with extra line for every input line Message-ID: <1550828319.37.0.854628356141.issue36075@roundup.psfhosted.org> New submission from Saba Kauser : Hi, I am building my python ibm_db driver on python 3.7 using the setup.py under https://github.com/SabaKauser/python-ibmdb/blob/master/IBM_DB/ibm_db/setup.py with 2to3 compatibility as: python setup.py build and installing as: python setup.py install I have a python script that after installing has new empty line added for every line. e.g: my source: if database is None: raise InterfaceError("createdb expects a not None database name value") if (not isinstance(database, basestring)) | \ (not isinstance(codeset, basestring)) | \ (not isinstance(mode, basestring)): raise InterfaceError("Arguments sould be string or unicode") The generated file under C:\Users\skauser\AppData\Local\Programs\Python\Python37\Lib\site-packages\ibm_db-2.0.9-py3.7-win-amd64.egg\ibm_db_dbi.py if database is None: raise InterfaceError("createdb expects a not None database name value") if (not isinstance(database, str)) | \ (not isinstance(codeset, str)) | \ (not isinstance(mode, str)): raise InterfaceError("Arguments sould be string or unicode") As you can see, there is this new line that is throwing runtime error. File "c:\users\skauser\appdata\local\programs\python\python37\lib\site-packages\ibm_db-2.0.9-py3.7-win-amd64.egg\ibm_db_dbi.py", line 846 ^ SyntaxError: invalid syntax Could you please let me know how can I get rid of this behavior? When I install the package using pip, I don't see this behavior. Thanks! Saba. ---------- components: 2to3 (2.x to 3.x conversion tool) messages: 336288 nosy: sabakauser priority: normal severity: normal status: open title: python 2to3 conversion tool is generating file with extra line for every input line type: compile error versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 04:46:31 2019 From: report at bugs.python.org (Petr Viktorin) Date: Fri, 22 Feb 2019 09:46:31 +0000 Subject: [issue35810] Object Initialization does not incref Heap-allocated Types In-Reply-To: <1548275752.94.0.463880453345.issue35810@roundup.psfhosted.org> Message-ID: <1550828791.33.0.292449290454.issue35810@roundup.psfhosted.org> Petr Viktorin added the comment: Changing all types to heap types is definitely a gigantic task. First let's make heap types more usable and bug-free, and then it will be easier :) (I do have an agenda here: improving heap types usable is also yak-shaving* for making modules play nice with subinterpreters, like in PEPs 489 & 573) * https://en.wiktionary.org/wiki/yak_shaving ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 05:16:03 2019 From: report at bugs.python.org (Martin Panter) Date: Fri, 22 Feb 2019 10:16:03 +0000 Subject: [issue36064] docs: urllib.request.Request not accepting iterables data type In-Reply-To: <1550744621.39.0.0634252256257.issue36064@roundup.psfhosted.org> Message-ID: <1550830563.95.0.999311082121.issue36064@roundup.psfhosted.org> Martin Panter added the comment: I agree the documentation is insufficient. It should have said if ?data? is iterated, it must yield bytes-like objects. I agree it is unwise to yet more special cases for the uploaded data types. When Lye passed the dictionary of three keys and values, I suspect they weren?t expecting it to upload just the key names using one HTTP chunk for each key. See Issue 23740 about the mess of data types currently supported. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 05:21:37 2019 From: report at bugs.python.org (Vlad Shcherbina) Date: Fri, 22 Feb 2019 10:21:37 +0000 Subject: [issue35889] sqlite3.Row doesn't have useful repr In-Reply-To: <1549112536.04.0.744689521798.issue35889@roundup.psfhosted.org> Message-ID: <1550830897.09.0.724788003928.issue35889@roundup.psfhosted.org> Vlad Shcherbina added the comment: There is no need to add explicit knowledge of reprlib to the Row object or vice versa. Those who use reprlib to limit output size will have no problem. Reprlib already truncates arbitrary reprs at the string level: https://github.com/python/cpython/blob/22bfe637ca7728e9f74d4dc8bb7a15ee2a913815/Lib/reprlib.py#L144 Those who use builtin repr() have to be prepared for the possibility of unbounded repr anyway, because all collection-like objects in Python have unbounded __repr__. It would be annoying if some collection-like objects decided to be clever and omit parts of their regular __repr__ because they feel it's too much for the user to handle. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 05:50:37 2019 From: report at bugs.python.org (Maciej Grela) Date: Fri, 22 Feb 2019 10:50:37 +0000 Subject: [issue36076] ssl.get_server_certificate should use SNI Message-ID: <1550832637.63.0.810742849841.issue36076@roundup.psfhosted.org> New submission from Maciej Grela : The ssl.get_server_certificate function doesn't send SNI information causing an wrong certificate to be sent back by the server (or connection close in some cases). This can be seen when trying to use get_server_certificate against a site behind cloudflare. An example is provided below: $ python3 -V Python 3.7.2 $ python3 -c "import ssl; print(ssl.get_server_certificate(('www.mx.com',443)))" | openssl x509 -text Certificate: Data: Version: 3 (0x2) Serial Number: 89:2a:bc:df:8a:f3:d6:f6:ae:c5:18:5a:78:ec:39:6e Signature Algorithm: ecdsa-with-SHA256 Issuer: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO ECC Domain Validation Secure Server CA 2 Validity Not Before: Dec 19 00:00:00 2018 GMT Not After : Jun 27 23:59:59 2019 GMT Subject: OU=Domain Control Validated, OU=PositiveSSL Multi-Domain, CN=ssl803013.cloudflaressl.com Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:ff:c1:c3:f1:c0:8a:08:84:ad:e4:25:f6:c3:03: 1f:26:0a:b4:85:e0:65:0e:f5:8b:13:1e:21:b2:54: 94:8c:f3:ce:98:eb:cf:ff:ff:1d:3a:03:22:b1:7c: 5f:13:e5:09:1f:77:b0:e8:ac:bf:e6:6c:ea:cb:57: df:e1:c8:14:da ASN1 OID: prime256v1 NIST CURVE: P-256 X509v3 extensions: X509v3 Authority Key Identifier: keyid:40:09:61:67:F0:BC:83:71:4F:DE:12:08:2C:6F:D4:D4:2B:76:3D:96 X509v3 Subject Key Identifier: 4B:F4:77:CD:FB:04:DC:0D:B2:A5:99:B8:6F:17:CC:80:DF:AE:59:DF X509v3 Key Usage: critical Digital Signature X509v3 Basic Constraints: critical CA:FALSE X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 Certificate Policies: Policy: 1.3.6.1.4.1.6449.1.2.2.7 CPS: https://secure.comodo.com/CPS Policy: 2.23.140.1.2.1 X509v3 CRL Distribution Points: Full Name: URI:http://crl.comodoca4.com/COMODOECCDomainValidationSecureServerCA2.crl Authority Information Access: CA Issuers - URI:http://crt.comodoca4.com/COMODOECCDomainValidationSecureServerCA2.crt OCSP - URI:http://ocsp.comodoca4.com X509v3 Subject Alternative Name: DNS:ssl803013.cloudflaressl.com, DNS:*.hscoscdn00.net, DNS:hscoscdn00.net 1.3.6.1.4.1.11129.2.4.2: ......u.......q...#...{G8W. .R....d6.......g..P......F0D. ...0....J|..2I..}%.Q.P...Z....g.. ......e....j...Y^.Ti^..........].w.t~..1.3..!..%OBp...^B ..75y..{.V...g..Pv.....H0F.!..1#I..\.....#2...$...X.... ......!...].{o..ud..6OV Q.x...J_(....[!. Signature Algorithm: ecdsa-with-SHA256 30:45:02:20:0c:8c:b6:ea:68:e4:d6:d6:18:95:50:8f:77:41: 63:51:81:59:3b:1b:e6:38:47:88:f3:47:d5:b0:0b:03:c5:ba: 02:21:00:d2:19:3f:71:e2:64:36:79:d1:4c:c9:98:fd:74:d7: 32:53:f6:b4:de:09:65:d8:a0:60:85:eb:f1:1f:75:35:75 -----BEGIN CERTIFICATE----- MIIFBzCCBK2gAwIBAgIRAIkqvN+K89b2rsUYWnjsOW4wCgYIKoZIzj0EAwIwgZIx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTgwNgYDVQQD Ey9DT01PRE8gRUNDIERvbWFpbiBWYWxpZGF0aW9uIFNlY3VyZSBTZXJ2ZXIgQ0Eg MjAeFw0xODEyMTkwMDAwMDBaFw0xOTA2MjcyMzU5NTlaMGwxITAfBgNVBAsTGERv bWFpbiBDb250cm9sIFZhbGlkYXRlZDEhMB8GA1UECxMYUG9zaXRpdmVTU0wgTXVs dGktRG9tYWluMSQwIgYDVQQDExtzc2w4MDMwMTMuY2xvdWRmbGFyZXNzbC5jb20w WTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAT/wcPxwIoIhK3kJfbDAx8mCrSF4GUO 9YsTHiGyVJSM886Y68///x06AyKxfF8T5Qkfd7DorL/mbOrLV9/hyBTao4IDBzCC AwMwHwYDVR0jBBgwFoAUQAlhZ/C8g3FP3hIILG/U1Ct2PZYwHQYDVR0OBBYEFEv0 d837BNwNsqWZuG8XzIDfrlnfMA4GA1UdDwEB/wQEAwIHgDAMBgNVHRMBAf8EAjAA MB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjBPBgNVHSAESDBGMDoGCysG AQQBsjEBAgIHMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5j b20vQ1BTMAgGBmeBDAECATBWBgNVHR8ETzBNMEugSaBHhkVodHRwOi8vY3JsLmNv bW9kb2NhNC5jb20vQ09NT0RPRUNDRG9tYWluVmFsaWRhdGlvblNlY3VyZVNlcnZl ckNBMi5jcmwwgYgGCCsGAQUFBwEBBHwwejBRBggrBgEFBQcwAoZFaHR0cDovL2Ny dC5jb21vZG9jYTQuY29tL0NPTU9ET0VDQ0RvbWFpblZhbGlkYXRpb25TZWN1cmVT ZXJ2ZXJDQTIuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC5jb21vZG9jYTQu Y29tMEgGA1UdEQRBMD+CG3NzbDgwMzAxMy5jbG91ZGZsYXJlc3NsLmNvbYIQKi5o c2Nvc2NkbjAwLm5ldIIOaHNjb3NjZG4wMC5uZXQwggEEBgorBgEEAdZ5AgQCBIH1 BIHyAPAAdQC72d+8H4pxtZOUI5eqkntHOFeVCqtS6BqQlmQ2jh7RhQAAAWfEHVAd AAAEAwBGMEQCIB73izCk6hPeSnyYAjJJD959JRpRHFD2EwNa3Bzo3mcUAiASBZfK xLxlg5H302r4gOVZXrFUaV6Ylpy57rzdrvb4XQB3AHR+2oMxrTMQkSGcziVPQnDC v/1eQiAIxjc1eeYQe8xWAAABZ8QdUHYAAAQDAEgwRgIhAMMxI0kXulz+sMgA7iMy LrjbJLcZ6ViL4e71CpHc99etAiEAzKFdBXtvvJR1ZAj4Nk9WClGbeBmO7EpfKP+4 nMFbIQ4wCgYIKoZIzj0EAwIDSAAwRQIgDIy26mjk1tYYlVCPd0FjUYFZOxvmOEeI 80fVsAsDxboCIQDSGT9x4mQ2edFMyZj9dNcyU/a03gll2KBghevxH3U1dQ== -----END CERTIFICATE----- As you can see the certificate returned has CN=ssl803013.cloudflaressl.com, the proper certificate has CN=www.mx.com as you can compare with openssl output when SNI is sent: $ openssl s_client -connect www.mx.com:443 -servername www.mx.com CONNECTED(00000006) depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root verify return:1 depth=1 C = US, ST = CA, L = San Francisco, O = "CloudFlare, Inc.", CN = CloudFlare Inc ECC CA-2 verify return:1 depth=0 C = US, ST = CA, L = San Francisco, O = "CloudFlare, Inc.", CN = www.mx.com verify return:1 --- Certificate chain 0 s:/C=US/ST=CA/L=San Francisco/O=CloudFlare, Inc./CN=www.mx.com i:/C=US/ST=CA/L=San Francisco/O=CloudFlare, Inc./CN=CloudFlare Inc ECC CA-2 1 s:/C=US/ST=CA/L=San Francisco/O=CloudFlare, Inc./CN=CloudFlare Inc ECC CA-2 i:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root --- Server certificate -----BEGIN CERTIFICATE----- MIIEsTCCBFigAwIBAgIQAjcQsekTBs8hJemLjbikNDAKBggqhkjOPQQDAjBvMQsw CQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28x GTAXBgNVBAoTEENsb3VkRmxhcmUsIEluYy4xIDAeBgNVBAMTF0Nsb3VkRmxhcmUg SW5jIEVDQyBDQS0yMB4XDTE4MTAxODAwMDAwMFoXDTE5MTAxODEyMDAwMFowYjEL MAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2Nv MRkwFwYDVQQKExBDbG91ZEZsYXJlLCBJbmMuMRMwEQYDVQQDEwp3d3cubXguY29t MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEpIwExa1SMy+gfeVr5vkDU6HP75tT R/EXeti75Mp7M8+aWGjndy0frFF99sUbLd7eLU4AvcQ/55Q+IPI70czNmqOCAuEw ggLdMB8GA1UdIwQYMBaAFD50LR/PRXUEfj/Aooc+TEODURPGMB0GA1UdDgQWBBTf wVI3nkYN/6HbYZq9m7DuZqxxxzAVBgNVHREEDjAMggp3d3cubXguY29tMA4GA1Ud DwEB/wQEAwIHgDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIweQYDVR0f BHIwcDA2oDSgMoYwaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Nsb3VkRmxhcmVJ bmNFQ0NDQTIuY3JsMDagNKAyhjBodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vQ2xv dWRGbGFyZUluY0VDQ0NBMi5jcmwwTAYDVR0gBEUwQzA3BglghkgBhv1sAQEwKjAo BggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzAIBgZngQwB AgIwdgYIKwYBBQUHAQEEajBoMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wQAYIKwYBBQUHMAKGNGh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNv bS9DbG91ZEZsYXJlSW5jRUNDQ0EtMi5jcnQwDAYDVR0TAQH/BAIwADCCAQQGCisG AQQB1nkCBAIEgfUEgfIA8AB2ALvZ37wfinG1k5Qjl6qSe0c4V5UKq1LoGpCWZDaO HtGFAAABZoguW3YAAAQDAEcwRQIhANcAvb1Emol7u2k7LdfkMdUTL8DNU+HNWLZc PjNrfYBfAiBqo3ixk0WfrJ/4X1Esr/DzpasP70RqlvNnhSQpKhUTEwB2AHR+2oMx rTMQkSGcziVPQnDCv/1eQiAIxjc1eeYQe8xWAAABZoguW2oAAAQDAEcwRQIhAPKv tl3iaYpmRBBN9rmcafB3FGBAdQ8ta5y8xPWjpn1cAiAJW45I6ekD3Afp0Nri+qOO 426qMXl9lJTkI+h7seRfEjAKBggqhkjOPQQDAgNHADBEAiBJVUN9XUYl0Hy/f7yn K+ximLR+8xINlban5hHj0PeghAIgXIoKNIKAl7r3la1J1KnWAfaoGgOo86hgSGLv b2tH1ps= -----END CERTIFICATE----- subject=/C=US/ST=CA/L=San Francisco/O=CloudFlare, Inc./CN=www.mx.com issuer=/C=US/ST=CA/L=San Francisco/O=CloudFlare, Inc./CN=CloudFlare Inc ECC CA-2 --- No client certificate CA names sent Server Temp Key: ECDH, X25519, 253 bits --- SSL handshake has read 2585 bytes and written 304 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-ECDSA-CHACHA20-POLY1305 Server public key is 256 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-ECDSA-CHACHA20-POLY1305 Session-ID: 2A4A8733FAEB281F19328C80B975907C6DB0FBE37B1D4A0A31D45C21504F10B4 Session-ID-ctx: Master-Key: F2F3881060640EF36D03DBAD46EBA8C3626D0CB2BE1253376DB98668E037D8C3ED03CE468DA5C5C86FFACB1C0C0943C6 TLS session ticket lifetime hint: 64800 (seconds) TLS session ticket: The problem lies within Lib/ssl.py get_server_certificate function: def get_server_certificate(addr, ssl_version=PROTOCOL_TLS, ca_certs=None): """Retrieve the certificate from the server at the specified address, and return it as a PEM-encoded string. If 'ca_certs' is specified, validate the server cert against it. If 'ssl_version' is specified, use it in the connection attempt.""" host, port = addr if ca_certs is not None: cert_reqs = CERT_REQUIRED else: cert_reqs = CERT_NONE context = _create_stdlib_context(ssl_version, cert_reqs=cert_reqs, cafile=ca_certs) with create_connection(addr) as sock: with context.wrap_socket(sock) as sslsock: dercert = sslsock.getpeercert(True) return DER_cert_to_PEM_cert(dercert) The wrap_socket function should be called with server_hostname parameter to send the SNI information. ---------- assignee: christian.heimes components: SSL messages: 336292 nosy: christian.heimes, enki priority: normal severity: normal status: open title: ssl.get_server_certificate should use SNI type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 06:04:15 2019 From: report at bugs.python.org (Ma Lin) Date: Fri, 22 Feb 2019 11:04:15 +0000 Subject: [issue35859] Capture behavior depends on the order of an alternation In-Reply-To: <1548857774.3.0.1614070954.issue35859@roundup.psfhosted.org> Message-ID: <1550833455.6.0.447976264338.issue35859@roundup.psfhosted.org> Ma Lin added the comment: A bug harvest, see PR11756, maybe sre has more bugs. Those bug exist since Python 2. Any ideas from regular expression experts? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 06:09:55 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 22 Feb 2019 11:09:55 +0000 Subject: [issue35307] Command line help example is missing "--prompt" option In-Reply-To: <1543054310.5.0.788709270274.issue35307@psf.upfronthosting.co.za> Message-ID: <1550833795.83.0.735002931857.issue35307@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +12009 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 06:14:43 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Fri, 22 Feb 2019 11:14:43 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1550834083.65.0.827745964392.issue35813@roundup.psfhosted.org> Giampaolo Rodola' added the comment: Code looks much better now. I'm still not convinced "SharedMemory(name=None, create=False, size=0)" is the best API. How are you supposed to "create or attach" atomically? You can do that with O_EXCL but as it stands this is not togglable via the API. Also, could you address my comment about size? https://bugs.python.org/issue35813#msg335731 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 06:39:49 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Fri, 22 Feb 2019 11:39:49 +0000 Subject: [issue36018] Add a Normal Distribution class to the statistics module In-Reply-To: <1550824574.37.0.695909778104.issue36018@roundup.psfhosted.org> Message-ID: <20190222113943.GR4465@ando.pearwood.info> Steven D'Aprano added the comment: Thanks Raymond. Apologies for commenting here instead of at the PR. While I've been fighting with more intermittedly broken than usual internet access, Github has stopped supporting my browser. I can't upgrade the browser without upgrading the OS, and I can't upgrade the OS without new hardware, and that will take money I don't have at the moment. So the bottom line is that while I can read *part* of the diffs on Github, that's about all I can do. I can't comment there, I can't fork, I can't make push requests, half the pages don't load for me and the other half don't work properly when they do load. I can't even do a git clone. So right now, the only thing I can do is comment on your extensive documentation in statistics.rst. That's very nicely done. The only thing that strikes me as problematic is the default value for sigma, namely 0.0. The PDF for normal curve divides by sigma, so if that's zero, things are undefined. So I think that sigma ought to be strictly positive. I also think it would be nice to default to the standard normal curve, with mu=0.0 and sigma=1.0. That will make it easy to work with Z scores. Thanks again for this class, and my apologies for my inability to follow the preferred workflow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 06:56:02 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Fri, 22 Feb 2019 11:56:02 +0000 Subject: [issue35307] Command line help example is missing "--prompt" option In-Reply-To: <1543054310.5.0.788709270274.issue35307@psf.upfronthosting.co.za> Message-ID: <1550836562.92.0.194500699303.issue35307@roundup.psfhosted.org> Cheryl Sabella added the comment: Thank you @daftwullie for the report and for the PR! And thank you, @xtreak for triaging and for the reminder. :-) ---------- nosy: +cheryl.sabella resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 07:27:13 2019 From: report at bugs.python.org (=?utf-8?b?0JrQuNGA0LjQu9C7INCn0YPRgNC60LjQvQ==?=) Date: Fri, 22 Feb 2019 12:27:13 +0000 Subject: [issue36077] Inheritance dataclasses fields and default init statement Message-ID: <1550838433.8.0.658564691536.issue36077@roundup.psfhosted.org> New submission from ?????? ?????? : I found a problem when use inherit dataclasses. When I define parent dataclass with field(s) with default (or default_factory) properties, and inherit child dataclass from parent, i define non-default field in it and got `TypeError('non-default argument {f.name!r} follows default argument')` in dataclasses.py(466)._init_fn. It happens because dataclass constructor defines all parent class fields as arguments in __init__ class and then all child class fields. Maybe it need to define all non-default fields in init before all default. ---------- messages: 336297 nosy: ?????? ?????? priority: normal severity: normal status: open title: Inheritance dataclasses fields and default init statement type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 07:28:34 2019 From: report at bugs.python.org (SilentGhost) Date: Fri, 22 Feb 2019 12:28:34 +0000 Subject: [issue36077] Inheritance dataclasses fields and default init statement In-Reply-To: <1550838433.8.0.658564691536.issue36077@roundup.psfhosted.org> Message-ID: <1550838514.35.0.493573840183.issue36077@roundup.psfhosted.org> Change by SilentGhost : ---------- nosy: +eric.smith versions: +Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 07:30:45 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Fri, 22 Feb 2019 12:30:45 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1550838645.49.0.812892228093.issue35813@roundup.psfhosted.org> Giampaolo Rodola' added the comment: Also, there is no way to delete/unwrap memory without using an existing SharedMemory instance, which is something we may not have on startup. Perhaps we should have a "shared_memory.unlink(name)" function similar to os.unlink() which simply calls C shm_unlink(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 07:31:06 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Fri, 22 Feb 2019 12:31:06 +0000 Subject: [issue36074] Result of `asyncio.Server.sockets` after `Server.close()` is not clear In-Reply-To: <1550826860.7.0.550984466305.issue36074@roundup.psfhosted.org> Message-ID: <1550838666.03.0.291290833481.issue36074@roundup.psfhosted.org> Emmanuel Arias added the comment: Yes, that is a problem (in principle) of the docs. But I think that would be appropriate return None if is closed. ---------- nosy: +eamanu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 07:32:29 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Fri, 22 Feb 2019 12:32:29 +0000 Subject: [issue35512] patch.dict resolves in_dict eagerly (should be late resolved) In-Reply-To: <1544993007.41.0.788709270274.issue35512@psf.upfronthosting.co.za> Message-ID: <1550838749.82.0.249885366116.issue35512@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: If I understand the issue correctly it's as below is a simple reproducer where target is resolved with {'a': 1} during the construction of the decorator [0] though it's redefined later in the program as target = dict(a=2). Also here due to this since target is reassigned the decorator just stores a reference to {'a': 1} and updates it with {'b': 2} leaving the reference to dict object {'a': 2} unpatched in test_with_decorator. Meanwhile in case of the context manager (test_with_context_manager) it's created and resolved at the time it's executed hence updating the object {'a': 2} correctly. A possible fix would be to store the reference to the string path of the patch '__main__.target' and try it again with importer function. I will take a further look into this. It would be helpful if you can confirm this reproducer is good enough and resembles the original report. from unittest import mock target = dict(a=1) @mock.patch.dict('__main__.target', dict(b=2)) def test_with_decorator(): print(f"target inside decorator : {target}") def test_with_context_manager(): with mock.patch.dict('__main__.target', dict(b=2)): print(f"target inside context : {target}") target = dict(a=2) test_with_decorator() test_with_context_manager() $ python3 test_foo.py target inside decorator : {'a': 2} target inside context : {'a': 2, 'b': 2} [0] https://github.com/python/cpython/blob/3208880f1c72800bacf94a2045fcb0436702c7a1/Lib/unittest/mock.py#L1624 ---------- nosy: +xtreak type: -> behavior versions: +Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 07:46:58 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Fri, 22 Feb 2019 12:46:58 +0000 Subject: [issue36074] Result of `asyncio.Server.sockets` after `Server.close()` is not clear In-Reply-To: <1550826860.7.0.550984466305.issue36074@roundup.psfhosted.org> Message-ID: <1550839618.94.0.351854050962.issue36074@roundup.psfhosted.org> Emmanuel Arias added the comment: hmm looking in depth when the server is closed, currently return None. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 07:48:31 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Fri, 22 Feb 2019 12:48:31 +0000 Subject: [issue36074] Result of `asyncio.Server.sockets` after `Server.close()` is not clear In-Reply-To: <1550826860.7.0.550984466305.issue36074@roundup.psfhosted.org> Message-ID: <1550839711.4.0.303470462122.issue36074@roundup.psfhosted.org> Emmanuel Arias added the comment: Maybe would be great mention that the None is still return for closed server ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 07:56:57 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Fri, 22 Feb 2019 12:56:57 +0000 Subject: [issue31162] urllib.request.urlopen CERTIFICATE_VERIFY_FAILED error In-Reply-To: <1502290158.78.0.927502362928.issue31162@psf.upfronthosting.co.za> Message-ID: <1550840217.36.0.835719026624.issue31162@roundup.psfhosted.org> Emmanuel Arias added the comment: hmmm I think that is not a bug. I think that this is a certification problem, literally. ---------- nosy: +eamanu status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 07:58:01 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Fri, 22 Feb 2019 12:58:01 +0000 Subject: [issue36074] Result of `asyncio.Server.sockets` after `Server.close()` is not clear In-Reply-To: <1550826860.7.0.550984466305.issue36074@roundup.psfhosted.org> Message-ID: <1550840281.93.0.147047851121.issue36074@roundup.psfhosted.org> Change by Emmanuel Arias : ---------- keywords: +patch pull_requests: +12010 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 08:20:51 2019 From: report at bugs.python.org (Kevin Mai-Hsuan Chia) Date: Fri, 22 Feb 2019 13:20:51 +0000 Subject: [issue36074] Result of `asyncio.Server.sockets` after `Server.close()` is not clear In-Reply-To: <1550826860.7.0.550984466305.issue36074@roundup.psfhosted.org> Message-ID: <1550841651.29.0.363333958227.issue36074@roundup.psfhosted.org> Kevin Mai-Hsuan Chia added the comment: Excuse me, I tried 3.7.2 and 3.8.0a1+ with the following code and still failed. Could you help me to try this? or can you give me a pointer to the code returning `None`? Sorry for the inconvenience and thanks a lot. ``` import asyncio import platform async def close_server(): def handler(reader, writer): pass s = await asyncio.start_server(handler, host='127.0.0.1', port=34567) s.close() await s.wait_closed() assert s.sockets is None print("version: ", platform.python_version()) asyncio.get_event_loop().run_until_complete(close_server()) ``` ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 08:28:40 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Fri, 22 Feb 2019 13:28:40 +0000 Subject: [issue36074] Result of `asyncio.Server.sockets` after `Server.close()` is not clear In-Reply-To: <1550826860.7.0.550984466305.issue36074@roundup.psfhosted.org> Message-ID: <1550842120.55.0.678728102513.issue36074@roundup.psfhosted.org> Emmanuel Arias added the comment: @mhchia yes! sorry! I was testing the .close() return. yes you are right is confused. I will modified the PR. Thanks ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 08:29:39 2019 From: report at bugs.python.org (=?utf-8?q?J=C3=B6rg_Stucke?=) Date: Fri, 22 Feb 2019 13:29:39 +0000 Subject: [issue36035] pathlib.Path().rglob() breaks with broken symlinks In-Reply-To: <1550578197.02.0.381973172531.issue36035@roundup.psfhosted.org> Message-ID: <1550842179.11.0.271171242391.issue36035@roundup.psfhosted.org> Change by J?rg Stucke : ---------- pull_requests: +12011 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 08:41:10 2019 From: report at bugs.python.org (=?utf-8?q?J=C3=B6rg_Stucke?=) Date: Fri, 22 Feb 2019 13:41:10 +0000 Subject: [issue36035] pathlib.Path().rglob() breaks with broken symlinks In-Reply-To: <1550578197.02.0.381973172531.issue36035@roundup.psfhosted.org> Message-ID: <1550842870.3.0.217343637225.issue36035@roundup.psfhosted.org> J?rg Stucke added the comment: I tried to add a test file in https://github.com/python/cpython/pull/11988 To fix all now broken tests I had to add a try except block to the _WildcardSelector as well (analogous to the _RecursiveWildcardSelector). I could only check on Linux and I have no idea how it behaves on any other OS. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 08:43:17 2019 From: report at bugs.python.org (Jason R. Coombs) Date: Fri, 22 Feb 2019 13:43:17 +0000 Subject: [issue35512] patch.dict resolves in_dict eagerly (should be late resolved) In-Reply-To: <1550838749.82.0.249885366116.issue35512@roundup.psfhosted.org> Message-ID: <09A3772D-20B0-4BBE-822F-1540E4D5DF19@jaraco.com> Jason R. Coombs added the comment: I agree that?s a good reproducer. Thanks for looking into this! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 08:45:47 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 22 Feb 2019 13:45:47 +0000 Subject: [issue36019] test_urllib fail in s390x buildbots: http://www.example.com/ In-Reply-To: <1550450495.08.0.90804425705.issue36019@roundup.psfhosted.org> Message-ID: <1550843147.75.0.00482425912955.issue36019@roundup.psfhosted.org> STINNER Victor added the comment: New changeset a40681dd5db8deaf05a635eecb91498dac882aa4 by Victor Stinner (St?phane Wirtel) in branch 'master': bpo-36019: Use pythontest.net instead of example.com in network tests (GH-11941) https://github.com/python/cpython/commit/a40681dd5db8deaf05a635eecb91498dac882aa4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 08:45:49 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 22 Feb 2019 13:45:49 +0000 Subject: [issue36019] test_urllib fail in s390x buildbots: http://www.example.com/ In-Reply-To: <1550450495.08.0.90804425705.issue36019@roundup.psfhosted.org> Message-ID: <1550843149.65.0.613656478374.issue36019@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +12012 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 08:46:52 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 22 Feb 2019 13:46:52 +0000 Subject: [issue36019] test_urllib fail in s390x buildbots: http://www.example.com/ In-Reply-To: <1550450495.08.0.90804425705.issue36019@roundup.psfhosted.org> Message-ID: <1550843212.8.0.786612135838.issue36019@roundup.psfhosted.org> STINNER Victor added the comment: > New changeset a40681dd5db8deaf05a635eecb91498dac882aa4 by Victor Stinner (St?phane Wirtel) in branch 'master': > bpo-36019: Use pythontest.net instead of example.com in network tests (GH-11941) I'm not sure that this change will fix https://bugs.python.org/issue36019 but I prefer that your CI doesn't flood public servers like google.com or example.com. I prefer that we control the external resources used by our tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 08:47:44 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 22 Feb 2019 13:47:44 +0000 Subject: [issue22239] asyncio: nested event loop In-Reply-To: <1408557830.66.0.604610139339.issue22239@psf.upfronthosting.co.za> Message-ID: <1550843264.96.0.675038399894.issue22239@roundup.psfhosted.org> Change by STINNER Victor : ---------- nosy: -vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 08:47:48 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 22 Feb 2019 13:47:48 +0000 Subject: [issue33944] Deprecate and remove pth files In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za> Message-ID: <1550843268.57.0.28689437804.issue33944@roundup.psfhosted.org> Change by STINNER Victor : ---------- nosy: -vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 08:47:52 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 22 Feb 2019 13:47:52 +0000 Subject: [issue35662] Windows #define _PY_EMULATED_WIN_CV 0 bug In-Reply-To: <1546658725.61.0.827924851828.issue35662@roundup.psfhosted.org> Message-ID: <1550843272.73.0.759323064333.issue35662@roundup.psfhosted.org> Change by STINNER Victor : ---------- nosy: -vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 08:48:09 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 22 Feb 2019 13:48:09 +0000 Subject: [issue29871] Enable optimized locks on Windows In-Reply-To: <1490146396.76.0.76409234296.issue29871@psf.upfronthosting.co.za> Message-ID: <1550843289.9.0.955967218141.issue29871@roundup.psfhosted.org> Change by STINNER Victor : ---------- nosy: -vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 08:48:48 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Fri, 22 Feb 2019 13:48:48 +0000 Subject: [issue35826] Typo in example for async with statement with condition In-Reply-To: <1548413052.91.0.387178410518.issue35826@roundup.psfhosted.org> Message-ID: <1550843328.84.0.575867297424.issue35826@roundup.psfhosted.org> Emmanuel Arias added the comment: This issue could be closed, right? ---------- nosy: +eamanu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 08:53:37 2019 From: report at bugs.python.org (Kevin Mai-Hsuan Chia) Date: Fri, 22 Feb 2019 13:53:37 +0000 Subject: [issue36074] Result of `asyncio.Server.sockets` after `Server.close()` is not clear In-Reply-To: <1550826860.7.0.550984466305.issue36074@roundup.psfhosted.org> Message-ID: <1550843617.6.0.455997832417.issue36074@roundup.psfhosted.org> Kevin Mai-Hsuan Chia added the comment: Sure thing. Should it be discussed more detailed before the PR? If the document or the returned value is controversial, I would like to contribute if needed. Thanks :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 08:56:54 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Fri, 22 Feb 2019 13:56:54 +0000 Subject: [issue36074] Result of `asyncio.Server.sockets` after `Server.close()` is not clear In-Reply-To: <1550826860.7.0.550984466305.issue36074@roundup.psfhosted.org> Message-ID: <1550843814.25.0.191267078894.issue36074@roundup.psfhosted.org> Emmanuel Arias added the comment: > Sure thing. Should it be discussed more detailed before the PR? If the document or the returned value is controversial, I would like to contribute if needed. Thanks :) Please, make the comments on the PR. This way, other reviewer can see your comments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 09:03:34 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 22 Feb 2019 14:03:34 +0000 Subject: [issue36019] test_urllib fail in s390x buildbots: http://www.example.com/ In-Reply-To: <1550450495.08.0.90804425705.issue36019@roundup.psfhosted.org> Message-ID: <1550844214.81.0.0720491553249.issue36019@roundup.psfhosted.org> miss-islington added the comment: New changeset 6163210089148ad31c270695f7273fc3561a211a by Miss Islington (bot) in branch '3.7': bpo-36019: Use pythontest.net instead of example.com in network tests (GH-11941) https://github.com/python/cpython/commit/6163210089148ad31c270695f7273fc3561a211a ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 09:18:34 2019 From: report at bugs.python.org (Axel) Date: Fri, 22 Feb 2019 14:18:34 +0000 Subject: [issue36078] argparse: positional with type=int, default=SUPPRESS raise ValueError Message-ID: <1550845114.74.0.376208054151.issue36078@roundup.psfhosted.org> New submission from Axel : Example source: from argparse import ArgumentParser, SUPPRESS ============== parser = ArgumentParser() parser.add_argument('i', nargs='?', type=int, default=SUPPRESS) args = parser.parse_args([]) ============== results in: error: argument integer: invalid int value: '==SUPPRESS==' Expected: args = Namespace() In Lib/argparse.py: line 2399 in _get_value: result = type_func(arg_string) with arg_string = SUPPRESS = '==SUPPRESS==' called by ... line 1836 in take_action: argument_values = self._get_values(action, argument_strings) which is done before checking for SUPPRESS in line 1851: if argument_values is not SUPPRESS: action(...) ---------- components: Library (Lib) messages: 336314 nosy: n8falke priority: normal severity: normal status: open title: argparse: positional with type=int, default=SUPPRESS raise ValueError type: behavior versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 09:37:02 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Fri, 22 Feb 2019 14:37:02 +0000 Subject: [issue35392] Create asyncio/sockutils.py In-Reply-To: <1543864023.37.0.788709270274.issue35392@psf.upfronthosting.co.za> Message-ID: <1550846222.17.0.913237210477.issue35392@roundup.psfhosted.org> Change by Emmanuel Arias : ---------- nosy: +eamanu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 09:40:41 2019 From: report at bugs.python.org (=?utf-8?q?J=C3=B6rg_Stucke?=) Date: Fri, 22 Feb 2019 14:40:41 +0000 Subject: [issue36035] pathlib.Path().rglob() breaks with broken symlinks In-Reply-To: <1550578197.02.0.381973172531.issue36035@roundup.psfhosted.org> Message-ID: <1550846441.14.0.328522794538.issue36035@roundup.psfhosted.org> J?rg Stucke added the comment: As expected the Windows CI build failed. All test fails were caused by: OSError: [WinError 1921] The name of the file cannot be resolved by the system: 'C:\\projects\\cpython\\build\\test_python_936\\@test_936_tmp\\brokenLinkLoop' Therefore, I added WinError 1921 to _IGNORED_WINERRORS as suggested by Eryk Sun. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 09:42:18 2019 From: report at bugs.python.org (Gerrit Holl) Date: Fri, 22 Feb 2019 14:42:18 +0000 Subject: [issue36079] pdb on setuptools "ValueError: underlying buffer has been detached" Message-ID: <1550846538.64.0.183791243037.issue36079@roundup.psfhosted.org> New submission from Gerrit Holl : I am unable to use `pdb` to debug a problem I have with the `python-hdf4` installer. The exception in the program to be debugged is printed twice, followed by an exception in pdb itself, ending with `ValueError: underlying buffer has been detached`. See below, in particular the lower part: $ python -mpdb setup.py install python -mpdb setup.py install > /panfs/e/vol0/gholl/checkouts/python-hdf4/setup.py(11)() -> """ (Pdb) cont running install running bdist_egg running egg_info running build_src build_src building extension "pyhdf._hdfext" sources build_src: building npy-pkg config files writing python_hdf4.egg-info/PKG-INFO writing dependency_links to python_hdf4.egg-info/dependency_links.txt writing top-level names to python_hdf4.egg-info/top_level.txt reading manifest file 'python_hdf4.egg-info/SOURCES.txt' writing manifest file 'python_hdf4.egg-info/SOURCES.txt' installing library code to build/bdist.linux-x86_64/egg running install_lib running build_py running build_ext customize UnixCCompiler customize UnixCCompiler using build_ext building 'pyhdf._hdfext' extension compiling C sources C compiler: gcc -pthread -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-I/panfs/e/vol0/gholl/venv/py36/lib/python3.6/site-packages/numpy/core/include -I/panfs/e/vol0/gholl/venv/py36/include -I/hpc/rhome/software/python/3.6.5/include/python3.6m -c' extra options: '-DNOSZIP' Traceback (most recent call last): File "/hpc/rhome/software/python/3.6.5/lib/python3.6/pdb.py", line 1667, in main pdb._runscript(mainpyfile) File "/hpc/rhome/software/python/3.6.5/lib/python3.6/pdb.py", line 1548, in _runscript self.run(statement) File "/hpc/rhome/software/python/3.6.5/lib/python3.6/bdb.py", line 434, in run exec(cmd, globals, locals) File "", line 1, in File "/panfs/e/vol0/gholl/checkouts/python-hdf4/setup.py", line 11, in """ File "/panfs/e/vol0/gholl/venv/py36/lib/python3.6/site-packages/numpy/distutils/core.py", line 171, in setup return old_setup(**new_attr) File "/panfs/e/vol0/gholl/venv/py36/lib/python3.6/site-packages/setuptools/__init__.py", line 129, in setup return distutils.core.setup(**attrs) File "/hpc/rhome/software/python/3.6.5/lib/python3.6/distutils/core.py", line 148, in setup dist.run_commands() File "/hpc/rhome/software/python/3.6.5/lib/python3.6/distutils/dist.py", line 955, in run_commands self.run_command(cmd) File "/hpc/rhome/software/python/3.6.5/lib/python3.6/distutils/dist.py", line 974, in run_command cmd_obj.run() File "/panfs/e/vol0/gholl/venv/py36/lib/python3.6/site-packages/numpy/distutils/command/install.py", line 62, in run r = self.setuptools_run() File "/panfs/e/vol0/gholl/venv/py36/lib/python3.6/site-packages/numpy/distutils/command/install.py", line 56, in setuptools_run self.do_egg_install() File "/panfs/e/vol0/gholl/venv/py36/lib/python3.6/site-packages/setuptools/command/install.py", line 109, in do_egg_install self.run_command('bdist_egg') File "/hpc/rhome/software/python/3.6.5/lib/python3.6/distutils/cmd.py", line 313, in run_command self.distribution.run_command(command) File "/hpc/rhome/software/python/3.6.5/lib/python3.6/distutils/dist.py", line 974, in run_command cmd_obj.run() File "/panfs/e/vol0/gholl/venv/py36/lib/python3.6/site-packages/setuptools/command/bdist_egg.py", line 172, in run cmd = self.call_command('install_lib', warn_dir=0) File "/panfs/e/vol0/gholl/venv/py36/lib/python3.6/site-packages/setuptools/command/bdist_egg.py", line 158, in call_command self.run_command(cmdname) File "/hpc/rhome/software/python/3.6.5/lib/python3.6/distutils/cmd.py", line 313, in run_command self.distribution.run_command(command) File "/hpc/rhome/software/python/3.6.5/lib/python3.6/distutils/dist.py", line 974, in run_command cmd_obj.run() File "/panfs/e/vol0/gholl/venv/py36/lib/python3.6/site-packages/setuptools/command/install_lib.py", line 11, in run self.build() File "/hpc/rhome/software/python/3.6.5/lib/python3.6/distutils/command/install_lib.py", line 107, in build self.run_command('build_ext') File "/hpc/rhome/software/python/3.6.5/lib/python3.6/distutils/cmd.py", line 313, in run_command self.distribution.run_command(command) File "/hpc/rhome/software/python/3.6.5/lib/python3.6/distutils/dist.py", line 974, in run_command cmd_obj.run() File "/panfs/e/vol0/gholl/venv/py36/lib/python3.6/site-packages/numpy/distutils/command/build_ext.py", line 261, in run self.build_extensions() File "/hpc/rhome/software/python/3.6.5/lib/python3.6/distutils/command/build_ext.py", line 448, in build_extensions self._build_extensions_serial() File "/hpc/rhome/software/python/3.6.5/lib/python3.6/distutils/command/build_ext.py", line 473, in _build_extensions_serial self.build_extension(ext) File "/panfs/e/vol0/gholl/venv/py36/lib/python3.6/site-packages/numpy/distutils/command/build_ext.py", line 379, in build_extension **kws) File "/panfs/e/vol0/gholl/venv/py36/lib/python3.6/site-packages/numpy/distutils/ccompiler.py", line 92, in m = lambda self, *args, **kw: func(self, *args, **kw) File "/panfs/e/vol0/gholl/venv/py36/lib/python3.6/site-packages/numpy/distutils/ccompiler.py", line 363, in CCompiler_compile single_compile(o) File "/panfs/e/vol0/gholl/venv/py36/lib/python3.6/site-packages/numpy/distutils/ccompiler.py", line 305, in single_compile if not _needs_build(obj, cc_args, extra_postargs, pp_opts): File "/panfs/e/vol0/gholl/venv/py36/lib/python3.6/site-packages/numpy/distutils/ccompiler.py", line 64, in _needs_build last_cmdline = lines[-1] IndexError: list index out of range Uncaught exception. Entering post mortem debugging Running 'cont' or 'step' will restart the program Traceback (most recent call last): File "/hpc/rhome/software/python/3.6.5/lib/python3.6/pdb.py", line 1667, in main pdb._runscript(mainpyfile) File "/hpc/rhome/software/python/3.6.5/lib/python3.6/pdb.py", line 1548, in _runscript self.run(statement) File "/hpc/rhome/software/python/3.6.5/lib/python3.6/bdb.py", line 434, in run exec(cmd, globals, locals) File "", line 1, in File "/panfs/e/vol0/gholl/checkouts/python-hdf4/setup.py", line 11, in """ File "/panfs/e/vol0/gholl/venv/py36/lib/python3.6/site-packages/numpy/distutils/core.py", line 171, in setup return old_setup(**new_attr) File "/panfs/e/vol0/gholl/venv/py36/lib/python3.6/site-packages/setuptools/__init__.py", line 129, in setup return distutils.core.setup(**attrs) File "/hpc/rhome/software/python/3.6.5/lib/python3.6/distutils/core.py", line 148, in setup dist.run_commands() File "/hpc/rhome/software/python/3.6.5/lib/python3.6/distutils/dist.py", line 955, in run_commands self.run_command(cmd) File "/hpc/rhome/software/python/3.6.5/lib/python3.6/distutils/dist.py", line 974, in run_command cmd_obj.run() File "/panfs/e/vol0/gholl/venv/py36/lib/python3.6/site-packages/numpy/distutils/command/install.py", line 62, in run r = self.setuptools_run() File "/panfs/e/vol0/gholl/venv/py36/lib/python3.6/site-packages/numpy/distutils/command/install.py", line 56, in setuptools_run self.do_egg_install() File "/panfs/e/vol0/gholl/venv/py36/lib/python3.6/site-packages/setuptools/command/install.py", line 109, in do_egg_install self.run_command('bdist_egg') File "/hpc/rhome/software/python/3.6.5/lib/python3.6/distutils/cmd.py", line 313, in run_command self.distribution.run_command(command) File "/hpc/rhome/software/python/3.6.5/lib/python3.6/distutils/dist.py", line 974, in run_command cmd_obj.run() File "/panfs/e/vol0/gholl/venv/py36/lib/python3.6/site-packages/setuptools/command/bdist_egg.py", line 172, in run cmd = self.call_command('install_lib', warn_dir=0) File "/panfs/e/vol0/gholl/venv/py36/lib/python3.6/site-packages/setuptools/command/bdist_egg.py", line 158, in call_command self.run_command(cmdname) File "/hpc/rhome/software/python/3.6.5/lib/python3.6/distutils/cmd.py", line 313, in run_command self.distribution.run_command(command) File "/hpc/rhome/software/python/3.6.5/lib/python3.6/distutils/dist.py", line 974, in run_command cmd_obj.run() File "/panfs/e/vol0/gholl/venv/py36/lib/python3.6/site-packages/setuptools/command/install_lib.py", line 11, in run self.build() File "/hpc/rhome/software/python/3.6.5/lib/python3.6/distutils/command/install_lib.py", line 107, in build self.run_command('build_ext') File "/hpc/rhome/software/python/3.6.5/lib/python3.6/distutils/cmd.py", line 313, in run_command self.distribution.run_command(command) File "/hpc/rhome/software/python/3.6.5/lib/python3.6/distutils/dist.py", line 974, in run_command cmd_obj.run() File "/panfs/e/vol0/gholl/venv/py36/lib/python3.6/site-packages/numpy/distutils/command/build_ext.py", line 261, in run self.build_extensions() File "/hpc/rhome/software/python/3.6.5/lib/python3.6/distutils/command/build_ext.py", line 448, in build_extensions self._build_extensions_serial() File "/hpc/rhome/software/python/3.6.5/lib/python3.6/distutils/command/build_ext.py", line 473, in _build_extensions_serial self.build_extension(ext) File "/panfs/e/vol0/gholl/venv/py36/lib/python3.6/site-packages/numpy/distutils/command/build_ext.py", line 379, in build_extension **kws) File "/panfs/e/vol0/gholl/venv/py36/lib/python3.6/site-packages/numpy/distutils/ccompiler.py", line 92, in m = lambda self, *args, **kw: func(self, *args, **kw) File "/panfs/e/vol0/gholl/venv/py36/lib/python3.6/site-packages/numpy/distutils/ccompiler.py", line 363, in CCompiler_compile single_compile(o) File "/panfs/e/vol0/gholl/venv/py36/lib/python3.6/site-packages/numpy/distutils/ccompiler.py", line 305, in single_compile if not _needs_build(obj, cc_args, extra_postargs, pp_opts): File "/panfs/e/vol0/gholl/venv/py36/lib/python3.6/site-packages/numpy/distutils/ccompiler.py", line 64, in _needs_build last_cmdline = lines[-1] IndexError: list index out of range During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/hpc/rhome/software/python/3.6.5/lib/python3.6/runpy.py", line 193, in _run_module_as_main "__main__", mod_spec) File "/hpc/rhome/software/python/3.6.5/lib/python3.6/runpy.py", line 85, in _run_code exec(code, run_globals) File "/hpc/rhome/software/python/3.6.5/lib/python3.6/pdb.py", line 1694, in pdb.main() File "/hpc/rhome/software/python/3.6.5/lib/python3.6/pdb.py", line 1686, in main pdb.interaction(None, t) File "/hpc/rhome/software/python/3.6.5/lib/python3.6/pdb.py", line 351, in interaction self.print_stack_entry(self.stack[self.curindex]) File "/hpc/rhome/software/python/3.6.5/lib/python3.6/pdb.py", line 1453, in print_stack_entry self.format_stack_entry(frame_lineno, prompt_prefix)) File "/hpc/rhome/software/python/3.6.5/lib/python3.6/pdb.py", line 453, in message print(msg, file=self.stdout) ValueError: underlying buffer has been detached ---------- messages: 336316 nosy: Gerrit.Holl priority: normal severity: normal status: open title: pdb on setuptools "ValueError: underlying buffer has been detached" versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 09:43:45 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Fri, 22 Feb 2019 14:43:45 +0000 Subject: [issue36077] Inheritance dataclasses fields and default init statement In-Reply-To: <1550838433.8.0.658564691536.issue36077@roundup.psfhosted.org> Message-ID: <1550846625.52.0.732161281814.issue36077@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Can you please add a simple reproducer to understand the issue in little more detail? I could see some tests along with different cases producing the error message at https://github.com/python/cpython/blob/a40681dd5db8deaf05a635eecb91498dac882aa4/Lib/test/test_dataclasses.py#L55 and a simple script would be helpful in understanding the behavior of the report. ---------- components: +Library (Lib) nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 09:44:25 2019 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 22 Feb 2019 14:44:25 +0000 Subject: [issue36077] Inheritance dataclasses fields and default init statement In-Reply-To: <1550838433.8.0.658564691536.issue36077@roundup.psfhosted.org> Message-ID: <1550846665.51.0.0919670492907.issue36077@roundup.psfhosted.org> Change by Eric V. Smith : ---------- assignee: -> eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 09:44:26 2019 From: report at bugs.python.org (Kevin Mai-Hsuan Chia) Date: Fri, 22 Feb 2019 14:44:26 +0000 Subject: [issue35826] Typo in example for async with statement with condition In-Reply-To: <1548413052.91.0.387178410518.issue35826@roundup.psfhosted.org> Message-ID: <1550846666.23.0.326070650013.issue35826@roundup.psfhosted.org> Kevin Mai-Hsuan Chia added the comment: Cool! Thanks for the reminder. ---------- stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 09:46:20 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Fri, 22 Feb 2019 14:46:20 +0000 Subject: [issue36078] argparse: positional with type=int, default=SUPPRESS raise ValueError In-Reply-To: <1550845114.74.0.376208054151.issue36078@roundup.psfhosted.org> Message-ID: <1550846780.31.0.852795012909.issue36078@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 09:57:28 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 22 Feb 2019 14:57:28 +0000 Subject: [issue36018] Add a Normal Distribution class to the statistics module In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org> Message-ID: <1550847448.41.0.961230390652.issue36018@roundup.psfhosted.org> Raymond Hettinger added the comment: I've made both suggested changes, "examples"->"samples" and set the defaults to the standard normal distribution. To bypass Github, I've attached a diff to this tracker issue. Let me know what you think :-) ---------- Added file: https://bugs.python.org/file48161/normdist_22feb2019.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 10:03:54 2019 From: report at bugs.python.org (Axel) Date: Fri, 22 Feb 2019 15:03:54 +0000 Subject: [issue36078] argparse: positional with type=int, default=SUPPRESS raise ValueError In-Reply-To: <1550845114.74.0.376208054151.issue36078@roundup.psfhosted.org> Message-ID: <1550847834.23.0.972303586211.issue36078@roundup.psfhosted.org> Axel added the comment: Some more details: The problem is not the order of assignment in take_action: Defaults have been set by: def parse_known_args(self, args=None, namespace=None): ... # add any action defaults that aren't present for action in self._actions: if action.dest is not SUPPRESS: if not hasattr(namespace, action.dest): if action.default is not SUPPRESS: setattr(namespace, action.dest, action.default) Assignment without argument should not happen, like the example shows: ============== from argparse import ArgumentParser parser = ArgumentParser() parser.add_argument('i', action="count", default=42) args = parser.parse_args([]) print(repr(args)) ============== Namespace(i=43) ============== ---------- nosy: -paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 10:09:51 2019 From: report at bugs.python.org (Julien Palard) Date: Fri, 22 Feb 2019 15:09:51 +0000 Subject: [issue36074] Result of `asyncio.Server.sockets` after `Server.close()` is not clear In-Reply-To: <1550826860.7.0.550984466305.issue36074@roundup.psfhosted.org> Message-ID: <1550848191.18.0.867642539515.issue36074@roundup.psfhosted.org> Julien Palard added the comment: Behavior changed in commit c9070d03f5169ad6e171e641b7fa8feab18bf229 (Jan 2018) but has been documented as returning None since 8ebeb03740dad4d9edd65de88f82840a05070941 (Jul 2014). ---------- nosy: +mdk, vstinner, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 10:12:57 2019 From: report at bugs.python.org (Axel) Date: Fri, 22 Feb 2019 15:12:57 +0000 Subject: [issue36078] argparse: positional with type=int, default=SUPPRESS raise ValueError In-Reply-To: <1550845114.74.0.376208054151.issue36078@roundup.psfhosted.org> Message-ID: <1550848377.34.0.725386137057.issue36078@roundup.psfhosted.org> Change by Axel : ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 10:19:41 2019 From: report at bugs.python.org (Sammy Gillespie) Date: Fri, 22 Feb 2019 15:19:41 +0000 Subject: [issue36080] Ensurepip fails to install pip into a nested virtual environment (on Windows) Message-ID: <1550848781.33.0.584948420455.issue36080@roundup.psfhosted.org> New submission from Sammy Gillespie : Running Windows 10 Enterprise. Create a virtual environment: > python -m venv .venv Activate that virtual environment and attempt to create another virtual environment using the same command. This new environment will not contain pip (or anything other than just Python). Investigating this further. Running: > python -Im ensurepip --upgrade --default-pip from within the second virtual environment results in: > Requirement already up-to-date: pip in ---------- I want to create a python tool that will build a virtual env, but this restricts me from being able to install that tool into a virtual env (e.g. using pipx). ---------- messages: 336322 nosy: Sammy Gillespie priority: normal severity: normal status: open title: Ensurepip fails to install pip into a nested virtual environment (on Windows) type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 10:22:31 2019 From: report at bugs.python.org (Julien Palard) Date: Fri, 22 Feb 2019 15:22:31 +0000 Subject: [issue36064] docs: urllib.request.Request not accepting iterables data type In-Reply-To: <1550744621.39.0.0634252256257.issue36064@roundup.psfhosted.org> Message-ID: <1550848951.22.0.0853663110816.issue36064@roundup.psfhosted.org> Change by Julien Palard : ---------- pull_requests: +12013 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 10:35:41 2019 From: report at bugs.python.org (Sammy Gillespie) Date: Fri, 22 Feb 2019 15:35:41 +0000 Subject: [issue36080] Ensurepip fails to install pip into a nested virtual environment (on Windows) In-Reply-To: <1550848781.33.0.584948420455.issue36080@roundup.psfhosted.org> Message-ID: <1550849741.56.0.799192396522.issue36080@roundup.psfhosted.org> Sammy Gillespie added the comment: To expand on this. Using: > python -m pip in the second virtual environment (which does not have pip) gives the following usage example: > Usage: > C:\venv_test\\Scripts\python.exe -m pip [options] Yet the python running this command is not in venv_1, it is in venv_2. So the issue appears to lie with how pip determines its python location. So this issue may be more suited there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 10:38:34 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Fri, 22 Feb 2019 15:38:34 +0000 Subject: [issue36080] Ensurepip fails to install pip into a nested virtual environment (on Windows) In-Reply-To: <1550848781.33.0.584948420455.issue36080@roundup.psfhosted.org> Message-ID: <1550849914.98.0.789200151941.issue36080@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Is this similar to issue35872? Can you please specify the full version of Python as in 3.7.0 or later? ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, xtreak, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 10:40:23 2019 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 Feb 2019 15:40:23 +0000 Subject: [issue28453] SSLObject.selected_alpn_protocol() not documented In-Reply-To: <1476589791.51.0.926571047111.issue28453@psf.upfronthosting.co.za> Message-ID: <1550850023.7.0.637604583324.issue28453@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch pull_requests: +12014 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 10:42:12 2019 From: report at bugs.python.org (Sammy Gillespie) Date: Fri, 22 Feb 2019 15:42:12 +0000 Subject: [issue36080] Ensurepip fails to install pip into a nested virtual environment (on Windows) In-Reply-To: <1550848781.33.0.584948420455.issue36080@roundup.psfhosted.org> Message-ID: <1550850132.35.0.845441144071.issue36080@roundup.psfhosted.org> Sammy Gillespie added the comment: This is identical to https://bugs.python.org/issue35872 I am running 3.7.2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 10:50:20 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 22 Feb 2019 15:50:20 +0000 Subject: [issue36074] Result of `asyncio.Server.sockets` after `Server.close()` is not clear In-Reply-To: <1550826860.7.0.550984466305.issue36074@roundup.psfhosted.org> Message-ID: <1550850620.73.0.138503278992.issue36074@roundup.psfhosted.org> Change by STINNER Victor : ---------- nosy: -vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 10:53:17 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 22 Feb 2019 15:53:17 +0000 Subject: [issue36018] Add a Normal Distribution class to the statistics module In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org> Message-ID: <1550850797.36.0.16680821717.issue36018@roundup.psfhosted.org> Change by Raymond Hettinger : Removed file: https://bugs.python.org/file48161/normdist_22feb2019.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 10:54:10 2019 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 22 Feb 2019 15:54:10 +0000 Subject: [issue22239] asyncio: nested event loop In-Reply-To: <1408557830.66.0.604610139339.issue22239@psf.upfronthosting.co.za> Message-ID: <1550850850.29.0.0368564576456.issue22239@roundup.psfhosted.org> Change by Guido van Rossum : ---------- nosy: -gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 10:54:15 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 22 Feb 2019 15:54:15 +0000 Subject: [issue36018] Add a Normal Distribution class to the statistics module In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org> Message-ID: <1550850855.55.0.769649311512.issue36018@roundup.psfhosted.org> Change by Raymond Hettinger : Added file: https://bugs.python.org/file48162/normdist_22feb2019.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 11:05:17 2019 From: report at bugs.python.org (Rolf Eike Beer) Date: Fri, 22 Feb 2019 16:05:17 +0000 Subject: [issue36081] Cannot set LDFLAGS containing $ Message-ID: <1550851517.09.0.227487072045.issue36081@roundup.psfhosted.org> New submission from Rolf Eike Beer : My use case is: LDFLAGS=-Wl,-rpath,'$ORIGIN/../lib' This works fine for everything build directly by the Makefile, but for everything that is build through the python distutils this breaks. This is not an issue of the python side, it happens because the Makefile passes the information to python using LDSHARED='$(BLDSHARED)'. At this point the variable is expanded and the $ORIGIN is expanded by the shell (or so) before passing it to python, so python actually received "-Wl,-rpath,/../lib" from the environment variable. I have worked around locally by doing something like $(subst $$,~dollar~,$(BLDSHARED)) and replacing that inside python with \\$ or so. Really hacky, but works for my current setup. ---------- components: Build messages: 336326 nosy: Dakon priority: normal severity: normal status: open title: Cannot set LDFLAGS containing $ type: compile error versions: Python 2.7, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 11:14:52 2019 From: report at bugs.python.org (Kevin Mai-Hsuan Chia) Date: Fri, 22 Feb 2019 16:14:52 +0000 Subject: [issue36074] Result of `asyncio.Server.sockets` after `Server.close()` is not clear In-Reply-To: <1550826860.7.0.550984466305.issue36074@roundup.psfhosted.org> Message-ID: <1550852092.84.0.899060215945.issue36074@roundup.psfhosted.org> Kevin Mai-Hsuan Chia added the comment: @mdk That's interesting. May I ask which one is the preferred behavior, `None` or `[]`? IMO both make sense, but `None` is more consistent with the behavior in previous versions. If it is the case, may I work on fixing this(`None` to `[]`) as a practice to contribute? Otherwise, the PR from @eamanu should be enough to fix the document. Thanks a lot for the review and the pointer! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 11:25:32 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Fri, 22 Feb 2019 16:25:32 +0000 Subject: [issue36074] Result of `asyncio.Server.sockets` after `Server.close()` is not clear In-Reply-To: <1550826860.7.0.550984466305.issue36074@roundup.psfhosted.org> Message-ID: <1550852732.6.0.0908358725026.issue36074@roundup.psfhosted.org> Emmanuel Arias added the comment: > @mdk That's interesting. May I ask which one is the preferred behavior, `None` or `[]`? IMO changing the returned of the sockets could represent a big change, and I think that this need to be discuss ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 11:37:49 2019 From: report at bugs.python.org (Sammy Gillespie) Date: Fri, 22 Feb 2019 16:37:49 +0000 Subject: [issue36080] Ensurepip fails to install pip into a nested virtual environment (on Windows) In-Reply-To: <1550848781.33.0.584948420455.issue36080@roundup.psfhosted.org> Message-ID: <1550853469.38.0.730228372811.issue36080@roundup.psfhosted.org> Change by Sammy Gillespie : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 11:42:11 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 22 Feb 2019 16:42:11 +0000 Subject: [issue36018] Add a Normal Distribution class to the statistics module In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org> Message-ID: <1550853731.23.0.858124045702.issue36018@roundup.psfhosted.org> Change by Raymond Hettinger : Removed file: https://bugs.python.org/file48162/normdist_22feb2019.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 11:42:26 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 22 Feb 2019 16:42:26 +0000 Subject: [issue36018] Add a Normal Distribution class to the statistics module In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org> Message-ID: <1550853746.72.0.154326445816.issue36018@roundup.psfhosted.org> Change by Raymond Hettinger : Added file: https://bugs.python.org/file48163/normdist_22feb2019.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 12:02:23 2019 From: report at bugs.python.org (Juho Pesonen) Date: Fri, 22 Feb 2019 17:02:23 +0000 Subject: [issue36082] The built-in round() function giving a wrong output Message-ID: <1550854943.4.0.447015578446.issue36082@roundup.psfhosted.org> New submission from Juho Pesonen : As the title says I have got some wrong outputs with the round() built-in function. The bug occurs only with certain numbers though. (I've had problems only with the number 2.5, but I assume that there is more than one number that gives wrong output.) Here are some outputs with the round built-in function: >>>round(2.5) 2 >>>round(2.51) 3 >>>round(3.5) 4 >>>round(1.5) 2 As you can see the number 2.5 gives 2 instead of 3. ---------- messages: 336329 nosy: Goodester priority: normal severity: normal status: open title: The built-in round() function giving a wrong output type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 12:07:34 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Fri, 22 Feb 2019 17:07:34 +0000 Subject: [issue36082] The built-in round() function giving a wrong output In-Reply-To: <1550854943.4.0.447015578446.issue36082@roundup.psfhosted.org> Message-ID: <1550855254.17.0.461205452177.issue36082@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: https://docs.python.org/3/whatsnew/3.0.html > The round() function rounding strategy and return type have changed. Exact halfway cases are now rounded to the nearest even result instead of away from zero. (For example, round(2.5) now returns 2 rather than 3.) round(x[, n]) now delegates to x.__round__([n]) instead of always returning a float. It generally returns an integer when called with a single argument and a value of the same type as x when called with two arguments. ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 12:08:55 2019 From: report at bugs.python.org (SilentGhost) Date: Fri, 22 Feb 2019 17:08:55 +0000 Subject: [issue36082] The built-in round() function giving a wrong output In-Reply-To: <1550854943.4.0.447015578446.issue36082@roundup.psfhosted.org> Message-ID: <1550855335.91.0.61414058468.issue36082@roundup.psfhosted.org> SilentGhost added the comment: This is the documented behaviour. It might seem counter-intuitive, but it's is not likely to change. ---------- nosy: +SilentGhost resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 12:19:09 2019 From: report at bugs.python.org (Francis MB) Date: Fri, 22 Feb 2019 17:19:09 +0000 Subject: [issue35892] Fix awkwardness of statistics.mode() for multimodal datasets In-Reply-To: <1550604928.05.0.658249570744.issue35892@roundup.psfhosted.org> Message-ID: <80fd9406-5660-2c0e-d01b-a771cd93bc42@email.de> Francis MB added the comment: Good options itemization! >> This would give us a clean, fast API with no flags: >> mode(Iterable) -> scalar >> multimode(Iterable) -> list [...] >> For any of those options, we should still add a separate multimode() >> function. [..] >> * Add a Deprecation warning to the current behavior of mode() when it >> finds multimodal data. Then change the behavior in Python 3.9. This >> is uncomfortable for one release, but does get us to the cleanest API >> and best performance. LGTM upto 3.9, shouldn't be "mode" at some point be replaced by "multimode" ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 12:24:47 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Fri, 22 Feb 2019 17:24:47 +0000 Subject: [issue36082] The built-in round() function giving a wrong output In-Reply-To: <1550854943.4.0.447015578446.issue36082@roundup.psfhosted.org> Message-ID: <1550856287.38.0.774479773973.issue36082@roundup.psfhosted.org> R?mi Lapeyre added the comment: This is called banker rounding and is done on purpose to limit the accumulation of errors when summing a list of rounded integers. You can read https://en.m.wikipedia.org/wiki/Rounding#Round_half_to_even and look at IEEE 754 for more information. ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 12:27:35 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 22 Feb 2019 17:27:35 +0000 Subject: [issue35943] PyImport_GetModule() can return partially-initialized module In-Reply-To: <1549646017.22.0.395154635441.issue35943@roundup.psfhosted.org> Message-ID: <1550856455.6.0.640214161004.issue35943@roundup.psfhosted.org> Change by Antoine Pitrou : ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 12:34:43 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 22 Feb 2019 17:34:43 +0000 Subject: [issue36074] Result of `asyncio.Server.sockets` after `Server.close()` is not clear In-Reply-To: <1550826860.7.0.550984466305.issue36074@roundup.psfhosted.org> Message-ID: <1550856883.71.0.895716712489.issue36074@roundup.psfhosted.org> miss-islington added the comment: New changeset df5cdc11123a35065bbf1636251447d0bfe789a5 by Miss Islington (bot) (Emmanuel Arias) in branch 'master': bpo-36074: Result of `asyncio.Server.sockets` after `Server.close()` after is not clear (GH-11987) https://github.com/python/cpython/commit/df5cdc11123a35065bbf1636251447d0bfe789a5 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 12:36:02 2019 From: report at bugs.python.org (Julien Palard) Date: Fri, 22 Feb 2019 17:36:02 +0000 Subject: [issue36074] Result of `asyncio.Server.sockets` after `Server.close()` is not clear In-Reply-To: <1550826860.7.0.550984466305.issue36074@roundup.psfhosted.org> Message-ID: <1550856962.88.0.576220694984.issue36074@roundup.psfhosted.org> Julien Palard added the comment: Thanks Emmanuel for the PR (yes those PRs do not need NEWS). Thanks Kevin for the proposition to try fixing it the other way around, that's appreciated, don't hesitate to filter on easy issues there's some others :) ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 12:39:46 2019 From: report at bugs.python.org (Davin Potts) Date: Fri, 22 Feb 2019 17:39:46 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1550857186.79.0.501359869762.issue35813@roundup.psfhosted.org> Davin Potts added the comment: > Code looks much better now. I'm still not convinced > "SharedMemory(name=None, create=False, size=0)" is the best API. > How are you supposed to "create or attach" atomically? We are consciously choosing to not support an atomic "create or attach". This significantly simplifies the API and avoids the valid concerns raised around user confusion relating to that behavior (including the use of different specified 'size' values in a race) but does not preclude our potentially introducing this as a feature in the future. This simpler API still supports a "try: create; except: attach" which is not atomic but effectively covers the primary use cases for "create or attach". Combined with a SyncManager.Lock, users can already achieve an atomic "create or attach" using this simpler API. > Also, could you address my comment about size? > https://bugs.python.org/issue35813#msg335731 >> Let me rephrase: are we forced to specify a value (aka call >> ftruncate()) on create ? If we are as I think, could size have a >> reasonable default value instead of 0? Basically I'm wondering if we >> can relieve the common user from thinking about what size to use, >> mostly because it's sort of a low level detail. Could it perhaps >> default to mmap.PAGESIZE? Apologies for not responding to your question already, Giampaolo. For the same reasons that (in C) malloc does not provide a default size, I do not think we should attempt to provide a default here. Not all platforms allocate shared memory blocks in chunks of mmap.PAGESIZE, thus on some platforms we would unnecessarily over-allocate no matter what default size we might choose. I do not think we should expect users to know what mmap.PAGESIZE is on their system. I think it is important that if a user requests a new allocation of memory, that they first consider how much memory will be needed. When attaching to an existing shared memory block, its size is already defined. I think this even fits with CPython's over-allocation strategies behind things like list, where an empty list triggers no malloc at all. We will not allocate memory until the user tells us how much to allocate. > Also, there is no way to delete/unwrap memory without using an > existing SharedMemory instance, which is something we may not have > on startup. Perhaps we should have a "shared_memory.unlink(name)" > function similar to os.unlink() which simply calls C shm_unlink(). It is not really possible to offer this on non-POSIX platforms so I think we should not attempt to offer a public "shared_memory.unlink(name)". It is possible to invoke "shm_unlink" with the name of a shared memory block (for those who really need it) on platforms with POSIX Shared Memory support via: shared_memory._posixshmem.shm_unlink('name') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 12:40:34 2019 From: report at bugs.python.org (=?utf-8?b?aGVydsOp?=) Date: Fri, 22 Feb 2019 17:40:34 +0000 Subject: [issue33927] Allow json.tool to have identical infile and outfile In-Reply-To: <1529577940.46.0.56676864532.issue33927@psf.upfronthosting.co.za> Message-ID: <1550857234.9.0.48684448954.issue33927@roundup.psfhosted.org> Change by herv? : ---------- pull_requests: +12015 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 12:44:09 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Fri, 22 Feb 2019 17:44:09 +0000 Subject: [issue36018] Add a Normal Distribution class to the statistics module In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org> Message-ID: <1550857449.83.0.801478998784.issue36018@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: @steven.daprano Bit off topic but you can also append .patch in the PR URL to generate patch file with all the commits made in the PR up to latest commit and .diff provides the current diff against master. They are plain text and can be downloaded through wget and viewed with an editor in case if it helps. https://github.com/python/cpython/pull/11973.patch https://github.com/python/cpython/pull/11973.diff ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 12:48:56 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 22 Feb 2019 17:48:56 +0000 Subject: [issue35892] Fix awkwardness of statistics.mode() for multimodal datasets In-Reply-To: <1549219885.57.0.86866159357.issue35892@roundup.psfhosted.org> Message-ID: <1550857736.48.0.737242231468.issue35892@roundup.psfhosted.org> Raymond Hettinger added the comment: > shouldn't be "mode" at some point be replaced by "multimode" ? No. The signature is completely incompatible with the existing mode() function. Like MS Excel which has two functions, MODE.SGNL and MODE.MULT, we should also have two functions, each with a clean signature and with running speed that is optimal for the desired result: mode(data: Iterable) -> object Returns a single value If multiple modes found, return first encountered Raises StatisticsError for an empty input Fast O(n), single pass, doesn't keep all data in memory multimode(data: Iterable) -> List[object] Always returns a list If multiple modes found, all are returned Returns an empty list for an empty input Slow O(n log n), loads all data in memory, full sort For the first one, I recommend skipping deprecation and just changing the behavior that usually raises an exception for multiple modes. In its current form, it likely to create bugs due to uncaught exceptions, and it doesn't provide any work-around if you do want only one of the modes. By analogy, consider what would happen if we had a max() function that raised an exception when there were duplicate maximum values. It would be almost usable. So, what the real max() actually does is return the first encountered maximum value: >>> max(3, 1, 3.0) 3 >>> max(3.0, 1, 3) 3.0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 12:56:21 2019 From: report at bugs.python.org (Alexey Izbyshev) Date: Fri, 22 Feb 2019 17:56:21 +0000 Subject: [issue36067] subprocess terminate() "invalid handle" error when process is gone In-Reply-To: <1550763482.04.0.374893682062.issue36067@roundup.psfhosted.org> Message-ID: <1550858181.63.0.727735761987.issue36067@roundup.psfhosted.org> Alexey Izbyshev added the comment: > Interesting. Because both errors/conditions are mapped to ERROR_INVALID_HANDLE we need the creation time. I can work on a patch for that. I don't understand why any patch for CPython is needed at all. Using invalid handles is a serious programming bug (it's similar to using freed memory), so CPython doesn't really have to attempt to detect the programmer's error, at least not if this attempt significantly complicates the existing code. In my opinion, the CI failure linked in the first comment simply indicates a bug in psutil and is unrelated to CPython at all. ---------- nosy: +izbyshev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 12:57:05 2019 From: report at bugs.python.org (paul j3) Date: Fri, 22 Feb 2019 17:57:05 +0000 Subject: [issue36078] argparse: positional with type=int, default=SUPPRESS raise ValueError In-Reply-To: <1550845114.74.0.376208054151.issue36078@roundup.psfhosted.org> Message-ID: <1550858225.58.0.226748679736.issue36078@roundup.psfhosted.org> paul j3 added the comment: Defaults are handled into two stages. At the start of parsing defaults are added to the Namespace. At the end of parsing intact defaults are evaluated with 'type'. But a nargs='?' positional gets special handling. It matches an empty string, so it is always 'seen'. If its default is not None, that default is put in the Namespace instead of the matching empty list. It's this special default handling that lets us use a ?-positional in a mutually exclusive group. I suspect the error arises from this special default handling, but I'll have to look at the code to verify the details. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 13:24:52 2019 From: report at bugs.python.org (WloHu) Date: Fri, 22 Feb 2019 18:24:52 +0000 Subject: [issue36066] Add `empty` block to `for` and `while` loops. In-Reply-To: <1550759385.86.0.911138177234.issue36066@roundup.psfhosted.org> Message-ID: <1550859892.8.0.00290767392404.issue36066@roundup.psfhosted.org> WloHu added the comment: Sorry for beeing ignorant about python-ideas. The linked proposal is almost exatly what I've requested here, the differences are that it discusses other keyword alternatives and mine suggests an alternative for making empty generators false. If lack of follow-up in the linked proposal can be considered as "won't do" then this issue can be closed. Should I repost any part of this to python-ideas or whole case is closed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 14:09:58 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Fri, 22 Feb 2019 19:09:58 +0000 Subject: [issue36077] Inheritance dataclasses fields and default init statement In-Reply-To: <1550838433.8.0.658564691536.issue36077@roundup.psfhosted.org> Message-ID: <1550862598.63.0.923561441344.issue36077@roundup.psfhosted.org> R?mi Lapeyre added the comment: I think this is what is referring ?????? ?????? to: Python 3.7.2 (default, Jan 13 2019, 12:50:01) [Clang 10.0.0 (clang-1000.11.45.5)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from dataclasses import dataclass >>> @dataclass ... class Parent: ... x: int = 1 ... >>> Parent() Parent(x=1) >>> @dataclass ... class Child(Parent): ... y: int ... Traceback (most recent call last): File "", line 2, in File "/usr/local/Cellar/python/3.7.2_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/dataclasses.py", line 991, in dataclass return wrap(_cls) File "/usr/local/Cellar/python/3.7.2_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/dataclasses.py", line 983, in wrap return _process_class(cls, init, repr, eq, order, unsafe_hash, frozen) File "/usr/local/Cellar/python/3.7.2_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/dataclasses.py", line 904, in _process_class else 'self', File "/usr/local/Cellar/python/3.7.2_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/dataclasses.py", line 490, in _init_fn raise TypeError(f'non-default argument {f.name!r} ' TypeError: non-default argument 'y' follows default argument @eric.smith, do you think Child's argument should be merged nicely with Parent's ones in this case? If so, can I propose a PR? ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 13:42:43 2019 From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=) Date: Fri, 22 Feb 2019 18:42:43 +0000 Subject: =?utf-8?q?=5Bissue36083=5D_Misformated_manpage=3A_--check-hash-based-pycs?= =?utf-8?b?IMK0ZGVmYXVsdMK0fMK0YWx3YXlzwrR8wrRuZXZlcsK0?= Message-ID: <1550860963.76.0.541506927126.issue36083@roundup.psfhosted.org> New submission from Miro Hron?ok : man python3.7 or man python3.8 says this in synopsis: python [ -B ] [ -b ] [ -d ] [ -E ] [ -h ] [ -i ] [ -I ] [ -m module-name ] [ -q ] [ -O ] [ -OO ] [ -s ] [ -S ] [ -u ] [ -v ] [ -V ] [ -W argument ] [ -x ] [ [ -X option ] -? ] [ --check-hash-based-pycs ?default?|?always?|?never? ] [ -c command | script | - ] [ arguments ] Some words are bold, some are underlined. However the ?default?|?always?|?never? bit after --check-hash-based-pycs is misformated. The backticks should not be there, they should be underline instead. The source literally has: [ .B \--check-hash-based-pycs \'default\'|\'always\'|\'never\' ] since the original implementation of PEP 552 in 42aa93b8ff2f7879282b06efc73a31ec7785e602 I think it should be replaced with: [ .B \--check-hash-based-pycs .I default|always|never ] Shall I send a PR? ---------- assignee: docs at python components: Documentation messages: 336342 nosy: docs at python, hroncok priority: normal severity: normal status: open title: Misformated manpage: --check-hash-based-pycs ?default?|?always?|?never? versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 14:21:22 2019 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 22 Feb 2019 19:21:22 +0000 Subject: [issue36077] Inheritance dataclasses fields and default init statement In-Reply-To: <1550838433.8.0.658564691536.issue36077@roundup.psfhosted.org> Message-ID: <1550863282.21.0.57034371154.issue36077@roundup.psfhosted.org> Eric V. Smith added the comment: I'm not keen on re-ordering parameters. Maybe it could be done if specified with a parameter to @dataclass. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 14:32:53 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Fri, 22 Feb 2019 19:32:53 +0000 Subject: [issue36077] Inheritance dataclasses fields and default init statement In-Reply-To: <1550838433.8.0.658564691536.issue36077@roundup.psfhosted.org> Message-ID: <1550863973.57.0.932749853833.issue36077@roundup.psfhosted.org> R?mi Lapeyre added the comment: I see your point. On the other hand, a new parameter would also increase the complexity for the user. Maybe it should not be seen as re-ordering but just a "zipping" them correctly: @dataclass class Parent: i: int j: int = 0 @dataclass class Child(Parent): k: int l: int = 1 The "naive" to define Child's __index__ is: __index__(self, i: int, j: int = 0, k: int, l: int = 1): but wouldn't this make sense (given that it is previsible and deterministic)? __index__(self, i: int, k: int, j: int = 0, l: int = 1): ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 16:48:47 2019 From: report at bugs.python.org (Alexey Izbyshev) Date: Fri, 22 Feb 2019 21:48:47 +0000 Subject: [issue36046] support dropping privileges when running subprocesses In-Reply-To: <1550625858.55.0.53498127684.issue36046@roundup.psfhosted.org> Message-ID: <1550872127.12.0.591009141083.issue36046@roundup.psfhosted.org> Alexey Izbyshev added the comment: Patrick, could you provide more background that would explain your choice of setreuid/setregid functions and the desired handling of supplementary groups? I'm not a security expert, so I may not have sufficient expertise to judge on that, but maybe my questions could be helpful for others: 1) setreuid/setregid, as used in your PR, will set the real, effective and saved ids to the specified value [1]. So this precludes the use-case where a user wants to temporarily switch the effective id to the real id ("drop privileges") and then switch it back to the old effective (saved) id in the child. This use case is supported for non-root processes by POSIX_SPAWN_RESETIDS flag used with posix_spawn() (the flag is implemented by simply calling setuid(getuid()) in the child). Is it okay that the proposed API doesn't support this? 2) While setreuid/setregid on Linux permit setting the real id to either the effective or the real id, POSIX leaves it unspecified [2]. Are we okay with potential portability problems? 3) setgroups() always requires privileges on Linux [3]. So, if we always call setgroups() if subprocess.Popen(groups=...) is used, we preclude the use case where a non-privileged process wants to switch its gid but doesn't want to touch its supplementary groups. Is this a valid use case we want to care about? The current workaround for the above is to call setgroups() only if geteuid() == 0, but I'm not sure it's a good one: (a) ISTM we're basically guessing the intent here: what if a process really wants to change its supplementary groups, but a user run it without appropriate privileges by mistake? I think such process would like to get an exception instead of silently ignored call to setgroups(). (b) geteuid() == 0 test is not precise. The Linux man page documents that the caller needs the CAP_SETGID capability, which doesn't necessarily imply that the effective id is zero. Another solution would be to split groups into two arguments: gid and supplementary groups. This way users can explicitly tell us whether they want to switch supplementary groups or not. Overall, I'd really like to have security experts review this PR if possible. [1] http://man7.org/linux/man-pages/man2/setreuid.2.html [2] http://pubs.opengroup.org/onlinepubs/9699919799/functions/setreuid.html [3] http://man7.org/linux/man-pages/man2/setgroups.2.html ---------- assignee: gregory.p.smith -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 16:49:21 2019 From: report at bugs.python.org (Alexey Izbyshev) Date: Fri, 22 Feb 2019 21:49:21 +0000 Subject: [issue36046] support dropping privileges when running subprocesses In-Reply-To: <1550625858.55.0.53498127684.issue36046@roundup.psfhosted.org> Message-ID: <1550872161.83.0.810690807359.issue36046@roundup.psfhosted.org> Change by Alexey Izbyshev : ---------- assignee: -> gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 16:52:40 2019 From: report at bugs.python.org (paul j3) Date: Fri, 22 Feb 2019 21:52:40 +0000 Subject: [issue36078] argparse: positional with type=int, default=SUPPRESS raise ValueError In-Reply-To: <1550845114.74.0.376208054151.issue36078@roundup.psfhosted.org> Message-ID: <1550872360.36.0.823953544762.issue36078@roundup.psfhosted.org> paul j3 added the comment: By defining a custom 'type' function: def foo(astr): if astr is argparse.SUPPRESS: raise KeyError return astr I get the full traceback 1831 def take_action(action, argument_strings, option_string=None): 1832 seen_actions.add(action) -> 1833 argument_values = self._get_values(action, argument_strings) and in '_get_values' the error is produced when it calls '_get_value' (which runs the 'type' function): # optional argument produces a default when not present if not arg_strings and action.nargs == OPTIONAL: if action.option_strings: value = action.const else: value = action.default if isinstance(value, str): --> value = self._get_value(action, value) self._check_value(action, value) It identifies this as an OPTIONAL action that has received an empty argument list, and assigns it the action.default. ZERO_OR_MORE * also gets the action.default, but without a _get_value() call. That default can be SUPPRESSed by the test at the end of take_action. A couple of fixes come to mind: - add a SUPPRESS test at the start of take_action - add a SUPPRESS test to _get_values block I quote above, maybe bypassing the `_get_value` call There is a unittest case of a suppressed optional positional; it just doesn't also test for a failed type. class TestDefaultSuppress(ParserTestCase): """Test actions with suppressed defaults""" argument_signatures = [ Sig('foo', nargs='?', default=argparse.SUPPRESS) I'm inclined go with the second choice, but the alternatives need to be throughly tested. In the mean time, an 'int' type could be replaced with one that is SUPPRESS knowledgeable: def bar(astr): if astr is argparse.SUPPRESS: return astr else: return int(astr) Note that this use of action.default is different from the normal default handling at the start of parse_known_args (and the end of _parse_known_args). It's specifically for positionals that will always be 'seen' (because an empty argument strings list satisfies their nargs). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 17:46:11 2019 From: report at bugs.python.org (Jake Tesler) Date: Fri, 22 Feb 2019 22:46:11 +0000 Subject: [issue36084] Threading: add builtin TID attribute to Thread objects Message-ID: <1550875571.41.0.297490361597.issue36084@roundup.psfhosted.org> New submission from Jake Tesler : This functionality adds a native Thread ID to threading.Thread objects. This ID (TID), similar to the PID of a process, is assigned by the OS (kernel) and is generally used for externally monitoring resources consumed by the running thread (or process). This does not replace the `ident` attribute within Thread objects, which is assigned by the Python interpreter and is guaranteed as unique for the lifetime of the Python instance. ---------- messages: 336348 nosy: Jake Tesler priority: normal severity: normal status: open title: Threading: add builtin TID attribute to Thread objects type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 17:47:58 2019 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 Feb 2019 22:47:58 +0000 Subject: [issue36084] Threading: add builtin TID attribute to Thread objects In-Reply-To: <1550875571.41.0.297490361597.issue36084@roundup.psfhosted.org> Message-ID: <1550875678.9.0.979011787897.issue36084@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch pull_requests: +12016 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 19:28:57 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 23 Feb 2019 00:28:57 +0000 Subject: [issue36085] Enable better DLL resolution Message-ID: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org> New submission from Steve Dower : So the fundamental problem is that the default DLL search path on Windows changes in various contexts, and the only consistent approach is the most difficult to support with current packaging tools. The result is .pyd files that need to resolve .dll dependencies from directories *other* than where the .pyd file is located. Here's a generic scenario: * my_package.subpackage1.my_module is implemented as my_package/subpackage1/my_module.pyd * my_package.subpackage2.my_module is implemented as my_package/subpackage2/my_module.pyd * my_module.pyd in both cases depends on HelperLib.dll * both modules must end up with the same instance of HelperLib.dll While there are various ways for my_modules.pyd to locate HelperLib.dll, the only totally reliable way is to put HelperLib.dll alongside my_module.pyd. However, because it is needed twice, this means two copies of the DLL, which is unacceptable. With Python 3.8, we are *nearly* dropping support for Windows 7, and I believe we can justify dropping support for Windows 7 without KB2533625 [1], which will have been released over eight years by the time 3.8 releases. This means the DLL search path enhancements are available. Proposal #1: CPython calls SetDefaultDllDirectories() [2] on startup and exposes AddDllDirectory() [3] via the sys or os module. This would ensure consistency in DLL search order regardless of security settings, and modules that have their own ".libs" directory have a supported API for adding it to the search path. Past experience of forcing a consistent search path like this is that it has broken many users who expect features like %PATH% to locate DLL dependencies to work. For security reasons, this feature is already deprecated and often disabled (see [4]), so it can't be relied upon, but it makes it impossible for a single package to modify this setting or use the supported method for adding more DLL search directories. Proposal #2: Resolve extension modules by full name Without this proposal, the directory structure looks like: my_package\ -subpackage1\ --__init__.py --my_module.pyd --HelperLib.dll -subpackage2\ --__init__.py --my_module.pyd --HelperLib.dll After this proposal, it could look like: my_package\ -subpackage1 --__init__.py -subpackage2\ --__init__.py -my_package.subpackage1.my_module.pyd -my_package.subpackage2.my_module.pyd -HelperLib.dll Essentially, when searching for modules, allow going up the package hierarchy and locating a fully-qualified name at any level of the import tree. Note that since "import my_package.subpackage1.my_module" implies both "import my_package" and "import my_package.subpackage1", those have to succeed, but then the final part of the import would use subpackage1.__path__ to look for "my_module.pyd" and my_package.__path__ to look for "my_package.subpackage1.my_module.pyd". This allows all extension modules to be co-located in the one (importable) directory, along with a single copy of any shared dependencies. [1]: https://go.microsoft.com/fwlink/p/?linkid=217865 [2]: https://docs.microsoft.com/windows/desktop/api/libloaderapi/nf-libloaderapi-setdefaultdlldirectories [3]: https://docs.microsoft.com/windows/desktop/api/libloaderapi/nf-libloaderapi-adddlldirectory [4]: https://docs.microsoft.com/windows/desktop/Dlls/dynamic-link-library-search-order ---------- assignee: steve.dower components: Windows messages: 336349 nosy: brett.cannon, eric.snow, ncoghlan, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Enable better DLL resolution type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 19:33:04 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 23 Feb 2019 00:33:04 +0000 Subject: [issue36085] Enable better DLL resolution In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org> Message-ID: <1550881984.32.0.390607122966.issue36085@roundup.psfhosted.org> Steve Dower added the comment: I nosied both Windows and import experts, and I'm about to go ping relevant numpy/scipy people on https://github.com/numpy/numpy/pull/13019 Personally, I would prefer option #1, despite the pain it would cause. It is the better long-term supported option, and Anaconda has already adopted a patch that does this. However, I think it's most appropriate to be a change in CPython at a major release boundary so that we can provide proper porting information for users. Option #2 is kind of neat, and honestly I thought this already worked when the fully-qualified .pyd was in a folder on sys.path. However, it's going to mess big time with all of our existing build tools. So I'm not thrilled about passing on that kind of pain - then again, most people don't need this, and those who do can do their own hacks to make it work (on the theory that they're already applying their own hacks anyway). I'm totally open to other suggestions on how to make these situations workable, though I will (continue to) push back hard against ideas that simply bring back the security concerns that led us to this point :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 19:51:23 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 23 Feb 2019 00:51:23 +0000 Subject: [issue33944] Deprecate and remove pth files In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za> Message-ID: <1550883083.37.0.0797427036048.issue33944@roundup.psfhosted.org> Steve Dower added the comment: I took a look at the docs PR, and honestly I don't even get what the "intended" uses of executable code are supposed to be. The examples are "load 3rd-party import hooks, adjust PATH variable", but the only cases I can think of where you'd need to do these in a .pth file is where your module is a single file. As soon as you have a package with __init__.py, you have a file that can do exactly the same modifications before the module that needs it is imported. I'd be inclined to limit the doc change to not provide any "valid" uses for this, and just discourage doing anything that takes a long time (most of the text in the PR is fine, IMHO). And yeah, I'd like to see the arbitrary code execution "feature" removed too. As for .pth files in general, I'm interested in the scenarios that caused Barry to have to do difficult debugging where "python -m site" wasn't able to help. If they all involved arbitrary code execution, then let's take out the right tumor. But if they somehow manipulated sys.path in a way that looking at sys.path doesn't reveal, then I'd like to know how. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 20:00:01 2019 From: report at bugs.python.org (Jeremy Kloth) Date: Sat, 23 Feb 2019 01:00:01 +0000 Subject: [issue36085] Enable better DLL resolution In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org> Message-ID: <1550883601.52.0.90337372287.issue36085@roundup.psfhosted.org> Change by Jeremy Kloth : ---------- nosy: +jkloth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 20:03:02 2019 From: report at bugs.python.org (Jacob Bundgaard) Date: Sat, 23 Feb 2019 01:03:02 +0000 Subject: [issue36086] Split IDLE into separate feature in Windows installer Message-ID: <1550883782.51.0.779365974532.issue36086@roundup.psfhosted.org> New submission from Jacob Bundgaard : I don't use IDLE to edit Python files, but do use tcl/tk for Python projects on Windows. Therefore, it would be useful for me to be able to install tcl/tk without also installing IDLE. However, in the Windows installer, tcl/tk and IDLE are bundled together into one feature. Splitting them into two features (the IDLE feature requiring the tcl/tk one) would reduce installation time, storage use, Explorer context menu cluttering, etc. for users like me. ---------- components: Installation messages: 336352 nosy: kimsey0 priority: normal severity: normal status: open title: Split IDLE into separate feature in Windows installer type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 20:33:35 2019 From: report at bugs.python.org (Eryk Sun) Date: Sat, 23 Feb 2019 01:33:35 +0000 Subject: [issue36085] Enable better DLL resolution In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org> Message-ID: <1550885614.98.0.845022400699.issue36085@roundup.psfhosted.org> Eryk Sun added the comment: > Proposal #1: CPython calls SetDefaultDllDirectories() [2] on startup SetDefaultDllDirectories() affects the entire process, so it would needlessly break the world -- especially for embedding applications and ctypes users that have relied on adding directories to PATH. When loading an extension module, we can simply replace LOAD_WITH_ALTERED_SEARCH_PATH in the LoadLibraryExW flags with LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR and LOAD_LIBRARY_SEARCH_DEFAULT_DIRS (application directory, System32 directory, and directories added via SetDllDirectoryW and AddDllDirectory). Writers of extension modules are constrained by our API. We'll simply mandate that PATH is no longer searched. It's cumbersome to require packages to have to manually call AddDllDirectory before being able to import an extension module with dependencies. We could create a protocol to store relative paths as an embedded resource in the extension module, which would be similar to the RPATH/RUNPATH $ORIGIN field in POSIX. We'd first map the extension module as a data file via LOAD_LIBRARY_AS_DATAFILE | LOAD_LIBRARY_AS_IMAGE_RESOURCE. Load and resolve the relative paths, add them via AddDllDirectory. Call LoadLibraryExW with the above-mentioned flags. Then remove the directories via RemoveDllDirectory. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 20:44:30 2019 From: report at bugs.python.org (Tony Hammack) Date: Sat, 23 Feb 2019 01:44:30 +0000 Subject: [issue36087] ThreadPoolExecutor max_workers none issue Message-ID: <1550886270.51.0.0223111900331.issue36087@roundup.psfhosted.org> New submission from Tony Hammack : ThreadPoolExecutor(max_workers=None) throws exception when it should not. Inconsistent with 3.4 documentation. If max_workers=None, then it should use the amount of cpus as threadcount. ---------- components: Library (Lib) messages: 336354 nosy: Tony Hammack priority: normal severity: normal status: open title: ThreadPoolExecutor max_workers none issue type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 20:54:58 2019 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Feb 2019 01:54:58 +0000 Subject: [issue36087] ThreadPoolExecutor max_workers none issue In-Reply-To: <1550886270.51.0.0223111900331.issue36087@roundup.psfhosted.org> Message-ID: <1550886898.26.0.870080915314.issue36087@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch pull_requests: +12018 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 20:59:10 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 23 Feb 2019 01:59:10 +0000 Subject: [issue36085] Enable better DLL resolution In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org> Message-ID: <1550887150.56.0.982016970249.issue36085@roundup.psfhosted.org> Steve Dower added the comment: I'm very against doing magic to extract the names from the DLL, but maybe we could have a search path in the parent package? Then add/remove it around importing the module. I think you're right that we just need to update the LoadLibrary flags, but will those also apply to dependencies of the loaded module? I thought not... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 21:17:51 2019 From: report at bugs.python.org (Liyu Gong) Date: Sat, 23 Feb 2019 02:17:51 +0000 Subject: [issue36088] zipfile cannot handle zip in zip Message-ID: <1550888271.02.0.0237674201375.issue36088@roundup.psfhosted.org> New submission from Liyu Gong : Suppose a.zip is z zip file containing 'abc/def/1.txt' zf = zipfile.ZipFile('a.zip') memf = zf.open('abc/def/1.txt', 'r') zf2 = zipfile.ZipFile(memf) will raise an error. However, when a.zip is a tar file containing 'abc/def/1.txt', the following codes tf = tarfile.open('a.zip') memf = tf.open('abc/def/1.txt', 'r') zf2 = zipfile.ZipFile(memf) works well. Is it a known issue? Thanks! ---------- files: a.zip messages: 336356 nosy: liyugong priority: normal severity: normal status: open title: zipfile cannot handle zip in zip versions: Python 3.6 Added file: https://bugs.python.org/file48164/a.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 22:02:10 2019 From: report at bugs.python.org (Inada Naoki) Date: Sat, 23 Feb 2019 03:02:10 +0000 Subject: [issue36016] Allow gc.getobjects to return the objects tracked by a specific generation In-Reply-To: <1550434835.07.0.108252572436.issue36016@roundup.psfhosted.org> Message-ID: <1550890930.31.0.324733866611.issue36016@roundup.psfhosted.org> Inada Naoki added the comment: New changeset 175421b58cc97a2555e474f479f30a6c5d2250b0 by Inada Naoki (Pablo Galindo) in branch 'master': bpo-36016: Add generation option to gc.getobjects() (GH-11909) https://github.com/python/cpython/commit/175421b58cc97a2555e474f479f30a6c5d2250b0 ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 22:02:12 2019 From: report at bugs.python.org (Alan Grgic) Date: Sat, 23 Feb 2019 03:02:12 +0000 Subject: [issue36089] Formatting/Spelling errors in SimpleHTTPServer docs Message-ID: <1550890932.86.0.256234354239.issue36089@roundup.psfhosted.org> New submission from Alan Grgic : The warning heading near the top of https://docs.python.org/2/library/simplehttpserver.html contains improperly formatted text and misspells SimpleHTTPServer as 'SimpleHTTServer'. ---------- assignee: docs at python components: Documentation messages: 336358 nosy: Alan Grgic, docs at python priority: normal severity: normal status: open title: Formatting/Spelling errors in SimpleHTTPServer docs versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 22:22:45 2019 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Feb 2019 03:22:45 +0000 Subject: [issue36089] Formatting/Spelling errors in SimpleHTTPServer docs In-Reply-To: <1550890932.86.0.256234354239.issue36089@roundup.psfhosted.org> Message-ID: <1550892165.51.0.539634088002.issue36089@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch pull_requests: +12020 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 22 22:33:27 2019 From: report at bugs.python.org (=?utf-8?b?5pmv5LqR6bmP?=) Date: Sat, 23 Feb 2019 03:33:27 +0000 Subject: [issue36090] spelling error in PEP219 introduction Message-ID: <1550892807.64.0.358542044817.issue36090@roundup.psfhosted.org> New submission from ??? : https://www.python.org/dev/peps/pep-0219/#introduction paragraph2 in more that a year? or in more than a year? ---------- messages: 336359 nosy: ??? priority: normal severity: normal status: open title: spelling error in PEP219 introduction _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 00:05:52 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sat, 23 Feb 2019 05:05:52 +0000 Subject: [issue36087] ThreadPoolExecutor max_workers none issue In-Reply-To: <1550886270.51.0.0223111900331.issue36087@roundup.psfhosted.org> Message-ID: <1550898352.59.0.0870827737302.issue36087@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Thanks for the report. 3.4 is in security fixes only mode and will reach end of life soon. This seems to be a backport of the change in 3.5 that won't be accepted. Since the feature is available in 3.5+ I would recommend upgrading to 3.5 and above and to close this issue. ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 00:10:51 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 Feb 2019 05:10:51 +0000 Subject: [issue36088] zipfile cannot handle zip in zip In-Reply-To: <1550888271.02.0.0237674201375.issue36088@roundup.psfhosted.org> Message-ID: <1550898651.78.0.376443767291.issue36088@roundup.psfhosted.org> Serhiy Storchaka added the comment: The current behavior looks correct to me. abc/def/1.txt is not a ZIP file, so the error is expected. tarfile.open('a.zip') raises an error too, because a.zip is not a tar file. ---------- nosy: +serhiy.storchaka status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 00:16:16 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 Feb 2019 05:16:16 +0000 Subject: [issue36089] Formatting/Spelling errors in SimpleHTTPServer docs In-Reply-To: <1550890932.86.0.256234354239.issue36089@roundup.psfhosted.org> Message-ID: <1550898976.76.0.413369395173.issue36089@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset c7be55208b294e408ff625757198419af8914fdf by Serhiy Storchaka (Alan Grgic) in branch '2.7': bpo-36089: Fix formatting/spelling on SimpleHTTPServer docs. (GH-11995) https://github.com/python/cpython/commit/c7be55208b294e408ff625757198419af8914fdf ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 00:26:52 2019 From: report at bugs.python.org (Liyu Gong) Date: Sat, 23 Feb 2019 05:26:52 +0000 Subject: [issue36088] zipfile cannot handle zip in zip In-Reply-To: <1550888271.02.0.0237674201375.issue36088@roundup.psfhosted.org> Message-ID: <1550899612.33.0.413550954211.issue36088@roundup.psfhosted.org> Liyu Gong added the comment: Sorry, I made a mistake. I retested on the following content a.zip ==> abc/def/1.zip zf = zipfile.ZipFile('a.zip') memf = zf.open('abc/def/1.zip', 'r') zf2 = zipfile.ZipFile(memf) will raise an error. However, when a.zip is a tar file containing 'abc/def/1.zip', the following codes a.tar ===> abc/def/1.zip tf = tarfile.open('a.tar') memf = tf.extractfile('abc/def/1.zip') zf2 = zipfile.ZipFile(memf) works well. Since only one file can be uploaded, I will try to upload the tar file on the next post. ---------- status: pending -> open Added file: https://bugs.python.org/file48165/a.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 00:27:35 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 Feb 2019 05:27:35 +0000 Subject: [issue36089] Formatting/Spelling errors in SimpleHTTPServer docs In-Reply-To: <1550890932.86.0.256234354239.issue36089@roundup.psfhosted.org> Message-ID: <1550899655.1.0.00201937727391.issue36089@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 00:28:32 2019 From: report at bugs.python.org (Liyu Gong) Date: Sat, 23 Feb 2019 05:28:32 +0000 Subject: [issue36088] zipfile cannot handle zip in zip In-Reply-To: <1550888271.02.0.0237674201375.issue36088@roundup.psfhosted.org> Message-ID: <1550899712.29.0.307505738271.issue36088@roundup.psfhosted.org> Liyu Gong added the comment: add a.tar ---------- Added file: https://bugs.python.org/file48166/a.tar _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 00:28:45 2019 From: report at bugs.python.org (Liyu Gong) Date: Sat, 23 Feb 2019 05:28:45 +0000 Subject: [issue36088] zipfile cannot handle zip in zip In-Reply-To: <1550888271.02.0.0237674201375.issue36088@roundup.psfhosted.org> Message-ID: <1550899725.76.0.7162710726.issue36088@roundup.psfhosted.org> Change by Liyu Gong : Removed file: https://bugs.python.org/file48164/a.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 00:38:06 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 Feb 2019 05:38:06 +0000 Subject: [issue36088] zipfile cannot handle zip in zip In-Reply-To: <1550888271.02.0.0237674201375.issue36088@roundup.psfhosted.org> Message-ID: <1550900286.05.0.498597341851.issue36088@roundup.psfhosted.org> Serhiy Storchaka added the comment: Supporting nested zip files is a new feature added in 3.7 (see issue22908). New features can be added only in new Python versions. 3.6 currently takes only security bug fixes. ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 00:40:36 2019 From: report at bugs.python.org (noah) Date: Sat, 23 Feb 2019 05:40:36 +0000 Subject: [issue34315] Regex not evalauated correctly In-Reply-To: <1533189179.81.0.56676864532.issue34315@psf.upfronthosting.co.za> Message-ID: <1550900436.15.0.1591104793.issue34315@roundup.psfhosted.org> noah added the comment: I was able to recreate the 'bad' output on Linux using 'bad' input. The issue is caused when you misspell WHERE, regex is looking for the exact word "WHERE", any lowercase (where), multicase (WHeRe), or misspelling (WERE) is going to cause it to return None because regex didn't find a matching substring. I also on a whim tested out a bunch of encodings before realizing it didn't run on bytes objects anyways, so really the only way to get this output is to misspell the input. I think this problem should probably be closed as it's not a bug with the python core. ---------- nosy: +ngwood111 status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 00:50:05 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 Feb 2019 05:50:05 +0000 Subject: [issue34315] Regex not evalauated correctly In-Reply-To: <1533189179.81.0.56676864532.issue34315@psf.upfronthosting.co.za> Message-ID: <1550901005.18.0.673308207903.issue34315@roundup.psfhosted.org> Serhiy Storchaka added the comment: For case-insensitive matching you can use the re.IGNORECASE flag. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 01:07:17 2019 From: report at bugs.python.org (Henry Chen) Date: Sat, 23 Feb 2019 06:07:17 +0000 Subject: [issue36091] clean up async generator from types module Message-ID: <1550902037.39.0.489582604413.issue36091@roundup.psfhosted.org> New submission from Henry Chen : the following script: ``` import sys, types def tr(frame, event, arg): print(frame, event, arg) return tr sys.settrace(tr) ``` gives the output: ``` call None exception (, GeneratorExit(), ) return None ``` This is due to Lib/types.py creating an async generator for the sole purpose of getting its type. I'll remove that reference after use to prevent the above message, which is probably benign but perhaps unnerving. ---------- components: Library (Lib) messages: 336368 nosy: scotchka priority: normal severity: normal status: open title: clean up async generator from types module type: behavior versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 01:08:37 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sat, 23 Feb 2019 06:08:37 +0000 Subject: [issue35512] patch.dict resolves in_dict eagerly (should be late resolved) In-Reply-To: <1544993007.41.0.788709270274.issue35512@psf.upfronthosting.co.za> Message-ID: <1550902117.62.0.202765119604.issue35512@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Looking further this can be solved for a string target in patch.dict which can be resolved again while calling the decorated function. There could be a case where the actual target is specified and in that case mock could only updates the reference and cannot track if the variable has been redefined to reference a different dict object. In the below case also it's resolved with {'a': 1} in the decorator and later redefining target to {'a': 2} whose reference is not updated. I can propose a PR for string target but I am not sure if this case can be solved or it's expected. This seems to be not a problem with patch.object where redefining a class later like dict seems to work correctly and maybe it's due to creating a new class itself that updates the local to reference new class? Any thoughts would be helpful. # script with dict target passed from unittest import mock target = dict(a=1) @mock.patch.dict(target, dict(b=2)) def test_with_decorator(): print(f"target inside decorator : {target}") def test_with_context_manager(): with mock.patch.dict(target, dict(b=2)): print(f"target inside context : {target}") target = dict(a=2) test_with_decorator() test_with_context_manager() $ ./python.exe test_foo.py target inside decorator : {'a': 2} target inside context : {'a': 2, 'b': 2} ---------- nosy: +cjw296, mariocj89, michael.foord _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 01:12:24 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sat, 23 Feb 2019 06:12:24 +0000 Subject: [issue36090] spelling error in PEP219 introduction In-Reply-To: <1550892807.64.0.358542044817.issue36090@roundup.psfhosted.org> Message-ID: <1550902344.68.0.745218351758.issue36090@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: I am not sure if the tracker can be used for updating a PEP since the PEPs are available in separate GitHub repo that accepts issues and PRs at https://github.com/python/peps . ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 01:19:24 2019 From: report at bugs.python.org (Henry Chen) Date: Sat, 23 Feb 2019 06:19:24 +0000 Subject: [issue36091] clean up async generator from types module In-Reply-To: <1550902037.39.0.489582604413.issue36091@roundup.psfhosted.org> Message-ID: <1550902764.93.0.779695450793.issue36091@roundup.psfhosted.org> Change by Henry Chen : ---------- keywords: +patch pull_requests: +12021 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 01:26:43 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sat, 23 Feb 2019 06:26:43 +0000 Subject: [issue36084] Threading: add builtin TID attribute to Thread objects In-Reply-To: <1550875571.41.0.297490361597.issue36084@roundup.psfhosted.org> Message-ID: <1550903203.25.0.929468411703.issue36084@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 01:49:42 2019 From: report at bugs.python.org (Eryk Sun) Date: Sat, 23 Feb 2019 06:49:42 +0000 Subject: [issue36085] Enable better DLL resolution In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org> Message-ID: <1550904582.87.0.841444607614.issue36085@roundup.psfhosted.org> Eryk Sun added the comment: > I'm very against doing magic to extract the names from the DLL, but > but maybe we could have a search path in the parent package? Then > add/remove it around importing the module. That works, too. I'm happy either way. We still can't load multiple DLLs with the same name with this technique. That requires private assembly packages, which is doable (in Windows 7+), but a bit complex and requires modifying the embedded #2 manifest of the extension module. The alternative is to rewrite the PE import tables of all DLLs to reference unique DLL names. Neither is necessary if everything is built against unique, versioned DLL names. > I think you're right that we just need to update the LoadLibrary > flags, but will those also apply to dependencies of the loaded > module? The DLL search path is computed once per LoadLibraryExW call based on either the call flags or the process default flags. We shouldn't mess with the process default, since there's no way to restore the legacy DLL search path, in particular this includes the Windows directory (%SystemRoot%), 16-bit System directory (%SystemRoot%\System), current directory, and PATH. Should we support a convenient syntax for including the current value of PATH at extension-module load time? This could be an entry that's exactly equal to "". (Less-than and greater-than are reserved as wildcard characters by all Windows file systems that I can think of.) It would iterate over PATH, adding each directory via AddDllDirectory. Of course, all added directories would subsequently be removed via RemoveDllDirectory after the LoadLibraryExW call. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 01:51:44 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sat, 23 Feb 2019 06:51:44 +0000 Subject: [issue36092] unittest.mock's patch.object and patch.dict are not supported on classmethod, propery and staticmethod Message-ID: <1550904704.81.0.829273897144.issue36092@roundup.psfhosted.org> New submission from Karthikeyan Singaravelan : While looking into the unittest.mock tests I came across test_patch_descriptor [0] which makes an early return since patch.object and patch.dict are not supported on staticmethod, classmethod and property as noted in the comment. The tests still fail on master. The test was added during initial addition of mock to stdlib (commit 345266aa7e7) and I couldn't find any issues related to this. So I am filing this if someones wants to fix it. [0] https://github.com/python/cpython/blob/175421b58cc97a2555e474f479f30a6c5d2250b0/Lib/unittest/test/testmock/testpatch.py#L667 ---------- components: Library (Lib) messages: 336372 nosy: cjw296, mariocj89, michael.foord, xtreak priority: normal severity: normal status: open title: unittest.mock's patch.object and patch.dict are not supported on classmethod, propery and staticmethod type: behavior versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 02:02:37 2019 From: report at bugs.python.org (SilentGhost) Date: Sat, 23 Feb 2019 07:02:37 +0000 Subject: [issue36086] Split IDLE into separate feature in Windows installer In-Reply-To: <1550883782.51.0.779365974532.issue36086@roundup.psfhosted.org> Message-ID: <1550905357.08.0.370242064956.issue36086@roundup.psfhosted.org> Change by SilentGhost : ---------- nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 02:04:07 2019 From: report at bugs.python.org (SilentGhost) Date: Sat, 23 Feb 2019 07:04:07 +0000 Subject: [issue36091] clean up async generator from types module In-Reply-To: <1550902037.39.0.489582604413.issue36091@roundup.psfhosted.org> Message-ID: <1550905447.04.0.0773105770715.issue36091@roundup.psfhosted.org> Change by SilentGhost : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 02:42:26 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sat, 23 Feb 2019 07:42:26 +0000 Subject: [issue36086] Split IDLE into separate feature in Windows installer In-Reply-To: <1550883782.51.0.779365974532.issue36086@roundup.psfhosted.org> Message-ID: <1550907746.31.0.805363107106.issue36086@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 02:54:25 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 Feb 2019 07:54:25 +0000 Subject: [issue36091] clean up async generator from types module In-Reply-To: <1550902037.39.0.489582604413.issue36091@roundup.psfhosted.org> Message-ID: <1550908465.9.0.416014110074.issue36091@roundup.psfhosted.org> Serhiy Storchaka added the comment: I am sure this change already was discussed in other issue, but I can not find that issue and I am not sure that there is a PR. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 02:59:18 2019 From: report at bugs.python.org (Windson Yang) Date: Sat, 23 Feb 2019 07:59:18 +0000 Subject: [issue36093] UnicodeEncodeError raise from smtplib.verify() method Message-ID: <1550908758.26.0.552141628876.issue36093@roundup.psfhosted.org> New submission from Windson Yang : AFAIK, the email address should support non-ASCII character (from https://stackoverflow.com/questions/760150/can-an-email-address-contain-international-non-english-characters and SMTPUTF8 option from https://docs.python.org/3/library/smtplib.html#smtplib.SMTP.sendmail) >>> import smtplib >>> s = smtplib.SMTP(host='smtp-mail.outlook.com', port=587) >>> s.verify('??@outlook.com') Traceback (most recent call last): File "", line 1, in File "/Users/windson/learn/cpython/Lib/smtplib.py", line 577, in verify self.putcmd("vrfy", _addr_only(address)) File "/Users/windson/learn/cpython/Lib/smtplib.py", line 367, in putcmd self.send(str) File "/Users/windson/learn/cpython/Lib/smtplib.py", line 352, in send s = s.encode(self.command_encoding) UnicodeEncodeError: 'ascii' codec can't encode characters in position 5-6: ordinal not in range(128) I found this issue when I updating https://github.com/python/cpython/pull/8938/files ---------- components: Unicode messages: 336374 nosy: Windson Yang, ezio.melotti, vstinner priority: normal severity: normal status: open title: UnicodeEncodeError raise from smtplib.verify() method type: behavior versions: Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 03:04:47 2019 From: report at bugs.python.org (Windson Yang) Date: Sat, 23 Feb 2019 08:04:47 +0000 Subject: [issue36093] UnicodeEncodeError raise from smtplib.verify() method In-Reply-To: <1550908758.26.0.552141628876.issue36093@roundup.psfhosted.org> Message-ID: <1550909087.27.0.850591333058.issue36093@roundup.psfhosted.org> Windson Yang added the comment: Btw, from the docs https://docs.python.org/3/library/smtplib.html#smtplib.SMTP.sendmail > msg may be a string containing characters in the ASCII range, or a byte string. A string is encoded to bytes using the ascii codec, and lone \r and \n characters are converted to \r\n characters. A byte string is not modified. So we can't send non-ASCII msg using send_mail(), is this expected behavior? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 04:42:35 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 23 Feb 2019 09:42:35 +0000 Subject: [issue36018] Add a Normal Distribution class to the statistics module In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org> Message-ID: <1550914955.29.0.765788255014.issue36018@roundup.psfhosted.org> Raymond Hettinger added the comment: Thanks for all the positive feedback. If there are no objections, I would like to push this so it will be in the second alpha release so that it can get exercised. We can still make adjustments afterwards. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 05:22:12 2019 From: report at bugs.python.org (Andrew Svetlov) Date: Sat, 23 Feb 2019 10:22:12 +0000 Subject: [issue36087] ThreadPoolExecutor max_workers none issue In-Reply-To: <1550886270.51.0.0223111900331.issue36087@roundup.psfhosted.org> Message-ID: <1550917332.21.0.399358259666.issue36087@roundup.psfhosted.org> Andrew Svetlov added the comment: Please use the correct documentation version for Python 3.4. https://docs.python.org/3.4/library/concurrent.futures.html doesn't mention the pool size auto-selection. The feature was added in Python 3.5 only. Also, Python 3.4 reached the end-of-life, this version is not supported anymore. ---------- nosy: +asvetlov resolution: -> not a bug stage: patch review -> resolved status: open -> closed type: crash -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 05:26:50 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 23 Feb 2019 10:26:50 +0000 Subject: [issue36086] Split IDLE into separate feature in Windows installer In-Reply-To: <1550883782.51.0.779365974532.issue36086@roundup.psfhosted.org> Message-ID: <1550917610.91.0.417255644196.issue36086@roundup.psfhosted.org> Terry J. Reedy added the comment: The installed space for /lib/idlelib it is roughly 2% of the total, depending on other options. The time saved is, I think, roughly comparable to the extra time it would take to read and think about another option. So the main issue would be making 'Edit with IDLE' optional. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 06:50:17 2019 From: report at bugs.python.org (Inada Naoki) Date: Sat, 23 Feb 2019 11:50:17 +0000 Subject: [issue36016] Allow gc.getobjects to return the objects tracked by a specific generation In-Reply-To: <1550434835.07.0.108252572436.issue36016@roundup.psfhosted.org> Message-ID: <1550922617.66.0.709686913374.issue36016@roundup.psfhosted.org> Change by Inada Naoki : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 08:42:06 2019 From: report at bugs.python.org (dfmz77669) Date: Sat, 23 Feb 2019 13:42:06 +0000 Subject: [issue34656] [CVE-2018-20406] memory exhaustion in Modules/_pickle.c:1393 In-Reply-To: <1536813527.13.0.956365154283.issue34656@psf.upfronthosting.co.za> Message-ID: <1550929326.76.0.359401841915.issue34656@roundup.psfhosted.org> Change by dfmz77669 : ---------- nosy: -alexandre.vassalotti, benjamin.peterson, hroncok, mcepl, miss-islington, serhiy.storchaka, shuoz, xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 08:49:42 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Sat, 23 Feb 2019 13:49:42 +0000 Subject: [issue36092] unittest.mock's patch.object and patch.dict are not supported on classmethod, propery and staticmethod In-Reply-To: <1550904704.81.0.829273897144.issue36092@roundup.psfhosted.org> Message-ID: <1550929782.69.0.515992047054.issue36092@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 09:03:24 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 23 Feb 2019 14:03:24 +0000 Subject: [issue36086] Split IDLE into separate feature in Windows installer In-Reply-To: <1550883782.51.0.779365974532.issue36086@roundup.psfhosted.org> Message-ID: <1550930604.96.0.202684606749.issue36086@roundup.psfhosted.org> Steve Dower added the comment: Right, Idle is tiny and painless compared to Tk, and adding additional options to the installer isn't trivial. I might consider a patch, but I'm not doing this myself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 09:06:00 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 23 Feb 2019 14:06:00 +0000 Subject: [issue36085] Enable better DLL resolution In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org> Message-ID: <1550930760.26.0.385297420683.issue36085@roundup.psfhosted.org> Steve Dower added the comment: > Should we support a convenient syntax for including the current value of PATH at extension-module load time? No. This is the bit that I refuse to add back, at least in CPython itself (if someone does it themselves then it's their bug). Private directories only. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 09:14:10 2019 From: report at bugs.python.org (dfmz77669) Date: Sat, 23 Feb 2019 14:14:10 +0000 Subject: [issue34656] [CVE-2018-20406] memory exhaustion in Modules/_pickle.c:1393 In-Reply-To: <1536813527.13.0.956365154283.issue34656@psf.upfronthosting.co.za> Message-ID: <1550931250.52.0.048595293873.issue34656@roundup.psfhosted.org> dfmz77669 added the comment: In python2, Picklertype donot has tp init which has bug in python3 Pickler_Type. I think it not effect python2. Can you arch more infor? thanks ---------- components: +ctypes -FreeBSD nosy: +dfmz77669 versions: -Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 09:17:43 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Sat, 23 Feb 2019 14:17:43 +0000 Subject: [issue36090] spelling error in PEP219 introduction In-Reply-To: <1550892807.64.0.358542044817.issue36090@roundup.psfhosted.org> Message-ID: <1550931463.3.0.641980397211.issue36090@roundup.psfhosted.org> Joannah Nanjekye added the comment: xtreak, I agree. I think the best way to report an issue on a PEP is on the github repository for PEPs. Feel free to open an issue here : https://github.com/python/peps/issues. ---------- nosy: +nanjekyejoannah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 10:13:39 2019 From: report at bugs.python.org (flokX) Date: Sat, 23 Feb 2019 15:13:39 +0000 Subject: [issue33695] Have shutil.copytree(), copy() and copystat() use cached scandir() stat()s In-Reply-To: <1527682955.69.0.682650639539.issue33695@psf.upfronthosting.co.za> Message-ID: <1550934819.99.0.0542347446783.issue33695@roundup.psfhosted.org> Change by flokX : ---------- pull_requests: +12022 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 10:16:23 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 23 Feb 2019 15:16:23 +0000 Subject: [issue35652] Add use_srcentry parameter to shutil.copytree() II In-Reply-To: <1546541865.13.0.115152005965.issue35652@roundup.psfhosted.org> Message-ID: <1550934983.3.0.329741556917.issue35652@roundup.psfhosted.org> Change by Giampaolo Rodola' : ---------- pull_requests: +12023 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 10:40:07 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 23 Feb 2019 15:40:07 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1550936407.5.0.0820977087216.issue35813@roundup.psfhosted.org> Giampaolo Rodola' added the comment: > We are consciously choosing to not support an atomic "create or attach". This significantly simplifies the API and avoids the valid concerns raised around user confusion relating to that behavior (including the use of different specified 'size' values in a race) but does not preclude our potentially introducing this as a feature in the future. I understand that because of *size* we cannot solve the race condition issue unless the user uses some sort of synchronization mechanism. FWIW I bumped into this lib: http://semanchuk.com/philip/sysv_ipc/ ...which provides two separate APIs to "create" and "attach": >>> SharedMemory("name", IPC_CREX) >>> attach("name") At this point I'm agnostic about the API, which is probably just a matter of personal taste (e.g. one may prefer a separate SharedMemory.attach() classmethod or a *mode* argument accepting "x" and "a"). I see that that lib use shmat() on attach and shmdt() on detach. I'm not sure if that makes a difference, just mentioning it because your implementation doesn't do that on close() and perhaps it should. > Combined with a SyncManager.Lock, users can already achieve an atomic "create or attach" using this simpler API. That assumes a single app/process which spawns a child (the "worker"). In that case SyncManager.Lock/others is indeed compatible with SharedMemory and can be used to implement non-racy "create or attach" and also to synchronize memory access on read and write. But AFAICT there are two uses cases for this functionality, and there currently is no mechanism to do any that if you have two unrelated apps/processes relying on a common shared memory *name* and *size*. I'm taking a peek at "man smh_overview" which says: <> That would translate into a new Semaphore(name=None, create=False) class which (possibly?) would also provide better performances compared to SyncManager.Semaphore. Not sure if we can do the same on Windows though. Extra 1: apparently there are also POSIX msgget(), msgrcv() and msgsnd() syscalls which could be used to implement a System-V message Queue similar to SyncManager.Queue later on. Extra 2: given the 2 distinct use-cases I wonder if the low-level component (shared_memory.py) really belongs to multiprocessing module. Perhaps this should be provided as a separate "sharedmemory" module with multiprocessing.managers.SharedMemoryMemory being the high-level interface. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 10:53:10 2019 From: report at bugs.python.org (Yash Aggarwal) Date: Sat, 23 Feb 2019 15:53:10 +0000 Subject: [issue35431] Add a function for computing binomial coefficients to the math module In-Reply-To: <1544131082.09.0.788709270274.issue35431@psf.upfronthosting.co.za> Message-ID: <1550937190.87.0.38871488164.issue35431@roundup.psfhosted.org> Yash Aggarwal added the comment: Can I get a consensus on weather math.perm() is needed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 11:29:43 2019 From: report at bugs.python.org (Mario Corchero) Date: Sat, 23 Feb 2019 16:29:43 +0000 Subject: [issue35512] patch.dict resolves in_dict eagerly (should be late resolved) In-Reply-To: <1544993007.41.0.788709270274.issue35512@psf.upfronthosting.co.za> Message-ID: <1550939383.86.0.520693517019.issue35512@roundup.psfhosted.org> Mario Corchero added the comment: Interesting, `patch` does resolve it when the patched function is called (see https://github.com/python/cpython/blob/175421b58cc97a2555e474f479f30a6c5d2250b0/Lib/unittest/mock.py#L1269) vs patch.dict that resolves it at the time the patcher is created - when decorating - (see https://github.com/python/cpython/blob/175421b58cc97a2555e474f479f30a6c5d2250b0/Lib/unittest/mock.py#L1624). An option might be to delay the resolution as done for patch, changing https://github.com/python/cpython/blob/175421b58cc97a2555e474f479f30a6c5d2250b0/Lib/unittest/mock.py#L1625 to `self.in_dict_name = in_dict` Example untested patch: ``` diff --git a/Lib/unittest/mock.py b/Lib/unittest/mock.py index 8f46050462..5328fda417 100644 --- a/Lib/unittest/mock.py +++ b/Lib/unittest/mock.py @@ -1620,9 +1620,7 @@ class _patch_dict(object): """ def __init__(self, in_dict, values=(), clear=False, **kwargs): - if isinstance(in_dict, str): - in_dict = _importer(in_dict) - self.in_dict = in_dict + self.in_dict_name = in_dict # support any argument supported by dict(...) constructor self.values = dict(values) self.values.update(kwargs) @@ -1649,7 +1647,7 @@ class _patch_dict(object): attr_value = getattr(klass, attr) if (attr.startswith(patch.TEST_PREFIX) and hasattr(attr_value, "__call__")): - decorator = _patch_dict(self.in_dict, self.values, self.clear) + decorator = _patch_dict(self.in_dict_name, self.values, self.clear) decorated = decorator(attr_value) setattr(klass, attr, decorated) return klass @@ -1662,7 +1660,11 @@ class _patch_dict(object): def _patch_dict(self): values = self.values - in_dict = self.in_dict + if isinstance(self.in_dict_name, str): + in_dict = _importer(self.in_dict_name) + else: + in_dict = self.in_dict_name + self.in_dict = in_dict ``` > This seems to be not a problem with patch.object where redefining a class later like dict seems to work correctly and maybe it's due to creating a new class itself that updates the local to reference new class? For patch, when you create a new class, the new one is patched as the name is resolved at the time the decorated function is executed, not when it is decorated. See: ``` $ cat t.py from unittest import mock import c target = dict(a=1) @mock.patch("c.A", "target", "updated") def test_with_decorator(): print(f"target inside decorator : {A.target}") def test_with_context_manager(): with mock.patch("c.A", "target", "updated"): print(f"target inside context : {A.target}") class A: target = "changed" c.A = A test_with_decorator() test_with_context_manager() xarmariocj89 at DESKTOP-9B6VH3A in ~/workspace/cpython on master* $ cat c.py class A: target = "original" mariocj89 at DESKTOP-9B6VH3A in ~/workspace/cpython on master* $ ./python ./t.py target inside decorator : changed target inside context : changed ``` If `patch` was implemented like `patch.dict`, you would see the first as "changed" as the reference to `c.A` would have been resolved when the decorator was run (before the re-definition of `A`). About `patch.object`, it cannot be compared, as it grabs the name at the time you execute the decorator because you are not passing a string, but the actual object to patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 11:34:54 2019 From: report at bugs.python.org (Philip Semanchuk) Date: Sat, 23 Feb 2019 16:34:54 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1550936407.5.0.0820977087216.issue35813@roundup.psfhosted.org> Message-ID: <8601E84C-7AC5-41FF-98E8-E5D71A0C1F20@pyspoken.com> Philip Semanchuk added the comment: > On Feb 23, 2019, at 10:40 AM, Giampaolo Rodola' wrote: > > > Giampaolo Rodola' added the comment: > >> We are consciously choosing to not support an atomic "create or attach". This significantly simplifies the API and avoids the valid concerns raised around user confusion relating to that behavior (including the use of different specified 'size' values in a race) but does not preclude our potentially introducing this as a feature in the future. > > I understand that because of *size* we cannot solve the race condition issue unless the user uses some sort of synchronization mechanism. FWIW I bumped into this lib: > http://semanchuk.com/philip/sysv_ipc/ > ...which provides two separate APIs to "create" and "attach": > >>>> SharedMemory("name", IPC_CREX) >>>> attach("name") > > At this point I'm agnostic about the API, which is probably just a matter of personal taste (e.g. one may prefer a separate SharedMemory.attach() classmethod or a *mode* argument accepting "x" and "a"). I see that that lib use shmat() on attach and shmdt() on detach. I'm not sure if that makes a difference, just mentioning it because your implementation doesn't do that on close() and perhaps it should. attach() and detach() are particular to SysV IPC which is different from the POSIX IPC that?s being used here. There?s no need for attach() and detach() with POSIX shared memory. POSIX IPC is generally simpler than SysV IPC, in part because it was developed after SysV IPC so the developers had the benefit of experience with the older API. Side note: I?m the author of the sysv_ipc package you found, as well as the posix_ipc package. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 11:36:46 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 23 Feb 2019 16:36:46 +0000 Subject: [issue35652] Add use_srcentry parameter to shutil.copytree() II In-Reply-To: <1546541865.13.0.115152005965.issue35652@roundup.psfhosted.org> Message-ID: <1550939806.98.0.782549317413.issue35652@roundup.psfhosted.org> Giampaolo Rodola' added the comment: Not sure why you created 2 identical issues. Closing this one as a duplicate of issue35648. ---------- nosy: +giampaolo.rodola resolution: -> duplicate stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 11:36:54 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 23 Feb 2019 16:36:54 +0000 Subject: [issue35652] Add use_srcentry parameter to shutil.copytree() II In-Reply-To: <1546541865.13.0.115152005965.issue35652@roundup.psfhosted.org> Message-ID: <1550939814.35.0.20541955921.issue35652@roundup.psfhosted.org> Change by Giampaolo Rodola' : ---------- pull_requests: -12023 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 11:37:33 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 23 Feb 2019 16:37:33 +0000 Subject: [issue35648] Add use_srcentry parameter to shutil.copytree() In-Reply-To: <1546506372.52.0.724433917377.issue35648@roundup.psfhosted.org> Message-ID: <1550939853.45.0.450283947931.issue35648@roundup.psfhosted.org> Change by Giampaolo Rodola' : ---------- assignee: docs at python -> resolution: later -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 11:42:57 2019 From: report at bugs.python.org (Davin Potts) Date: Sat, 23 Feb 2019 16:42:57 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1550940177.77.0.0490177666158.issue35813@roundup.psfhosted.org> Davin Potts added the comment: > FWIW I bumped into this lib: http://semanchuk.com/philip/sysv_ipc/ The author of that lib, Philip Semanchuk, is one of the people participating in this effort -- he has posted above in msg334934 here on b.p.o. and has helped review the PR in GH-11816. He is also the author of the posix_ipc package which was the original basis for our POSIX Shared Memory implementation here. The decision to base our Unix platform support upon POSIX and not SystemV libraries came after considerable research and there are important differences between the two. To oversimplify: POSIX Shared Memory support has now been available for some time on Linux, *BSD, MacOS, and others and is something of a successor to the SystemV. > That assumes a single app/process which spawns a child (the "worker"). Not true. A manager started by one process can be connected to by another process that is not a child. This is covered in the docs here: https://docs.python.org/3/library/multiprocessing.html#using-a-remote-manager That child can then request that shared memory blocks it creates be remotely tracked and managed by that remote process's manager. While I would not expect this to be a common use case, this is a feature of BaseManager that we inherit into SharedMemoryManager. The SyncManager.Lock can be used as part of this as well. Thus, two unrelated apps/processes *can* coordinate their management of shared memory blocks through the SharedMemoryManager. > That would translate into a new Semaphore(name=None, create=False) > class which (possibly?) would also provide better performances > compared to SyncManager.Semaphore Right! You might have noticed that Philip has such a semaphore construct in his posix_ipc lib. I opted to not attempt to add this feature as part of this effort to both (1) keep focused on the core needs to work with shared memory, and (2) to take more time in the future to work out how to get cross-platform support for the semaphore right (as you point out, there are complications to work through). > Extra 1: apparently there are also POSIX msgget(), msgrcv() and > msgsnd() syscalls which could be used to implement a System-V message > Queue similar to SyncManager.Queue later on. Right! This is also something Philip has in his posix_ipc lib. This should be part of the roadmap for what we do next with SharedMemory. This one may be complicated by the fact that not all platforms that implement POSIX Shared Memory chose to also implement these functions in the same way. We will need time to work out what we can or can not reasonably do here. > Extra 2: given the 2 distinct use-cases I wonder if the low-level > component (shared_memory.py) really belongs to multiprocessing module Given what I wrote above about how multiprocessing.managers does enable these use cases and the existing "distributed shared memory" support in multiprocessing, I think it logically belongs in multiprocessing. I suggest that "shm_open" and "shm_unlink" are our low-level tools, which appropriately are in _posixshmem, but SharedMemory and the rest are high-level tools; SharedMemoryManager will not be able to cover all life-cycle management use cases thus SharedMemory will be needed by many and in contrast, "shm_open" and "shm_unlink" will be needed only by those wishing to do something wacky. (Note: I am not trying to make "wacky" sound like a bad thing because wacky can be very cool sometimes.) Philip's ears should now be burning, I mentioned him so many times in this post. Ah! He beat me to it while I was writing this. Awesome! We would not be where we are with SharedMemory without his efforts over many years with his posix_ipc lib. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 11:49:05 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sat, 23 Feb 2019 16:49:05 +0000 Subject: [issue35512] patch.dict resolves in_dict eagerly (should be late resolved) In-Reply-To: <1544993007.41.0.788709270274.issue35512@psf.upfronthosting.co.za> Message-ID: <1550940545.87.0.641264801498.issue35512@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Thanks Mario for the details. I had almost the same patch while writing msg336300 :) There were no test case failures except that I had resolved it in the constructor storing the string representation as a separate variable and also while calling the function which could be avoided as per your approach to just store the string and resolve once during function call. I think this is a good way to do this. Are you planning to create a PR or shall I go ahead with this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 11:52:24 2019 From: report at bugs.python.org (Mario Corchero) Date: Sat, 23 Feb 2019 16:52:24 +0000 Subject: [issue35512] patch.dict resolves in_dict eagerly (should be late resolved) In-Reply-To: <1544993007.41.0.788709270274.issue35512@psf.upfronthosting.co.za> Message-ID: <1550940744.95.0.11031353532.issue35512@roundup.psfhosted.org> Mario Corchero added the comment: Great, all yours :) I'll be happy to review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 11:57:47 2019 From: report at bugs.python.org (mattip) Date: Sat, 23 Feb 2019 16:57:47 +0000 Subject: [issue36085] Enable better DLL resolution In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org> Message-ID: <1550941067.27.0.83089415539.issue36085@roundup.psfhosted.org> mattip added the comment: Clear documentation would go a long way toward onboarding package providers. Of course this does not solve the problem for packages with no active ongoing support for windows, and will annoy developers whose code base is full of `os.environ['PATH']` games. Perhaps the solution should come with a deprecation warning when setting `os.environ['PATH']`. It would be very helpful if failure to import a pyd (or for that matter to open a DLL with ctypes) due to missing support dlls could be easily debugged. Right now we get a message from windows that seems to suggest the file was not found. - Python could check if the file exists on disk and print a more helpful message - A debug hook to print the dll search path at the time of the failed LoadLibraryEx call, or perhaps adding it as an attribute of the Exception (this might be nice to have on Linux as well, even though there the Exception already includes the name of the missing *.so). Even better would be official python/Microsoft support for a CLI version of depends.exe like ldd on linux, but that seems much harder and is out of scope for this issue. ---------- nosy: +mattip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 12:14:29 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 23 Feb 2019 17:14:29 +0000 Subject: [issue35652] Add use_srcentry parameter to shutil.copytree() II In-Reply-To: <1546541865.13.0.115152005965.issue35652@roundup.psfhosted.org> Message-ID: <1550942069.69.0.611111527866.issue35652@roundup.psfhosted.org> Change by Giampaolo Rodola' : ---------- pull_requests: +12024 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 12:14:29 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 23 Feb 2019 17:14:29 +0000 Subject: [issue33695] Have shutil.copytree(), copy() and copystat() use cached scandir() stat()s In-Reply-To: <1527682955.69.0.682650639539.issue33695@psf.upfronthosting.co.za> Message-ID: <1550942069.75.0.117799277762.issue33695@roundup.psfhosted.org> Change by Giampaolo Rodola' : ---------- pull_requests: +12025 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 12:17:38 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 23 Feb 2019 17:17:38 +0000 Subject: [issue35648] Add use_srcentry parameter to shutil.copytree() In-Reply-To: <1546506372.52.0.724433917377.issue35648@roundup.psfhosted.org> Message-ID: <1550942258.05.0.354857594273.issue35648@roundup.psfhosted.org> Giampaolo Rodola' added the comment: It turns out that's a bug I introduced in PR-7874. I'm providing: https://github.com/python/cpython/pull/11997 ...which fixes it without introducing a new parameter. I also verified that monkey patching shutil.copy2 and shutil.copy doesn't cause any issue. ---------- nosy: +giampaolo.rodola pull_requests: +12026 stage: resolved -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 12:44:01 2019 From: report at bugs.python.org (=?utf-8?b?6LW15Yab5pix?=) Date: Sat, 23 Feb 2019 17:44:01 +0000 Subject: [issue36094] When using an SMTP SSL connection,, get ValueError. Message-ID: <1550943841.97.0.129283187576.issue36094@roundup.psfhosted.org> New submission from ??? <200612453 at qq.com>: The following bug occurs when you connect after creating an instance of SMTP_SSL: ``` import smtplib smtp_server = "smtp.163.com" con2 = smtplib.SMTP_SSL() con2.connect(smtp_server, 465) ``` ValueError: server_hostname cannot be an empty string or start with a leading dot. File "E:\code\noUse.py", line 8, in con2.connect(smtp_server, 465) ---------- components: email files: 1.png messages: 336393 nosy: barry, r.david.murray, tyrone-zhao priority: normal severity: normal status: open title: When using an SMTP SSL connection,, get ValueError. type: resource usage versions: Python 3.7 Added file: https://bugs.python.org/file48167/1.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 12:57:38 2019 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Feb 2019 17:57:38 +0000 Subject: [issue36094] When using an SMTP SSL connection,, get ValueError. In-Reply-To: <1550943841.97.0.129283187576.issue36094@roundup.psfhosted.org> Message-ID: <1550944658.41.0.606699722434.issue36094@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch pull_requests: +12027 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 13:02:42 2019 From: report at bugs.python.org (flokX) Date: Sat, 23 Feb 2019 18:02:42 +0000 Subject: [issue35648] Add use_srcentry parameter to shutil.copytree() In-Reply-To: <1546506372.52.0.724433917377.issue35648@roundup.psfhosted.org> Message-ID: <1550944962.71.0.582214075307.issue35648@roundup.psfhosted.org> flokX added the comment: You are right about the bug. The funny thing is, I never saw it. The problem I see is another. The use_srcentry variable in the _copytree function is set by determining if the copy_function is the function copy2 or copy. If so the srcentry is passed to the copy_function. If the user passes a custom copy_function to copytree, this function will ever become only the srcname and not the srcentry. To summarize it: The integrated copy_functions get the srcentry and custom copy_functions get the srcname. But what is if the custom copy_function is a edited copy2 function or needs the srcentry? In order to fix this was my idea to have a parameter to control if the custom copy_function get the srcentry or a srcname. Please write me if there is anything misconception in my thoughts or other objections? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 13:05:05 2019 From: report at bugs.python.org (SilentGhost) Date: Sat, 23 Feb 2019 18:05:05 +0000 Subject: [issue36094] When using an SMTP SSL connection,, get ValueError. In-Reply-To: <1550943841.97.0.129283187576.issue36094@roundup.psfhosted.org> Message-ID: <1550945105.35.0.413000938068.issue36094@roundup.psfhosted.org> Change by SilentGhost : ---------- stage: patch review -> type: resource usage -> behavior versions: +Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 13:05:23 2019 From: report at bugs.python.org (SilentGhost) Date: Sat, 23 Feb 2019 18:05:23 +0000 Subject: [issue36094] When using an SMTP SSL connection,, get ValueError. In-Reply-To: <1550943841.97.0.129283187576.issue36094@roundup.psfhosted.org> Message-ID: <1550945123.03.0.750215997114.issue36094@roundup.psfhosted.org> Change by SilentGhost : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 13:08:25 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 23 Feb 2019 18:08:25 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1550945305.2.0.0764057493443.issue35813@roundup.psfhosted.org> Giampaolo Rodola' added the comment: > Side note: I?m the author of the sysv_ipc package you found, as well as the posix_ipc package. Sorry, I didn't realize it was you. > Not true. A manager started by one process can be connected to by another process that is not a child. This is covered in the docs here: https://docs.python.org/3/library/multiprocessing.html#using-a-remote-manager Ah nice! OK then. With this + Philip's explanation on why shmat()/shmdt() are not needed I guess I ran out of API-related complaints now. =) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 13:15:43 2019 From: report at bugs.python.org (Sanyam Khurana) Date: Sat, 23 Feb 2019 18:15:43 +0000 Subject: [issue4502] Allowing get_pre_input_hook from Readline In-Reply-To: <1228268977.11.0.20813106029.issue4502@psf.upfronthosting.co.za> Message-ID: <1550945743.92.0.824147002903.issue4502@roundup.psfhosted.org> Sanyam Khurana added the comment: I'm working on applying this patch cleanly and writing a test for this. However, it seems I'm unable to import `readline` in compiled version of Python. I'm trying to provide a path to the installation of readline in my system using LDFLAGS, and then reconfiguring and recompiling, but seems like it didn't work. Can someone provide me a pointer here, please? ---------- assignee: -> CuriousLearner nosy: +CuriousLearner versions: +Python 3.8 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 13:27:06 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 23 Feb 2019 18:27:06 +0000 Subject: [issue1054041] Python doesn't exit with proper resultcode on SIGINT Message-ID: <1550946426.0.0.831345248679.issue1054041@roundup.psfhosted.org> Change by Gregory P. Smith : ---------- pull_requests: +12029 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 13:35:56 2019 From: report at bugs.python.org (Eric Snow) Date: Sat, 23 Feb 2019 18:35:56 +0000 Subject: [issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h In-Reply-To: <1549069628.87.0.454232469964.issue35886@roundup.psfhosted.org> Message-ID: <1550946956.08.0.00817078992212.issue35886@roundup.psfhosted.org> Eric Snow added the comment: New changeset be3b295838547bba267eb08434b418ef0df87ee0 by Eric Snow in branch 'master': bpo-35886: Make PyInterpreterState an opaque type in the public API. (GH-11731) https://github.com/python/cpython/commit/be3b295838547bba267eb08434b418ef0df87ee0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 13:36:41 2019 From: report at bugs.python.org (Eric Snow) Date: Sat, 23 Feb 2019 18:36:41 +0000 Subject: [issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h In-Reply-To: <1549069628.87.0.454232469964.issue35886@roundup.psfhosted.org> Message-ID: <1550947001.35.0.968894699762.issue35886@roundup.psfhosted.org> Change by Eric Snow : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 13:40:56 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 23 Feb 2019 18:40:56 +0000 Subject: [issue36085] Enable better DLL resolution In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org> Message-ID: <1550947256.76.0.109633973075.issue36085@roundup.psfhosted.org> Steve Dower added the comment: > Even better would be official python/Microsoft support for a CLI version of depends.exe like ldd on linux The dumpbin.exe tool with /IMPORTS is a good start, and I've definitely wrapped it in Python before to do this kind of analysis (not reproducibly, yet...). Doing this kind of analysis live is oddly tough, but there may be an ETW provider that a debug hook could enable to get more of a trace. Again, we're deep in third-party tool territory, not a change to core CPython. Certainly if we can drop support for base Windows 7 we will document how to use more recent OS support via whatever we add. Though to a certain extent those hitting problems are going deep enough that reading the MSDN docs will have to be mandatory (at least for those who want to know "why"). I really don't want to have to reproduce those docs and make them guaranteed Python semantics. > will annoy developers whose code base is full of `os.environ['PATH']` games. Perhaps the solution should come with a deprecation warning when setting `os.environ['PATH']`. Yeah, this is the downside of changing anything at all, though of course since resolving DLLs via PATH is already broken, those developers are already annoyed ;) And we can't add warning that wouldn't annoy those who legitimately modify PATH for process launches. So I think it's mostly about providing a supported path for those developers to be able to port their code when they discover it's broken. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 13:43:51 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 23 Feb 2019 18:43:51 +0000 Subject: [issue1054041] Python doesn't exit with proper resultcode on SIGINT Message-ID: <1550947431.72.0.827269711215.issue1054041@roundup.psfhosted.org> Gregory P. Smith added the comment: New changeset 06babb24225d41a76e4aee975380294ca1ee1d7c by Gregory P. Smith in branch 'master': bpo-1054041: Add What's New docs. (GH-11999) https://github.com/python/cpython/commit/06babb24225d41a76e4aee975380294ca1ee1d7c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 13:44:58 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 23 Feb 2019 18:44:58 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1550947498.73.0.445896180351.issue35813@roundup.psfhosted.org> Raymond Hettinger added the comment: Any objections to getting this patch applied today so that it will be in the second alpha? Of course, further adjustments can still be made afterwards if needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 13:59:26 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sat, 23 Feb 2019 18:59:26 +0000 Subject: [issue35512] patch.dict resolves in_dict eagerly (should be late resolved) In-Reply-To: <1544993007.41.0.788709270274.issue35512@psf.upfronthosting.co.za> Message-ID: <1550948366.08.0.559835268328.issue35512@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- keywords: +patch pull_requests: +12030 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 14:39:17 2019 From: report at bugs.python.org (Brandt Bucher) Date: Sat, 23 Feb 2019 19:39:17 +0000 Subject: [issue36095] Better NaN sorting. Message-ID: <1550950757.55.0.405574866511.issue36095@roundup.psfhosted.org> New submission from Brandt Bucher : Sorting sequences containing NaN values produces an incompletely sorted result. Further, because of the complexity of the timsort, this incomplete sort often silently produces unintuitive, unstable-seeming results that are extremely sensitive to the ordering of the inputs: >>> sorted([3, 1, 2, float('nan'), 2.0, 2, 2.0]) [1, 2, 2.0, 2.0, 3, nan, 2] >>> sorted(reversed([3, 1, 2, float('nan'), 2.0, 2, 2.0])) [1, 2.0, 2, 2.0, nan, 2, 3] The patch I have provided addresses these issues, including for lists containing nested lists/tuples with NaN values. Specifically, it stably sorts NaNs to the end of the list with no changes to the timsort itself (just the element-wise comparison functions): >>> sorted([3, 1, 2, float('nan'), 2.0, 2, 2.0]) [1, 2, 2.0, 2, 2.0, 3, nan] >>> sorted([[3], [1], [2], [float('nan')], [2.0], [2], [2.0]]) [[1], [2], [2.0], [2], [2.0], [3], [nan]] It also includes a new regression test for this behavior. Some other benefits to this patch: * These changes generally result in a sorting performance improvement across data types. The largest increases here are for nested lists, since we add a new unsafe_list_compare function. Other speed increases are due to safe_object_compare's delegation to unsafe comparison functions for objects of the same type. Specifically, the speed impact (positive is faster, negative is slower) is between: * -3% and +3% (10 elements, no PGO) * 0% and +4% (10 elements, PGO) * 0% and +9% (1000 elements, no PGO) * -1% and +9% (1000 elements, PGO) * The current weird NaN-sorting behavior is not documented, so this is not a breaking change. * IEEE754 compliance is maintained. The result is still a stable (arguably, more stable), nondecreasing ordering of the original list. ---------- components: Interpreter Core messages: 336401 nosy: brandtbucher priority: normal severity: normal status: open title: Better NaN sorting. type: behavior versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 14:39:36 2019 From: report at bugs.python.org (Brandt Bucher) Date: Sat, 23 Feb 2019 19:39:36 +0000 Subject: [issue36095] Better NaN sorting. In-Reply-To: <1550950757.55.0.405574866511.issue36095@roundup.psfhosted.org> Message-ID: <1550950776.31.0.373336737969.issue36095@roundup.psfhosted.org> Change by Brandt Bucher : ---------- keywords: +patch pull_requests: +12031 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 14:39:56 2019 From: report at bugs.python.org (Eric Snow) Date: Sat, 23 Feb 2019 19:39:56 +0000 Subject: [issue35724] Check for main interpreter when checking for "main" thread (for signal handling) In-Reply-To: <1547240687.08.0.242313450509.issue35724@roundup.psfhosted.org> Message-ID: <1550950796.32.0.968130890784.issue35724@roundup.psfhosted.org> Change by Eric Snow : ---------- pull_requests: -11124 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 14:46:23 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sat, 23 Feb 2019 19:46:23 +0000 Subject: [issue36095] Better NaN sorting. In-Reply-To: <1550950757.55.0.405574866511.issue36095@roundup.psfhosted.org> Message-ID: <1550951183.3.0.574126136853.issue36095@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +rhettinger, tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 14:58:39 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Sat, 23 Feb 2019 19:58:39 +0000 Subject: [issue36095] Better NaN sorting. In-Reply-To: <1550950757.55.0.405574866511.issue36095@roundup.psfhosted.org> Message-ID: <1550951919.51.0.505703298377.issue36095@roundup.psfhosted.org> Cheryl Sabella added the comment: This has been brought up in the past, for example, see #12286. ---------- nosy: +cheryl.sabella _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 15:08:51 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Sat, 23 Feb 2019 20:08:51 +0000 Subject: =?utf-8?q?=5Bissue36083=5D_Misformated_manpage=3A_--check-hash-based-pycs?= =?utf-8?b?IMK0ZGVmYXVsdMK0fMK0YWx3YXlzwrR8wrRuZXZlcsK0?= In-Reply-To: <1550860963.76.0.541506927126.issue36083@roundup.psfhosted.org> Message-ID: <1550952531.52.0.786985635338.issue36083@roundup.psfhosted.org> Cheryl Sabella added the comment: Thanks for the report, Miro! Adding Benjamin Peterson to the nosy, since that was his commit. I'd wait until he comments before making a PR. ---------- nosy: +benjamin.peterson, cheryl.sabella _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 16:01:31 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Sat, 23 Feb 2019 21:01:31 +0000 Subject: [issue36094] When using an SMTP SSL connection,, get ValueError. In-Reply-To: <1550943841.97.0.129283187576.issue36094@roundup.psfhosted.org> Message-ID: <1550955691.55.0.911436015831.issue36094@roundup.psfhosted.org> Cheryl Sabella added the comment: tyrone-zhao, thank you for the report and the detail on the commit. Adding @christian.heimes to the nosylist as he added change this under issue19785 and @dstufft as he modified it to be `self._host`. ---------- nosy: +cheryl.sabella, christian.heimes, dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 16:14:28 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 Feb 2019 21:14:28 +0000 Subject: [issue36095] Better NaN sorting. In-Reply-To: <1550950757.55.0.405574866511.issue36095@roundup.psfhosted.org> Message-ID: <1550956468.56.0.276810560869.issue36095@roundup.psfhosted.org> Serhiy Storchaka added the comment: Does it work for subclasses of float? For other floating point types like numpy.float32? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 16:17:27 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Sat, 23 Feb 2019 21:17:27 +0000 Subject: [issue36090] spelling error in PEP219 introduction In-Reply-To: <1550892807.64.0.358542044817.issue36090@roundup.psfhosted.org> Message-ID: <1550956647.01.0.404877078387.issue36090@roundup.psfhosted.org> Cheryl Sabella added the comment: Yes, ???, Karthikeyan, or Joannah, please open an issue on the PEPs repo and then add the link here and close this issue. ???, if you're interested in submitting a PR, the process is similar on the PEPs repo, so feel free to work on this issue there. Also, there have been some older issues that are for PEPs, but were created before there was an issues list to report them on, so if you run into one of them while triaging, just do the same. Thanks! ---------- nosy: +cheryl.sabella _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 16:49:42 2019 From: report at bugs.python.org (Brandt Bucher) Date: Sat, 23 Feb 2019 21:49:42 +0000 Subject: [issue36095] Better NaN sorting. In-Reply-To: <1550950757.55.0.405574866511.issue36095@roundup.psfhosted.org> Message-ID: <1550958582.94.0.684834092963.issue36095@roundup.psfhosted.org> Brandt Bucher added the comment: As a design decision, I consciously chose "no". However, it would be straightforward to make the change to support float subclasses: #define ISNAN(N) (N->ob_type == &PyFloat_Type && Py_IS_NAN(PyFloat_AsDouble(N))) becomes #define ISNAN(N) (PyFloat_Check(N) && Py_IS_NAN(PyFloat_AsDouble(N))) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 16:53:15 2019 From: report at bugs.python.org (mattip) Date: Sat, 23 Feb 2019 21:53:15 +0000 Subject: [issue36085] Enable better DLL resolution In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org> Message-ID: <1550958795.05.0.0852135743547.issue36085@roundup.psfhosted.org> mattip added the comment: > legitimately modify PATH for process launches Correct me if I'm wrong, don't process launches use the `env` kwarg for Popen, not the raw os.environ['PATH']? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 16:59:21 2019 From: report at bugs.python.org (Henry Chen) Date: Sat, 23 Feb 2019 21:59:21 +0000 Subject: [issue36091] clean up async generator from types module In-Reply-To: <1550902037.39.0.489582604413.issue36091@roundup.psfhosted.org> Message-ID: <1550959161.6.0.880969392097.issue36091@roundup.psfhosted.org> Henry Chen added the comment: As it happens @cheryl.sabella has created a very useful data set of which files are impacted by open PRs: https://github.com/csabella/pulls and as of 2019-02-18, the only open PR that relates to Lib/types.py is https://github.com/python/cpython/pull/5068 on an unrelated matter ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 17:24:46 2019 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 23 Feb 2019 22:24:46 +0000 Subject: =?utf-8?q?=5Bissue36083=5D_Misformated_manpage=3A_--check-hash-based-pycs?= =?utf-8?b?IMK0ZGVmYXVsdMK0fMK0YWx3YXlzwrR8wrRuZXZlcsK0?= In-Reply-To: <1550952531.52.0.786985635338.issue36083@roundup.psfhosted.org> Message-ID: <698ce2de-4477-430e-b9ee-24ddf283581a@www.fastmail.com> Benjamin Peterson added the comment: A PR would be welcome. On Sat, Feb 23, 2019, at 12:08, Cheryl Sabella wrote: > > Cheryl Sabella added the comment: > > Thanks for the report, Miro! Adding Benjamin Peterson to the nosy, > since that was his commit. I'd wait until he comments before making a > PR. > > ---------- > nosy: +benjamin.peterson, cheryl.sabella > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 17:40:49 2019 From: report at bugs.python.org (Eric Snow) Date: Sat, 23 Feb 2019 22:40:49 +0000 Subject: [issue35724] Check for main interpreter when checking for "main" thread (for signal handling) In-Reply-To: <1547240687.08.0.242313450509.issue35724@roundup.psfhosted.org> Message-ID: <1550961649.52.0.412555221541.issue35724@roundup.psfhosted.org> Eric Snow added the comment: New changeset 64d6cc826dacebc2493b1bb5e8cb97828eb76f81 by Eric Snow in branch 'master': bpo-35724: Explicitly require the main interpreter for signal-handling. (GH-11530) https://github.com/python/cpython/commit/64d6cc826dacebc2493b1bb5e8cb97828eb76f81 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 17:41:49 2019 From: report at bugs.python.org (Eric Snow) Date: Sat, 23 Feb 2019 22:41:49 +0000 Subject: [issue35724] Check for main interpreter when checking for "main" thread (for signal handling) In-Reply-To: <1547240687.08.0.242313450509.issue35724@roundup.psfhosted.org> Message-ID: <1550961709.39.0.743424478335.issue35724@roundup.psfhosted.org> Change by Eric Snow : ---------- assignee: -> eric.snow resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 17:42:07 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 23 Feb 2019 22:42:07 +0000 Subject: [issue36095] Better NaN sorting. In-Reply-To: <1550950757.55.0.405574866511.issue36095@roundup.psfhosted.org> Message-ID: <1550961727.93.0.918807491916.issue36095@roundup.psfhosted.org> Raymond Hettinger added the comment: -1 I am flat opposed to special casing the list.sort() code for the specific case of NaNs. This is an incorrect delegation of responsibility. The sorted objects are responsible for saying how they will sort and whether than is. deterministic. Note, float('NaN') isn't the only case. Sets objects only have a partial ordering. Also note that list.sort() isn't the only tool that compares objects. There is also min(), max(), heaps, bisect, etc. For the most part, we've able to keep those all it sync with one another by a clear separation of responsibilities (objects decide how they are compared versus tools that use comparisons). At the very least, this would need a python-ideas discussion. FWIW, the usual solution to this problem is to strip the NaN values using math.isnan(). ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 17:44:11 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 23 Feb 2019 22:44:11 +0000 Subject: [issue36018] Add a Normal Distribution class to the statistics module In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org> Message-ID: <1550961851.72.0.171746162628.issue36018@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 11c79531655a4aa3f82c20ff562ac571f40040cc by Raymond Hettinger in branch 'master': bpo-36018: Add the NormalDist class to the statistics module (GH-11973) https://github.com/python/cpython/commit/11c79531655a4aa3f82c20ff562ac571f40040cc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 17:46:55 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 23 Feb 2019 22:46:55 +0000 Subject: [issue36018] Add a Normal Distribution class to the statistics module In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org> Message-ID: <1550962015.84.0.731004462845.issue36018@roundup.psfhosted.org> Raymond Hettinger added the comment: Okay, it's in for the second alpha. Please continue to make API or implementation suggestions. Nothing is set in stone. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 17:53:18 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Sat, 23 Feb 2019 22:53:18 +0000 Subject: [issue36096] IDLE: Refactor class variables to instance variables in colorizer Message-ID: <1550962398.99.0.0484672984397.issue36096@roundup.psfhosted.org> New submission from Cheryl Sabella : >From Terry's comment on PR11472 for issue 35689: > I don't like the use of class variables to initialize volatile instance state variables. I think it confuses the code a bit. Better, I think, to put them in an `init_state` method called from `__init__`. (I am not sure if method could be used in tests.) Since the tests do not access the class vars directly on the class, they should not be affected. I am leaving this minor refactoring for another issue after merging the tests. Then we can modify the class docstring. ---------- assignee: terry.reedy components: IDLE messages: 336415 nosy: cheryl.sabella, terry.reedy priority: normal severity: normal status: open title: IDLE: Refactor class variables to instance variables in colorizer type: enhancement versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 17:56:12 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Sat, 23 Feb 2019 22:56:12 +0000 Subject: [issue36096] IDLE: Refactor class variables to instance variables in colorizer In-Reply-To: <1550962398.99.0.0484672984397.issue36096@roundup.psfhosted.org> Message-ID: <1550962572.64.0.487259534524.issue36096@roundup.psfhosted.org> Change by Cheryl Sabella : ---------- keywords: +patch pull_requests: +12033 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 18:23:44 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 23 Feb 2019 23:23:44 +0000 Subject: [issue36085] Enable better DLL resolution In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org> Message-ID: <1550964224.14.0.760978966986.issue36085@roundup.psfhosted.org> Steve Dower added the comment: > Correct me if I'm wrong, don't process launches use the `env` kwarg for Popen, not the raw os.environ['PATH']? If you don't provide env, it'll use the current process's environment, and if you do provide it without copying at least some entries, chances are your process won't start (and in general, you copy the current value and add to it). I've never seen anyone try to reset PATH here, nor would I recommend it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 18:37:55 2019 From: report at bugs.python.org (Davin Potts) Date: Sat, 23 Feb 2019 23:37:55 +0000 Subject: [issue36018] Add a Normal Distribution class to the statistics module In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org> Message-ID: <1550965075.57.0.309398923647.issue36018@roundup.psfhosted.org> Davin Potts added the comment: There is an inconsistency worth paying attention to in the choice of names of the input parameters. Currently in the statistics module, pvariance() accepts a parameter named "mu" and pstdev() and variance() each accept a parameter named "xbar". The docs describe both "mu" and "xbar" as "it should be the mean of data". I suggest it is worth rationalizing the names used within the statistics module for consistency before reusing "mu" or "xbar" or anything else in NormalDist. Using the names of mathematical symbols that are commonly used to represent a concept is potentially confusing because those symbols are not always *universally* used. For example, students are often introduced to new concepts in introductory mathematics texts where concepts such as "mean" appear in formulas and equations not as "mu" but as "xbar" or simply "m" or other simple (and hopefully "friendly") names/symbols. As a mathematician, if I am told a variable is named, "mu", I still feel the need to ask what it represents. Sure, I can try guessing based upon context but I will usually have more than one guess that I could make. Rather than continue down a path of using various mathematical-symbols-written-out-in-English-spelling, one alternative would be to use less ambiguous, more informative variable names such as "mean". It might be worth considering a change to the parameter names of "mu" and "sigma" in NormalDist to names like "mean" and "stddev", respectively. Or perhaps "mean" and "standard_deviation". Or perhaps "mean" and "variance" would be easier still (recognizing that variance can be readily computed from standard deviation in this particular context). In terms of consistency with other packages that users are likely to also use, scipy.stats functions/objects commonly refer to these concepts as "mean" and "var". I like the idea of making NormalDist readily approachable for students as well as those more familiar with these concepts. The offerings in scipy.stats are excellent but they are not always the most approachable things for new students of statistics. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 18:45:28 2019 From: report at bugs.python.org (Brandt Bucher) Date: Sat, 23 Feb 2019 23:45:28 +0000 Subject: [issue36095] Better NaN sorting. In-Reply-To: <1550950757.55.0.405574866511.issue36095@roundup.psfhosted.org> Message-ID: <1550965528.04.0.511342772121.issue36095@roundup.psfhosted.org> Brandt Bucher added the comment: Thanks for the feedback. I agree with you on the iffy delegation issue. However, this is problem that I feel deserves a fix... the behavior (silently producing garbage results) is just so un-pythonic. It?s been made clear in other issues that a warning isn?t right here, and sorting is guaranteed to use __lt__ (which NaN defines well for use in all other contexts). I honestly don?t see any other way. If that means fixing min, max, and friends too, I think it?s worth it. Special cases justify special-casing, especially when doing so doesn?t break the rules. NaN isn?t like any other value of any other type; It?s practically defined by its ability to ruin valid comparison operations, even with fellow floats, for which ordering is otherwise well-defined. For what it?s worth, I don?t know if anybody who?s tried to sort sets. Every Python programmer I know has blindly sorted floats at some point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 18:48:58 2019 From: report at bugs.python.org (Eric Snow) Date: Sat, 23 Feb 2019 23:48:58 +0000 Subject: [issue36097] Use only public C-API in _xxsubinterpreters module. Message-ID: <1550965738.11.0.154386205273.issue36097@roundup.psfhosted.org> New submission from Eric Snow : After discussions about our use of the public C-API in stdlib extension modules, I realized that I'd written the _xxsubinterpreters module using internal C-API. However, there's no reason not to stick to the public C-API. Fixing this will require adding a few new "private" functions. ---------- assignee: eric.snow components: Interpreter Core messages: 336419 nosy: eric.snow priority: normal severity: normal stage: needs patch status: open title: Use only public C-API in _xxsubinterpreters module. versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 18:55:05 2019 From: report at bugs.python.org (Eric Snow) Date: Sat, 23 Feb 2019 23:55:05 +0000 Subject: [issue36097] Use only public C-API in _xxsubinterpreters module. In-Reply-To: <1550965738.11.0.154386205273.issue36097@roundup.psfhosted.org> Message-ID: <1550966105.19.0.0501538486319.issue36097@roundup.psfhosted.org> Change by Eric Snow : ---------- keywords: +patch pull_requests: +12034 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 19:22:05 2019 From: report at bugs.python.org (MultiSosnooley) Date: Sun, 24 Feb 2019 00:22:05 +0000 Subject: [issue36098] asyncio: ssl client-server with "slow" read Message-ID: <1550967725.88.0.520289067216.issue36098@roundup.psfhosted.org> New submission from MultiSosnooley : Recently, some awesome contributors add support for implicit ssl mode for aioftp. But this produced some issues and one of them is not relevant to aioftp, but to asyncio. Here is link https://repl.it/@multisosnooley/asyncio-ssl-connection-with-slow-retreiving to reproduce. This code mimics one test of aioftp: filesystem slower, than socket write. Reduced code to reproduce use sleep for this purpose. So we have proper run without ssl (you can test this by removing ssl argument in server and client instantiation) and ?buggy? in case of ssl. After some digging in I realised, that someone calls connection_lost of ssl protocol before we read all data from transport. Data sent by server, but client have (looks like 64k) buffer and since there is no transport read fails. Also, I can say (with help of wireshark) that in case of non-ssl connection, tcp FIN initiated by server (as it should be), but in case of ssl ? FIN sent by client. Direct code to reproduce ``` import ssl import asyncio import trustme HOST = "127.0.0.1" PORT = 8021 ca = trustme.CA() server_cert = ca.issue_server_cert(HOST) ssl_server = ssl.create_default_context(ssl.Purpose.CLIENT_AUTH) server_cert.configure_cert(ssl_server) ssl_client = ssl.create_default_context(ssl.Purpose.SERVER_AUTH) ca.configure_trust(ssl_client) async def handler(reader, writer): writer.write(b"0" * 4 * 100 * 1024) await writer.drain() writer.close() await asyncio.sleep(1) print("handler done") async def client(): # reader, writer = await asyncio.open_connection(HOST, PORT) reader, writer = await asyncio.open_connection(HOST, PORT, ssl=ssl_client) count = 0 while True: data = await reader.read(8192) count += len(data) print(f"received {len(data)}, total {count}") if not data: break await asyncio.sleep(0.001) writer.close() loop = asyncio.get_event_loop() # start = asyncio.start_server(handler, HOST, PORT) start = asyncio.start_server(handler, HOST, PORT, ssl=ssl_server) server = loop.run_until_complete(start) loop.run_until_complete(client()) server.close() loop.run_until_complete(server.wait_closed()) ``` Output: ``` received 8192, total 8192 received 8192, total 16384 received 8192, total 24576 received 8192, total 32768 received 8192, total 40960 received 8192, total 49152 received 8192, total 57344 received 8192, total 65536 received 8192, total 73728 received 8192, total 81920 received 8192, total 90112 received 8192, total 98304 received 8192, total 106496 received 8192, total 114688 received 8192, total 122880 received 8192, total 131072 received 8192, total 139264 received 8192, total 147456 received 8192, total 155648 received 8192, total 163840 received 8192, total 172032 received 8192, total 180224 received 8192, total 188416 received 8192, total 196608 received 8192, total 204800 received 8192, total 212992 received 8192, total 221184 received 8192, total 229376 received 8192, total 237568 received 8192, total 245760 received 8192, total 253952 received 8192, total 262144 received 8192, total 270336 received 8192, total 278528 received 8192, total 286720 received 8192, total 294912 received 8192, total 303104 received 8192, total 311296 received 8192, total 319488 received 8192, total 327680 received 8192, total 335872 Traceback (most recent call last): File "slow-data-test.py", line 46, in loop.run_until_complete(client()) File "/home/poh/.pyenv/versions/3.6.7/lib/python3.6/asyncio/base_events.py", line 473, in run_until_complete return future.result() File "slow-data-test.py", line 33, in client data = await reader.read(8192) File "/home/poh/.pyenv/versions/3.6.7/lib/python3.6/asyncio/streams.py", line 640, in read self._maybe_resume_transport() File "/home/poh/.pyenv/versions/3.6.7/lib/python3.6/asyncio/streams.py", line 408, in _maybe_resume_transport self._transport.resume_reading() File "/home/poh/.pyenv/versions/3.6.7/lib/python3.6/asyncio/sslproto.py", line 351, in resume_reading self._ssl_protocol._transport.resume_reading() AttributeError: 'NoneType' object has no attribute 'resume_reading' ``` ---------- components: asyncio messages: 336420 nosy: MultiSosnooley, asvetlov, yselivanov priority: normal severity: normal status: open title: asyncio: ssl client-server with "slow" read type: behavior versions: Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 20:53:25 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 24 Feb 2019 01:53:25 +0000 Subject: [issue34211] Cygwin build broken due to use of &PyType_Type in static declaration in _abc module In-Reply-To: <1532451616.3.0.56676864532.issue34211@psf.upfronthosting.co.za> Message-ID: <1550973205.4.0.764901260938.issue34211@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +12035 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 20:55:01 2019 From: report at bugs.python.org (Inada Naoki) Date: Sun, 24 Feb 2019 01:55:01 +0000 Subject: [issue34211] Cygwin build broken due to use of &PyType_Type in static declaration in _abc module In-Reply-To: <1532451616.3.0.56676864532.issue34211@psf.upfronthosting.co.za> Message-ID: <1550973301.02.0.64587270627.issue34211@roundup.psfhosted.org> Change by Inada Naoki : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 21:55:59 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 24 Feb 2019 02:55:59 +0000 Subject: [issue36095] Better NaN sorting. In-Reply-To: <1550950757.55.0.405574866511.issue36095@roundup.psfhosted.org> Message-ID: <1550976959.98.0.121800747188.issue36095@roundup.psfhosted.org> Raymond Hettinger added the comment: This issue isn't sorting. The issue is with what NaNs do. You can propose to "fix" NaNs rather than special casing everything else in Python that compares two values. A NaN could be given a deterministic sort order relative to other floats (much as None used to compare less than everything else), That said, you'll find people who argue than NaNs aren't broken and are doing exactly what they're supposed to do. Please take this to python-ideas. From my point of view, the current proposal is a non-starter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 22:03:06 2019 From: report at bugs.python.org (Susan Su) Date: Sun, 24 Feb 2019 03:03:06 +0000 Subject: [issue21150] Add quick links table to argparse docs In-Reply-To: <1396558035.28.0.485991636726.issue21150@psf.upfronthosting.co.za> Message-ID: <1550977386.27.0.87470202545.issue21150@roundup.psfhosted.org> Change by Susan Su : ---------- keywords: +patch pull_requests: +12036 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 22:10:57 2019 From: report at bugs.python.org (Susan Su) Date: Sun, 24 Feb 2019 03:10:57 +0000 Subject: [issue33043] Add a 'Contributing to Docs' link at the bottom of docs.python.org In-Reply-To: <1520703028.47.0.467229070634.issue33043@psf.upfronthosting.co.za> Message-ID: <1550977857.65.0.337860859767.issue33043@roundup.psfhosted.org> Change by Susan Su : ---------- keywords: +patch pull_requests: +12037 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 22:17:37 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Sun, 24 Feb 2019 03:17:37 +0000 Subject: [issue36018] Add a Normal Distribution class to the statistics module In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org> Message-ID: <1550978257.49.0.158746146533.issue36018@roundup.psfhosted.org> Steven D'Aprano added the comment: Karthikeyan: thanks for the hint about Github. Raymond: thanks for the diff. Some comments: Why use object.__setattr__(self, 'mu', mu) instead of self.mu = mu in the __init__ method? Should __pos__ return a copy rather than the instance itself? The rest looks good to me, and I look forward to using it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 22:20:09 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Sun, 24 Feb 2019 03:20:09 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1550978409.6.0.16383486016.issue35813@roundup.psfhosted.org> Giampaolo Rodola' added the comment: IMHO given the size of the change and how quickly this evolved I would probably feel safer to mark the API as experimental (no pun intended, this is great work), at least in alpha2. I believe we now have a good explanation in the docs but it still needs to be integrated better into the larger, existing multiprocessing docs (I will try to add some comments on the PR tomorrow). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 22:34:39 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 24 Feb 2019 03:34:39 +0000 Subject: [issue24310] Idle documentation -- what to do if you do not see an underscore. In-Reply-To: <1432789747.51.0.656358937266.issue24310@psf.upfronthosting.co.za> Message-ID: <1550979279.59.0.284856949562.issue24310@roundup.psfhosted.org> Change by Terry J. Reedy : ---------- keywords: +patch pull_requests: +12038 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 22:39:59 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Sun, 24 Feb 2019 03:39:59 +0000 Subject: [issue36099] Clarify the difference between mu and xbar in the statistics documentation Message-ID: <1550979599.93.0.0625062939228.issue36099@roundup.psfhosted.org> New submission from Steven D'Aprano : The documentation isn't clear as to the difference between mu and xbar, and why one is used in variance and the other in pvariance. See #36018 for discussion. For the record: mu or ? is the population parameter, i.e. the mean of the entire population, if you could average every individual. xbar or x? is the mean of a sample. ---------- assignee: docs at python components: Documentation messages: 336424 nosy: docs at python, steven.daprano priority: normal severity: normal status: open title: Clarify the difference between mu and xbar in the statistics documentation type: behavior versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 22:41:08 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Sun, 24 Feb 2019 03:41:08 +0000 Subject: [issue36018] Add a Normal Distribution class to the statistics module In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org> Message-ID: <1550979668.05.0.985591670037.issue36018@roundup.psfhosted.org> Steven D'Aprano added the comment: Davin: the chice of using mu versus xbar was deliberate, as they represent different quantities: the population mean versus a sample mean. But reading over the docs with fresh eyes, I can now see that the distinction is not as clear as I intended. I think that changing the names now would be a breaking change, but even if it wasn't, I don't want to change the names. The distinction between population parameters (mu) and sample statistics (xbar) is important and I think the function parameters should reflect that. As for the new NormalDist class, we aren't limited by backwards compatibility, but I would still argue for the current names mu and sigma. As well as matching the population parameters of the distribution, they also matches the names used in calculators such as the TI Nspire and Casio Classpad (two very popular CAS calculators used by secondary school students). See #36099. If you would like to suggest some doc changes, please feel free to do so. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 22:51:27 2019 From: report at bugs.python.org (Ned Deily) Date: Sun, 24 Feb 2019 03:51:27 +0000 Subject: [issue24310] Idle documentation -- what to do if you do not see an underscore. In-Reply-To: <1432789747.51.0.656358937266.issue24310@psf.upfronthosting.co.za> Message-ID: <1550980287.34.0.389074472649.issue24310@roundup.psfhosted.org> Ned Deily added the comment: Sorry this issue slipped off my radar. Terry's new PR 12007 provides a more general documentation update such that the I no longer think the tcltk page should be updated. Removing myself. ---------- assignee: ned.deily -> versions: +Python 3.7, Python 3.8 -Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 22:51:45 2019 From: report at bugs.python.org (Ned Deily) Date: Sun, 24 Feb 2019 03:51:45 +0000 Subject: [issue24310] Idle documentation -- what to do if you do not see an underscore. In-Reply-To: <1432789747.51.0.656358937266.issue24310@psf.upfronthosting.co.za> Message-ID: <1550980305.18.0.237420213205.issue24310@roundup.psfhosted.org> Change by Ned Deily : ---------- nosy: -ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 22:55:57 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 24 Feb 2019 03:55:57 +0000 Subject: [issue24310] Idle documentation -- what to do if you do not see an underscore. In-Reply-To: <1432789747.51.0.656358937266.issue24310@psf.upfronthosting.co.za> Message-ID: <1550980557.2.0.537652852142.issue24310@roundup.psfhosted.org> Terry J. Reedy added the comment: I don't think one 4-years-old anonymous report missing essential details, and not verified since, is sufficient to drive a doc change, especially since the Mac installer has switched from recommending ActiveState 8.5.18 to installing our own compilation of 8.6.8. On my MacBook Air with Mohave and 3.7.2, I added 'p__g' to the top of IDLE settings dialog font tab text sample and looked for glitches with various fonts and sizes. The only thing I found was with Optima 13. The 'g' was the double loop ('eyeglasses') form and a bit of the bottom of the lower loop was gone or thin. It was still easily recognized and the 'p__' part was unaffected. I decided to document use of the font sample, including the possibility of changing face and size to avoid glitches. Since the procedure is generic for any platform or character, I did not specify Mac or 'p_g'. ---------- assignee: -> terry.reedy nosy: +ned.deily, terry.reedy stage: patch review -> versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 22:57:02 2019 From: report at bugs.python.org (Ned Deily) Date: Sun, 24 Feb 2019 03:57:02 +0000 Subject: [issue24310] Idle documentation -- what to do if you do not see an underscore. In-Reply-To: <1432789747.51.0.656358937266.issue24310@psf.upfronthosting.co.za> Message-ID: <1550980622.42.0.444256202046.issue24310@roundup.psfhosted.org> Change by Ned Deily : ---------- nosy: -ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 23:05:00 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 24 Feb 2019 04:05:00 +0000 Subject: [issue24310] Idle documentation -- what to do if you do not see an underscore. In-Reply-To: <1432789747.51.0.656358937266.issue24310@psf.upfronthosting.co.za> Message-ID: <1550981100.25.0.974444599222.issue24310@roundup.psfhosted.org> Terry J. Reedy added the comment: New changeset d610116a2e48b55788b62e11f2e6956af06b3de0 by Terry Jan Reedy in branch 'master': bpo-24310: Document IDLE settings dialog font tab sample (GH-12007) https://github.com/python/cpython/commit/d610116a2e48b55788b62e11f2e6956af06b3de0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 23:05:27 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 24 Feb 2019 04:05:27 +0000 Subject: [issue24310] Idle documentation -- what to do if you do not see an underscore. In-Reply-To: <1432789747.51.0.656358937266.issue24310@psf.upfronthosting.co.za> Message-ID: <1550981127.5.0.482634389097.issue24310@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +12039 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 23:08:18 2019 From: report at bugs.python.org (Davin Potts) Date: Sun, 24 Feb 2019 04:08:18 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1550981298.65.0.699436530529.issue35813@roundup.psfhosted.org> Davin Potts added the comment: New changeset e895de3e7f3cc2f7213b87621cfe9812ea4343f0 by Davin Potts in branch 'master': bpo-35813: Tests and docs for shared_memory (#11816) https://github.com/python/cpython/commit/e895de3e7f3cc2f7213b87621cfe9812ea4343f0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 23:14:13 2019 From: report at bugs.python.org (Davin Potts) Date: Sun, 24 Feb 2019 04:14:13 +0000 Subject: [issue35813] shared memory construct to avoid need for serialization between processes In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org> Message-ID: <1550981653.41.0.0252064712897.issue35813@roundup.psfhosted.org> Davin Potts added the comment: @Giampaolo: The docstring in the shared_memory module currently marks the API as experimental. (You read my mind...) I will start a new PR where we can work on the better-integration-into-the-larger-multiprocessing-docs and add comments there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 23:23:12 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 24 Feb 2019 04:23:12 +0000 Subject: [issue24310] Idle documentation -- what to do if you do not see an underscore. In-Reply-To: <1432789747.51.0.656358937266.issue24310@psf.upfronthosting.co.za> Message-ID: <1550982192.81.0.043319874435.issue24310@roundup.psfhosted.org> miss-islington added the comment: New changeset 38aea4131f57769d2c3d136b09172760db097605 by Miss Islington (bot) in branch '3.7': bpo-24310: Document IDLE settings dialog font tab sample (GH-12007) https://github.com/python/cpython/commit/38aea4131f57769d2c3d136b09172760db097605 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 23:29:54 2019 From: report at bugs.python.org (Ned Deily) Date: Sun, 24 Feb 2019 04:29:54 +0000 Subject: [issue33043] Add a 'Contributing to Docs' link at the bottom of docs.python.org In-Reply-To: <1520703028.47.0.467229070634.issue33043@psf.upfronthosting.co.za> Message-ID: <1550982594.33.0.802390771066.issue33043@roundup.psfhosted.org> Change by Ned Deily : ---------- nosy: +mdk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 23:36:01 2019 From: report at bugs.python.org (Tim Peters) Date: Sun, 24 Feb 2019 04:36:01 +0000 Subject: [issue36095] Better NaN sorting. In-Reply-To: <1550950757.55.0.405574866511.issue36095@roundup.psfhosted.org> Message-ID: <1550982961.8.0.68587912094.issue36095@roundup.psfhosted.org> Tim Peters added the comment: If we could roll back the clock, I'd impose a total ordering on floats in Python and supply some other way to spell 754's comparison operators (which users would have to ask for explicitly if they wanted to hassle with the near-useless and too-often-surprising "unordered" outcome). But, too late. As is, I don't want to mess up every context that _uses_ comparisons under the covers to make a special case out of NaNs. Floats are a partially ordered type, and live with the consequences. Which are approximately none for me ;-) I rarely have a use for a NaN to begin with, and never in a list I intend to sort. That said, the one thing that gives me pause is this line from numpy's docs: https://docs.scipy.org/doc/numpy/reference/generated/numpy.sort.html "In numpy versions >= 1.4.0 nan values are sorted to the end." But that's not the end of it: https://pandas.pydata.org/pandas-docs/stable/reference/api/pandas.DataFrame.sort_values.html ... na_position : {?first?, ?last?}, default ?last? first puts NaNs at the beginning, last puts NaNs at the end So people who go down this path can't get two steps before making a fork in the road ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 23 23:56:06 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 24 Feb 2019 04:56:06 +0000 Subject: [issue24310] Idle documentation -- what to do if you do not see an underscore. In-Reply-To: <1432789747.51.0.656358937266.issue24310@psf.upfronthosting.co.za> Message-ID: <1550984166.95.0.110858298987.issue24310@roundup.psfhosted.org> Change by Terry J. Reedy : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 00:26:13 2019 From: report at bugs.python.org (Davin Potts) Date: Sun, 24 Feb 2019 05:26:13 +0000 Subject: [issue36018] Add a Normal Distribution class to the statistics module In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org> Message-ID: <1550985973.71.0.474925237485.issue36018@roundup.psfhosted.org> Davin Potts added the comment: Steven: Your point about population versus sample makes sense and your point that altering their names would be a breaking change is especially important. I think that pretty well puts an end to my suggestion of alternative names and says the current pattern should be kept with NormalDist. I particularly like the idea of using the TI Nspire and Casio Classpad to guide or help confirm what symbols might be recognizable to secondary students or 1st year university students. Raymond: As an idea for examples demonstrating the code, what about an example where a plot of pdf is created, possibly for comparison with cdf? This would require something like matplotlib but would help to visually communicate the concepts of pdf, perhaps with different sigma values? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 00:30:53 2019 From: report at bugs.python.org (Davin Potts) Date: Sun, 24 Feb 2019 05:30:53 +0000 Subject: [issue36099] Clarify the difference between mu and xbar in the statistics documentation In-Reply-To: <1550979599.93.0.0625062939228.issue36099@roundup.psfhosted.org> Message-ID: <1550986253.13.0.87734656556.issue36099@roundup.psfhosted.org> Davin Potts added the comment: Without necessarily defining what each means, perhaps it is sufficient to change this clause in the docs: it should be the mean of data For pvariance() it could read as: it should be the *population* mean of data And for variance() it could read as: it should be the *sample* mean of data ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 00:56:41 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 24 Feb 2019 05:56:41 +0000 Subject: [issue36018] Add a Normal Distribution class to the statistics module In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org> Message-ID: <1550987801.68.0.789821688116.issue36018@roundup.psfhosted.org> Raymond Hettinger added the comment: > Why use object.__setattr__(self, 'mu', mu) instead of > self.mu = mu in the __init__ method? The idea was the instances should be immutable and hashable, but this added unnecessary complexity, so I took this out prior to the check in. > Should __pos__ return a copy rather than the instance itself? Yes. I'll fix that straight-way. ^ The chice of using mu versus xbar was deliberate I concur with that choice and also prefer to stick with mu and sigma: 1) It's too late to change it elsewhere in statistics and the random modules. 2) Having attribute names the same as function names in the same module is confusing. 3) I had already user tested this API in some Python courses. 4) The variable names match the various external sources I've linked to in the docs. 5) Python historically hasn't shied from greek letter names (math: pi tau gamma random: alpha, better, lambd, mu, sigma). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 00:59:22 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 24 Feb 2019 05:59:22 +0000 Subject: [issue36018] Add a Normal Distribution class to the statistics module In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org> Message-ID: <1550987962.87.0.526522959278.issue36018@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- pull_requests: +12040 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 01:00:41 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 24 Feb 2019 06:00:41 +0000 Subject: [issue36018] Add a Normal Distribution class to the statistics module In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org> Message-ID: <1550988041.47.0.309563788262.issue36018@roundup.psfhosted.org> Raymond Hettinger added the comment: Steven, Davin, Michael: Thanks for the encouragement and taking the time to review this code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 01:07:08 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 24 Feb 2019 06:07:08 +0000 Subject: [issue23205] Unit test needed for IDLE's GrepDialog.py's findfiles() In-Reply-To: <1420791360.73.0.110066531981.issue23205@psf.upfronthosting.co.za> Message-ID: <1550988428.03.0.522408520162.issue23205@roundup.psfhosted.org> Terry J. Reedy added the comment: Findfiles was more like os.walk than os.listdir. os.walk now uses os.scandir instead of os.listdir. From 3.7.2 doc: "By default, errors from the scandir() call are ignored. If optional argument onerror is specified, it should be a function; it will be called with one argument, an OSError instance. It can report the error to continue with the walk, or raise the exception to abort the walk. Note that the filename is available as the filename attribute of the exception object." We should delete the try: except: and pass in a function to print the name and error message. This could be done after getting a working patch. Defaults are not needed as findfiles is called with 3 positional args. The calling method should do the replacement of '' with os.curdir(). The patch must be incomplete as generators do not have a sort method. Replace the first 3 lines of grep_it with folder, filepat = os.path.split(path) if not folder: folder = os.curdir() filelist = sorted(findfiles(folder, filepat, self.recvar.get()) and replace 'list' with 'filelist' in the following code. Cheryl, grab the issue if you want to do this. ---------- nosy: +cheryl.sabella stage: patch review -> needs patch versions: +Python 3.7, Python 3.8 -Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 01:08:30 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 24 Feb 2019 06:08:30 +0000 Subject: [issue36099] Clarify the difference between mu and xbar in the statistics documentation In-Reply-To: <1550979599.93.0.0625062939228.issue36099@roundup.psfhosted.org> Message-ID: <1550988510.86.0.898137490477.issue36099@roundup.psfhosted.org> Raymond Hettinger added the comment: > Without necessarily defining what each means, > perhaps it is sufficient to change this clause in the docs +1 That is a simple way to address the concern. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 01:19:08 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 24 Feb 2019 06:19:08 +0000 Subject: [issue36018] Add a Normal Distribution class to the statistics module In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org> Message-ID: <1550989148.37.0.473428475166.issue36018@roundup.psfhosted.org> miss-islington added the comment: New changeset 79fbcc597dfd039d3261fffcb519b5ec5a18df9d by Miss Islington (bot) (Raymond Hettinger) in branch 'master': bpo-36018: Make __pos__ return a distinct instance of NormDist (GH-12009) https://github.com/python/cpython/commit/79fbcc597dfd039d3261fffcb519b5ec5a18df9d ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 01:31:46 2019 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 Feb 2019 06:31:46 +0000 Subject: [issue36045] builtins.help function is not much help with async functions In-Reply-To: <1550619387.23.0.907293710235.issue36045@roundup.psfhosted.org> Message-ID: <1550989906.5.0.894160134307.issue36045@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch pull_requests: +12041 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 01:31:59 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 24 Feb 2019 06:31:59 +0000 Subject: [issue23216] IDLE grep/find/replace source code needs docstrings In-Reply-To: <1420881306.22.0.52075806524.issue23216@psf.upfronthosting.co.za> Message-ID: <1550989919.54.0.00997290614422.issue23216@roundup.psfhosted.org> Terry J. Reedy added the comment: Current module names, docstring status, and note. grep - present, some args not doc'ed replace - spotty; do not repetively doc 'event=None' args search - ditto searchbase - present searchengine - present; do not separately docstring 'isxyz' wrappers Closing """ must be on line by itself. Parts of the patch should be usable at least as 'first drafts' for filling in missing docstrings. I am not sure whether better to edit diff (maybe after splitting into diffs for each module) and apply (I have never done this with git) or to edit modules directly. Cheryl, another one you might want to grab. ---------- nosy: +cheryl.sabella stage: patch review -> needs patch versions: +Python 3.7, Python 3.8 -Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 01:35:29 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 24 Feb 2019 06:35:29 +0000 Subject: [issue1442493] IDLE shell window gets very slow when displaying long lines Message-ID: <1550990129.15.0.778037710231.issue1442493@roundup.psfhosted.org> Change by Terry J. Reedy : ---------- versions: +Python 3.8 -Python 2.7, Python 3.3, Python 3.4, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 01:37:48 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 24 Feb 2019 06:37:48 +0000 Subject: [issue1442493] IDLE shell window gets very slow when displaying long lines Message-ID: <1550990268.21.0.22356539728.issue1442493@roundup.psfhosted.org> Terry J. Reedy added the comment: Squeezer was added last summer, and definitely helps, but I still intend to consider other points raised here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 02:03:58 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 24 Feb 2019 07:03:58 +0000 Subject: [issue24090] Add a "copy value to clipboard" option to the debugger In-Reply-To: <1430479248.08.0.880712455727.issue24090@psf.upfronthosting.co.za> Message-ID: <1550991838.26.0.407588627138.issue24090@roundup.psfhosted.org> Terry J. Reedy added the comment: The squeezer feature added last summer can be used to copy large output in Shell to the clipboard. '>>> [None]*10000' results in a squeezer label representing 750 wrapped lines. Note that pasting into a new editor disables it for awhile. (Editor does not wrap). Pasting into command prompt is not good either. Notepad++ handles the 60000 char line pretty well. I am not sure what I was thinking about a block copy in Shell. If a block is selected, it is easily copied. My thinking now is that large output in the debugger should be squeezed, at a much lower threashhold than in Shell. It is designed for values of, say, 40 chars or less. 'Large' values could then be copied to clipboard or displayed in a separate viewer. ---------- versions: +Python 3.8 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 02:04:35 2019 From: report at bugs.python.org (Ned Deily) Date: Sun, 24 Feb 2019 07:04:35 +0000 Subject: [issue27313] test case failures in test_widgets.ComboboxTest.of test_ttk_guionly on OS X with Cocoa Tk 8.5.18 In-Reply-To: <1465866380.0.0.570463827001.issue27313@psf.upfronthosting.co.za> Message-ID: <1550991875.65.0.922759883903.issue27313@roundup.psfhosted.org> Change by Ned Deily : ---------- keywords: +patch pull_requests: +12042 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 02:28:32 2019 From: report at bugs.python.org (Ned Deily) Date: Sun, 24 Feb 2019 07:28:32 +0000 Subject: [issue27313] test case failures in test_widgets.ComboboxTest.of test_ttk_guionly on OS X with Cocoa Tk 8.5.18 In-Reply-To: <1465866380.0.0.570463827001.issue27313@psf.upfronthosting.co.za> Message-ID: <1550993312.73.0.275977517078.issue27313@roundup.psfhosted.org> Ned Deily added the comment: New changeset aeca373b339e0ea9739536ce6b43bd90f3b89873 by Ned Deily in branch 'master': bpo-27313: Avoid test_ttk_guionly ComboboxTest fail with macOS Cocoa Tk (GH-12011) https://github.com/python/cpython/commit/aeca373b339e0ea9739536ce6b43bd90f3b89873 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 02:28:42 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 24 Feb 2019 07:28:42 +0000 Subject: [issue27313] test case failures in test_widgets.ComboboxTest.of test_ttk_guionly on OS X with Cocoa Tk 8.5.18 In-Reply-To: <1465866380.0.0.570463827001.issue27313@psf.upfronthosting.co.za> Message-ID: <1550993322.28.0.396749456452.issue27313@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +12043 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 02:28:52 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 24 Feb 2019 07:28:52 +0000 Subject: [issue27313] test case failures in test_widgets.ComboboxTest.of test_ttk_guionly on OS X with Cocoa Tk 8.5.18 In-Reply-To: <1465866380.0.0.570463827001.issue27313@psf.upfronthosting.co.za> Message-ID: <1550993332.15.0.980414090605.issue27313@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +12044 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 02:46:23 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 24 Feb 2019 07:46:23 +0000 Subject: [issue27313] test case failures in test_widgets.ComboboxTest.of test_ttk_guionly on OS X with Cocoa Tk 8.5.18 In-Reply-To: <1465866380.0.0.570463827001.issue27313@psf.upfronthosting.co.za> Message-ID: <1550994383.68.0.421300785645.issue27313@roundup.psfhosted.org> miss-islington added the comment: New changeset 25d20a6503f3cd4ff8cf0e8ee33eea2b1daa77a8 by Miss Islington (bot) in branch '3.7': bpo-27313: Avoid test_ttk_guionly ComboboxTest fail with macOS Cocoa Tk (GH-12011) https://github.com/python/cpython/commit/25d20a6503f3cd4ff8cf0e8ee33eea2b1daa77a8 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 02:54:26 2019 From: report at bugs.python.org (Ned Deily) Date: Sun, 24 Feb 2019 07:54:26 +0000 Subject: [issue26386] tkinter - Treeview - .selection_add and selection_toggle In-Reply-To: <1455813008.22.0.795281140329.issue26386@psf.upfronthosting.co.za> Message-ID: <1550994866.85.0.612910752563.issue26386@roundup.psfhosted.org> Change by Ned Deily : ---------- pull_requests: +12045 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 02:56:15 2019 From: report at bugs.python.org (Ned Deily) Date: Sun, 24 Feb 2019 07:56:15 +0000 Subject: [issue27313] test case failures in test_widgets.ComboboxTest.of test_ttk_guionly on OS X with Cocoa Tk 8.5.18 In-Reply-To: <1465866380.0.0.570463827001.issue27313@psf.upfronthosting.co.za> Message-ID: <1550994975.92.0.103940007726.issue27313@roundup.psfhosted.org> Ned Deily added the comment: New changeset 1dee4565fae9ccb54719fa99d7944c148736083a by Ned Deily (Miss Islington (bot)) in branch '3.6': bpo-27313: Avoid test_ttk_guionly ComboboxTest fail with macOS Cocoa Tk (GH-12011) (GH-12013) https://github.com/python/cpython/commit/1dee4565fae9ccb54719fa99d7944c148736083a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 03:04:21 2019 From: report at bugs.python.org (Ned Deily) Date: Sun, 24 Feb 2019 08:04:21 +0000 Subject: [issue26386] tkinter - Treeview - .selection_add and selection_toggle In-Reply-To: <1455813008.22.0.795281140329.issue26386@psf.upfronthosting.co.za> Message-ID: <1550995461.72.0.572673712989.issue26386@roundup.psfhosted.org> Ned Deily added the comment: New changeset 72ff2f7554e550762acaad805a8a0d456a29468a by Ned Deily in branch '2.7': bpo-26386: Re-enable missing widget testcases in test_ttk_guionly. (GH-12014) https://github.com/python/cpython/commit/72ff2f7554e550762acaad805a8a0d456a29468a ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 03:05:25 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Sun, 24 Feb 2019 08:05:25 +0000 Subject: [issue36099] Clarify the difference between mu and xbar in the statistics documentation In-Reply-To: <1550979599.93.0.0625062939228.issue36099@roundup.psfhosted.org> Message-ID: <1550995525.13.0.580743927507.issue36099@roundup.psfhosted.org> Steven D'Aprano added the comment: I'm happy with that doc change. If nobody objects, this might make an easy "Good first issue" for the upcoming sprint. Assigning to Cheryl to stop anyone else grabbing it. ---------- assignee: docs at python -> cheryl.sabella nosy: +cheryl.sabella _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 03:07:19 2019 From: report at bugs.python.org (Ned Deily) Date: Sun, 24 Feb 2019 08:07:19 +0000 Subject: [issue26386] tkinter - Treeview - .selection_add and selection_toggle In-Reply-To: <1455813008.22.0.795281140329.issue26386@psf.upfronthosting.co.za> Message-ID: <1550995639.83.0.999750549171.issue26386@roundup.psfhosted.org> Ned Deily added the comment: It looks like some testing code was inadvertently committed in the 2.7 branch fix causing only the Treeview testcases to be executed when test_ttk_gui_only is run. (I noticed this because a testcase was failing on other branches but not 2.7 although the tests are virtually identical.) PR 12014 fixes this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 03:22:22 2019 From: report at bugs.python.org (Ned Deily) Date: Sun, 24 Feb 2019 08:22:22 +0000 Subject: [issue27313] test case failures in test_widgets.ComboboxTest.of test_ttk_guionly on OS X with Cocoa Tk 8.5.18 In-Reply-To: <1465866380.0.0.570463827001.issue27313@psf.upfronthosting.co.za> Message-ID: <1550996542.43.0.0354848830259.issue27313@roundup.psfhosted.org> Change by Ned Deily : ---------- pull_requests: +12046 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 03:33:22 2019 From: report at bugs.python.org (Ned Deily) Date: Sun, 24 Feb 2019 08:33:22 +0000 Subject: [issue27313] test case failures in test_widgets.ComboboxTest.of test_ttk_guionly on OS X with Cocoa Tk 8.5.18 In-Reply-To: <1465866380.0.0.570463827001.issue27313@psf.upfronthosting.co.za> Message-ID: <1550997202.13.0.667950817454.issue27313@roundup.psfhosted.org> Ned Deily added the comment: New changeset b5213f4def07107952ce422ecc9d8508f4f084b4 by Ned Deily in branch '2.7': [2.7] bpo-27313: Avoid test_ttk_guionly ComboboxTest fail with macOS Cocoa Tk (GH-12015) https://github.com/python/cpython/commit/b5213f4def07107952ce422ecc9d8508f4f084b4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 03:40:52 2019 From: report at bugs.python.org (Ned Deily) Date: Sun, 24 Feb 2019 08:40:52 +0000 Subject: [issue27313] test case failures in test_widgets.ComboboxTest.of test_ttk_guionly on OS X with Cocoa Tk 8.5.18 In-Reply-To: <1465866380.0.0.570463827001.issue27313@psf.upfronthosting.co.za> Message-ID: <1550997652.77.0.353930155548.issue27313@roundup.psfhosted.org> Ned Deily added the comment: macOS Cocoa Tk returns an identity of 'Combobox.button' for the created Combobox widget at the tested location whereas the X-based Tk's (including the macOS X version) returns 'textarea'. Rather than try to further modify the test code, I just modified the test case to pass with either value when running on macOS. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 03:50:55 2019 From: report at bugs.python.org (Ned Deily) Date: Sun, 24 Feb 2019 08:50:55 +0000 Subject: [issue21359] IDLE Redo command accelerator acts as Undo with current OS X Cocoa Tk 8.5.15 In-Reply-To: <1398549164.45.0.802525173407.issue21359@psf.upfronthosting.co.za> Message-ID: <1550998255.6.0.743079129432.issue21359@roundup.psfhosted.org> Change by Ned Deily : ---------- assignee: ned.deily -> versions: +Python 2.7, Python 3.8 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 04:02:22 2019 From: report at bugs.python.org (Marcos Dione) Date: Sun, 24 Feb 2019 09:02:22 +0000 Subject: [issue36100] int() and float() should accept any isnumeric() digit Message-ID: <1550998942.15.0.168903018656.issue36100@roundup.psfhosted.org> New submission from Marcos Dione : Following https://blog.lerner.co.il/pythons-str-isdigit-vs-str-isnumeric/, we have this: Python 3.8.0a1+ (heads/master:001fee14e0, Feb 20 2019, 08:28:02) [GCC 8.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> '?????'.isnumeric() True >>> int('?????') Traceback (most recent call last): File "", line 1, in ValueError: invalid literal for int() with base 10: '?????' >>> float('?????') Traceback (most recent call last): File "", line 1, in ValueError: could not convert string to float: '?????' I think Reuven is right, these should be accepted as input. I just wonder if we should do the same for f.i. roman numerics... ---------- components: Library (Lib) messages: 336451 nosy: StyXman priority: normal severity: normal status: open title: int() and float() should accept any isnumeric() digit type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 04:13:35 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Sun, 24 Feb 2019 09:13:35 +0000 Subject: [issue35648] Add use_srcentry parameter to shutil.copytree() In-Reply-To: <1546506372.52.0.724433917377.issue35648@roundup.psfhosted.org> Message-ID: <1550999615.56.0.27633662667.issue35648@roundup.psfhosted.org> Giampaolo Rodola' added the comment: When user uses copy_function argument, the callback function should always receive path strings, both for consistency and for not breaking backward compatibility. This line: use_srcentry = copy_function is copy2 or copy_function is copy ...makes sure of that (only passes DirEntry instances around if copy_function is not specified by user). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 04:36:23 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Sun, 24 Feb 2019 09:36:23 +0000 Subject: [issue33671] Efficient zero-copy for shutil.copy* functions (Linux, OSX and Win) In-Reply-To: <1527524243.69.0.682650639539.issue33671@psf.upfronthosting.co.za> Message-ID: <1551000983.41.0.327341534995.issue33671@roundup.psfhosted.org> Change by Giampaolo Rodola' : ---------- pull_requests: +12047 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 04:40:30 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Sun, 24 Feb 2019 09:40:30 +0000 Subject: [issue33671] Efficient zero-copy for shutil.copy* functions (Linux, OSX and Win) In-Reply-To: <1527524243.69.0.682650639539.issue33671@psf.upfronthosting.co.za> Message-ID: <1551001230.08.0.973613659201.issue33671@roundup.psfhosted.org> Change by Giampaolo Rodola' : ---------- pull_requests: -7528 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 04:40:56 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Sun, 24 Feb 2019 09:40:56 +0000 Subject: [issue33671] Efficient zero-copy for shutil.copy* functions (Linux, OSX and Win) In-Reply-To: <1527524243.69.0.682650639539.issue33671@psf.upfronthosting.co.za> Message-ID: <1551001256.81.0.0144482721302.issue33671@roundup.psfhosted.org> Change by Giampaolo Rodola' : ---------- pull_requests: -7529 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 04:41:10 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Sun, 24 Feb 2019 09:41:10 +0000 Subject: [issue33671] Efficient zero-copy for shutil.copy* functions (Linux, OSX and Win) In-Reply-To: <1527524243.69.0.682650639539.issue33671@psf.upfronthosting.co.za> Message-ID: <1551001270.86.0.531203853081.issue33671@roundup.psfhosted.org> Change by Giampaolo Rodola' : ---------- pull_requests: -7536 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 05:05:25 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Sun, 24 Feb 2019 10:05:25 +0000 Subject: [issue36100] int() and float() should accept any isnumeric() digit In-Reply-To: <1550998942.15.0.168903018656.issue36100@roundup.psfhosted.org> Message-ID: <1551002725.83.0.385571425891.issue36100@roundup.psfhosted.org> Steven D'Aprano added the comment: I think that analysis is wrong. The Wikipedia page describes the meaning of the Unicode Decimal/Digit/Numeric properties: https://en.wikipedia.org/wiki/Unicode_character_property#Numeric_values_and_types and the characters you show aren't appropriate for converting to ints: py> for c in '?????': ... print(unicodedata.name(c)) ... CJK UNIFIED IDEOGRAPH-4E00 CJK UNIFIED IDEOGRAPH-4E8C CJK UNIFIED IDEOGRAPH-4E09 CJK UNIFIED IDEOGRAPH-56DB CJK UNIFIED IDEOGRAPH-4E94 The first one, for example, is translated as "one; a, an; alone"; it is better read as the *word* one rather than the numeral 1. (Disclaimer: I am not a Chinese speaker and I welcome correction from an expert.) Likewise U+4E8C, translated as "two; twice". The blog post is factually wrong when it claims: "str.isdigit only returns True for what I said before, strings containing solely the digits 0-9." py> s = "\N{BENGALI DIGIT ONE}\N{BENGALI DIGIT TWO}" py> s.isdigit() True py> int(s) 12 So I think that there's nothing to do here (unless it is perhaps to add a FAQ about it, or improve the docs). ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 05:14:50 2019 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 24 Feb 2019 10:14:50 +0000 Subject: [issue36100] int() and float() should accept any isnumeric() digit In-Reply-To: <1550998942.15.0.168903018656.issue36100@roundup.psfhosted.org> Message-ID: <1551003290.31.0.342727250765.issue36100@roundup.psfhosted.org> Mark Dickinson added the comment: [Steven posted his answer while I was composing mine; posting mine anyway ...] I don't think this would make sense. There are lots of characters that can't be interpreted as a decimal digit but for which `isnumeric` nevertheless gives True. >>> s = "????" >>> for c in s: print(unicodedata.name(c)) ... CIRCLED NUMBER TWENTY THREE VULGAR FRACTION THREE FIFTHS NUMBER SEVENTEEN FULL STOP ROMAN NUMERAL TWELVE >>> s.isnumeric() True What value would you expect `int(s)` to have in this situation? Note that `int` and `float` already accept non-ASCII digits: >>> s = "?????????" >>> int(s) 123456789 >>> float(s) 123456789.0 ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 05:24:17 2019 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 24 Feb 2019 10:24:17 +0000 Subject: [issue36100] int() and float() should accept any isnumeric() digit In-Reply-To: <1550998942.15.0.168903018656.issue36100@roundup.psfhosted.org> Message-ID: <1551003857.44.0.22555181985.issue36100@roundup.psfhosted.org> Mark Dickinson added the comment: > What value would you expect `int(s)` to have in this situation? Actually, I guess that question was too easy. The value for `int(s)` should *obviously* be 23 * 1000 + (3/5) * 100 + 17 * 10 + 12 = 23242. I should have used ? instead of ?. Anyway, agreed with Steven that no change should be made here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 05:31:50 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sun, 24 Feb 2019 10:31:50 +0000 Subject: [issue36100] int() and float() should accept any isnumeric() digit In-Reply-To: <1550998942.15.0.168903018656.issue36100@roundup.psfhosted.org> Message-ID: <1551004310.02.0.906912622886.issue36100@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Not a unicode expert but searching along the lines there was a note added on issue10610 that int() is supported for characters of 'Nd' category. So to check if a string can be converted to integer with help of int() I should be using str.isdecimal() instead of str.isnumeric() ? https://docs.python.org/3/library/stdtypes.html#numeric-types-int-float-complex > The numeric literals accepted include the digits 0 to 9 or any Unicode equivalent (code points with the Nd property). See http://www.unicode.org/Public/10.0.0/ucd/extracted/DerivedNumericType.txt for a complete list of code points with the Nd property. >>> [unicodedata.category(c) for c in '?????'] ['Lo', 'Lo', 'Lo', 'Lo', 'Lo'] >>> [unicodedata.category(c) for c in '\N{BENGALI DIGIT ONE}\N{BENGALI DIGIT TWO}'] ['Nd', 'Nd'] ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 05:37:48 2019 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 24 Feb 2019 10:37:48 +0000 Subject: [issue36095] Better NaN sorting. In-Reply-To: <1550950757.55.0.405574866511.issue36095@roundup.psfhosted.org> Message-ID: <1551004668.99.0.794466274705.issue36095@roundup.psfhosted.org> Mark Dickinson added the comment: Agreed with Raymond and Tim here that the sorting functionality itself shouldn't be special-cased for nans. [Tim] > So people who go down this path can't get two steps before making a fork in the road ;-) Well, both those solutions are wrong. *Clearly*, negative NaNs should be sorted to the start of the list, while positive NaNs are sorted to the end of the list. (Yes, I'm joking, but only a little bit: that's the result you'd get if you used IEEE 754's totalOrder to sort. But it's difficult to see how it would be useful in practice, given that people usually don't know about or care about the sign that their NaN has.) Maybe the solution would be to provide an official "math.total_order" function that can be used as a key: sorted(my_list_of_floats_with_nans_in_it, key=math.total_order) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 05:39:07 2019 From: report at bugs.python.org (Eryk Sun) Date: Sun, 24 Feb 2019 10:39:07 +0000 Subject: [issue36080] Ensurepip fails to install pip into a nested virtual environment (on Windows) In-Reply-To: <1550848781.33.0.584948420455.issue36080@roundup.psfhosted.org> Message-ID: <1551004747.28.0.449375829333.issue36080@roundup.psfhosted.org> Change by Eryk Sun : ---------- superseder: -> Creating venv from venv no longer works in 3.7.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 05:51:02 2019 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 24 Feb 2019 10:51:02 +0000 Subject: [issue35431] Add a function for computing binomial coefficients to the math module In-Reply-To: <1544131082.09.0.788709270274.issue35431@psf.upfronthosting.co.za> Message-ID: <1551005462.63.0.888638020107.issue35431@roundup.psfhosted.org> Mark Dickinson added the comment: > Can I get a consensus on weather math.perm() is needed? It's not, for the purposes of this issue. I think `math.perm` should be the subject of a separate issue and discussion, and a separate PR. That way it doesn't block completion of this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 05:57:40 2019 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 24 Feb 2019 10:57:40 +0000 Subject: [issue36100] int() and float() should accept any isnumeric() digit In-Reply-To: <1550998942.15.0.168903018656.issue36100@roundup.psfhosted.org> Message-ID: <1551005860.15.0.254276561879.issue36100@roundup.psfhosted.org> Mark Dickinson added the comment: > So to check if a string can be converted to integer with help of int() I should be using str.isdecimal() instead of str.isnumeric() ? Yes, I think that's correct. The characters matched by `str.isdecimal` are a subset of those matched by `str.isdigit`, which in turn are a subset of those matched by `str.isnumeric`. `int` and `float` required general category Nd, which corresponds to `str.isdigit`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 05:58:35 2019 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 24 Feb 2019 10:58:35 +0000 Subject: [issue36100] int() and float() should accept any isnumeric() digit In-Reply-To: <1550998942.15.0.168903018656.issue36100@roundup.psfhosted.org> Message-ID: <1551005915.37.0.647754004452.issue36100@roundup.psfhosted.org> Mark Dickinson added the comment: > which corresponds to `str.isdigit`. Gah! That should have said: > which corresponds to `str.isdecimal`. Sorry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 06:07:41 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sun, 24 Feb 2019 11:07:41 +0000 Subject: [issue36100] int() and float() should accept any isnumeric() digit In-Reply-To: <1550998942.15.0.168903018656.issue36100@roundup.psfhosted.org> Message-ID: <1551006461.71.0.390771447441.issue36100@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: > `int` and `float` required general category Nd, which corresponds to `str.isdigit`. Sorry, did you mean str.isdecimal? since there could be a subset where isdigit is True and isdecimal returns False. >>> '\u00B2'.isdecimal() False >>> '\u00B2'.isdigit() True >>> import unicodedata >>> unicodedata.category('\u00B2') 'No' >>> int('\u00B2') Traceback (most recent call last): File "", line 1, in ValueError: invalid literal for int() with base 10: '?' Is this worth an FAQ or an addition to the existing note on int that specifies characters should belong to 'Nd' category to add a note that str.isdecimal should return True ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 06:13:40 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Sun, 24 Feb 2019 11:13:40 +0000 Subject: [issue36100] int() and float() should accept any isnumeric() digit In-Reply-To: <1551006461.71.0.390771447441.issue36100@roundup.psfhosted.org> Message-ID: <20190224111329.GT4465@ando.pearwood.info> Steven D'Aprano added the comment: On Sun, Feb 24, 2019 at 11:07:41AM +0000, Karthikeyan Singaravelan wrote: > Is this worth an FAQ or an addition to the existing note on int that > specifies characters should belong to 'Nd' category to add a note that > str.isdecimal should return True Yes, I think that there should be a FAQ about the differences between isdigit, isdecimal and isnumeric, pointing to the relevant Unicode documentation. I would also like to see a briefer note added to each of the string methods docstrings as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 06:27:48 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Sun, 24 Feb 2019 11:27:48 +0000 Subject: [issue36099] Clarify the difference between mu and xbar in the statistics documentation In-Reply-To: <1550979599.93.0.0625062939228.issue36099@roundup.psfhosted.org> Message-ID: <1551007668.42.0.00444897367431.issue36099@roundup.psfhosted.org> Cheryl Sabella added the comment: Great! Thank you, Steven. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 06:43:31 2019 From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=) Date: Sun, 24 Feb 2019 11:43:31 +0000 Subject: =?utf-8?q?=5Bissue36083=5D_Misformated_manpage=3A_--check-hash-based-pycs?= =?utf-8?b?IMK0ZGVmYXVsdMK0fMK0YWx3YXlzwrR8wrRuZXZlcsK0?= In-Reply-To: <1550860963.76.0.541506927126.issue36083@roundup.psfhosted.org> Message-ID: <1551008611.09.0.503315273098.issue36083@roundup.psfhosted.org> Change by Miro Hron?ok : ---------- keywords: +patch pull_requests: +12048 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 06:44:36 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sun, 24 Feb 2019 11:44:36 +0000 Subject: [issue36100] int() and float() should accept any isnumeric() digit In-Reply-To: <1550998942.15.0.168903018656.issue36100@roundup.psfhosted.org> Message-ID: <1551008676.25.0.320923616218.issue36100@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Agreed, though str.isnumeric behavior might seem to be correct in terms of user who knows unicode internals the naming makes it easy to be used for a general user on trying to determine if the string can be used for int() without knowing unicode internals. I am not sure how this can be explained in simpler terms but it would be good if clarified in the docs to avoid confusion. There seems to be have been thread [0] in the past about multiple ways to check for a unicode literal to be number causing confusion. It adds more confusion on Python 2 where strings are not unicode by default. $ python2.7 Python 2.7.14 (default, Mar 12 2018, 13:54:56) [GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> '\u00B2'.isdigit() False >>> u'\u00B2'.isdigit() True [0] https://mail.python.org/pipermail/python-list/2012-May/624340.html ---------- versions: -Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 07:19:50 2019 From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=) Date: Sun, 24 Feb 2019 12:19:50 +0000 Subject: [issue36029] Use title-case HTTP header fields In-Reply-To: <1550529210.49.0.526576386821.issue36029@roundup.psfhosted.org> Message-ID: <1551010790.28.0.506178837703.issue36029@roundup.psfhosted.org> G?ry added the comment: Please see the changes and my reply in the PR. ---------- title: Use consistent case for HTTP header fields -> Use title-case HTTP header fields _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 07:39:23 2019 From: report at bugs.python.org (Marcos Dione) Date: Sun, 24 Feb 2019 12:39:23 +0000 Subject: [issue36100] int() and float() should accept any isnumeric() digit In-Reply-To: <1550998942.15.0.168903018656.issue36100@roundup.psfhosted.org> Message-ID: <1551011963.24.0.784641306814.issue36100@roundup.psfhosted.org> Marcos Dione added the comment: Thanks for all the examples, I'm convinced. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed versions: +Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 08:32:58 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Sun, 24 Feb 2019 13:32:58 +0000 Subject: [issue36100] Document the differences between str.isdigit, isdecimal and isnumeric In-Reply-To: <1550998942.15.0.168903018656.issue36100@roundup.psfhosted.org> Message-ID: <1551015178.54.0.39080661456.issue36100@roundup.psfhosted.org> Steven D'Aprano added the comment: I'm re-opening the ticket with a change of subject, because I think this should be treated as a documentation enhancement: - improve the docstrings for str.isdigit, isnumeric and isdecimal to make it clear what each does (e.g. what counts as a digit); - similarly improve the documentation for int and float? although the existing comment may be sufficient https://docs.python.org/3/library/stdtypes.html#numeric-types-int-float-complex - add a FAQ summarizing the situation. I don't think we need to worry about backporting the docs to Python 2, but if others disagree, I won't object. ---------- assignee: -> docs at python components: +Documentation -Library (Lib) nosy: +docs at python resolution: not a bug -> stage: resolved -> status: closed -> open title: int() and float() should accept any isnumeric() digit -> Document the differences between str.isdigit, isdecimal and isnumeric type: behavior -> enhancement versions: -Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 08:36:09 2019 From: report at bugs.python.org (Ma Lin) Date: Sun, 24 Feb 2019 13:36:09 +0000 Subject: [issue36101] remove non-ascii characters in docstring Message-ID: <1551015369.9.0.190424926201.issue36101@roundup.psfhosted.org> New submission from Ma Lin : replace ?(\u2019) with '(\x27) ---------- assignee: docs at python components: Documentation messages: 336468 nosy: Ma Lin, docs at python priority: normal severity: normal status: open title: remove non-ascii characters in docstring versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 08:38:03 2019 From: report at bugs.python.org (Ma Lin) Date: Sun, 24 Feb 2019 13:38:03 +0000 Subject: [issue36101] remove non-ascii characters in docstring In-Reply-To: <1551015369.9.0.190424926201.issue36101@roundup.psfhosted.org> Message-ID: <1551015483.2.0.887089349985.issue36101@roundup.psfhosted.org> Change by Ma Lin : ---------- keywords: +patch pull_requests: +12049 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 08:45:24 2019 From: report at bugs.python.org (Ma Lin) Date: Sun, 24 Feb 2019 13:45:24 +0000 Subject: [issue36101] remove non-ascii characters in docstring In-Reply-To: <1551015369.9.0.190424926201.issue36101@roundup.psfhosted.org> Message-ID: <1551015924.9.0.123952957151.issue36101@roundup.psfhosted.org> Ma Lin added the comment: only 3.8 branch has those non-ascii characters. ---------- versions: -Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 08:53:55 2019 From: report at bugs.python.org (Stefan Krah) Date: Sun, 24 Feb 2019 13:53:55 +0000 Subject: [issue23460] Decimals do not obey ':g' exponential notation formatting rules In-Reply-To: <1423847721.13.0.666007782647.issue23460@psf.upfronthosting.co.za> Message-ID: <1551016435.12.0.677323601592.issue23460@roundup.psfhosted.org> Stefan Krah added the comment: I just noticed that there are other differences, for example the "removal of trailing zeros" passage does not apply to Decimal: >>> format(Decimal("1.000000e-6"), "g") '0.000001000000' Perhaps it would be easier to have separate docs for float and decimal after all, or a long footnote for decimal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 09:05:33 2019 From: report at bugs.python.org (Stefan Krah) Date: Sun, 24 Feb 2019 14:05:33 +0000 Subject: [issue23460] Decimals do not obey ':g' exponential notation formatting rules In-Reply-To: <1423847721.13.0.666007782647.issue23460@psf.upfronthosting.co.za> Message-ID: <1551017133.71.0.687674515559.issue23460@roundup.psfhosted.org> Stefan Krah added the comment: On the other hand, the docs say "insignificant trailing zeros are removed from the significand", so technically it *is* correct, because trailing zeros are significant in decimal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 09:22:12 2019 From: report at bugs.python.org (Brandt Bucher) Date: Sun, 24 Feb 2019 14:22:12 +0000 Subject: [issue36095] Better NaN sorting. In-Reply-To: <1550950757.55.0.405574866511.issue36095@roundup.psfhosted.org> Message-ID: <1551018132.1.0.568364924477.issue36095@roundup.psfhosted.org> Brandt Bucher added the comment: One other idea I had considered was having a new magic method intended to be used for elementwise comparisons such as these (I?m thinking specifically of the old __cmp__/tp_compare). Sorting routines could check for this method on each element, but fall back on __lt__ if it is missing or NotImplemented. This would allow us to define an ordering for types independent of the rich comparison behavior. Simply defining it for floats and adding quick patches for list.sort/min/max/... would provide the language (and users) with that flexibility. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 09:55:49 2019 From: report at bugs.python.org (Zackery Spytz) Date: Sun, 24 Feb 2019 14:55:49 +0000 Subject: [issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h In-Reply-To: <1437054680.06.0.553712434946.issue24643@psf.upfronthosting.co.za> Message-ID: <1551020149.54.0.910369141528.issue24643@roundup.psfhosted.org> Change by Zackery Spytz : ---------- keywords: +patch pull_requests: +12050 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 10:01:08 2019 From: report at bugs.python.org (Zackery Spytz) Date: Sun, 24 Feb 2019 15:01:08 +0000 Subject: [issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h In-Reply-To: <1437054680.06.0.553712434946.issue24643@psf.upfronthosting.co.za> Message-ID: <1551020468.22.0.308572821225.issue24643@roundup.psfhosted.org> Zackery Spytz added the comment: I've created a PR for this issue. ---------- nosy: +ZackerySpytz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 10:08:13 2019 From: report at bugs.python.org (Paul Ganssle) Date: Sun, 24 Feb 2019 15:08:13 +0000 Subject: [issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h In-Reply-To: <1437054680.06.0.553712434946.issue24643@psf.upfronthosting.co.za> Message-ID: <1551020893.25.0.264426256111.issue24643@roundup.psfhosted.org> Change by Paul Ganssle : ---------- nosy: +p-ganssle _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 10:47:21 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Sun, 24 Feb 2019 15:47:21 +0000 Subject: [issue36090] spelling error in PEP219 introduction In-Reply-To: <1550892807.64.0.358542044817.issue36090@roundup.psfhosted.org> Message-ID: <1551023241.09.0.851023987664.issue36090@roundup.psfhosted.org> Joannah Nanjekye added the comment: I have opened an issue on the PEP repository : https://github.com/python/peps/issues/899 I will close this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 10:48:30 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Sun, 24 Feb 2019 15:48:30 +0000 Subject: [issue36090] spelling error in PEP219 introduction In-Reply-To: <1550892807.64.0.358542044817.issue36090@roundup.psfhosted.org> Message-ID: <1551023310.12.0.836820547358.issue36090@roundup.psfhosted.org> Change by Joannah Nanjekye : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 10:51:24 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Sun, 24 Feb 2019 15:51:24 +0000 Subject: [issue11776] Constructor signatures missing in types module documentation In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za> Message-ID: <1551023484.86.0.97975735126.issue11776@roundup.psfhosted.org> Cheryl Sabella added the comment: @mikehoy, would you be interested in converting your patch to a GitHub pull request? For others, please give Mike at least a week to respond before opening a PR with his changes. Thank you! ---------- nosy: +cheryl.sabella versions: +Python 3.7, Python 3.8 -Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 11:06:28 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sun, 24 Feb 2019 16:06:28 +0000 Subject: [issue32758] Stack overflow when parse long expression to AST In-Reply-To: <1517682171.17.0.467229070634.issue32758@psf.upfronthosting.co.za> Message-ID: <1551024388.93.0.815081982132.issue32758@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: This seems like an easy issue that the warnings in docs for ast need to be manually backported to 2.7 since miss Islington cannot cherry pick two PRs for 2.7 in https://bugs.python.org/issue32758#msg313511 . ---------- nosy: +Mariatta, cheryl.sabella, xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 11:07:19 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Sun, 24 Feb 2019 16:07:19 +0000 Subject: [issue36090] spelling error in PEP219 introduction In-Reply-To: <1550892807.64.0.358542044817.issue36090@roundup.psfhosted.org> Message-ID: <1551024439.53.0.699979129771.issue36090@roundup.psfhosted.org> Cheryl Sabella added the comment: Thanks, @nanjekyejoannah! ---------- resolution: -> third party _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 11:17:20 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Sun, 24 Feb 2019 16:17:20 +0000 Subject: [issue11776] Constructor signatures missing in types module documentation In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za> Message-ID: <1551025040.91.0.241396411938.issue11776@roundup.psfhosted.org> Emmanuel Arias added the comment: > For others, please give Mike at least a week to respond before opening a PR with his changes. Okas! ---------- nosy: +eamanu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 12:25:23 2019 From: report at bugs.python.org (Tz a) Date: Sun, 24 Feb 2019 17:25:23 +0000 Subject: [issue11776] Constructor signatures missing in types module documentation In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za> Message-ID: <1551029123.78.0.889870833532.issue11776@roundup.psfhosted.org> Change by Tz a : ---------- nosy: +Tz a _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 12:46:05 2019 From: report at bugs.python.org (flokX) Date: Sun, 24 Feb 2019 17:46:05 +0000 Subject: [issue35648] Add use_srcentry parameter to shutil.copytree() In-Reply-To: <1546506372.52.0.724433917377.issue35648@roundup.psfhosted.org> Message-ID: <1551030365.88.0.0438037477198.issue35648@roundup.psfhosted.org> flokX added the comment: Okay, than this behaviour is wanted. I only thought that the user should have more control about it, but you are right, only the path string is better to handle. I will close the PR. ---------- pull_requests: +12051 resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 12:49:12 2019 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 Feb 2019 17:49:12 +0000 Subject: [issue33529] [security] Infinite loop on folding email (_fold_as_ew()) if an header has no spaces In-Reply-To: <1526429548.63.0.682650639539.issue33529@psf.upfronthosting.co.za> Message-ID: <1551030552.51.0.931236844527.issue33529@roundup.psfhosted.org> Change by Roundup Robot : ---------- pull_requests: +12052 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 13:54:52 2019 From: report at bugs.python.org (Chris Withers) Date: Sun, 24 Feb 2019 18:54:52 +0000 Subject: [issue35512] patch.dict resolves in_dict eagerly (should be late resolved) In-Reply-To: <1544993007.41.0.788709270274.issue35512@psf.upfronthosting.co.za> Message-ID: <1551034492.3.0.45504007413.issue35512@roundup.psfhosted.org> Chris Withers added the comment: New changeset a875ea58b29fbf510f9790ae1653eeaa47dc0de8 by Chris Withers (Xtreak) in branch 'master': bpo-35512: Resolve string target to patch.dict decorator during function call GH#12000 https://github.com/python/cpython/commit/a875ea58b29fbf510f9790ae1653eeaa47dc0de8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 14:01:46 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 24 Feb 2019 19:01:46 +0000 Subject: [issue35512] patch.dict resolves in_dict eagerly (should be late resolved) In-Reply-To: <1544993007.41.0.788709270274.issue35512@psf.upfronthosting.co.za> Message-ID: <1551034906.25.0.21875586808.issue35512@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +12053 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 14:25:45 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 24 Feb 2019 19:25:45 +0000 Subject: [issue36018] Add a Normal Distribution class to the statistics module In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org> Message-ID: <1551036345.48.0.565296704687.issue36018@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- pull_requests: +12054 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 14:44:59 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 24 Feb 2019 19:44:59 +0000 Subject: [issue36018] Add a Normal Distribution class to the statistics module In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org> Message-ID: <1551037499.84.0.528627541296.issue36018@roundup.psfhosted.org> miss-islington added the comment: New changeset 9e456bc70e7bc9ee9726d356d7167457e585fd4c by Miss Islington (bot) (Raymond Hettinger) in branch 'master': bpo-36018: Add properties for mean and stdev (GH-12022) https://github.com/python/cpython/commit/9e456bc70e7bc9ee9726d356d7167457e585fd4c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 15:16:48 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Sun, 24 Feb 2019 20:16:48 +0000 Subject: [issue23205] Unit test needed for IDLE's GrepDialog.py's findfiles() In-Reply-To: <1420791360.73.0.110066531981.issue23205@psf.upfronthosting.co.za> Message-ID: <1551039408.33.0.0217208050505.issue23205@roundup.psfhosted.org> Cheryl Sabella added the comment: Sure, thanks. grep was on list to add tests to, so I'll take a look at this as well. Thanks! ---------- assignee: -> cheryl.sabella _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 15:18:11 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Sun, 24 Feb 2019 20:18:11 +0000 Subject: [issue23216] IDLE grep/find/replace source code needs docstrings In-Reply-To: <1420881306.22.0.52075806524.issue23216@psf.upfronthosting.co.za> Message-ID: <1551039491.9.0.671470927822.issue23216@roundup.psfhosted.org> Change by Cheryl Sabella : ---------- assignee: -> cheryl.sabella _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 15:53:15 2019 From: report at bugs.python.org (=?utf-8?q?Manuel_Cer=C3=B3n?=) Date: Sun, 24 Feb 2019 20:53:15 +0000 Subject: [issue29446] Improve tkinter 'import *' situation In-Reply-To: <1486243465.34.0.0929989866435.issue29446@psf.upfronthosting.co.za> Message-ID: <1551041595.34.0.289692117631.issue29446@roundup.psfhosted.org> Change by Manuel Cer?n : ---------- nosy: +ceronman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 15:55:22 2019 From: report at bugs.python.org (=?utf-8?q?Manuel_Cer=C3=B3n?=) Date: Sun, 24 Feb 2019 20:55:22 +0000 Subject: [issue25026] (FreeBSD/OSX) Fix fcntl module to accept 'unsigned long' type commands for ioctl(2). In-Reply-To: <1441694117.96.0.393183554729.issue25026@psf.upfronthosting.co.za> Message-ID: <1551041722.32.0.274393665557.issue25026@roundup.psfhosted.org> Change by Manuel Cer?n : ---------- nosy: +ceronman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 16:05:18 2019 From: report at bugs.python.org (=?utf-8?q?Manuel_Cer=C3=B3n?=) Date: Sun, 24 Feb 2019 21:05:18 +0000 Subject: [issue18299] Change script_helper to use universal_newlines=True in _assert_python In-Reply-To: <1372163490.54.0.858843080501.issue18299@psf.upfronthosting.co.za> Message-ID: <1551042318.74.0.270230950403.issue18299@roundup.psfhosted.org> Change by Manuel Cer?n : ---------- nosy: +ceronman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 16:37:32 2019 From: report at bugs.python.org (=?utf-8?q?Manuel_Cer=C3=B3n?=) Date: Sun, 24 Feb 2019 21:37:32 +0000 Subject: [issue21879] str.format() gives poor diagnostic on placeholder mismatch In-Reply-To: <1404052648.46.0.81950938275.issue21879@psf.upfronthosting.co.za> Message-ID: <1551044252.79.0.382801584535.issue21879@roundup.psfhosted.org> Change by Manuel Cer?n : ---------- nosy: +ceronman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 16:43:18 2019 From: report at bugs.python.org (Jacob Bundgaard) Date: Sun, 24 Feb 2019 21:43:18 +0000 Subject: [issue36086] Split IDLE into separate feature in Windows installer In-Reply-To: <1550883782.51.0.779365974532.issue36086@roundup.psfhosted.org> Message-ID: <1551044598.18.0.343684491275.issue36086@roundup.psfhosted.org> Change by Jacob Bundgaard : ---------- keywords: +patch pull_requests: +12055 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 16:45:45 2019 From: report at bugs.python.org (Jacob Bundgaard) Date: Sun, 24 Feb 2019 21:45:45 +0000 Subject: [issue36086] Split IDLE into separate feature in Windows installer In-Reply-To: <1550883782.51.0.779365974532.issue36086@roundup.psfhosted.org> Message-ID: <1551044745.22.0.309954475821.issue36086@roundup.psfhosted.org> Jacob Bundgaard added the comment: I'm glad to hear that you might consider a patch. I've created a draft pull request for this, but I still need to figure out how to encode the dependency from IDLE to Tcl/Tk in WIX. Do you have any insights? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 16:46:21 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 24 Feb 2019 21:46:21 +0000 Subject: [issue36018] Add a Normal Distribution class to the statistics module In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org> Message-ID: <1551044781.8.0.531778677031.issue36018@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:08:29 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:08:29 +0000 Subject: [issue12851] ctypes: getbuffer() never provides strides In-Reply-To: <1314611923.07.0.681765586879.issue12851@psf.upfronthosting.co.za> Message-ID: <1551046109.18.0.260112799592.issue12851@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:08:57 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:08:57 +0000 Subject: [issue1553375] Add traceback.print_full_exception() Message-ID: <1551046137.14.0.73526934487.issue1553375@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:09:25 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:09:25 +0000 Subject: [issue20265] Bring Windows docs up to date In-Reply-To: <1389757265.26.0.116885263001.issue20265@psf.upfronthosting.co.za> Message-ID: <1551046165.44.0.429708199803.issue20265@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:09:57 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:09:57 +0000 Subject: [issue13248] deprecated in 3.2/3.3, should be removed in 3.5 or ??? In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za> Message-ID: <1551046197.01.0.351143643479.issue13248@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:10:26 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:10:26 +0000 Subject: [issue23677] Mention dict and set comps in library reference In-Reply-To: <1426495855.1.0.56894829498.issue23677@psf.upfronthosting.co.za> Message-ID: <1551046226.56.0.763051217136.issue23677@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:11:31 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:11:31 +0000 Subject: [issue17055] ftplib.ftpcp test In-Reply-To: <1359326908.35.0.973015877338.issue17055@psf.upfronthosting.co.za> Message-ID: <1551046291.31.0.556299432156.issue17055@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:12:26 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:12:26 +0000 Subject: [issue23137] Python 2.7.9 test_gdb fails on CentOS 7 In-Reply-To: <1419983350.87.0.850193733351.issue23137@psf.upfronthosting.co.za> Message-ID: <1551046346.44.0.434078672274.issue23137@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:13:05 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Sun, 24 Feb 2019 22:13:05 +0000 Subject: [issue31035] Document order of firing callbacks added with Future.add_done_callback() In-Reply-To: <1500995618.96.0.99651815805.issue31035@psf.upfronthosting.co.za> Message-ID: <1551046385.21.0.239860950881.issue31035@roundup.psfhosted.org> Cheryl Sabella added the comment: The docs for asyncio were rewritten in September 2018. @socketpair, please take a look at the new documentation and update this ticket if any of your requests are now explained. If not, would you be able to provide more specific suggestions of what you would like to see included? Thanks! ---------- assignee: docs at python -> nosy: +cheryl.sabella versions: +Python 3.8 -Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:13:30 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:13:30 +0000 Subject: [issue9917] resource max value represented as signed when should be unsigned In-Reply-To: <1285119777.0.0.437398080007.issue9917@psf.upfronthosting.co.za> Message-ID: <1551046410.0.0.178767092563.issue9917@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:13:56 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:13:56 +0000 Subject: [issue18161] call fchdir if subprocess.Popen(cwd=integer|fileobject) In-Reply-To: <1370634042.31.0.748329507458.issue18161@psf.upfronthosting.co.za> Message-ID: <1551046436.15.0.314307036734.issue18161@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:14:24 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:14:24 +0000 Subject: [issue20923] Explain ConfigParser 'valid section name' and .SECTCRE In-Reply-To: <1394806905.89.0.637343755468.issue20923@psf.upfronthosting.co.za> Message-ID: <1551046464.56.0.410583572083.issue20923@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:16:35 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:16:35 +0000 Subject: [issue8304] time.strftime() and Unicode characters on Windows In-Reply-To: <1270307324.04.0.0348018847246.issue8304@psf.upfronthosting.co.za> Message-ID: <1551046595.38.0.608119422188.issue8304@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:17:04 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:17:04 +0000 Subject: [issue15347] IDLE - does not close if the debugger was active In-Reply-To: <1342207963.58.0.539607447258.issue15347@psf.upfronthosting.co.za> Message-ID: <1551046624.98.0.952845296995.issue15347@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:22:09 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Sun, 24 Feb 2019 22:22:09 +0000 Subject: [issue23677] Mention dict and set comps in library reference In-Reply-To: <1426495855.1.0.56894829498.issue23677@psf.upfronthosting.co.za> Message-ID: <1551046929.02.0.963003410551.issue23677@roundup.psfhosted.org> Cheryl Sabella added the comment: Assigning to @Mariatta for the CPython mentored sprint. ---------- assignee: docs at python -> Mariatta nosy: +Mariatta, cheryl.sabella stage: patch review -> needs patch versions: +Python 3.7, Python 3.8 -Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:23:49 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:23:49 +0000 Subject: [issue12790] doctest.testmod does not run tests in functools.partial functions In-Reply-To: <1313812473.15.0.9197967798.issue12790@psf.upfronthosting.co.za> Message-ID: <1551047029.1.0.572936529468.issue12790@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:24:18 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:24:18 +0000 Subject: [issue18769] argparse remove subparser In-Reply-To: <1376757040.66.0.700111900917.issue18769@psf.upfronthosting.co.za> Message-ID: <1551047058.66.0.51347053497.issue18769@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:25:17 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:25:17 +0000 Subject: [issue7897] Support parametrized tests in unittest In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za> Message-ID: <1551047117.82.0.104461957381.issue7897@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:35:12 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:35:12 +0000 Subject: [issue5714] http.server._url_collapse_path should live elsewhere In-Reply-To: <1239063845.81.0.120232947257.issue5714@psf.upfronthosting.co.za> Message-ID: <1551047712.26.0.237708066854.issue5714@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:35:56 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:35:56 +0000 Subject: [issue18906] Create a way to always run tests in subprocesses within regrtest In-Reply-To: <1378142237.02.0.163660197957.issue18906@psf.upfronthosting.co.za> Message-ID: <1551047756.5.0.227321702401.issue18906@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:36:29 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:36:29 +0000 Subject: [issue21506] Windows MSI installer should mklink (symlink) python.exe to python2.7.exe In-Reply-To: <1400067370.68.0.607872004364.issue21506@psf.upfronthosting.co.za> Message-ID: <1551047789.42.0.227713175305.issue21506@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:37:46 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:37:46 +0000 Subject: [issue678264] test_resource fails when file size is limited Message-ID: <1551047866.67.0.704720099527.issue678264@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:38:57 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:38:57 +0000 Subject: [issue1471934] Python libcrypt build problem on Solaris 8, 9, 10 and OpenSolaris Message-ID: <1551047937.9.0.993690132399.issue1471934@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:39:40 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:39:40 +0000 Subject: [issue16473] quopri module differences in quoted-printable text with whitespace In-Reply-To: <1352928126.09.0.115783436578.issue16473@psf.upfronthosting.co.za> Message-ID: <1551047980.47.0.817039322462.issue16473@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:40:16 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:40:16 +0000 Subject: [issue17750] allow the testsuite to run in the installed location In-Reply-To: <1366108780.66.0.667292537865.issue17750@psf.upfronthosting.co.za> Message-ID: <1551048016.12.0.500077104954.issue17750@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:41:34 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:41:34 +0000 Subject: [issue7687] Bluetooth support untested In-Reply-To: <1263367703.76.0.187821272753.issue7687@psf.upfronthosting.co.za> Message-ID: <1551048094.21.0.924490598733.issue7687@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:42:34 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:42:34 +0000 Subject: [issue18697] Unify arguments names in Unicode object C API documentation In-Reply-To: <1376074126.58.0.40251146149.issue18697@psf.upfronthosting.co.za> Message-ID: <1551048154.86.0.644179801431.issue18697@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:43:10 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:43:10 +0000 Subject: [issue19905] Add 128-bit integer support to ctypes In-Reply-To: <1386295654.39.0.271762839295.issue19905@psf.upfronthosting.co.za> Message-ID: <1551048190.64.0.38055766974.issue19905@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:43:39 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:43:39 +0000 Subject: [issue14534] Add means to mark unittest.TestCases as "do not load". In-Reply-To: <1333977053.0.0.776415854805.issue14534@psf.upfronthosting.co.za> Message-ID: <1551048219.76.0.0621702058689.issue14534@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:44:07 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:44:07 +0000 Subject: [issue993766] bdist_dumb and --relative on Windows fails Message-ID: <1551048247.82.0.915710848654.issue993766@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:44:55 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:44:55 +0000 Subject: [issue16296] Patch to fix building on Win32/64 under VS 2010 In-Reply-To: <1350842175.59.0.919553926658.issue16296@psf.upfronthosting.co.za> Message-ID: <1551048295.31.0.503216915163.issue16296@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:46:22 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:46:22 +0000 Subject: [issue6164] [AIX] Patch to correct the AIX C/C++ linker argument used for 'runtime_library_dirs' In-Reply-To: <1243876957.94.0.533443517724.issue6164@psf.upfronthosting.co.za> Message-ID: <1551048382.23.0.571161266838.issue6164@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:49:24 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Sun, 24 Feb 2019 22:49:24 +0000 Subject: [issue14534] Add means to mark unittest.TestCases as "do not load". In-Reply-To: <1333977053.0.0.776415854805.issue14534@psf.upfronthosting.co.za> Message-ID: <1551048564.67.0.565775761656.issue14534@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:52:29 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:52:29 +0000 Subject: [issue22211] Remove VMS specific code in expat.h & xmlrole.h In-Reply-To: <1408222450.15.0.0579194114943.issue22211@psf.upfronthosting.co.za> Message-ID: <1551048749.12.0.758268131582.issue22211@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:53:04 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:53:04 +0000 Subject: [issue3367] Uninitialized value read in parsetok.c In-Reply-To: <1216153264.95.0.467111480464.issue3367@psf.upfronthosting.co.za> Message-ID: <1551048784.59.0.26911662741.issue3367@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:53:30 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:53:30 +0000 Subject: [issue24322] Hundreds of linker warnings on Windows In-Reply-To: <1432892603.92.0.682917004344.issue24322@psf.upfronthosting.co.za> Message-ID: <1551048810.81.0.0346870803171.issue24322@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:53:58 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:53:58 +0000 Subject: [issue11352] Update cgi module doc In-Reply-To: <1298895261.86.0.965235067518.issue11352@psf.upfronthosting.co.za> Message-ID: <1551048838.18.0.401355488792.issue11352@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:54:55 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:54:55 +0000 Subject: [issue10009] Automated MSI installation does not work In-Reply-To: <1285963909.15.0.466947839123.issue10009@psf.upfronthosting.co.za> Message-ID: <1551048895.69.0.257639247929.issue10009@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:55:37 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:55:37 +0000 Subject: [issue14484] missing return in win32_kill? In-Reply-To: <1333462226.23.0.725280599354.issue14484@psf.upfronthosting.co.za> Message-ID: <1551048937.47.0.260353453292.issue14484@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:56:09 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:56:09 +0000 Subject: [issue13850] Summary tables for argparse add_argument options In-Reply-To: <1327384498.23.0.981832544617.issue13850@psf.upfronthosting.co.za> Message-ID: <1551048969.81.0.492826193725.issue13850@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:58:19 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:58:19 +0000 Subject: [issue22123] Provide a direct function for types.SimpleNamespace() In-Reply-To: <1406966548.11.0.912987884229.issue22123@psf.upfronthosting.co.za> Message-ID: <1551049099.36.0.292727518569.issue22123@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:58:29 2019 From: report at bugs.python.org (Tim Peters) Date: Sun, 24 Feb 2019 22:58:29 +0000 Subject: [issue36095] Better NaN sorting. In-Reply-To: <1550950757.55.0.405574866511.issue36095@roundup.psfhosted.org> Message-ID: <1551049109.6.0.721748992761.issue36095@roundup.psfhosted.org> Tim Peters added the comment: > *Clearly*, negative NaNs should be sorted to the start > of the list, while positive NaNs are sorted to the end > of the list. (Yes, I'm joking, but only a little bit: that's > the result you'd get if you used IEEE 754's totalOrder > to sort. So not a joke at all! If a revision of the standard mandates a specific total ordering, it's certain that people will eventually ask for it be supported. > But it's difficult to see how it would be useful in > practice, given that people usually don't know about > or care about the sign that their NaN has.) The standard "wastes" an enormous number of bit patterns on NaNs, catering to some hypothetical system that uses those bits to encode diagnostic information (e.g., maybe the source code line number of the operation that produced the NaN), and this is just one more "wasted" bit. If any implementation actually used any of these possibilities, I'm sure semi-plausible ;-) use cases would follow. I bet this was driven by implementation - it's _almost_ what you'd get if you viewed the float bit patterns as signed integers. Seems the only flaw with that is that the negative floats are in "reverse order" then. Which can be repaired easily enough; e.g., import struct def totkey(x, *, MASK=(1 << 63) - 1, pack=struct.pack): asint = int.from_bytes(pack(">d", x), "big", signed=True) if asint < 0: asint ^= MASK return asint Then xs = [2.0, 1.0, 0.0, -0.0, -1.0, -2.0, math.inf, -math.inf, math.nan, -math.nan] print(sorted(xs, key=totkey)) displays [nan, -inf, -2.0, -1.0, -0.0, 0.0, 1.0, 2.0, inf, nan] That makes negative NaNs smallest, positive NaNs largest, puts -0 before +0, and in all other respects I checked ;-) appears to match the totalOrder requirements. On most boxes, it will even consider (positive) signaling NaNs to "be smaller" than (positive) quiet NaNs, which totalOrder also seems to require (presumably again not because it's obviously useful, but because it _follows_ from a very simple implementation like the one above). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:58:51 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:58:51 +0000 Subject: [issue8075] Windows (Vista/7) install error when choosing to compile .py files In-Reply-To: <1267832622.74.0.429526645693.issue8075@psf.upfronthosting.co.za> Message-ID: <1551049131.42.0.870613902017.issue8075@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:59:21 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:59:21 +0000 Subject: [issue18173] Add MixedTypeKey to reprlib In-Reply-To: <1370786072.61.0.824503392112.issue18173@psf.upfronthosting.co.za> Message-ID: <1551049161.18.0.680749334054.issue18173@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 17:59:50 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 22:59:50 +0000 Subject: [issue13456] Providing a custom HTTPResponse class to HTTPConnection In-Reply-To: <1321988533.96.0.72454390842.issue13456@psf.upfronthosting.co.za> Message-ID: <1551049190.12.0.955059241597.issue13456@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 18:01:58 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 23:01:58 +0000 Subject: [issue15358] Test pkgutil.walk_packages in test_pkgutil instead of test_runpy In-Reply-To: <1342346071.33.0.869652246152.issue15358@psf.upfronthosting.co.za> Message-ID: <1551049318.24.0.600953745282.issue15358@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 18:02:42 2019 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 Feb 2019 23:02:42 +0000 Subject: [issue10308] Modules/getpath.c bugs In-Reply-To: <1288870063.75.0.834981100194.issue10308@psf.upfronthosting.co.za> Message-ID: <1551049362.27.0.885138299274.issue10308@roundup.psfhosted.org> Change by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 18:18:52 2019 From: report at bugs.python.org (Inada Naoki) Date: Sun, 24 Feb 2019 23:18:52 +0000 Subject: [issue36101] remove non-ascii characters in docstring In-Reply-To: <1551015369.9.0.190424926201.issue36101@roundup.psfhosted.org> Message-ID: <1551050332.4.0.468991848855.issue36101@roundup.psfhosted.org> Inada Naoki added the comment: New changeset 463572c8beb59fd9d6850440af48a5c5f4c0c0c9 by Inada Naoki (animalize) in branch 'master': bpo-36101: remove non-ascii characters in docstring (GH-12018) https://github.com/python/cpython/commit/463572c8beb59fd9d6850440af48a5c5f4c0c0c9 ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 18:20:06 2019 From: report at bugs.python.org (Inada Naoki) Date: Sun, 24 Feb 2019 23:20:06 +0000 Subject: [issue36101] remove non-ascii characters in docstring In-Reply-To: <1551015369.9.0.190424926201.issue36101@roundup.psfhosted.org> Message-ID: <1551050406.32.0.886867988286.issue36101@roundup.psfhosted.org> Inada Naoki added the comment: thanks ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 18:40:49 2019 From: report at bugs.python.org (Eric Snow) Date: Sun, 24 Feb 2019 23:40:49 +0000 Subject: [issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed. In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za> Message-ID: <1551051649.55.0.332575125789.issue33608@roundup.psfhosted.org> Eric Snow added the comment: New changeset ef4ac967e2f3a9a18330cc6abe14adb4bc3d0465 by Eric Snow in branch 'master': bpo-33608: Factor out a private, per-interpreter _Py_AddPendingCall(). (GH-11617) https://github.com/python/cpython/commit/ef4ac967e2f3a9a18330cc6abe14adb4bc3d0465 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 18:42:44 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 24 Feb 2019 23:42:44 +0000 Subject: [issue11776] Constructor signatures missing in types module documentation In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za> Message-ID: <1551051764.71.0.291746304507.issue11776@roundup.psfhosted.org> Terry J. Reedy added the comment: I agree that we should properly document all of the types, even if belately. A PR is premature until we agree in more detail what 'properly' means. The most recent patch 'complete-patch...' has multiple errors and needs major revision, to the point that a new patch will be 'based on' rather than 'an edit' of Hoy's work. 1. The table needs to be explained. It should not just duplicate explanation elsewhere in the doc. Currently it only lists classes with Python signatures that can be instantiated from Python. It might make more sense to have a table of types that cannot be instantiated, and not list them elsewhere. The table seems to be a response to an unreferenced and incomplete (and therefore non-authoritative) suggestion. We should do what seems best now. Perhaps there should be two tables for non-callable and callable (from Python) types. The former without individual entries, the latter with, and with links thereto in the table. Or perhaps skip tables and just make two subsections for the two groups of types/classes. There are not currently alphabetical anyway. 2. The types that cannot be instantiated have wrong doc. "+ This does support direct creation." This seems to be Nick's "This type does support direct creation " However, 'this' referred to ModuleType, not to the 'do not call' type he listed previously. Correct would be "This type cannot be instantiated by calling it." and I would prefer saying this just once and listing the modules in a table with short explanation. Table intro might be "The following types cannot be instantiated by calling them from Python. Hence no argument signature is given." 3. The wrong initial comments are followed by the wrong "Please see :class:`XyzType` (imp.new_module). Again, these are derived from Nick's comment that only applies to callable ModuleType. The reference to imp is obsolete as imp is deprecated. The imp.new_module(name) entry says to use importlib.util.module_from_spec(spec), but a name is not spec. We don't need to add this; see below. 4. The patch does not touch the ModuleType entry, currently (3.7 online): class types.ModuleType(name, doc=None) The type of modules. Constructor takes the name of the module to be created and optionally its docstring. Note Use importlib.util.module_from_spec() to create a new module if you wish to set the various import-controlled attributes. This looks fine. The only thing we might change is the awkward 'Constructor takes' to 'A call takes' or something. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 18:46:44 2019 From: report at bugs.python.org (Inada Naoki) Date: Sun, 24 Feb 2019 23:46:44 +0000 Subject: [issue33671] Efficient zero-copy for shutil.copy* functions (Linux, OSX and Win) In-Reply-To: <1527524243.69.0.682650639539.issue33671@psf.upfronthosting.co.za> Message-ID: <1551052004.64.0.0847067829662.issue33671@roundup.psfhosted.org> Inada Naoki added the comment: New changeset 3b0abb019662e42070f1d6f7e74440afb1808f03 by Inada Naoki (Giampaolo Rodola) in branch 'master': bpo-33671: allow setting shutil.copyfile() bufsize globally (GH-12016) https://github.com/python/cpython/commit/3b0abb019662e42070f1d6f7e74440afb1808f03 ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 18:56:13 2019 From: report at bugs.python.org (Eric Snow) Date: Sun, 24 Feb 2019 23:56:13 +0000 Subject: [issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed. In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za> Message-ID: <1551052573.56.0.472349589399.issue33608@roundup.psfhosted.org> Change by Eric Snow : ---------- pull_requests: +12057 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 19:09:16 2019 From: report at bugs.python.org (Inada Naoki) Date: Mon, 25 Feb 2019 00:09:16 +0000 Subject: [issue35551] Encoding and alias issues In-Reply-To: <1545386892.27.0.788709270274.issue35551@psf.upfronthosting.co.za> Message-ID: <1551053356.87.0.923624625273.issue35551@roundup.psfhosted.org> Inada Naoki added the comment: Removing unused alias is OK. But I'm not sure about adding new alias. In encodings/ package, there are both of mac_centeuro.py and mac_latin2.py. Why alias is needed, without removing mac_centeuro.py? ---------- nosy: +inada.naoki versions: +Python 3.8 -Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 19:50:33 2019 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 25 Feb 2019 00:50:33 +0000 Subject: =?utf-8?q?=5Bissue36083=5D_Misformated_manpage=3A_--check-hash-based-pycs?= =?utf-8?b?IMK0ZGVmYXVsdMK0fMK0YWx3YXlzwrR8wrRuZXZlcsK0?= In-Reply-To: <1550860963.76.0.541506927126.issue36083@roundup.psfhosted.org> Message-ID: <1551055833.31.0.625697561761.issue36083@roundup.psfhosted.org> Benjamin Peterson added the comment: New changeset 16323cb2c3d315e02637cebebdc5ff46be32ecdf by Benjamin Peterson (Miro Hron?ok) in branch 'master': closes bpo-36083: Fix formatting of the manpage Synopsis. (GH-12017) https://github.com/python/cpython/commit/16323cb2c3d315e02637cebebdc5ff46be32ecdf ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 19:50:43 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 25 Feb 2019 00:50:43 +0000 Subject: =?utf-8?q?=5Bissue36083=5D_Misformated_manpage=3A_--check-hash-based-pycs?= =?utf-8?b?IMK0ZGVmYXVsdMK0fMK0YWx3YXlzwrR8wrRuZXZlcsK0?= In-Reply-To: <1550860963.76.0.541506927126.issue36083@roundup.psfhosted.org> Message-ID: <1551055843.91.0.710312256534.issue36083@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +12058 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 19:56:15 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 25 Feb 2019 00:56:15 +0000 Subject: =?utf-8?q?=5Bissue36083=5D_Misformated_manpage=3A_--check-hash-based-pycs?= =?utf-8?b?IMK0ZGVmYXVsdMK0fMK0YWx3YXlzwrR8wrRuZXZlcsK0?= In-Reply-To: <1550860963.76.0.541506927126.issue36083@roundup.psfhosted.org> Message-ID: <1551056175.98.0.0712561917112.issue36083@roundup.psfhosted.org> miss-islington added the comment: New changeset ca5e6aaea5168bff274f3e98d7970bfa1bc366a2 by Miss Islington (bot) in branch '3.7': closes bpo-36083: Fix formatting of the manpage Synopsis. (GH-12017) https://github.com/python/cpython/commit/ca5e6aaea5168bff274f3e98d7970bfa1bc366a2 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 24 23:36:42 2019 From: report at bugs.python.org (BLKSerene) Date: Mon, 25 Feb 2019 04:36:42 +0000 Subject: [issue35551] Encoding and alias issues In-Reply-To: <1545386892.27.0.788709270274.issue35551@psf.upfronthosting.co.za> Message-ID: <1551069402.72.0.819604837698.issue35551@roundup.psfhosted.org> BLKSerene added the comment: I suppose that mac_centeuro can be removed since it is identical to mac_latin2, and there are already some aliases for mac_latin2. Then, mac_centeuro can be added as an alias for mac_latin2. I'm not sure about why latin_1 and iso8859_1 are both supported (they are identical). The doc says: "CPython implementation detail: Some common encodings can bypass the codecs lookup machinery to improve performance. These optimization opportunities are only recognized by CPython for a limited set of (case insensitive) aliases: utf-8, utf8, latin-1, latin1, iso-8859-1, iso8859-1, mbcs (Windows only), ascii, us-ascii, utf-16, utf16, utf-32, utf32, and the same using underscores instead of dashes. Using alternative aliases for these encodings may result in slower execution." Also not sure whether this would matter or not. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 00:12:54 2019 From: report at bugs.python.org (Inada Naoki) Date: Mon, 25 Feb 2019 05:12:54 +0000 Subject: [issue35551] Encoding and alias issues In-Reply-To: <1545386892.27.0.788709270274.issue35551@psf.upfronthosting.co.za> Message-ID: <1551071574.58.0.511911783404.issue35551@roundup.psfhosted.org> Inada Naoki added the comment: @lemburg I confirmed mac_latin1 and mac_centeuro are identical, even though they are generated from different sources. >>> from encodings import mac_latin2, mac_centeuro >>> mac_latin2.decoding_table == mac_centeuro.decoding_table True How do you think about removing mac_centeuro and adding an alias to mac_latin2? ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 00:15:49 2019 From: report at bugs.python.org (Martin Panter) Date: Mon, 25 Feb 2019 05:15:49 +0000 Subject: [issue36050] Why does http.client.HTTPResponse._safe_read use MAXAMOUNT In-Reply-To: <1550667343.87.0.589252473583.issue36050@roundup.psfhosted.org> Message-ID: <1551071749.92.0.397165530704.issue36050@roundup.psfhosted.org> Martin Panter added the comment: The 1 MiB limit was added for Issue 1296004; apparently some platforms were overallocating multiple buffers and running out of memory. I suspect the loop in "_safe_read" was inherited from Python 2, which has different kinds of file objects. The comments suggest it does partial reads. But the Python 3 code calls "socket.makefile" with "buffering" mode enabled by default. I agree it should be safe to read the total length in one go. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 01:22:15 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 25 Feb 2019 06:22:15 +0000 Subject: [issue22123] Provide a direct function for types.SimpleNamespace() In-Reply-To: <1406966548.11.0.912987884229.issue22123@psf.upfronthosting.co.za> Message-ID: <1551075735.95.0.835052661256.issue22123@roundup.psfhosted.org> Raymond Hettinger added the comment: Five years have passed with no one pushing this forward. During that time, types.SimpleNamespace() has diminished in popularity and dataclasses have risen as a better general purpose data holder. Marking this as closed. ---------- resolution: -> rejected stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 01:54:20 2019 From: report at bugs.python.org (Nathaniel Smith) Date: Mon, 25 Feb 2019 06:54:20 +0000 Subject: [issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h In-Reply-To: <1549069628.87.0.454232469964.issue35886@roundup.psfhosted.org> Message-ID: <1551077660.23.0.298611017273.issue35886@roundup.psfhosted.org> Nathaniel Smith added the comment: This broke cffi: gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -g -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -fPIC -DUSE__THREAD -DHAVE_SYNC_SYNCHRONIZE -I/opt/python/3.8-dev/include/python3.8m -c c/_cffi_backend.c -o build/temp.linux-x86_64-3.8/c/_cffi_backend.o In file included from c/cffi1_module.c:20:0, from c/_cffi_backend.c:7552: c/call_python.c: In function ?_get_interpstate_dict?: c/call_python.c:20:30: error: dereferencing pointer to incomplete type ?PyInterpreterState {aka struct _is}? builtins = tstate->interp->builtins; ^ error: command 'gcc' failed with exit status 1 I haven't investigated further but heads up. ---------- nosy: +arigo, njs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 02:49:01 2019 From: report at bugs.python.org (Armin Rigo) Date: Mon, 25 Feb 2019 07:49:01 +0000 Subject: [issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h In-Reply-To: <1549069628.87.0.454232469964.issue35886@roundup.psfhosted.org> Message-ID: <1551080941.15.0.781835897087.issue35886@roundup.psfhosted.org> Armin Rigo added the comment: Just so you know, when we look at the changes to CPython, the easiest fix is to add these lines in cffi: #if PY_VERSION_HEX >= 0x03080000 # define Py_BUILD_CORE # include "internal/pycore_pystate.h" # undef Py_BUILD_CORE #endif But if we're looking for a cleaner way to fix this, then cffi's needs could be covered by adding a general-purpose-storage dict to PyInterpreterState (like PyThreadState->dict, but per sub-interpreter instead of per thread), and an API function to get it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 03:11:47 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 Feb 2019 08:11:47 +0000 Subject: [issue33671] Efficient zero-copy for shutil.copy* functions (Linux, OSX and Win) In-Reply-To: <1527524243.69.0.682650639539.issue33671@psf.upfronthosting.co.za> Message-ID: <1551082307.3.0.59678144453.issue33671@roundup.psfhosted.org> STINNER Victor added the comment: shutil.COPY_BUFSIZE isn't documented. Is it a deliberate choice? https://docs.python.org/dev/library/shutil.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 04:03:37 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 Feb 2019 09:03:37 +0000 Subject: [issue36102] TestSharedMemory fails on AMD64 FreeBSD CURRENT Shared 3.x Message-ID: <1551085417.13.0.962588202568.issue36102@roundup.psfhosted.org> New submission from STINNER Victor : TestSharedMemory fails on AMD64 FreeBSD CURRENT Shared 3.x: * The tests should be skipped on this buildbot worker * Or the feature should be fixed on FreeBSD https://buildbot.python.org/all/#/builders/168/builds/617 Example: ERROR: test_shared_memory_ShareableList_basics (test.test_multiprocessing_forkserver.WithProcessesTestSharedMemory) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/_test_multiprocessing.py", line 3770, in test_shared_memory_ShareableList_basics sl = shared_memory.ShareableList( File "/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/multiprocessing/shared_memory.py", line 305, in __init__ self.shm = SharedMemory(name, create=True, size=requested_size) File "/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/multiprocessing/shared_memory.py", line 88, in __init__ self._fd = _posixshmem.shm_open( OSError: [Errno 22] Invalid argument: 'psm_f66c2bc7b9' Failures: ERROR: test_shared_memory_ShareableList_basics (test.test_multiprocessing_forkserver.WithProcessesTestSharedMemory) ERROR: test_shared_memory_ShareableList_pickling (test.test_multiprocessing_forkserver.WithProcessesTestSharedMemory) ERROR: test_shared_memory_SharedMemoryManager_basics (test.test_multiprocessing_forkserver.WithProcessesTestSharedMemory) ERROR: test_shared_memory_across_processes (test.test_multiprocessing_forkserver.WithProcessesTestSharedMemory) ERROR: test_shared_memory_basics (test.test_multiprocessing_forkserver.WithProcessesTestSharedMemory) ERROR: test_shared_memory_ShareableList_basics (test.test_multiprocessing_fork.WithProcessesTestSharedMemory) ERROR: test_shared_memory_ShareableList_pickling (test.test_multiprocessing_fork.WithProcessesTestSharedMemory) ERROR: test_shared_memory_SharedMemoryManager_basics (test.test_multiprocessing_fork.WithProcessesTestSharedMemory) ERROR: test_shared_memory_across_processes (test.test_multiprocessing_fork.WithProcessesTestSharedMemory) ERROR: test_shared_memory_basics (test.test_multiprocessing_fork.WithProcessesTestSharedMemory) ERROR: test_shared_memory_ShareableList_basics (test.test_multiprocessing_spawn.WithProcessesTestSharedMemory) ERROR: test_shared_memory_ShareableList_pickling (test.test_multiprocessing_spawn.WithProcessesTestSharedMemory) ERROR: test_shared_memory_SharedMemoryManager_basics (test.test_multiprocessing_spawn.WithProcessesTestSharedMemory) ERROR: test_shared_memory_across_processes (test.test_multiprocessing_spawn.WithProcessesTestSharedMemory) ERROR: test_shared_memory_basics (test.test_multiprocessing_spawn.WithProcessesTestSharedMemory) ---------- components: Tests messages: 336503 nosy: davin, giampaolo.rodola, pitrou, vstinner priority: normal severity: normal status: open title: TestSharedMemory fails on AMD64 FreeBSD CURRENT Shared 3.x versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 04:27:42 2019 From: report at bugs.python.org (Inada Naoki) Date: Mon, 25 Feb 2019 09:27:42 +0000 Subject: [issue29659] Expose the `length` arg from shutil.copyfileobj for public use In-Reply-To: <1488157044.73.0.933925559387.issue29659@psf.upfronthosting.co.za> Message-ID: <1551086862.35.0.232630823368.issue29659@roundup.psfhosted.org> Inada Naoki added the comment: bpo-33671 fixed this. ---------- resolution: -> fixed stage: test needed -> resolved status: open -> closed versions: +Python 3.8 -Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 04:27:56 2019 From: report at bugs.python.org (Inada Naoki) Date: Mon, 25 Feb 2019 09:27:56 +0000 Subject: [issue36103] Increase Message-ID: <1551086876.41.0.525070679929.issue36103@roundup.psfhosted.org> Change by Inada Naoki : ---------- nosy: inada.naoki priority: normal severity: normal status: open title: Increase _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 04:38:53 2019 From: report at bugs.python.org (Inada Naoki) Date: Mon, 25 Feb 2019 09:38:53 +0000 Subject: [issue36103] Increase shutil.COPY_BUFSIZE Message-ID: <1551087533.63.0.252770144463.issue36103@roundup.psfhosted.org> New submission from Inada Naoki : shutil.COPY_BUFSIZE is 16KiB on non-Windows platform. But it seems bit small for performance. As this article[1], 128KiB is the best performance on common system. [1]: https://eklitzke.org/efficient-file-copying-on-linux Another resource: EBS document [2] uses 128KiB I/O for throughput. [2]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.html Can we increase shutil.COPY_BUFSIZE to 128KiB by default? Note that 128KiB is small enough when comparing with Windows (1MB by default). ---------- components: +Library (Lib) title: Increase -> Increase shutil.COPY_BUFSIZE type: -> resource usage versions: +Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 05:02:12 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 Feb 2019 10:02:12 +0000 Subject: [issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h In-Reply-To: <1549069628.87.0.454232469964.issue35886@roundup.psfhosted.org> Message-ID: <1551088932.48.0.795155263877.issue35886@roundup.psfhosted.org> STINNER Victor added the comment: > This broke cffi: Well, that's not a surprise :-) It's a deliberate backward incompatible change. But that's where I suggested to test "popular C extensions" with a C API change before merging it. It's ok if issues are discovered later, but the author of backward incompatible C API changes should collaborate with popular C extension maintainers to help to deal with these issues. Can someone report the issue to cffi and post back the url to the bug here? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 05:10:23 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 Feb 2019 10:10:23 +0000 Subject: [issue10308] Modules/getpath.c bugs In-Reply-To: <1288870063.75.0.834981100194.issue10308@psf.upfronthosting.co.za> Message-ID: <1551089423.86.0.432533309006.issue10308@roundup.psfhosted.org> STINNER Victor added the comment: I reviewed getpath.diff: diff -pru Python-2.7/Modules/getpath.c Python-2.7/Modules/getpath.c --- Python-2.7/Modules/getpath.c +++ Python-2.7/Modules/getpath.c @@ -218,7 +218,7 @@ joinpath(char *buffer, char *stuff) if (n > MAXPATHLEN) Py_FatalError("buffer overflow in getpath.c's joinpath()"); k = strlen(stuff); - if (n + k > MAXPATHLEN) + if (k > MAXPATHLEN - n) k = MAXPATHLEN - n; strncpy(buffer+n, stuff, k); buffer[n+k] = '\0'; As I explained in a previous comment, this change is useless: "n+k" cannot overflow. @@ -229,10 +229,9 @@ joinpath(char *buffer, char *stuff) static void copy_absolute(char *path, char *p) { - if (p[0] == SEP) + if (p[0] == SEP || getcwd(path, MAXPATHLEN) == NULL) strcpy(path, p); else { - getcwd(path, MAXPATHLEN); if (p[0] == '.' && p[1] == SEP) p += 2; joinpath(path, p); The code changed in the meanwhile (in the master branch, in 3.7 maybe, I don't recall), getcwd() error is now checked in copy_absolute(): if (!_Py_wgetcwd(path, pathlen)) { /* unable to get the current directory */ wcscpy(path, p); return; } diff -pru Python-3.2a3/Modules/getpath.c Python-3.2a3/Modules/getpath.c --- Python-3.2a3/Modules/getpath.c +++ Python-3.2a3/Modules/getpath.c @@ -351,18 +351,18 @@ search_for_exec_prefix(wchar_t *argv0_pa else { char buf[MAXPATHLEN+1]; PyObject *decoded; - wchar_t rel_builddir_path[MAXPATHLEN+1]; - size_t n; n = fread(buf, 1, MAXPATHLEN, f); buf[n] = '\0'; fclose(f); decoded = PyUnicode_DecodeUTF8(buf, n, "surrogateescape"); if (decoded != NULL) { - n = PyUnicode_AsWideChar((PyUnicodeObject*)decoded, + wchar_t rel_builddir_path[MAXPATHLEN+1]; + Py_ssize_t k; + k = PyUnicode_AsWideChar((PyUnicodeObject*)decoded, rel_builddir_path, MAXPATHLEN); Py_DECREF(decoded); - if (n >= 0) { - rel_builddir_path[n] = L'\0'; + if (k >= 0) { + rel_builddir_path[k] = L'\0'; wcscpy(exec_prefix, argv0_path); joinpath(exec_prefix, rel_builddir_path); return -1; Again, the code changed in the meanwhile: wchar_t *rel_builddir_path; ... rel_builddir_path = _Py_DecodeUTF8_surrogateescape(buf, n); if (rel_builddir_path) { There is a new _Py_DecodeUTF8_surrogateescape() function which returns directly wchar_t* strings. I close the issue. -- Modules/getpath.c should be rewritten without global MAXPATHLEN limit. I rewrote the code to avoid global variables and pass buffer lengths in some functions. It's better but not perfect yet :-)) ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 05:12:46 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 Feb 2019 10:12:46 +0000 Subject: [issue34656] [CVE-2018-20406] memory exhaustion in Modules/_pickle.c:1393 In-Reply-To: <1536813527.13.0.956365154283.issue34656@psf.upfronthosting.co.za> Message-ID: <1551089566.83.0.710992600204.issue34656@roundup.psfhosted.org> STINNER Victor added the comment: As I wrote in my previous comment, I don't think that Python 2.7 is affected by this issue. ---------- components: +Library (Lib) -ctypes versions: +Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 05:14:54 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 Feb 2019 10:14:54 +0000 Subject: [issue36093] UnicodeEncodeError raise from smtplib.verify() method In-Reply-To: <1550908758.26.0.552141628876.issue36093@roundup.psfhosted.org> Message-ID: <1551089694.66.0.643776914091.issue36093@roundup.psfhosted.org> STINNER Victor added the comment: Barry: would you mind to have a look at this issue? It seems like smtplib encodes Unicode commands to ASCII, whereas verify() argument (SMTP "VRFY" command) is an hostname and hostname can be non-ASCII ("punycode" encoding, RFC 3492). ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 05:41:14 2019 From: report at bugs.python.org (Nathaniel Smith) Date: Mon, 25 Feb 2019 10:41:14 +0000 Subject: [issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h In-Reply-To: <1549069628.87.0.454232469964.issue35886@roundup.psfhosted.org> Message-ID: <1551091274.45.0.345464565267.issue35886@roundup.psfhosted.org> Nathaniel Smith added the comment: The cffi issue is: https://bitbucket.org/cffi/cffi/issues/403/build-fails-on-38-dev-pyinterpreterstate Armin already went ahead and committed the change to make cffi include internal/pycore_pystate.h. I guess this might not be the ideal final outcome though :-). Without some fix though it's very difficult to test things on 3.8-dev, because cffi shows up in the dependency stacks of *large* portions of the ecosystem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 05:50:03 2019 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Mon, 25 Feb 2019 10:50:03 +0000 Subject: [issue36104] test_httplib and test_nntplib fail on ARMv7 Ubuntu Message-ID: <1551091803.08.0.0253234252542.issue36104@roundup.psfhosted.org> New submission from ?ukasz Langa : The ARMv7 Ubuntu buildbot is consistently failing since build #2160: https://buildbot.python.org/all/#/builders/106/builds/2160 This looks like a testing environment issue to me rather than a code issue. But I'd like it fixed either way before we get to 3.8.0 beta1 since this is a stable builder. Greg, you can ask Inadasan about whether his dict/OrderedDict changes might have any effect on this failure: https://github.com/python/cpython/commit/c95404ff65dab1469dcd1dfec58ba54a8e7e7b3a That was the only relevant change I observed between the working and the broken build. The NNTP test failure looks like this: ====================================================================== ERROR: setUpClass (test.test_nntplib.NetworkedNNTP_SSLTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/test/test_nntplib.py", line 295, in setUpClass cls.server = cls.NNTP_CLASS(cls.NNTP_HOST, timeout=TIMEOUT, File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/nntplib.py", line 1077, in __init__ self.sock = _encrypt_on(self.sock, ssl_context, host) File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/nntplib.py", line 292, in _encrypt_on return context.wrap_socket(sock, server_hostname=hostname) File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/ssl.py", line 405, in wrap_socket return self.sslsocket_class._create( File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/ssl.py", line 853, in _create self.do_handshake() File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/ssl.py", line 1117, in do_handshake self._sslobj.do_handshake() ssl.SSLError: [SSL: DH_KEY_TOO_SMALL] dh key too small (_ssl.c:1055) The HTTP test failure looks like this: ====================================================================== ERROR: test_networked_good_cert (test.test_httplib.HTTPSTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/test/test_httplib.py", line 1629, in test_networked_good_cert h.request('GET', '/') File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py", line 1229, in request self._send_request(method, url, body, headers, encode_chunked) File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py", line 1275, in _send_request self.endheaders(body, encode_chunked=encode_chunked) File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py", line 1224, in endheaders self._send_output(message_body, encode_chunked=encode_chunked) File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py", line 1016, in _send_output self.send(msg) File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py", line 956, in send self.connect() File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py", line 1391, in connect self.sock = self._context.wrap_socket(self.sock, File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/ssl.py", line 405, in wrap_socket return self.sslsocket_class._create( File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/ssl.py", line 853, in _create self.do_handshake() File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/ssl.py", line 1117, in do_handshake self._sslobj.do_handshake() ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: EE certificate key too weak (_ssl.c:1055) ---------- assignee: gregory.p.smith messages: 336511 nosy: gregory.p.smith, inada.naoki, lukasz.langa, zach.ware priority: deferred blocker severity: normal stage: needs patch status: open title: test_httplib and test_nntplib fail on ARMv7 Ubuntu type: behavior versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 05:57:16 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 25 Feb 2019 10:57:16 +0000 Subject: [issue36105] Windows: use GetNativeSystemInfo instead of GetSystemInfo Message-ID: <1551092236.86.0.52473881575.issue36105@roundup.psfhosted.org> New submission from Giampaolo Rodola' : This is what MS doc says about GetSystemInfo: https://docs.microsoft.com/en-us/windows/desktop/api/sysinfoapi/nf-sysinfoapi-getsysteminfo <> $ grep -r GetSystemInfo Modules/_ctypes/malloc_closure.c: GetSystemInfo(&systeminfo); Modules/mmapmodule.c: GetSystemInfo(&si); Modules/mmapmodule.c: GetSystemInfo(&si); Modules/posixmodule.c: GetSystemInfo(&sysinfo); ---------- components: Windows messages: 336512 nosy: eryksun, giampaolo.rodola, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows: use GetNativeSystemInfo instead of GetSystemInfo versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 06:55:06 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 25 Feb 2019 11:55:06 +0000 Subject: [issue36105] Windows: use GetNativeSystemInfo instead of GetSystemInfo In-Reply-To: <1551092236.86.0.52473881575.issue36105@roundup.psfhosted.org> Message-ID: <1551095706.1.0.240596070222.issue36105@roundup.psfhosted.org> Ronald Oussoren added the comment: I guess it depends on what the information is used for. From a quick glance at the code I'd say that the current usage is correct, and that GetNativeSystemInfo could be used when reporting about the currently running system (for example by functions in the platform module). ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 07:12:30 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 25 Feb 2019 12:12:30 +0000 Subject: [issue33671] Efficient zero-copy for shutil.copy* functions (Linux, OSX and Win) In-Reply-To: <1527524243.69.0.682650639539.issue33671@psf.upfronthosting.co.za> Message-ID: <1551096750.59.0.557248470404.issue33671@roundup.psfhosted.org> Giampaolo Rodola' added the comment: Yes, it's deliberate, see PR-12016. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 07:27:40 2019 From: report at bugs.python.org (Eddie Elizondo) Date: Mon, 25 Feb 2019 12:27:40 +0000 Subject: [issue35810] Object Initialization does not incref Heap-allocated Types In-Reply-To: <1548275752.94.0.463880453345.issue35810@roundup.psfhosted.org> Message-ID: <1551097660.22.0.420856382147.issue35810@roundup.psfhosted.org> Eddie Elizondo added the comment: > could we just remove the whole concept of heap allocated types? I do have plans to start migrating more and more CPython modules to use heap allocated types. For example I have posixmodule up in the queue (PR10854) and a local change with all of _io migrated. I'm only blocked by having correct refcnts in these types. So, yes, let's work towards migrating all the static types to heap-allocated types! I have the time and energy to embark on this huge task so you'll see more and more of these PRs from me in the future. :) > First let's make heap types more usable and bug-free, and then it will be easier In that way, I agree with Petr, let's start by fixing the core issues first. With all of that in mind, it seems to me that we are all agree on the current solution. Let's try to push this forward and merge the PR. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 07:44:24 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 Feb 2019 12:44:24 +0000 Subject: [issue33671] Efficient zero-copy for shutil.copy* functions (Linux, OSX and Win) In-Reply-To: <1527524243.69.0.682650639539.issue33671@psf.upfronthosting.co.za> Message-ID: <1551098664.62.0.122698856798.issue33671@roundup.psfhosted.org> STINNER Victor added the comment: > Yes, it's deliberate, see PR-12016. "I decided not to document `shutil.COPY_BUFSIZE` because I consider it a corner case." Ok. I have no opinion on that, I just wanted to ask the question :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 07:49:50 2019 From: report at bugs.python.org (Kevin Walzer) Date: Mon, 25 Feb 2019 12:49:50 +0000 Subject: [issue32129] Icon on macOS In-Reply-To: <1511585376.3.0.213398074469.issue32129@psf.upfronthosting.co.za> Message-ID: <1551098990.53.0.194594085979.issue32129@roundup.psfhosted.org> Kevin Walzer added the comment: Is there any reason not to commit the patch I submitted to address this issue?As an alternative I can submit a high-res PNG that can be used, and will submit a different patch to incorporate it, which would work from either the standard app bundle or the command line. Either way, there is no reason to continue to have this visual artifact in IDLE on the Mac. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 08:19:16 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Mon, 25 Feb 2019 13:19:16 +0000 Subject: [issue36104] test_httplib and test_nntplib fail on ARMv7 Ubuntu In-Reply-To: <1551091803.08.0.0253234252542.issue36104@roundup.psfhosted.org> Message-ID: <1551100756.86.0.654950373745.issue36104@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Related to issue35925 ? ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 08:24:49 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Mon, 25 Feb 2019 13:24:49 +0000 Subject: [issue36104] test_httplib and test_nntplib fail on ARMv7 Ubuntu In-Reply-To: <1551091803.08.0.0253234252542.issue36104@roundup.psfhosted.org> Message-ID: <1551101089.63.0.736907590762.issue36104@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +pablogsal, vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 08:47:03 2019 From: report at bugs.python.org (Dmitrii Pasechnik) Date: Mon, 25 Feb 2019 13:47:03 +0000 Subject: [issue36106] resolve sinpi() name clash with libm Message-ID: <1551102423.19.0.037549170544.issue36106@roundup.psfhosted.org> New submission from Dmitrii Pasechnik : The standard math library (libm) may follow IEEE-754 recommendation to include an implementation of sinPi(), i.e. sinPi(x):=sin(pi*x). And this triggers a name clash, found by FreeBSD developer Steve Kargl, who worken on putting sinpi into libm used on FreeBSD (it has to be named "sinpi", not "sinPi", cf. e.g. https://en.cppreference.com/w/c/experimental/fpext4) ---------- components: Extension Modules messages: 336519 nosy: dimpase priority: normal pull_requests: 12059 severity: normal status: open title: resolve sinpi() name clash with libm type: compile error versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 08:53:56 2019 From: report at bugs.python.org (SilentGhost) Date: Mon, 25 Feb 2019 13:53:56 +0000 Subject: [issue36106] resolve sinpi() name clash with libm In-Reply-To: <1551102423.19.0.037549170544.issue36106@roundup.psfhosted.org> Message-ID: <1551102836.15.0.773955659623.issue36106@roundup.psfhosted.org> Change by SilentGhost : ---------- nosy: +mark.dickinson stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 09:05:33 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 Feb 2019 14:05:33 +0000 Subject: [issue36104] test_httplib and test_nntplib fail on ARMv7 Ubuntu In-Reply-To: <1551091803.08.0.0253234252542.issue36104@roundup.psfhosted.org> Message-ID: <1551103533.65.0.655742984714.issue36104@roundup.psfhosted.org> Change by STINNER Victor : ---------- resolution: -> duplicate superseder: -> test_httplib test_nntplib test_ssl fail on ARMv7 Debian buster bot (OpenSSL 1.1.1a) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 09:06:18 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 Feb 2019 14:06:18 +0000 Subject: [issue35925] test_httplib test_nntplib test_ssl fail on ARMv7 Debian buster bot (OpenSSL 1.1.1a) In-Reply-To: <1549503926.32.0.191493141556.issue35925@roundup.psfhosted.org> Message-ID: <1551103578.55.0.672336966098.issue35925@roundup.psfhosted.org> STINNER Victor added the comment: bpo-36104 has been marked as a duplicate of this issue. Copy of Lukasz's msg336511: The ARMv7 Ubuntu buildbot is consistently failing since build #2160: https://buildbot.python.org/all/#/builders/106/builds/2160 This looks like a testing environment issue to me rather than a code issue. But I'd like it fixed either way before we get to 3.8.0 beta1 since this is a stable builder. Greg, you can ask Inadasan about whether his dict/OrderedDict changes might have any effect on this failure: https://github.com/python/cpython/commit/c95404ff65dab1469dcd1dfec58ba54a8e7e7b3a That was the only relevant change I observed between the working and the broken build. The NNTP test failure looks like this: ====================================================================== ERROR: setUpClass (test.test_nntplib.NetworkedNNTP_SSLTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/test/test_nntplib.py", line 295, in setUpClass cls.server = cls.NNTP_CLASS(cls.NNTP_HOST, timeout=TIMEOUT, File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/nntplib.py", line 1077, in __init__ self.sock = _encrypt_on(self.sock, ssl_context, host) File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/nntplib.py", line 292, in _encrypt_on return context.wrap_socket(sock, server_hostname=hostname) File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/ssl.py", line 405, in wrap_socket return self.sslsocket_class._create( File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/ssl.py", line 853, in _create self.do_handshake() File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/ssl.py", line 1117, in do_handshake self._sslobj.do_handshake() ssl.SSLError: [SSL: DH_KEY_TOO_SMALL] dh key too small (_ssl.c:1055) The HTTP test failure looks like this: ====================================================================== ERROR: test_networked_good_cert (test.test_httplib.HTTPSTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/test/test_httplib.py", line 1629, in test_networked_good_cert h.request('GET', '/') File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py", line 1229, in request self._send_request(method, url, body, headers, encode_chunked) File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py", line 1275, in _send_request self.endheaders(body, encode_chunked=encode_chunked) File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py", line 1224, in endheaders self._send_output(message_body, encode_chunked=encode_chunked) File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py", line 1016, in _send_output self.send(msg) File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py", line 956, in send self.connect() File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py", line 1391, in connect self.sock = self._context.wrap_socket(self.sock, File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/ssl.py", line 405, in wrap_socket return self.sslsocket_class._create( File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/ssl.py", line 853, in _create self.do_handshake() File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/ssl.py", line 1117, in do_handshake self._sslobj.do_handshake() ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: EE certificate key too weak (_ssl.c:1055) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 09:07:12 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 Feb 2019 14:07:12 +0000 Subject: [issue35925] test_httplib test_nntplib test_ssl fail on ARMv7 Debian buster bot (OpenSSL 1.1.1a) In-Reply-To: <1549503926.32.0.191493141556.issue35925@roundup.psfhosted.org> Message-ID: <1551103632.55.0.515601732076.issue35925@roundup.psfhosted.org> STINNER Victor added the comment: Lukasz: this issue is that Debian Buster uses a strict OpenSSL policy. I guess that external public server used by tests are incompatible with this strict policy. ---------- nosy: +lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 09:07:18 2019 From: report at bugs.python.org (Davin Potts) Date: Mon, 25 Feb 2019 14:07:18 +0000 Subject: [issue36102] TestSharedMemory fails on AMD64 FreeBSD CURRENT Shared 3.x In-Reply-To: <1551085417.13.0.962588202568.issue36102@roundup.psfhosted.org> Message-ID: <1551103638.81.0.256629353008.issue36102@roundup.psfhosted.org> Davin Potts added the comment: Though apparently undocumented on FreeBSD, their implementation of shm_open differs from others in the following way: all names for shared memory blocks *must* begin with a slash. This requirement does not exist on OpenBSD. According to its man page on shm_open, FreeBSD does at least communicate the following non-standard, additional requirement: Two processes opening the same path are guaranteed to access the same shared memory object if and only if path begins with a slash (`/') character. Given that this requirement is not universal and because a leading slash controls other behaviors on platforms like Windows, it would be confusing to make a leading slash a universal requirement. Likewise, requiring users on FreeBSD to be aware of this nuance would be contrary to the goals of the SharedMemory class. I will prepare a patch to prepend a leading slash onto the requested shared memory block name and detect the need for it. I have verified that this does solve the problem on FreeBSD and that all tests then pass. I will test NetBSD and DragonflyBSD to see if they also impose FreeBSD's undocumented requirement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 09:14:05 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 Feb 2019 14:14:05 +0000 Subject: [issue36104] test_httplib and test_nntplib fail on ARMv7 Ubuntu In-Reply-To: <1551091803.08.0.0253234252542.issue36104@roundup.psfhosted.org> Message-ID: <1551104045.73.0.702198299584.issue36104@roundup.psfhosted.org> Change by STINNER Victor : ---------- stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 09:24:12 2019 From: report at bugs.python.org (desbma) Date: Mon, 25 Feb 2019 14:24:12 +0000 Subject: [issue36103] Increase shutil.COPY_BUFSIZE In-Reply-To: <1551087533.63.0.252770144463.issue36103@roundup.psfhosted.org> Message-ID: <1551104652.5.0.0308018800709.issue36103@roundup.psfhosted.org> desbma added the comment: Your first link explains why 128kB buffer size is faster in the context of cp: it's due to fadvise and kernel read ahead. None of the shutil functions call fadvise, so the benchmark and conclusions are irrelevant to the Python buffer size IMO. In general, the bigger buffer, the better, to reduce syscall frequency (also explained in the article), but going from 16kB to 128kB is clearly in the micro optimization range, unlikely to do any significant difference. Also with 3.8, in many typical file copy cases (but not all), sendfile will be used, which makes buffer size even less important. ---------- nosy: +desbma _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 09:39:07 2019 From: report at bugs.python.org (Axel) Date: Mon, 25 Feb 2019 14:39:07 +0000 Subject: [issue36078] argparse: positional with type=int, default=SUPPRESS raise ValueError In-Reply-To: <1550845114.74.0.376208054151.issue36078@roundup.psfhosted.org> Message-ID: <1551105547.31.0.0500728606077.issue36078@roundup.psfhosted.org> Axel added the comment: Thanks for so fast looking into this. Good idea to use the workaround with a own conversion function. I'll use this for now. To see what's happening, I tried a own Action with print in __call__ and a own conversion function with printing. I found following workflow: 1) direct assignment of unconverted default value (if not SUPPRESS, in parse_known_args) 2) conversion of argument string into given type 3) call to Action.__call__ which sets the converted value 4) only in edge cases: Convert default into given type and set in target When there is no option there is only: default | arg, narg = '?' | --opt | arg, narg = '*' ----------------------------------------------------- None | 1), 3) | 1) | 1), 2) with [] SUPPRESS | 2)! | | str | 1), 2), 3) | 1) | 1), 2) not str* | 1), 3) | 1), 4) | 1), 2) *can be int, float or other calss It gets more complex the deeper I get into the source... Yes, your second choice has probably less side effects. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 09:53:31 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Mon, 25 Feb 2019 14:53:31 +0000 Subject: [issue36106] resolve sinpi() name clash with libm In-Reply-To: <1551102423.19.0.037549170544.issue36106@roundup.psfhosted.org> Message-ID: <1551106411.08.0.140218821666.issue36106@roundup.psfhosted.org> Emmanuel Arias added the comment: Hi!, It seem a good improve to resolve a potential problem. But I am not convinced if that problem could appear because sinpi() is definded locally. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 09:55:58 2019 From: report at bugs.python.org (Andrey Paramonov) Date: Mon, 25 Feb 2019 14:55:58 +0000 Subject: [issue30782] Allow limiting the number of concurrent tasks in asyncio.as_completed In-Reply-To: <1498525522.6.0.617023291854.issue30782@psf.upfronthosting.co.za> Message-ID: <1551106558.64.0.83048434945.issue30782@roundup.psfhosted.org> Andrey Paramonov added the comment: > an implicit requirement that back pressure from the consumer should be handled (i.e. if whoever's iterating through "async for fut in as_completed(...)" is too slow, then the tasks should pause until it catches up) No, I don't think it is required or desired to be handled. My initial sketch was imprecise: it's better to asynchronously yield task results, not "completed task" futures. This way, no additional buffer needed, all error handling can be consolidated inside `igather()`, and that's actually more compatible with `asyncio.gather()`. I.e, instead of ---- yield next_fut ---- use ---- yield await next_fut ---- ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 09:58:22 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 25 Feb 2019 14:58:22 +0000 Subject: [issue36105] Windows: use GetNativeSystemInfo instead of GetSystemInfo In-Reply-To: <1551092236.86.0.52473881575.issue36105@roundup.psfhosted.org> Message-ID: <1551106702.67.0.745561654558.issue36105@roundup.psfhosted.org> Steve Dower added the comment: Yeah, possibly only the CPU count one could change, but there's an ongoing discussion on another bug about whether that should return the actual count or the usable count. 32-bit processes have restrictions beyond what the system is capable of, and I believe we want those reflected in each of these cases. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 10:00:24 2019 From: report at bugs.python.org (Dmitrii Pasechnik) Date: Mon, 25 Feb 2019 15:00:24 +0000 Subject: [issue36106] resolve sinpi() name clash with libm In-Reply-To: <1551102423.19.0.037549170544.issue36106@roundup.psfhosted.org> Message-ID: <1551106824.57.0.641155241337.issue36106@roundup.psfhosted.org> Dmitrii Pasechnik added the comment: This has a potential header conflict. For the same reason functions like lgamma, etc. are prefixed with `m_` in Modules/mathmodule.c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 10:05:12 2019 From: report at bugs.python.org (Dmitrii Pasechnik) Date: Mon, 25 Feb 2019 15:05:12 +0000 Subject: [issue36106] resolve sinpi() name clash with libm In-Reply-To: <1551102423.19.0.037549170544.issue36106@roundup.psfhosted.org> Message-ID: <1551107112.99.0.917496667684.issue36106@roundup.psfhosted.org> Dmitrii Pasechnik added the comment: e.g. if I rename `m_lgamma` to `lgamma` I get ``` mathmodule.c:389:1: error: static declaration of ?lgamma? follows non-static declaration lgamma(double x) ``` ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 10:06:57 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 Feb 2019 15:06:57 +0000 Subject: [issue36030] add internal API function to create tuple without items array initialization In-Reply-To: <1550563364.86.0.164811838679.issue36030@roundup.psfhosted.org> Message-ID: <1551107217.39.0.861403022674.issue36030@roundup.psfhosted.org> Serhiy Storchaka added the comment: This change is virtually renaming _PyStack_AsTuple to _PyTuple_FromArray and using it in appropriate places for code simplification. I am +1 for such change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 10:08:03 2019 From: report at bugs.python.org (Davin Potts) Date: Mon, 25 Feb 2019 15:08:03 +0000 Subject: [issue36102] TestSharedMemory fails on AMD64 FreeBSD CURRENT Shared 3.x In-Reply-To: <1551085417.13.0.962588202568.issue36102@roundup.psfhosted.org> Message-ID: <1551107283.23.0.678520255266.issue36102@roundup.psfhosted.org> Davin Potts added the comment: In local testing, I found the following systems to impose the leading slash as a requirement for simply creating a shared memory block: * NetBSD 8.0 * FreeBSD 12.x * TrueOS 18.12 (the OS formerly known as PC-BSD) I found the following systems to have no required leading slash and all tests currently pass without modification: * OpenBSD 6.4 * DragonflyBSD 5.4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 10:28:53 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 25 Feb 2019 15:28:53 +0000 Subject: [issue36105] Windows: use GetNativeSystemInfo instead of GetSystemInfo In-Reply-To: <1551092236.86.0.52473881575.issue36105@roundup.psfhosted.org> Message-ID: <1551108533.15.0.935147657894.issue36105@roundup.psfhosted.org> Giampaolo Rodola' added the comment: It appears you guys are right. Sorry for the noise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 09:48:47 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Mon, 25 Feb 2019 14:48:47 +0000 Subject: [issue36106] resolve sinpi() name clash with libm In-Reply-To: <1551102423.19.0.037549170544.issue36106@roundup.psfhosted.org> Message-ID: <1551106127.96.0.0470000085745.issue36106@roundup.psfhosted.org> Change by Emmanuel Arias : ---------- nosy: +eamanu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 10:52:19 2019 From: report at bugs.python.org (Inada Naoki) Date: Mon, 25 Feb 2019 15:52:19 +0000 Subject: [issue36103] Increase shutil.COPY_BUFSIZE In-Reply-To: <1551087533.63.0.252770144463.issue36103@roundup.psfhosted.org> Message-ID: <1551109939.9.0.780725143751.issue36103@roundup.psfhosted.org> Inada Naoki added the comment: > Your first link explains why 128kB buffer size is faster in the context of cp: it's due to fadvise and kernel read ahead. > > None of the shutil functions call fadvise, so the benchmark and conclusions are irrelevant to the Python buffer size IMO. Even without fadvice, readahead works automatically. fadvice doubles readahead size on Linux. But I don't know it really doubles readahead size when block device advertised readahead size. > In general, the bigger buffer, the better, to reduce syscall frequency (also explained in the article), but going from 16kB to 128kB is clearly in the micro optimization range, unlikely to do any significant difference. > > Also with 3.8, in many typical file copy cases (but not all), sendfile will be used, which makes buffer size even less important. It is used for copyfileobj. So better default value may worth enough. In my Linux box, SATA SSD (Samsung SSD 500GB 860EVO) is used. It has unstable sequential write performance. Here is quick test: $ dd if=/dev/urandom of=f1 bs=1M count=1k $ ./python -m timeit -n1 -r5 -v -s 'import shutil;' -- 'f1=open("f1","rb"); f2=open("/dev/null", "wb"); shutil.copyfileobj(f1, f2, 8*1024); f1.close(); f2.close()' raw times: 301 msec, 302 msec, 301 msec, 301 msec, 300 msec 1 loop, best of 5: 300 msec per loop $ ./python -m timeit -n1 -r5 -v -s 'import shutil;' -- 'f1=open("f1","rb"); f2=open("/dev/null", "wb"); shutil.copyfileobj(f1, f2, 16*1024); f1.close(); f2.close()' raw times: 194 msec, 194 msec, 193 msec, 193 msec, 193 msec 1 loop, best of 5: 193 msec per loop $ ./python -m timeit -n1 -r5 -v -s 'import shutil;' -- 'f1=open("f1","rb"); f2=open("/dev/null", "wb"); shutil.copyfileobj(f1, f2, 32*1024); f1.close(); f2.close()' raw times: 140 msec, 140 msec, 140 msec, 140 msec, 140 msec 1 loop, best of 5: 140 msec per loop $ ./python -m timeit -n1 -r5 -v -s 'import shutil;' -- 'f1=open("f1","rb"); f2=open("/dev/null", "wb"); shutil.copyfileobj(f1, f2, 64*1024); f1.close(); f2.close()' raw times: 112 msec, 112 msec, 112 msec, 112 msec, 112 msec 1 loop, best of 5: 112 msec per loop $ ./python -m timeit -n1 -r5 -v -s 'import shutil;' -- 'f1=open("f1","rb"); f2=open("/dev/null", "wb"); shutil.copyfileobj(f1, f2, 128*1024); f1.close(); f2.close()' raw times: 101 msec, 101 msec, 101 msec, 101 msec, 101 msec As far as this result, I think 64KiB is the best balance. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 10:58:03 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 Feb 2019 15:58:03 +0000 Subject: [issue36048] Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__ In-Reply-To: <1550644985.32.0.26417547244.issue36048@roundup.psfhosted.org> Message-ID: <1551110283.28.0.672219321777.issue36048@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset 6a44f6eef3d0958d88882347190b3e2d1222c2e9 by Serhiy Storchaka in branch 'master': bpo-36048: Use __index__() instead of __int__() for implicit conversion if available. (GH-11952) https://github.com/python/cpython/commit/6a44f6eef3d0958d88882347190b3e2d1222c2e9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 10:58:33 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 Feb 2019 15:58:33 +0000 Subject: [issue28450] Misleading/inaccurate documentation about unknown escape sequences in regular expressions In-Reply-To: <1476529213.17.0.132534478532.issue28450@psf.upfronthosting.co.za> Message-ID: <1551110313.36.0.791646597658.issue28450@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset a180b007d96fe68b32f11dec720fbd0cd5b6758a by Serhiy Storchaka in branch 'master': bpo-28450: Fix and improve the documentation for unknown escapes in RE. (GH-11920) https://github.com/python/cpython/commit/a180b007d96fe68b32f11dec720fbd0cd5b6758a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 10:59:49 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 Feb 2019 15:59:49 +0000 Subject: [issue35459] Use PyDict_GetItemWithError() instead of PyDict_GetItem() In-Reply-To: <1544525657.6.0.788709270274.issue35459@psf.upfronthosting.co.za> Message-ID: <1551110389.22.0.494646494048.issue35459@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset a24107b04c1277e3c1105f98aff5bfa3a98b33a0 by Serhiy Storchaka in branch 'master': bpo-35459: Use PyDict_GetItemWithError() instead of PyDict_GetItem(). (GH-11112) https://github.com/python/cpython/commit/a24107b04c1277e3c1105f98aff5bfa3a98b33a0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 11:11:08 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Mon, 25 Feb 2019 16:11:08 +0000 Subject: [issue35178] Typo/trivial mistake in warnings.py (may be related to 2.x to 3.x conversion) In-Reply-To: <1541516830.55.0.788709270274.issue35178@psf.upfronthosting.co.za> Message-ID: <1551111068.56.0.630222610206.issue35178@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: @tashrifbillah I will be happy to add a test on a follow up PR attributing to the original PR as per https://github.com/python/cpython/pull/10343#issuecomment-467026474 Thanks ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 11:13:58 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 Feb 2019 16:13:58 +0000 Subject: [issue36048] Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__ In-Reply-To: <1550644985.32.0.26417547244.issue36048@roundup.psfhosted.org> Message-ID: <1551111238.72.0.604813512584.issue36048@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 11:18:04 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 Feb 2019 16:18:04 +0000 Subject: [issue28450] Misleading/inaccurate documentation about unknown escape sequences in regular expressions In-Reply-To: <1476529213.17.0.132534478532.issue28450@psf.upfronthosting.co.za> Message-ID: <1551111484.08.0.0204163296642.issue28450@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- pull_requests: +12060 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 11:19:28 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 Feb 2019 16:19:28 +0000 Subject: [issue35459] Use PyDict_GetItemWithError() instead of PyDict_GetItem() In-Reply-To: <1544525657.6.0.788709270274.issue35459@psf.upfronthosting.co.za> Message-ID: <1551111568.31.0.909682233934.issue35459@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 11:22:18 2019 From: report at bugs.python.org (Dongyan Li) Date: Mon, 25 Feb 2019 16:22:18 +0000 Subject: [issue34781] infinite waiting in multiprocessing.Pool In-Reply-To: <1537734641.75.0.956365154283.issue34781@psf.upfronthosting.co.za> Message-ID: <1551111738.42.0.997845048602.issue34781@roundup.psfhosted.org> Dongyan Li added the comment: I got the same issue with Python 3.7.2 on Windows Build 14393. Seems that the program got stuck on the `waiter.acquire()` method. ---------- nosy: +Dongyan Li _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 11:28:55 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 Feb 2019 16:28:55 +0000 Subject: [issue28450] Misleading/inaccurate documentation about unknown escape sequences in regular expressions In-Reply-To: <1476529213.17.0.132534478532.issue28450@psf.upfronthosting.co.za> Message-ID: <1551112135.68.0.677842425391.issue28450@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset 95fc8e687c487ecf97f4b1b98dfc0c05e3c9cbff by Serhiy Storchaka in branch '3.7': [3.7] bpo-28450: Fix and improve the documentation for unknown escapes in RE. (GH-11920). (GH-12029) https://github.com/python/cpython/commit/95fc8e687c487ecf97f4b1b98dfc0c05e3c9cbff ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 11:30:13 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 Feb 2019 16:30:13 +0000 Subject: [issue28450] Misleading/inaccurate documentation about unknown escape sequences in regular expressions In-Reply-To: <1476529213.17.0.132534478532.issue28450@psf.upfronthosting.co.za> Message-ID: <1551112213.93.0.723934535876.issue28450@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 11:42:59 2019 From: report at bugs.python.org (Ned Deily) Date: Mon, 25 Feb 2019 16:42:59 +0000 Subject: [issue32129] Icon on macOS In-Reply-To: <1511585376.3.0.213398074469.issue32129@psf.upfronthosting.co.za> Message-ID: <1551112979.74.0.328110391085.issue32129@roundup.psfhosted.org> Change by Ned Deily : ---------- pull_requests: +12061 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 11:58:04 2019 From: report at bugs.python.org (Natanael Copa) Date: Mon, 25 Feb 2019 16:58:04 +0000 Subject: [issue36107] aarch64 python3 buffer overflow with stack protector on rpi3 (alpine linux) Message-ID: <1551113884.84.0.457828150843.issue36107@roundup.psfhosted.org> New submission from Natanael Copa : Alpine Linux's python 3.6.8 native build on aarch64 gets killed by stack protector when run on Raspberry Pi 3. It does not happen when same binary runs on packet.net's aarch64 machine. I was able to get a backtrace by copying the core. Core was generated by `python3'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0000007f86e85d9c in a_crash () at ./src/internal/atomic.h:250 250 ./src/internal/atomic.h: No such file or directory. (gdb) bt #0 0x0000007f86e85d9c in a_crash () at ./src/internal/atomic.h:250 #1 __stack_chk_fail () at src/env/__stack_chk_fail.c:17 #2 0x0000007f86cbc068 in _PyObject_CallMethodId_SizeT (o=o at entry=0x7f86bb1a98, name=name at entry=0x7f86e1cb88 , format=format at entry=0x0) at Objects/abstract.c:2677 #3 0x0000007f86d2fbb0 in _io_TextIOWrapper___init___impl (write_through=0, line_buffering=1, newline=, errors=0x7f86d6d810 "strict", encoding=, buffer=0x7f86bb1a98, self=) at ./Modules/_io/textio.c:1017 #4 _io_TextIOWrapper___init__ (self=0x7f86b5e630, args=, kwargs=) at ./Modules/_io/clinic/textio.c.h:173 #5 0x0000007f86cabf94 in type_call (type=, args=0x7f86b2c0a0, kwds=0x0) at Objects/typeobject.c:915 #6 0x0000007f86c5f25c in PyObject_Call (func=0x7f86e083b0 , args=, kwargs=kwargs at entry=0x0) at Objects/abstract.c:2261 #7 0x0000007f86c5f30c in call_function_tail (callable=callable at entry=0x7f86e083b0 , args=, args at entry=0x7f86b2c0a0) at Objects/abstract.c:2512 #8 0x0000007f86c96d5c in callmethod (func=func at entry=0x7f86e083b0 , format=format at entry=0x7f86d7d4de "OsssO", va=..., is_size_t=is_size_t at entry=0) at Objects/abstract.c:2596 #9 0x0000007f86cbc8c8 in _PyObject_CallMethodId (o=o at entry=0x7f86adf098, name=name at entry=0x7f86e1e0c0 , format=format at entry=0x7f86d7d4de "OsssO") at Objects/abstract.c:2640 #10 0x0000007f86cd8dec in create_stdio (io=, fd=, write_mode=, name=, encoding=, errors=, io=, fd=, write_mode=, name=, encoding=, errors=) at Python/pylifecycle.c:1154 #11 0x0000007f86cd91b4 in initstdio () at Python/pylifecycle.c:1277 #12 0x0000007f86d419cc in _Py_InitializeEx_Private (install_sigs=, install_importlib=, install_sigs=, install_importlib=) at Python/pylifecycle.c:449 #13 0x0000007f86d41a70 in Py_InitializeEx (install_sigs=install_sigs at entry=1) at Python/pylifecycle.c:470 #14 0x0000007f86d41a78 in Py_Initialize () at Python/pylifecycle.c:476 #15 0x0000007f86d42c74 in Py_Main (argc=1, argv=0x7f86f10f60) at Modules/main.c:700 #16 0x000000558291db34 in main (argc=1, argv=0x7feb5b3e48) at ./Programs/python.c:69 Downstream reports: https://bugs.alpinelinux.org/issues/9981 https://github.com/gliderlabs/docker-alpine/issues/486 ---------- components: Interpreter Core files: strace.out messages: 336540 nosy: Natanael Copa priority: normal severity: normal status: open title: aarch64 python3 buffer overflow with stack protector on rpi3 (alpine linux) versions: Python 3.6 Added file: https://bugs.python.org/file48168/strace.out _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 11:59:15 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 Feb 2019 16:59:15 +0000 Subject: [issue36030] add internal API function to create tuple without items array initialization In-Reply-To: <1550563364.86.0.164811838679.issue36030@roundup.psfhosted.org> Message-ID: <1551113955.44.0.263766000433.issue36030@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 234531b4462b20d668762bd78406fd2ebab129c9 by Victor Stinner (Sergey Fedoseev) in branch 'master': bpo-36030: Add _PyTuple_FromArray() function (GH-11954) https://github.com/python/cpython/commit/234531b4462b20d668762bd78406fd2ebab129c9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 12:08:23 2019 From: report at bugs.python.org (Natanael Copa) Date: Mon, 25 Feb 2019 17:08:23 +0000 Subject: [issue36107] aarch64 python3 buffer overflow with stack protector on rpi3 (alpine linux) In-Reply-To: <1551113884.84.0.457828150843.issue36107@roundup.psfhosted.org> Message-ID: <1551114503.29.0.307149400495.issue36107@roundup.psfhosted.org> Natanael Copa added the comment: Interestingly, it does not crash when I run python in valgrind. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 12:15:40 2019 From: report at bugs.python.org (Natanael Copa) Date: Mon, 25 Feb 2019 17:15:40 +0000 Subject: [issue36107] aarch64 python3 buffer overflow with stack protector on rpi3 (alpine linux) In-Reply-To: <1551113884.84.0.457828150843.issue36107@roundup.psfhosted.org> Message-ID: <1551114940.79.0.337636606016.issue36107@roundup.psfhosted.org> Natanael Copa added the comment: Valgrind claims there are some use of uninitialized values. ---------- Added file: https://bugs.python.org/file48169/valgrind.out _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 12:18:10 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Mon, 25 Feb 2019 17:18:10 +0000 Subject: [issue36030] add internal API function to create tuple without items array initialization In-Reply-To: <1550563364.86.0.164811838679.issue36030@roundup.psfhosted.org> Message-ID: <1551115090.59.0.303612419756.issue36030@roundup.psfhosted.org> Change by Sergey Fedoseev : ---------- pull_requests: +12062 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 12:40:35 2019 From: report at bugs.python.org (Eric Snow) Date: Mon, 25 Feb 2019 17:40:35 +0000 Subject: [issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed. In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za> Message-ID: <1551116435.37.0.32337875992.issue33608@roundup.psfhosted.org> Eric Snow added the comment: GH-11617 has introduces a slight performance regression which will need to be resolved. If I can't find the problem right away then I'll probably temporarily revert the commit. See https://mail.python.org/pipermail/python-dev/2019-February/156451.html. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 12:49:57 2019 From: report at bugs.python.org (Natanael Copa) Date: Mon, 25 Feb 2019 17:49:57 +0000 Subject: [issue36107] aarch64 python3 buffer overflow with stack protector on rpi3 (alpine linux) In-Reply-To: <1551113884.84.0.457828150843.issue36107@roundup.psfhosted.org> Message-ID: <1551116997.39.0.767949267669.issue36107@roundup.psfhosted.org> Natanael Copa added the comment: It seems like python 3.7.2 works. Any idea which commit(s) may have fixed it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 13:01:04 2019 From: report at bugs.python.org (desbma) Date: Mon, 25 Feb 2019 18:01:04 +0000 Subject: [issue36103] Increase shutil.COPY_BUFSIZE In-Reply-To: <1551087533.63.0.252770144463.issue36103@roundup.psfhosted.org> Message-ID: <1551117664.72.0.122434540092.issue36103@roundup.psfhosted.org> desbma added the comment: If you do a benchmark by reading from a file, and then writing to /dev/null several times, without clearing caches, you are measuring *only* the syscall overhead: * input data is read from the Linux page cache, not the file on your SSD itself * no data is written (obviously because output is /dev/null) Your current command line also measures open/close timings, without that I think the speed should linearly increase when doubling buffer size, but of course this is misleading, because its a synthetic benchmark. Also if you clear caches in between tests, and write the output file to the SSD itself, sendfile will be used, and should be even faster. So again I'm not sure this means much compared to real world usage. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 13:01:39 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Mon, 25 Feb 2019 18:01:39 +0000 Subject: [issue35178] Typo/trivial mistake in warnings.py (may be related to 2.x to 3.x conversion) In-Reply-To: <1541516830.55.0.788709270274.issue35178@psf.upfronthosting.co.za> Message-ID: <1551117699.99.0.416181374181.issue35178@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- keywords: +patch pull_requests: +12063 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 13:02:39 2019 From: report at bugs.python.org (Ned Deily) Date: Mon, 25 Feb 2019 18:02:39 +0000 Subject: [issue32129] Icon on macOS In-Reply-To: <1511585376.3.0.213398074469.issue32129@psf.upfronthosting.co.za> Message-ID: <1551117759.03.0.317121199351.issue32129@roundup.psfhosted.org> Change by Ned Deily : ---------- pull_requests: +12064 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 13:20:32 2019 From: report at bugs.python.org (Ned Deily) Date: Mon, 25 Feb 2019 18:20:32 +0000 Subject: [issue32129] IDLE app icon is blurry on macOS with Aqua Tk 8.6 In-Reply-To: <1511585376.3.0.213398074469.issue32129@psf.upfronthosting.co.za> Message-ID: <1551118832.68.0.724913543199.issue32129@roundup.psfhosted.org> Ned Deily added the comment: Thanks, Kevin, for the reminder. Yeah, there's no reason not to push this. I've attached PRs for 3.x and for 2.7. ---------- stage: patch review -> commit review title: Icon on macOS -> IDLE app icon is blurry on macOS with Aqua Tk 8.6 versions: +Python 2.7, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 13:23:10 2019 From: report at bugs.python.org (Natanael Copa) Date: Mon, 25 Feb 2019 18:23:10 +0000 Subject: [issue36107] aarch64 python3 buffer overflow with stack protector on rpi3 (alpine linux) In-Reply-To: <1551113884.84.0.457828150843.issue36107@roundup.psfhosted.org> Message-ID: <1551118990.64.0.266647362117.issue36107@roundup.psfhosted.org> Change by Natanael Copa : ---------- type: -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 13:57:20 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Mon, 25 Feb 2019 18:57:20 +0000 Subject: [issue35840] Control flow inconsistency on closed asyncio stream In-Reply-To: <1548662045.39.0.770532095049.issue35840@roundup.psfhosted.org> Message-ID: <1551121040.35.0.721039240959.issue35840@roundup.psfhosted.org> Emmanuel Arias added the comment: Ok, I am working on that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 14:32:52 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 25 Feb 2019 19:32:52 +0000 Subject: [issue36108] Avoid failing the build on race condition in clean Message-ID: <1551123172.45.0.629021519376.issue36108@roundup.psfhosted.org> New submission from Steve Dower : In PCbuild/openssl.props there is a task that deletes some copied files. This *might* fail on rebuilds where a Python process from a previous build has been running (for a very specific example, the rebuild as part of the release build triggered this). We shouldn't need to fail the build in this case, so change the "TreatErrorsAsWarnings" attribute to "false" (Note that this is not fixed by the KillPython step if the still-running executable is "python.exe" but we're building "python_d.exe" in the same folder. But warning and continuing is going to be fine for these particular files.) ---------- components: Build, Windows keywords: easy (C) messages: 336549 nosy: paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Avoid failing the build on race condition in clean type: compile error versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 14:58:17 2019 From: report at bugs.python.org (Lukas Geiger) Date: Mon, 25 Feb 2019 19:58:17 +0000 Subject: [issue36039] Replace append loops with list comprehensions In-Reply-To: <1550592309.68.0.760031675356.issue36039@roundup.psfhosted.org> Message-ID: <1551124697.37.0.707325711555.issue36039@roundup.psfhosted.org> Lukas Geiger added the comment: Thank you very much for your thorough explanation, totally makes sense. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 15:18:42 2019 From: report at bugs.python.org (Davin Potts) Date: Mon, 25 Feb 2019 20:18:42 +0000 Subject: [issue36102] TestSharedMemory fails on AMD64 FreeBSD CURRENT Shared 3.x In-Reply-To: <1551085417.13.0.962588202568.issue36102@roundup.psfhosted.org> Message-ID: <1551125922.79.0.0100461216158.issue36102@roundup.psfhosted.org> Change by Davin Potts : ---------- keywords: +patch pull_requests: +12065 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 16:02:19 2019 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Feb 2019 21:02:19 +0000 Subject: [issue34623] _elementtree.c doesn't call XML_SetHashSalt() In-Reply-To: <1536619664.47.0.56676864532.issue34623@psf.upfronthosting.co.za> Message-ID: <1551128539.28.0.654688590895.issue34623@roundup.psfhosted.org> Larry Hastings added the comment: New changeset d16eaf36795da48b930b80b20d3805bc27820712 by larryhastings (stratakis) in branch '3.4': [3.4] bpo-34623: Use XML_SetHashSalt in _elementtree (#9953) https://github.com/python/cpython/commit/d16eaf36795da48b930b80b20d3805bc27820712 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 16:04:12 2019 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Feb 2019 21:04:12 +0000 Subject: [issue34623] _elementtree.c doesn't call XML_SetHashSalt() In-Reply-To: <1536619664.47.0.56676864532.issue34623@psf.upfronthosting.co.za> Message-ID: <1551128652.07.0.023359314685.issue34623@roundup.psfhosted.org> Larry Hastings added the comment: New changeset 41b48e71ac8a71f56694b548f118bd20ce203410 by larryhastings (stratakis) in branch '3.5': [3.5] bpo-34623: Use XML_SetHashSalt in _elementtree (#9933) https://github.com/python/cpython/commit/41b48e71ac8a71f56694b548f118bd20ce203410 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 16:04:55 2019 From: report at bugs.python.org (Davin Potts) Date: Mon, 25 Feb 2019 21:04:55 +0000 Subject: [issue36102] TestSharedMemory fails on AMD64 FreeBSD CURRENT Shared 3.x In-Reply-To: <1551085417.13.0.962588202568.issue36102@roundup.psfhosted.org> Message-ID: <1551128695.89.0.158378378596.issue36102@roundup.psfhosted.org> Davin Potts added the comment: I have locally tested GH-12036 on all 5 of the aforementioned OSes and all are made happy by the patch. Victor: If we want to go ahead and apply this patch right away to hopefully make the FreeBSD buildbot go green, the nature of this change is sufficiently small that it will still be easy to change during the alpha period. ---------- stage: patch review -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 16:06:02 2019 From: report at bugs.python.org (Davin Potts) Date: Mon, 25 Feb 2019 21:06:02 +0000 Subject: [issue36102] TestSharedMemory fails on AMD64 FreeBSD CURRENT Shared 3.x In-Reply-To: <1551085417.13.0.962588202568.issue36102@roundup.psfhosted.org> Message-ID: <1551128762.94.0.226645596147.issue36102@roundup.psfhosted.org> Change by Davin Potts : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 16:15:44 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 25 Feb 2019 21:15:44 +0000 Subject: [issue36109] test_descr fails on AMD64 Windows8 3.x buildbots Message-ID: <1551129344.76.0.345137125147.issue36109@roundup.psfhosted.org> New submission from Pablo Galindo Salgado : https://buildbot.python.org/all/#/builders/32/builds/2198 ====================================================================== ERROR: test_vicious_descriptor_nonsense (test.test_descr.ClassPropertiesAndMethods) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\buildarea\3.x.bolen-windows8\build\lib\test\test_descr.py", line 4341, in test_vicious_descriptor_nonsense self.assertEqual(c.attr, 1) File "D:\buildarea\3.x.bolen-windows8\build\lib\test\test_descr.py", line 4328, in __eq__ del C.attr AttributeError: attr ---------------------------------------------------------------------- Ran 140 tests in 7.836s ---------- components: Tests, Windows messages: 336554 nosy: pablogsal, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: test_descr fails on AMD64 Windows8 3.x buildbots versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 16:17:20 2019 From: report at bugs.python.org (Chris Withers) Date: Mon, 25 Feb 2019 21:17:20 +0000 Subject: [issue35512] patch.dict resolves in_dict eagerly (should be late resolved) In-Reply-To: <1544993007.41.0.788709270274.issue35512@psf.upfronthosting.co.za> Message-ID: <1551129440.52.0.080597784268.issue35512@roundup.psfhosted.org> Chris Withers added the comment: New changeset ea199b90bb61866cd3c2f154341d1eb0d5c4a710 by Chris Withers (Miss Islington (bot)) in branch '3.7': bpo-35512: Resolve string target to patch.dict decorator during function call GHGH-12000 (#12021) https://github.com/python/cpython/commit/ea199b90bb61866cd3c2f154341d1eb0d5c4a710 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 16:18:39 2019 From: report at bugs.python.org (Nikolaus Rath) Date: Mon, 25 Feb 2019 21:18:39 +0000 Subject: [issue20177] Derby #8: Convert 28 sites to Argument Clinic across 2 files In-Reply-To: <1389138574.32.0.892814928986.issue20177@psf.upfronthosting.co.za> Message-ID: <1551129519.76.0.661072437206.issue20177@roundup.psfhosted.org> Nikolaus Rath added the comment: Sorry, no. I have long lost context and interest in this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 16:20:10 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 25 Feb 2019 21:20:10 +0000 Subject: [issue36109] test_descr fails on AMD64 Windows8 3.x buildbots In-Reply-To: <1551129344.76.0.345137125147.issue36109@roundup.psfhosted.org> Message-ID: <1551129610.56.0.602369599353.issue36109@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: I can reproduce this locally. How has this not being spotted by the CI: ? ./python.exe -m test test_descr Run tests sequentially 0:00:00 load avg: 3.82 [1/1] test_descr test test_descr failed -- Traceback (most recent call last): File "/Users/pgalindo3/github/cpython/Lib/test/test_descr.py", line 4341, in test_vicious_descriptor_nonsense self.assertEqual(c.attr, 1) File "/Users/pgalindo3/github/cpython/Lib/test/test_descr.py", line 4328, in __eq__ del C.attr AttributeError: attr test_descr failed == Tests result: FAILURE == 1 test failed: test_descr Total duration: 2 sec 437 ms Tests result: FAILURE ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 16:28:39 2019 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Feb 2019 21:28:39 +0000 Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org> Message-ID: <1551130119.01.0.156575993813.issue35746@roundup.psfhosted.org> Larry Hastings added the comment: New changeset 6c655ce34ae54adb8eef22b73108e22cc381cb8d by larryhastings (Victor Stinner) in branch '3.4': bpo-35746: Fix segfault in ssl's cert parser (GH-11569) (#11868) https://github.com/python/cpython/commit/6c655ce34ae54adb8eef22b73108e22cc381cb8d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 16:29:05 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 Feb 2019 21:29:05 +0000 Subject: [issue36102] TestSharedMemory fails on AMD64 FreeBSD CURRENT Shared 3.x In-Reply-To: <1551085417.13.0.962588202568.issue36102@roundup.psfhosted.org> Message-ID: <1551130145.88.0.077646686403.issue36102@roundup.psfhosted.org> STINNER Victor added the comment: Apply the patch, we will see if the buildbot color changes :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 16:37:27 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 25 Feb 2019 21:37:27 +0000 Subject: [issue36109] test_descr fails on AMD64 Windows8 3.x buildbots In-Reply-To: <1551129344.76.0.345137125147.issue36109@roundup.psfhosted.org> Message-ID: <1551130647.52.0.331379462796.issue36109@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: It seems that this is a race condition created as a consequence of: https://github.com/python/cpython/pull/11112/files ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 16:37:41 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 Feb 2019 21:37:41 +0000 Subject: [issue36030] add internal API function to create tuple without items array initialization In-Reply-To: <1550563364.86.0.164811838679.issue36030@roundup.psfhosted.org> Message-ID: <1551130661.25.0.365706106388.issue36030@roundup.psfhosted.org> STINNER Victor added the comment: New changeset f1b9abe35f75393351b3d954a392122a3f8f6951 by Victor Stinner (Sergey Fedoseev) in branch 'master': bpo-36030: Remove _PyStack_AsTuple() and _PyStack_AsTupleSlice() (GH-12032) https://github.com/python/cpython/commit/f1b9abe35f75393351b3d954a392122a3f8f6951 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 16:45:42 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 Feb 2019 21:45:42 +0000 Subject: [issue36110] test_descr: test_vicious_descriptor_nonsense() fails randomly Message-ID: <1551131142.81.0.685289347637.issue36110@roundup.psfhosted.org> New submission from STINNER Victor : test_vicious_descriptor_nonsense() started to fails randomly: $ ./python -m test -j0 -F test_descr test_descr test_descr test_descr test_descr test_descr Run tests in parallel using 10 child processes 0:00:03 load avg: 1.24 [1/6] test_descr passed 0:00:03 load avg: 1.70 [2/6/1] test_descr failed test test_descr failed -- Traceback (most recent call last): File "/home/vstinner/prog/python/master/Lib/test/test_descr.py", line 4341, in test_vicious_descriptor_nonsense self.assertEqual(c.attr, 1) File "/home/vstinner/prog/python/master/Lib/test/test_descr.py", line 4328, in __eq__ del C.attr AttributeError: attr 0:00:03 load avg: 1.70 [3/6/1] test_descr passed 0:00:04 load avg: 1.70 [4/6/1] test_descr passed 0:00:04 load avg: 1.70 [5/6/1] test_descr passed 0:00:04 load avg: 1.70 [6/6/1] test_descr passed == Tests result: FAILURE == 5 tests OK. 1 test failed: test_descr Total duration: 4 sec 213 ms Tests result: FAILURE -- It seems like it's a regression introduced by this change: a24107b04c1277e3c1105f98aff5bfa3a98b33a0 is the first bad commit commit a24107b04c1277e3c1105f98aff5bfa3a98b33a0 Author: Serhiy Storchaka Date: Mon Feb 25 17:59:46 2019 +0200 bpo-35459: Use PyDict_GetItemWithError() instead of PyDict_GetItem(). (GH-11112) :040000 040000 da22597a443c84fb29588a3557f5dd04e292a1cc fb73df9fbfdc1893e9f0bde9fbc6ab6febabbe8f M Include :040000 040000 4b26a84a0e3a813470e34ddef29596da41d3d28f ca6192ea98e014434a32e2a114e42b297408ce00 M Modules :040000 040000 b2dd7d4e832c64ba44781a34093c5d69ea127932 26bfeced0b5776634051ed57d701361252c6de68 M Objects :040000 040000 6b5a0bf3a25434ee3de5c9dae3e880217773c0fb 56265d6d2cd8cb92ba47541909af2edec46196e6 M Python ---------- components: Tests messages: 336562 nosy: serhiy.storchaka, vstinner priority: normal severity: normal status: open title: test_descr: test_vicious_descriptor_nonsense() fails randomly versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 16:47:47 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 Feb 2019 21:47:47 +0000 Subject: [issue35459] Use PyDict_GetItemWithError() instead of PyDict_GetItem() In-Reply-To: <1544525657.6.0.788709270274.issue35459@psf.upfronthosting.co.za> Message-ID: <1551131267.62.0.292222901271.issue35459@roundup.psfhosted.org> STINNER Victor added the comment: It seems like the change introduced a regression: bpo-36110. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 17:12:02 2019 From: report at bugs.python.org (Enji Cooper) Date: Mon, 25 Feb 2019 22:12:02 +0000 Subject: [issue36111] Negative `offset` values are no longer acceptable with implementation of `seek` with python3; should be per POSIX Message-ID: <1551132722.44.0.748659725129.issue36111@roundup.psfhosted.org> New submission from Enji Cooper : I tried using os.SEEK_END in a technical interview, but unfortunately, that didn't work with python 3.x: pinklady:cpython ngie$ python3 Python 3.7.2 (default, Feb 12 2019, 08:15:36) [Clang 10.0.0 (clang-1000.11.45.5)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> fp = open("configure"); fp.seek(-100, os.SEEK_END) Traceback (most recent call last): File "", line 1, in io.UnsupportedOperation: can't do nonzero end-relative seeks It does however work with 2.x, which is aligned with the POSIX spec implementation, as shown below: pinklady:cpython ngie$ python Python 2.7.15 (default, Oct 2 2018, 11:47:18) [GCC 4.2.1 Compatible Apple LLVM 10.0.0 (clang-1000.11.45.2)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> fp = open("configure"); fp.seek(-100, os.SEEK_END) >>> fp.tell() 501076 >>> os.stat("configure").st_size 501176 >>> ---------- components: IO messages: 336564 nosy: yaneurabeya priority: normal severity: normal status: open title: Negative `offset` values are no longer acceptable with implementation of `seek` with python3; should be per POSIX _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 17:33:23 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Mon, 25 Feb 2019 22:33:23 +0000 Subject: [issue36111] Negative `offset` values are no longer acceptable with implementation of `seek` with python3; should be per POSIX In-Reply-To: <1551132722.44.0.748659725129.issue36111@roundup.psfhosted.org> Message-ID: <1551134003.15.0.800749101559.issue36111@roundup.psfhosted.org> Steven D'Aprano added the comment: I believe you will find that this is because you opened the file in text mode, which means Unicode, not bytes. If you open it in binary mode, the POSIX spec applies: py> fp = open("sample", "rb"); fp.seek(-100, os.SEEK_END) 350 Supported values for seeking in text (Unicode) files are documented here: https://docs.python.org/3/library/io.html#io.TextIOBase.seek I don't believe this is a bug, or possible to be changed. Do you still think otherwise? If not, we should close this ticket. ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 17:37:48 2019 From: report at bugs.python.org (Rohit travels and tours) Date: Mon, 25 Feb 2019 22:37:48 +0000 Subject: [issue36102] TestSharedMemory fails on AMD64 FreeBSD CURRENT Shared 3.x In-Reply-To: <1551085417.13.0.962588202568.issue36102@roundup.psfhosted.org> Message-ID: <1551134268.05.0.277906258465.issue36102@roundup.psfhosted.org> Change by Rohit travels and tours : ---------- type: -> resource usage _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 17:41:54 2019 From: report at bugs.python.org (Davin Potts) Date: Mon, 25 Feb 2019 22:41:54 +0000 Subject: [issue36102] TestSharedMemory fails on AMD64 FreeBSD CURRENT Shared 3.x In-Reply-To: <1551085417.13.0.962588202568.issue36102@roundup.psfhosted.org> Message-ID: <1551134514.56.0.376044898564.issue36102@roundup.psfhosted.org> Davin Potts added the comment: New changeset aadef2b41600cb6a4f845cdc4cea001c916d8745 by Davin Potts in branch 'master': bpo-36102: Prepend slash to all POSIX shared memory block names (#12036) https://github.com/python/cpython/commit/aadef2b41600cb6a4f845cdc4cea001c916d8745 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 17:42:10 2019 From: report at bugs.python.org (Enji Cooper) Date: Mon, 25 Feb 2019 22:42:10 +0000 Subject: [issue36111] Negative `offset` values are no longer acceptable with implementation of `seek` with python3; should be per POSIX In-Reply-To: <1551132722.44.0.748659725129.issue36111@roundup.psfhosted.org> Message-ID: <1551134530.09.0.20093475112.issue36111@roundup.psfhosted.org> Enji Cooper added the comment: ?! Being blunt: why should opening a file in binary vs text mode matter? POSIX doesn't make this distinction. Per the pydoc (https://docs.python.org/2/library/functions.html#open): > The default is to use text mode, which may convert '\n' characters to a platform-specific representation on writing and back on reading. If this is one of the only differentiators between binary and text mode, why should certain types of seeking be made impossible? Having to stat the file, then set the cursor to the size of the file, minus the offset breaks the 'seek(..)' interface, and having to use 'rb', then convert from bytes to unicode overly complicates things :(. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 17:44:15 2019 From: report at bugs.python.org (Enji Cooper) Date: Mon, 25 Feb 2019 22:44:15 +0000 Subject: [issue36111] Negative `offset` values are no longer acceptable with implementation of `seek` with python3 when in text mode; should be per POSIX In-Reply-To: <1551132722.44.0.748659725129.issue36111@roundup.psfhosted.org> Message-ID: <1551134655.24.0.230364749631.issue36111@roundup.psfhosted.org> Change by Enji Cooper : ---------- title: Negative `offset` values are no longer acceptable with implementation of `seek` with python3; should be per POSIX -> Negative `offset` values are no longer acceptable with implementation of `seek` with python3 when in text mode; should be per POSIX _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 17:44:16 2019 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Feb 2019 22:44:16 +0000 Subject: [issue34656] [CVE-2018-20406] memory exhaustion in Modules/_pickle.c:1393 In-Reply-To: <1536813527.13.0.956365154283.issue34656@psf.upfronthosting.co.za> Message-ID: <1551134656.1.0.905694825974.issue34656@roundup.psfhosted.org> Larry Hastings added the comment: New changeset 4b42d575bf0fb01192b3ec54b7e224b238691527 by larryhastings (Victor Stinner) in branch '3.4': [3.4] bpo-34656: Avoid relying on signed overflow in _pickle memos (GH-9261) (#11870) https://github.com/python/cpython/commit/4b42d575bf0fb01192b3ec54b7e224b238691527 ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 17:46:14 2019 From: report at bugs.python.org (Davin Potts) Date: Mon, 25 Feb 2019 22:46:14 +0000 Subject: [issue36102] TestSharedMemory fails on AMD64 FreeBSD CURRENT Shared 3.x In-Reply-To: <1551085417.13.0.962588202568.issue36102@roundup.psfhosted.org> Message-ID: <1551134774.34.0.546378055337.issue36102@roundup.psfhosted.org> Davin Potts added the comment: Closing. Thank you Giampaolo for jumping in so quickly to review! Thank you Victor for catching this on the buildbot. Though what is this talk of "_if_ the color changes"? ;) ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 17:55:35 2019 From: report at bugs.python.org (Anthony Sottile) Date: Mon, 25 Feb 2019 22:55:35 +0000 Subject: [issue35802] os.stat / os.lstat always present, but code checks hastattr(os, 'stat') / hasattr(os, 'lstat') In-Reply-To: <1548106954.23.0.477810476155.issue35802@roundup.psfhosted.org> Message-ID: <1551135335.61.0.025839758748.issue35802@roundup.psfhosted.org> Change by Anthony Sottile : ---------- stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 18:12:37 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Mon, 25 Feb 2019 23:12:37 +0000 Subject: [issue35892] Fix awkwardness of statistics.mode() for multimodal datasets In-Reply-To: <1549219885.57.0.86866159357.issue35892@roundup.psfhosted.org> Message-ID: <1551136357.17.0.423707827606.issue35892@roundup.psfhosted.org> Steven D'Aprano added the comment: Executive summary: - let's change the behaviour of mode to return a single mode rather than raise an exception if there are multimodes; - and let's do it without a depreciation period. Further comments in no particular order: I agree that in practice the current implementation of mode has turned out to be quite awkward. Unfortunately I feel that just chosing one mode and returning it as "the" mode is statistically dubious (despite it being commonplace!). I've checked with some statisticians, or at least people who claim to be statisticians on the Internet, and they agree. (The usual advice from statisticians is to always plot your data before talking about the mode or modes, as even local maxima can be meaningful.) Nevertheless, Raymond's use-case of the nearest neighbor algorithm is persuasive. We should change the mode function to return one of the modes. Which one? Again, people I've spoken to suggest that there's no statistical basis to picking any specific one (first found, last found, smallest, largest). I'm unhappy about documenting which mode is returned, as I expect it will be an implementation detail that could change in the future. Raymond, are you happy to leave the specific detail of which mode is returned unspecified? Or do you have an argument for why we should specify it, and can do so without limiting future implementations? I too strongly prefer a separate multimode function over a flag to the mode function. As for backwards-compatibility, I've asked around trying to find anyone who claims that changing the behaviour would break their code. I haven't found anyone. I guess that means that unless any of the other core devs object, I'm happy to go with Raymond's recommendation to just change the behaviour without a depreciation period. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 18:13:12 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 Feb 2019 23:13:12 +0000 Subject: [issue36102] TestSharedMemory fails on AMD64 FreeBSD CURRENT Shared 3.x In-Reply-To: <1551085417.13.0.962588202568.issue36102@roundup.psfhosted.org> Message-ID: <1551136392.89.0.446915077386.issue36102@roundup.psfhosted.org> STINNER Victor added the comment: FYI the test also failed on AMD64 FreeBSD 10-STABLE Non-Debug 3.x: https://buildbot.python.org/all/#/builders/167/builds/600 I will keep on eye on this buildbot worker as well ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 18:16:41 2019 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Feb 2019 23:16:41 +0000 Subject: [issue35411] FTP tests of test_urllib2net fail on Travis CI: 425 Security: Bad IP connecting. In-Reply-To: <1543961289.76.0.788709270274.issue35411@psf.upfronthosting.co.za> Message-ID: <1551136601.27.0.0774899119216.issue35411@roundup.psfhosted.org> Larry Hastings added the comment: New changeset 8bcbc7896d1fe1c289bae339d408fdf1472a00fa by larryhastings (Victor Stinner) in branch '3.5': bpo-35411: Skip test_urllib2net FTP tests on Travis CI (GH-10907) (#11874) https://github.com/python/cpython/commit/8bcbc7896d1fe1c289bae339d408fdf1472a00fa ---------- nosy: +larry, lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 18:19:21 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Mon, 25 Feb 2019 23:19:21 +0000 Subject: [issue35892] Fix awkwardness of statistics.mode() for multimodal datasets In-Reply-To: <1549219885.57.0.86866159357.issue35892@roundup.psfhosted.org> Message-ID: <1551136761.5.0.290285073005.issue35892@roundup.psfhosted.org> Steven D'Aprano added the comment: What do people think about leaving this as an "Easy First Issue" for the sprint? If others agree that it is sufficiently easy, we can assign the task to Cheryl. It should be fairly easy: mode calls an internal function _counts which is not public and not used anywhere else, so it can be changed completely or even discarded if needed. ---------- nosy: +cheryl.sabella _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 18:21:50 2019 From: report at bugs.python.org (Totte Karlsson) Date: Mon, 25 Feb 2019 23:21:50 +0000 Subject: [issue36112] os.path.realpath on windows and substed drives Message-ID: <1551136910.4.0.075710439537.issue36112@roundup.psfhosted.org> New submission from Totte Karlsson : Python's os.path.realpath, when used with a substed drive on the Windows platform, don't resolve the substed path to the *real* path. For example creating a substed drive like this: subst z: C:\Users\Public\Desktop and checking for the real path in python like this: import os myPath = "S:\\" print("Real path of: " + myPath + " is: " + os.path.realpath(myPath) ) prints Real path of: S:\ is: S:\ In the docs for the [subst][1] command, a substed drive is referred to as a *virtual* drive. Virtual, suggesting something being "not real", indicates that the Python *realpath* command is not working properly on Windows. [1]: https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/subst ---------- components: Windows messages: 336574 nosy: Totte Karlsson, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: os.path.realpath on windows and substed drives type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 18:23:12 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 25 Feb 2019 23:23:12 +0000 Subject: [issue36110] test_descr: test_vicious_descriptor_nonsense() fails randomly In-Reply-To: <1551131142.81.0.685289347637.issue36110@roundup.psfhosted.org> Message-ID: <1551136992.98.0.666127827734.issue36110@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: Duplicate of https://bugs.python.org/issue36109 ---------- nosy: +pablogsal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 18:23:25 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 25 Feb 2019 23:23:25 +0000 Subject: [issue36110] test_descr: test_vicious_descriptor_nonsense() fails randomly In-Reply-To: <1551131142.81.0.685289347637.issue36110@roundup.psfhosted.org> Message-ID: <1551137005.82.0.825510761165.issue36110@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 18:23:47 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 25 Feb 2019 23:23:47 +0000 Subject: [issue36110] test_descr: test_vicious_descriptor_nonsense() fails randomly In-Reply-To: <1551131142.81.0.685289347637.issue36110@roundup.psfhosted.org> Message-ID: <1551137027.1.0.833109470116.issue36110@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: I was faster this time ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 18:32:18 2019 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Feb 2019 23:32:18 +0000 Subject: [issue34791] xml package does not obey sys.flags.ignore_environment In-Reply-To: <1537807650.53.0.956365154283.issue34791@psf.upfronthosting.co.za> Message-ID: <1551137538.15.0.811309368817.issue34791@roundup.psfhosted.org> Larry Hastings added the comment: New changeset 765d333512e9b58da4a4431595a0e81517ef0443 by larryhastings (Victor Stinner) in branch '3.4': bpo-34791: xml package obeys ignore env flags (GH-9544) (#11872) https://github.com/python/cpython/commit/765d333512e9b58da4a4431595a0e81517ef0443 ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 18:32:20 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Mon, 25 Feb 2019 23:32:20 +0000 Subject: [issue24235] ABCs don't fail metaclass instantiation In-Reply-To: <1431985736.79.0.831498694265.issue24235@psf.upfronthosting.co.za> Message-ID: <1551137540.65.0.514190343617.issue24235@roundup.psfhosted.org> Cheryl Sabella added the comment: Closing as a duplicate as Luiz suggested. ---------- nosy: +cheryl.sabella resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> abstract class instantiable when subclassing built-in types _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 18:41:01 2019 From: report at bugs.python.org (Patrick McLean) Date: Mon, 25 Feb 2019 23:41:01 +0000 Subject: [issue36046] support dropping privileges when running subprocesses In-Reply-To: <1550625858.55.0.53498127684.issue36046@roundup.psfhosted.org> Message-ID: <1551138061.21.0.259266980664.issue36046@roundup.psfhosted.org> Patrick McLean added the comment: Alexey, here are my responses to your points: 1) This is intentional, this is for dropping privileges before running some (possibly untrusted) command, we do not want to leave a path for the subprocess to gain root back. If there is a subprocess that needs root for some operations, it would presumably have the ability to drop privileges itself, and would not need the python script to do it before running it. 2) While POSIX leaves it unspecified what changes are permitted for an unprivileged process, these are permitted for a privileged process, which is the main use case for this functionality. In the case the OS does not support it for an unpriviliged process, the syscall would fail with EPERM, which can be handled from the calling python code. I am fine removing the workaround, and allowing it to fail with EPERM. Perhaps we could find another way around this for running the tests in an unprivileged environment, or just leave the test only running the EPERM case... I could change the API to have have group= and supp_groups= if you prefer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 18:42:27 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Mon, 25 Feb 2019 23:42:27 +0000 Subject: [issue25337] weakref.finalize documentation refers to old interpreter shutdown behavior In-Reply-To: <1444270840.16.0.813580393824.issue25337@psf.upfronthosting.co.za> Message-ID: <1551138147.96.0.323600092006.issue25337@roundup.psfhosted.org> Cheryl Sabella added the comment: Adding @pitrou to the nosylist as he implemented PEP442 in issue 18112. If he agrees with the proposed change, then I believe this can be marked as 'easy'. ---------- nosy: +cheryl.sabella, pitrou versions: +Python 3.7, Python 3.8 -Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 18:54:40 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Mon, 25 Feb 2019 23:54:40 +0000 Subject: [issue35033] Column or row spanning cells are not implemented. In-Reply-To: <1540052915.48.0.788709270274.issue35033@psf.upfronthosting.co.za> Message-ID: <1551138880.96.0.99447775812.issue35033@roundup.psfhosted.org> Cheryl Sabella added the comment: > https://github.com/sphinx-doc/sphinx/pull/5559 has been merged, let's wait for a release of Sphinx and we'll be able to build Python 3.8 documentation as text again. I tried running the sphinx-build command using Sphinx 1.8.4 and I got the same exception. Running Sphinx v1.8.4 building [mo]: all of 0 po files building [text]: all source files updating environment: 475 added, 0 changed, 0 removed reading sources... [100%] whatsnew/index looking for now-outdated files... none found pickling environment... done checking consistency... done preparing documents... done writing output... [ 12%] c-api/typeobj Exception occurred: File "n:\projects\cpython-venv\lib\site-packages\sphinx\writers\text.py", line 623, in visit_entry raise NotImplementedError('Column or row spanning cells are ' NotImplementedError: Column or row spanning cells are not implemented. The full traceback has been saved in C:\Users\cheka\AppData\Local\Temp\sphinx-err-222wk1in.log, if you want to report the issue to the developers. Please also report this if it was a user error, so that a better error message can be provided next time. A bug report can be filed in the tracker at . Thanks! ---------- nosy: +cheryl.sabella _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 18:56:19 2019 From: report at bugs.python.org (Julien Palard) Date: Mon, 25 Feb 2019 23:56:19 +0000 Subject: [issue35033] Column or row spanning cells are not implemented. In-Reply-To: <1540052915.48.0.788709270274.issue35033@psf.upfronthosting.co.za> Message-ID: <1551138979.23.0.885535002204.issue35033@roundup.psfhosted.org> Julien Palard added the comment: IIRC this will be released in the next major sphinx version, planned for around march. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 18:56:47 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 25 Feb 2019 23:56:47 +0000 Subject: [issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h In-Reply-To: <1437054680.06.0.553712434946.issue24643@psf.upfronthosting.co.za> Message-ID: <1551139007.03.0.155853845746.issue24643@roundup.psfhosted.org> Steve Dower added the comment: New changeset 6673decfa0fb078f60587f5cb5e98460eea137c2 by Steve Dower (Zackery Spytz) in branch 'master': bpo-24643: Fix "#define timezone _timezone" clashes on Windows (GH-12019) https://github.com/python/cpython/commit/6673decfa0fb078f60587f5cb5e98460eea137c2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 18:56:56 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 25 Feb 2019 23:56:56 +0000 Subject: [issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h In-Reply-To: <1437054680.06.0.553712434946.issue24643@psf.upfronthosting.co.za> Message-ID: <1551139016.48.0.917830370143.issue24643@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +12066 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 19:07:17 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 26 Feb 2019 00:07:17 +0000 Subject: [issue35802] os.stat / os.lstat always present, but code checks hastattr(os, 'stat') / hasattr(os, 'lstat') In-Reply-To: <1548106954.23.0.477810476155.issue35802@roundup.psfhosted.org> Message-ID: <1551139637.05.0.918539602068.issue35802@roundup.psfhosted.org> Giampaolo Rodola' added the comment: A BB failed. Looks like it's unrelated with this change: https://buildbot.python.org/all/#/builders/99/builds/2198 ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 19:08:01 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Tue, 26 Feb 2019 00:08:01 +0000 Subject: [issue35033] Column or row spanning cells are not implemented. In-Reply-To: <1540052915.48.0.788709270274.issue35033@psf.upfronthosting.co.za> Message-ID: <1551139681.57.0.909144073863.issue35033@roundup.psfhosted.org> Cheryl Sabella added the comment: Apologies, I didn't realize it would be in the major version; I checked since there had been minor release versions since this ticket. I'll check again once the major release is out. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 19:15:08 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 26 Feb 2019 00:15:08 +0000 Subject: [issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h In-Reply-To: <1437054680.06.0.553712434946.issue24643@psf.upfronthosting.co.za> Message-ID: <1551140108.05.0.0761936941143.issue24643@roundup.psfhosted.org> miss-islington added the comment: New changeset 0b3019a02e60171e9b7edb261e1234109001819c by Miss Islington (bot) in branch '3.7': bpo-24643: Fix "GH-define timezone _timezone" clashes on Windows (GH-12019) https://github.com/python/cpython/commit/0b3019a02e60171e9b7edb261e1234109001819c ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 19:17:06 2019 From: report at bugs.python.org (Larry Hastings) Date: Tue, 26 Feb 2019 00:17:06 +0000 Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org> Message-ID: <1551140226.04.0.564929839172.issue35746@roundup.psfhosted.org> Larry Hastings added the comment: New changeset efec7631edf3b9480dc3988c97ffef94df8800da by larryhastings (Victor Stinner) in branch '3.5': bpo-35746: Fix segfault in ssl's cert parser (GH-11569) (#11867) https://github.com/python/cpython/commit/efec7631edf3b9480dc3988c97ffef94df8800da ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 19:29:37 2019 From: report at bugs.python.org (Enji Cooper) Date: Tue, 26 Feb 2019 00:29:37 +0000 Subject: [issue36111] Negative `offset` values are no longer acceptable with implementation of `seek` with python3 when in text mode; should be per POSIX In-Reply-To: <1551132722.44.0.748659725129.issue36111@roundup.psfhosted.org> Message-ID: <1551140977.21.0.833800694271.issue36111@roundup.psfhosted.org> Enji Cooper added the comment: Opening and seeking using SEEK_END worked in text mode with python 2.7. I'm not terribly sure why 3.x should depart from this behavior: >>> fp = open("configure", "rt"); fp.seek(-100, os.SEEK_END) >>> fp.tell() 501076 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 19:30:14 2019 From: report at bugs.python.org (Enji Cooper) Date: Tue, 26 Feb 2019 00:30:14 +0000 Subject: [issue36111] Negative `offset` values are no longer acceptable with implementation of `seek` with python3 when in text mode; should be per POSIX In-Reply-To: <1551132722.44.0.748659725129.issue36111@roundup.psfhosted.org> Message-ID: <1551141014.98.0.0746974014104.issue36111@roundup.psfhosted.org> Change by Enji Cooper : ---------- versions: +Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 19:41:36 2019 From: report at bugs.python.org (Larry Hastings) Date: Tue, 26 Feb 2019 00:41:36 +0000 Subject: [issue34656] [CVE-2018-20406] memory exhaustion in Modules/_pickle.c:1393 In-Reply-To: <1536813527.13.0.956365154283.issue34656@psf.upfronthosting.co.za> Message-ID: <1551141696.08.0.295272330324.issue34656@roundup.psfhosted.org> Larry Hastings added the comment: New changeset ef33dd6036aafbd3f06c1d56e2b1a81dae3da63c by larryhastings (Victor Stinner) in branch '3.5': closes bpo-34656: Avoid relying on signed overflow in _pickle memos. (GH-9261) (#11869) https://github.com/python/cpython/commit/ef33dd6036aafbd3f06c1d56e2b1a81dae3da63c ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 20:03:59 2019 From: report at bugs.python.org (Eric Snow) Date: Tue, 26 Feb 2019 01:03:59 +0000 Subject: [issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h In-Reply-To: <1549069628.87.0.454232469964.issue35886@roundup.psfhosted.org> Message-ID: <1551143039.1.0.196681158491.issue35886@roundup.psfhosted.org> Eric Snow added the comment: @Armin, thanks for fixing things on your end so quickly. :) Adding PyInterpreterState.dict and a public getter function (a la PyThreadState) is probably fine. I'm just not sure how that relates to the problem with cffi's use of the "builtins" field. If it would be useful in general then feel free to open a separate issue. I doubt there'd be much opposition if you presented a decent use case, since the cost would be low. In the case of PyInterpreterState.builtins specifically, if you need it we could add a simple PyInterpreterState_GetBuiltins(). However, couldn't you already use existing public API, e.g. `PyEval_GetBuiltins()` or `PyImport_GetModule("builtins")`? Regardless, we certainly don't want to put anyone in a position that they must define Py_BUILD_CORE just for access to PyInterpreterState fields. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 20:05:47 2019 From: report at bugs.python.org (Eric Snow) Date: Tue, 26 Feb 2019 01:05:47 +0000 Subject: [issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h In-Reply-To: <1551088932.48.0.795155263877.issue35886@roundup.psfhosted.org> Message-ID: Eric Snow added the comment: On Mon, Feb 25, 2019 at 3:02 AM STINNER Victor wrote: > But that's where I suggested to test "popular C extensions" with a C API change before merging it. It's ok if issues are discovered later, but the author of backward incompatible C API changes should collaborate with popular C extension maintainers to help to deal with these issues. Yeah, that was my bad. I jumped the gun a bit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 20:47:50 2019 From: report at bugs.python.org (Larry Hastings) Date: Tue, 26 Feb 2019 01:47:50 +0000 Subject: [issue34791] xml package does not obey sys.flags.ignore_environment In-Reply-To: <1537807650.53.0.956365154283.issue34791@psf.upfronthosting.co.za> Message-ID: <1551145670.18.0.197050527355.issue34791@roundup.psfhosted.org> Larry Hastings added the comment: New changeset 7cd08cf62086a8a2d84fd825dfcd8bfe33bf1986 by larryhastings (Victor Stinner) in branch '3.5': bpo-34791: xml package obeys ignore env flags (GH-9544) (#11871) https://github.com/python/cpython/commit/7cd08cf62086a8a2d84fd825dfcd8bfe33bf1986 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 20:56:56 2019 From: report at bugs.python.org (Enji Cooper) Date: Tue, 26 Feb 2019 01:56:56 +0000 Subject: [issue8747] Autoconf tests in python not portably correct In-Reply-To: <1274174021.7.0.201652385814.issue8747@psf.upfronthosting.co.za> Message-ID: <1551146216.8.0.588316656455.issue8747@roundup.psfhosted.org> Enji Cooper added the comment: This issue has been superseded by other work. ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 20:58:06 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 26 Feb 2019 01:58:06 +0000 Subject: [issue35892] Fix awkwardness of statistics.mode() for multimodal datasets In-Reply-To: <1549219885.57.0.86866159357.issue35892@roundup.psfhosted.org> Message-ID: <1551146286.98.0.91337972212.issue35892@roundup.psfhosted.org> Raymond Hettinger added the comment: > If others agree that it is sufficiently easy, we can assign > the task to Cheryl. It's only easy if we clearly specify what we want to occur. Deciding what the right behavior should be is not a beginner skill. Proposed spec: ''' Modify the API statistics.mode to handle multimodal cases so that the first mode encountered is the one returned. If the input is empty, raise a StatisticsError. TestCases: mode([]) --> StatisticsError mode('aabbbcc') --> 'c' mode(iter('aabbbcc')) --> 'c' mode('eeffddddggaaaa') --> 'a' Implementation: * Discard the internal _counts function. * Instead use Counter(data).most_common(1)[0][0] because that makes only a single pass over the data Documentation: * Update statistics.rst and include a versionchanged directive * In the Whatsnew compatibility section, note this is a behavior change. Code that used to raise StatisticsError will now return a useful value. Note that the rationale for the change is that the current mode() behavior would unexpectedly fail when given multimodal data. When: * We want this for 3.8 so it can't wait very long ''' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 21:05:49 2019 From: report at bugs.python.org (Enji Cooper) Date: Tue, 26 Feb 2019 02:05:49 +0000 Subject: [issue13497] Fix for broken nice test on non-broken platforms with pedantic compilers In-Reply-To: <1322566155.29.0.23147421321.issue13497@psf.upfronthosting.co.za> Message-ID: <1551146749.39.0.250011399842.issue13497@roundup.psfhosted.org> Change by Enji Cooper : ---------- pull_requests: +12067 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 21:19:14 2019 From: report at bugs.python.org (Eryk Sun) Date: Tue, 26 Feb 2019 02:19:14 +0000 Subject: [issue36102] TestSharedMemory fails on AMD64 FreeBSD CURRENT Shared 3.x In-Reply-To: <1551085417.13.0.962588202568.issue36102@roundup.psfhosted.org> Message-ID: <1551147554.82.0.222537533133.issue36102@roundup.psfhosted.org> Eryk Sun added the comment: > Given that this requirement is not universal and because a leading > slash controls other behaviors on platforms like Windows Forward slash has no special meaning anywhere in the names of NT objects, such as memory Section objects (aka file-mapping objects) and registry Key objects. Only the file API translates forward slash to backslash, and that's only implemented for the sake of DOS compatibility in a few core functions that normalize and translate DOS paths. Maybe you're thinking of the "Global\\" and "Session\\" prefixes for named kernel objects, which require a backslash since the name is really a handle-relative NT path. The session's object directory contains object symbolic links named "Global" and "Session". A name such as "Global\spam" resolves to "spam" in the global object directory, but "Global/spam", with forward slash, is just a regular name in the local directory. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 21:29:06 2019 From: report at bugs.python.org (Eric Snow) Date: Tue, 26 Feb 2019 02:29:06 +0000 Subject: [issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed. In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za> Message-ID: <1551148146.82.0.295863276171.issue33608@roundup.psfhosted.org> Eric Snow added the comment: At least, it *might* be a performance regression. Here are the two commits I tried: after: ef4ac967e2f3a9a18330cc6abe14adb4bc3d0465 (PR #11617, from this issue) before: 463572c8beb59fd9d6850440af48a5c5f4c0c0c9 (the one right before) After building each (a normal build, not debug), I ran the micro-benchmark Raymond referred to ("./python Tools/scripts/var_access_benchmark.py") multiple times. There was enough variability between runs from the same commit that I'm uncertain at this point if there really is any performance regression. For the most part the results between the two commits are really close. Also, the results from the "after" commit fall within the variability I've seen between runs of the "before" commit. I'm going to try with the "performance" suite (https://github.com/python/performance) to see if it shows any regression. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 21:32:10 2019 From: report at bugs.python.org (Eryk Sun) Date: Tue, 26 Feb 2019 02:32:10 +0000 Subject: [issue36112] os.path.realpath on windows and substed drives In-Reply-To: <1551136910.4.0.075710439537.issue36112@roundup.psfhosted.org> Message-ID: <1551148330.8.0.406019661835.issue36112@roundup.psfhosted.org> Eryk Sun added the comment: In Windows, realpath is currently an alias for abspath. Issue 14094 has a pending PR that implements realpath, but it's waiting on improved tests and final approval. I'm afraid it won't make it into 3.8. I suggest using the resolve() method of a pathlib.Path. For example: >>> os.system('subst W: C:\\Windows') 0 >>> pathlib.Path('W:\\').resolve() WindowsPath('C:/Windows') ---------- nosy: +eryksun resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> ntpath.realpath() should use GetFinalPathNameByHandle() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 22:03:58 2019 From: report at bugs.python.org (Jarry Shaw) Date: Tue, 26 Feb 2019 03:03:58 +0000 Subject: [issue34785] pty.spawn -- auto-termination after child process is dead (a zombie) In-Reply-To: <1537773919.52.0.956365154283.issue34785@psf.upfronthosting.co.za> Message-ID: <1551150238.49.0.471927835408.issue34785@roundup.psfhosted.org> Jarry Shaw added the comment: This issue is duplicated with issue26228, sorry. ---------- stage: patch review -> resolved status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 22:11:27 2019 From: report at bugs.python.org (Saba Kauser) Date: Tue, 26 Feb 2019 03:11:27 +0000 Subject: [issue36075] python 2to3 conversion tool is generating file with extra line for every input line In-Reply-To: <1550828319.37.0.854628356141.issue36075@roundup.psfhosted.org> Message-ID: <1551150687.03.0.877335217323.issue36075@roundup.psfhosted.org> Saba Kauser added the comment: Did anyone get a chance to look at my case? Thanks, Saba. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 22:20:03 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 26 Feb 2019 03:20:03 +0000 Subject: [issue35512] patch.dict resolves in_dict eagerly (should be late resolved) In-Reply-To: <1544993007.41.0.788709270274.issue35512@psf.upfronthosting.co.za> Message-ID: <1551151203.75.0.668568066494.issue35512@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Closing this as resolved. @jaraco this just made it to 3.8.0 alpha 2, feel free to reopen this if needed. Thanks Mario and Chris for review and merge :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 22:20:26 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 26 Feb 2019 03:20:26 +0000 Subject: [issue35512] patch.dict resolves in_dict eagerly (should be late resolved) In-Reply-To: <1544993007.41.0.788709270274.issue35512@psf.upfronthosting.co.za> Message-ID: <1551151226.38.0.927061657671.issue35512@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 22:21:12 2019 From: report at bugs.python.org (Jarry Shaw) Date: Tue, 26 Feb 2019 03:21:12 +0000 Subject: [issue26228] pty.spawn hangs on FreeBSD 9.3, 10.x In-Reply-To: <1453953861.58.0.104331734212.issue26228@psf.upfronthosting.co.za> Message-ID: <1551151272.02.0.958119297119.issue26228@roundup.psfhosted.org> Jarry Shaw added the comment: Chris' patch works on macOS 10.14 (Mojave); but after it terminates, tty attributes are not restored (new-lines are missing). btw, I've implemented a workaround library with solution through either `ps` command or `psutil` package, see `ptyng` on PyPI. ---------- nosy: +jarryshaw _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 22:43:02 2019 From: report at bugs.python.org (Enji Cooper) Date: Tue, 26 Feb 2019 03:43:02 +0000 Subject: [issue36111] Non-zero `offset`s are no longer acceptable with implementation of `seek` in some cases with python3 when in text mode; should be per POSIX In-Reply-To: <1551132722.44.0.748659725129.issue36111@roundup.psfhosted.org> Message-ID: <1551152582.62.0.915879267185.issue36111@roundup.psfhosted.org> Change by Enji Cooper : ---------- title: Negative `offset` values are no longer acceptable with implementation of `seek` with python3 when in text mode; should be per POSIX -> Non-zero `offset`s are no longer acceptable with implementation of `seek` in some cases with python3 when in text mode; should be per POSIX _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 22:43:53 2019 From: report at bugs.python.org (Enji Cooper) Date: Tue, 26 Feb 2019 03:43:53 +0000 Subject: [issue36111] Non-zero `offset`s are no longer acceptable with SEEK_END/SEEK_CUR implementation of `seek` in python3 when in text mode, breaking py 2.x behavior/POSIX In-Reply-To: <1551132722.44.0.748659725129.issue36111@roundup.psfhosted.org> Message-ID: <1551152633.76.0.770514144298.issue36111@roundup.psfhosted.org> Change by Enji Cooper : ---------- title: Non-zero `offset`s are no longer acceptable with implementation of `seek` in some cases with python3 when in text mode; should be per POSIX -> Non-zero `offset`s are no longer acceptable with SEEK_END/SEEK_CUR implementation of `seek` in python3 when in text mode, breaking py 2.x behavior/POSIX _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 23:10:24 2019 From: report at bugs.python.org (Eric Snow) Date: Tue, 26 Feb 2019 04:10:24 +0000 Subject: [issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed. In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za> Message-ID: <1551154224.46.0.696199819315.issue33608@roundup.psfhosted.org> Eric Snow added the comment: Here's what I did (more or less): $ python3 -m pip install --user perf $ python3 -m perf system tune $ git clone git at github.com:python/performance.git $ git clone git at github.com:python/cpython.git $ cd cpython $ git checkout ef4ac967e2f3a9a18330cc6abe14adb4bc3d0465 $ ./configure $ make -j8 $ ./python ../performance/pyperformance run --fast --output speed.after $ git checkout HEAD^ $ make -j8 $ ./python ../performance/pyperformance run --fast --output speed.before $ ./python ../performance/pyperformance compare speed.before speed.after -O table Here are my results: speed.before ============ Performance version: 0.7.0 Report on Linux-4.15.0-45-generic-x86_64-with-glibc2.26 Number of logical CPUs: 4 Start date: 2019-02-25 20:39:44.151699 End date: 2019-02-25 20:48:04.817516 speed.after =========== Performance version: 0.7.0 Report on Linux-4.15.0-45-generic-x86_64-with-glibc2.26 Number of logical CPUs: 4 Start date: 2019-02-25 20:29:56.610702 End date: 2019-02-25 20:38:11.667461 +-------------------------+--------------+-------------+--------------+-----------------------+ | Benchmark | speed.before | speed.after | Change | Significance | +=========================+==============+=============+==============+=======================+ | 2to3 | 447 ms | 440 ms | 1.02x faster | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | chaos | 155 ms | 156 ms | 1.01x slower | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | crypto_pyaes | 154 ms | 152 ms | 1.01x faster | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | deltablue | 10.7 ms | 10.5 ms | 1.01x faster | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | django_template | 177 ms | 172 ms | 1.03x faster | Significant (t=3.66) | +-------------------------+--------------+-------------+--------------+-----------------------+ | dulwich_log | 105 ms | 106 ms | 1.01x slower | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | fannkuch | 572 ms | 573 ms | 1.00x slower | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | float | 149 ms | 146 ms | 1.02x faster | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | go | 351 ms | 349 ms | 1.00x faster | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | hexiom | 14.6 ms | 14.4 ms | 1.01x faster | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | html5lib | 126 ms | 122 ms | 1.03x faster | Significant (t=3.46) | +-------------------------+--------------+-------------+--------------+-----------------------+ | json_dumps | 17.6 ms | 17.2 ms | 1.02x faster | Significant (t=2.65) | +-------------------------+--------------+-------------+--------------+-----------------------+ | json_loads | 36.4 us | 36.1 us | 1.01x faster | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | logging_format | 15.2 us | 14.9 us | 1.02x faster | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | logging_silent | 292 ns | 296 ns | 1.01x slower | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | logging_simple | 13.7 us | 13.4 us | 1.02x faster | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | mako | 22.9 ms | 22.5 ms | 1.02x faster | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | meteor_contest | 134 ms | 134 ms | 1.00x faster | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | nbody | 157 ms | 161 ms | 1.03x slower | Significant (t=-3.85) | +-------------------------+--------------+-------------+--------------+-----------------------+ | nqueens | 134 ms | 132 ms | 1.02x faster | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | pathlib | 30.1 ms | 31.0 ms | 1.03x slower | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | pickle | 11.5 us | 11.6 us | 1.01x slower | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | pickle_dict | 29.5 us | 30.5 us | 1.03x slower | Significant (t=-6.37) | +-------------------------+--------------+-------------+--------------+-----------------------+ | pickle_list | 4.54 us | 4.58 us | 1.01x slower | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | pickle_pure_python | 652 us | 651 us | 1.00x faster | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | pidigits | 212 ms | 215 ms | 1.02x slower | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | python_startup | 11.6 ms | 11.5 ms | 1.01x faster | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | python_startup_no_site | 8.07 ms | 7.95 ms | 1.01x faster | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | raytrace | 729 ms | 722 ms | 1.01x faster | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | regex_compile | 249 ms | 247 ms | 1.01x faster | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | regex_dna | 203 ms | 204 ms | 1.00x slower | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | regex_effbot | 3.55 ms | 3.55 ms | 1.00x faster | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | regex_v8 | 28.3 ms | 28.3 ms | 1.00x slower | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | richards | 105 ms | 105 ms | 1.00x faster | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | scimark_fft | 429 ms | 436 ms | 1.01x slower | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | scimark_lu | 238 ms | 237 ms | 1.00x faster | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | scimark_monte_carlo | 144 ms | 139 ms | 1.04x faster | Significant (t=3.61) | +-------------------------+--------------+-------------+--------------+-----------------------+ | scimark_sor | 265 ms | 260 ms | 1.02x faster | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | scimark_sparse_mat_mult | 5.41 ms | 5.25 ms | 1.03x faster | Significant (t=4.26) | +-------------------------+--------------+-------------+--------------+-----------------------+ | spectral_norm | 174 ms | 173 ms | 1.01x faster | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | sqlalchemy_declarative | 216 ms | 214 ms | 1.01x faster | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | sqlalchemy_imperative | 41.6 ms | 41.2 ms | 1.01x faster | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | sqlite_synth | 3.99 us | 3.91 us | 1.02x faster | Significant (t=2.49) | +-------------------------+--------------+-------------+--------------+-----------------------+ | sympy_expand | 559 ms | 559 ms | 1.00x faster | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | sympy_integrate | 25.2 ms | 25.3 ms | 1.00x slower | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | sympy_str | 261 ms | 260 ms | 1.00x faster | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | sympy_sum | 136 ms | 138 ms | 1.01x slower | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | telco | 8.36 ms | 8.32 ms | 1.00x faster | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | tornado_http | 273 ms | 271 ms | 1.01x faster | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | unpack_sequence | 58.8 ns | 60.0 ns | 1.02x slower | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | unpickle | 21.5 us | 21.5 us | 1.00x faster | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | unpickle_list | 5.60 us | 5.55 us | 1.01x faster | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | unpickle_pure_python | 497 us | 481 us | 1.03x faster | Significant (t=5.04) | +-------------------------+--------------+-------------+--------------+-----------------------+ | xml_etree_generate | 141 ms | 140 ms | 1.01x faster | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | xml_etree_iterparse | 131 ms | 133 ms | 1.01x slower | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | xml_etree_parse | 186 ms | 187 ms | 1.00x slower | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ | xml_etree_process | 115 ms | 113 ms | 1.01x faster | Not significant | +-------------------------+--------------+-------------+--------------+-----------------------+ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 23:11:45 2019 From: report at bugs.python.org (Eric Snow) Date: Tue, 26 Feb 2019 04:11:45 +0000 Subject: [issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed. In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za> Message-ID: <1551154305.98.0.928228636864.issue33608@roundup.psfhosted.org> Eric Snow added the comment: ...so it doesn't appear that my PR introduces a performance regression. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 25 23:42:25 2019 From: report at bugs.python.org (N. Srinivasan) Date: Tue, 26 Feb 2019 04:42:25 +0000 Subject: [issue36113] Problem With SciPy Computation of sigma Message-ID: <1551156145.2.0.780333517951.issue36113@roundup.psfhosted.org> New submission from N. Srinivasan : """ Construct normal probability plot """ import math import scipy.stats as ss import numpy as np import matplotlib.pyplot as plt import seaborn as sns import prettytable from random import seed seed(100) ################ mu = 0.0 sigma = 1.0 x = np.linspace(mu - 5*sigma, mu + 5*sigma, 10) norm_pdf_x= ss.norm.pdf(x,mu,sigma) plt.plot(x,norm_pdf_x) print("The Std. Dev. of normally Dist. x =", np.std(norm_pdf_x)) print() ########################################### Produces a wrong Result for sigma: The Std. Dev. of normally Dist. x = 0.13142071847657633 Should be 1.0 ---------- components: Library (Lib) files: test_normal.py messages: 336604 nosy: nisthesecond priority: normal severity: normal status: open title: Problem With SciPy Computation of sigma versions: Python 3.7 Added file: https://bugs.python.org/file48170/test_normal.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 00:16:06 2019 From: report at bugs.python.org (Berker Peksag) Date: Tue, 26 Feb 2019 05:16:06 +0000 Subject: [issue36113] Problem With SciPy Computation of sigma In-Reply-To: <1551156145.2.0.780333517951.issue36113@roundup.psfhosted.org> Message-ID: <1551158166.34.0.00333927745322.issue36113@roundup.psfhosted.org> Berker Peksag added the comment: This tracker is for issues with the Python programming language and its standard library. SciPy is not part of the standard library. Please use SciPy project's support channels to get help for your problem. Thank you! ---------- nosy: +berker.peksag resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 00:26:43 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Feb 2019 05:26:43 +0000 Subject: [issue36111] Non-zero `offset`s are no longer acceptable with SEEK_END/SEEK_CUR implementation of `seek` in python3 when in text mode, breaking py 2.x behavior/POSIX In-Reply-To: <1551132722.44.0.748659725129.issue36111@roundup.psfhosted.org> Message-ID: <1551158803.47.0.73949706236.issue36111@roundup.psfhosted.org> Serhiy Storchaka added the comment: This does not have relation to POSIX, since POSIX says nothing about Unicode files. "Text mode" in POSIX means binary files with converted newlines. This mode is not supported in Python 3. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 00:34:27 2019 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 26 Feb 2019 05:34:27 +0000 Subject: [issue13497] Fix for broken nice test on non-broken platforms with pedantic compilers In-Reply-To: <1322566155.29.0.23147421321.issue13497@psf.upfronthosting.co.za> Message-ID: <1551159267.67.0.626123006143.issue13497@roundup.psfhosted.org> Benjamin Peterson added the comment: New changeset 90c6facebd5666fec85f125ee2795b48b30319a4 by Benjamin Peterson (ngie-eign) in branch 'master': closes bpo-13497: Fix `broken nice` configure test. (GH-12041) https://github.com/python/cpython/commit/90c6facebd5666fec85f125ee2795b48b30319a4 ---------- nosy: +benjamin.peterson resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 00:34:42 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 26 Feb 2019 05:34:42 +0000 Subject: [issue13497] Fix for broken nice test on non-broken platforms with pedantic compilers In-Reply-To: <1322566155.29.0.23147421321.issue13497@psf.upfronthosting.co.za> Message-ID: <1551159282.22.0.172032665985.issue13497@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +12068 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 00:34:51 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 26 Feb 2019 05:34:51 +0000 Subject: [issue13497] Fix for broken nice test on non-broken platforms with pedantic compilers In-Reply-To: <1322566155.29.0.23147421321.issue13497@psf.upfronthosting.co.za> Message-ID: <1551159291.24.0.156022874805.issue13497@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +12069 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 00:38:59 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Feb 2019 05:38:59 +0000 Subject: [issue36109] test_descr fails on AMD64 Windows8 3.x buildbots In-Reply-To: <1551129344.76.0.345137125147.issue36109@roundup.psfhosted.org> Message-ID: <1551159539.55.0.823758309624.issue36109@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- keywords: +patch pull_requests: +12070 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 00:49:46 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 26 Feb 2019 05:49:46 +0000 Subject: [issue36109] test_descr fails on AMD64 Windows8 3.x buildbots In-Reply-To: <1551129344.76.0.345137125147.issue36109@roundup.psfhosted.org> Message-ID: <1551160186.16.0.760016794424.issue36109@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: Although PR12004 fixes the problem, something a bit more fundamental may have changed. I have spent time investigating why this is happening and the problem is that in the line: self.assertEqual(c.attr, 1) Evil.__eq__ is invoked twice where before it was only invoked once. This does not happen all the time, and it seems to only happen under some combination of hashes in the class dictionary, being the extra __eq__ invocation a check for equality when looking up attr in the c object. When the test succeeds, the extra check is not done (and therefore the attribute is not deleted). I think this happens because some identity is used to check when doing the lookup (comparing the pointers) but I would like to understand exactly how the hash is influencing the different code paths to be sure that nothing important has changed recently. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 00:50:04 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 26 Feb 2019 05:50:04 +0000 Subject: [issue36109] test_descr fails on AMD64 Windows8 3.x buildbots In-Reply-To: <1551129344.76.0.345137125147.issue36109@roundup.psfhosted.org> Message-ID: <1551160204.75.0.225285331668.issue36109@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- Removed message: https://bugs.python.org/msg336608 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 00:50:16 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 26 Feb 2019 05:50:16 +0000 Subject: [issue36109] test_descr fails on AMD64 Windows8 3.x buildbots In-Reply-To: <1551129344.76.0.345137125147.issue36109@roundup.psfhosted.org> Message-ID: <1551160216.78.0.997509236851.issue36109@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: Although 12044 fixes the problem, something a bit more fundamental may have changed. I have spent time investigating why this is happening and the problem is that in the line: self.assertEqual(c.attr, 1) Evil.__eq__ is invoked twice where before it was only invoked once. This does not happen all the time, and it seems to only happen under some combination of hashes in the class dictionary, being the extra __eq__ invocation a check for equality when looking up attr in the c object. When the test succeeds, the extra check is not done (and therefore the attribute is not deleted). I think this happens because some identity is used to check when doing the lookup (comparing the pointers) but I would like to understand exactly how the hash is influencing the different code paths to be sure that nothing important has changed recently. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 00:54:36 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 26 Feb 2019 05:54:36 +0000 Subject: [issue13497] Fix for broken nice test on non-broken platforms with pedantic compilers In-Reply-To: <1322566155.29.0.23147421321.issue13497@psf.upfronthosting.co.za> Message-ID: <1551160476.01.0.534958772181.issue13497@roundup.psfhosted.org> miss-islington added the comment: New changeset a0f656d310bdd08aaaa6f1e186bc7a4174e4068f by Miss Islington (bot) in branch '2.7': closes bpo-13497: Fix `broken nice` configure test. (GH-12041) https://github.com/python/cpython/commit/a0f656d310bdd08aaaa6f1e186bc7a4174e4068f ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 00:59:17 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 26 Feb 2019 05:59:17 +0000 Subject: [issue13497] Fix for broken nice test on non-broken platforms with pedantic compilers In-Reply-To: <1322566155.29.0.23147421321.issue13497@psf.upfronthosting.co.za> Message-ID: <1551160757.03.0.282876165206.issue13497@roundup.psfhosted.org> miss-islington added the comment: New changeset 2055ebb940a737b1375435209c37eae535f062f9 by Miss Islington (bot) in branch '3.7': closes bpo-13497: Fix `broken nice` configure test. (GH-12041) https://github.com/python/cpython/commit/2055ebb940a737b1375435209c37eae535f062f9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 01:00:08 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 26 Feb 2019 06:00:08 +0000 Subject: [issue36109] test_descr fails on AMD64 Windows8 3.x buildbots In-Reply-To: <1551129344.76.0.345137125147.issue36109@roundup.psfhosted.org> Message-ID: <1551160808.48.0.323763418865.issue36109@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: Ok, actually this turns to be much easier: Sometimes __eq__ was also called twice but now as we use PyDict_GetItemWithError instead of PyDict_GetItem, if the extra __eq__ happens as a consequence of a dict lookup the error is ignored so that was the reason the test was not failing before. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 01:03:23 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 26 Feb 2019 06:03:23 +0000 Subject: [issue36109] test_descr fails on AMD64 Windows8 3.x buildbots In-Reply-To: <1551129344.76.0.345137125147.issue36109@roundup.psfhosted.org> Message-ID: <1551161003.91.0.317121088846.issue36109@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: New changeset ff3d39faa8aa28308cc5eae6843eaac514da8fd8 by Pablo Galindo (Serhiy Storchaka) in branch 'master': bpo-36109: Fix random test_descr failure. (GH-12044) https://github.com/python/cpython/commit/ff3d39faa8aa28308cc5eae6843eaac514da8fd8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 01:03:51 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 26 Feb 2019 06:03:51 +0000 Subject: [issue36109] test_descr fails on AMD64 Windows8 3.x buildbots In-Reply-To: <1551129344.76.0.345137125147.issue36109@roundup.psfhosted.org> Message-ID: <1551161031.25.0.761542167823.issue36109@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 01:05:27 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 26 Feb 2019 06:05:27 +0000 Subject: [issue36109] test_descr fails on AMD64 Windows8 3.x buildbots In-Reply-To: <1551129344.76.0.345137125147.issue36109@roundup.psfhosted.org> Message-ID: <1551161127.88.0.237102034991.issue36109@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: A lot of buildbots were failing for this test so a lot of them will become green after ff3d39faa8aa28308cc5eae6843eaac514da8fd8. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 01:09:51 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 26 Feb 2019 06:09:51 +0000 Subject: [issue36114] test_multiprocessing_spawn changes the execution environment Message-ID: <1551161391.14.0.479239981135.issue36114@roundup.psfhosted.org> New submission from Pablo Galindo Salgado : OK (skipped=32) Warning -- files was modified by test_multiprocessing_spawn Before: [] After: ['python.core'] https://buildbot.python.org/all/#/builders/168/builds/632/steps/4/logs/stdio ---------- components: Tests messages: 336615 nosy: pablogsal priority: normal severity: normal status: open title: test_multiprocessing_spawn changes the execution environment versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 01:14:58 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 26 Feb 2019 06:14:58 +0000 Subject: [issue36114] test_multiprocessing_spawn changes the execution environment In-Reply-To: <1551161391.14.0.479239981135.issue36114@roundup.psfhosted.org> Message-ID: <1551161698.87.0.0930219989077.issue36114@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: Another failure: https://buildbot.python.org/all/#/builders/168/builds/633 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 01:31:08 2019 From: report at bugs.python.org (Inada Naoki) Date: Tue, 26 Feb 2019 06:31:08 +0000 Subject: [issue36111] Non-zero `offset`s are no longer acceptable with SEEK_END/SEEK_CUR implementation of `seek` in python3 when in text mode, breaking py 2.x behavior/POSIX In-Reply-To: <1551132722.44.0.748659725129.issue36111@roundup.psfhosted.org> Message-ID: <1551162668.93.0.104012430994.issue36111@roundup.psfhosted.org> Change by Inada Naoki : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 01:32:35 2019 From: report at bugs.python.org (Inada Naoki) Date: Tue, 26 Feb 2019 06:32:35 +0000 Subject: [issue36111] Non-zero `offset`s are no longer acceptable with SEEK_END/SEEK_CUR implementation of `seek` in python3 when in text mode, breaking py 2.x behavior/POSIX In-Reply-To: <1551132722.44.0.748659725129.issue36111@roundup.psfhosted.org> Message-ID: <1551162755.64.0.811699811988.issue36111@roundup.psfhosted.org> Inada Naoki added the comment: If you want byte IO, you can use "rb" mode. You can seek on it. ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 01:36:17 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Feb 2019 06:36:17 +0000 Subject: [issue36106] resolve sinpi() name clash with libm In-Reply-To: <1551102423.19.0.037549170544.issue36106@roundup.psfhosted.org> Message-ID: <1551162977.74.0.295620977939.issue36106@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset f57cd8288dbe6aba99c057f37ad6d58f8db75350 by Serhiy Storchaka (Dima Pasechnik) in branch 'master': bpo-36106: Resolve sinpi name clash with libm (IEEE-754 violation). (GH-12027) https://github.com/python/cpython/commit/f57cd8288dbe6aba99c057f37ad6d58f8db75350 ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 01:36:25 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 26 Feb 2019 06:36:25 +0000 Subject: [issue36106] resolve sinpi() name clash with libm In-Reply-To: <1551102423.19.0.037549170544.issue36106@roundup.psfhosted.org> Message-ID: <1551162985.3.0.962572923698.issue36106@roundup.psfhosted.org> Change by miss-islington : ---------- keywords: +patch pull_requests: +12071 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 01:50:24 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 26 Feb 2019 06:50:24 +0000 Subject: [issue36114] test_multiprocessing_spawn changes the execution environment In-Reply-To: <1551161391.14.0.479239981135.issue36114@roundup.psfhosted.org> Message-ID: <1551163824.85.0.162714804637.issue36114@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- nosy: +koobs -pablogsal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 01:50:34 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 26 Feb 2019 06:50:34 +0000 Subject: [issue36114] test_multiprocessing_spawn changes the execution environment In-Reply-To: <1551161391.14.0.479239981135.issue36114@roundup.psfhosted.org> Message-ID: <1551163834.6.0.898903875744.issue36114@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- nosy: +pablogsal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 01:54:50 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 26 Feb 2019 06:54:50 +0000 Subject: [issue36115] test_ctypes leaks references and memory blocks Message-ID: <1551164090.87.0.472334012156.issue36115@roundup.psfhosted.org> New submission from Pablo Galindo Salgado : https://buildbot.python.org/all/#/builders/1/builds/515 OK (skipped=89) . test_ctypes leaked [72, 72, 72] references, sum=216 test_ctypes leaked [26, 26, 26] memory blocks, sum=78 2 tests failed again: test_ctypes test_inspect == Tests result: FAILURE then FAILURE == ---------- components: Tests, ctypes messages: 336619 nosy: pablogsal priority: normal severity: normal status: open title: test_ctypes leaks references and memory blocks versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 02:02:56 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 26 Feb 2019 07:02:56 +0000 Subject: [issue36114] test_multiprocessing_spawn changes the execution environment In-Reply-To: <1551161391.14.0.479239981135.issue36114@roundup.psfhosted.org> Message-ID: <1551164576.36.0.846746884042.issue36114@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: PR12045 fixes this ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 02:03:30 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 26 Feb 2019 07:03:30 +0000 Subject: [issue36114] test_multiprocessing_spawn changes the execution environment In-Reply-To: <1551161391.14.0.479239981135.issue36114@roundup.psfhosted.org> Message-ID: <1551164610.9.0.856623890654.issue36114@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- Removed message: https://bugs.python.org/msg336620 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 02:04:34 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 26 Feb 2019 07:04:34 +0000 Subject: [issue36115] test_ctypes leaks references and memory blocks In-Reply-To: <1551164090.87.0.472334012156.issue36115@roundup.psfhosted.org> Message-ID: <1551164674.77.0.151400759726.issue36115@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: PR12045 fixes this ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 02:06:39 2019 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 26 Feb 2019 07:06:39 +0000 Subject: [issue36115] test_ctypes leaks references and memory blocks In-Reply-To: <1551164090.87.0.472334012156.issue36115@roundup.psfhosted.org> Message-ID: <1551164799.44.0.886543029322.issue36115@roundup.psfhosted.org> Change by Benjamin Peterson : ---------- keywords: +patch pull_requests: +12072 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 02:10:58 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 26 Feb 2019 07:10:58 +0000 Subject: [issue36106] resolve sinpi() name clash with libm In-Reply-To: <1551102423.19.0.037549170544.issue36106@roundup.psfhosted.org> Message-ID: <1551165058.98.0.809515758209.issue36106@roundup.psfhosted.org> miss-islington added the comment: New changeset 4e6646fef5d2cc53422e4eca0b18201ed5a5c4b6 by Miss Islington (bot) in branch '3.7': bpo-36106: Resolve sinpi name clash with libm (IEEE-754 violation). (GH-12027) https://github.com/python/cpython/commit/4e6646fef5d2cc53422e4eca0b18201ed5a5c4b6 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 02:12:05 2019 From: report at bugs.python.org (Inada Naoki) Date: Tue, 26 Feb 2019 07:12:05 +0000 Subject: [issue36103] Increase shutil.COPY_BUFSIZE In-Reply-To: <1551117664.72.0.122434540092.issue36103@roundup.psfhosted.org> Message-ID: Inada Naoki added the comment: > > desbma added the comment: > > If you do a benchmark by reading from a file, and then writing to /dev/null several times, without clearing caches, you are measuring *only* the syscall overhead: > * input data is read from the Linux page cache, not the file on your SSD itself Yes. I measures syscall overhead to determine reasonable buffer size. shutil may be used when page cache is warm. > * no data is written (obviously because output is /dev/null) As I said before, my SSD doesn't have stable write performance. (It is typical for consumer SSD). So this is intensional. And there are use cases copy from/to io.BytesIO or other file-like objects. > > Your current command line also measures open/close timings, without that I think the speed should linearly increase when doubling buffer size, but of course this is misleading, because its a synthetic benchmark. I'm not measuring speed of my cheap SSD. The goal of this benchmark is finding reasonable buffer size. There are vary real usages. So reducing syscall overhead with reasonable buffer size is worth enough. > > Also if you clear caches in between tests, and write the output file to the SSD itself, sendfile will be used, and should be even faster. No. sendfile is not used by shutil.copyfileobj, even if dst is real file on disk. > > So again I'm not sure this means much compared to real world usage. > "Real world usage" is vary. Sometime it is not affected. Sometime it affects. On the other hand, what is the cons of changing 16KiB to 64KiB? Windows used 1MiB already. And CPython runtime uses a few MBs of memory too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 02:12:13 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 26 Feb 2019 07:12:13 +0000 Subject: [issue36115] test_ctypes leaks references and memory blocks In-Reply-To: <1551164090.87.0.472334012156.issue36115@roundup.psfhosted.org> Message-ID: <1551165133.86.0.900626267901.issue36115@roundup.psfhosted.org> miss-islington added the comment: New changeset d5a551c2694e32835bcdafc01d611f3227ca36b3 by Miss Islington (bot) (Benjamin Peterson) in branch 'master': closes bpo-36115: Fix some reference leaks in typeobject.c. (GH-12045) https://github.com/python/cpython/commit/d5a551c2694e32835bcdafc01d611f3227ca36b3 ---------- nosy: +miss-islington resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 02:13:43 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 26 Feb 2019 07:13:43 +0000 Subject: [issue36116] test_multiprocessing_spawn fails on AMD64 Windows8 3.x Message-ID: <1551165223.62.0.963183120667.issue36116@roundup.psfhosted.org> New submission from Pablo Galindo Salgado : test test_multiprocessing_spawn failed test_import (test.test_multiprocessing_spawn._TestImportStar) ... ok ====================================================================== FAIL: test_mymanager_context (test.test_multiprocessing_spawn.WithManagerTestMyManager) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\buildarea\3.x.bolen-windows8\build\lib\test\_test_multiprocessing.py", line 2747, in test_mymanager_context self.assertIn(manager._process.exitcode, (0, -signal.SIGTERM)) AssertionError: 3221225477 not found in (0, -15) ---------------------------------------------------------------------- Ran 344 tests in 328.196s FAILED (failures=1, skipped=40) 1 test failed again: test_multiprocessing_spawn == Tests result: FAILURE then FAILURE == https://buildbot.python.org/all/#/builders/32/builds/2204/steps/3/logs/stdio ---------- components: Tests, Windows messages: 336625 nosy: pablogsal, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: test_multiprocessing_spawn fails on AMD64 Windows8 3.x versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 02:21:47 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 26 Feb 2019 07:21:47 +0000 Subject: [issue36116] test_multiprocessing_spawn fails on AMD64 Windows8 3.x In-Reply-To: <1551165223.62.0.963183120667.issue36116@roundup.psfhosted.org> Message-ID: <1551165707.67.0.9421469792.issue36116@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: It also fails on Windows 7: https://buildbot.python.org/all/#/builders/58/builds/1983/steps/3/logs/stdio ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 02:28:34 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 26 Feb 2019 07:28:34 +0000 Subject: [issue36116] test_multiprocessing_spawn fails on AMD64 Windows8 3.x In-Reply-To: <1551165223.62.0.963183120667.issue36116@roundup.psfhosted.org> Message-ID: <1551166114.97.0.55097441657.issue36116@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: It seems that return code 3221225477 in Windows is: #define STATUS_ACCESS_VIOLATION ((NTSTATUS)0xC0000005L) so this is a segfault in the manager. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 02:54:27 2019 From: report at bugs.python.org (Eryk Sun) Date: Tue, 26 Feb 2019 07:54:27 +0000 Subject: [issue32986] multiprocessing, default assumption of Pool size unhelpful In-Reply-To: <1520013089.33.0.467229070634.issue32986@psf.upfronthosting.co.za> Message-ID: <1551167667.4.0.872565069467.issue32986@roundup.psfhosted.org> Change by Eryk Sun : ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 03:04:22 2019 From: report at bugs.python.org (Brandt Bucher) Date: Tue, 26 Feb 2019 08:04:22 +0000 Subject: [issue36117] Allow rich comparisons for real-valued complex objects. Message-ID: <1551168262.55.0.429171834399.issue36117@roundup.psfhosted.org> New submission from Brandt Bucher : Currently, it isn't legal to perform <, >, <=, or >= rich comparisons on any complex objects, even though these operations are mathematically well-defined for real numbers. The attached PR addresses this by defining rich comparisons for real-valued complex objects against subclasses of int and float, as well as for decimal.Decimal and fractions.Fraction types. They still raise TypeErrors when either of the operands has a nonzero imaginary part. ---------- components: Interpreter Core messages: 336628 nosy: brandtbucher priority: normal severity: normal status: open title: Allow rich comparisons for real-valued complex objects. type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 03:04:36 2019 From: report at bugs.python.org (Brandt Bucher) Date: Tue, 26 Feb 2019 08:04:36 +0000 Subject: [issue36117] Allow rich comparisons for real-valued complex objects. In-Reply-To: <1551168262.55.0.429171834399.issue36117@roundup.psfhosted.org> Message-ID: <1551168276.99.0.389172824834.issue36117@roundup.psfhosted.org> Change by Brandt Bucher : ---------- keywords: +patch pull_requests: +12073 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 03:21:14 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Feb 2019 08:21:14 +0000 Subject: [issue36117] Allow rich comparisons for real-valued complex objects. In-Reply-To: <1551168262.55.0.429171834399.issue36117@roundup.psfhosted.org> Message-ID: <1551169274.48.0.779744484587.issue36117@roundup.psfhosted.org> Serhiy Storchaka added the comment: I don't think we should do this. In numerical computation we should not depend on exact floating point values, because is affected by computation errors. It would be hard to debug the program when some complex numbers are orderable, but other are not, and the difference between formers and latters is insignificant. ---------- nosy: +mark.dickinson, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 03:22:35 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Feb 2019 08:22:35 +0000 Subject: [issue36117] Allow rich comparisons for real-valued complex objects. In-Reply-To: <1551168262.55.0.429171834399.issue36117@roundup.psfhosted.org> Message-ID: <1551169355.39.0.959127601259.issue36117@roundup.psfhosted.org> Serhiy Storchaka added the comment: If you need to order real-valued complex object, convert them to float objects first. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 03:30:05 2019 From: report at bugs.python.org (Brandt Bucher) Date: Tue, 26 Feb 2019 08:30:05 +0000 Subject: [issue36117] Allow rich comparisons for real-valued complex objects. In-Reply-To: <1551168262.55.0.429171834399.issue36117@roundup.psfhosted.org> Message-ID: <1551169805.02.0.288011089975.issue36117@roundup.psfhosted.org> Brandt Bucher added the comment: I don't really see, though, how comparing complex(42) == float(42) is any less dangerous than complex(42) <= float(42). It seems odd to me, personally, that real-valued complex objects are valid for *some* rich comparisons (but not others) when the math is unambiguous. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 03:43:01 2019 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 26 Feb 2019 08:43:01 +0000 Subject: [issue36117] Allow rich comparisons for real-valued complex objects. In-Reply-To: <1551168262.55.0.429171834399.issue36117@roundup.psfhosted.org> Message-ID: <1551170581.54.0.212383421975.issue36117@roundup.psfhosted.org> Mark Dickinson added the comment: -1 from me. The rules for when things are comparable or not should be kept simple. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 03:59:25 2019 From: report at bugs.python.org (Kubilay Kocak) Date: Tue, 26 Feb 2019 08:59:25 +0000 Subject: [issue36106] resolve sinpi() name clash with libm In-Reply-To: <1551102423.19.0.037549170544.issue36106@roundup.psfhosted.org> Message-ID: <1551171565.24.0.201323882843.issue36106@roundup.psfhosted.org> Kubilay Kocak added the comment: Downstream issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232792 ---------- nosy: +koobs versions: +Python 2.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 03:59:27 2019 From: report at bugs.python.org (Domenico Barbieri) Date: Tue, 26 Feb 2019 08:59:27 +0000 Subject: [issue36118] Cannot correctly concatenate nested list that contains more than ~45 entries with other nested lists. Message-ID: <1551171567.53.0.226883358106.issue36118@roundup.psfhosted.org> New submission from Domenico Barbieri : Here is an example of what happens: >>> x = [["a", "b", ... , "BZ"]] >>> y = [[], [1,2,3,4,5, ... , 99]] >>> y[0] = x[0] >>> print(y[0]) >>> ["a", "b", "c", ... , "BZ", [1,2,3,4,5, ... , 99]] ---------- messages: 336634 nosy: Domenico Barbieri priority: normal severity: normal status: open title: Cannot correctly concatenate nested list that contains more than ~45 entries with other nested lists. type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 04:21:25 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Tue, 26 Feb 2019 09:21:25 +0000 Subject: [issue36118] Cannot correctly concatenate nested list that contains more than ~45 entries with other nested lists. In-Reply-To: <1551171567.53.0.226883358106.issue36118@roundup.psfhosted.org> Message-ID: <1551172885.24.0.108038861455.issue36118@roundup.psfhosted.org> Steven D'Aprano added the comment: I cannot reproduce the behaviour you show. First problem: ``...`` is a legal Python object, Ellipsis, so your example code literally means: # x = [["a", "b", ... , "BZ"]] x is a list containing one sublist, which contains exactly four objects. So when I run your code as you write it, I get: py> x = [["a", "b", ... , "BZ"]] py> y = [[], [1,2,3,4,5, ... , 99]] py> y[0] = x[0] py> print(y[0]) ['a', 'b', Ellipsis, 'BZ'] which is exactly what I expect. If we use more than 45 entries, as you suggest, I still cannot reproduce your bug report: py> x = [ list(range(0, 100)) ] py> y = [ [], list(range(1000, 1200)) ] py> assert len(x[0]) > 45 py> assert len(y[1]) > 45 py> y[0] = x[0] py> print(y[0]) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99] which is exactly the behaviour I expect. The above is using Python 3.5. I suggest you start from a fresh interpreter session and show precisely what steps needed to reproduce the behaviour you are seeing, and show the behaviour you expect. It might help to read this: http://www.sscce.org/ ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 04:29:00 2019 From: report at bugs.python.org (Geoff Shannon) Date: Tue, 26 Feb 2019 09:29:00 +0000 Subject: [issue26228] pty.spawn hangs on FreeBSD 9.3, 10.x In-Reply-To: <1453953861.58.0.104331734212.issue26228@psf.upfronthosting.co.za> Message-ID: <1551173340.69.0.944282978828.issue26228@roundup.psfhosted.org> Change by Geoff Shannon : ---------- pull_requests: +12074 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 04:50:18 2019 From: report at bugs.python.org (Geoff Shannon) Date: Tue, 26 Feb 2019 09:50:18 +0000 Subject: [issue26228] pty.spawn hangs on FreeBSD 9.3, 10.x In-Reply-To: <1453953861.58.0.104331734212.issue26228@psf.upfronthosting.co.za> Message-ID: <1551174618.38.0.683678753509.issue26228@roundup.psfhosted.org> Geoff Shannon added the comment: I took a shot at fixing this in a smaller more targeted patch. I think this should still solve the major issue of pty.spawn hanging on platforms that don't raise an error. In addition, pty.spawn should now _ALWAYS_ return the terminal to the previous settings. ---------- nosy: +RadicalZephyr _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 04:57:40 2019 From: report at bugs.python.org (Dmitrii Pasechnik) Date: Tue, 26 Feb 2019 09:57:40 +0000 Subject: [issue36106] resolve sinpi() name clash with libm In-Reply-To: <1551102423.19.0.037549170544.issue36106@roundup.psfhosted.org> Message-ID: <1551175060.42.0.221653705229.issue36106@roundup.psfhosted.org> Change by Dmitrii Pasechnik : ---------- pull_requests: +12076 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 04:58:45 2019 From: report at bugs.python.org (Peixing Xin) Date: Tue, 26 Feb 2019 09:58:45 +0000 Subject: [issue31904] Python should support VxWorks RTOS In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za> Message-ID: <1551175125.46.0.0929595676296.issue31904@roundup.psfhosted.org> Change by Peixing Xin : ---------- pull_requests: +12077 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 05:14:58 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Tue, 26 Feb 2019 10:14:58 +0000 Subject: [issue36030] add internal API function to create tuple without items array initialization In-Reply-To: <1550563364.86.0.164811838679.issue36030@roundup.psfhosted.org> Message-ID: <1551176098.03.0.738028639388.issue36030@roundup.psfhosted.org> Change by Sergey Fedoseev : ---------- pull_requests: +12078 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 05:23:02 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Tue, 26 Feb 2019 10:23:02 +0000 Subject: [issue36030] add internal API function to create tuple without items array initialization In-Reply-To: <1550563364.86.0.164811838679.issue36030@roundup.psfhosted.org> Message-ID: <1551176582.54.0.666658051771.issue36030@roundup.psfhosted.org> Sergey Fedoseev added the comment: I added WIP PR with discussed micro-optimization, here are benchmark results: $ python -m perf compare_to --min-speed 1 -G master.json tuple-untracked.json Slower (1): - sqlite_synth: 5.16 us +- 0.10 us -> 5.22 us +- 0.08 us: 1.01x slower (+1%) Faster (19): - python_startup: 12.9 ms +- 0.7 ms -> 12.2 ms +- 0.0 ms: 1.06x faster (-5%) - python_startup_no_site: 8.96 ms +- 0.29 ms -> 8.56 ms +- 0.03 ms: 1.05x faster (-4%) - raytrace: 882 ms +- 11 ms -> 854 ms +- 12 ms: 1.03x faster (-3%) - mako: 27.9 ms +- 0.8 ms -> 27.1 ms +- 0.3 ms: 1.03x faster (-3%) - scimark_monte_carlo: 176 ms +- 4 ms -> 171 ms +- 5 ms: 1.03x faster (-3%) - logging_format: 17.7 us +- 0.4 us -> 17.2 us +- 0.3 us: 1.03x faster (-3%) - telco: 11.0 ms +- 0.2 ms -> 10.8 ms +- 0.4 ms: 1.02x faster (-2%) - richards: 123 ms +- 2 ms -> 120 ms +- 2 ms: 1.02x faster (-2%) - pathlib: 35.1 ms +- 0.7 ms -> 34.6 ms +- 0.5 ms: 1.01x faster (-1%) - scimark_sparse_mat_mult: 6.97 ms +- 0.20 ms -> 6.88 ms +- 0.29 ms: 1.01x faster (-1%) - scimark_sor: 327 ms +- 6 ms -> 323 ms +- 3 ms: 1.01x faster (-1%) - scimark_fft: 570 ms +- 5 ms -> 562 ms +- 4 ms: 1.01x faster (-1%) - float: 184 ms +- 2 ms -> 182 ms +- 2 ms: 1.01x faster (-1%) - logging_simple: 15.8 us +- 0.4 us -> 15.6 us +- 0.3 us: 1.01x faster (-1%) - deltablue: 12.6 ms +- 0.2 ms -> 12.5 ms +- 0.3 ms: 1.01x faster (-1%) - crypto_pyaes: 186 ms +- 2 ms -> 184 ms +- 2 ms: 1.01x faster (-1%) - hexiom: 17.3 ms +- 0.1 ms -> 17.2 ms +- 0.1 ms: 1.01x faster (-1%) - sqlalchemy_declarative: 253 ms +- 4 ms -> 251 ms +- 3 ms: 1.01x faster (-1%) - spectral_norm: 225 ms +- 2 ms -> 223 ms +- 3 ms: 1.01x faster (-1%) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 05:24:03 2019 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 26 Feb 2019 10:24:03 +0000 Subject: [issue36117] Allow rich comparisons for real-valued complex objects. In-Reply-To: <1551168262.55.0.429171834399.issue36117@roundup.psfhosted.org> Message-ID: <1551176643.46.0.663210669549.issue36117@roundup.psfhosted.org> Eric V. Smith added the comment: -1. We don't want to have objects that are orderable depending on their values. I can't think of anywhere else we do this. It would be very easy to have a complex == 42+0.0000001j, after some calculation. This near-zero imaginary part would prevent it from being orderable, while if a similar calculation produced exactly 42+0j, then that instance would be orderable. An application relying on this would be a nightmare to write comprehensive tests for. Whether something is orderable or not should depend solely on its type, not its value. ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 05:32:52 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Tue, 26 Feb 2019 10:32:52 +0000 Subject: [issue36030] add internal API function to create tuple without items array initialization In-Reply-To: <1550563364.86.0.164811838679.issue36030@roundup.psfhosted.org> Message-ID: <1551177172.13.0.127458725403.issue36030@roundup.psfhosted.org> Sergey Fedoseev added the comment: This optimization also can be used for BUILD_TUPLE opcode and in pickle module, if it's OK to add _PyTuple_StealFromArray() function :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 05:41:18 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Feb 2019 10:41:18 +0000 Subject: [issue36106] resolve sinpi() name clash with libm In-Reply-To: <1551102423.19.0.037549170544.issue36106@roundup.psfhosted.org> Message-ID: <1551177678.94.0.061306606728.issue36106@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset b545ba0a508a5980ab147ed2641a42be3b31a2db by Serhiy Storchaka (Dima Pasechnik) in branch '2.7': [2.7] bpo-36106: resolve sinpi name clash with libm (IEEE-754 violation). (GH-12027) (GH-12050) https://github.com/python/cpython/commit/b545ba0a508a5980ab147ed2641a42be3b31a2db ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 05:42:10 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Feb 2019 10:42:10 +0000 Subject: [issue36106] resolve sinpi() name clash with libm In-Reply-To: <1551102423.19.0.037549170544.issue36106@roundup.psfhosted.org> Message-ID: <1551177730.2.0.290845024007.issue36106@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 05:47:13 2019 From: report at bugs.python.org (Andrei Stefan) Date: Tue, 26 Feb 2019 10:47:13 +0000 Subject: [issue36119] Can't add/append in set/list inside shared dict Message-ID: <1551178033.97.0.988149024615.issue36119@roundup.psfhosted.org> New submission from Andrei Stefan : I'm creating a shared dict for multiprocessing purposes: from multiprocessing import Manager manager = Manager() shared_dict = manager.dict() If I add a set or a list as a value in the dict: shared_dict['test'] = set() or shared_dict['test'] = list() I can't add/append in that set/list inside the shared dictionary: shared_dict['test'].add(1234) or shared_dict['test'].append(1234) The following expression: print(dict(shared_dict)) Will return: {'test': set()} or {'test': []}. But if I add in the set/list using operators: shared_dict['test'] |= {1234} or shared_dict['test'] += [1234] It will work: {'test': {1234}} or {'test': [1234]}. ---------- components: Build files: image (2).png messages: 336642 nosy: andrei2peu priority: normal severity: normal status: open title: Can't add/append in set/list inside shared dict type: behavior versions: Python 3.6 Added file: https://bugs.python.org/file48171/image (2).png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 05:55:55 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 26 Feb 2019 10:55:55 +0000 Subject: [issue36109] test_descr: test_vicious_descriptor_nonsense() fails randomly In-Reply-To: <1551129344.76.0.345137125147.issue36109@roundup.psfhosted.org> Message-ID: <1551178555.42.0.353924808095.issue36109@roundup.psfhosted.org> Change by STINNER Victor : ---------- title: test_descr fails on AMD64 Windows8 3.x buildbots -> test_descr: test_vicious_descriptor_nonsense() fails randomly _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 05:59:12 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 26 Feb 2019 10:59:12 +0000 Subject: [issue36103] Increase shutil.COPY_BUFSIZE In-Reply-To: <1551087533.63.0.252770144463.issue36103@roundup.psfhosted.org> Message-ID: <1551178752.34.0.373526070971.issue36103@roundup.psfhosted.org> Giampaolo Rodola' added the comment: @Inada: having played with this in the past I seem to remember that on Linux the bigger bufsize doesn't make a reasonable difference (but I may be wrong), that's why I suggest to try some benchmarks. In issue33671 I pasted some one-liners you can use (and you should target copyfileobj() instead of copyfile() in order to skip the os.sendfile() path). Also on Linux "echo 3 | sudo tee /proc/sys/vm/drop_caches" is supposed to disable the cache. ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 06:01:29 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 26 Feb 2019 11:01:29 +0000 Subject: [issue36119] Can't add/append in set/list inside shared dict In-Reply-To: <1551178033.97.0.988149024615.issue36119@roundup.psfhosted.org> Message-ID: <1551178889.11.0.0755203353472.issue36119@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: https://docs.python.org/3/library/multiprocessing.html#proxy-objects > If standard (non-proxy) list or dict objects are contained in a referent, modifications to those mutable values will not be propagated through the manager because the proxy has no way of knowing when the values contained within are modified. However, storing a value in a container proxy (which triggers a __setitem__ on the proxy object) does propagate through the manager and so to effectively modify such an item, one could re-assign the modified value to the container proxy $ ./python.exe Python 3.8.0a2+ (heads/master:d5a551c269, Feb 26 2019, 15:49:14) [Clang 7.0.2 (clang-700.1.81)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from multiprocessing import Manager >>> man = Manager() >>> shared_list = man.dict() >>> shared_list['a'] = list() >>> shared_list['a'].append(100) >>> shared_list >>> dict(shared_list) {'a': []} >>> shared_list['a'] += [1000] # Update and assign >>> dict(shared_list) {'a': [1000]} >>> shared_list['a'] += [1000] # Update and assign >>> dict(shared_list) {'a': [1000, 1000]} ---------- nosy: +pitrou, xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 06:04:47 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 26 Feb 2019 11:04:47 +0000 Subject: [issue35652] Add use_srcentry parameter to shutil.copytree() II In-Reply-To: <1546541865.13.0.115152005965.issue35652@roundup.psfhosted.org> Message-ID: <1551179087.7.0.769525445692.issue35652@roundup.psfhosted.org> Giampaolo Rodola' added the comment: New changeset c606a9cbd48f69d3f4a09204c781dda9864218b7 by Giampaolo Rodola in branch 'master': bpo-35652: shutil.copytree(copy_function=...) erroneously pass DirEntry instead of path str (GH-11997) https://github.com/python/cpython/commit/c606a9cbd48f69d3f4a09204c781dda9864218b7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 06:15:29 2019 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 26 Feb 2019 11:15:29 +0000 Subject: [issue34624] -W option and PYTHONWARNINGS env variable does not accept module regexes In-Reply-To: <1536622594.77.0.0269046726804.issue34624@psf.upfronthosting.co.za> Message-ID: <1551179729.55.0.402050149406.issue34624@roundup.psfhosted.org> Nick Coghlan added the comment: I think the only reason I didn't mention this discrepancy in my doc updates is because I wasn't aware there *was* a discrepancy. The weird syntax was then just an incorrect amalgamation of "optional argument" notation with an improperly escaped regex suffix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 06:21:07 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 26 Feb 2019 11:21:07 +0000 Subject: [issue35459] Use PyDict_GetItemWithError() instead of PyDict_GetItem() In-Reply-To: <1544525657.6.0.788709270274.issue35459@psf.upfronthosting.co.za> Message-ID: <1551180067.73.0.736815902375.issue35459@roundup.psfhosted.org> STINNER Victor added the comment: > It seems like the change introduced a regression: bpo-36110. While the test has been fixed, IMHO we need to better document this subtle behavior change since it can be surprising. The test failed because PyObject_GetAttr() no longer ignores exceptions when getting the attribute from the type dictionary. It's a significant change compared to Python 3.7. Right now, the change has not even a NEWS entry, whereas it's a backward incompatible change! Don't get my wrong: the change is correct, we don't want to ignore arbitrary exceptions, it's just a matter of documentation. ---------- nosy: +pablogsal resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 06:24:02 2019 From: report at bugs.python.org (Inada Naoki) Date: Tue, 26 Feb 2019 11:24:02 +0000 Subject: [issue36103] Increase shutil.COPY_BUFSIZE In-Reply-To: <1551087533.63.0.252770144463.issue36103@roundup.psfhosted.org> Message-ID: <1551180242.66.0.153545614395.issue36103@roundup.psfhosted.org> Inada Naoki added the comment: > Also on Linux "echo 3 | sudo tee /proc/sys/vm/drop_caches" is supposed to disable the cache. As I said already, shutil is not used only with cold cache. If cache is cold, disk speed will be upper bound in most cases. But when cache is hot, or using very fast NVMe disk, syscall overhead can be non-negligible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 06:34:43 2019 From: report at bugs.python.org (Jonathan) Date: Tue, 26 Feb 2019 11:34:43 +0000 Subject: [issue36120] Regression - Concurrent Futures Message-ID: <1551180883.79.0.205102352043.issue36120@roundup.psfhosted.org> New submission from Jonathan : I'm using Concurrent Futures to run some work in parallel (futures.ProcessPoolExecutor) on windows 7 x64. The code works fine in 3.6.3, and 3.5.x before that. I've just upgraded to 3.7.2 and it's giving me these errors: Process SpawnProcess-6: Traceback (most recent call last): File "c:\_libs\Python37\lib\multiprocessing\process.py", line 297, in _bootstrap self.run() File "c:\_libs\Python37\lib\multiprocessing\process.py", line 99, in run self._target(*self._args, **self._kwargs) File "c:\_libs\Python37\lib\concurrent\futures\process.py", line 226, in _process_worker call_item = call_queue.get(block=True) File "c:\_libs\Python37\lib\multiprocessing\queues.py", line 93, in get with self._rlock: File "c:\_libs\Python37\lib\multiprocessing\synchronize.py", line 95, in __enter__ return self._semlock.__enter__() PermissionError: [WinError 5] Access is denied If I switch back to the 3.6.3 venv it works fine again. ---------- messages: 336649 nosy: jonathan-lp priority: normal severity: normal status: open title: Regression - Concurrent Futures versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 06:36:41 2019 From: report at bugs.python.org (Jonathan) Date: Tue, 26 Feb 2019 11:36:41 +0000 Subject: [issue36120] Regression - Concurrent Futures In-Reply-To: <1551180883.79.0.205102352043.issue36120@roundup.psfhosted.org> Message-ID: <1551181001.63.0.470924837625.issue36120@roundup.psfhosted.org> Jonathan added the comment: There's also this error too: Traceback (most recent call last): File "c:\_libs\Python37\lib\multiprocessing\process.py", line 297, in _bootstrap self.run() File "c:\_libs\Python37\lib\multiprocessing\process.py", line 99, in run self._target(*self._args, **self._kwargs) File "c:\_libs\Python37\lib\concurrent\futures\process.py", line 226, in _process_worker call_item = call_queue.get(block=True) File "c:\_libs\Python37\lib\multiprocessing\queues.py", line 94, in get res = self._recv_bytes() File "c:\_libs\Python37\lib\multiprocessing\synchronize.py", line 98, in __exit__ return self._semlock.__exit__(*args) OSError: [WinError 6] The handle is invalid ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 06:44:07 2019 From: report at bugs.python.org (Carlos Ramos) Date: Tue, 26 Feb 2019 11:44:07 +0000 Subject: [issue36121] csv: Non global alternative to csv.field_size_limit Message-ID: <1551181447.91.0.36050465631.issue36121@roundup.psfhosted.org> New submission from Carlos Ramos : The function csv.field_size_limit gets and sets a global variable. It would be useful to change this limit in a per-reader or per-thread basis, so that a library can change it without affecting global state. ---------- components: Extension Modules messages: 336651 nosy: Carlos Ramos priority: normal severity: normal status: open title: csv: Non global alternative to csv.field_size_limit type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 06:46:51 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Tue, 26 Feb 2019 11:46:51 +0000 Subject: [issue36120] Regression - Concurrent Futures In-Reply-To: <1551180883.79.0.205102352043.issue36120@roundup.psfhosted.org> Message-ID: <1551181611.59.0.893256553534.issue36120@roundup.psfhosted.org> Cheryl Sabella added the comment: Thank you for the report. Please add a script that contains the least amount of code that would replicate the error. Thanks! >From the devguide: > last but not least, you have to describe the problem in detail, including what you expected to happen, what did happen, and how to replicate the problem in the Comment field. Be sure to include whether any extension modules were involved, and what hardware and software platform you were using (including version information as appropriate). ---------- nosy: +cheryl.sabella stage: -> test needed versions: +Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 06:51:13 2019 From: report at bugs.python.org (bers) Date: Tue, 26 Feb 2019 11:51:13 +0000 Subject: [issue36122] Second run of 2to3 continues to modify output Message-ID: <1551181873.79.0.208082027128.issue36122@roundup.psfhosted.org> New submission from bers : I did this on Windows 10: P:\>python --version Python 3.7.2 P:\>echo print 1, 2 > Test.py P:\>python Test.py File "Test.py", line 1 print 1, 2 ^ SyntaxError: Missing parentheses in call to 'print'. Did you mean print(1, 2)? P:\>2to3 -w 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: Refactored Test.py --- Test.py (original) +++ Test.py (refactored) @@ -1 +1 @@ -print 1, 2 +print(1, 2) RefactoringTool: Files that were modified: RefactoringTool: Test.py P:\>python Test.py 1 2 P:\>2to3 -w 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: Refactored Test.py --- Test.py (original) +++ Test.py (refactored) @@ -1 +1 @@ -print(1, 2) +print((1, 2)) RefactoringTool: Files that were modified: RefactoringTool: Test.py P:\>python Test.py (1, 2) Note how "print 1, 2" first becomes "print(1, 2)" (expected), then becomes "print((1, 2))" in the following run. This changes the output of Test.py ---------- components: 2to3 (2.x to 3.x conversion tool) messages: 336653 nosy: bers priority: normal severity: normal status: open title: Second run of 2to3 continues to modify output type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 06:51:39 2019 From: report at bugs.python.org (Jonathan) Date: Tue, 26 Feb 2019 11:51:39 +0000 Subject: [issue36120] Regression - Concurrent Futures In-Reply-To: <1551180883.79.0.205102352043.issue36120@roundup.psfhosted.org> Message-ID: <1551181899.13.0.938305991187.issue36120@roundup.psfhosted.org> Jonathan added the comment: The "ProcessPoolExecutor Example" on this page breaks for me: https://docs.python.org/3/library/concurrent.futures.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 07:00:21 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 26 Feb 2019 12:00:21 +0000 Subject: [issue36122] Second run of 2to3 continues to modify output In-Reply-To: <1551181873.79.0.208082027128.issue36122@roundup.psfhosted.org> Message-ID: <1551182421.05.0.0333051393602.issue36122@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: This seems to be same as issue35417 and some resolution on detecting these type of cases at issue10375. ---------- nosy: +benjamin.peterson, xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 07:12:32 2019 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 26 Feb 2019 12:12:32 +0000 Subject: [issue36098] asyncio: ssl client-server with "slow" read In-Reply-To: <1550967725.88.0.520289067216.issue36098@roundup.psfhosted.org> Message-ID: <1551183152.94.0.993352843295.issue36098@roundup.psfhosted.org> Andrew Svetlov added the comment: Thanks for the report. We definitely have to fix `AttributeError`. Unfortunately, SSL implementation in asyncio is very tricky. Yuri has an experimental asyncio ssl replacement in his uvloop project rewritten from scratch. There is a plan to port it into asyncio itself. P.S. `await writer.drain()` doesn't send all data to buffer but ensures that the write buffer size is below high watermark limit (https://docs.python.org/3/library/asyncio-protocol.html#asyncio.WriteTransport.set_write_buffer_limits) Actually, it is good. Even after pushing a data into socket buffer you have no knowledge when the data is delivered to peer (or maybe not delivered at all at the moment of socket closing). Moreover, when I experimented with write buffer disabling (transport.set_write_buffer_limits(1)) in aiohttp server benchmarks was executed about 50% slower for simple 'ping' request. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 07:26:22 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 26 Feb 2019 12:26:22 +0000 Subject: [issue36116] test_multiprocessing_spawn fails on AMD64 Windows8 3.x In-Reply-To: <1551165223.62.0.963183120667.issue36116@roundup.psfhosted.org> Message-ID: <1551183982.89.0.657037328662.issue36116@roundup.psfhosted.org> Change by STINNER Victor : ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 07:40:06 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Tue, 26 Feb 2019 12:40:06 +0000 Subject: [issue36121] csv: Non global alternative to csv.field_size_limit In-Reply-To: <1551181447.91.0.36050465631.issue36121@roundup.psfhosted.org> Message-ID: <1551184806.03.0.436526226104.issue36121@roundup.psfhosted.org> R?mi Lapeyre added the comment: Hi Carlos, I think this can be added as a new `field_size_limit` keyword argument to csv.reader(). I will work on it. ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 07:43:13 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Tue, 26 Feb 2019 12:43:13 +0000 Subject: [issue36123] Race condition in test_socket Message-ID: <1551184993.57.0.687748994767.issue36123@roundup.psfhosted.org> New submission from Joannah Nanjekye : Looking at the buildbot failures, there is a race condition in a test_socket test: def _testWithTimeoutTriggeredSend(self): address = self.serv.getsockname() with open(support.TESTFN, 'rb') as file: with socket.create_connection(address, timeout=0.01) as sock: meth = self.meth_from_sock(sock) self.assertRaises(socket.timeout, meth, file) def testWithTimeoutTriggeredSend(self): conn = self.accept_conn() conn.recv(88192) on slow buildbot, create_connection() fails with a timeout exception sometimes because the server fails to start listing in less than 10 ms. https://buildbot.python.org/all/#/builders/167/builds/597 ====================================================================== ERROR: testWithTimeoutTriggeredSend (test.test_socket.SendfileUsingSendTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/test/test_socket.py", line 5796, in testWithTimeoutTriggeredSend conn = self.accept_conn() File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/test/test_socket.py", line 5607, in accept_conn conn, addr = self.serv.accept() File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/socket.py", line 212, in accept fd, addr = self._accept() socket.timeout: timed out ====================================================================== ERROR: testWithTimeoutTriggeredSend (test.test_socket.SendfileUsingSendTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/test/test_socket.py", line 335, in _tearDown raise exc File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/test/test_socket.py", line 353, in clientRun test_func() File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/test/test_socket.py", line 5791, in _testWithTimeoutTriggeredSend with socket.create_connection(address, timeout=0.01) as sock: File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/socket.py", line 727, in create_connection raise err File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/socket.py", line 716, in create_connection sock.connect(sa) socket.timeout: timed out Note: Reported my Victor. I created the bug to track. ---------- components: Tests messages: 336658 nosy: nanjekyejoannah priority: normal severity: normal status: open title: Race condition in test_socket type: behavior versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 07:47:24 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Tue, 26 Feb 2019 12:47:24 +0000 Subject: [issue36123] Race condition in test_socket In-Reply-To: <1551184993.57.0.687748994767.issue36123@roundup.psfhosted.org> Message-ID: <1551185244.92.0.757722230748.issue36123@roundup.psfhosted.org> Change by Joannah Nanjekye : ---------- keywords: +patch pull_requests: +12079 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 07:53:05 2019 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 26 Feb 2019 12:53:05 +0000 Subject: [issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h In-Reply-To: <1549069628.87.0.454232469964.issue35886@roundup.psfhosted.org> Message-ID: <1551185585.31.0.380839166786.issue35886@roundup.psfhosted.org> Nick Coghlan added the comment: Next incompatibility: https://github.com/python-hyper/brotlipy/issues/147 (which indirectly broke httpbin) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 07:59:14 2019 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 26 Feb 2019 12:59:14 +0000 Subject: [issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h In-Reply-To: <1549069628.87.0.454232469964.issue35886@roundup.psfhosted.org> Message-ID: <1551185954.34.0.645934540587.issue35886@roundup.psfhosted.org> Nick Coghlan added the comment: (On closer inspection, that's actually be the same breakage as already mentioned above) However, what I'm not clear on is how this would affect projects that had *already* generated their cffi code, and include that in their sdist. Are all those sdists going to fail to build on Python 3.8 now? It's OK to require that extension modules be rebuilt for a new release, but breaking compatibility with a *code generator* that means a broad selection of projects are all going to fail to build is a much bigger problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 08:04:46 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 26 Feb 2019 13:04:46 +0000 Subject: [issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h In-Reply-To: <1549069628.87.0.454232469964.issue35886@roundup.psfhosted.org> Message-ID: <1551186286.59.0.680404934925.issue35886@roundup.psfhosted.org> St?phane Wirtel added the comment: @nick which indirectly broke httpbin and this one is used by python-requests and we can't execute the tests of requests. ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 08:19:51 2019 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 26 Feb 2019 13:19:51 +0000 Subject: [issue33944] Deprecate and remove pth files In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za> Message-ID: <1551187191.18.0.457726647182.issue33944@roundup.psfhosted.org> Nick Coghlan added the comment: Yep, I completely understand (and agree with) the desire to eliminate the code injection exploit that was introduced decades ago by using exec() to run lines starting with "import " (i.e. "import sys; "). I just don't want to lose the "add this location to sys.path" behaviour that exists for lines in pth files that *don't* start with "import ", since that has plenty of legitimate use cases, and the only downside of overusing it is an excessively long default sys.path (which has far more consistent and obvious symptoms than the arbitrary code execution case can lead to). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 08:21:49 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Tue, 26 Feb 2019 13:21:49 +0000 Subject: [issue31916] ensurepip not honoring value of $(DESTDIR) - pip not installed In-Reply-To: <1509502125.3.0.213398074469.issue31916@psf.upfronthosting.co.za> Message-ID: <1551187309.79.0.516768911259.issue31916@roundup.psfhosted.org> Cheryl Sabella added the comment: Closing as third-party as @yan12125's report pinpoints the cause of the issue as part of pip. ---------- nosy: +cheryl.sabella resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 08:22:54 2019 From: report at bugs.python.org (Armin Rigo) Date: Tue, 26 Feb 2019 13:22:54 +0000 Subject: [issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h In-Reply-To: <1549069628.87.0.454232469964.issue35886@roundup.psfhosted.org> Message-ID: <1551187374.0.0.158837859432.issue35886@roundup.psfhosted.org> Armin Rigo added the comment: @nick the C sources produced by cffi don't change. When they are compiled, they use Py_LIMITED_API so you can continue using a single compiled module version for any recent-enough Python 3.x. The required fix is only inside the cffi module itself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 08:27:03 2019 From: report at bugs.python.org (Roundup Robot) Date: Tue, 26 Feb 2019 13:27:03 +0000 Subject: [issue36041] email: folding of quoted string in display_name violates RFC In-Reply-To: <1550594739.09.0.990893515193.issue36041@roundup.psfhosted.org> Message-ID: <1551187623.05.0.771115610057.issue36041@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch pull_requests: +12080 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 08:32:49 2019 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 26 Feb 2019 13:32:49 +0000 Subject: [issue36085] Enable better DLL resolution In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org> Message-ID: <1551187969.32.0.439852972391.issue36085@roundup.psfhosted.org> Nick Coghlan added the comment: As a note in favour of the "Allow package nesting to be encoded in names, not just directories" approach, we actually have a similar problem affecting builtin modules: they're currently limited to top-level modules, with no way for the module to indicate that it's actually part of the parent package. Details at https://bugs.python.org/issue1644818 (yes, that's a SourceForge era issue number). The solutions may not overlap in practice, but they're conceptually related (i.e. outside frozen modules, the package topology is pretty tightly coupled to the underlying filesystem layout) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 08:33:29 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Tue, 26 Feb 2019 13:33:29 +0000 Subject: [issue36120] Regression - Concurrent Futures In-Reply-To: <1551180883.79.0.205102352043.issue36120@roundup.psfhosted.org> Message-ID: <1551188009.46.0.948529118186.issue36120@roundup.psfhosted.org> Cheryl Sabella added the comment: Thank you. I just tried running the example and it worked OK for me in the 3.8 master build. I believe your report is a duplicate of issue 35797. ---------- resolution: -> duplicate stage: test needed -> resolved status: open -> closed superseder: -> concurrent.futures.ProcessPoolExecutor does not work in venv on Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 08:34:33 2019 From: report at bugs.python.org (Aaryn Tonita) Date: Tue, 26 Feb 2019 13:34:33 +0000 Subject: [issue36041] email: folding of quoted string in display_name violates RFC In-Reply-To: <1550594739.09.0.990893515193.issue36041@roundup.psfhosted.org> Message-ID: <1551188073.22.0.336500996122.issue36041@roundup.psfhosted.org> Aaryn Tonita added the comment: Sorry about the delay. I opened pull request https://github.com/python/cpython/pull/12054 for this. Let me know if you need anything else. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 08:36:11 2019 From: report at bugs.python.org (Aaryn Tonita) Date: Tue, 26 Feb 2019 13:36:11 +0000 Subject: [issue36041] email: folding of quoted string in display_name violates RFC In-Reply-To: <1550594739.09.0.990893515193.issue36041@roundup.psfhosted.org> Message-ID: <1551188171.92.0.209402292964.issue36041@roundup.psfhosted.org> Aaryn Tonita added the comment: Although I am not personally interested in backporting a fix for this issue, anyone that experiences this issue in python 3.5 can execute the following monkey patch to solve the issue: def _fix_issue_36041_3_5(): from email._header_value_parser import QuotedString, ValueTerminal, quote_string import email._header_value_parser class BareQuotedString(QuotedString): token_type = 'bare-quoted-string' def __str__(self): return quote_string(''.join(str(x) for x in self)) @property def value(self): return ''.join(str(x) for x in self) @property def parts(self): parts = list(self) escaped_parts = [] for part in parts: if isinstance(part, ValueTerminal): escaped = quote_string(str(part))[1:-1] escaped_parts.append(ValueTerminal(escaped, 'ptext')) else: escaped_parts.append(part) # Add quotes to the first and last parts. escaped_parts[0] = ValueTerminal('"' + str(escaped_parts[0]), 'ptext') escaped_parts[-1] = ValueTerminal(str(escaped_parts[-1] + '"'), 'ptext') return escaped_parts email._header_value_parser.BareQuotedString = BareQuotedString ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 08:40:24 2019 From: report at bugs.python.org (=?utf-8?q?Carlos_Dam=C3=A1zio?=) Date: Tue, 26 Feb 2019 13:40:24 +0000 Subject: [issue21879] str.format() gives poor diagnostic on placeholder mismatch In-Reply-To: <1404052648.46.0.81950938275.issue21879@psf.upfronthosting.co.za> Message-ID: <1551188424.11.0.327095702396.issue21879@roundup.psfhosted.org> Carlos Dam?zio added the comment: I've noticed this issue is quite not active, but I'm up on participating in it if anyone is doing it already. Since then, this issue still persists: >>> '{1}'.format() Traceback (most recent call last): File "", line 1, in IndexError: tuple index out of range Reading further, I agree that improving the message is suitable. We should leave the Index Exception while changing the text to "Replacement index %d out of range for positional args tuple". Even though I find it quite extent for an exception message, I guess it couldn't be any other way, unless someone gives a better suggestion. ---------- nosy: +dmzz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 08:46:42 2019 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 26 Feb 2019 13:46:42 +0000 Subject: [issue36124] Provide convenient C API for storing per-interpreter state Message-ID: <1551188802.37.0.811137397494.issue36124@roundup.psfhosted.org> New submission from Nick Coghlan : (New issue derived from https://bugs.python.org/issue35886#msg336501 ) cffi needs a generally available way to get access to a caching dict for the currently active subinterpreter. Currently, they do that by storing it as an attribute in the builtins namespace: https://bitbucket.org/cffi/cffi/src/07d1803cb17b230571e3155e52082a356b31d44c/c/call_python.c?fileviewer=file-view-default As a result, they had to amend their code to include the CPython internal headers in 3.8.x, in order to regain access to the "builtins" reference. Armin suggested that a nicer way for them to achieve the same end result is if there was a PyInterpreter_GetDict() API, akin to https://docs.python.org/3/c-api/init.html#c.PyThreadState_GetDict That way they could store their cache dict in there in 3.8+, and only use the builtin dict on older Python versions. ---------- messages: 336670 nosy: ncoghlan priority: normal severity: normal status: open title: Provide convenient C API for storing per-interpreter state _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 08:47:15 2019 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 26 Feb 2019 13:47:15 +0000 Subject: [issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h In-Reply-To: <1549069628.87.0.454232469964.issue35886@roundup.psfhosted.org> Message-ID: <1551188835.58.0.0519504771185.issue35886@roundup.psfhosted.org> Nick Coghlan added the comment: Oh, cool (both the fact the issue here is only with building cffi itself, and that cffi creates extension modules that build with PY_LIMITED_API). I've filed https://bugs.python.org/issue36124 to follow up on the PyInterpreter_GetDict API idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 08:47:32 2019 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 26 Feb 2019 13:47:32 +0000 Subject: [issue36124] Provide convenient C API for storing per-interpreter state In-Reply-To: <1551188802.37.0.811137397494.issue36124@roundup.psfhosted.org> Message-ID: <1551188852.65.0.678868886291.issue36124@roundup.psfhosted.org> Change by Nick Coghlan : ---------- stage: -> needs patch type: -> enhancement versions: +Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 09:03:41 2019 From: report at bugs.python.org (=?utf-8?q?Carlos_Dam=C3=A1zio?=) Date: Tue, 26 Feb 2019 14:03:41 +0000 Subject: [issue21879] str.format() gives poor diagnostic on placeholder mismatch In-Reply-To: <1404052648.46.0.81950938275.issue21879@psf.upfronthosting.co.za> Message-ID: <1551189821.15.0.729465331362.issue21879@roundup.psfhosted.org> Carlos Dam?zio added the comment: Ops, someone already patched it! Sorry guys. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 09:14:16 2019 From: report at bugs.python.org (Paul Ganssle) Date: Tue, 26 Feb 2019 14:14:16 +0000 Subject: [issue36122] Second run of 2to3 continues to modify output In-Reply-To: <1551181873.79.0.208082027128.issue36122@roundup.psfhosted.org> Message-ID: <1551190456.32.0.306140297986.issue36122@roundup.psfhosted.org> Paul Ganssle added the comment: Because what's being printed is a tuple, I think it's not exactly the same as issue35417, because in fact this is the correct behavior for 2to3, note that in Python 2: Python 2.7.15 (default, Jul 21 2018, 11:13:03) >>> print 1, 2 1 2 >>> print(1, 2) (1, 2) And in Python 3: Python 3.7.2 (default, Feb 9 2019, 13:18:43) >>> print(1, 2) 1 2 >>> print((1, 2)) (1, 2) I think this bug report is based on an understandable misunderstanding of what 2to3 does - 2to3 is not intended to be idempotent or to generate code the works for both Python 2 and Python 3, it's intended to translate Python 2 code into Python 3, so passing it something that is *already Python 3 code* you are not guaranteed to get a meaningful output from it. In this case, it first translates `print 1, 2` (Python 2) into `print(1, 2)` (Python 3), then when you run it a second time, it translates `print(1, 2)` (Python 2) into `print((1, 2))` (Python 3) - in both cases it's doing the right thing. @bers I hope that this has helped to clarify the situation. Thank you for taking the time to report this. ---------- nosy: +p-ganssle _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 09:19:22 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Tue, 26 Feb 2019 14:19:22 +0000 Subject: [issue35892] Fix awkwardness of statistics.mode() for multimodal datasets In-Reply-To: <1551146286.98.0.91337972212.issue35892@roundup.psfhosted.org> Message-ID: <20190226141916.GZ4465@ando.pearwood.info> Steven D'Aprano added the comment: > Proposed spec: > ''' > Modify the API statistics.mode to handle multimodal cases so that the > first mode encountered is the one returned. If the input is empty, > raise a StatisticsError. Are you happy guaranteeing that it will always be the first mode encountered? I'm not happy about it, but I'll follow you lead on this one. > TestCases: > mode([]) --> StatisticsError > mode('aabbbcc') --> 'c' That should be 'b'. > mode(iter('aabbbcc')) --> 'c' And again 'b'. > mode('eeffddddggaaaa') --> 'a' If it is first encountered, that should be 'd'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 09:21:39 2019 From: report at bugs.python.org (bers) Date: Tue, 26 Feb 2019 14:21:39 +0000 Subject: [issue36122] Second run of 2to3 continues to modify output In-Reply-To: <1551181873.79.0.208082027128.issue36122@roundup.psfhosted.org> Message-ID: <1551190899.69.0.0210099528481.issue36122@roundup.psfhosted.org> bers added the comment: Yes, understood! Thanks for the explanation. ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 09:37:29 2019 From: report at bugs.python.org (Armin Rigo) Date: Tue, 26 Feb 2019 14:37:29 +0000 Subject: [issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h In-Reply-To: <1549069628.87.0.454232469964.issue35886@roundup.psfhosted.org> Message-ID: <1551191849.03.0.0231645198179.issue35886@roundup.psfhosted.org> Armin Rigo added the comment: Cool. Also, no bugfix release of cffi was planned, but I can make one if you think it might help for testing the current pre-release of CPython 3.8. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 09:37:46 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 26 Feb 2019 14:37:46 +0000 Subject: [issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed. In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za> Message-ID: <1551191866.45.0.939379968103.issue33608@roundup.psfhosted.org> STINNER Victor added the comment: > ...so it doesn't appear that my PR introduces a performance regression. IMHO there is no performance regression at all. Just noice in the result which doesn't come with std dev. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 09:37:55 2019 From: report at bugs.python.org (Brandt Bucher) Date: Tue, 26 Feb 2019 14:37:55 +0000 Subject: [issue36117] Allow rich comparisons for real-valued complex objects. In-Reply-To: <1551168262.55.0.429171834399.issue36117@roundup.psfhosted.org> Message-ID: <1551191875.92.0.675071391223.issue36117@roundup.psfhosted.org> Brandt Bucher added the comment: > The rules for when things are comparable or not should be kept simple. I think that the sort of user who uses complex numbers for their numerical calculations would still find this behavior "simple", but that may just be me. > We don't want to have objects that are orderable depending on their values. I can't think of anywhere else we do this. Well... tuples and lists behave this way. ;) > An application relying on this would be a nightmare to write comprehensive tests for. I'm not arguing that applications should rely on this behavior as core functionality, just that Python's more advanced math functionality deserves to be correct. With that said, there are already so many weird limitations on complex numbers and floating-point values in general. I wouldn't expect users to treat comparing complex numbers any differently than they would treat comparing floats. Check check the .imag value in the former, check math.isnan in the latter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 09:40:28 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 26 Feb 2019 14:40:28 +0000 Subject: [issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h In-Reply-To: <1549069628.87.0.454232469964.issue35886@roundup.psfhosted.org> Message-ID: <1551192028.01.0.946910049256.issue35886@roundup.psfhosted.org> St?phane Wirtel added the comment: @arigo Yep, I am interested because I would like to execute the tests of the major projects/libraries (django, flasks, pandas, requests, ...) and create issues for the maintainer. the sooner we get feedback, the sooner we can fix the bugs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 09:53:49 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 26 Feb 2019 14:53:49 +0000 Subject: [issue31904] Python should support VxWorks RTOS In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za> Message-ID: <1551192829.65.0.607847519949.issue31904@roundup.psfhosted.org> STINNER Victor added the comment: Kuhl, Brian started a new discussion: [Python-Dev] VxWorks and cpython? https://mail.python.org/pipermail/python-dev/2019-January/156024.html PR 11968 and PR 12051 are small and reasonable. IMHO we can take decisions on a case by case basic. But WindRiver plans to provide a buildbot and is already showing their will to propose PRs, so it seems like things are moving on. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 10:07:49 2019 From: report at bugs.python.org (Brandt Bucher) Date: Tue, 26 Feb 2019 15:07:49 +0000 Subject: [issue36117] Allow rich comparisons for real-valued complex objects. In-Reply-To: <1551168262.55.0.429171834399.issue36117@roundup.psfhosted.org> Message-ID: <1551193669.28.0.28692693322.issue36117@roundup.psfhosted.org> Change by Brandt Bucher : ---------- type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 10:11:40 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Feb 2019 15:11:40 +0000 Subject: [issue36117] Allow rich comparisons for real-valued complex objects. In-Reply-To: <1551168262.55.0.429171834399.issue36117@roundup.psfhosted.org> Message-ID: <1551193900.66.0.481534994999.issue36117@roundup.psfhosted.org> Serhiy Storchaka added the comment: NaN and complex numbers are not orderable by definition. This is a feature, not a bug. ---------- resolution: -> not a bug stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 10:13:12 2019 From: report at bugs.python.org (Armin Rigo) Date: Tue, 26 Feb 2019 15:13:12 +0000 Subject: [issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h In-Reply-To: <1549069628.87.0.454232469964.issue35886@roundup.psfhosted.org> Message-ID: <1551193992.87.0.470677815466.issue35886@roundup.psfhosted.org> Armin Rigo added the comment: Done. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 10:26:58 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 26 Feb 2019 15:26:58 +0000 Subject: [issue36030] add internal API function to create tuple without items array initialization In-Reply-To: <1550563364.86.0.164811838679.issue36030@roundup.psfhosted.org> Message-ID: <1551194818.25.0.93968277414.issue36030@roundup.psfhosted.org> STINNER Victor added the comment: > This optimization also can be used for BUILD_TUPLE opcode and in pickle module, if it's OK to add _PyTuple_StealFromArray() function :-) I would like to see a micro-benchmark showing that it's faster. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 10:29:56 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 26 Feb 2019 15:29:56 +0000 Subject: [issue36030] add internal API function to create tuple without items array initialization In-Reply-To: <1550563364.86.0.164811838679.issue36030@roundup.psfhosted.org> Message-ID: <1551194996.7.0.92129596112.issue36030@roundup.psfhosted.org> STINNER Victor added the comment: Can you please convert msg336142 into a perf script? See the doc: https://perf.readthedocs.io/en/latest/developer_guide.html And then run again these benchmarks on PR 12052. If you have a script, you can do: ./python-ref script.py -o ref.json ./python-untracked script.py -o untracked.json ./python-untracked -m perf compare_to ref.json untracked.json https://perf.readthedocs.io/en/latest/cli.html#compare-to-cmd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 10:38:20 2019 From: report at bugs.python.org (Inada Naoki) Date: Tue, 26 Feb 2019 15:38:20 +0000 Subject: [issue36103] Increase shutil.COPY_BUFSIZE In-Reply-To: <1551087533.63.0.252770144463.issue36103@roundup.psfhosted.org> Message-ID: <1551195500.37.0.566234475573.issue36103@roundup.psfhosted.org> Inada Naoki added the comment: Read this file too. http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/ioblksize.h coreutils choose 128KiB for *minimal* buffer size to reduce syscall overhead. In case of shutil, we have Python interpreter overhead adding to syscall overhead. Who has deeper insights than coreutils author? I think 128KiB is the best, but I'm OK to 64KiB for conservative decision. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 10:51:26 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 26 Feb 2019 15:51:26 +0000 Subject: [issue35459] Use PyDict_GetItemWithError() instead of PyDict_GetItem() In-Reply-To: <1544525657.6.0.788709270274.issue35459@psf.upfronthosting.co.za> Message-ID: <1551196286.76.0.666769660619.issue35459@roundup.psfhosted.org> Josh Rosenberg added the comment: #36110 was closed as a duplicate; the superseder is #36109 (which has been fixed). The change should still be documented, just in case anyone gets bitten by it. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 10:57:24 2019 From: report at bugs.python.org (Eric Snow) Date: Tue, 26 Feb 2019 15:57:24 +0000 Subject: [issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed. In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za> Message-ID: <1551196644.52.0.463991529578.issue33608@roundup.psfhosted.org> Eric Snow added the comment: FYI, I have a couple of small follow-up changes to land before I close this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 11:00:10 2019 From: report at bugs.python.org (Ross Burton) Date: Tue, 26 Feb 2019 16:00:10 +0000 Subject: [issue36125] Cannot cross-compile to more featureful but same tune Message-ID: <1551196810.67.0.249603335877.issue36125@roundup.psfhosted.org> New submission from Ross Burton : My build machine is a Haswell Intel x86-64. I'm cross-compiling to x86-64, with -mtune=Skylake -avx2. During make install PYTHON_FOR_BUILD loads modules from the *build* Lib/ which contain instructions my Haswell can't execute: | _PYTHON_PROJECT_BASE=/data/poky-tmp/master/work/corei7-64-poky-linux/python3/3.7.2-r0/build _PYTHON_HOST_PLATFORM=linux-x86_64 PYTHONPATH=../Python-3.7.2/Lib _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata_m_linux_x86_64-linux-gnu python3.7 -v -S -m sysconfig --generate-posix-vars ;\ Illegal instruction ---------- components: Build messages: 336688 nosy: rossburton priority: normal severity: normal status: open title: Cannot cross-compile to more featureful but same tune versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 11:15:30 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 26 Feb 2019 16:15:30 +0000 Subject: [issue26228] pty.spawn hangs on FreeBSD 9.3, 10.x In-Reply-To: <1453953861.58.0.104331734212.issue26228@psf.upfronthosting.co.za> Message-ID: <1551197730.63.0.958696012155.issue26228@roundup.psfhosted.org> STINNER Victor added the comment: Please have a look at this pty.spawn() documentation change: https://github.com/python/cpython/pull/11980 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 11:18:26 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 26 Feb 2019 16:18:26 +0000 Subject: [issue36123] Race condition in test_socket In-Reply-To: <1551184993.57.0.687748994767.issue36123@roundup.psfhosted.org> Message-ID: <1551197906.16.0.00854094286474.issue36123@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 53b9e1a1c1d86187ad6fbee492b697ef8be74205 by Victor Stinner (Joannah Nanjekye) in branch 'master': bpo-36123: Fix test_socket.testWithTimeoutTriggeredSend() race condition (GH-12053) https://github.com/python/cpython/commit/53b9e1a1c1d86187ad6fbee492b697ef8be74205 ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 11:18:49 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 26 Feb 2019 16:18:49 +0000 Subject: [issue36123] Race condition in test_socket In-Reply-To: <1551184993.57.0.687748994767.issue36123@roundup.psfhosted.org> Message-ID: <1551197929.12.0.730805671273.issue36123@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +12081 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 11:30:29 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 26 Feb 2019 16:30:29 +0000 Subject: [issue35417] Double parenthesis in print function running 2to3 in already correct call In-Reply-To: <1544004619.56.0.788709270274.issue35417@psf.upfronthosting.co.za> Message-ID: <1551198629.66.0.147737628217.issue35417@roundup.psfhosted.org> STINNER Victor added the comment: I suggest to close this issue as WONTFIX. 2to3 is designed as a tool to convert a Python 2 code base to Python 3 at once. I understand that once the code base is converted, you may want to revert some unwanted "useless" changes. Python 2 and Python 3 languages have some intersections where it's hard to guess if the code is valid or not in Python 3. 2to3 uses heuristic which implements practical solutions. And you noticed, there are some corner cases where 2to3 generates useless changes. IMHO 2to3 is fine. It may be nice to enhance it, but well, it's a trade-off, it's good as it is. You may want to test other tools like modernize, 2to6, sixer, etc. which made different trade-offs. Note: I'm the author of sixer and I'm not a big of 2to3 since it drops Python 2 support and generate many changes which are not needed since Python 3.2. ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 11:34:18 2019 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 26 Feb 2019 16:34:18 +0000 Subject: [issue36106] resolve sinpi() name clash with libm In-Reply-To: <1551102423.19.0.037549170544.issue36106@roundup.psfhosted.org> Message-ID: <1551198858.52.0.288654920482.issue36106@roundup.psfhosted.org> Mark Dickinson added the comment: This one was my fault. Thanks for the fix! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 11:42:10 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 26 Feb 2019 16:42:10 +0000 Subject: [issue36030] add internal API function to create tuple without items array initialization In-Reply-To: <1550563364.86.0.164811838679.issue36030@roundup.psfhosted.org> Message-ID: <1551199330.94.0.661866716114.issue36030@roundup.psfhosted.org> Josh Rosenberg added the comment: Victor/vstinner: Isn't PR 12032 reintroducing the issue fixed in #29234? _PyStack_AsTuple was explicitly marked as _Py_NO_INLINE because inlining was creating excessive stack consumption in the callers (which were the bytecode interpreter loop), but the new _PyTuple_FromArray isn't marked as _Py_NO_INLINE, so the swap reintroduces the problem. Seems like either: 1. _PyTuple_FromArray should also be marked _Py_NO_INLINE or 2. _PyStack_AsTuple should continue to exist as the non-inlined version of _PyTuple_FromArray It's possible this isn't as much of an issue because _PyTuple_FromArray is in tupleobject.c (where it's only called in one place), while _PyStack_AsTuple was in call.c and was called from within call.c in four places, but only if link-time optimization isn't involved (and in practice, most public distributions of CPython are built with link-time optimization now, correct?); if LTO is enabled, the same stack bloat issues are possible. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 11:48:55 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 26 Feb 2019 16:48:55 +0000 Subject: [issue36123] Race condition in test_socket In-Reply-To: <1551184993.57.0.687748994767.issue36123@roundup.psfhosted.org> Message-ID: <1551199735.01.0.0863696202187.issue36123@roundup.psfhosted.org> miss-islington added the comment: New changeset 2632474957fa9c6311af21be6906d1234853f288 by Miss Islington (bot) in branch '3.7': bpo-36123: Fix test_socket.testWithTimeoutTriggeredSend() race condition (GH-12053) https://github.com/python/cpython/commit/2632474957fa9c6311af21be6906d1234853f288 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 11:54:29 2019 From: report at bugs.python.org (Eric Snow) Date: Tue, 26 Feb 2019 16:54:29 +0000 Subject: [issue36124] Provide convenient C API for storing per-interpreter state In-Reply-To: <1551188802.37.0.811137397494.issue36124@roundup.psfhosted.org> Message-ID: <1551200069.65.0.975654708531.issue36124@roundup.psfhosted.org> Eric Snow added the comment: +1 from me @Armin, thanks to Nick I understand your request better now. I'll put up a PR by the end of the week if no one beats me to it. ---------- nosy: +arigo, eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 11:54:34 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 26 Feb 2019 16:54:34 +0000 Subject: [issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h In-Reply-To: <1437054680.06.0.553712434946.issue24643@psf.upfronthosting.co.za> Message-ID: <1551200074.47.0.665045821211.issue24643@roundup.psfhosted.org> Steve Dower added the comment: Thanks, Zackery! ---------- assignee: -> steve.dower resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 11:56:16 2019 From: report at bugs.python.org (Enji Cooper) Date: Tue, 26 Feb 2019 16:56:16 +0000 Subject: [issue13501] Make libedit support more generic; port readline / libedit to FreeBSD In-Reply-To: <1322579942.3.0.601983912656.issue13501@psf.upfronthosting.co.za> Message-ID: <1551200176.33.0.580831447391.issue13501@roundup.psfhosted.org> Enji Cooper added the comment: I'll try to rebase Martin's changes, as they don't apply to the master branch on GitHub today. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 11:56:50 2019 From: report at bugs.python.org (Enji Cooper) Date: Tue, 26 Feb 2019 16:56:50 +0000 Subject: [issue13501] Make libedit support more generic; port readline / libedit to FreeBSD In-Reply-To: <1322579942.3.0.601983912656.issue13501@psf.upfronthosting.co.za> Message-ID: <1551200210.11.0.379926147613.issue13501@roundup.psfhosted.org> Change by Enji Cooper : ---------- versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 12:01:58 2019 From: report at bugs.python.org (Ross Burton) Date: Tue, 26 Feb 2019 17:01:58 +0000 Subject: [issue36125] Cannot cross-compile to more featureful but same tune In-Reply-To: <1551196810.67.0.249603335877.issue36125@roundup.psfhosted.org> Message-ID: <1551200518.52.0.85801529343.issue36125@roundup.psfhosted.org> Ross Burton added the comment: >From what I can tell: configure.ac sets PYTHON_FOR_BUILD like this if cross-compiling: PYTHON_FOR_BUILD='_PYTHON_PROJECT_BASE=$(abs_builddir) _PYTHON_HOST_PLATFORM=$(_PYTHON_HOST_PLATFORM) PYTHONPATH=$(shell test -f pybuilddir.txt && echo $(abs_builddir)/`cat pybuilddir.txt`:)$(srcdir)/Lib _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata_$(ABIFLAGS)_$(MACHDEP)_$(MULTIARCH) '$interp Note how PYTHONPATH is set to the source and build paths for Lib/. The intention appears to be that the sysconfig.py in the build is used. In my case that directory is also full of shared libraries that Python happily loads, and then fails. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 12:09:57 2019 From: report at bugs.python.org (zasdfgbnm) Date: Tue, 26 Feb 2019 17:09:57 +0000 Subject: [issue36126] Reference count leakage in structseq_repr Message-ID: <1551200997.63.0.481035129926.issue36126@roundup.psfhosted.org> New submission from zasdfgbnm : In Python 2.7 structseq is not a tuple, and in `structseq_repr` a tuple is created to help extracting items. However when the check at https://github.com/python/cpython/blob/2.7/Objects/structseq.c#L268 fails, the reference count of this tuple is not decreased, causing memory leakage. To reproduce, download the attached file, install and run the `quicktest.py` and watch the memory usage. This bug only exists on python 2.7, because on python >3.2, no helper tuple is created. ---------- components: Interpreter Core files: structseq.tar.xz messages: 336699 nosy: zasdfgbnm priority: normal pull_requests: 12082 severity: normal status: open title: Reference count leakage in structseq_repr type: behavior versions: Python 2.7 Added file: https://bugs.python.org/file48172/structseq.tar.xz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 12:30:36 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Feb 2019 17:30:36 +0000 Subject: [issue36127] Argument Clinic: inline parsing code for functions with keyword parameters Message-ID: <1551202236.03.0.123634318665.issue36127@roundup.psfhosted.org> New submission from Serhiy Storchaka : This is a follow up of issue23867 and issue35582. The proposed PR makes Argument Clinic inlining parsing code for functions with keyword parameters, i.e. functions that use _PyArg_ParseTupleAndKeywordsFast() and _PyArg_ParseStackAndKeywords() now. This saves time for parsing format strings and calling few levels of functions. ---------- assignee: serhiy.storchaka components: Argument Clinic messages: 336700 nosy: larry, serhiy.storchaka, vstinner priority: normal severity: normal status: open title: Argument Clinic: inline parsing code for functions with keyword parameters type: performance versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 12:32:46 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Feb 2019 17:32:46 +0000 Subject: [issue36127] Argument Clinic: inline parsing code for functions with keyword parameters In-Reply-To: <1551202236.03.0.123634318665.issue36127@roundup.psfhosted.org> Message-ID: <1551202366.75.0.919160210134.issue36127@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- keywords: +patch pull_requests: +12083 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 12:34:00 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Feb 2019 17:34:00 +0000 Subject: [issue36127] Argument Clinic: inline parsing code for functions with keyword parameters In-Reply-To: <1551202236.03.0.123634318665.issue36127@roundup.psfhosted.org> Message-ID: <1551202440.14.0.562736617209.issue36127@roundup.psfhosted.org> Serhiy Storchaka added the comment: Some examples: $ ./python -m perf timeit --compare-to=../cpython-release-baseline/python --duplicate=1000 -s "round_ = round" "round_(4.2)" Mean +- std dev: [...] 110 ns +- 3 ns -> [...] 81.4 ns +- 2.2 ns: 1.35x faster (-26%) $ ./python -m perf timeit --compare-to=../cpython-release-baseline/python --duplicate=1000 -s "sum_ = sum" "sum_(())" Mean +- std dev: [...] 88.0 ns +- 6.5 ns -> [...] 57.6 ns +- 1.1 ns: 1.53x faster (-35%) $ ./python -m perf timeit --compare-to=../cpython-release-baseline/python --duplicate=1000 -s "sum_ = sum; a = [1, 2]" "sum_(a)" Mean +- std dev: [...] 95.9 ns +- 2.1 ns -> [...] 70.6 ns +- 2.0 ns: 1.36x faster (-26%) $ ./python -m perf timeit --compare-to=../cpython-release-baseline/python --duplicate=1000 "'abc'.split()" Mean +- std dev: [...] 102 ns +- 3 ns -> [...] 80.5 ns +- 2.1 ns: 1.26x faster (-21%) $ ./python -m perf timeit --compare-to=../cpython-release-baseline/python --duplicate=1000 "b'abc'.split()" Mean +- std dev: [...] 91.8 ns +- 2.3 ns -> [...] 75.1 ns +- 1.4 ns: 1.22x faster (-18%) $ ./python -m perf timeit --compare-to=../cpython-release-baseline/python --duplicate=1000 "'abc'.split('-')" Mean +- std dev: [...] 118 ns +- 2 ns -> [...] 89.2 ns +- 1.8 ns: 1.32x faster (-24%) $ ./python -m perf timeit --compare-to=../cpython-release-baseline/python --duplicate=1000 "b'abc'.decode()" Mean +- std dev: [...] 96.1 ns +- 3.6 ns -> [...] 78.9 ns +- 2.2 ns: 1.22x faster (-18%) $ ./python -m perf timeit --compare-to=../cpython-release-baseline/python --duplicate=1000 "'abc'.encode()" Mean +- std dev: [...] 72.4 ns +- 1.9 ns -> [...] 55.1 ns +- 1.8 ns: 1.31x faster (-24%) $ ./python -m perf timeit --compare-to=../cpython-release-baseline/python --duplicate=1000 -s "int_= int" "int(4.2)" Mean +- std dev: [...] 105 ns +- 4 ns -> [...] 78.8 ns +- 1.9 ns: 1.33x faster (-25%) $ ./python -m perf timeit --compare-to=../cpython-release-baseline/python --duplicate=1000 -s "int_= int" "int('5')" Mean +- std dev: [...] 154 ns +- 5 ns -> [...] 122 ns +- 4 ns: 1.26x faster (-21%) $ ./python -m perf timeit --compare-to=../cpython-release-baseline/python --duplicate=1000 "42 .to_bytes(2, 'little') Mean +- std dev: [...] 109 ns +- 3 ns -> [...] 72.4 ns +- 1.9 ns: 1.51x faster (-34%) $ ./python -m perf timeit --compare-to=../cpython-release-baseline/python --duplicate=1000 "from_bytes = int.from_bytes" "from_bytes(b'ab', 'little')" Mean +- std dev: [...] 138 ns +- 3 ns -> [...] 96.3 ns +- 3.0 ns: 1.43x faster (-30%) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 12:44:21 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 26 Feb 2019 17:44:21 +0000 Subject: [issue36119] Can't add/append in set/list inside shared dict In-Reply-To: <1551178033.97.0.988149024615.issue36119@roundup.psfhosted.org> Message-ID: <1551203061.15.0.0164538743373.issue36119@roundup.psfhosted.org> Josh Rosenberg added the comment: As Karthikeyan, this is an inevitable, and documented, consequence of the proxies not being aware of in-place modification of their contents. As your own example demonstrates, any approach that provides that information to the shared dict proxy will work; |= and += are almost the same as .update and .extend, but implemented such that the left hand side is always reassigned, even when the result of __ior__/__iadd__ is the same object it was called on. Thus, |=/+= work, while add/append/update/extend do not. Note that as of 3.6, there is another option: Nested shared objects: > Changed in version 3.6: Shared objects are capable of being nested. For example, a shared container object such as a shared list can contain other shared objects which will all be managed and synchronized by the SyncManager. So the alternative solution in your case (assuming you're on 3.6 or later, which your bug version tags say you are) is to make the sub-lists manager.lists, or replace use of a set with manager.dict (as dicts with all values set to True, are largely compatible with set anyway, especially with the advent of dict views): manager = Manager() shared_dict = manager.dict() shared_dict['test'] = manager.dict() # or shared_dict['test'] = manager.list() shared_dict['test'][1234] = True # or shared_dict['test'].append(1234) Downside: The repr of shared dicts/lists doesn't display the contents, so your example code won't make it obvious that the problem is fixed, but it does in fact work. I wrote a terrible JSON one-liner to check the contents, and it demonstrates that the shared dict/list work just fine: import json from multiprocessing import Manager from multiprocessing.managers import DictProxy, ListProxy manager = Manager() shared_dict = manager.dict() shared_dict['testset'] = set() shared_dict['testlist'] = [] shared_dict['testshareddict'] = manager.dict() shared_dict['testsharedlist'] = manager.list() shared_dict['testset'].add(1234) shared_dict['testlist'].append(1234) shared_dict['testshareddict'][1234] = True shared_dict['testsharedlist'].append(1234) print(json.dumps(shared_dict, default=lambda x: dict(x) if isinstance(x, DictProxy) else list(x) if isinstance(x, ListProxy) else dict.fromkeys(x, True) if isinstance(x, (set, frozenset)) else x)) The dump shows that the changes to the shared inner dict and list are reflected in the result directly, even with no assignment back to the keys of the outer dict (while, as you note, the plain set and list show no changes). Closing as not a bug, since this is fully documented, with multiple workarounds available. ---------- nosy: +josh.r resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 12:44:32 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 26 Feb 2019 17:44:32 +0000 Subject: [issue36127] Argument Clinic: inline parsing code for functions with keyword parameters In-Reply-To: <1551202236.03.0.123634318665.issue36127@roundup.psfhosted.org> Message-ID: <1551203072.38.0.295673281466.issue36127@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: That's a lot faster and will be great if they make it to next alpha :) Adding Ammar Askar since they did review for positional arguments. ---------- nosy: +ammar2, xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 12:50:28 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Tue, 26 Feb 2019 17:50:28 +0000 Subject: [issue36123] Race condition in test_socket In-Reply-To: <1551184993.57.0.687748994767.issue36123@roundup.psfhosted.org> Message-ID: <1551203428.47.0.286874781196.issue36123@roundup.psfhosted.org> Joannah Nanjekye added the comment: I am closing this as it has been fixed by this PR ---------- stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 13:09:08 2019 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 26 Feb 2019 18:09:08 +0000 Subject: [issue33944] Deprecate and remove pth files In-Reply-To: <1551187191.18.0.457726647182.issue33944@roundup.psfhosted.org> Message-ID: <0A95210B-C817-40BD-9086-216B00CEFC25@python.org> Barry A. Warsaw added the comment: On Feb 26, 2019, at 05:19, Nick Coghlan wrote: > > I just don't want to lose the "add this location to sys.path" behaviour that exists for lines in pth files that *don't* start with "import ", since that has plenty of legitimate use cases, and the only downside of overusing it is an excessively long default sys.path (which has far more consistent and obvious symptoms than the arbitrary code execution case can lead to). It?s also very difficult to debug because pth loading usually happens before the user has a chance to intervene with a debugger. This means mysterious things can happen, like different versions of a package getting imported than you expect. Extending sys.path is a useful use case, but doing so in pth files is problematic. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 13:53:22 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 26 Feb 2019 18:53:22 +0000 Subject: [issue36127] Argument Clinic: inline parsing code for functions with keyword parameters In-Reply-To: <1551202236.03.0.123634318665.issue36127@roundup.psfhosted.org> Message-ID: <1551207202.43.0.454989836298.issue36127@roundup.psfhosted.org> Change by Josh Rosenberg : ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 14:08:09 2019 From: report at bugs.python.org (Paul Monson) Date: Tue, 26 Feb 2019 19:08:09 +0000 Subject: [issue36071] Add support for Windows ARM32 in ctypes/libffi Message-ID: <1551208089.99.0.61936836229.issue36071@roundup.psfhosted.org> Change by Paul Monson : ---------- keywords: +patch pull_requests: +12084 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 14:12:27 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 26 Feb 2019 19:12:27 +0000 Subject: [issue36127] Argument Clinic: inline parsing code for functions with keyword parameters In-Reply-To: <1551202236.03.0.123634318665.issue36127@roundup.psfhosted.org> Message-ID: <1551208347.19.0.0530809746155.issue36127@roundup.psfhosted.org> Josh Rosenberg added the comment: How much bigger does the core interpreter + built-in extension modules get when you make this change? How much more memory is used by real world programs? I'm a little concerned when I see individual functions growing by 140 lines in the first file of the diff. Clearly the increase in memory usage wasn't enough to slow down the microbenchmarks (which can probably fit the entire hot code path in CPU on die cache), but I'd be worried about the aggregate effect on real world programs if we go from a handful of argument parsing code paths reused by every function (and therefore kept constantly hot) to hundreds (or thousands?) of unique argument parsing code paths, each one unique to a single function. It could easily look great when a single function is being called repeatedly, while looking much less great (possibly worse) when the many varied function calls are interleaved. It should be tested on a number of systems too; any losses to cache unfriendliness would be highly dependent on the size of the CPU cache. I'll grant, it doesn't seem like inlining positional argument parsing has caused problems, and it looks like we're still using _PyArg_UnpackKeywords, so argument parsing isn't completely devolved to each functions, but I think we need something more than microbenchmarks before we jump on this. If my worries end up being unfounded, I'll be happy. Looks very cool if we can really get that sort of speed up for all function calls, not just positional args only functions. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 14:19:11 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 26 Feb 2019 19:19:11 +0000 Subject: [issue36118] Cannot correctly concatenate nested list that contains more than ~45 entries with other nested lists. In-Reply-To: <1551171567.53.0.226883358106.issue36118@roundup.psfhosted.org> Message-ID: <1551208751.17.0.313494325984.issue36118@roundup.psfhosted.org> Josh Rosenberg added the comment: Agreed, I cannot reproduce this (online link showing behavior): https://tio.run/##K6gsycjPM/7/v0LBViE6WilRSUdBKQlI6OnpKQCZTlFKsbFclWDJWB2FaEMdIx1jHRMdU5gKS0uQfLRBLFBJBZDiKijKzCvRAIlocv3/DwA My guess is the code is subtly different, e.g. replacing: >>> y[0] = x[0] >>> print(y[0]) with: >>> y[:1] = x[0] >>> print(y) would get roughly what the OP is seeing (and it would be the correct/expected result in that case). Either way, not a bug. ---------- nosy: +josh.r resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 14:54:42 2019 From: report at bugs.python.org (Geoff Shannon) Date: Tue, 26 Feb 2019 19:54:42 +0000 Subject: [issue26228] pty.spawn hangs on FreeBSD 9.3, 10.x In-Reply-To: <1453953861.58.0.104331734212.issue26228@psf.upfronthosting.co.za> Message-ID: <1551210882.31.0.303727397151.issue26228@roundup.psfhosted.org> Geoff Shannon added the comment: I'm aware of it. I actually wrote that patch as well. :D ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 15:32:24 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 26 Feb 2019 20:32:24 +0000 Subject: [issue33944] Deprecate and remove pth files In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za> Message-ID: <1551213144.95.0.64457862021.issue33944@roundup.psfhosted.org> Steve Dower added the comment: > Extending sys.path is a useful use case, but doing so in pth files is problematic. There are 100 other ways to end up in this situation though. Why is *this* one so much worse? Can you offer an issue you hit that was caused by a .pth file that *wasn't* debuggable by listing sys.path? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 15:37:59 2019 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 26 Feb 2019 20:37:59 +0000 Subject: [issue33944] Deprecate and remove pth files In-Reply-To: <1551213144.95.0.64457862021.issue33944@roundup.psfhosted.org> Message-ID: <7D783D44-7A43-4DBD-BF1D-CA88937A9E87@python.org> Barry A. Warsaw added the comment: On Feb 26, 2019, at 12:32, Steve Dower wrote: > > There are 100 other ways to end up in this situation though. Why is *this* one so much worse? Because there?s no good place to stick a pdb/breakpoint to debug such issues other than site.py, and that usually requires sudo. > Can you offer an issue you hit that was caused by a .pth file that *wasn't* debuggable by listing sys.path? I don?t remember the details, but yes I have been caught in this trap. The thing is, by the time user code gets called, the damage is already done, so debugging is quite difficult. This will be alleviated at least partially by deprecating the executing of random code. Maybe just allowing sys.path hacking will be enough to make it not so terrible, especially if e.g. (and I haven?t check to see whether this is the case today), `python -v` shows you exactly which .pth file is extending sys.path. The issue is discoverability. Since pth files happen before you get an interpreter prompt, it?s too difficult to debug unexpected, wrong, or broken behavior. My opposition would lessen if there were clear ways to debug, and preferably also prevent, pth interpretation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 15:52:41 2019 From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=) Date: Tue, 26 Feb 2019 20:52:41 +0000 Subject: [issue33944] Deprecate and remove pth files In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za> Message-ID: <1551214361.63.0.240756004462.issue33944@roundup.psfhosted.org> Ionel Cristian M?rie? added the comment: > Because there?s no good place to stick a pdb/breakpoint to debug such issues other than site.py, and that usually requires sudo. Something bad was installed with sudo but suddenly sudo is not acceptable for debugging? This seems crazy. How exactly are pth files hard to debug? Are those files hard to edit? They sure are, but the problem ain't the point where they are run, it's the fact that a big lump of code is stuffed on a single line. Lets fix that instead! I've written pth files with lots of stuff in them, and my experience is quite the opposite - they help with debugging. A lot. It's an incredibly useful python feature. > I don?t remember the details, but yes I have been caught in this trap. Maybe if you remember the details we can discuss what are the debugging options, and what can be improved. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 15:59:18 2019 From: report at bugs.python.org (Michael Sullivan) Date: Tue, 26 Feb 2019 20:59:18 +0000 Subject: [issue35975] Put back the ability to parse files where async/await aren't keywords In-Reply-To: <1549931018.54.0.209945896308.issue35975@roundup.psfhosted.org> Message-ID: <1551214758.94.0.533953552902.issue35975@roundup.psfhosted.org> Change by Michael Sullivan : ---------- nosy: +msullivan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 16:05:00 2019 From: report at bugs.python.org (Gregory Szorc) Date: Tue, 26 Feb 2019 21:05:00 +0000 Subject: [issue36128] ResourceReader for FileLoader inconsistently handles path separators Message-ID: <1551215100.55.0.236644911032.issue36128@roundup.psfhosted.org> New submission from Gregory Szorc : The implementation of the ResourceReader API for the FileLoader class in importlib/_bootstrap_external.py is inconsistent with regards to handling of path separators. Specifically, "is_resource()" returns False if "resource" has a path separator. But "open_resource()" will happily open resources containing a path separator. I would think the two would agree about whether a path with separators is a resource or not. The documentation at https://docs.python.org/3.7/library/importlib.html#importlib.abc.ResourceReader implies that resources in subdirectories should not be allowed. One can easily demonstrate this behavior oddity with Mercurial: (Pdb) p sys.modules['mercurial'].__spec__.loader.get_resource_reader('mercurial').open_resource('help/config.txt') <_io.FileIO name='/home/gps/src/hg/mercurial/help/config.txt' mode='rb' closefd=True> (Pdb) p sys.modules['mercurial'].__spec__.loader.get_resource_reader('mercurial').is_resource('help/config.txt') False The behavior has been present since the functionality was added (https://github.com/python/cpython/pull/5168). ---------- components: Library (Lib) messages: 336712 nosy: barry, indygreg priority: normal severity: normal status: open title: ResourceReader for FileLoader inconsistently handles path separators type: behavior versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 16:21:21 2019 From: report at bugs.python.org (Alexey Izbyshev) Date: Tue, 26 Feb 2019 21:21:21 +0000 Subject: [issue36046] support dropping privileges when running subprocesses In-Reply-To: <1550625858.55.0.53498127684.issue36046@roundup.psfhosted.org> Message-ID: <1551216081.87.0.993190968923.issue36046@roundup.psfhosted.org> Alexey Izbyshev added the comment: > 1) This is intentional, this is for dropping privileges before running some (possibly untrusted) command, we do not want to leave a path for the subprocess to gain root back. If there is a subprocess that needs root for some operations, it would presumably have the ability to drop privileges itself, and would not need the python script to do it before running it. > 2) While POSIX leaves it unspecified what changes are permitted for an unprivileged process, these are permitted for a privileged process, which is the main use case for this functionality. In the case the OS does not support it for an unpriviliged process, the syscall would fail with EPERM, which can be handled from the calling python code. Thanks for your explanation. In case of a privileged process, the behavior of setreuid/setregid/setgroups does seem well-defined. But setuid/setgid change all ids (real, effective, saved) too in this case. Do you prefer setreuid/setregid because they provide stricter semantics in non-privileged processes compared to setuid/setgid? (The latter ones change the effective id only, potentially preserving the process ability to switch ids later). > I am fine removing the workaround, and allowing it to fail with EPERM. Perhaps we could find another way around this for running the tests in an unprivileged environment, or just leave the test only running the EPERM case... > I could change the API to have have group= and supp_groups= if you prefer. Personally, I do prefer separate arguments because subprocess is a relatively low-level module and tends to expose underlying operations, so it seems logical to have a knob that maps to setgid() and another one that maps to setgroups(). @gregory.p.smith: what do you think about it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 16:23:19 2019 From: report at bugs.python.org (Ivan Pozdeev) Date: Tue, 26 Feb 2019 21:23:19 +0000 Subject: [issue33944] Deprecate and remove pth files In-Reply-To: <7D783D44-7A43-4DBD-BF1D-CA88937A9E87@python.org> Message-ID: <23826c7b-edc9-ca4b-866b-afdf0bb640b4@mail.ru> Ivan Pozdeev added the comment: On 26.02.2019 23:37, Barry A. Warsaw wrote: > My opposition would lessen if there were clear ways to debug, and preferably also prevent, pth interpretation. Easy. Insert a chunk into site.py that would call pdb.set_trace() if an envvar (e.g. `PYSITEDEBUG') or a command line switch is set. Actually, why can't whoever has this problem add such a chunk themselves? Is this really such a frequent and ubiquitous problem that this needs to be in the stock codebase? I suspect we're dealing with a vocal minority here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 16:47:13 2019 From: report at bugs.python.org (Gregory Szorc) Date: Tue, 26 Feb 2019 21:47:13 +0000 Subject: [issue36129] io documentation unclear about flush() and close() semantics for wrapped streams Message-ID: <1551217633.94.0.247260600398.issue36129@roundup.psfhosted.org> New submission from Gregory Szorc : As part of implementing io.RawIOBase/io.BufferedIOBase compatible stream types for python-zstandard, I became confused about the expected behavior of flush() and close() when a stream is wrapping another stream. The documentation doesn't lay out explicitly when flush() and close() on the outer stream should be proxied to the inner stream, if ever. Here are some specific questions (it would be great to have answers to these in the docs): 1. When flush() is called on the outer stream, should flush() be called on the inner stream as well? Or should we simply write() to the inner stream and not perform a flush() on that inner stream? 2. When close() is called on the outer stream, should close() be called on the inner stream as well? 3. If close() is not automatically called on the inner stream during an outer stream's close(), should the outer stream trigger a flush() or any other special behavior on the inner stream? Or should it just write() any lingering data and then go away? 4. Are any of the answers from 1-3 impacted by whether the stream is a reader or writer? (Obviously reader streams don't have a meaningful flush() implementation.) 5. Are any of the answers from 1-3 impacted by whether the stream is in blocking/non-blocking mode? 6. Do any of the answers from 1-3 vary depending on whether behavior is incurred by the outer stream's __exit__? (This issue was inspired by https://github.com/indygreg/python-zstandard/issues/76.) ---------- components: Interpreter Core messages: 336715 nosy: indygreg priority: normal severity: normal status: open title: io documentation unclear about flush() and close() semantics for wrapped streams type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 17:23:02 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 26 Feb 2019 22:23:02 +0000 Subject: [issue33944] Deprecate and remove pth files In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za> Message-ID: <1551219782.65.0.253436824353.issue33944@roundup.psfhosted.org> Steve Dower added the comment: Barry is a steering council member now, so by definition he's 1/5th of the loudest possible minority ;) I am totally okay with adding more diagnostics here. Frankly, if "-v" doesn't currently log info about .pth files (or other things that the site module does when it's active) then we should just do that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 17:31:28 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 26 Feb 2019 22:31:28 +0000 Subject: [issue36030] add internal API function to create tuple without items array initialization In-Reply-To: <1550563364.86.0.164811838679.issue36030@roundup.psfhosted.org> Message-ID: <1551220288.31.0.919450179897.issue36030@roundup.psfhosted.org> STINNER Victor added the comment: > Victor/vstinner: Isn't PR 12032 reintroducing the issue fixed in #29234? No according to manual tests: https://github.com/python/cpython/pull/12032#issuecomment-467110233 Usage of the stack memory doesn't change with PR 12032. FYI I also tested manually since I was very surprised, and I confirm that the PR doesn't change the usage of the stack memory :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 17:35:25 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 26 Feb 2019 22:35:25 +0000 Subject: [issue36030] add internal API function to create tuple without items array initialization In-Reply-To: <1550563364.86.0.164811838679.issue36030@roundup.psfhosted.org> Message-ID: <1551220525.53.0.316770475269.issue36030@roundup.psfhosted.org> STINNER Victor added the comment: > if LTO is enabled, the same stack bloat issues are possible Please test, I'm not interested to spend too much time on that topic. To be clear, _Py_NO_INLINE was a hack and a micro-optimization. It doesn't solve a real bug. Python has very weak promises on the maximum stack depth. My work on reducing the stack memory usage was mostly motivated by my work on FASTCALL, since some patches reduced the maximum stack depth. They increased the stack memory usage with micro-optimizations like "PyObject *small_stack[_PY_FASTCALL_SMALL_STACK];" which is allocated on ths stack: see Objects/call.c. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 17:41:32 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 26 Feb 2019 22:41:32 +0000 Subject: [issue36127] Argument Clinic: inline parsing code for functions with keyword parameters In-Reply-To: <1551202236.03.0.123634318665.issue36127@roundup.psfhosted.org> Message-ID: <1551220892.48.0.0433733079274.issue36127@roundup.psfhosted.org> STINNER Victor added the comment: > How much bigger does the core interpreter + built-in extension modules get when you make this change? How much more memory is used by real world programs? Well, any optimization is a matter of trade-off between memory and CPU. Last years, CPU are not really getting way faster (especially when you consider that Python is usually only able to use a single CPU thread), whereas computers are getting more and more RAM. > It should be tested on a number of systems too; any losses to cache unfriendliness would be highly dependent on the size of the CPU cache. I prefer to no pay too much attention to assumptions on the hardware. I prefer to only trust benchmarks :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 18:04:20 2019 From: report at bugs.python.org (Patrick McLean) Date: Tue, 26 Feb 2019 23:04:20 +0000 Subject: [issue36046] support dropping privileges when running subprocesses In-Reply-To: <1550625858.55.0.53498127684.issue36046@roundup.psfhosted.org> Message-ID: <1551222260.33.0.459058878826.issue36046@roundup.psfhosted.org> Patrick McLean added the comment: > Thanks for your explanation. In case of a privileged process, the behavior of setreuid/setregid/setgroups does seem well-defined. But setuid/setgid change all ids (real, effective, saved) too in this case. Do you prefer setreuid/setregid because they provide stricter semantics in non-privileged processes compared to setuid/setgid? (The latter ones change the effective id only, potentially preserving the process ability to switch ids later). Yes, exactly. The stricter semantics provide stronger security guarantees. The idea is to run code in an unprivileged context in a way that the code has no way to regain privileges. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 18:31:47 2019 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 26 Feb 2019 23:31:47 +0000 Subject: [issue33944] Deprecate and remove pth files In-Reply-To: <1551214361.63.0.240756004462.issue33944@roundup.psfhosted.org> Message-ID: <2832BB08-0306-4A98-BE70-7C475E83E4B4@python.org> Barry A. Warsaw added the comment: On Feb 26, 2019, at 12:52, Ionel Cristian M?rie? wrote: > > Something bad was installed with sudo but suddenly sudo is not acceptable for debugging? This seems crazy. Your sudo may not be my sudo. :) Let?s say I update my Ubuntu desktop and a new version of package with a pth breaks. Maybe I didn?t even know I was doing that, via automated updates, or management portal, etc. Now a poor user who depends on this has their code break. How do *they* debug the problem? FWIW, `sudo pip install` should just be banned IMHO :). > How exactly are pth files hard to debug? Are those files hard to edit? They sure are, but the problem ain't the point where they are run, it's the fact that a big lump of code is stuffed on a single line. Lets fix that instead! For sure. But here?s the thing: you need to know *which* pth file is problematic. Which means you have to debug the entire startup process where pth files are loaded. That means you?re not really debugging pth files themselves (often), but site.py. Debugging site.py for an installed Python is not trivial. Hopefully you are at least not squeamish about editing a system file and breaking Python worse than the original bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 18:41:20 2019 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 26 Feb 2019 23:41:20 +0000 Subject: [issue33944] Deprecate and remove pth files In-Reply-To: <23826c7b-edc9-ca4b-866b-afdf0bb640b4@mail.ru> Message-ID: Barry A. Warsaw added the comment: On Feb 26, 2019, at 13:23, Ivan Pozdeev wrote: > > Easy. Insert a chunk into site.py that would call pdb.set_trace() if an envvar (e.g. `PYSITEDEBUG') or a command line switch is set. > > Actually, why can't whoever has this problem add such a chunk themselves? Is this really such a frequent and ubiquitous problem > that this needs to be in the stock codebase? I suspect we're dealing with a vocal minority here. Basically yes, I?ve done this. But think of the poor user who doesn?t have that expertise or ability to hack on an installed Python?s site.py file. When their application breaks because some faulty pth was installed behind their back, how do they debug their application when the breakage has already occurred before Python even gets to their code? How do they answer questions like ?where did that magical sys.path entry come from?? or ?how did that module get in sys.modules already?? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 18:45:24 2019 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 26 Feb 2019 23:45:24 +0000 Subject: [issue36128] ResourceReader for FileLoader inconsistently handles path separators In-Reply-To: <1551215100.55.0.236644911032.issue36128@roundup.psfhosted.org> Message-ID: <53809FB6-AAA3-4BDF-B1DD-7FA215C58724@python.org> Barry A. Warsaw added the comment: On Feb 26, 2019, at 13:05, Gregory Szorc wrote: > > I would think the two would agree about whether a path with separators is a resource or not. The documentation at https://docs.python.org/3.7/library/importlib.html#importlib.abc.ResourceReader implies that resources in subdirectories should not be allowed. Historical context is in the standalone tracker: https://gitlab.com/python-devs/importlib_resources/issues/58 Clearly, with the current definition of the API, open_resource() should not allow slashes. Please follow up on the above link if you have opinions about changing the behavior. We would have an opportunity to relax that constraint in Python 3.8, if it?s something we want to do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 19:25:20 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 27 Feb 2019 00:25:20 +0000 Subject: [issue36129] io documentation unclear about flush() and close() semantics for wrapped streams In-Reply-To: <1551217633.94.0.247260600398.issue36129@roundup.psfhosted.org> Message-ID: <1551227120.14.0.151958117531.issue36129@roundup.psfhosted.org> Josh Rosenberg added the comment: The general rule of thumb is to have the API behave as if no wrapping is occurring. The outermost layer should still adhere to the documented API requirements, so both flush and close should cascade (flush says it flushes the "buffers" plural; all user mode buffers should be flushed, no matter the layer), closing the outer layer without closing the inner makes it non-intuitive as to *how* you close the inner layers at all. So the answers are: 1. flush all layers when told to flush 2. close all layers when told to close (exception for when you accept a fd, you can take a closefd argument and avoid closing the fd itself, but all Python layers should be closed) 3. N/A (close cascades) 4. No. 5. Non-blocking I/O doesn't seem to have a completely consistent story, but from the existing classes, I'm guessing outer layers should try to write to the underlying stream when told to do so, and raise BlockingIOError if they'd would block. The close story should be roughly the same; try to flush, raise BlockingIOError if it would block, then close (which shouldn't do much since the buffers are flushed). 6. No. #5 is weird, and we could probably use a more coherent story for how non-blocking I/O should be done (asyncio provides one story, selectors another, and the io module seems to sort of gloss over the design strategy for non-blocking I/O). You can derive all but #5 from how the built-in open behaves; it returns different types (FileIO, Buffered*, TextIOWrapper), but whatever it returns, you don't need to pay attention to the layered aspect if you don't want to (most don't). flush works as expected (no flushing each layer independently), close works as expected (no leaked file handles from only closing the outer layer), using it with a with statement is identical to explicitly calling close with a try/finally block. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 19:30:19 2019 From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=) Date: Wed, 27 Feb 2019 00:30:19 +0000 Subject: [issue33944] Deprecate and remove pth files In-Reply-To: <2832BB08-0306-4A98-BE70-7C475E83E4B4@python.org> Message-ID: Ionel Cristian M?rie? added the comment: On Wed, Feb 27, 2019 at 1:31 AM Barry A. Warsaw wrote: > Your sudo may not be my sudo. :) Let?s say I update my Ubuntu desktop and a new version of package with a pth breaks. > Maybe I didn?t even know I was doing that, via automated updates, or management portal, etc. > Now a poor user who depends on this has their code break. How do *they* debug the problem? Well that's easy: * update my Ubuntu desktop -> stuff breaks -> rollback/downgrade * automated updates -> stuff breaks -> stop using them, and learn lesson ;) * management portal -> stuff breaks -> complain to sysadmin Desktop users don't need to debug problems, devs/sysadmins do. They have sudo. > FWIW, `sudo pip install` should just be banned IMHO :). Lets also ban ctypes and threads right? :) > For sure. But here?s the thing: you need to know *which* pth file is problematic. Which means you have to debug the entire startup process where pth files are loaded. How many pth files could one have? 2-3 ... 5 at most. Just `locate .pth` and rename the biggest one till the problem goes away. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 19:34:30 2019 From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=) Date: Wed, 27 Feb 2019 00:34:30 +0000 Subject: [issue33944] Deprecate and remove pth files In-Reply-To: Message-ID: Ionel Cristian M?rie? added the comment: On Wed, Feb 27, 2019 at 1:41 AM Barry A. Warsaw wrote: > Basically yes, I?ve done this. But think of the poor user who doesn?t have that expertise or ability to hack on an installed Python?s site.py file. When their application breaks because some faulty pth was installed behind their back, how do they debug their application when the breakage has already occurred before Python even gets to their code? How do they answer questions like ?where did that magical sys.path entry come from?? or ?how did that module get in sys.modules already?? Aren't these sort of questions answered by using `strace python -v` or similar? What information is missing more exactly? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 19:40:02 2019 From: report at bugs.python.org (Christopher Unkel) Date: Wed, 27 Feb 2019 00:40:02 +0000 Subject: [issue25872] multithreading traceback KeyError when modifying file In-Reply-To: <1450200064.35.0.872448112145.issue25872@psf.upfronthosting.co.za> Message-ID: <1551228002.68.0.666464272163.issue25872@roundup.psfhosted.org> Change by Christopher Unkel : ---------- keywords: +patch pull_requests: +12085 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 20:19:48 2019 From: report at bugs.python.org (Eric Snow) Date: Wed, 27 Feb 2019 01:19:48 +0000 Subject: [issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed. In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za> Message-ID: <1551230388.46.0.233176148149.issue33608@roundup.psfhosted.org> Change by Eric Snow : ---------- pull_requests: +12086 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 22:02:47 2019 From: report at bugs.python.org (Ned Deily) Date: Wed, 27 Feb 2019 03:02:47 +0000 Subject: [issue36125] Cannot cross-compile to more featureful but same tune In-Reply-To: <1551196810.67.0.249603335877.issue36125@roundup.psfhosted.org> Message-ID: <1551236567.42.0.555123422241.issue36125@roundup.psfhosted.org> Ned Deily added the comment: Thanks for the report. Unfortunately, as far as I know, we don't claim anywhere to support cross-compiling in general. As you've probably noticed, the Python Makefile-based build system (for non-Windows platforms) is by no means a conventional GNU autotools one. Over the years there have been some efforts to add support for a handful of specific cross-compilation scenarios, for example compiling for Android. But I'm afraid you are more or less on your own for the case here. That said, if you or someone else is motivated to supply some fixes to make more cross-compiling cases work, feel free to reopen the issue and submit the fixes as PRs and they may be considered. What would probably be the best would be to try to reimplement our build system from the ground up with modern Autotools or something similar but that's a *really* big deal. ---------- nosy: +ned.deily resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 22:04:20 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 27 Feb 2019 03:04:20 +0000 Subject: [issue28441] Change sys.executable to include executable suffix In-Reply-To: <1476452085.73.0.180033377767.issue28441@psf.upfronthosting.co.za> Message-ID: <1551236660.9.0.82308962155.issue28441@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +12087 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 22:46:52 2019 From: report at bugs.python.org (Anthony Sottile) Date: Wed, 27 Feb 2019 03:46:52 +0000 Subject: [issue36130] Pdb(skip=[...]) + module without __name__ => TypeError Message-ID: <1551239212.19.0.177135344366.issue36130@roundup.psfhosted.org> New submission from Anthony Sottile : Here's the simplest example I could come up with -- hit this while debugging pytest (which uses attrs which uses similar code to this to make classes) import pdb; pdb.Pdb(skip=['django.*']).set_trace() eval(compile("1", "", "exec"), {}) print('ok!') When running this: $ python3.8 t.py > /home/asottile/workspace/setup-cfg-fmt/t.py(2)() -> eval(compile("1", "", "exec"), {}) (Pdb) n Traceback (most recent call last): File "t.py", line 2, in eval(compile("1", "", "exec"), {}) File "", line 1, in File "/usr/lib/python3.8/bdb.py", line 90, in trace_dispatch return self.dispatch_call(frame, arg) File "/usr/lib/python3.8/bdb.py", line 128, in dispatch_call if not (self.stop_here(frame) or self.break_anywhere(frame)): File "/usr/lib/python3.8/bdb.py", line 203, in stop_here self.is_skipped_module(frame.f_globals.get('__name__')): File "/usr/lib/python3.8/bdb.py", line 194, in is_skipped_module if fnmatch.fnmatch(module_name, pattern): File "/usr/lib/python3.8/fnmatch.py", line 34, in fnmatch name = os.path.normcase(name) File "/usr/lib/python3.8/posixpath.py", line 54, in normcase s = os.fspath(s) TypeError: expected str, bytes or os.PathLike object, not NoneType $ python3.8 --version --version Python 3.8.0a2 (default, Feb 25 2019, 23:11:49) [GCC 7.3.0] ---------- components: Library (Lib) messages: 336728 nosy: Anthony Sottile priority: normal severity: normal status: open title: Pdb(skip=[...]) + module without __name__ => TypeError versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 26 23:44:09 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Wed, 27 Feb 2019 04:44:09 +0000 Subject: [issue36130] Pdb(skip=[...]) + module without __name__ => TypeError In-Reply-To: <1551239212.19.0.177135344366.issue36130@roundup.psfhosted.org> Message-ID: <1551242649.41.0.810696050317.issue36130@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +xdegaye, xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 00:06:02 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Wed, 27 Feb 2019 05:06:02 +0000 Subject: [issue36131] test.test_urllib2net.TimeoutTest ftp related tests fail due to ftp://www.pythontest.net/ being unavailable Message-ID: <1551243962.9.0.321127985724.issue36131@roundup.psfhosted.org> New submission from Karthikeyan Singaravelan : I am seeing this error on Windows and Mac CI builds where FTP related tests in test.test_urllib2net.TimeoutTest are failing. It's reproducible locally too where the tests are skipped on Mac and Ubuntu. Not sure if it's random since several PRs in the last few hours fail with this. Appveyor : * https://ci.appveyor.com/project/python/cpython/builds/22675425#L2817 VSTS builds : * https://dev.azure.com/Python/cpython/_build/results?buildId=38631 * https://dev.azure.com/Python/cpython/_build/results?buildId=38625 $ ./python.exe -m unittest -vv test.test_urllib2net.TimeoutTest test_ftp_basic (test.test_urllib2net.TimeoutTest) ... skipped "Resource 'ftp://www.pythontest.net/' is not available" test_ftp_default_timeout (test.test_urllib2net.TimeoutTest) ... skipped "Resource 'ftp://www.pythontest.net/' is not available" test_ftp_no_timeout (test.test_urllib2net.TimeoutTest) ... /Users/karthikeyansingaravelan/stuff/python/cpython/Lib/encodings/idna.py:163: ResourceWarning: unclosed for label in labels[:-1]: ResourceWarning: Enable tracemalloc to get the object allocation traceback /Users/karthikeyansingaravelan/stuff/python/cpython/Lib/encodings/idna.py:163: ResourceWarning: unclosed for label in labels[:-1]: ResourceWarning: Enable tracemalloc to get the object allocation traceback /Users/karthikeyansingaravelan/stuff/python/cpython/Lib/encodings/idna.py:163: ResourceWarning: unclosed for label in labels[:-1]: ResourceWarning: Enable tracemalloc to get the object allocation traceback /Users/karthikeyansingaravelan/stuff/python/cpython/Lib/encodings/idna.py:163: ResourceWarning: unclosed for label in labels[:-1]: ResourceWarning: Enable tracemalloc to get the object allocation traceback /Users/karthikeyansingaravelan/stuff/python/cpython/Lib/encodings/idna.py:163: ResourceWarning: unclosed for label in labels[:-1]: ResourceWarning: Enable tracemalloc to get the object allocation traceback skipped "Resource 'ftp://www.pythontest.net/' is not available" test_ftp_timeout (test.test_urllib2net.TimeoutTest) ... skipped "Resource 'ftp://www.pythontest.net/' is not available" test_http_basic (test.test_urllib2net.TimeoutTest) ... ok test_http_default_timeout (test.test_urllib2net.TimeoutTest) ... ok test_http_no_timeout (test.test_urllib2net.TimeoutTest) ... ok test_http_timeout (test.test_urllib2net.TimeoutTest) ... ok ---------------------------------------------------------------------- Ran 8 tests in 33.617s OK (skipped=4) ---------- components: Tests messages: 336729 nosy: benjamin.peterson, pablogsal, vstinner, xtreak priority: normal severity: normal status: open title: test.test_urllib2net.TimeoutTest ftp related tests fail due to ftp://www.pythontest.net/ being unavailable type: behavior versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 01:34:14 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Wed, 27 Feb 2019 06:34:14 +0000 Subject: [issue36131] test.test_urllib2net.TimeoutTest ftp related tests fail due to ftp://www.pythontest.net/ being unavailable In-Reply-To: <1551243962.9.0.321127985724.issue36131@roundup.psfhosted.org> Message-ID: <1551249254.13.0.994793486218.issue36131@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: Several buildbots are failing due to this problem. Some examples: https://buildbot.python.org/all/#builders/33/builds/520 https://buildbot.python.org/all/#builders/72/builds/503 https://buildbot.python.org/all/#builders/78/builds/419 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 01:34:35 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Wed, 27 Feb 2019 06:34:35 +0000 Subject: [issue36131] test.test_urllib2net.TimeoutTest ftp related tests fail due to ftp://www.pythontest.net/ being unavailable In-Reply-To: <1551243962.9.0.321127985724.issue36131@roundup.psfhosted.org> Message-ID: <1551249275.46.0.756616478864.issue36131@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- priority: normal -> high versions: +Python 2.7, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 01:43:33 2019 From: report at bugs.python.org (Anthony Sottile) Date: Wed, 27 Feb 2019 06:43:33 +0000 Subject: [issue36130] Pdb(skip=[...]) + module without __name__ => TypeError In-Reply-To: <1551239212.19.0.177135344366.issue36130@roundup.psfhosted.org> Message-ID: <1551249813.06.0.876970380937.issue36130@roundup.psfhosted.org> Change by Anthony Sottile : ---------- keywords: +patch pull_requests: +12088 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 01:56:51 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Wed, 27 Feb 2019 06:56:51 +0000 Subject: [issue36131] test.test_urllib2net.TimeoutTest ftp related tests fail due to ftp://www.pythontest.net/ being unavailable In-Reply-To: <1551243962.9.0.321127985724.issue36131@roundup.psfhosted.org> Message-ID: <1551250611.13.0.869950075704.issue36131@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: These tests were skipped in Travis with issue35411 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 02:04:48 2019 From: report at bugs.python.org (Safihre) Date: Wed, 27 Feb 2019 07:04:48 +0000 Subject: [issue31122] SSLContext.wrap_socket() throws OSError with errno == 0 In-Reply-To: <1501874201.48.0.0126792321555.issue31122@psf.upfronthosting.co.za> Message-ID: <1551251088.13.0.417976664817.issue31122@roundup.psfhosted.org> Safihre added the comment: In the CherryPy project it is also observed on Windows with Python 3,7.2. In CherryPy it's triggered by Checker plugin, which connects to the app listening to the socket port in TLS mode via plain HTTP during startup (from the same process). It has been around for a while: https://github.com/cherrypy/cherrypy/issues/1618#issuecomment-454150794 ---------- nosy: +Safihre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 02:16:35 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 27 Feb 2019 07:16:35 +0000 Subject: [issue35892] Fix awkwardness of statistics.mode() for multimodal datasets In-Reply-To: <1549219885.57.0.86866159357.issue35892@roundup.psfhosted.org> Message-ID: <1551251795.38.0.453148090195.issue35892@roundup.psfhosted.org> Raymond Hettinger added the comment: > Are you happy guaranteeing that it will always be the first > mode encountered? Yes. All of the other implementations I looked at make some guarantee about which mode is returned. Maple, Matlab, and Excel all return the first encountered.? That is convenient for us because it is what Counter(data).most_common(1) already does and does cheaply (single pass, no auxiliary memory). It also matches what a number of our other tools do: >>> max(3, 3.0) # 3 is first encountered 3 >>> max(3.0, 3) # 3.0 is first encountered 3.0 >>> list(dict.fromkeys('aabbaacc'))[0] # 'a' is first encountered 'a' >>> sorted([3, 3.0])[0] # 3 is first encountered (due to sort stability) 3 >>> sorted([3.0, 3])[0] # 3.0 is first encountered (due to sort stability) 3.0 ? Scipy returned the smallest value rather than first value but it algorithm was sorting based to accommodate running a parallel mode() computation on multiple columns of an array. For us, that approach would be much slow, would require more memory, and would require more bookkeeping. P.S. I'm no longer thinking this should be saved for Pycon sprints. That is right at the beta 1 feature freeze. We should aim to get this resolved well in advance of that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 02:57:24 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Wed, 27 Feb 2019 07:57:24 +0000 Subject: [issue36030] add internal API function to create tuple without items array initialization In-Reply-To: <1550563364.86.0.164811838679.issue36030@roundup.psfhosted.org> Message-ID: <1551254244.48.0.221184796928.issue36030@roundup.psfhosted.org> Sergey Fedoseev added the comment: > Can you please convert msg336142 into a perf script? > And then run again these benchmarks on PR 12052. +--------------------+---------+------------------------------+ | Benchmark | ref | untracked | +====================+=========+==============================+ | list_as_tuple(0) | 50.7 ns | 45.5 ns: 1.12x faster (-10%) | +--------------------+---------+------------------------------+ | list_as_tuple(1) | 64.5 ns | 56.5 ns: 1.14x faster (-12%) | +--------------------+---------+------------------------------+ | list_as_tuple(5) | 72.0 ns | 62.6 ns: 1.15x faster (-13%) | +--------------------+---------+------------------------------+ | list_as_tuple(10) | 86.3 ns | 77.1 ns: 1.12x faster (-11%) | +--------------------+---------+------------------------------+ | list_as_tuple(100) | 469 ns | 450 ns: 1.04x faster (-4%) | +--------------------+---------+------------------------------+ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 03:11:53 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Wed, 27 Feb 2019 08:11:53 +0000 Subject: [issue36030] add internal API function to create tuple without items array initialization In-Reply-To: <1550563364.86.0.164811838679.issue36030@roundup.psfhosted.org> Message-ID: <1551255113.27.0.307132931695.issue36030@roundup.psfhosted.org> Sergey Fedoseev added the comment: >> This optimization also can be used for BUILD_TUPLE opcode and in pickle module, if it's OK to add _PyTuple_StealFromArray() function :-) > I would like to see a micro-benchmark showing that it's faster. +-----------------+-----------------+-----------------------------+ | Benchmark | build_tuple_ref | build_tuple_untracked | +=================+=================+=============================+ | (a, ) | 19.9 ns | 19.4 ns: 1.03x faster (-3%) | +-----------------+-----------------+-----------------------------+ | (a, 1) | 24.0 ns | 22.6 ns: 1.06x faster (-6%) | +-----------------+-----------------+-----------------------------+ | (a, 1, 1) | 28.2 ns | 25.9 ns: 1.09x faster (-8%) | +-----------------+-----------------+-----------------------------+ | (a, 1, 1, 1) | 31.0 ns | 29.0 ns: 1.07x faster (-6%) | +-----------------+-----------------+-----------------------------+ | (a, 1, 1, 1, 1) | 34.7 ns | 32.2 ns: 1.08x faster (-7%) | +-----------------+-----------------+-----------------------------+ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 03:14:41 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Wed, 27 Feb 2019 08:14:41 +0000 Subject: [issue36030] add internal API function to create tuple without items array initialization In-Reply-To: <1550563364.86.0.164811838679.issue36030@roundup.psfhosted.org> Message-ID: <1551255281.03.0.596617139162.issue36030@roundup.psfhosted.org> Change by Sergey Fedoseev : Added file: https://bugs.python.org/file48173/build_tuple_bench.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 03:14:51 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Wed, 27 Feb 2019 08:14:51 +0000 Subject: [issue36030] add internal API function to create tuple without items array initialization In-Reply-To: <1550563364.86.0.164811838679.issue36030@roundup.psfhosted.org> Message-ID: <1551255291.21.0.638965779587.issue36030@roundup.psfhosted.org> Change by Sergey Fedoseev : Added file: https://bugs.python.org/file48174/list_as_tuple_bench.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 03:27:51 2019 From: report at bugs.python.org (Sebastian Koslowski) Date: Wed, 27 Feb 2019 08:27:51 +0000 Subject: =?utf-8?q?=5Bissue34841=5D_Script=E2=80=99s_directory_not_in_sys=2Epath_w?= =?utf-8?q?ith_embeddable_Windows_distribution?= In-Reply-To: <1538207344.54.0.545547206417.issue34841@psf.upfronthosting.co.za> Message-ID: <1551256071.47.0.530298112904.issue34841@roundup.psfhosted.org> Sebastian Koslowski added the comment: I ran into the same problem. Seems like adding an empty sys.path entry through the _pth file is not supported at the moment: https://github.com/python/cpython/blob/53b9e1a1c1d86187ad6fbee492b697ef8be74205/PC/getpathp.c#L589 For now, I have enabled 'import site' and edited that (inside the zip file) to include 'sys.path.insert(0, "")' ---------- nosy: +skoslowski _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 04:06:01 2019 From: report at bugs.python.org (Jules Lasne) Date: Wed, 27 Feb 2019 09:06:01 +0000 Subject: [issue35524] using/windows launcher image might be deprecated In-Reply-To: <1545135302.84.0.788709270274.issue35524@psf.upfronthosting.co.za> Message-ID: <1551258361.41.0.614010743325.issue35524@roundup.psfhosted.org> Jules Lasne added the comment: Hi there, any news on this ? Of course it isn't top priority but might as well do it if you can :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 04:24:47 2019 From: report at bugs.python.org (Inada Naoki) Date: Wed, 27 Feb 2019 09:24:47 +0000 Subject: [issue28441] Change sys.executable to include executable suffix In-Reply-To: <1476452085.73.0.180033377767.issue28441@psf.upfronthosting.co.za> Message-ID: <1551259487.52.0.90485979657.issue28441@roundup.psfhosted.org> Inada Naoki added the comment: New changeset e5897b67badeb04a04e16e29f7650d833141d67e by Inada Naoki (Miss Islington (bot)) in branch '3.7': bpo-28441: Ensure `.exe` suffix in `sys.executable` on MinGW and Cygwin (GH-4348) https://github.com/python/cpython/commit/e5897b67badeb04a04e16e29f7650d833141d67e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 05:41:44 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 27 Feb 2019 10:41:44 +0000 Subject: [issue36131] test.test_urllib2net.TimeoutTest ftp related tests fail due to ftp://www.pythontest.net/ being unavailable In-Reply-To: <1551243962.9.0.321127985724.issue36131@roundup.psfhosted.org> Message-ID: <1551264104.72.0.237416004147.issue36131@roundup.psfhosted.org> STINNER Victor added the comment: Right now, ftp://www.pythontest.net/ fails with "500 OOPS: vsf_sysutil_bind" according to Firefox. It's not the first time that I see this error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 05:59:20 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 27 Feb 2019 10:59:20 +0000 Subject: [issue36131] test.test_urllib2net.TimeoutTest ftp related tests fail due to ftp://www.pythontest.net/ being unavailable In-Reply-To: <1551243962.9.0.321127985724.issue36131@roundup.psfhosted.org> Message-ID: <1551265160.1.0.380141609486.issue36131@roundup.psfhosted.org> STINNER Victor added the comment: > https://buildbot.python.org/all/#builders/33/builds/520 ERROR: test_ftp_basic (test.test_urllib2net.TimeoutTest) ERROR: test_ftp_default_timeout (test.test_urllib2net.TimeoutTest) ERROR: test_ftp_no_timeout (test.test_urllib2net.TimeoutTest) ERROR: test_ftp_timeout (test.test_urllib2net.TimeoutTest) Example: ERROR: test_ftp_basic (test.test_urllib2net.TimeoutTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\buildarea\2.7.ware-win81-release.refleak\build\lib\test\test_urllib2net.py", line 300, in test_ftp_basic u = _urlopen_with_retry(self.FTP_HOST) File "D:\buildarea\2.7.ware-win81-release.refleak\build\lib\test\test_urllib2net.py", line 25, in wrapped return _retry_thrice(func, exc, *args, **kwargs) File "D:\buildarea\2.7.ware-win81-release.refleak\build\lib\test\test_urllib2net.py", line 21, in _retry_thrice raise last_exc URLError: ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 06:01:18 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 27 Feb 2019 11:01:18 +0000 Subject: [issue36131] test.test_urllib2net.TimeoutTest ftp related tests fail due to ftp://www.pythontest.net/ being unavailable In-Reply-To: <1551243962.9.0.321127985724.issue36131@roundup.psfhosted.org> Message-ID: <1551265278.79.0.207985895457.issue36131@roundup.psfhosted.org> STINNER Victor added the comment: $ ./python -m test -v test_urllib2net -u all ... test_ftp (test.test_urllib2net.OtherNetworkTests) ... skipped "Resource 'ftp://www.pythontest.net/README' is not available" test_redirect_url_withfrag (test.test_urllib2net.OtherNetworkTests) ... ok test_sites_no_connection_close (test.test_urllib2net.OtherNetworkTests) ... skipped 'XXX: http://www.imdb.com is gone' test_urlwithfrag (test.test_urllib2net.OtherNetworkTests) ... ok test_ftp_basic (test.test_urllib2net.TimeoutTest) ... skipped "Resource 'ftp://www.pythontest.net/' is not available" test_ftp_default_timeout (test.test_urllib2net.TimeoutTest) ... skipped "Resource 'ftp://www.pythontest.net/' is not available" test_ftp_no_timeout (test.test_urllib2net.TimeoutTest) ... ERROR test_ftp_timeout (test.test_urllib2net.TimeoutTest) ... ERROR ... ERROR: test_ftp_no_timeout (test.test_urllib2net.TimeoutTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/vstinner/prog/python/master/Lib/urllib/request.py", line 1540, in ftp_open fp, retrlen = fw.retrfile(file, type) File "/home/vstinner/prog/python/master/Lib/urllib/request.py", line 2425, in retrfile conn, retrlen = self.ftp.ntransfercmd(cmd) File "/home/vstinner/prog/python/master/Lib/ftplib.py", line 359, in ntransfercmd host, port = self.makepasv() File "/home/vstinner/prog/python/master/Lib/ftplib.py", line 337, in makepasv host, port = parse227(self.sendcmd('PASV')) File "/home/vstinner/prog/python/master/Lib/ftplib.py", line 273, in sendcmd return self.getresp() File "/home/vstinner/prog/python/master/Lib/ftplib.py", line 246, in getresp raise error_perm(resp) ftplib.error_perm: 500 OOPS: vsf_sysutil_bind During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/vstinner/prog/python/master/Lib/test/test_urllib2net.py", line 327, in test_ftp_no_timeout u = _urlopen_with_retry(self.FTP_HOST, timeout=None) File "/home/vstinner/prog/python/master/Lib/test/test_urllib2net.py", line 27, in wrapped return _retry_thrice(func, exc, *args, **kwargs) File "/home/vstinner/prog/python/master/Lib/test/test_urllib2net.py", line 23, in _retry_thrice raise last_exc File "/home/vstinner/prog/python/master/Lib/test/test_urllib2net.py", line 19, in _retry_thrice return func(*args, **kwargs) File "/home/vstinner/prog/python/master/Lib/urllib/request.py", line 222, in urlopen return opener.open(url, data, timeout) File "/home/vstinner/prog/python/master/Lib/urllib/request.py", line 525, in open response = self._open(req, data) File "/home/vstinner/prog/python/master/Lib/urllib/request.py", line 542, in _open result = self._call_chain(self.handle_open, protocol, protocol + File "/home/vstinner/prog/python/master/Lib/urllib/request.py", line 503, in _call_chain result = func(*args) File "/home/vstinner/prog/python/master/Lib/urllib/request.py", line 1551, in ftp_open raise exc.with_traceback(sys.exc_info()[2]) File "/home/vstinner/prog/python/master/Lib/urllib/request.py", line 1540, in ftp_open fp, retrlen = fw.retrfile(file, type) File "/home/vstinner/prog/python/master/Lib/urllib/request.py", line 2425, in retrfile conn, retrlen = self.ftp.ntransfercmd(cmd) File "/home/vstinner/prog/python/master/Lib/ftplib.py", line 359, in ntransfercmd host, port = self.makepasv() File "/home/vstinner/prog/python/master/Lib/ftplib.py", line 337, in makepasv host, port = parse227(self.sendcmd('PASV')) File "/home/vstinner/prog/python/master/Lib/ftplib.py", line 273, in sendcmd return self.getresp() File "/home/vstinner/prog/python/master/Lib/ftplib.py", line 246, in getresp raise error_perm(resp) urllib.error.URLError: ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 06:09:35 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 27 Feb 2019 11:09:35 +0000 Subject: [issue31904] Python should support VxWorks RTOS In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za> Message-ID: <1551265775.76.0.176813644115.issue31904@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 32f5fdd7f4213743fe2f6eedd0fe2108f3157021 by Victor Stinner (pxinwr) in branch 'master': bpo-31904: Add cross-build support for VxWorks RTOS (GH-11968) https://github.com/python/cpython/commit/32f5fdd7f4213743fe2f6eedd0fe2108f3157021 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 06:10:31 2019 From: report at bugs.python.org (Andrew P. Lentvorski, Jr.) Date: Wed, 27 Feb 2019 11:10:31 +0000 Subject: [issue36132] Python cannot access hci_channel field in sockaddr_hci Message-ID: <1551265831.42.0.956760803512.issue36132@roundup.psfhosted.org> New submission from Andrew P. Lentvorski, Jr. : On Linux, sockaddr_hci is: struct sockaddr_hci { sa_family_t hci_family; unsigned short hci_dev; unsigned short hci_channel; }; Unfortunately, it seems like python does not allow any way to initialize hci_channel, so you can't use a user channel socket (hci_channel == 0) or a monitor channel. There is probably a larger discussion of how to enable people to use a new field that appears in a structure like this, but that's above my pay grade ... Even worse, this appears to have been known for a while (since 2013 at least! by Chromium), but while people complained, nobody actually took the time to file it upstream with Python. So, I'm filing it upstream. Hopefully this is easy to fix by someone who knows what's up. Thanks. See: https://chromium.googlesource.com/chromiumos/platform/btsocket/+/factory-4455.B https://github.com/w3h/isf/blob/master/lib/thirdparty/scapy/layers/bluetooth.py class BluetoothUserSocket(SuperSocket): desc = "read/write H4 over a Bluetooth user channel" def __init__(self, adapter=0): # s = socket.socket(socket.AF_BLUETOOTH, socket.SOCK_RAW, socket.BTPROTO_HCI) # s.bind((0,1)) # yeah, if only # thanks to Python's weak ass socket and bind implementations, we have # to call down into libc with ctypes sockaddr_hcip = POINTER(sockaddr_hci) cdll.LoadLibrary("libc.so.6") libc = CDLL("libc.so.6") socket_c = libc.socket socket_c.argtypes = (c_int, c_int, c_int); socket_c.restype = c_int bind = libc.bind bind.argtypes = (c_int, POINTER(sockaddr_hci), c_int) bind.restype = c_int ######## ## actual code s = socket_c(31, 3, 1) # (AF_BLUETOOTH, SOCK_RAW, HCI_CHANNEL_USER) if s < 0: raise BluetoothSocketError("Unable to open PF_BLUETOOTH socket") sa = sockaddr_hci() sa.sin_family = 31 # AF_BLUETOOTH sa.hci_dev = adapter # adapter index sa.hci_channel = 1 # HCI_USER_CHANNEL r = bind(s, sockaddr_hcip(sa), sizeof(sa)) ---------- components: Library (Lib) messages: 336743 nosy: bsder priority: normal severity: normal status: open title: Python cannot access hci_channel field in sockaddr_hci versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 06:13:49 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 27 Feb 2019 11:13:49 +0000 Subject: [issue36132] Python cannot access hci_channel field in sockaddr_hci In-Reply-To: <1551265831.42.0.956760803512.issue36132@roundup.psfhosted.org> Message-ID: <1551266029.22.0.592366777102.issue36132@roundup.psfhosted.org> St?phane Wirtel added the comment: Thank you, I have changed the related versions of Python to 3.8 because it's a new feature and the other releases are in security mode or bugfix mode. ---------- nosy: +matrixise versions: -Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 06:40:15 2019 From: report at bugs.python.org (Fabian Dill) Date: Wed, 27 Feb 2019 11:40:15 +0000 Subject: [issue36133] ThreadPoolExecutor and ProcessPoolExecutor, dynamic worker count Message-ID: <1551267615.45.0.917307104051.issue36133@roundup.psfhosted.org> New submission from Fabian Dill : The request is, that the _max_workers attribute of the pools are exposed as a proper interface, that would allow changing of the worker amount after initialisation. ---------- components: Library (Lib) messages: 336745 nosy: Fabian Dill priority: normal severity: normal status: open title: ThreadPoolExecutor and ProcessPoolExecutor, dynamic worker count versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 06:45:19 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Wed, 27 Feb 2019 11:45:19 +0000 Subject: [issue36131] test.test_urllib2net.TimeoutTest ftp related tests fail due to ftp://www.pythontest.net/ being unavailable In-Reply-To: <1551243962.9.0.321127985724.issue36131@roundup.psfhosted.org> Message-ID: <1551267919.03.0.0605909092941.issue36131@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: > Right now, ftp://www.pythontest.net/ fails with "500 OOPS: vsf_sysutil_bind" according to Firefox. It's not the first time that I see this error. Related issue in the past due to disk space issue35386 . When I first created the issue opening the FTP URL on Firefox used to give me result or raise 425 Bad IP error but now it's now consistently returning "500 OOPS: vsf_sysutil_bind" consistently. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 07:37:54 2019 From: report at bugs.python.org (Apoorv Sachan) Date: Wed, 27 Feb 2019 12:37:54 +0000 Subject: [issue36134] test failure : test_re; recipe for target 'test' failed Message-ID: <1551271074.84.0.0671486163913.issue36134@roundup.psfhosted.org> New submission from Apoorv Sachan : ## while building python3.7 from source code on debian9.8 stretch. hardware : intel corei5 3337U 4 Gib -- physical ram//4 Gib -- swap space following the instructions given in the README.rst file: user at host $ ./configure --enable-optimizations #---works fine : no issues user at host $ make #---works fine : noissues user at host $ make test produces this FAIL: test_locale_flag (test.test_re.ReTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/apoos-maximus/packages/Python-3.7.2/Lib/test/test_re.py", line 1540, in test_locale_flag self.assertTrue(pat.match(bletter)) AssertionError: None is not true ---------------------------------------------------------------------- Ran 123 tests in 1.048s FAILED (failures=1, skipped=2) test test_re failed 1 test failed again: test_re == Tests result: FAILURE then FAILURE == 384 tests OK. 1 test failed: test_re 29 tests skipped: test_bz2 test_ctypes test_curses test_dbm_gnu test_dbm_ndbm test_devpoll test_gdb test_gzip test_idle test_kqueue test_lzma test_msilib test_ossaudiodev test_readline test_smtpnet test_sqlite test_ssl test_startfile test_tcl test_tix test_tk test_ttk_guionly test_ttk_textonly test_turtle test_winconsoleio test_winreg test_winsound test_zipfile64 test_zlib 1 re-run test: test_re 2 tests run no tests: test_dtrace test_future4 Total duration: 4 min 44 sec Tests result: FAILURE then FAILURE Makefile:1074: recipe for target 'test' failed make: *** [test] Error 2 #on rerunning the same test user at host $ make test TESTOPTS="-v test_re" FAIL: test_locale_flag (test.test_re.ReTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/apoos-maximus/packages/Python-3.7.2/Lib/test/test_re.py", line 1540, in test_locale_flag self.assertTrue(pat.match(bletter)) AssertionError: None is not true ---------------------------------------------------------------------- Ran 123 tests in 0.750s FAILED (failures=1, skipped=2) test test_re failed 1 test failed again: test_re == Tests result: FAILURE then FAILURE == 1 test failed: test_re 1 re-run test: test_re Total duration: 1 sec 646 ms Tests result: FAILURE then FAILURE Makefile:1074: recipe for target 'test' failed make: *** [test] Error 2 ###### this is how the bug could be reproduced PS: do have a look at the traceback ::it makes no sense to me, it might to you ! ---------- components: Build messages: 336747 nosy: apoos-maximus priority: normal severity: normal status: open title: test failure : test_re; recipe for target 'test' failed type: compile error versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 07:46:41 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 Feb 2019 12:46:41 +0000 Subject: [issue36127] Argument Clinic: inline parsing code for functions with keyword parameters In-Reply-To: <1551202236.03.0.123634318665.issue36127@roundup.psfhosted.org> Message-ID: <1551271601.06.0.46645998412.issue36127@roundup.psfhosted.org> Serhiy Storchaka added the comment: Good questions Josh! The size of the python binary has been increased from 17494944 bytes (17085 KiB) to 17657112 bytes (17243 KiB) -- by 1%. I think that this change can not increase memory consumption, because the new code does not use the heap (the old code can allocate additional memory dynamically). As for using the stack memory, it is not so clear. On one side, the new code allocates an array on the stack for references to all parameters, and this memory is left in use until you return from the function. On other side, the old code allocates a lot of variables and static-sized buffers, and creates several function frames, but this memory is released after the end of arguments parsing. I think that for non-recursive functions the new code has smaller stack memory consumption (while the function has less than several tens of parameters), but for recursive functions it can increase stack memory consumption. Although I do not know whether any of affected functions is recursive. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 07:52:51 2019 From: report at bugs.python.org (Apoorv Sachan) Date: Wed, 27 Feb 2019 12:52:51 +0000 Subject: [issue36135] altinstall error Makefile:1140: recipe for target 'altinstall' failed Message-ID: <1551271971.31.0.932732600535.issue36135@roundup.psfhosted.org> New submission from Apoorv Sachan : #as directed in the README.rst file #doing a 'make altinstall' instead of install to install python3.7.2 along side other versions ....this is to be performed after './configure' 'make' and 'make test' commands. please refer issue 36134 :titled :: (two issues could be related) "test failure : test_re; recipe for target 'test' failed" as there was also a make test failure prior to 'make altinstall' -------terminal-------------- user at host $ make altinstall .... #... everything goes well.... #... process ends with this traceback . . . . Traceback (most recent call last): File "/home/apoos-maximus/packages/Python-3.7.2/Lib/runpy.py", line 193, in _run_module_as_main "__main__", mod_spec) File "/home/apoos-maximus/packages/Python-3.7.2/Lib/runpy.py", line 85, in _run_code exec(code, run_globals) File "/home/apoos-maximus/packages/Python-3.7.2/Lib/ensurepip/__main__.py", line 5, in sys.exit(ensurepip._main()) File "/home/apoos-maximus/packages/Python-3.7.2/Lib/ensurepip/__init__.py", line 204, in _main default_pip=args.default_pip, File "/home/apoos-maximus/packages/Python-3.7.2/Lib/ensurepip/__init__.py", line 117, in _bootstrap return _run_pip(args + [p[0] for p in _PROJECTS], additional_paths) File "/home/apoos-maximus/packages/Python-3.7.2/Lib/ensurepip/__init__.py", line 27, in _run_pip import pip._internal zipimport.ZipImportError: can't decompress data; zlib not available Makefile:1140: recipe for target 'altinstall' failed make: *** [altinstall] Error 1 =========end============== i do end up with a python 3.7 installation and still can't make sense of the failure. ---------- components: Installation messages: 336749 nosy: apoos-maximus priority: normal severity: normal status: open title: altinstall error Makefile:1140: recipe for target 'altinstall' failed type: compile error versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 07:53:50 2019 From: report at bugs.python.org (Yash Aggarwal) Date: Wed, 27 Feb 2019 12:53:50 +0000 Subject: [issue35431] Add a function for computing binomial coefficients to the math module In-Reply-To: <1544131082.09.0.788709270274.issue35431@psf.upfronthosting.co.za> Message-ID: <1551272030.76.0.205693009235.issue35431@roundup.psfhosted.org> Yash Aggarwal added the comment: @mark.dickinson Ok, then I will work on comb for now then. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 07:59:31 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Wed, 27 Feb 2019 12:59:31 +0000 Subject: [issue36134] test failure : test_re; recipe for target 'test' failed In-Reply-To: <1551271074.84.0.0671486163913.issue36134@roundup.psfhosted.org> Message-ID: <1551272371.05.0.974966775616.issue36134@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Search gives me issue29571 that looks similar to this report. This seems to be locale specific and information on your locale, OS etc would be helpful. Can you please add the output of below? * python -m test.pythoninfo * locale * ./python -m test -v test_re Thanks ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 08:00:34 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 Feb 2019 13:00:34 +0000 Subject: [issue36127] Argument Clinic: inline parsing code for functions with keyword parameters In-Reply-To: <1551202236.03.0.123634318665.issue36127@roundup.psfhosted.org> Message-ID: <1551272434.07.0.338437739622.issue36127@roundup.psfhosted.org> Serhiy Storchaka added the comment: As for depending the optimization on the size of CPU cache, I have repeated mickrobenchmarks on the computer with 6 MiB cache and two computers with 512 KiB caches (64- and 32-bit). Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz (cache size: 6144 KB): +---------------------------------+----------+------------------------------+ | Benchmark | baseline | inline | +=================================+==========+==============================+ | round_(4.2) | 113 ns | 81.3 ns: 1.39x faster (-28%) | +---------------------------------+----------+------------------------------+ | sum_(()) | 83.8 ns | 56.7 ns: 1.48x faster (-32%) | +---------------------------------+----------+------------------------------+ | sum_(a) | 98.0 ns | 72.1 ns: 1.36x faster (-26%) | +---------------------------------+----------+------------------------------+ | 'abc'.split() | 107 ns | 83.1 ns: 1.29x faster (-22%) | +---------------------------------+----------+------------------------------+ | b'abc'.split() | 101 ns | 75.4 ns: 1.34x faster (-25%) | +---------------------------------+----------+------------------------------+ | 'abc'.split('-') | 123 ns | 89.9 ns: 1.37x faster (-27%) | +---------------------------------+----------+------------------------------+ | 'abc'.encode() | 79.6 ns | 59.2 ns: 1.34x faster (-26%) | +---------------------------------+----------+------------------------------+ | b'abc'.decode() | 105 ns | 84.7 ns: 1.24x faster (-20%) | +---------------------------------+----------+------------------------------+ | int_(4.2) | 88.9 ns | 64.1 ns: 1.39x faster (-28%) | +---------------------------------+----------+------------------------------+ | int_('5') | 137 ns | 108 ns: 1.28x faster (-22%) | +---------------------------------+----------+------------------------------+ | 42 .to_bytes(2, 'little') | 113 ns | 77.6 ns: 1.45x faster (-31%) | +---------------------------------+----------+------------------------------+ | int_from_bytes(b'ab', 'little') | 83.4 ns | 51.5 ns: 1.62x faster (-38%) | +---------------------------------+----------+------------------------------+ | struct_i32_unpack_from(b'abcd') | 96.0 ns | 71.6 ns: 1.34x faster (-25%) | +---------------------------------+----------+------------------------------+ | re_word_match('a') | 221 ns | 180 ns: 1.22x faster (-18%) | +---------------------------------+----------+------------------------------+ | datetime_now() | 282 ns | 248 ns: 1.14x faster (-12%) | +---------------------------------+----------+------------------------------+ Not significant (1): zlib_compress(b'abc') AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ (cache size: 512 KB): +---------------------------------+----------+-----------------------------+ | Benchmark | baseline | inline | +=================================+==========+=============================+ | round_(4.2) | 391 ns | 272 ns: 1.44x faster (-31%) | +---------------------------------+----------+-----------------------------+ | sum_(()) | 212 ns | 160 ns: 1.32x faster (-24%) | +---------------------------------+----------+-----------------------------+ | sum_(a) | 256 ns | 211 ns: 1.21x faster (-18%) | +---------------------------------+----------+-----------------------------+ | 'abc'.split() | 290 ns | 233 ns: 1.25x faster (-20%) | +---------------------------------+----------+-----------------------------+ | b'abc'.split() | 263 ns | 226 ns: 1.16x faster (-14%) | +---------------------------------+----------+-----------------------------+ | 'abc'.split('-') | 316 ns | 262 ns: 1.21x faster (-17%) | +---------------------------------+----------+-----------------------------+ | 'abc'.encode() | 197 ns | 154 ns: 1.28x faster (-22%) | +---------------------------------+----------+-----------------------------+ | b'abc'.decode() | 303 ns | 250 ns: 1.21x faster (-18%) | +---------------------------------+----------+-----------------------------+ | int_(4.2) | 234 ns | 171 ns: 1.37x faster (-27%) | +---------------------------------+----------+-----------------------------+ | int_('5') | 372 ns | 310 ns: 1.20x faster (-17%) | +---------------------------------+----------+-----------------------------+ | 42 .to_bytes(2, 'little') | 370 ns | 245 ns: 1.51x faster (-34%) | +---------------------------------+----------+-----------------------------+ | int_from_bytes(b'ab', 'little') | 251 ns | 167 ns: 1.50x faster (-33%) | +---------------------------------+----------+-----------------------------+ | struct_i32_unpack_from(b'abcd') | 252 ns | 202 ns: 1.24x faster (-20%) | +---------------------------------+----------+-----------------------------+ | re_word_match('a') | 625 ns | 524 ns: 1.19x faster (-16%) | +---------------------------------+----------+-----------------------------+ | datetime_now() | 2.05 us | 1.99 us: 1.03x faster (-3%) | +---------------------------------+----------+-----------------------------+ | zlib_compress(b'abc') | 28.6 us | 28.0 us: 1.02x faster (-2%) | +---------------------------------+----------+-----------------------------+ Intel(R) Atom(TM) CPU N570 @ 1.66GHz (cache size: 512 KB), 32-bit: +---------------------------------+----------+------------------------------+ | Benchmark | baseline | inline | +=================================+==========+==============================+ | round_(4.2) | 1.95 us | 1.29 us: 1.51x faster (-34%) | +---------------------------------+----------+------------------------------+ | sum_(()) | 1.15 us | 821 ns: 1.40x faster (-29%) | +---------------------------------+----------+------------------------------+ | sum_(a) | 1.32 us | 1.02 us: 1.30x faster (-23%) | +---------------------------------+----------+------------------------------+ | 'abc'.split() | 1.32 us | 1.11 us: 1.19x faster (-16%) | +---------------------------------+----------+------------------------------+ | b'abc'.split() | 1.22 us | 1.03 us: 1.18x faster (-15%) | +---------------------------------+----------+------------------------------+ | 'abc'.split('-') | 1.78 us | 1.15 us: 1.54x faster (-35%) | +---------------------------------+----------+------------------------------+ | 'abc'.encode() | 1.05 us | 883 ns: 1.19x faster (-16%) | +---------------------------------+----------+------------------------------+ | b'abc'.decode() | 1.34 us | 1.17 us: 1.15x faster (-13%) | +---------------------------------+----------+------------------------------+ | int_(4.2) | 1.23 us | 859 ns: 1.43x faster (-30%) | +---------------------------------+----------+------------------------------+ | int_('5') | 2.20 us | 1.41 us: 1.56x faster (-36%) | +---------------------------------+----------+------------------------------+ | 42 .to_bytes(2, 'little') | 1.45 us | 1.09 us: 1.33x faster (-25%) | +---------------------------------+----------+------------------------------+ | int_from_bytes(b'ab', 'little') | 1.07 us | 737 ns: 1.45x faster (-31%) | +---------------------------------+----------+------------------------------+ | struct_i32_unpack_from(b'abcd') | 1.31 us | 1.08 us: 1.21x faster (-18%) | +---------------------------------+----------+------------------------------+ | re_word_match('a') | 2.85 us | 2.06 us: 1.39x faster (-28%) | +---------------------------------+----------+------------------------------+ | datetime_now() | 6.20 us | 5.92 us: 1.05x faster (-4%) | +---------------------------------+----------+------------------------------+ | zlib_compress(b'abc') | 28.7 us | 26.9 us: 1.07x faster (-6%) | +---------------------------------+----------+------------------------------+ The speed up is significant on all computers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 08:03:38 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 27 Feb 2019 13:03:38 +0000 Subject: [issue36135] altinstall error Makefile:1140: recipe for target 'altinstall' failed In-Reply-To: <1551271971.31.0.932732600535.issue36135@roundup.psfhosted.org> Message-ID: <1551272618.98.0.0984184723208.issue36135@roundup.psfhosted.org> St?phane Wirtel added the comment: fix your compilation with the zlib headers zipimport.ZipImportError: can't decompress data; zlib not available not related to python itself. ---------- nosy: +matrixise resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 08:13:29 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 27 Feb 2019 13:13:29 +0000 Subject: [issue36127] Argument Clinic: inline parsing code for functions with keyword parameters In-Reply-To: <1551202236.03.0.123634318665.issue36127@roundup.psfhosted.org> Message-ID: <1551273209.27.0.244442408332.issue36127@roundup.psfhosted.org> STINNER Victor added the comment: About the stack memory usage, in the past, I used a subfunction tagged with _Py_NO_INLINE to work on temporary stack but then drop it: void function() { subfunction(); /* use temporary stack */ /* don't waste stack memory */ ... } I'm not sure if such pattern could be used here for things like " PyObject *argsbuf[12];". The problem is that argument parsing uses a lot of local variables allocated on the stack. In practice, it's more like: void function(args) { int x; parse_args(args, &x); /* use temporary stack */ /* don't waste stack memory */ ... } I expect a long list of "&arg" where arg is a local variable of function(). Well, that's basically the design of the current PyArg_ParseTuple() function family :-) PyArg_ParseTuple() does its stuff in private and uses more stack memory, but once PyArg_ParseTuple() returns, the memory on the stack is "released" just because we exited the function. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 08:15:26 2019 From: report at bugs.python.org (Apoorv Sachan) Date: Wed, 27 Feb 2019 13:15:26 +0000 Subject: [issue36134] test failure : test_re; recipe for target 'test' failed In-Reply-To: <1551271074.84.0.0671486163913.issue36134@roundup.psfhosted.org> Message-ID: <1551273326.5.0.769607487644.issue36134@roundup.psfhosted.org> Apoorv Sachan added the comment: ###the outputs for the commands: user at host $ python -m test.pythoninfo /usr/bin/python: No module named test.pythoninfo ------------------------------ user at host $ locale LANG=en_IN LANGUAGE=en_IN:en LC_CTYPE="en_IN" LC_NUMERIC="en_IN" LC_TIME="en_IN" LC_COLLATE="en_IN" LC_MONETARY="en_IN" LC_MESSAGES="en_IN" LC_PAPER="en_IN" LC_NAME="en_IN" LC_ADDRESS="en_IN" LC_TELEPHONE="en_IN" LC_MEASUREMENT="en_IN" LC_IDENTIFICATION="en_IN" LC_ALL= ------------------------------------ user at host $ ./python -m test -v test_re == CPython 3.7.2 (default, Feb 27 2019, 17:26:06) [GCC 6.3.0 20170516] == Linux-4.9.0-8-amd64-x86_64-with-debian-9.8 little-endian == cwd: /home/apoos-maximus/packages/Python-3.7.2/build/test_python_32039 == CPU count: 4 == encodings: locale=UTF-8, FS=utf-8 Run tests sequentially 0:00:00 load avg: 0.60 [1/1] test_re test_re_benchmarks (test.test_re.ExternalTests) re_tests benchmarks ... ok test_re_tests (test.test_re.ExternalTests) re_tests test suite ... ok test_overlap_table (test.test_re.ImplementationTest) ... ok test_bytes (test.test_re.PatternReprTests) ... ok test_inline_flags (test.test_re.PatternReprTests) ... ok test_locale (test.test_re.PatternReprTests) ... ok test_long_pattern (test.test_re.PatternReprTests) ... ok test_multiple_flags (test.test_re.PatternReprTests) ... ok test_quotes (test.test_re.PatternReprTests) ... ok test_single_flag (test.test_re.PatternReprTests) ... ok test_unicode_flag (test.test_re.PatternReprTests) ... ok test_unknown_flags (test.test_re.PatternReprTests) ... ok test_without_flags (test.test_re.PatternReprTests) ... ok test_anyall (test.test_re.ReTests) ... ok test_ascii_and_unicode_flag (test.test_re.ReTests) ... ok test_backref_group_name_in_exception (test.test_re.ReTests) ... ok test_basic_re_sub (test.test_re.ReTests) ... ok test_big_codesize (test.test_re.ReTests) ... ok test_bigcharset (test.test_re.ReTests) ... ok test_bug_113254 (test.test_re.ReTests) ... ok test_bug_114660 (test.test_re.ReTests) ... ok test_bug_117612 (test.test_re.ReTests) ... ok test_bug_1661 (test.test_re.ReTests) ... ok test_bug_16688 (test.test_re.ReTests) ... ok test_bug_20998 (test.test_re.ReTests) ... ok test_bug_2537 (test.test_re.ReTests) ... ok test_bug_29444 (test.test_re.ReTests) ... ok test_bug_3629 (test.test_re.ReTests) ... ok test_bug_418626 (test.test_re.ReTests) ... ok test_bug_448951 (test.test_re.ReTests) ... ok test_bug_449000 (test.test_re.ReTests) ... ok test_bug_449964 (test.test_re.ReTests) ... ok test_bug_527371 (test.test_re.ReTests) ... ok test_bug_581080 (test.test_re.ReTests) ... ok test_bug_612074 (test.test_re.ReTests) ... ok test_bug_6509 (test.test_re.ReTests) ... ok test_bug_6561 (test.test_re.ReTests) ... ok test_bug_725106 (test.test_re.ReTests) ... ok test_bug_725149 (test.test_re.ReTests) ... ok test_bug_764548 (test.test_re.ReTests) ... ok test_bug_817234 (test.test_re.ReTests) ... ok test_bug_926075 (test.test_re.ReTests) ... ok test_bug_931848 (test.test_re.ReTests) ... ok test_bytes_str_mixing (test.test_re.ReTests) ... ok test_case_helpers (test.test_re.ReTests) ... ok test_category (test.test_re.ReTests) ... ok test_character_set_errors (test.test_re.ReTests) ... ok test_compile (test.test_re.ReTests) ... ok test_constants (test.test_re.ReTests) ... ok test_copying (test.test_re.ReTests) ... ok test_dealloc (test.test_re.ReTests) ... ok test_debug_flag (test.test_re.ReTests) ... ok test_dollar_matches_twice (test.test_re.ReTests) $ matches the end of string, and just before the terminating ... ok test_empty_array (test.test_re.ReTests) ... ok test_enum (test.test_re.ReTests) ... ok test_error (test.test_re.ReTests) ... ok test_expand (test.test_re.ReTests) ... ok test_finditer (test.test_re.ReTests) ... ok test_flags (test.test_re.ReTests) ... ok test_getattr (test.test_re.ReTests) ... ok test_group (test.test_re.ReTests) ... ok test_group_name_in_exception (test.test_re.ReTests) ... ok test_groupdict (test.test_re.ReTests) ... ok test_ignore_case (test.test_re.ReTests) ... ok test_ignore_case_range (test.test_re.ReTests) ... ok test_ignore_case_set (test.test_re.ReTests) ... ok test_inline_flags (test.test_re.ReTests) ... ok test_issue17998 (test.test_re.ReTests) ... ok test_keep_buffer (test.test_re.ReTests) ... ok test_keyword_parameters (test.test_re.ReTests) ... ok test_large_search (test.test_re.ReTests) ... ok test_large_subn (test.test_re.ReTests) ... ok test_locale_caching (test.test_re.ReTests) ... skipped 'test needs en_US.iso88591 locale' test_locale_compiled (test.test_re.ReTests) ... skipped 'test needs en_US.iso88591 locale' test_locale_flag (test.test_re.ReTests) ... FAIL test_lookahead (test.test_re.ReTests) ... ok test_lookbehind (test.test_re.ReTests) ... ok test_match_getitem (test.test_re.ReTests) ... ok test_match_repr (test.test_re.ReTests) ... ok test_misc_errors (test.test_re.ReTests) ... ok test_multiple_repeat (test.test_re.ReTests) ... ok test_not_literal (test.test_re.ReTests) ... ok test_nothing_to_repeat (test.test_re.ReTests) ... ok test_other_escapes (test.test_re.ReTests) ... ok test_pattern_compare (test.test_re.ReTests) ... ok test_pattern_compare_bytes (test.test_re.ReTests) ... ok test_pickling (test.test_re.ReTests) ... ok test_possible_set_operations (test.test_re.ReTests) ... ok test_qualified_re_split (test.test_re.ReTests) ... ok test_qualified_re_sub (test.test_re.ReTests) ... ok test_re_escape (test.test_re.ReTests) ... ok test_re_escape_bytes (test.test_re.ReTests) ... ok test_re_escape_non_ascii (test.test_re.ReTests) ... ok test_re_escape_non_ascii_bytes (test.test_re.ReTests) ... ok test_re_findall (test.test_re.ReTests) ... ok test_re_fullmatch (test.test_re.ReTests) ... ok test_re_groupref (test.test_re.ReTests) ... ok test_re_groupref_exists (test.test_re.ReTests) ... ok test_re_groupref_overflow (test.test_re.ReTests) ... ok test_re_match (test.test_re.ReTests) ... ok test_re_split (test.test_re.ReTests) ... ok test_re_subn (test.test_re.ReTests) ... ok test_repeat_minmax (test.test_re.ReTests) ... ok test_repeat_minmax_overflow (test.test_re.ReTests) ... ok test_repeat_minmax_overflow_maxrepeat (test.test_re.ReTests) ... ok test_scanner (test.test_re.ReTests) ... ok test_scoped_flags (test.test_re.ReTests) ... ok test_search_coverage (test.test_re.ReTests) ... ok test_search_dot_unicode (test.test_re.ReTests) ... ok test_search_star_plus (test.test_re.ReTests) ... ok test_special_escapes (test.test_re.ReTests) ... ok test_sre_byte_class_literals (test.test_re.ReTests) ... ok test_sre_byte_literals (test.test_re.ReTests) ... ok test_sre_character_class_literals (test.test_re.ReTests) ... ok test_sre_character_literals (test.test_re.ReTests) ... ok test_stack_overflow (test.test_re.ReTests) ... ok test_string_boundaries (test.test_re.ReTests) ... ok test_sub_template_numeric_escape (test.test_re.ReTests) ... ok test_symbolic_groups (test.test_re.ReTests) ... ok test_symbolic_refs (test.test_re.ReTests) ... ok test_unlimited_zero_width_repeat (test.test_re.ReTests) ... ok test_weakref (test.test_re.ReTests) ... ok test_zerowidth (test.test_re.ReTests) ... ok ====================================================================== FAIL: test_locale_flag (test.test_re.ReTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/apoos-maximus/packages/Python-3.7.2/Lib/test/test_re.py", line 1540, in test_locale_flag self.assertTrue(pat.match(bletter)) AssertionError: None is not true ---------------------------------------------------------------------- Ran 123 tests in 0.746s FAILED (failures=1, skipped=2) test test_re failed test_re failed == Tests result: FAILURE == 1 test failed: test_re Total duration: 782 ms Tests result: FAILURE ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 08:20:55 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 Feb 2019 13:20:55 +0000 Subject: [issue36127] Argument Clinic: inline parsing code for functions with keyword parameters In-Reply-To: <1551202236.03.0.123634318665.issue36127@roundup.psfhosted.org> Message-ID: <1551273655.34.0.430736668824.issue36127@roundup.psfhosted.org> Serhiy Storchaka added the comment: In addition, this change can allow us to get rid of large and complex functions _PyArg_ParseTupleAndKeywordsFast() and _PyArg_ParseStackAndKeywords(). The former is no longer used in CPython, and the latter is still used in few places to support some deprecated formatting codes for which I intentionally not implemented inlining. After getting rid of uses of such codes (the patch in progress) we could remove both these functions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 08:21:19 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Wed, 27 Feb 2019 13:21:19 +0000 Subject: [issue36096] IDLE: Refactor class variables to instance variables in colorizer In-Reply-To: <1550962398.99.0.0484672984397.issue36096@roundup.psfhosted.org> Message-ID: <1551273679.93.0.153038668315.issue36096@roundup.psfhosted.org> Cheryl Sabella added the comment: New changeset ed1deb0719f0ac1b08a374e30ad26a701d4d51a2 by Cheryl Sabella in branch 'master': bpo-36096: IDLE: Refactor class variables in colorizer (GH-12002) https://github.com/python/cpython/commit/ed1deb0719f0ac1b08a374e30ad26a701d4d51a2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 08:21:42 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 27 Feb 2019 13:21:42 +0000 Subject: [issue36096] IDLE: Refactor class variables to instance variables in colorizer In-Reply-To: <1550962398.99.0.0484672984397.issue36096@roundup.psfhosted.org> Message-ID: <1551273702.11.0.907390150131.issue36096@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +12089 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 08:38:33 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Wed, 27 Feb 2019 13:38:33 +0000 Subject: [issue36134] test failure : test_re; recipe for target 'test' failed In-Reply-To: <1551271074.84.0.0671486163913.issue36134@roundup.psfhosted.org> Message-ID: <1551274713.39.0.13511119115.issue36134@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Thanks for the details. This seems to be the same as issue29571 where the issue was reported on Ubuntu for en_IN but not happening in Gentoo. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 08:51:30 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 27 Feb 2019 13:51:30 +0000 Subject: [issue13850] Summary tables for argparse add_argument options In-Reply-To: <1327384498.23.0.981832544617.issue13850@psf.upfronthosting.co.za> Message-ID: <1551275490.44.0.357205639651.issue13850@roundup.psfhosted.org> Change by St?phane Wirtel : ---------- pull_requests: +12090 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 08:58:50 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Wed, 27 Feb 2019 13:58:50 +0000 Subject: [issue36135] altinstall error Makefile:1140: recipe for target 'altinstall' failed In-Reply-To: <1551271971.31.0.932732600535.issue36135@roundup.psfhosted.org> Message-ID: <1551275930.78.0.563191276056.issue36135@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: This might help : https://devguide.python.org/setup/#install-dependencies ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 09:21:26 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 27 Feb 2019 14:21:26 +0000 Subject: [issue36136] Windows: python._pth sets isolated mode late during Python initialization Message-ID: <1551277286.04.0.945215476701.issue36136@roundup.psfhosted.org> New submission from STINNER Victor : The read_pth_file() of PC/getpathp.c sets Py_IsolatedFlag and Py_NoSiteFlag to 1 in Python 3.6. calculate_path() checked if a file with a "._pth" extension exists in "dllpath" or "progpath". I refactored deeply the Python initialization in Python 3.7 and I'm not sure I introduced a regression or not. In Python 3.7, _PyCoreConfig_Read() calls config_init_path_config() which indirectly calls read_pth_file(). pymain_read_conf_impl() detects if Py_IsolatedFlag and Py_NoSiteFlag have been modified and store the new value in cmdline->isolated and cmdline->no_site_import. Later, cmdline_set_global_config() sets Py_IsolatedFlag and Py_NoSiteFlag; and _PyCoreConfig_SetGlobalConfig() sets Py_IgnoreEnvironmentFlag. The problem is the relationship between isolated/cmdline.Py_IsolatedFlag, no_site_import/cmdline.Py_NoSiteFlag and Py_IgnoreEnvironmentFlag/config.ignore_environment. The isolated mode must set Py_NoSiteFlag to 1 and Py_IgnoreEnvironmentFlag to 1. For example, pymain_read_conf_impl() uses: /* Set Py_IgnoreEnvironmentFlag for Py_GETENV() */ Py_IgnoreEnvironmentFlag = config->ignore_environment || cmdline->isolated; But it's done before calling _PyCoreConfig_Read(). Moreover, _PyCoreConfig_Read() reads PYTHONxxx environment variables before calling indirectly read_pth_file(), and so PYTHONxxx env vars are read whereas they are supposed to be ignored. Calling read_pth_file() earlier is challenging since it depends on configuration parameters which are before calling it. At the end, I'm not sure if it's a real issue. I'm not sure if there is a regression in Python 3.7. -- But the code in Python 3.8 changed a lot again: _PyCoreConfig_Read() is now responsible to read all environment variables. In Python 3.8, read_pth_file() uses a _PyPathConfig structure to set isolated and site_import parameters. These parameters are then copied to _PyCoreConfig in _PyCoreConfig_CalculatePathConfig(). Moreover, _PyCoreConfig_Read() is more explicit with the relationship between isolated, use_environment and user_site_directory. The function *starts* with: if (config->isolated > 0) { config->use_environment = 0; config->user_site_directory = 0; } Problems (inconsistencies) arise if isolated is set from 0 to 1 after this code. ---------- components: Interpreter Core messages: 336760 nosy: vstinner priority: normal severity: normal status: open title: Windows: python._pth sets isolated mode late during Python initialization versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 09:34:57 2019 From: report at bugs.python.org (Mika Fischer) Date: Wed, 27 Feb 2019 14:34:57 +0000 Subject: [issue36137] SSL verification fails for some sites inside windows docker container Message-ID: <1551278097.55.0.344471071893.issue36137@roundup.psfhosted.org> New submission from Mika Fischer : Inside a windows docker container, SSL verification fails for some but not all hosts. See this issue over in the docker repo: https://github.com/docker-library/python/issues/359 Maybe you guys could shed some light on what could be the possible. To reproduce, install Docker for Windows and then: This works: ``` docker run -ti python:3.7-windowsservercore-1809 python -c "import urllib.request as r; r.urlopen('https://bootstrap.pypa.io').close()" ``` This doesn't ``` docker run -ti python:3.7-windowsservercore-1809 python -c "import urllib.request as r; r.urlopen('https://google.com').close()" Traceback (most recent call last): File "C:\Python\lib\urllib\request.py", line 1317, in do_open encode_chunked=req.has_header('Transfer-encoding')) File "C:\Python\lib\http\client.py", line 1229, in request self._send_request(method, url, body, headers, encode_chunked) File "C:\Python\lib\http\client.py", line 1275, in _send_request self.endheaders(body, encode_chunked=encode_chunked) File "C:\Python\lib\http\client.py", line 1224, in endheaders self._send_output(message_body, encode_chunked=encode_chunked) File "C:\Python\lib\http\client.py", line 1016, in _send_output self.send(msg) File "C:\Python\lib\http\client.py", line 956, in send self.connect() File "C:\Python\lib\http\client.py", line 1392, in connect server_hostname=server_hostname) File "C:\Python\lib\ssl.py", line 412, in wrap_socket session=session File "C:\Python\lib\ssl.py", line 853, in _create self.do_handshake() File "C:\Python\lib\ssl.py", line 1117, in do_handshake self._sslobj.do_handshake() ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1056) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 1, in File "C:\Python\lib\urllib\request.py", line 222, in urlopen return opener.open(url, data, timeout) File "C:\Python\lib\urllib\request.py", line 525, in open response = self._open(req, data) File "C:\Python\lib\urllib\request.py", line 543, in _open '_open', req) File "C:\Python\lib\urllib\request.py", line 503, in _call_chain result = func(*args) File "C:\Python\lib\urllib\request.py", line 1360, in https_open context=self._context, check_hostname=self._check_hostname) File "C:\Python\lib\urllib\request.py", line 1319, in do_open raise URLError(err) urllib.error.URLError: ``` ---------- assignee: christian.heimes components: SSL messages: 336761 nosy: Mika Fischer, christian.heimes priority: normal severity: normal status: open title: SSL verification fails for some sites inside windows docker container type: behavior versions: Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 09:37:42 2019 From: report at bugs.python.org (Paul Ganssle) Date: Wed, 27 Feb 2019 14:37:42 +0000 Subject: [issue35417] Double parenthesis in print function running 2to3 in already correct call In-Reply-To: <1544004619.56.0.788709270274.issue35417@psf.upfronthosting.co.za> Message-ID: <1551278262.23.0.239514684038.issue35417@roundup.psfhosted.org> Paul Ganssle added the comment: > 2to3 is designed as a tool to convert a Python 2 code base to Python 3 at once. I understand that once the code base is converted, you may want to revert some unwanted "useless" changes. While this problem is likely to show up because someone has run 2to3 on a codebase more than once, I have *always* used parentheses around my print statements, even in pure Python 2, so it's not necessarily the case that this will cause problems. I think this is a legitimate bug but also harmless since the code it generates is equivalent to the version with only one set of parentheses. I don't see a great deal of harm in marking this as low priority and leaving the bug open for someone to fix later, other than the fact that if someone comes along and fixes it, they may be discouraged to find that there are not really core developers interested in reviewing and merging the PR. I will note that with the end of Python 2, 2to3 may become *more* relevant as fewer and fewer people are looking to translate code from 2->2/3 and more people will be looking to translate 2->3 directly. ---------- nosy: +p-ganssle _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 09:47:50 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 27 Feb 2019 14:47:50 +0000 Subject: [issue36137] SSL verification fails for some sites inside windows docker container In-Reply-To: <1551278097.55.0.344471071893.issue36137@roundup.psfhosted.org> Message-ID: <1551278870.9.0.601834724983.issue36137@roundup.psfhosted.org> St?phane Wirtel added the comment: I can't reproduce it with python 3.8a2 and I don't have a laptop with Windows. ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 09:51:49 2019 From: report at bugs.python.org (Mika Fischer) Date: Wed, 27 Feb 2019 14:51:49 +0000 Subject: [issue36137] SSL verification fails for some sites inside windows docker container In-Reply-To: <1551278097.55.0.344471071893.issue36137@roundup.psfhosted.org> Message-ID: <1551279109.06.0.963506869391.issue36137@roundup.psfhosted.org> Mika Fischer added the comment: Sorry if I wasn't completely clear. This issue occurs only on Windows and only when running python inside a windows docker container. The question is what is python using on Windows to verify SSL certificates and what might be different inside the container that might let that process fail for some hosts and not for others... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 09:54:37 2019 From: report at bugs.python.org (Paul Ganssle) Date: Wed, 27 Feb 2019 14:54:37 +0000 Subject: [issue36138] Improve documentation about converting datetime.timedelta to scalars Message-ID: <1551279277.78.0.420201199405.issue36138@roundup.psfhosted.org> New submission from Paul Ganssle : In a recent python-dev thread, there was some confusion about how to get something like `timedelta.total_microseconds()`. There is already an existing, supported idiom for this, which is that `timedelta` implements division: td = timedelta(hours=1) num_microseconds = td / timedelta(microseconds=1) In this e-mail ( https://mail.python.org/pipermail/python-dev/2019-February/156351.html ), Nick Coghlan proposed that we update the documentation and there were no objections, quoting: * In the "Supported Operations" section of https://docs.python.org/3/library/datetime.html#timedelta-objects, change "Division (3) of t2 by t3." to "Division (3) of overall duration t2 by interval unit t3." * In the total_seconds() documentation, add a sentence "For interval units other than seconds, use the division form directly (e.g. `td / timedelta(microseconds=1)`)" I am starting this issue to track that change. ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 336765 nosy: belopolsky, docs at python, ncoghlan, p-ganssle priority: normal severity: normal status: open title: Improve documentation about converting datetime.timedelta to scalars versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 09:58:53 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 27 Feb 2019 14:58:53 +0000 Subject: [issue36137] SSL verification fails for some sites inside windows docker container In-Reply-To: <1551278097.55.0.344471071893.issue36137@roundup.psfhosted.org> Message-ID: <1551279533.51.0.55093333523.issue36137@roundup.psfhosted.org> St?phane Wirtel added the comment: sure, I have just confirmed that this error does not occur with the last python 3.8a2 and that I don't have a Windows system for an eventual debugging session. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 10:00:15 2019 From: report at bugs.python.org (Tianon) Date: Wed, 27 Feb 2019 15:00:15 +0000 Subject: [issue36137] SSL verification fails for some sites inside windows docker container In-Reply-To: <1551278097.55.0.344471071893.issue36137@roundup.psfhosted.org> Message-ID: <1551279615.75.0.575750507237.issue36137@roundup.psfhosted.org> Change by Tianon : ---------- nosy: +tianon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 10:05:58 2019 From: report at bugs.python.org (Christian Heimes) Date: Wed, 27 Feb 2019 15:05:58 +0000 Subject: [issue36137] SSL verification fails for some sites inside windows docker container In-Reply-To: <1551278097.55.0.344471071893.issue36137@roundup.psfhosted.org> Message-ID: <1551279958.08.0.0543855943118.issue36137@roundup.psfhosted.org> Christian Heimes added the comment: This is probably a duplicate of #36137. Windows doesn't have CA certs pre-installed. They are downloaded from the update server on demand. Python doesn't trigger the update but only uses certs that are already present. It's a design flaw in my implementation. I wasn't aware of Windows' behavior when I hooked up the Windows cert store to the SSL module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 10:55:39 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 27 Feb 2019 15:55:39 +0000 Subject: [issue13850] Summary tables for argparse add_argument options In-Reply-To: <1327384498.23.0.981832544617.issue13850@psf.upfronthosting.co.za> Message-ID: <1551282939.2.0.358050829349.issue13850@roundup.psfhosted.org> St?phane Wirtel added the comment: just for 2.7, 3.7 & 3.8 because they are in bugfix mode. ---------- versions: +Python 3.7, Python 3.8 -Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 11:06:14 2019 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Wed, 27 Feb 2019 16:06:14 +0000 Subject: [issue36138] Improve documentation about converting datetime.timedelta to scalars In-Reply-To: <1551279277.78.0.420201199405.issue36138@roundup.psfhosted.org> Message-ID: <1551283574.2.0.949010156232.issue36138@roundup.psfhosted.org> Change by Fred L. Drake, Jr. : ---------- nosy: +fdrake _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 11:07:20 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Wed, 27 Feb 2019 16:07:20 +0000 Subject: [issue36121] csv: Non global alternative to csv.field_size_limit In-Reply-To: <1551181447.91.0.36050465631.issue36121@roundup.psfhosted.org> Message-ID: <1551283640.73.0.0923689022601.issue36121@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- keywords: +patch pull_requests: +12091 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 11:10:41 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Wed, 27 Feb 2019 16:10:41 +0000 Subject: [issue36121] csv: Non global alternative to csv.field_size_limit In-Reply-To: <1551181447.91.0.36050465631.issue36121@roundup.psfhosted.org> Message-ID: <1551283841.32.0.830561153277.issue36121@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- components: +Library (Lib) -Extension Modules _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 11:40:10 2019 From: report at bugs.python.org (Paul Ganssle) Date: Wed, 27 Feb 2019 16:40:10 +0000 Subject: [issue22194] access to cdecimal / libmpdec API In-Reply-To: <1408022998.0.0.480794879626.issue22194@psf.upfronthosting.co.za> Message-ID: <1551285610.11.0.893387317644.issue22194@roundup.psfhosted.org> Change by Paul Ganssle : ---------- nosy: +p-ganssle _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 11:45:57 2019 From: report at bugs.python.org (Paul Ganssle) Date: Wed, 27 Feb 2019 16:45:57 +0000 Subject: [issue15237] Add capsule API to _decimal In-Reply-To: <1341136971.24.0.846129884923.issue15237@psf.upfronthosting.co.za> Message-ID: <1551285957.71.0.134303894079.issue15237@roundup.psfhosted.org> Change by Paul Ganssle : ---------- nosy: +p-ganssle _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 11:53:12 2019 From: report at bugs.python.org (Paul Ganssle) Date: Wed, 27 Feb 2019 16:53:12 +0000 Subject: [issue23607] Inconsistency in datetime.utcfromtimestamp(Decimal) In-Reply-To: <1425810901.79.0.570490913636.issue23607@psf.upfronthosting.co.za> Message-ID: <1551286392.99.0.235963007367.issue23607@roundup.psfhosted.org> Paul Ganssle added the comment: I'm not sure if either of these patches got merged, but at some point this was fixed: Python 3.7.2 (default, Feb 9 2019, 13:18:43) [GCC 8.2.1 20181127] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from datetime import datetime >>> from decimal import Decimal >>> datetime.utcfromtimestamp(Decimal(123456.0)) datetime.datetime(1970, 1, 2, 10, 17, 36) I recommend that someone add some regression tests to this, then we can close the issue. I'm also going to mark this as "easy" since adding tests for this particular example should be pretty simple. ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 12:01:35 2019 From: report at bugs.python.org (daniel hahler) Date: Wed, 27 Feb 2019 17:01:35 +0000 Subject: [issue31078] pdb's debug command (Pdb.do_debug) doesn't use rawinput even if the parent pdb uses rawinput In-Reply-To: <1501362127.96.0.48372316228.issue31078@psf.upfronthosting.co.za> Message-ID: <1551286895.23.0.706450104319.issue31078@roundup.psfhosted.org> daniel hahler added the comment: I can confirm that this fixes cursor keys not working properly after "debug foo()" (recursive debugging) with pdb. ---------- nosy: +blueyed versions: +Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 12:10:20 2019 From: report at bugs.python.org (Ned Deily) Date: Wed, 27 Feb 2019 17:10:20 +0000 Subject: [issue28441] Change sys.executable to include executable suffix In-Reply-To: <1476452085.73.0.180033377767.issue28441@psf.upfronthosting.co.za> Message-ID: <1551287420.03.0.12403950871.issue28441@roundup.psfhosted.org> Change by Ned Deily : ---------- versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 12:10:29 2019 From: report at bugs.python.org (Paul Ganssle) Date: Wed, 27 Feb 2019 17:10:29 +0000 Subject: [issue23607] Inconsistency in datetime.utcfromtimestamp(Decimal) In-Reply-To: <1425810901.79.0.570490913636.issue23607@psf.upfronthosting.co.za> Message-ID: <1551287429.2.0.116112410519.issue23607@roundup.psfhosted.org> Paul Ganssle added the comment: Oh actually that's my mistake. I can't reproduce the failure in the constructor in the Python version of the module, and also it seems to be fixed in the pure Python version as of at least 3.6: Python 3.6.7 (default, Oct 25 2018, 16:11:17) [GCC 8.2.1 20180831] on linux >>> import sys >>> sys.modules['_datetime'] = None >>> from decimal import Decimal as D >>> from datetime import datetime >>> datetime.utcfromtimestamp(D(123456.12345)) datetime.datetime(1970, 1, 2, 10, 17, 36, 123450) But the truncation behavior is still present in the C version as of Python 3.8.0a1+: Python 3.8.0a1+ (heads/master:3766f18, Feb 11 2019, 12:52:31) [GCC 8.2.1 20181127] on linux >>> from datetime import datetime >>> from decimal import Decimal as D >>> datetime.utcfromtimestamp(D(123456.12345)) datetime.datetime(1970, 1, 2, 10, 17, 36) I still think we need a test for the constructor behavior, but I'm going to remove "easy", since we still need to fix truncation in the C version. ---------- keywords: -easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 12:11:22 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 Feb 2019 17:11:22 +0000 Subject: [issue23607] Inconsistency in datetime.utcfromtimestamp(Decimal) In-Reply-To: <1425810901.79.0.570490913636.issue23607@psf.upfronthosting.co.za> Message-ID: <1551287482.55.0.00821871190707.issue23607@roundup.psfhosted.org> Serhiy Storchaka added the comment: No, the bug is not fixed, and this is not easy issue. You should use non-integer Decimals to reproduce it. In 3.8 this emits a deprecation warning: >>> import datetime >>> from decimal import Decimal as D >>> datetime.datetime.utcfromtimestamp(D(1425808327.307651)) :1: DeprecationWarning: an integer is required (got type decimal.Decimal). Implicit conversion to integers using __int__ is deprecated, and may be removed in a future version of Python. datetime.datetime(2015, 3, 8, 9, 52, 7) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 12:14:23 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Wed, 27 Feb 2019 17:14:23 +0000 Subject: [issue23607] Inconsistency in datetime.utcfromtimestamp(Decimal) In-Reply-To: <1425810901.79.0.570490913636.issue23607@psf.upfronthosting.co.za> Message-ID: <1551287663.1.0.495659380931.issue23607@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 12:23:35 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Wed, 27 Feb 2019 17:23:35 +0000 Subject: [issue36131] test.test_urllib2net.TimeoutTest ftp related tests fail due to ftp://www.pythontest.net/ being unavailable In-Reply-To: <1551243962.9.0.321127985724.issue36131@roundup.psfhosted.org> Message-ID: <1551288215.47.0.445958360209.issue36131@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: Almost all buildbots have failed due to this issue. It seems that is fixed now: ? ./python.exe -m test -v test_urllib2net -u all == CPython 3.8.0a2+ (heads/master:d5a551c269, Feb 27 2019, 09:17:08) [Clang 10.0.0 (clang-1000.10.44.4)] == macOS-10.14.3-x86_64-i386-64bit little-endian == cwd: /Users/pgalindo3/github/cpython/build/test_python_15573 == CPU count: 8 == encodings: locale=UTF-8, FS=utf-8 Run tests sequentially 0:00:00 load avg: 2.02 [1/1] test_urllib2net test_close (test.test_urllib2net.CloseSocketTest) ... ok test_custom_headers (test.test_urllib2net.OtherNetworkTests) ... ok test_file (test.test_urllib2net.OtherNetworkTests) ... ok test_ftp (test.test_urllib2net.OtherNetworkTests) ... ok test_redirect_url_withfrag (test.test_urllib2net.OtherNetworkTests) ... ok test_sites_no_connection_close (test.test_urllib2net.OtherNetworkTests) ... skipped 'XXX: http://www.imdb.com is gone' test_urlwithfrag (test.test_urllib2net.OtherNetworkTests) ... ok test_ftp_basic (test.test_urllib2net.TimeoutTest) ... ok test_ftp_default_timeout (test.test_urllib2net.TimeoutTest) ... ok test_ftp_no_timeout (test.test_urllib2net.TimeoutTest) ... ok test_ftp_timeout (test.test_urllib2net.TimeoutTest) ... ok test_http_basic (test.test_urllib2net.TimeoutTest) ... ok test_http_default_timeout (test.test_urllib2net.TimeoutTest) ... ok test_http_no_timeout (test.test_urllib2net.TimeoutTest) ... ok test_http_timeout (test.test_urllib2net.TimeoutTest) ... ok ---------------------------------------------------------------------- Ran 15 tests in 9.531s OK (skipped=1) == Tests result: SUCCESS == 1 test OK. Total duration: 10 sec 17 ms Tests result: SUCCESS I am going to re-trigger a build in all affected buildbots. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 12:30:02 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Wed, 27 Feb 2019 17:30:02 +0000 Subject: [issue36116] test_multiprocessing_spawn fails on AMD64 Windows8 3.x In-Reply-To: <1551165223.62.0.963183120667.issue36116@roundup.psfhosted.org> Message-ID: <1551288602.77.0.530507206131.issue36116@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: Adding ?ukasz, as I think this is a release blocker (the Windows 8 and 7 multiprocessing module may be causing segfaults). ---------- nosy: +lukasz.langa priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 13:00:41 2019 From: report at bugs.python.org (Davide Rizzo) Date: Wed, 27 Feb 2019 18:00:41 +0000 Subject: [issue36139] release GIL on mmap dealloc Message-ID: <1551290441.84.0.237778309898.issue36139@roundup.psfhosted.org> New submission from Davide Rizzo : munmap() can take a long time. I think mmap_object_dealloc can trivially release the GIL around this operation. Something similar was already mentioned in https://bugs.python.org/issue1572968 but a general patch was never provided. The dealloc case alone is significant enough to deserve fixing. ---------- components: Library (Lib) messages: 336775 nosy: davide.rizzo priority: normal severity: normal status: open title: release GIL on mmap dealloc versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 13:07:17 2019 From: report at bugs.python.org (Roundup Robot) Date: Wed, 27 Feb 2019 18:07:17 +0000 Subject: [issue36139] release GIL on mmap dealloc In-Reply-To: <1551290441.84.0.237778309898.issue36139@roundup.psfhosted.org> Message-ID: <1551290837.73.0.665399889723.issue36139@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch pull_requests: +12092 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 13:38:06 2019 From: report at bugs.python.org (Zackery Spytz) Date: Wed, 27 Feb 2019 18:38:06 +0000 Subject: [issue36140] An incorrect check in _msi.c's msidb_getsummaryinformation() Message-ID: <1551292686.09.0.0441775599344.issue36140@roundup.psfhosted.org> New submission from Zackery Spytz : msidb_getsummaryinformation() checks the wrong variable after calling PyObject_NEW(). ---------- components: Windows messages: 336776 nosy: ZackerySpytz, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: An incorrect check in _msi.c's msidb_getsummaryinformation() type: behavior versions: Python 2.7, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 13:40:25 2019 From: report at bugs.python.org (Zackery Spytz) Date: Wed, 27 Feb 2019 18:40:25 +0000 Subject: [issue36140] An incorrect check in _msi.c's msidb_getsummaryinformation() In-Reply-To: <1551292686.09.0.0441775599344.issue36140@roundup.psfhosted.org> Message-ID: <1551292825.85.0.517745157725.issue36140@roundup.psfhosted.org> Change by Zackery Spytz : ---------- keywords: +patch pull_requests: +12093 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 13:56:12 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 27 Feb 2019 18:56:12 +0000 Subject: [issue36096] IDLE: Refactor class variables to instance variables in colorizer In-Reply-To: <1550962398.99.0.0484672984397.issue36096@roundup.psfhosted.org> Message-ID: <1551293772.71.0.0130002453946.issue36096@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +12094 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 14:14:10 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 27 Feb 2019 19:14:10 +0000 Subject: [issue36096] IDLE: Refactor class variables to instance variables in colorizer In-Reply-To: <1550962398.99.0.0484672984397.issue36096@roundup.psfhosted.org> Message-ID: <1551294850.19.0.0616573276536.issue36096@roundup.psfhosted.org> Terry J. Reedy added the comment: New changeset 488aabafe2f1c5db05a6c1a7a8b49d7b89b1f36b by Terry Jan Reedy (Miss Islington (bot)) in branch '3.7': bpo-36096: IDLE: Refactor class variables in colorizer (GH-12002) (GH-12075) https://github.com/python/cpython/commit/488aabafe2f1c5db05a6c1a7a8b49d7b89b1f36b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 14:24:28 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 27 Feb 2019 19:24:28 +0000 Subject: [issue36096] IDLE: Refactor class variables to instance variables in colorizer In-Reply-To: <1550962398.99.0.0484672984397.issue36096@roundup.psfhosted.org> Message-ID: <1551295468.04.0.23076436249.issue36096@roundup.psfhosted.org> Change by Terry J. Reedy : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 14:42:44 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 27 Feb 2019 19:42:44 +0000 Subject: [issue36116] test_multiprocessing_spawn fails on AMD64 Windows8 3.x In-Reply-To: <1551165223.62.0.963183120667.issue36116@roundup.psfhosted.org> Message-ID: <1551296564.82.0.733646549437.issue36116@roundup.psfhosted.org> Steve Dower added the comment: It's also possible that the child process is causing the segfault because of misconfiguration (e.g. broken environment variables). And depending on the OS, abort() calls (via Py_FatalError) sometimes appear to be segfaults, so it could be any number of issues. (Aside - I'd love to replace the abort() calls with specific exit codes for configuration errors - they really mess up the crash data we see on Windows.) I'll try some tests locally to see if this is reproducible, but if anyone can extract the original stdout/stderr from the buildbot, that would be helpful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 14:47:08 2019 From: report at bugs.python.org (=?utf-8?q?Manuel_Cer=C3=B3n?=) Date: Wed, 27 Feb 2019 19:47:08 +0000 Subject: [issue35360] Update SQLite to 3.26 in Windows and macOS installer builds In-Reply-To: <1543580070.45.0.788709270274.issue35360@psf.upfronthosting.co.za> Message-ID: <1551296828.18.0.726924469499.issue35360@roundup.psfhosted.org> Change by Manuel Cer?n : ---------- nosy: +ceronman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 14:51:13 2019 From: report at bugs.python.org (muhzi) Date: Wed, 27 Feb 2019 19:51:13 +0000 Subject: [issue36141] configure: error: could not find pthreads on your system during cross compilation Message-ID: <1551297073.48.0.367193754314.issue36141@roundup.psfhosted.org> New submission from muhzi : I am facing a problem while trying to compile Python for android armv7a using the latest NDK version (clang). The configure script fails to find pthread library, which should be bundled in libc. Here is the full configure output: Building for armv7a-linux-androideabi configure: loading site script ./config.site checking build system type... x86_64-pc-linux-gnu checking host system type... armv7a-unknown-linux-androideabi checking for python3.7... python3.7 checking for python interpreter for cross build... python3.7 checking for --enable-universalsdk... no checking for --with-universal-archs... no checking MACHDEP... checking for --without-gcc... no checking for --with-icc... no checking for armv7a-linux-androideabi-gcc... armv7a-linux-androideabi16-clang checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... yes checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether armv7a-linux-androideabi16-clang accepts -g... yes checking for armv7a-linux-androideabi16-clang option to accept ISO C89... none needed checking how to run the C preprocessor... armv7a-linux-androideabi16-clang -E checking for grep that handles long lines and -e... /bin/grep checking for a sed that does not truncate output... /bin/sed checking for --with-cxx-main=... no checking for the platform triplet based on compiler characteristics... none checking for -Wl,--no-as-needed... yes checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking for the Android API level... 16 checking for the Android arm ABI... 7 checking for --with-suffix... checking for case-insensitive build directory... no checking LIBRARY... libpython$(VERSION)$(ABIFLAGS).a checking LINKCC... $(PURIFY) $(MAINCC) checking for GNU ld... yes checking for --enable-shared... yes checking for --enable-profiling... no checking LDLIBRARY... libpython$(LDVERSION).so checking for armv7a-linux-androideabi-ar... arm-linux-androideabi-ar checking for armv7a-linux-androideabi-readelf... arm-linux-androideabi-readelf checking for a BSD-compatible install... /usr/bin/install -c checking for a thread-safe mkdir -p... /bin/mkdir -p checking for --with-pydebug... no checking for --with-assertions... no checking for --enable-optimizations... no checking for --with-lto... no checking for -llvm-profdata... no checking for -Wextra... yes checking whether armv7a-linux-androideabi16-clang accepts and needs -fno-strict-aliasing... no checking if we can turn off armv7a-linux-androideabi16-clang unused result warning... yes checking if we can turn off armv7a-linux-androideabi16-clang unused parameter warning... yes checking if we can turn off armv7a-linux-androideabi16-clang missing field initializers warning... yes checking if we can turn off armv7a-linux-androideabi16-clang invalid function cast warning... no checking if we can turn on armv7a-linux-androideabi16-clang mixed sign comparison warning... yes checking if we can turn on armv7a-linux-androideabi16-clang unreachable code warning... yes checking if we can turn on armv7a-linux-androideabi16-clang strict-prototypes warning... yes checking if we can make implicit function declaration an error in armv7a-linux-androideabi16-clang... yes checking whether pthreads are available without options... no checking whether armv7a-linux-androideabi16-clang accepts -Kpthread... no checking whether armv7a-linux-androideabi16-clang accepts -Kthread... no checking whether armv7a-linux-androideabi16-clang accepts -pthread... no checking whether armv7a-linux-androideabi16-clang++ also accepts flags for thread support... no checking for ANSI C header files... (cached) yes checking asm/types.h usability... yes checking asm/types.h presence... yes checking for asm/types.h... yes checking crypt.h usability... no checking crypt.h presence... no checking for crypt.h... no checking conio.h usability... no checking conio.h presence... no checking for conio.h... no checking direct.h usability... no checking direct.h presence... no checking for direct.h... no checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking errno.h usability... yes checking errno.h presence... yes checking for errno.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking ieeefp.h usability... no checking ieeefp.h presence... no checking for ieeefp.h... no checking io.h usability... no checking io.h presence... no checking for io.h... no checking langinfo.h usability... yes checking langinfo.h presence... yes checking for langinfo.h... yes checking libintl.h usability... no checking libintl.h presence... no checking for libintl.h... no checking process.h usability... no checking process.h presence... no checking for process.h... no checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes checking sched.h usability... yes checking sched.h presence... yes checking for sched.h... yes checking shadow.h usability... no checking shadow.h presence... no checking for shadow.h... no checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking stropts.h usability... no checking stropts.h presence... no checking for stropts.h... no checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking for unistd.h... (cached) yes checking utime.h usability... yes checking utime.h presence... yes checking for utime.h... yes checking poll.h usability... yes checking poll.h presence... yes checking for poll.h... yes checking sys/devpoll.h usability... no checking sys/devpoll.h presence... no checking for sys/devpoll.h... no checking sys/epoll.h usability... yes checking sys/epoll.h presence... yes checking for sys/epoll.h... yes checking sys/poll.h usability... yes checking sys/poll.h presence... yes checking for sys/poll.h... yes checking sys/audioio.h usability... no checking sys/audioio.h presence... no checking for sys/audioio.h... no checking sys/xattr.h usability... yes checking sys/xattr.h presence... yes checking for sys/xattr.h... yes checking sys/bsdtty.h usability... no checking sys/bsdtty.h presence... no checking for sys/bsdtty.h... no checking sys/event.h usability... no checking sys/event.h presence... no checking for sys/event.h... no checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/ioctl.h usability... yes checking sys/ioctl.h presence... yes checking for sys/ioctl.h... yes checking sys/kern_control.h usability... no checking sys/kern_control.h presence... no checking for sys/kern_control.h... no checking sys/loadavg.h usability... no checking sys/loadavg.h presence... no checking for sys/loadavg.h... no checking sys/lock.h usability... no checking sys/lock.h presence... no checking for sys/lock.h... no checking sys/mkdev.h usability... no checking sys/mkdev.h presence... no checking for sys/mkdev.h... no checking sys/modem.h usability... no checking sys/modem.h presence... no checking for sys/modem.h... no checking sys/param.h usability... yes checking sys/param.h presence... yes checking for sys/param.h... yes checking sys/random.h usability... yes checking sys/random.h presence... yes checking for sys/random.h... yes checking sys/select.h usability... yes checking sys/select.h presence... yes checking for sys/select.h... yes checking sys/sendfile.h usability... yes checking sys/sendfile.h presence... yes checking for sys/sendfile.h... yes checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking sys/statvfs.h usability... yes checking sys/statvfs.h presence... yes checking for sys/statvfs.h... yes checking for sys/stat.h... (cached) yes checking sys/syscall.h usability... yes checking sys/syscall.h presence... yes checking for sys/syscall.h... yes checking sys/sys_domain.h usability... no checking sys/sys_domain.h presence... no checking for sys/sys_domain.h... no checking sys/termio.h usability... no checking sys/termio.h presence... no checking for sys/termio.h... no checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/times.h usability... yes checking sys/times.h presence... yes checking for sys/times.h... yes checking for sys/types.h... (cached) yes checking sys/uio.h usability... yes checking sys/uio.h presence... yes checking for sys/uio.h... yes checking sys/un.h usability... yes checking sys/un.h presence... yes checking for sys/un.h... yes checking sys/utsname.h usability... yes checking sys/utsname.h presence... yes checking for sys/utsname.h... yes checking sys/wait.h usability... yes checking sys/wait.h presence... yes checking for sys/wait.h... yes checking pty.h usability... yes checking pty.h presence... yes checking for pty.h... yes checking libutil.h usability... no checking libutil.h presence... no checking for libutil.h... no checking sys/resource.h usability... yes checking sys/resource.h presence... yes checking for sys/resource.h... yes checking netpacket/packet.h usability... yes checking netpacket/packet.h presence... yes checking for netpacket/packet.h... yes checking sysexits.h usability... yes checking sysexits.h presence... yes checking for sysexits.h... yes checking bluetooth.h usability... no checking bluetooth.h presence... no checking for bluetooth.h... no checking linux/tipc.h usability... yes checking linux/tipc.h presence... yes checking for linux/tipc.h... yes checking linux/random.h usability... yes checking linux/random.h presence... yes checking for linux/random.h... yes checking spawn.h usability... yes checking spawn.h presence... yes checking for spawn.h... yes checking util.h usability... no checking util.h presence... no checking for util.h... no checking alloca.h usability... yes checking alloca.h presence... yes checking for alloca.h... yes checking endian.h usability... yes checking endian.h presence... yes checking for endian.h... yes checking sys/endian.h usability... yes checking sys/endian.h presence... yes checking for sys/endian.h... yes checking sys/sysmacros.h usability... yes checking sys/sysmacros.h presence... yes checking for sys/sysmacros.h... yes checking for dirent.h that defines DIR... yes checking for library containing opendir... no checking whether sys/types.h defines makedev... no checking for sys/mkdev.h... (cached) no checking for sys/sysmacros.h... (cached) yes checking bluetooth/bluetooth.h usability... no checking bluetooth/bluetooth.h presence... no checking for bluetooth/bluetooth.h... no checking for net/if.h... yes checking for linux/netlink.h... yes checking for linux/vm_sockets.h... yes checking for linux/can.h... yes checking for linux/can/raw.h... yes checking for linux/can/bcm.h... yes checking for clock_t in time.h... yes checking for makedev... no checking for le64toh... no checking for mode_t... yes checking for off_t... yes checking for pid_t... yes checking for size_t... yes checking for uid_t in sys/types.h... yes checking for ssize_t... yes checking for __uint128_t... no checking size of int... 4 checking size of long... 4 checking size of long long... 8 checking size of void *... 4 checking size of short... 2 checking size of float... 4 checking size of double... 8 checking size of fpos_t... 8 checking size of size_t... 4 checking size of pid_t... 4 checking size of uintptr_t... 4 checking for long double support... yes checking size of long double... 8 checking size of _Bool... 1 checking size of off_t... 8 checking whether to enable large file support... yes checking size of time_t... 4 checking for pthread_t... yes checking size of pthread_t... 4 checking size of pthread_key_t... 4 checking whether pthread_key_t is compatible with int... yes checking for --enable-framework... no checking for dyld... no checking the extension of shared libraries... .so checking LDSHARED... $(CC) -shared checking CCSHARED... checking LINKFORSHARED... -pie -Xlinker -export-dynamic checking CFLAGSFORSHARED... $(CCSHARED) checking SHLIBS... $(LIBS) checking for sendfile in -lsendfile... no checking for dlopen in -ldl... no checking for shl_load in -ldld... no checking uuid/uuid.h usability... no checking uuid/uuid.h presence... no checking for uuid/uuid.h... no checking uuid.h usability... no checking uuid.h presence... no checking for uuid.h... no checking for uuid_generate_time_safe... no checking for uuid_create... no checking for uuid_enc_be... no checking for library containing sem_init... no checking for textdomain in -lintl... no checking aligned memory access is required... yes checking for --with-hash-algorithm... default checking for --with-address-sanitizer... no checking for --with-memory-sanitizer... no checking for --with-undefined-behavior-sanitizer... no checking for t_open in -lnsl... no checking for socket in -lsocket... no checking for --with-libs... no checking for armv7a-linux-androideabi-pkg-config... no checking for pkg-config... /usr/bin/pkg-config configure: WARNING: using cross tools not prefixed with host triplet checking pkg-config is at least version 0.9.0... yes checking for --with-system-expat... yes checking for --with-system-ffi... yes configure: WARNING: --with(out)-system-ffi is ignored on this platform checking for --with-system-libmpdec... no checking for --enable-loadable-sqlite-extensions... no checking for --with-tcltk-includes... default checking for --with-tcltk-libs... default checking for --with-dbmliborder... checking for _POSIX_THREADS in unistd.h... yes checking for pthread_create in -lpthread... checking for pthread_detach... no checking for pthread_create in -lpthreads... no checking for pthread_create in -lc_r... no checking for __pthread_create_system in -lpthread... no checking for pthread_create in -lcma... no configure: error: could not find pthreads on your system ---------- messages: 336779 nosy: muhzi, xdegaye priority: normal severity: normal status: open title: configure: error: could not find pthreads on your system during cross compilation versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 15:05:23 2019 From: report at bugs.python.org (muhzi) Date: Wed, 27 Feb 2019 20:05:23 +0000 Subject: [issue36141] configure: error: could not find pthreads on your system during cross compilation In-Reply-To: <1551297073.48.0.367193754314.issue36141@roundup.psfhosted.org> Message-ID: <1551297923.65.0.0410746694859.issue36141@roundup.psfhosted.org> Change by muhzi : ---------- components: +Cross-Build nosy: +Alex.Willmer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 15:09:35 2019 From: report at bugs.python.org (muhzi) Date: Wed, 27 Feb 2019 20:09:35 +0000 Subject: [issue36141] configure: error: could not find pthreads on your system during cross compilation In-Reply-To: <1551297073.48.0.367193754314.issue36141@roundup.psfhosted.org> Message-ID: <1551298175.19.0.43446398656.issue36141@roundup.psfhosted.org> Change by muhzi : ---------- type: -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 15:32:05 2019 From: report at bugs.python.org (=?utf-8?q?Manuel_Cer=C3=B3n?=) Date: Wed, 27 Feb 2019 20:32:05 +0000 Subject: [issue23864] issubclass without registration only works for "one-trick pony" collections ABCs. In-Reply-To: <1428145067.47.0.0726533343331.issue23864@psf.upfronthosting.co.za> Message-ID: <1551299525.62.0.787179810668.issue23864@roundup.psfhosted.org> Change by Manuel Cer?n : ---------- nosy: +ceronman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 15:32:11 2019 From: report at bugs.python.org (=?utf-8?q?Manuel_Cer=C3=B3n?=) Date: Wed, 27 Feb 2019 20:32:11 +0000 Subject: [issue25737] array is not a Sequence In-Reply-To: <1448537649.86.0.885493348949.issue25737@psf.upfronthosting.co.za> Message-ID: <1551299531.13.0.196654543979.issue25737@roundup.psfhosted.org> Change by Manuel Cer?n : ---------- nosy: +ceronman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 16:04:26 2019 From: report at bugs.python.org (Robert Marshall) Date: Wed, 27 Feb 2019 21:04:26 +0000 Subject: [issue13501] Make libedit support more generic; port readline / libedit to FreeBSD In-Reply-To: <1322579942.3.0.601983912656.issue13501@psf.upfronthosting.co.za> Message-ID: <1551301466.35.0.144321607505.issue13501@roundup.psfhosted.org> Robert Marshall added the comment: I have rebased this to recent master hash 53b9e1a1c1 and submitted a pull request. It built in my CI environment, so seems to be OK as far as compiling. I'll run the test suite against it later this evening when I have time to stand up a quick build enviroment with the full dependency list. ---------- nosy: +Robert Marshall pull_requests: +12095 Added file: https://bugs.python.org/file48175/0001-Build-or-disable-readline-module-with-Editline.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 16:23:13 2019 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 27 Feb 2019 21:23:13 +0000 Subject: [issue36141] configure: error: could not find pthreads on your system during cross compilation In-Reply-To: <1551297073.48.0.367193754314.issue36141@roundup.psfhosted.org> Message-ID: <1551302593.83.0.669382355815.issue36141@roundup.psfhosted.org> Xavier de Gaye added the comment: What is the NDK version ? There is no Android pthread library. It is possible that the failure comes from the fact that the first configure test on pthread_create links with pthread and that the Android linker fails now instead of ignoring this error as it did before. Can you add "ac_cv_pthread_is_default=yes" to the configure command line in order to tell configure that the pthread functions are in the main libc (i.e. bionic) to see if this fixes the problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 17:19:58 2019 From: report at bugs.python.org (Eryk Sun) Date: Wed, 27 Feb 2019 22:19:58 +0000 Subject: [issue36116] test_multiprocessing_spawn fails on AMD64 Windows8 3.x In-Reply-To: <1551165223.62.0.963183120667.issue36116@roundup.psfhosted.org> Message-ID: <1551305998.77.0.661456118793.issue36116@roundup.psfhosted.org> Eryk Sun added the comment: > And depending on the OS, abort() calls (via Py_FatalError) sometimes > appear to be segfaults, so it could be any number of issues. > (Aside - I'd love to replace the abort() calls with specific exit > codes for configuration errors - they really mess up the crash data > we see on Windows.) In particular, with the Universal CRT, an unhandled abort() is implemented by a __fastfail intrinsic [1] (int 0x29 instruction in x86) with the argument FAST_FAIL_FATAL_APP_EXIT (7). Prior to Windows 8 this appears as an access violation. In Windows 8+ it's implemented as a second-chance STATUS_STACK_BUFFER_OVERRUN (0xC0000409) exception, which is overloaded from its previous use to support failure codes. (The old usage appears as the failure code FAST_FAIL_LEGACY_GS_VIOLATION, defined to be 0.) It starts as a second-chance exception in order to bypass normal exception handling (i.e. SEH, VEH, UnhandledExceptionFilter). The second-chance exception event is sent to an attached debugger and/or the session server (csrss.exe). Python's normal signal handling for SIGABRT can't prevent this, since the C handler just sets a flag and returns. But enabling faulthandler sets a C signal handler that restores the previous handler and calls raise(SIGABRT). The default SIGABRT handler for the explicit raise() code path simply calls _exit(3). Alternatively, we could prevent the __fastfail call via _set_abort_behavior [2], if implemented in msvcrt. For example: msvcrt.set_abort_behavior(0, msvcrt.CALL_REPORTFAULT). [1]: https://docs.microsoft.com/en-us/cpp/intrinsics/fastfail [2]: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/set-abort-behavior ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 17:58:33 2019 From: report at bugs.python.org (Brett Cannon) Date: Wed, 27 Feb 2019 22:58:33 +0000 Subject: [issue36128] ResourceReader for FileLoader inconsistently handles path separators In-Reply-To: <1551215100.55.0.236644911032.issue36128@roundup.psfhosted.org> Message-ID: <1551308313.8.0.814052506426.issue36128@roundup.psfhosted.org> Change by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 18:41:58 2019 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 27 Feb 2019 23:41:58 +0000 Subject: [issue30406] async and await should be keywords in 3.7 In-Reply-To: <1495229262.01.0.300246152317.issue30406@psf.upfronthosting.co.za> Message-ID: <1551310918.66.0.0165027478718.issue30406@roundup.psfhosted.org> Guido van Rossum added the comment: Sadly if I get my way this will all be reverted -- see https://bugs.python.org/issue35975. I'm working on a PR. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 18:50:48 2019 From: report at bugs.python.org (Andrew P. Lentvorski, Jr.) Date: Wed, 27 Feb 2019 23:50:48 +0000 Subject: [issue36132] Python cannot access hci_channel field in sockaddr_hci In-Reply-To: <1551265831.42.0.956760803512.issue36132@roundup.psfhosted.org> Message-ID: <1551311448.18.0.0312935900516.issue36132@roundup.psfhosted.org> Andrew P. Lentvorski, Jr. added the comment: It's up to you how you folks want to deal with this, but classifying it as a "bug" for those versions in bugfix is likely acceptable. You already have to call bind with a tuple, so as long as it is *optional* to add an extra field to that tuple (and I can't imagine that any fix would not do that as it would break existing code), it's not going to break things. However, since nobody seems to have felt the need to file this, fixing this in 3.8 is probably just fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 19:24:20 2019 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 28 Feb 2019 00:24:20 +0000 Subject: [issue35975] Put back the ability to parse files where async/await aren't keywords In-Reply-To: <1549931018.54.0.209945896308.issue35975@roundup.psfhosted.org> Message-ID: <1551313460.41.0.559119814224.issue35975@roundup.psfhosted.org> Yury Selivanov added the comment: Well, it's not just rolling back async/await from being keywords. Since 3.7 it's possible to create async generator expressions in non-async functions. This wasn't possible to do with old hacks on the lexer. So if you want to revert the change you risk losing some functionality we enabled in 3.7 ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 19:37:38 2019 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 28 Feb 2019 00:37:38 +0000 Subject: [issue35975] Put back the ability to parse files where async/await aren't keywords In-Reply-To: <1549931018.54.0.209945896308.issue35975@roundup.psfhosted.org> Message-ID: <1551314258.37.0.376627143216.issue35975@roundup.psfhosted.org> Guido van Rossum added the comment: That should still work. The strategy is as follows: - For Python 3.7 or higher, 'async' and 'await' are *always* recognized. - For Python 3.5 and 3.6, the hacks from the PEP are used. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 19:44:52 2019 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 28 Feb 2019 00:44:52 +0000 Subject: [issue35975] Put back the ability to parse files where async/await aren't keywords In-Reply-To: <1549931018.54.0.209945896308.issue35975@roundup.psfhosted.org> Message-ID: <1551314692.51.0.928915502367.issue35975@roundup.psfhosted.org> Change by Guido van Rossum : ---------- keywords: +patch pull_requests: +12096 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 19:50:08 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Thu, 28 Feb 2019 00:50:08 +0000 Subject: [issue24740] make patchcheck doesn't detect changes if commit is done first In-Reply-To: <1438056026.2.0.092826443421.issue24740@psf.upfronthosting.co.za> Message-ID: <1551315008.93.0.677105534957.issue24740@roundup.psfhosted.org> Cheryl Sabella added the comment: I believe this issue has been resolved under the new Github workflow. I ran `make patchcheck` on a commit that had been pushed and it identified the changes. ---------- nosy: +cheryl.sabella _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 20:00:29 2019 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 28 Feb 2019 01:00:29 +0000 Subject: [issue35975] Put back the ability to parse files where async/await aren't keywords In-Reply-To: <1549931018.54.0.209945896308.issue35975@roundup.psfhosted.org> Message-ID: <1551315629.69.0.27177277763.issue35975@roundup.psfhosted.org> Yury Selivanov added the comment: Actually, I think we could revert to old lexer hacks in 3.8 if we modify them to treat 'async for' tocken sequence as one meta-tocken. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 20:10:22 2019 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 28 Feb 2019 01:10:22 +0000 Subject: [issue35975] Put back the ability to parse files where async/await aren't keywords In-Reply-To: <1549931018.54.0.209945896308.issue35975@roundup.psfhosted.org> Message-ID: <1551316222.91.0.83146824262.issue35975@roundup.psfhosted.org> Guido van Rossum added the comment: But why would we? I already have a working solution. (Literally reverting Jelle's PR won't work anyway, because Serhiy changed how regen-token works.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 20:19:28 2019 From: report at bugs.python.org (Chih-Hsuan Yen) Date: Thu, 28 Feb 2019 01:19:28 +0000 Subject: [issue29397] linux/random.h present but cannot be compiled In-Reply-To: <1485872500.79.0.0659257887821.issue29397@psf.upfronthosting.co.za> Message-ID: <1551316768.1.0.121840927231.issue29397@roundup.psfhosted.org> Change by Chih-Hsuan Yen : ---------- nosy: -yan12125 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 20:20:20 2019 From: report at bugs.python.org (Chih-Hsuan Yen) Date: Thu, 28 Feb 2019 01:20:20 +0000 Subject: [issue23794] http package should support HTTP/2 In-Reply-To: <1427479110.25.0.801999785412.issue23794@psf.upfronthosting.co.za> Message-ID: <1551316820.86.0.893756793238.issue23794@roundup.psfhosted.org> Change by Chih-Hsuan Yen : ---------- nosy: -yan12125 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 20:21:19 2019 From: report at bugs.python.org (Chih-Hsuan Yen) Date: Thu, 28 Feb 2019 01:21:19 +0000 Subject: [issue34095] [2.7] Seg fault on archlinux 32 when run tests with xvfb-run In-Reply-To: <1531314252.99.0.56676864532.issue34095@psf.upfronthosting.co.za> Message-ID: <1551316879.96.0.38633640566.issue34095@roundup.psfhosted.org> Change by Chih-Hsuan Yen : ---------- nosy: -yan12125 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 20:25:45 2019 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 28 Feb 2019 01:25:45 +0000 Subject: [issue35975] Put back the ability to parse files where async/await aren't keywords In-Reply-To: <1549931018.54.0.209945896308.issue35975@roundup.psfhosted.org> Message-ID: <1551317145.86.0.863884386334.issue35975@roundup.psfhosted.org> Yury Selivanov added the comment: > But why would we? I already have a working solution. I've heard some complaints that it's hard to migrate to Python 3.7 because async and await are keywords (although I think by now all popular libraries have migrated already), so in case you ever considered to revert that decision I think we could actually make it work. But for the current PR you're working on we don't need that, you're right. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 20:28:33 2019 From: report at bugs.python.org (Chih-Hsuan Yen) Date: Thu, 28 Feb 2019 01:28:33 +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: <1551317313.12.0.128424489892.issue27640@roundup.psfhosted.org> Change by Chih-Hsuan Yen : ---------- nosy: -yan12125 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 20:42:19 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 28 Feb 2019 01:42:19 +0000 Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to setup memory allocator and encodings Message-ID: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org> New submission from STINNER Victor : I added a _PyCoreConfig structure to Python 3.7 which contains almost all parameters used to configure Python. Problems: _PyCoreConfig uses bytes and Unicode strings (char* and wchar_t*) whereas it is also used to setup the memory allocator and (filesystem, locale and stdio) encodings. I propose to add a new _PyPreConfig which is the "strict minimum" configuration to setup encodings and the memory allocator. In practice, it also contains parameters which directly or indirectly impacts the allocator and encodings. For example, isolated impacts use_environment which impacts the allocator (PYTHONMALLOC environment variable). Another example: dev_mode=1 sets the allocator to "debug". The command line arguments are now parsed twice. _PyPreConfig only parses a few parameters like -E, -I and -X. A temporary _PyPreCmdline is used to store command line arguments like -X options. I moved structures closer to where they are used. "Global" _PyMain structure has been removed. _PyCmdline now lives way shorter than previously and is moved from main.c to coreconfig.c. The idea is to better control when and how memory is allocated. In term of API, we get something like: _PyCoreConfig config = _PyCoreConfig_INIT; config.preconfig.stdio_encoding = "iso8859-1"; config.preconfig.stdio_errors = "replace"; config.user_site_directory = 0; ... _PyInitError err = _Py_InitializeFromConfig(&config); if (_Py_INIT_FAILED(err)) { _Py_ExitInitError(err); } ... Py_Finalize(); return 0; "config.preconfig.stdio_errors" syntax isn't great, but it's simpler to implement than duplicating all _PyPreConfig fields into _PyCoreConfig. ---------- components: Interpreter Core messages: 336791 nosy: vstinner priority: normal severity: normal status: open title: Add a new _PyPreConfig step to Python initialization to setup memory allocator and encodings versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 20:47:22 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 28 Feb 2019 01:47:22 +0000 Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to setup memory allocator and encodings In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org> Message-ID: <1551318442.51.0.851465456203.issue36142@roundup.psfhosted.org> Change by STINNER Victor : ---------- keywords: +patch pull_requests: +12097 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 20:50:07 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 28 Feb 2019 01:50:07 +0000 Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to setup memory allocator and encodings In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org> Message-ID: <1551318607.43.0.556432724737.issue36142@roundup.psfhosted.org> STINNER Victor added the comment: PR 12087 is a WIP change which implements everything as a single commit. I'm not 100% sure yet that it's best approach for Python initialization, but I'm sure that it solves real interdependencies issues between _PyCoreConfig parameters. IHMO have a "pre-initialization" step to setup the memory allocator and the encodings is a better design. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 20:53:06 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 28 Feb 2019 01:53:06 +0000 Subject: [issue22213] Make pyvenv style virtual environments easier to configure when embedding Python In-Reply-To: <1408275761.36.0.915361061447.issue22213@psf.upfronthosting.co.za> Message-ID: <1551318786.7.0.50273565267.issue22213@roundup.psfhosted.org> STINNER Victor added the comment: I created bpo-36142: "Add a new _PyPreConfig step to Python initialization to setup memory allocator and encodings". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 21:42:41 2019 From: report at bugs.python.org (Patrick McLean) Date: Thu, 28 Feb 2019 02:42:41 +0000 Subject: [issue36046] support dropping privileges when running subprocesses In-Reply-To: <1550625858.55.0.53498127684.issue36046@roundup.psfhosted.org> Message-ID: <1551321761.37.0.913022415634.issue36046@roundup.psfhosted.org> Patrick McLean added the comment: I have updated the pull request to include 'group' and 'extra_groups' as separate parameters. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 22:06:04 2019 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 28 Feb 2019 03:06:04 +0000 Subject: [issue35975] Put back the ability to parse files where async/await aren't keywords In-Reply-To: <1549931018.54.0.209945896308.issue35975@roundup.psfhosted.org> Message-ID: <1551323164.83.0.180355759074.issue35975@roundup.psfhosted.org> Guido van Rossum added the comment: And the same tokenizer trick that detects 'async def' could detect 'async for' easily. See https://github.com/python/cpython/pull/12086/files#diff-30b8266a4285de981f8b1b82a8cc6231R1418 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 22:32:16 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 28 Feb 2019 03:32:16 +0000 Subject: [issue24740] make patchcheck doesn't detect changes if commit is done first In-Reply-To: <1438056026.2.0.092826443421.issue24740@psf.upfronthosting.co.za> Message-ID: <1551324736.41.0.637710606531.issue24740@roundup.psfhosted.org> Terry J. Reedy added the comment: I am pretty sure I have done the same after making all commits to the local branch. Plus we have the better workflow. So closing until there is a confirmed problem with the new workflow. ---------- resolution: -> out of date stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 23:11:10 2019 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 28 Feb 2019 04:11:10 +0000 Subject: [issue36143] AUto-generate Lib/keyword.py Message-ID: <1551327070.18.0.354102770805.issue36143@roundup.psfhosted.org> New submission from Guido van Rossum : The stdib keyword.py module must be regenerated after adding/removing keywords from the grammar. While this is rare, we now generate everything else derived from the grammar. Hopefully someone can add some rules to the Makefile to auto-generate this one too when regen-grammar is run. This is probably an easy project for a beginning contributor. ---------- components: Build messages: 336797 nosy: gvanrossum priority: normal severity: normal status: open title: AUto-generate Lib/keyword.py versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 23:14:29 2019 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 28 Feb 2019 04:14:29 +0000 Subject: [issue36143] Auto-generate Lib/keyword.py In-Reply-To: <1551327070.18.0.354102770805.issue36143@roundup.psfhosted.org> Message-ID: <1551327269.82.0.0824421122286.issue36143@roundup.psfhosted.org> Change by Arfrever Frehtes Taifersar Arahesis : ---------- title: AUto-generate Lib/keyword.py -> Auto-generate Lib/keyword.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 23:18:58 2019 From: report at bugs.python.org (Brandt Bucher) Date: Thu, 28 Feb 2019 04:18:58 +0000 Subject: [issue36144] Dictionary addition. Message-ID: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org> New submission from Brandt Bucher : ...as discussed in python-ideas. Semantically: d1 + d2 <-> d3 = d1.copy(); d3.update(d2); d3 d1 += d2 <-> d1.update(d2) Attached is a working implementation with new/fixed tests for consideration. I've also updated collections.UserDict with the new __add__/__radd__/__iadd__ methods. ---------- components: Interpreter Core messages: 336798 nosy: brandtbucher priority: normal severity: normal status: open title: Dictionary addition. type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 23:19:14 2019 From: report at bugs.python.org (Brandt Bucher) Date: Thu, 28 Feb 2019 04:19:14 +0000 Subject: [issue36144] Dictionary addition. In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org> Message-ID: <1551327554.47.0.654655895335.issue36144@roundup.psfhosted.org> Change by Brandt Bucher : ---------- keywords: +patch pull_requests: +12098 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 23:35:11 2019 From: report at bugs.python.org (Zachary Ware) Date: Thu, 28 Feb 2019 04:35:11 +0000 Subject: [issue36143] Auto-generate Lib/keyword.py In-Reply-To: <1551327070.18.0.354102770805.issue36143@roundup.psfhosted.org> Message-ID: <1551328511.24.0.746391009044.issue36143@roundup.psfhosted.org> Zachary Ware added the comment: Lib/keyword.py already regenerates itself from Python/graminit.c when run as a script, but there should be a `regen-keyword.py` target added to Makefile.pre.in and included as a dependency of the `regen-all` target. Agreed that this is a good starting issue, particularly for anyone wanting to get more familiar with Makefiles. See also issue30638. ---------- keywords: +easy nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 27 23:44:29 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 28 Feb 2019 04:44:29 +0000 Subject: [issue36143] Auto-generate Lib/keyword.py In-Reply-To: <1551327070.18.0.354102770805.issue36143@roundup.psfhosted.org> Message-ID: <1551329069.57.0.271389495583.issue36143@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +cheryl.sabella _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 00:01:17 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 28 Feb 2019 05:01:17 +0000 Subject: [issue36144] Dictionary addition. In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org> Message-ID: <1551330077.66.0.617010927874.issue36144@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 00:11:37 2019 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 28 Feb 2019 05:11:37 +0000 Subject: [issue35975] Put back the ability to parse files where async/await aren't keywords In-Reply-To: <1549931018.54.0.209945896308.issue35975@roundup.psfhosted.org> Message-ID: <1551330697.9.0.0157283155734.issue35975@roundup.psfhosted.org> Yury Selivanov added the comment: > And the same tokenizer trick that detects 'async def' could detect 'async for' easily. Exactly. I just never thought that we could support async generator expressions with the kind of hacks in tokenizer we had in 3.5-3.6. FWIW I still believe that it's better for async & await tokens to be proper keywords, but in case we ever realize we want them to become "soft" keywords we apparently have options. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 00:14:00 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 28 Feb 2019 05:14:00 +0000 Subject: [issue36131] test.test_urllib2net.TimeoutTest ftp related tests fail due to ftp://www.pythontest.net/ being unavailable In-Reply-To: <1551243962.9.0.321127985724.issue36131@roundup.psfhosted.org> Message-ID: <1551330840.54.0.0231447395791.issue36131@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Just curious if it was some regression or infrastructure related issue in pythontest.net ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 00:16:02 2019 From: report at bugs.python.org (Thrlwiti) Date: Thu, 28 Feb 2019 05:16:02 +0000 Subject: [issue30235] Validate shutil supports path-like objects, update docs accordingly In-Reply-To: <1493745159.76.0.694023923588.issue30235@psf.upfronthosting.co.za> Message-ID: <1551330962.66.0.0689628761845.issue30235@roundup.psfhosted.org> Change by Thrlwiti : ---------- nosy: +THRlWiTi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 00:50:12 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Thu, 28 Feb 2019 05:50:12 +0000 Subject: [issue36131] test.test_urllib2net.TimeoutTest ftp related tests fail due to ftp://www.pythontest.net/ being unavailable In-Reply-To: <1551243962.9.0.321127985724.issue36131@roundup.psfhosted.org> Message-ID: <1551333012.17.0.242388038996.issue36131@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: That was my impression. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 01:33:14 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 28 Feb 2019 06:33:14 +0000 Subject: [issue36144] Dictionary addition. In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org> Message-ID: <1551335594.85.0.826717148797.issue36144@roundup.psfhosted.org> Raymond Hettinger added the comment: I believe that Guido rejected this when it was proposed a few years ago. ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 01:34:46 2019 From: report at bugs.python.org (Mika Fischer) Date: Thu, 28 Feb 2019 06:34:46 +0000 Subject: [issue36137] SSL verification fails for some sites inside windows docker container In-Reply-To: <1551278097.55.0.344471071893.issue36137@roundup.psfhosted.org> Message-ID: <1551335686.46.0.031343012313.issue36137@roundup.psfhosted.org> Mika Fischer added the comment: > This is probably a duplicate of #36137. I think you mixed up the issue number, #36137 is this issue. > Windows doesn't have CA certs pre-installed. They are downloaded from the update server on demand. Python doesn't trigger the update but only uses certs that are already present. It's a design flaw in my implementation. I wasn't aware of Windows' behavior when I hooked up the Windows cert store to the SSL module. Oh, so that means that it is broken on normal Windows as well and only works coincidentally? In any case, I can confirm that when the certificate is fetched using some other means, the request works: ``` docker run -ti python:3.7-windowsservercore-1809 powershell -command "(New-Object System.Net.WebClient).DownloadString(\"https://google.com\") >$null; python -c \"import urllib.request as r; r.urlopen('https://google.com').close()\"" ``` ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 01:37:19 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 28 Feb 2019 06:37:19 +0000 Subject: [issue13850] Summary tables for argparse add_argument options In-Reply-To: <1327384498.23.0.981832544617.issue13850@psf.upfronthosting.co.za> Message-ID: <1551335839.39.0.098546687262.issue13850@roundup.psfhosted.org> Raymond Hettinger added the comment: I like the idea of having various summary tables for argparse, but the one in the PR isn't visually attractive or self-explanatory. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 01:56:54 2019 From: report at bugs.python.org (Mika Fischer) Date: Thu, 28 Feb 2019 06:56:54 +0000 Subject: [issue36137] SSL verification fails for some sites inside windows docker container In-Reply-To: <1551278097.55.0.344471071893.issue36137@roundup.psfhosted.org> Message-ID: <1551337014.86.0.468630500829.issue36137@roundup.psfhosted.org> Mika Fischer added the comment: The easiest workaround I found (on Windows 10) is to use ``` certutil -generateSSTFromWU roots.sst && certutil -addstore -f root roots.sst && del roots.sst ``` before using Python... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 01:58:40 2019 From: report at bugs.python.org (Peter L) Date: Thu, 28 Feb 2019 06:58:40 +0000 Subject: [issue33944] Deprecate and remove pth files In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za> Message-ID: <1551337120.58.0.728824785664.issue33944@roundup.psfhosted.org> Change by Peter L : ---------- nosy: +Peter L3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 02:06:52 2019 From: report at bugs.python.org (chenkai) Date: Thu, 28 Feb 2019 07:06:52 +0000 Subject: [issue33085] *** Error in `python': double free or corruption (out): 0x00007ff5254d50d0 *** In-Reply-To: <1521183590.06.0.467229070634.issue33085@psf.upfronthosting.co.za> Message-ID: <1551337612.04.0.404741551205.issue33085@roundup.psfhosted.org> chenkai <13016135670 at 163.com> added the comment: OS: (python36) [root at localhost ~]# uname -a Linux localhost.localdomain 3.10.0-862.el7.x86_64 #1 SMP Fri Apr 20 16:44:24 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux Python 3.6.5 (default, Feb 28 2019, 01:43:16) [GCC 4.8.5 20150623 (Red Hat 4.8.5-28)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> *** Error in `python': free(): invalid pointer: 0x00007f4eb7a64558 *** ======= Backtrace: ========= /lib64/libc.so.6(+0x81499)[0x7f4eb6c45499] python(PyOS_Readline+0xec)[0x5cc48c] python[0x447250] python[0x448b98] python(PyTokenizer_Get+0x9)[0x4499d9] python[0x4457dd] python(PyParser_ASTFromFileObject+0x89)[0x427909] python[0x427b1b] python(PyRun_InteractiveLoopFlags+0x76)[0x427e46] python(PyRun_AnyFileExFlags+0x3c)[0x427fcc] python(Py_Main+0xc44)[0x43b934] python(main+0x162)[0x41d8b2] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7f4eb6be6445] python[0x41d970] ======= Memory map: ======== ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 02:07:07 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 28 Feb 2019 07:07:07 +0000 Subject: [issue36144] Dictionary addition. In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org> Message-ID: <1551337627.19.0.353000766671.issue36144@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Python ideas discussion in 2015 : https://mail.python.org/pipermail/python-ideas/2015-February/031748.html LWN summary : https://lwn.net/Articles/635397/ ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 02:10:58 2019 From: report at bugs.python.org (Peter L) Date: Thu, 28 Feb 2019 07:10:58 +0000 Subject: [issue33944] Deprecate and remove pth files In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za> Message-ID: <1551337858.24.0.639548755728.issue33944@roundup.psfhosted.org> Peter L added the comment: +1 for python -v listing .pth files found and loaded. For debugging, I just add a: import sys; print('Loading mypth.pth') to the start of the pth file. A plain print doesn't work(?). breakpoint() doesn't work(?). It would be nice to be able to get the filename (__file__ is site.py) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 02:29:11 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Feb 2019 07:29:11 +0000 Subject: [issue36144] Dictionary addition. In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org> Message-ID: <1551338951.81.0.987288888645.issue36144@roundup.psfhosted.org> Serhiy Storchaka added the comment: I believe it was proposed and rejected multiple times. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 02:36:52 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 28 Feb 2019 07:36:52 +0000 Subject: [issue36144] Dictionary addition. In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org> Message-ID: <1551339412.76.0.627363613546.issue36144@roundup.psfhosted.org> Raymond Hettinger added the comment: For the record, I'm opposed to the idea. * Use of the + operator is a temptation to produce new dictionaries rather than update an existing dict in-place which is usually what you want. * We already have ChainMap() which presents a single view of multiple mappings with any copying. * It is natural to expect the plus operator to be commutative, but this operation would necessarily be non-commutative. * Many other APIs are modeled on the dict API, so we should not grow the API unless there is a big win. The effects would be pervasive. * I don't see other languages going down this path, nor am I seeing dict subclasses that implement this functionality. Those are indications that this more of a "fun thing we could do" rather than a "thing that people need". * The existing code already reads nicely: options.update(user_selections) That reads more like self explanatory English than: options += user_selections The latter takes more effort to correctly parse and makes it less clear that you're working with dicts. * It isn't self-evident that the right operand needs to be another dictionary. If a person is trying to "add a key / value pair" to an existing dictionary, the "+=" operator would be tempting but it wouldn't work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 02:52:06 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Feb 2019 07:52:06 +0000 Subject: [issue36144] Dictionary addition. In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org> Message-ID: <1551340326.74.0.909745187914.issue36144@roundup.psfhosted.org> Serhiy Storchaka added the comment: > * It is natural to expect the plus operator to be commutative, but this operation would necessarily be non-commutative. In Python, the plus operator for sequences (strings, lists, tuples) is non-commutative. But I have other arguments against it: * It conflicts with the plus operator of Counter (which is a specialized dict): Counter(a=2) + Counter(a=3) == Counter(a=5), but the proposed idea makes dict(a=2) + dict(a=3) == dict(a=3). * We already have a syntax for dict merging: {**d1, **d2}. It works with arbitrary mappings, in contrary to the plus operator, which needs a special support in argument types. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 03:12:00 2019 From: report at bugs.python.org (Inada Naoki) Date: Thu, 28 Feb 2019 08:12:00 +0000 Subject: [issue36139] release GIL on mmap dealloc In-Reply-To: <1551290441.84.0.237778309898.issue36139@roundup.psfhosted.org> Message-ID: <1551341520.43.0.880770631062.issue36139@roundup.psfhosted.org> Inada Naoki added the comment: Your patch is modifying obmalloc. It uses MAP_PRIVATE|MAP_ANONYMOUS mmap. Does it really take log time? How? #1572968 is different. It is mmap module. It can use file-backed mmap. It is I/O. ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 03:14:55 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 28 Feb 2019 08:14:55 +0000 Subject: [issue35892] Fix awkwardness of statistics.mode() for multimodal datasets In-Reply-To: <1549219885.57.0.86866159357.issue35892@roundup.psfhosted.org> Message-ID: <1551341695.33.0.367477497522.issue35892@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- keywords: +patch pull_requests: +12099 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 03:15:59 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Thu, 28 Feb 2019 08:15:59 +0000 Subject: [issue13850] Summary tables for argparse add_argument options In-Reply-To: <1327384498.23.0.981832544617.issue13850@psf.upfronthosting.co.za> Message-ID: <1551341759.78.0.813883655729.issue13850@roundup.psfhosted.org> St?phane Wirtel added the comment: Hi @Raymond, Yep, I understand about the "look", I have seen the result after the build of the doc but the patch was like that and I did not want to change the initial patch. Would you suggest one layout and I could update the PR with your recommendations? Thanks for your review ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 03:17:02 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 28 Feb 2019 08:17:02 +0000 Subject: [issue35892] Fix awkwardness of statistics.mode() for multimodal datasets In-Reply-To: <1549219885.57.0.86866159357.issue35892@roundup.psfhosted.org> Message-ID: <1551341822.91.0.826194144451.issue35892@roundup.psfhosted.org> Raymond Hettinger added the comment: Attached a draft PR for discussion purposes. Let me know what you think (I'm not wedded to any part of it). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 03:23:10 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 28 Feb 2019 08:23:10 +0000 Subject: [issue36144] Dictionary addition. In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org> Message-ID: <1551342190.96.0.665487765904.issue36144@roundup.psfhosted.org> Raymond Hettinger added the comment: > In Python, the plus operator for sequences (strings, lists, > tuples) is non-commutative. For sequences, that is obvious and expected, but not so much with mappings where the order of overlapping keys is determined by the left operand and the value associated with those keys is determined by the right operand. Also with sequences the + operator actually means "add to", but with dictionaries it means "add/or replace" which is contrary to the normal meaning of plus. I think that was one of Guido's reasons for favoring "|" instead of "+" for set-to-set operations. > We already have a syntax for dict merging: {**d1, **d2}. > It works with arbitrary mappings, This is a good point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 03:38:23 2019 From: report at bugs.python.org (Inada Naoki) Date: Thu, 28 Feb 2019 08:38:23 +0000 Subject: [issue36139] release GIL on mmap dealloc In-Reply-To: <1551290441.84.0.237778309898.issue36139@roundup.psfhosted.org> Message-ID: <1551343103.97.0.572818900083.issue36139@roundup.psfhosted.org> Inada Naoki added the comment: Sorry, I messed up. Your PR is changing mmap module, not obmalloc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 04:06:21 2019 From: report at bugs.python.org (muhzi) Date: Thu, 28 Feb 2019 09:06:21 +0000 Subject: [issue36141] configure: error: could not find pthreads on your system during cross compilation In-Reply-To: <1551297073.48.0.367193754314.issue36141@roundup.psfhosted.org> Message-ID: <1551344781.74.0.600866271609.issue36141@roundup.psfhosted.org> muhzi added the comment: Well, it solves the problem with the configure script. My pyconfig.h.in contains: /* Define to 1 if you have the header file. */ #undef HAVE_PTHREAD_H /* Define to 1 if you have the `pthread_init' function. */ #undef HAVE_PTHREAD_INIT /* Define to 1 if you have the `pthread_kill' function. */ #undef HAVE_PTHREAD_KILL /* Define to 1 if you have the `pthread_sigmask' function. */ #undef HAVE_PTHREAD_SIGMASK The problem extends after the configuration. It's as if the android headers are not visible to configure. All the macros are undefined in the pyconfig file too btw. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 04:15:51 2019 From: report at bugs.python.org (Davide Rizzo) Date: Thu, 28 Feb 2019 09:15:51 +0000 Subject: [issue36139] release GIL on mmap dealloc In-Reply-To: <1551290441.84.0.237778309898.issue36139@roundup.psfhosted.org> Message-ID: <1551345351.01.0.827399586806.issue36139@roundup.psfhosted.org> Davide Rizzo added the comment: Yes, this is mmap module. I found this to be slow for posix-shm-backed mmaps. Several milliseconds, like 20ms for a 128 MB object. Maybe the same can happen with private|anon mmaps? I will follow up with more numbers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 04:20:07 2019 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 28 Feb 2019 09:20:07 +0000 Subject: [issue36144] Dictionary addition. In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org> Message-ID: <1551345607.85.0.189419677128.issue36144@roundup.psfhosted.org> Stefan Behnel added the comment: > We already have a syntax for dict merging: {**d1, **d2}. Which doesn't mean that "d1 + d2" isn't much more intuitive than this special-character heavy version. It takes me a while to see the dict merge under that heap of stars. And that's already the shortest example. > It works with arbitrary mappings, The RHS of "d += M" doesn't have to be a dict IMHO, it could be any mapping. And even "dict(X) + M" doesn't look all too bad to me, even though there's "dict(X, **M)". > Use of the + operator is a temptation to produce new dictionaries rather than update an existing dict in-place which is usually what you want. That's why there would be support for "+=". The exact same argument already fails for lists, where concatenation is usually much more performance critical than for the average little dict. (And remember that most code isn't performance critical at all.) > We already have ChainMap() which presents a single view of multiple mappings with any copying. Which is a different use case that is unlikely to go away with this proposal. > makes it less clear that you're working with dicts. This is a valid argument, although it always depends on the concrete code what the most readable way to express its intentions is. Again, this doesn't really differ for lists. Let's wait for the PEP, I'd say. ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 04:24:41 2019 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 28 Feb 2019 09:24:41 +0000 Subject: [issue36141] configure: error: could not find pthreads on your system during cross compilation In-Reply-To: <1551297073.48.0.367193754314.issue36141@roundup.psfhosted.org> Message-ID: <1551345881.87.0.297622010363.issue36141@roundup.psfhosted.org> Xavier de Gaye added the comment: > The problem extends after the configuration. It's as if the android headers are not visible to configure. All the macros are undefined in the pyconfig file too btw. pyconfig.h is generated by configure from pyconfig.h.in. Please attach the new output of running configure with ac_cv_pthread_is_default=yes (please do not paste it in your post). BTW what is the NDK version ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 04:57:10 2019 From: report at bugs.python.org (muhzi) Date: Thu, 28 Feb 2019 09:57:10 +0000 Subject: [issue36141] configure: error: could not find pthreads on your system during cross compilation In-Reply-To: <1551297073.48.0.367193754314.issue36141@roundup.psfhosted.org> Message-ID: <1551347830.46.0.851160141396.issue36141@roundup.psfhosted.org> muhzi added the comment: OK! NDK version is 19.1.5304403 Cool, so I uploaded the output of configure (attachments) Sorry for the confusion about pyconfig.h, what I was trying to say is after providing ac_cv_pthread_is_default=yes to configure I get errors in make: Python/pytime.c:911:9: error: implicit declaration of function 'pytime_fromtimespec' is invalid in C99 [-Werror,-Wimplicit-function-declaration] if (pytime_fromtimespec(tp, &ts, raise) < 0) { ^ Python/pytime.c:911:9: note: did you mean 'pytime_fromtimeval'? Python/pytime.c:336:1: note: 'pytime_fromtimeval' declared here pytime_fromtimeval(_PyTime_t *tp, struct timeval *tv, int raise) ^ Python/pytime.c:911:9: warning: this function declaration is not a prototype [-Wstrict-prototypes] if (pytime_fromtimespec(tp, &ts, raise) < 0) { ^ ---------- Added file: https://bugs.python.org/file48176/config.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 05:12:23 2019 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 28 Feb 2019 10:12:23 +0000 Subject: [issue36144] Dictionary addition. In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org> Message-ID: <1551348743.61.0.900416097381.issue36144@roundup.psfhosted.org> Change by Mark Dickinson : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 05:26:28 2019 From: report at bugs.python.org (Christian Heimes) Date: Thu, 28 Feb 2019 10:26:28 +0000 Subject: [issue36137] SSL verification fails for some sites inside windows docker container In-Reply-To: <1551278097.55.0.344471071893.issue36137@roundup.psfhosted.org> Message-ID: <1551349588.44.0.347703954137.issue36137@roundup.psfhosted.org> Christian Heimes added the comment: Err, I meant #36011 The enum cert store trick only breaks on a fresh installation. If you have used Windows for a bit (e.g. downloaded Firefox with Edge *g*), the root CA store is filled with common CA certs. Your certutil trick also works, as it triggers cert retrieval and update from Windows Update Server. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 05:26:32 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 28 Feb 2019 10:26:32 +0000 Subject: [issue30235] Validate shutil supports path-like objects, update docs accordingly In-Reply-To: <1493745159.76.0.694023923588.issue30235@psf.upfronthosting.co.za> Message-ID: <1551349592.72.0.896676055957.issue30235@roundup.psfhosted.org> Giampaolo Rodola' added the comment: One thing to note is the copy_function parameter: if a path-like object is given as input should the copy_function receive the same object instead of a path string? >>> copytree(path_like_src, path_like_dst, copy_function=foo) Because of issue33695 in case of copytree(..., copy_function=...) we currently force to always pass path strings if copy_function is specified: https://github.com/python/cpython/blob/ed1deb0719f0ac1b08a374e30ad26a701d4d51a2/Lib/shutil.py#L450 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 05:49:39 2019 From: report at bugs.python.org (Thrlwiti) Date: Thu, 28 Feb 2019 10:49:39 +0000 Subject: [issue31652] make install fails: no module _ctypes In-Reply-To: <1506812661.87.0.213398074469.issue31652@psf.upfronthosting.co.za> Message-ID: <1551350979.94.0.803384897174.issue31652@roundup.psfhosted.org> Change by Thrlwiti : ---------- nosy: +THRlWiTi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 06:20:05 2019 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 28 Feb 2019 11:20:05 +0000 Subject: [issue36141] configure: error: could not find pthreads on your system during cross compilation In-Reply-To: <1551297073.48.0.367193754314.issue36141@roundup.psfhosted.org> Message-ID: <1551352805.73.0.157780325312.issue36141@roundup.psfhosted.org> Xavier de Gaye added the comment: This is a different problem. Please create a new issue and attach pyconfig.h. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 06:23:44 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 28 Feb 2019 11:23:44 +0000 Subject: [issue29571] test_re is failing when local is set for `en_IN` In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za> Message-ID: <1551353024.79.0.0819007632524.issue29571@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Similar issue reported on debian9.8 stretch with python 3.7.2 and en_IN : issue36134 ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 06:35:25 2019 From: report at bugs.python.org (Davide Rizzo) Date: Thu, 28 Feb 2019 11:35:25 +0000 Subject: [issue36139] release GIL on mmap dealloc In-Reply-To: <1551290441.84.0.237778309898.issue36139@roundup.psfhosted.org> Message-ID: <1551353725.5.0.161540056421.issue36139@roundup.psfhosted.org> Davide Rizzo added the comment: munmap() of private maps is usually pretty fast but not negligible (2 ms for 1GB). Shared maps are much slower. For some reason, shared maps explicitly backed by POSIX shared memory stand in between but are still pretty slow. If someone cares about file-backed mmaps I can test those too. I thought this is already significant to justify releasing the GIL. This is on Linux 4.4: shared anon mmap 1048576 bytes mmap time 6,393 ns write time 449,062 ns munmap time 100,205 ns -- private anon mmap 1048576 bytes mmap time 2,168 ns write time 308,966 ns munmap time 36,930 ns -- posix shm + mmap 1048576 bytes mmap time 13,299 ns write time 369,305 ns close time 1,545 ns munmap time 26,759 ns -- shared anon mmap 134217728 bytes mmap time 4,641 ns write time 64,508,536 ns munmap time 13,592,556 ns -- private anon mmap 134217728 bytes mmap time 6,116 ns write time 25,402,084 ns munmap time 388,976 ns -- posix shm + mmap 134217728 bytes mmap time 29,034 ns write time 66,826,645 ns close time 3,707 ns munmap time 3,475,977 ns -- shared anon mmap 1073741824 bytes mmap time 11,127 ns write time 508,227,373 ns munmap time 94,885,306 ns -- private anon mmap 1073741824 bytes mmap time 7,133 ns write time 199,933,903 ns munmap time 2,361,036 ns -- posix shm + mmap 1073741824 bytes mmap time 24,868 ns write time 527,566,819 ns close time 4,015 ns munmap time 21,179,674 ns -- ---------- Added file: https://bugs.python.org/file48177/unmap.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 06:44:57 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Thu, 28 Feb 2019 11:44:57 +0000 Subject: [issue29397] linux/random.h present but cannot be compiled In-Reply-To: <1485872500.79.0.0659257887821.issue29397@psf.upfronthosting.co.za> Message-ID: <1551354297.08.0.559637419255.issue29397@roundup.psfhosted.org> Change by Emmanuel Arias : ---------- nosy: +eamanu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 06:51:25 2019 From: report at bugs.python.org (muhzi) Date: Thu, 28 Feb 2019 11:51:25 +0000 Subject: [issue36145] android arm cross compilation fails, h Message-ID: <1551354685.49.0.372861646836.issue36145@roundup.psfhosted.org> New submission from muhzi : This is a follow up of #36141, I'm trying to build python for android armv7a. The problem was the configure script fails to find pthread_create in the android headers. Now after getting past the configuration, I get a build error: armv7a-linux-androideabi16-clang -c -mfloat-abi=softfp -mfpu=vfpv3-d16 -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes -Werror=implicit-function-declaration -I. -I./Include -DPy_BUILD_CORE -o Python/pytime.o Python/pytime.c Python/pytime.c:911:9: error: implicit declaration of function 'pytime_fromtimespec' is invalid in C99 [-Werror,-Wimplicit-function-declaration] if (pytime_fromtimespec(tp, &ts, raise) < 0) { ^ Python/pytime.c:911:9: note: did you mean 'pytime_fromtimeval'? Python/pytime.c:336:1: note: 'pytime_fromtimeval' declared here pytime_fromtimeval(_PyTime_t *tp, struct timeval *tv, int raise) ^ Python/pytime.c:911:9: warning: this function declaration is not a prototype [-Wstrict-prototypes] if (pytime_fromtimespec(tp, &ts, raise) < 0) { ^ The declaration for pytime_fromtimespec needs the token HAVE_CLOCK_GETTIME to be defined to 1, which isn't the case (as per pyconfig.h). I checked the android headers and time.h seems to have the necessary function for this token. I uploaded pyconfig.h for reference (attached). ---------- components: Cross-Build files: pyconfig.h messages: 336828 nosy: Alex.Willmer, muhzi, xdegaye priority: normal severity: normal status: open title: android arm cross compilation fails, h type: compile error versions: Python 3.7 Added file: https://bugs.python.org/file48178/pyconfig.h _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 06:54:53 2019 From: report at bugs.python.org (muhzi) Date: Thu, 28 Feb 2019 11:54:53 +0000 Subject: [issue36145] android arm cross compilation fails, config issue In-Reply-To: <1551354685.49.0.372861646836.issue36145@roundup.psfhosted.org> Message-ID: <1551354893.0.0.356783029052.issue36145@roundup.psfhosted.org> Change by muhzi : ---------- title: android arm cross compilation fails, h -> android arm cross compilation fails, config issue _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 07:00:05 2019 From: report at bugs.python.org (Christian Heimes) Date: Thu, 28 Feb 2019 12:00:05 +0000 Subject: [issue36139] release GIL on mmap dealloc In-Reply-To: <1551290441.84.0.237778309898.issue36139@roundup.psfhosted.org> Message-ID: <1551355205.14.0.386364157936.issue36139@roundup.psfhosted.org> Christian Heimes added the comment: The change sounds like a good idea and should be backported, too. IIRC mmap() performance also depends on MMU and TLB speed. In the past I have seen paravirtualized systems with poor MMU performance that caused fork() to be slow and Redis to hang. ---------- nosy: +christian.heimes, davin versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 07:13:22 2019 From: report at bugs.python.org (Christian Heimes) Date: Thu, 28 Feb 2019 12:13:22 +0000 Subject: [issue29397] linux/random.h present but cannot be compiled In-Reply-To: <1485872500.79.0.0659257887821.issue29397@psf.upfronthosting.co.za> Message-ID: <1551356002.95.0.0106446833408.issue29397@roundup.psfhosted.org> Christian Heimes added the comment: It's a CentOS 5 system with Kernel 2.6.18. The getrandom() syscall was added in Linux Kernel version 3.17. Your OS simply lacks the necessary feature to use linux/random.h. Python will automatically fall back to /dev/urandom. ---------- nosy: +christian.heimes resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 07:32:17 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Feb 2019 12:32:17 +0000 Subject: [issue35975] Put back the ability to parse files where async/await aren't keywords In-Reply-To: <1549931018.54.0.209945896308.issue35975@roundup.psfhosted.org> Message-ID: <1551357137.6.0.64262256563.issue35975@roundup.psfhosted.org> Serhiy Storchaka added the comment: Would not be simpler to just drop the support of Python versions <3.7 in new MyPy versions? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 07:46:01 2019 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 28 Feb 2019 12:46:01 +0000 Subject: [issue36145] android arm cross compilation fails, config issue In-Reply-To: <1551354685.49.0.372861646836.issue36145@roundup.psfhosted.org> Message-ID: <1551357961.42.0.0162383003173.issue36145@roundup.psfhosted.org> Xavier de Gaye added the comment: There is a bug in the implementation of pymonotonic() in Python/pytime.c: The call to pytime_fromtimespec() is not encapsulated by an #ifdef HAVE_CLOCK_GETTIME. @muhzi It seems that your pyconfig.h is generated with configure failing to find the NDK headers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 07:46:23 2019 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 28 Feb 2019 12:46:23 +0000 Subject: [issue36145] android arm cross compilation fails, config issue In-Reply-To: <1551354685.49.0.372861646836.issue36145@roundup.psfhosted.org> Message-ID: <1551357983.37.0.0275783172893.issue36145@roundup.psfhosted.org> Change by Xavier de Gaye : ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 07:55:55 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Feb 2019 12:55:55 +0000 Subject: [issue36134] test failure : test_re; recipe for target 'test' failed In-Reply-To: <1551271074.84.0.0671486163913.issue36134@roundup.psfhosted.org> Message-ID: <1551358555.85.0.344125373779.issue36134@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> test_re is failing when local is set for `en_IN` _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 07:57:28 2019 From: report at bugs.python.org (Inada Naoki) Date: Thu, 28 Feb 2019 12:57:28 +0000 Subject: [issue31652] make install fails: no module _ctypes In-Reply-To: <1506812661.87.0.213398074469.issue31652@psf.upfronthosting.co.za> Message-ID: <1551358648.25.0.761281147284.issue31652@roundup.psfhosted.org> Change by Inada Naoki : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 07:59:54 2019 From: report at bugs.python.org (muhzi) Date: Thu, 28 Feb 2019 12:59:54 +0000 Subject: [issue36145] android arm cross compilation fails, config issue In-Reply-To: <1551354685.49.0.372861646836.issue36145@roundup.psfhosted.org> Message-ID: <1551358794.35.0.675613690392.issue36145@roundup.psfhosted.org> muhzi added the comment: Yes, pretty much so, which I think was what caused the pthread problem. Why would it fail to find the headers? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 08:19:00 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Feb 2019 13:19:00 +0000 Subject: [issue36126] Reference count leakage in structseq_repr In-Reply-To: <1551200997.63.0.481035129926.issue36126@roundup.psfhosted.org> Message-ID: <1551359940.75.0.127342149197.issue36126@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset 69b4a17f342146d6b7a73975a37678db9916aa75 by Serhiy Storchaka (Gao, Xiang) in branch '2.7': bpo-36126: Fix ref count leakage in structseq_repr. (GH-12035) https://github.com/python/cpython/commit/69b4a17f342146d6b7a73975a37678db9916aa75 ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 08:20:19 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Feb 2019 13:20:19 +0000 Subject: [issue36126] Reference count leakage in structseq_repr In-Reply-To: <1551200997.63.0.481035129926.issue36126@roundup.psfhosted.org> Message-ID: <1551360019.88.0.733054664587.issue36126@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- resolution: -> fixed stage: -> resolved status: open -> closed type: behavior -> resource usage _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 08:50:35 2019 From: report at bugs.python.org (Ludovic Gasc) Date: Thu, 28 Feb 2019 13:50:35 +0000 Subject: [issue23794] http package should support HTTP/2 In-Reply-To: <1427479110.25.0.801999785412.issue23794@psf.upfronthosting.co.za> Message-ID: <1551361835.04.0.89151459887.issue23794@roundup.psfhosted.org> Change by Ludovic Gasc : ---------- nosy: -Ludovic.Gasc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 09:05:18 2019 From: report at bugs.python.org (Paul Ganssle) Date: Thu, 28 Feb 2019 14:05:18 +0000 Subject: [issue36145] android arm cross compilation fails, config issue In-Reply-To: <1551354685.49.0.372861646836.issue36145@roundup.psfhosted.org> Message-ID: <1551362718.5.0.341918270885.issue36145@roundup.psfhosted.org> Change by Paul Ganssle : ---------- nosy: +p-ganssle _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 09:46:04 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Thu, 28 Feb 2019 14:46:04 +0000 Subject: [issue36143] Auto-generate Lib/keyword.py In-Reply-To: <1551327070.18.0.354102770805.issue36143@roundup.psfhosted.org> Message-ID: <1551365164.55.0.64937247378.issue36143@roundup.psfhosted.org> Joannah Nanjekye added the comment: I am working on this. Shouldn't there be a PR by tomorrow from me. Someone else can take it on. ---------- nosy: +nanjekyejoannah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 10:01:49 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Feb 2019 15:01:49 +0000 Subject: [issue36143] Auto-generate Lib/keyword.py In-Reply-To: <1551327070.18.0.354102770805.issue36143@roundup.psfhosted.org> Message-ID: <1551366109.63.0.0154339047657.issue36143@roundup.psfhosted.org> Serhiy Storchaka added the comment: Do not haste with this. After implementing pgen in Python, Lib/keyword.py can be generated directly by pgen. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 10:08:07 2019 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 28 Feb 2019 15:08:07 +0000 Subject: [issue36145] android arm cross compilation fails, config issue In-Reply-To: <1551354685.49.0.372861646836.issue36145@roundup.psfhosted.org> Message-ID: <1551366487.21.0.715476698787.issue36145@roundup.psfhosted.org> Xavier de Gaye added the comment: Obviously because you do not tell clang where to find those headers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 10:12:50 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Thu, 28 Feb 2019 15:12:50 +0000 Subject: [issue36143] Auto-generate Lib/keyword.py In-Reply-To: <1551327070.18.0.354102770805.issue36143@roundup.psfhosted.org> Message-ID: <1551366770.02.0.248292703085.issue36143@roundup.psfhosted.org> Joannah Nanjekye added the comment: Noted. Releasing this in favor of when pgen is implemented in Python to solve this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 10:35:52 2019 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 28 Feb 2019 15:35:52 +0000 Subject: [issue36143] Auto-generate Lib/keyword.py In-Reply-To: <1551327070.18.0.354102770805.issue36143@roundup.psfhosted.org> Message-ID: <1551368152.29.0.513347880113.issue36143@roundup.psfhosted.org> Guido van Rossum added the comment: A similar thing seems to be the list of keywords in Lib/pydoc.py. The recipe says # CAUTION: if you change one of these dictionaries, be sure to adapt the # list of needed labels in Doc/tools/extensions/pyspecific.py and # regenerate the pydoc_data/topics.py file by running # make pydoc-topics # in Doc/ and copying the output file into the Lib/ directory. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 10:36:49 2019 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 28 Feb 2019 15:36:49 +0000 Subject: [issue36143] Auto-generate Lib/keyword.py In-Reply-To: <1551327070.18.0.354102770805.issue36143@roundup.psfhosted.org> Message-ID: <1551368209.86.0.658377223229.issue36143@roundup.psfhosted.org> Guido van Rossum added the comment: (However that doesn't seem to work. Anyway, there's a list of all keywords there.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 10:37:34 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 28 Feb 2019 15:37:34 +0000 Subject: [issue36146] Refactor setup.py Message-ID: <1551368254.14.0.622163548129.issue36146@roundup.psfhosted.org> New submission from STINNER Victor : The detect_modules() method of setup.py became longer and longer over the years. It is now 1128 lines long. It's way too long: it becomes very hard to track the lifetime of a variable and many variables are overriden on purpose or not. Shorter functions help to track the lifetime of variables, ease review and reduce the number of bugs. ---------- components: Build messages: 336841 nosy: vstinner priority: normal severity: normal status: open title: Refactor setup.py versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 10:37:51 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 28 Feb 2019 15:37:51 +0000 Subject: [issue36146] Refactor setup.py In-Reply-To: <1551368254.14.0.622163548129.issue36146@roundup.psfhosted.org> Message-ID: <1551368271.2.0.601258953088.issue36146@roundup.psfhosted.org> Change by STINNER Victor : ---------- keywords: +patch pull_requests: +12100 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 10:44:30 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 28 Feb 2019 15:44:30 +0000 Subject: [issue36146] Refactor setup.py In-Reply-To: <1551368254.14.0.622163548129.issue36146@roundup.psfhosted.org> Message-ID: <1551368670.6.0.709674196026.issue36146@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +12101 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 10:47:55 2019 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 28 Feb 2019 15:47:55 +0000 Subject: [issue36143] Auto-generate Lib/keyword.py In-Reply-To: <1551327070.18.0.354102770805.issue36143@roundup.psfhosted.org> Message-ID: <1551368875.14.0.635600817667.issue36143@roundup.psfhosted.org> Guido van Rossum added the comment: Hum, it seems the right solution was to arrange for async and await to appear in the list of keywords despite their special status. Nevertheless in theory there's something that can be done here to auto-regenerate the list derived from the Grammar. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 10:51:02 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Thu, 28 Feb 2019 15:51:02 +0000 Subject: [issue21879] str.format() gives poor diagnostic on placeholder mismatch In-Reply-To: <1404052648.46.0.81950938275.issue21879@psf.upfronthosting.co.za> Message-ID: <1551369062.18.0.705859720541.issue21879@roundup.psfhosted.org> Joannah Nanjekye added the comment: @dmzz, You can convert the patch into a PR on github or Open a PR with your own implementation. If working with this same patch, the next step would be to test the patch if it is still in good shape now before opening a PR. ---------- nosy: +nanjekyejoannah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 10:51:25 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 28 Feb 2019 15:51:25 +0000 Subject: [issue36143] Auto-generate Lib/keyword.py In-Reply-To: <1551327070.18.0.354102770805.issue36143@roundup.psfhosted.org> Message-ID: <1551369085.86.0.790862936949.issue36143@roundup.psfhosted.org> STINNER Victor added the comment: > Do not haste with this. After implementing pgen in Python, Lib/keyword.py can be generated directly by pgen. That's bpo-35808 and PR 11814 which is under review. Anyway, at the end, it would be nice if Lib/keyword.py would be regenerated by "make regen-all". Currently, "regen-all" doesn't regenerate everything. For example, configure is not regenerated. ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 11:05:08 2019 From: report at bugs.python.org (Francisco Couzo) Date: Thu, 28 Feb 2019 16:05:08 +0000 Subject: [issue21879] str.format() gives poor diagnostic on placeholder mismatch In-Reply-To: <1404052648.46.0.81950938275.issue21879@psf.upfronthosting.co.za> Message-ID: <1551369908.22.0.893434216672.issue21879@roundup.psfhosted.org> Francisco Couzo added the comment: I'm preparing the PR myself ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 11:07:48 2019 From: report at bugs.python.org (Christian Heimes) Date: Thu, 28 Feb 2019 16:07:48 +0000 Subject: [issue34631] Upgrade to OpenSSL 1.1.1b In-Reply-To: <1536686026.27.0.0269046726804.issue34631@psf.upfronthosting.co.za> Message-ID: <1551370068.5.0.955902197507.issue34631@roundup.psfhosted.org> Christian Heimes added the comment: Hi macOS and Windows devs, as I explained in https://mail.python.org/pipermail/python-dev/2019-February/156470.html we need to update Python 3.7 to OpenSSL 1.1.1 eventually. 1.1.0 will reach EOL in September. ---------- components: +Windows, macOS nosy: +ned.deily, paul.moore, ronaldoussoren, steve.dower, tim.golden, zach.ware title: Upgrade to OpenSSL 1.1.1 -> Upgrade to OpenSSL 1.1.1b versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 11:11:58 2019 From: report at bugs.python.org (Christian Heimes) Date: Thu, 28 Feb 2019 16:11:58 +0000 Subject: [issue34631] Upgrade to OpenSSL 1.1.1b In-Reply-To: <1536686026.27.0.0269046726804.issue34631@psf.upfronthosting.co.za> Message-ID: <1551370318.96.0.758069138199.issue34631@roundup.psfhosted.org> Change by Christian Heimes : ---------- keywords: +patch pull_requests: +12102 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 11:21:02 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 28 Feb 2019 16:21:02 +0000 Subject: [issue36144] Dictionary addition. In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org> Message-ID: <1551370862.24.0.128239330719.issue36144@roundup.psfhosted.org> Josh Rosenberg added the comment: scoder: dict(X, **M) is broken unless M is known to be string keyed (it used to work, but in Python 3, it will raise a TypeError). It's part of the argument for the additional unpacking generalizations from PEP 448; {**X, **M} does what dict(X, **M) is trying to do, but without abusing the keyword argument passing convention. You also claim "It takes me a while to see the dict merge under that heap of stars", but that's at least as much about the newness of PEP 448 (and for many Python coders, a complete lack of familiarity with the pre-existing varargs unpacking rules for functions) as it is about the punctuation; after all, you clearly recognize dict(X, **M) even though it's been wrong in most contexts for years. In any event, I'm a strong -1 on this, for largely the same reasons as Raymond and others: 1. It doesn't provide any new functionality, just one more way to do it; += is satisfied by .update, + is satisfied (more generally and efficiently) by the unpacking generalizations 2. It's needlessly confusing; addition is, for all existing types in the standard library I can think of, lossless; the information from both sides of the + is preserved in some form, either by addition or concatenation (and in the concatenation case, addition is happening, just to the length of the resulting sequence, and order is preserved). Addition for dictionaries would introduce new rules specific to dicts that do not exist for any other type regarding loss of values, non-additive resulting length, etc. Those rules would likely be similar to those of dict literals and the update method, but they'd need to be made explicit. By contrast, the PEP 448 unpacking generalization rules followed the existing rules for dict literals; no special rules occur, it just behaves intuitively (if you already knew the rules for dict literals without unpacking being involved). 3. Almost any generic, duck-typing based code for which addition makes sense will not make sense for dicts simply because it loosens the definition of addition too much to be useful, so best case, it still raises TypeError (when dicts added to non-dict things), worst case, it silently operates in a way that violates the rules of both addition and concatenation rather than raising a TypeError that the generic code could use to determine the correct thing to do. 4. The already mentioned conflict with Counter (which already has an addition operator, with lossless semantics) 5. (Minor) It means PyDict_Type needs a non-NULL tp_as_number, so now it's slightly slower to reject dicts as being non-numeric at the C layer Problem #2 could be used to argue for allowing | instead of + (which would also resolve #4, and parts of #3), since | is already used for unioning with sets, and this operation is much closer to a union operation than addition or concatenation. Even so, it would still be misleading; at least with sets, there is no associated value, so it's still mostly lossless (you lose the input lengths, but the unique input data is kept); with dicts, you'd be losing values too. Basically, I think the PEP 448 unpacking syntax should remain as the "one-- and preferably only one --obvious way to" combine dictionaries as a one-liner. It's more composable, since it allows adding arbitrary additional key/value pairs, and more efficient, since it allows combining more than two dicts at once with no additional temporaries: dicta + dictb + dictc requires "dictab" to be made first, then thrown away after dictab + dictc produces dictabc, while {**dicta, **dictb, **dictc} builds dictabc directly. The only real argument I can see for not sticking to unpacking is that it doesn't allow for arbitrary dict-like things to produce new dict-like things directly; you'd have to rewrap as myspecialdict({**speciala, **specialb}). But I don't think that's a flaw worth fixing if it means major changes to the behavior of what I'm guessing is one of the three most commonly used types in Python (along with int and tuple, thanks to the integration of dicts into so many facets of the implementation). ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 11:34:00 2019 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 28 Feb 2019 16:34:00 +0000 Subject: [issue36144] Dictionary addition. In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org> Message-ID: <1551371640.18.0.0194083342553.issue36144@roundup.psfhosted.org> Guido van Rossum added the comment: I changed my mind and am now in favor. Most of the arguments against could also be used against list+list. Counter addition is actually a nice special case of this -- it produces the same keys but has a more sophisticated way of merging values for common keys. Please read the python-ideas thread! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 11:42:22 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 28 Feb 2019 16:42:22 +0000 Subject: [issue36144] Dictionary addition. In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org> Message-ID: <1551372142.36.0.533596511934.issue36144@roundup.psfhosted.org> Josh Rosenberg added the comment: Also note: That Python ideas thread that xtreak linked ( https://mail.python.org/pipermail/python-ideas/2015-February/031748.html ) largely rejected the proposal a couple weeks before PEP 448 was approved. At the time, the proposal wasn't just about +/+=; that was the initial proposal, but operator overloading was heavily criticized for the failure to adhere to either addition or concatenation semantics, so alternate constructors and top-level functions similar to sorted were proposed as alternatives (e.g. merged(dicta, dictb)). The whole thread ended up being about creating an approved, built-in way of one-lining: d3 = d1.copy(); d3.update(d2) A key quote though is that this was needed because there was no other option without rolling your own merged function. Andrew Barnert summarized it best: "I'm +1 on constructor, +0.5 on a function (whether it's called updated or merged, whether it's in builtins or collections), +0.5 on both constructor and function, -0.5 on a method, and -1 on an operator. "Unless someone is seriously championing PEP 448 for 3.5, in which case I'm -0.5 on anything, because it looks like PEP 448 would already give us one obvious way to do it, and none of the alternatives are sufficiently nicer than that way to be worth having another." As it happens, PEP 448 was put in 3.5, and we got the one obvious way to do it. Side-note: It occurs to me there will be one more "way to do it" in 3.8 already, thanks to PEP 572: (d3 := d1.copy()).update(d2) I think I'll stick with d3 = {**d1, **d2} though. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 11:44:16 2019 From: report at bugs.python.org (Dusan Gligoric) Date: Thu, 28 Feb 2019 16:44:16 +0000 Subject: [issue6766] Cannot modify dictionaries inside dictionaries using Managers from multiprocessing In-Reply-To: <1251049590.58.0.809281249474.issue6766@psf.upfronthosting.co.za> Message-ID: <1551372256.32.0.966067045923.issue6766@roundup.psfhosted.org> Dusan Gligoric <7six at protonmail.com> added the comment: Hey folks, This is still an issue with 3.7.2 =============================================== # Python 3.7.2 (default, Jan 10 2019, 23:51:51) # [GCC 8.2.1 20181127] on linux from multiprocessing import Manager manager = Manager() d = manager.dict({}) d["test"] = {"a": 123} # update fails d["test"]["a"] = 321 # add fails d["test"]["b"] = 321 print(d) ---------- nosy: +dusan76 versions: +Python 3.7 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 11:48:42 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 28 Feb 2019 16:48:42 +0000 Subject: [issue36146] Refactor setup.py In-Reply-To: <1551368254.14.0.622163548129.issue36146@roundup.psfhosted.org> Message-ID: <1551372522.87.0.0534611502181.issue36146@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 4cbea518a0827d23a41a45b03a8af729c2f16605 by Victor Stinner in branch 'master': bpo-36146: Refactor setup.py (GH-12093) https://github.com/python/cpython/commit/4cbea518a0827d23a41a45b03a8af729c2f16605 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 11:54:52 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 28 Feb 2019 16:54:52 +0000 Subject: [issue36018] Add a Normal Distribution class to the statistics module In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org> Message-ID: <1551372892.96.0.0310828090768.issue36018@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- pull_requests: +12103 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 12:02:43 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 28 Feb 2019 17:02:43 +0000 Subject: [issue36146] Refactor setup.py In-Reply-To: <1551368254.14.0.622163548129.issue36146@roundup.psfhosted.org> Message-ID: <1551373363.07.0.874322630669.issue36146@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +12104 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 12:12:40 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 28 Feb 2019 17:12:40 +0000 Subject: [issue36146] Refactor setup.py In-Reply-To: <1551368254.14.0.622163548129.issue36146@roundup.psfhosted.org> Message-ID: <1551373960.73.0.837330389181.issue36146@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +12105 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 12:16:27 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 28 Feb 2019 17:16:27 +0000 Subject: [issue36018] Add a Normal Distribution class to the statistics module In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org> Message-ID: <1551374187.73.0.0443801078547.issue36018@roundup.psfhosted.org> miss-islington added the comment: New changeset ef17fdbc1c274dc84c2f611c40449ab84824607e by Miss Islington (bot) (Raymond Hettinger) in branch 'master': bpo-36018: Add special value tests and make minor tweaks to the docs (GH-12096) https://github.com/python/cpython/commit/ef17fdbc1c274dc84c2f611c40449ab84824607e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 12:27:51 2019 From: report at bugs.python.org (Steve Dower) Date: Thu, 28 Feb 2019 17:27:51 +0000 Subject: [issue33944] Deprecate and remove pth files In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za> Message-ID: <1551374871.7.0.994355708941.issue33944@roundup.psfhosted.org> Steve Dower added the comment: > But think of the poor user who doesn?t have that expertise or ability to hack on an installed Python?s site.py file. This is actually part of the thinking behind the reportabug tool I started (and why when you format it as raw text you get the listing of everything in any directory on sys.path - mostly because I haven't added a Markdown rendering of that). If the answer is to enhance that and tell users "run `reportabug mybrokenmodule` and send me the output", well, that's why I put it on GitHub :) https://github.com/zooba/reportabug I see no reason to hold up adding pth logging to -v, so anyone interested please feel free to do a PR. The only reason I see to hold up PE 10131 (docs update) is because it documents the rationale for using arbitrary code execution in a pth file. Since we clearly want to get rid of it, I don't think we should in any way rationalize it in the docs. Once these are done, I think we'll have to reevaluate whether .pth files are actually a problem in their normal behavior, and whether the benefit outweighs the cost. But since we're all agreed that they aren't easy to debug and contain features we all want to get rid of, there's not much point using the current state to do the cost/benefit analysis. Let's fix the bits we can fix first and then see where we stand. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 12:30:25 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 28 Feb 2019 17:30:25 +0000 Subject: [issue36144] Dictionary addition. In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org> Message-ID: <1551375025.51.0.988781081784.issue36144@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Current python-ideas thread for the issue : https://mail.python.org/pipermail/python-ideas/2019-February/055509.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 12:34:12 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 28 Feb 2019 17:34:12 +0000 Subject: [issue29571] test_re is failing when local is set for `en_IN` In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za> Message-ID: <1551375252.75.0.237404209212.issue29571@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +12106 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 12:34:31 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 28 Feb 2019 17:34:31 +0000 Subject: [issue29571] test_re is failing when local is set for `en_IN` In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za> Message-ID: <1551375271.56.0.263764017823.issue29571@roundup.psfhosted.org> STINNER Victor added the comment: Ah, I can reproduce the bug on Fedora 29 using "LANG=en_IN ./python -m test -v test_re". The problem is that locale.getlocale() is not reliable: it pretends that the locale encoding is ISO8859-1, whereas the real encoding is UTF-8: $ LANG=en_IN ./python Python 3.8.0a2+ (heads/master:4cbea518a0, Feb 28 2019, 18:19:44) >>> chr(224).encode('ISO8859-1') b'\xe0' >>> import _testcapi >>> _testcapi.DecodeLocaleEx(b'\xe0', 0, 'strict') Traceback (most recent call last): File "", line 1, in RuntimeError: decode error: pos=0, reason=decoding error >>> import locale # Wrong encoding >>> locale.getlocale(locale.LC_CTYPE) ('en_IN', 'ISO8859-1') >>> locale.setlocale(locale.LC_CTYPE, None) 'en_IN' >>> locale._parse_localename('en_IN') ('en_IN', 'ISO8859-1') # Real encoding >>> locale.getpreferredencoding() 'UTF-8' >>> locale.nl_langinfo(locale.CODESET) 'UTF-8' Attached PR 12099 fix the issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 12:40:16 2019 From: report at bugs.python.org (Anthony Sottile) Date: Thu, 28 Feb 2019 17:40:16 +0000 Subject: [issue33944] Deprecate and remove pth files In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za> Message-ID: <1551375616.83.0.524645842496.issue33944@roundup.psfhosted.org> Anthony Sottile added the comment: > contain features we all want to get rid of I don't think even this is unanimous. Things like registering codecs, instrumenting coverage in subprocesses, etc. all seem like legitimate uses of the arbitrary code execution feature ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 12:42:14 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 28 Feb 2019 17:42:14 +0000 Subject: [issue36131] test.test_urllib2net.TimeoutTest ftp related tests fail due to ftp://www.pythontest.net/ being unavailable In-Reply-To: <1551243962.9.0.321127985724.issue36131@roundup.psfhosted.org> Message-ID: <1551375734.82.0.0347443580737.issue36131@roundup.psfhosted.org> STINNER Victor added the comment: I discussed with Ernest on #python-infra. It was an issue with the DNS "resolving the host back to 127.0.1.1 (...) so vsftpd is telling users to connect back to themselves". ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 12:52:38 2019 From: report at bugs.python.org (Charalampos Stratakis) Date: Thu, 28 Feb 2019 17:52:38 +0000 Subject: [issue13096] ctypes: segfault with large POINTER type names In-Reply-To: <1317700059.13.0.375039668353.issue13096@psf.upfronthosting.co.za> Message-ID: <1551376358.86.0.800302982691.issue13096@roundup.psfhosted.org> Change by Charalampos Stratakis : ---------- pull_requests: +12107 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 12:53:00 2019 From: report at bugs.python.org (Charalampos Stratakis) Date: Thu, 28 Feb 2019 17:53:00 +0000 Subject: [issue13096] ctypes: segfault with large POINTER type names In-Reply-To: <1317700059.13.0.375039668353.issue13096@psf.upfronthosting.co.za> Message-ID: <1551376380.13.0.735300535369.issue13096@roundup.psfhosted.org> Charalampos Stratakis added the comment: It seems the python2 backport was incomplete as a PyMem_Free is missing, making buf leak. ---------- nosy: +cstratak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 12:53:21 2019 From: report at bugs.python.org (Charalampos Stratakis) Date: Thu, 28 Feb 2019 17:53:21 +0000 Subject: [issue13096] ctypes: segfault with large POINTER type names In-Reply-To: <1317700059.13.0.375039668353.issue13096@psf.upfronthosting.co.za> Message-ID: <1551376401.78.0.853480993121.issue13096@roundup.psfhosted.org> Change by Charalampos Stratakis : ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 13:03:20 2019 From: report at bugs.python.org (Charalampos Stratakis) Date: Thu, 28 Feb 2019 18:03:20 +0000 Subject: [issue36147] [2.7] Coverity scan: Modules/_ctypes/cfield.c , Variable "result" going out of scope Message-ID: <1551377000.6.0.726806174953.issue36147@roundup.psfhosted.org> New submission from Charalampos Stratakis : Coverity scan on python2 resulted in this error. Python-2.7.15/Modules/_ctypes/cfield.c:1297: alloc_fn: Storage is returned from allocation function "PyString_FromString". Python-2.7.15/Objects/stringobject.c:143:5: alloc_fn: Storage is returned from allocation function "PyObject_Malloc". Python-2.7.15/Objects/obmalloc.c:982:5: alloc_fn: Storage is returned from allocation function "malloc". Python-2.7.15/Objects/obmalloc.c:982:5: return_alloc_fn: Directly returning storage allocated by "malloc". Python-2.7.15/Objects/stringobject.c:143:5: var_assign: Assigning: "op" = "PyObject_Malloc(37UL + size)". Python-2.7.15/Objects/stringobject.c:164:5: return_alloc: Returning allocated memory "op". Python-2.7.15/Modules/_ctypes/cfield.c:1297: var_assign: Assigning: "result" = storage returned from "PyString_FromString((char *)ptr)". Python-2.7.15/Modules/_ctypes/cfield.c:1311: leaked_storage: Variable "result" going out of scope leaks the storage it points to. 1309| } else 1310| /* cannot shorten the result */ 1311|-> return PyString_FromStringAndSize(ptr, size); 1312| } 1313| This was fixed on python3 with https://github.com/python/cpython/commit/19b52545df898ec911c44e29f75badb902924c0b Partially backporting this change for this file should fix the issue. ---------- components: Extension Modules messages: 336859 nosy: cstratak, vstinner priority: normal severity: normal status: open title: [2.7] Coverity scan: Modules/_ctypes/cfield.c , Variable "result" going out of scope versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 13:04:08 2019 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 28 Feb 2019 18:04:08 +0000 Subject: [issue33944] Deprecate and remove pth files In-Reply-To: <1551375616.83.0.524645842496.issue33944@roundup.psfhosted.org> Message-ID: Barry A. Warsaw added the comment: On Feb 28, 2019, at 09:40, Anthony Sottile wrote: > > I don't think even this is unanimous. Things like registering codecs, instrumenting coverage in subprocesses, etc. all seem like legitimate uses of the arbitrary code execution feature Except pth files are a terrible interface for that, given all the other problems, including weird wall-of-code inducing restrictions on what actually gets executed. I?m in agreement with Steve Dower in principle here. I would like to see a solution that deprecates and eventually removes arbitrary code execution in pth files, leaves sys.path extension alone (for now ), and improves the discoverability and debuggability of magical pth files. What I think Anthony is looking for are ways to register ?start up functions? that get executed automatically when the Python interpreter starts up. Perhaps somewhat analogous to atexit functions? But if we?re going to officially support a feature like that, I think a PEP would be the right vehicle to suss out all the gory details, like, should these things be global across all invocations of the interpreter, how a user or application would disable that, how would bugs in start up functions get discovered, reported, and debugged, what if any execution order guarantees should be made, etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 13:10:18 2019 From: report at bugs.python.org (Charalampos Stratakis) Date: Thu, 28 Feb 2019 18:10:18 +0000 Subject: [issue36147] [2.7] Coverity scan: Modules/_ctypes/cfield.c , Variable "result" going out of scope In-Reply-To: <1551377000.6.0.726806174953.issue36147@roundup.psfhosted.org> Message-ID: <1551377418.82.0.396215807293.issue36147@roundup.psfhosted.org> Charalampos Stratakis added the comment: Also the change from PyUnicode_FromStringAndSize to PyBytes_FromStringAndSize happened here: https://bugs.python.org/issue8966 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 13:10:46 2019 From: report at bugs.python.org (daniel hahler) Date: Thu, 28 Feb 2019 18:10:46 +0000 Subject: [issue35931] pdb: "debug print(" crashes with SyntaxError In-Reply-To: <1549555371.45.0.73616044825.issue35931@roundup.psfhosted.org> Message-ID: <1551377446.27.0.00527364708502.issue35931@roundup.psfhosted.org> daniel hahler added the comment: Re-opening: it currently still crashes with a NameError when using "debug doesnotexist", or "debug doesnotexist()". Will create a new PR for this. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 13:11:01 2019 From: report at bugs.python.org (Charalampos Stratakis) Date: Thu, 28 Feb 2019 18:11:01 +0000 Subject: [issue36147] [2.7] Coverity scan: Modules/_ctypes/cfield.c , Variable "result" going out of scope In-Reply-To: <1551377000.6.0.726806174953.issue36147@roundup.psfhosted.org> Message-ID: <1551377461.8.0.292194973601.issue36147@roundup.psfhosted.org> Change by Charalampos Stratakis : ---------- keywords: +patch pull_requests: +12108 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 13:25:39 2019 From: report at bugs.python.org (Anthony Sottile) Date: Thu, 28 Feb 2019 18:25:39 +0000 Subject: [issue33944] Deprecate and remove pth files In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za> Message-ID: <1551378339.36.0.0336805607153.issue33944@roundup.psfhosted.org> Anthony Sottile added the comment: > What I think Anthony is looking for are ways to register ?start up functions? that get executed automatically when the Python interpreter starts up yes, this is what I want to still exist :) my hope is that there's a clear standards-track replacement *before* deprecating .pth (which currently satisfies my usecases for startup functions) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 13:25:55 2019 From: report at bugs.python.org (daniel hahler) Date: Thu, 28 Feb 2019 18:25:55 +0000 Subject: [issue35931] pdb: "debug print(" crashes with SyntaxError In-Reply-To: <1549555371.45.0.73616044825.issue35931@roundup.psfhosted.org> Message-ID: <1551378355.39.0.291785918395.issue35931@roundup.psfhosted.org> Change by daniel hahler : ---------- pull_requests: +12109 stage: resolved -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 13:35:43 2019 From: report at bugs.python.org (sls) Date: Thu, 28 Feb 2019 18:35:43 +0000 Subject: [issue36148] smtplib.SMTP.sendmail: mta status codes only accessible by local variables Message-ID: <1551378943.89.0.92811496764.issue36148@roundup.psfhosted.org> New submission from sls : MTA status codes (visible via setdebuglevel(1)) are not accessible as the `sendmail`-method stores them only locally (code, resp). I suggest to store the mta status codes, for instance: "250, b'2.0.0 Ok: queued as XYZ" etc. in an instance attribute (tuple) to access them on smtp-sessions. As an email developer those information are very important to me. ---------- components: Library (Lib) messages: 336864 nosy: sls priority: normal severity: normal status: open title: smtplib.SMTP.sendmail: mta status codes only accessible by local variables type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 13:45:18 2019 From: report at bugs.python.org (Thomas Wouters) Date: Thu, 28 Feb 2019 18:45:18 +0000 Subject: [issue36149] use of uninitialised memory in cPickle. Message-ID: <1551379518.13.0.26926379608.issue36149@roundup.psfhosted.org> New submission from Thomas Wouters : There is a bug in cPickle that makes it use uninitialised memory when reading a truncated pickle from a file (an actual C FILE*, not just any file-like object). Using MemorySanitizer: % ./python Python 2.7.15 (default, redacted, redacted) [GCC 4.2.1 Compatible Clang (redacted)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import tempfile, cPickle >>> f = tempfile.TemporaryFile() >>> f.write('F') >>> f.seek(0) >>> cPickle.load(f) Uninitialized bytes in __interceptor_strlen at offset 1 inside [0x701000001b50, 3) ==23453==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x561a9110d51b in PyString_FromFormatV Objects/stringobject.c:241:22 #1 0x561a912ba454 in PyErr_Format Python/errors.c:567:14 #2 0x561a91303bc8 in PyOS_string_to_double Python/pystrtod.c #3 0x561a90b4a7d7 in load_float Modules/cPickle.c:3618:9 #4 0x561a90b48ca7 in load Modules/cPickle.c:4779:17 #5 0x561a90b56d9c in cpm_load Modules/cPickle.c:5758:11 #6 0x561a91260b89 in call_function Python/ceval.c:4379:17 The problem is Modules/cPickle:readline_file end-of-file handling logic: for (; i < (self->buf_size - 1); i++) { if (feof(self->fp) || (self->buf[i] = getc(self->fp)) == '\n') { self->buf[i + 1] = '\0'; *s = self->buf; return i + 1; } } When feof(self->pf) becomes true, the code skips over writing to self->buf[i] (which hasn't been written to yet), only writes to self->buf[i+1], and returns self->buf. There is an additional problem that the code fails to check for the EOF return of getc(), which means it may write EOF-cast-to-a-char to self->buf[i] without realising it's meant to be an EOF. (EOF is usually -1, but I don't remember if that's a valid cast or undefined behaviour.) Theoretically this could cause invalid, truncated pickles to be read succesfully, but with the wrong value for the last item. (It could perhaps do even worse things with files that change while cPickle is reading them, but that's harder to reason about.) (Use of uninitialised memory is a potential security issue, although so is using pickles, so I'm conflicted about the bug type...) ---------- components: Interpreter Core messages: 336865 nosy: twouters priority: normal severity: normal status: open title: use of uninitialised memory in cPickle. type: security versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 13:51:21 2019 From: report at bugs.python.org (sls) Date: Thu, 28 Feb 2019 18:51:21 +0000 Subject: [issue36148] smtplib.SMTP.sendmail: mta status codes only accessible by local variables In-Reply-To: <1551378943.89.0.92811496764.issue36148@roundup.psfhosted.org> Message-ID: <1551379881.33.0.421783913226.issue36148@roundup.psfhosted.org> Change by sls : ---------- keywords: +patch pull_requests: +12111 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 13:56:40 2019 From: report at bugs.python.org (Thomas Wouters) Date: Thu, 28 Feb 2019 18:56:40 +0000 Subject: [issue36149] use of uninitialised memory in cPickle. In-Reply-To: <1551379518.13.0.26926379608.issue36149@roundup.psfhosted.org> Message-ID: <1551380200.99.0.0955070188634.issue36149@roundup.psfhosted.org> Change by Thomas Wouters : ---------- keywords: +patch pull_requests: +12112 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 14:00:57 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 28 Feb 2019 19:00:57 +0000 Subject: [issue36148] smtplib.SMTP.sendmail: mta status codes only accessible by local variables In-Reply-To: <1551378943.89.0.92811496764.issue36148@roundup.psfhosted.org> Message-ID: <1551380457.59.0.0372686539057.issue36148@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- components: +email nosy: +barry, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 14:13:41 2019 From: report at bugs.python.org (Zackery Spytz) Date: Thu, 28 Feb 2019 19:13:41 +0000 Subject: [issue36150] Possible assertion failures due to _ctypes.c's PyCData_reduce() Message-ID: <1551381221.9.0.581708361836.issue36150@roundup.psfhosted.org> New submission from Zackery Spytz : The PyBytes_FromStringAndSize() and PyObject_GetAttrString() calls in PyCData_reduce() are not checked for failure. ---------- components: Extension Modules, ctypes messages: 336866 nosy: ZackerySpytz priority: normal severity: normal status: open title: Possible assertion failures due to _ctypes.c's PyCData_reduce() type: crash versions: Python 2.7, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 14:16:27 2019 From: report at bugs.python.org (Zackery Spytz) Date: Thu, 28 Feb 2019 19:16:27 +0000 Subject: [issue36150] Possible assertion failures due to _ctypes.c's PyCData_reduce() In-Reply-To: <1551381221.9.0.581708361836.issue36150@roundup.psfhosted.org> Message-ID: <1551381387.91.0.88117455287.issue36150@roundup.psfhosted.org> Change by Zackery Spytz : ---------- keywords: +patch pull_requests: +12113 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 15:26:54 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Feb 2019 20:26:54 +0000 Subject: [issue36150] Possible assertion failures due to _ctypes.c's PyCData_reduce() In-Reply-To: <1551381221.9.0.581708361836.issue36150@roundup.psfhosted.org> Message-ID: <1551385614.07.0.56442714372.issue36150@roundup.psfhosted.org> Serhiy Storchaka added the comment: Does not Py_BuildValue() check the argument for "N" for NULL? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 16:07:43 2019 From: report at bugs.python.org (Aiden Zhou) Date: Thu, 28 Feb 2019 21:07:43 +0000 Subject: [issue36151] Incorrect answer when calculating 11//3 Message-ID: <1551388063.52.0.300657450058.issue36151@roundup.psfhosted.org> New submission from Aiden Zhou : When calculating 11//3, the last digit of the decimals is wrongly rounded to 5 as obviously it needs to be rounded to 7. IDLE (Python 3.7 32-bit) ---------- assignee: terry.reedy components: IDLE files: Screenshot (102)_LI.jpg messages: 336868 nosy: azihdoeun, terry.reedy priority: normal severity: normal status: open title: Incorrect answer when calculating 11//3 type: behavior versions: Python 3.7 Added file: https://bugs.python.org/file48179/Screenshot (102)_LI.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 16:08:47 2019 From: report at bugs.python.org (Aiden Zhou) Date: Thu, 28 Feb 2019 21:08:47 +0000 Subject: [issue36151] Incorrect answer when calculating 11//3 In-Reply-To: <1551388063.52.0.300657450058.issue36151@roundup.psfhosted.org> Message-ID: <1551388127.43.0.579107808241.issue36151@roundup.psfhosted.org> Change by Aiden Zhou : Added file: https://bugs.python.org/file48180/Screenshot (102)_LI.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 16:09:58 2019 From: report at bugs.python.org (Aiden Zhou) Date: Thu, 28 Feb 2019 21:09:58 +0000 Subject: [issue36151] Incorrect answer when calculating 11//3 In-Reply-To: <1551388063.52.0.300657450058.issue36151@roundup.psfhosted.org> Message-ID: <1551388198.58.0.463140264081.issue36151@roundup.psfhosted.org> Change by Aiden Zhou : Removed file: https://bugs.python.org/file48180/Screenshot (102)_LI.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 16:20:37 2019 From: report at bugs.python.org (Zachary Ware) Date: Thu, 28 Feb 2019 21:20:37 +0000 Subject: [issue36151] Incorrect answer when calculating 11/3 In-Reply-To: <1551388063.52.0.300657450058.issue36151@roundup.psfhosted.org> Message-ID: <1551388837.39.0.302553004478.issue36151@roundup.psfhosted.org> Zachary Ware added the comment: This has nothing to do with IDLE and everything to do with how floating point numbers work; have a read through https://docs.python.org/3/tutorial/floatingpoint.html for an introduction to floating point. If you need exact decimal math, use the `decimal` module instead. ---------- assignee: terry.reedy -> components: -IDLE nosy: +zach.ware resolution: -> not a bug stage: -> resolved status: open -> closed title: Incorrect answer when calculating 11//3 -> Incorrect answer when calculating 11/3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 16:36:33 2019 From: report at bugs.python.org (Christian Heimes) Date: Thu, 28 Feb 2019 21:36:33 +0000 Subject: [issue36150] Possible assertion failures due to _ctypes.c's PyCData_reduce() In-Reply-To: <1551381221.9.0.581708361836.issue36150@roundup.psfhosted.org> Message-ID: <1551389793.5.0.368425670933.issue36150@roundup.psfhosted.org> Christian Heimes added the comment: Yes, N and O accept NULL and pass the exception up the call stack. It's not a bug. https://docs.python.org/3/c-api/arg.html?highlight=py_buildvalue#c.Py_BuildValue ---------- nosy: +christian.heimes resolution: -> not a bug stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 16:36:34 2019 From: report at bugs.python.org (R. David Murray) Date: Thu, 28 Feb 2019 21:36:34 +0000 Subject: [issue36148] smtplib.SMTP.sendmail: mta status codes only accessible by local variables In-Reply-To: <1551378943.89.0.92811496764.issue36148@roundup.psfhosted.org> Message-ID: <1551389794.82.0.766161812055.issue36148@roundup.psfhosted.org> R. David Murray added the comment: Thanks for the PR, but this is a duplicate of #29539, which I think has a better API proposal. Since the original author never actually submitted a PR there, perhaps you could pick up his work (after pinging the issue). ---------- resolution: -> duplicate stage: patch review -> resolved status: open -> closed superseder: -> Deprecate string concatenation without plus versions: +Python 3.8 -Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 16:37:53 2019 From: report at bugs.python.org (R. David Murray) Date: Thu, 28 Feb 2019 21:37:53 +0000 Subject: [issue36148] smtplib.SMTP.sendmail: mta status codes only accessible by local variables In-Reply-To: <1551378943.89.0.92811496764.issue36148@roundup.psfhosted.org> Message-ID: <1551389873.04.0.496507359412.issue36148@roundup.psfhosted.org> R. David Murray added the comment: Sorry, that should be #29539. ---------- superseder: Deprecate string concatenation without plus -> [smtplib] collect response data for all recipients _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 16:39:13 2019 From: report at bugs.python.org (R. David Murray) Date: Thu, 28 Feb 2019 21:39:13 +0000 Subject: [issue29539] [smtplib] collect response data for all recipients In-Reply-To: <1486946725.6.0.180199923995.issue29539@psf.upfronthosting.co.za> Message-ID: <1551389953.52.0.387454670374.issue29539@roundup.psfhosted.org> Change by R. David Murray : ---------- nosy: +sls _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 17:08:47 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 28 Feb 2019 22:08:47 +0000 Subject: [issue36151] Incorrect answer when calculating 11/3 In-Reply-To: <1551388063.52.0.300657450058.issue36151@roundup.psfhosted.org> Message-ID: <1551391727.36.0.0496614962754.issue36151@roundup.psfhosted.org> Terry J. Reedy added the comment: To add to Zach's answer: Please do not mark issues for IDLE just because you use IDLE to send your code to Python and display the returned string answer. If in any doubt, rerun the same code directly with Python either interactively or from the command line. (Note: Windows requires "", not '', on command line.) C:\Users\Terry>python -c "print(11/3)" 3.6666666666666665 As for the result: 11/3 cannot be exactly represented as a binary (or decimal) finite-precision floating point number. In this case, the nearest binary float is less that 11/3. Python prints floats with up to 17 decimal digits. We can get more with the decimal module. >>> decimal.Decimal(11/3) Decimal('3.666666666666666518636930049979127943515777587890625') We can also check with decimal float literals >>> 11/3 == 3.6666666666666665) True This expression is true for all 18 digit literals from 3.66666666666666630 to 3.66666666666666674 It would have been better to ask about 11/3 on python-list (for instance), where other beginners could see the answer, rather than here. I will repost my answer there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 17:20:35 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Thu, 28 Feb 2019 22:20:35 +0000 Subject: [issue36151] Incorrect answer when calculating 11/3 In-Reply-To: <1551388063.52.0.300657450058.issue36151@roundup.psfhosted.org> Message-ID: <1551392435.02.0.272958451894.issue36151@roundup.psfhosted.org> Steven D'Aprano added the comment: Aiden: in the future, please do not post unnecessary screenshots of text. They are hostile to the blind and slight-impaired, they make it impossible to copy your code and run it ourselves, and they cannot be searched for. Instead, copy and paste the text demonstrating the code and the results: py> 11/3 3.6666666666666665 Thank you. Zachary: while the rest of your comments were excellent, please don't tell people that Decimal is "exact". Decimal is a floating point format just like floats are, and so suffers the same kinds of rounding errors as binary floats. In fact, Decimal often suffers from larger rounding errors than binary, which is why serious numeric data scientists still use binary float. The advantages of Decimal over binary float is that you can configure how much precision is used, and that any number you can write out exactly in base 10 can be represented exactly as a Decimal. But it still has to round off values which cannot be represented exactly as Decimals. ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 17:24:18 2019 From: report at bugs.python.org (Ivan Pozdeev) Date: Thu, 28 Feb 2019 22:24:18 +0000 Subject: [issue33944] Deprecate and remove pth files In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za> Message-ID: <1551392658.01.0.739285930871.issue33944@roundup.psfhosted.org> Change by Ivan Pozdeev : ---------- pull_requests: +12114 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 17:27:55 2019 From: report at bugs.python.org (Ivan Pozdeev) Date: Thu, 28 Feb 2019 22:27:55 +0000 Subject: [issue33944] Deprecate and remove pth files In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za> Message-ID: <1551392875.66.0.390930978345.issue33944@roundup.psfhosted.org> Ivan Pozdeev added the comment: On second thought, the inability to debug code that runs at startup, before user code ever gets control, is a fundamental issue (this problem arises for any software that has startup code), so such a facility in stock codebase has a merit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 17:47:45 2019 From: report at bugs.python.org (sls) Date: Thu, 28 Feb 2019 22:47:45 +0000 Subject: [issue29539] [smtplib] collect response data for all recipients In-Reply-To: <1486946725.6.0.180199923995.issue29539@psf.upfronthosting.co.za> Message-ID: <1551394065.72.0.357705470027.issue29539@roundup.psfhosted.org> sls added the comment: Did you make a PR ? I didn't notice this issue and did a quick fix: https://github.com/python/cpython/pull/12104 I was hoping this or similar fixes would be implemented in 3.7.x Anyways. I'd suggest to return both success and errors for each recipient. sendmail returns a dict already. Why not adding each status? Maybe using something like "mta_result" as variable instead of senderrs, which is in my opinion more clear to understand. Also, this would have the advantage to parse the return value easily and you're able to access more verbose information like mta msg id and so on. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 18:05:44 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 28 Feb 2019 23:05:44 +0000 Subject: [issue29571] test_re is failing when local is set for `en_IN` In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za> Message-ID: <1551395144.26.0.557817599941.issue29571@roundup.psfhosted.org> STINNER Victor added the comment: > This seems to have broken test_re on Windows, see https://ci.appveyor.com/project/python/cpython/build/3.7.0a0.1 It seems like the ANSI code page is 1252 ("cp1252"). == CPython 3.7.0a0 (master:d31b28e16a2387d0251df948ef5d1b33d4357652, Mar 5 2017, 21:47:06) [MSC v.1900 32 bit (Intel)] == Windows-2012ServerR2-6.3.9600-SP0 little-endian == hash algorithm: siphash24 32bit == cwd: C:\projects\cpython\build\test_python_1844 == encodings: locale=cp1252, FS=utf-8 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=1, verbose=0, bytes_warning=2, quiet=0, hash_randomization=1, isolated=0) Using random seed 5949816 ... FAIL: test_locale_flag (test.test_re.ReTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\projects\cpython\lib\test\test_re.py", line 1422, in test_locale_flag self.assertTrue(pat.match(bletter)) AssertionError: None is not true > getpreferredencoding() takes a completely different path on windows > (returns a codepage) and isn't related to the C locale. On my Windows 10 with Python 3.8, getpreferredencoding() (and getpreferredencoding(False)) returns "cp1252", getlocale(LC_CTYPE)[1] returns "1252". Python has an alias "1252" for "cp1252". On Windows, getpreferredencoding() is implemented as _locale._getdefaultlocale()[1]. _getdefaultlocale()[1] is implemented with: PyOS_snprintf(encoding, sizeof(encoding), "cp%d", GetACP()); At the end, it's the ANSI code page (1252). -- I don't understand how the change ace5c0fdd9b962e6e886c29dbcea72c53f051dc4 introduced a regression. And so I don't understand how commit 21a74312f2d1ddee71fade709af49d078085ec30 (revert) could fix anything. -- On my PR 12099, two Windows CI run and both succeeded: * AppVeyor: pythoninfo says "locale.encoding: cp1252" https://ci.appveyor.com/project/python/cpython/builds/22726025 * Windows PR Tests on Azure Pipeline: pythoninfo also says "locale.encoding: cp1252" When the change ace5c0fdd9b962e6e886c29dbcea72c53f051dc4 was merged, Python had no working Windows CI. Things evolved at lot in the meanwhile. I also tested manually my PR 12099 on my Windows 10 VM which also uses cp1252: test_re pass. -- re.LOCALE flag of re.compile() for a bytes pattern uses the following function of Modules/_sre.c: LOCAL(int) char_loc_ignore(SRE_CODE pattern, SRE_CODE ch) { return ch == pattern || (SRE_CODE) sre_lower_locale(ch) == pattern || (SRE_CODE) sre_upper_locale(ch) == pattern; } ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 18:08:09 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 28 Feb 2019 23:08:09 +0000 Subject: [issue29571] test_re is failing when local is set for `en_IN` In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za> Message-ID: <1551395289.01.0.424226906888.issue29571@roundup.psfhosted.org> STINNER Victor added the comment: New changeset ab71f8b793f7b42853ccd2a127ae7720adc5bcb4 by Victor Stinner in branch 'master': bpo-29571: Fix test_re.test_locale_flag() (GH-12099) https://github.com/python/cpython/commit/ab71f8b793f7b42853ccd2a127ae7720adc5bcb4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 18:08:30 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 28 Feb 2019 23:08:30 +0000 Subject: [issue29571] test_re is failing when local is set for `en_IN` In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za> Message-ID: <1551395310.12.0.894665177368.issue29571@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +12115 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 18:25:04 2019 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 28 Feb 2019 23:25:04 +0000 Subject: [issue35975] Put back the ability to parse files where async/await aren't keywords In-Reply-To: <1549931018.54.0.209945896308.issue35975@roundup.psfhosted.org> Message-ID: <1551396304.47.0.647357075169.issue35975@roundup.psfhosted.org> Guido van Rossum added the comment: > Would not be simpler to just drop the support of Python versions <3.7 in new MyPy versions? Not really -- mypy has a lot of users who run it over (very) large code bases that can't easily be upgraded. Basically mypy has to support all Python versions that haven't reached their end of life yet. (And it's also important that mypy not be constrained to the same Python version as the target code.) I suppose we could just stick with the existing typed_ast that supports 3.4 through 3.7, but we actually have a use case for the end_lineno and end_col_offset fields that were just added to ast in 3.8, and in general we'd like to support any future grammar elements and ast features. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 18:51:49 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Thu, 28 Feb 2019 23:51:49 +0000 Subject: [issue36152] IDLE: Remove close_when_done from colorizer close() Message-ID: <1551397909.36.0.802357976023.issue36152@roundup.psfhosted.org> New submission from Cheryl Sabella : Remove the unused `close_when_done` parameter from `close()` in `colorizer.ColorDelegator()`. * The second parameter to close() is called `close_when_done` and it is expected to contain a toplevel widget that has a destroy() method. * Originally, the editor window had code that would send self.top (if colorizing was in process) as the value for this parameter: doh = colorizing and self.top self.color.close(doh) # Cancel colorization * This was changed via this commit (https://github.com/python/cpython/commit/8ce8a784bd672ba42975dec752848392ff9a7797) in 2007 to instead be: self.color.close(False) self.color = None The value of `False` made it so the destroy code in colorizer wouldn't be run even though `None` or leaving the parameter off would have been more clear. In any case, this `close_when_done` hasn't been used since 2007. ---------- assignee: cheryl.sabella components: IDLE messages: 336880 nosy: cheryl.sabella, terry.reedy priority: normal severity: normal status: open title: IDLE: Remove close_when_done from colorizer close() type: enhancement versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 18:55:43 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Thu, 28 Feb 2019 23:55:43 +0000 Subject: [issue36152] IDLE: Remove close_when_done from colorizer close() In-Reply-To: <1551397909.36.0.802357976023.issue36152@roundup.psfhosted.org> Message-ID: <1551398143.96.0.521696955866.issue36152@roundup.psfhosted.org> Change by Cheryl Sabella : ---------- keywords: +patch pull_requests: +12116 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 19:04:40 2019 From: report at bugs.python.org (Cheryl Sabella) Date: Fri, 01 Mar 2019 00:04:40 +0000 Subject: [issue36152] IDLE: Remove close_when_done from colorizer close() In-Reply-To: <1551397909.36.0.802357976023.issue36152@roundup.psfhosted.org> Message-ID: <1551398680.85.0.405183457441.issue36152@roundup.psfhosted.org> Change by Cheryl Sabella : ---------- assignee: cheryl.sabella -> terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 19:32:40 2019 From: report at bugs.python.org (Ivan Pozdeev) Date: Fri, 01 Mar 2019 00:32:40 +0000 Subject: [issue33944] Deprecate and remove pth files In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za> Message-ID: <1551400360.4.0.979771357977.issue33944@roundup.psfhosted.org> Change by Ivan Pozdeev : ---------- pull_requests: +12117 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 19:49:32 2019 From: report at bugs.python.org (Sridhar Iyer) Date: Fri, 01 Mar 2019 00:49:32 +0000 Subject: [issue36153] Freeze support documentation is misleading. Message-ID: <1551401372.79.0.134624139836.issue36153@roundup.psfhosted.org> New submission from Sridhar Iyer : The documentation on freeze_support listed on https://docs.python.org/3/library/multiprocessing.html need to be fixed This mentions: "Calling freeze_support() has no effect when invoked on any operating system other than Windows. In addition, if the module is being run normally by the Python interpreter on Windows (the program has not been frozen), then freeze_support() has no effect." This is not true. Sklearn/tensorflow libraries tend to cause an infinite loop when frozen with pyinstaller (tested on python 3.6 on ubuntu 14.04). freeze_support is the only way to get around the situation and should be included before including any other module that includes a multiprocessing library (not just in main). ---------- assignee: docs at python components: Documentation messages: 336881 nosy: Sridhar Iyer, docs at python priority: normal severity: normal status: open title: Freeze support documentation is misleading. versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 19:58:35 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 01 Mar 2019 00:58:35 +0000 Subject: [issue33944] Deprecate and remove pth files In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za> Message-ID: <1551401915.86.0.220245357362.issue33944@roundup.psfhosted.org> Steve Dower added the comment: The sitecustomize.py file is totally available, and the only limitation there is packages can't inject themselves into it on installation. And if you want to trigger it on a package import then you totally can (though there's *another* discussion about that being a bad idea). .pth files really only satisfy the "run at startup because I'm a dependency of something that my user wants and don't make them opt-in to my changed behaviour", which I don't like :) If encodings need to be available without an explicit import, sure, we can add a point for those. Import hooks can always be injected by a package __init__.py before the importer will try and resolve the module, so nothing is needed there. But having a PEP with specific use cases to argue about is the way to create new mechanisms here. I don't agree we need a solution before declaring that the old way should be avoided and will eventually be removed, provided we don't add noisy warnings until there's an alternative. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 20:13:06 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Mar 2019 01:13:06 +0000 Subject: [issue29571] test_re is failing when local is set for `en_IN` In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za> Message-ID: <1551402786.77.0.656123222048.issue29571@roundup.psfhosted.org> STINNER Victor added the comment: AppVeyor failed on the backport to Python 3.7 of my fix: PR 12108. Ok, now I understand the bug in Python 3.7. locale.getlocale(locale.LC_CTYPE)[1] returns None because Python doesn't set LC_CTYPE to the user preferred locale. I'm not sure of which locale is used in practice in that case, but at least I can say that None is not the expected encoding name... str.encode() and bytes.decode() use UTF-8 when None is passed as the encoding. locale.getpreferredencoding() returns 'cp1252' which is the ANSI code page. Python 3.8 is different. In bpo-34485, I modified Python 3.8 to set LC_CTYPE locale to the user preference (ANSI code page): --- commit 177d921c8c03d30daa32994362023f777624b10d Author: Victor Stinner Date: Wed Aug 29 11:25:15 2018 +0200 bpo-34485, Windows: LC_CTYPE set to user preference (GH-8988) On Windows, the LC_CTYPE is now set to the user preferred locale at startup: _Py_SetLocaleFromEnv(LC_CTYPE) is now called during the Python initialization. Previously, the LC_CTYPE locale was "C" at startup, but changed when calling setlocale(LC_CTYPE, "") or setlocale(LC_ALL, ""). pymain_read_conf() now also calls _Py_SetLocaleFromEnv(LC_CTYPE) to behave as _Py_InitializeCore(). Moreover, it doesn't save/restore the LC_ALL anymore. On Windows, standard streams like sys.stdout now always use surrogateescape error handler by default (ignore the locale). --- ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 20:50:51 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 01 Mar 2019 01:50:51 +0000 Subject: [issue36152] IDLE: Remove close_when_done from colorizer close() In-Reply-To: <1551397909.36.0.802357976023.issue36152@roundup.psfhosted.org> Message-ID: <1551405051.74.0.595684835271.issue36152@roundup.psfhosted.org> Terry J. Reedy added the comment: Thanks for digging up the history. I would have approved without, but feel better with. Using the colorizer close method to close a window seemed flakey to me, and it seems someone else thought the same long ago. I suspect the machinery was left to avoid breaking external uses. PEP 434 changed this avoidance being *necessary*. (I am sure I have seen a SO answer with percolator + colorizer, as in turtledemo.) IDLE has had a too many shutdown bugs and still has some. Not adding one was my main concern when reviewing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 21:14:29 2019 From: report at bugs.python.org (Windson Yang) Date: Fri, 01 Mar 2019 02:14:29 +0000 Subject: [issue36153] Freeze support documentation is misleading. In-Reply-To: <1551401372.79.0.134624139836.issue36153@roundup.psfhosted.org> Message-ID: <1551406469.03.0.806127799225.issue36153@roundup.psfhosted.org> Windson Yang added the comment: IIUC, your script (using Sklearn/tensorflow) will cause an infinite loop when building with pyinstaller. Would you mind upload an example script so I can try to reproduce it? ---------- nosy: +Windson Yang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 21:16:35 2019 From: report at bugs.python.org (Windson Yang) Date: Fri, 01 Mar 2019 02:16:35 +0000 Subject: [issue29539] [smtplib] collect response data for all recipients In-Reply-To: <1486946725.6.0.180199923995.issue29539@psf.upfronthosting.co.za> Message-ID: <1551406595.04.0.700781224768.issue29539@roundup.psfhosted.org> Windson Yang added the comment: sls, are you working on this feature now? ---------- nosy: +Windson Yang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 21:25:55 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Mar 2019 02:25:55 +0000 Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to setup memory allocator and encodings In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org> Message-ID: <1551407155.86.0.310630568637.issue36142@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +12118 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 21:44:15 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Mar 2019 02:44:15 +0000 Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to setup memory allocator and encodings In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org> Message-ID: <1551408255.83.0.632116485354.issue36142@roundup.psfhosted.org> STINNER Victor added the comment: New changeset f684d83d86e1990784816d4b243d724e6ab8304f by Victor Stinner in branch 'master': bpo-36142: Exclude coreconfig.h from Py_LIMITED_API (GH-12111) https://github.com/python/cpython/commit/f684d83d86e1990784816d4b243d724e6ab8304f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 22:20:42 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Mar 2019 03:20:42 +0000 Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to setup memory allocator and encodings In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org> Message-ID: <1551410442.64.0.256213537737.issue36142@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +12119 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 22:29:25 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 01 Mar 2019 03:29:25 +0000 Subject: [issue36122] Second run of 2to3 continues to modify output In-Reply-To: <1551181873.79.0.208082027128.issue36122@roundup.psfhosted.org> Message-ID: <1551410965.78.0.752480950632.issue36122@roundup.psfhosted.org> Change by Terry J. Reedy : ---------- resolution: -> not a bug type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 22:42:14 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 01 Mar 2019 03:42:14 +0000 Subject: [issue36075] python 2to3 conversion tool is generating file with extra line for every input line In-Reply-To: <1550828319.37.0.854628356141.issue36075@roundup.psfhosted.org> Message-ID: <1551411734.47.0.282192927712.issue36075@roundup.psfhosted.org> Terry J. Reedy added the comment: I suspect that this may not be a cpython issue, in which case, it should be closed here as 'not-a-bug'. I suggest that you present this on python-list and ask 'where is the bug most likely to be?' You should get more readers there. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 23:05:01 2019 From: report at bugs.python.org (Saba Kauser) Date: Fri, 01 Mar 2019 04:05:01 +0000 Subject: [issue36075] python 2to3 conversion tool is generating file with extra line for every input line In-Reply-To: <1550828319.37.0.854628356141.issue36075@roundup.psfhosted.org> Message-ID: <1551413101.97.0.763872331875.issue36075@roundup.psfhosted.org> Saba Kauser added the comment: Could you please share the URL ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 23:29:31 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 01 Mar 2019 04:29:31 +0000 Subject: [issue36066] Add `empty` block to `for` and `while` loops. In-Reply-To: <1550759385.86.0.911138177234.issue36066@roundup.psfhosted.org> Message-ID: <1551414571.92.0.317768098585.issue36066@roundup.psfhosted.org> Terry J. Reedy added the comment: Syntax changes need PEPs. By default, syntax changes are rejected. This is especially true for new keywords, as any acceptible word will already be in use, and hence its introduction *will* break code. We are still having issues over having temporarily made 'async' and 'await' 'semi-keywords' (for 2 versions) to smooth out breakage. So new keywords must enable something previously difficult. But implementing the 'empty' idea is fairly trivial, as demonstrated in the initial post. A third alternative is a peak(iterator) class with a __bool__ method. I posted one once, probably on python-list. But the extra overhead every iteration must be larger than the simple assignment, which is so fast one should not worry about it. I suspect the flag also beats the chain alternative. --- [More opinionated than the above ...] Calling what is easy and works today 'non-idiomatic' is nearly pure opinion and not persuasive as a rhetorical device. The complicated rules for else-never interaction to be far more 'anti-idiomatic' from a comprehension point of view. In any case, a flag allows easy, flexible, and precise ordering of never, something, and either-way code. ---------- nosy: +terry.reedy resolution: -> postponed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 23:39:16 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Fri, 01 Mar 2019 04:39:16 +0000 Subject: [issue36075] python 2to3 conversion tool is generating file with extra line for every input line In-Reply-To: <1550828319.37.0.854628356141.issue36075@roundup.psfhosted.org> Message-ID: <1551415156.96.0.00519364614426.issue36075@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: @sabakauser You can find python-list mailing list here : https://mail.python.org/mailman/listinfo/python-list ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 23:42:26 2019 From: report at bugs.python.org (kellena) Date: Fri, 01 Mar 2019 04:42:26 +0000 Subject: [issue36154] Python quit unexpectedly error Message-ID: <1551415346.96.0.363606290461.issue36154@roundup.psfhosted.org> New submission from kellena : I'm on a Mac running Mojave, version 10.14.3. I installed Python 3.7. I'm now getting a "Python quit unexpectedly" error consistently and I don't know why or if I did something to cause it. I've tried uninstalling and reinstalling but I'm still getting the error. I've checked online resources such as Stack Overflow and "reinstall" is pretty much the standard suggestion, which I've already done. Here's the full error. Please tell me how to fix this: > Process: Python [7756] > Path: /Library/Frameworks/Python.framework/Versions/3.7/Resources/Python.app/Contents/MacOS/Python > Identifier: Python > Version: 3.7.2 (3.7.2) > Code Type: X86-64 (Native) > Parent Process: Code Helper [785] > Responsible: Python [7756] > User ID: 501 > > Date/Time: 2019-02-27 16:27:29.136 -0600 > OS Version: Mac OS X 10.14.3 (18D109) > Report Version: 12 > Bridge OS Version: 3.3 (16P3133) > Anonymous UUID: DB5CA6AD-7D99-F9D4-0475-D401946AB77E > > Sleep/Wake UUID: D7171268-D6D9-464C-B881-A97EE3C3AB2D > > Time Awake Since Boot: 17000 seconds > Time Since Wake: 420 seconds > > System Integrity Protection: enabled > > Crashed Thread: 0 Dispatch queue: com.apple.main-thread > > Exception Type: EXC_CRASH (SIGABRT) > Exception Codes: 0x0000000000000000, 0x0000000000000000 > Exception Note: EXC_CORPSE_NOTIFY > > Application Specific Information: > dyld2 mode > abort() called > > Thread 0 Crashed:: Dispatch queue: com.apple.main-thread > 0 libsystem_kernel.dylib 0x00007fff6b87723e __pthread_kill + 10 > 1 libsystem_pthread.dylib 0x00007fff6b92dc1c pthread_kill + 285 > 2 libsystem_c.dylib 0x00007fff6b7e01c9 abort + 127 > 3 org.python.python 0x00000001049ff420 fatal_error + 592 > 4 org.python.python 0x00000001049fe784 _Py_FatalInitError + 36 > 5 org.python.python 0x0000000104a27031 pymain_main + 7921 > 6 org.python.python 0x0000000104a2713a _Py_UnixMain + 58 > 7 libdyld.dylib 0x00007fff6b737ed9 start + 1 > > Thread 0 crashed with X86 Thread State (64-bit): > rax: 0x0000000000000000 rbx: 0x000000010b3955c0 rcx: 0x00007ffeeb313e88 rdx: 0x0000000000000000 > rdi: 0x0000000000000307 rsi: 0x0000000000000006 rbp: 0x00007ffeeb313ec0 rsp: 0x00007ffeeb313e88 > r8: 0x0000000000000000 r9: 0x00000000b7d055e4 r10: 0x0000000000000000 r11: 0x0000000000000206 > r12: 0x0000000000000307 r13: 0x00007fff9e5139a0 r14: 0x0000000000000006 r15: 0x000000000000002d > rip: 0x00007fff6b87723e rfl: 0x0000000000000206 cr2: 0x00007fff9e511188 > > Logical CPU: 0 > Error Code: 0x02000148 > Trap Number: 133 > > > Binary Images: > 0x1048eb000 - 0x1048ebfff +org.python.python (3.7.2 - 3.7.2) <122E5A60-3D65-3759-AD3F-54658AA10863> /Library/Frameworks/Python.framework/Versions/3.7/Resources/Python.app/Contents/MacOS/Python > 0x1048f3000 - 0x104accff7 +org.python.python (3.7.2, [c] 2001-2018 Python Software Foundation. - 3.7.2) <779A7040-54B9-3956-85A6-C3CFE0C5A52A> /Library/Frameworks/Python.framework/Versions/3.7/Python > 0x10b2df000 - 0x10b35da87 dyld (655.1) <3EBA447F-A546-366B-B302-8DC3B21A3E30> /usr/lib/dyld > 0x7fff3e4af000 - 0x7fff3e8fcfef com.apple.CoreFoundation (6.9 - 1562) <02A2C178-9FF6-385C-A9C5-7F4FC9D66311> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation > 0x7fff687f9000 - 0x7fff687faff7 libDiagnosticMessagesClient.dylib (107) <15210AC0-61F9-3F9D-A159-A009F62EB537> /usr/lib/libDiagnosticMessagesClient.dylib > 0x7fff68bab000 - 0x7fff68bacffb libSystem.B.dylib (1252.200.5) /usr/lib/libSystem.B.dylib > 0x7fff68e05000 - 0x7fff68e5cff7 libc++.1.dylib (400.9.4) /usr/lib/libc++.1.dylib > 0x7fff68e5d000 - 0x7fff68e72fff libc++abi.dylib (400.17) <446F4748-8A89-3D2E-AE1C-27EEBE93A8AB> /usr/lib/libc++abi.dylib > 0x7fff69ac1000 - 0x7fff69d24ffb libicucore.A.dylib (62109.0.1) /usr/lib/libicucore.A.dylib > 0x7fff6a653000 - 0x7fff6add9fe7 libobjc.A.dylib (750.1) <804715F4-F52D-34D0-8FEC-A25DC08513C3> /usr/lib/libobjc.A.dylib > 0x7fff6b536000 - 0x7fff6b548ffb libz.1.dylib (70.200.4) <15F7B40A-424C-33BB-BF2C-7E8195128B78> /usr/lib/libz.1.dylib > 0x7fff6b5b9000 - 0x7fff6b5bdff3 libcache.dylib (81) <704331AC-E43D-343A-8C24-39201142AF27> /usr/lib/system/libcache.dylib > 0x7fff6b5be000 - 0x7fff6b5c8ff3 libcommonCrypto.dylib (60118.220.1) <9C865644-EE9A-3662-AB77-7C8A5E561784> /usr/lib/system/libcommonCrypto.dylib > 0x7fff6b5c9000 - 0x7fff6b5d0fff libcompiler_rt.dylib (63.4) <817772E3-E836-3FFD-A39B-BDCD1C357221> /usr/lib/system/libcompiler_rt.dylib > 0x7fff6b5d1000 - 0x7fff6b5daff3 libcopyfile.dylib (146.200.3) <5C5C4F35-DAB7-3CF1-940F-F47192AB8289> /usr/lib/system/libcopyfile.dylib > 0x7fff6b5db000 - 0x7fff6b65ffdf libcorecrypto.dylib (602.230.1) /usr/lib/system/libcorecrypto.dylib > 0x7fff6b6e6000 - 0x7fff6b720ff7 libdispatch.dylib (1008.220.2) <2FDB1401-5119-3DF0-91F5-F4E105F00CD7> /usr/lib/system/libdispatch.dylib > 0x7fff6b721000 - 0x7fff6b750ff3 libdyld.dylib (655.1) <90C801E7-5D05-37A8-810C-B58E8C53953A> /usr/lib/system/libdyld.dylib > 0x7fff6b751000 - 0x7fff6b751ffb libkeymgr.dylib (30) /usr/lib/system/libkeymgr.dylib > 0x7fff6b75f000 - 0x7fff6b75fff7 liblaunch.dylib (1336.240.2) /usr/lib/system/liblaunch.dylib > 0x7fff6b760000 - 0x7fff6b765fff libmacho.dylib (921) <6ADB99F3-D142-3A0A-B3CE-031354766ACC> /usr/lib/system/libmacho.dylib > 0x7fff6b766000 - 0x7fff6b768ffb libquarantine.dylib (86.220.1) <58524FD7-63C5-38E0-9D90-845A79551C14> /usr/lib/system/libquarantine.dylib > 0x7fff6b769000 - 0x7fff6b76aff3 libremovefile.dylib (45.200.2) /usr/lib/system/libremovefile.dylib > 0x7fff6b76b000 - 0x7fff6b782ff3 libsystem_asl.dylib (356.200.4) <33C62769-1242-3BC1-9459-13CBCDECC7FE> /usr/lib/system/libsystem_asl.dylib > 0x7fff6b783000 - 0x7fff6b783fff libsystem_blocks.dylib (73) <152EDADF-7D94-35F2-89B7-E66DCD945BBA> /usr/lib/system/libsystem_blocks.dylib > 0x7fff6b784000 - 0x7fff6b80cfff libsystem_c.dylib (1272.200.26) /usr/lib/system/libsystem_c.dylib > 0x7fff6b80d000 - 0x7fff6b810ff7 libsystem_configuration.dylib (963.200.27) <94898525-ECC8-3CC9-B312-CBEAAC305E32> /usr/lib/system/libsystem_configuration.dylib > 0x7fff6b811000 - 0x7fff6b814ff7 libsystem_coreservices.dylib (66) <10818C17-70E1-328E-A3E3-C3EB81AEC590> /usr/lib/system/libsystem_coreservices.dylib > 0x7fff6b815000 - 0x7fff6b81bffb libsystem_darwin.dylib (1272.200.26) <07468CF7-982F-37C4-83D0-D5E602A683AA> /usr/lib/system/libsystem_darwin.dylib > 0x7fff6b81c000 - 0x7fff6b822ff7 libsystem_dnssd.dylib (878.240.1) <5FEA5E1E-E80F-3616-AD33-8E936D61F31A> /usr/lib/system/libsystem_dnssd.dylib > 0x7fff6b823000 - 0x7fff6b86fff3 libsystem_info.dylib (517.200.9) <54B65F21-2E93-3579-9B72-6637A03245D9> /usr/lib/system/libsystem_info.dylib > 0x7fff6b870000 - 0x7fff6b898ff7 libsystem_kernel.dylib (4903.241.1) /usr/lib/system/libsystem_kernel.dylib > 0x7fff6b899000 - 0x7fff6b8e4ff7 libsystem_m.dylib (3158.200.7) /usr/lib/system/libsystem_m.dylib > 0x7fff6b8e5000 - 0x7fff6b909ff7 libsystem_malloc.dylib (166.220.1) <4777DC06-F9C6-356E-82AB-86A1C6D62F3A> /usr/lib/system/libsystem_malloc.dylib > 0x7fff6b90a000 - 0x7fff6b915ff3 libsystem_networkextension.dylib (767.240.1) <4DB0D4A2-83E7-3638-AAA0-39CECD5C25F8> /usr/lib/system/libsystem_networkextension.dylib > 0x7fff6b916000 - 0x7fff6b91dfff libsystem_notify.dylib (172.200.21) <65B3061D-41D7-3485-B217-A861E05AD50B> /usr/lib/system/libsystem_notify.dylib > 0x7fff6b91e000 - 0x7fff6b927fef libsystem_platform.dylib (177.200.16) <83DED753-51EC-3B8C-A98D-883A5184086B> /usr/lib/system/libsystem_platform.dylib > 0x7fff6b928000 - 0x7fff6b932fff libsystem_pthread.dylib (330.230.1) <80CC5992-823E-327E-BB6E-9D4568B84161> /usr/lib/system/libsystem_pthread.dylib > 0x7fff6b933000 - 0x7fff6b936ff7 libsystem_sandbox.dylib (851.230.3) /usr/lib/system/libsystem_sandbox.dylib > 0x7fff6b937000 - 0x7fff6b939ff3 libsystem_secinit.dylib (30.220.1) <5964B6D2-19D4-3CF9-BDBC-4EB1D42348F1> /usr/lib/system/libsystem_secinit.dylib > 0x7fff6b93a000 - 0x7fff6b941ff7 libsystem_symptoms.dylib (820.237.2) <487E1794-4C6E-3B1B-9C55-95B1A5FF9B90> /usr/lib/system/libsystem_symptoms.dylib > 0x7fff6b942000 - 0x7fff6b957ff7 libsystem_trace.dylib (906.220.1) <4D4BA88A-FA32-379D-8860-33838723B35F> /usr/lib/system/libsystem_trace.dylib > 0x7fff6b959000 - 0x7fff6b95effb libunwind.dylib (35.4) /usr/lib/system/libunwind.dylib > 0x7fff6b95f000 - 0x7fff6b98ffff libxpc.dylib (1336.240.2) /usr/lib/system/libxpc.dylib > > External Modification Summary: > Calls made by other processes targeting this process: > task_for_pid: 0 > thread_create: 0 > thread_set_state: 0 > Calls made by this process: > task_for_pid: 0 > thread_create: 0 > thread_set_state: 0 > Calls made by all processes on this machine: > task_for_pid: 25582 > thread_create: 0 > thread_set_state: 0 > > VM Region Summary: > ReadOnly portion of Libraries: Total=237.2M resident=0K(0%) swapped_out_or_unallocated=237.2M(100%) > Writable regions: Total=35.5M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=35.5M(100%) > > VIRTUAL REGION > REGION TYPE SIZE COUNT (non-coalesced) > =========== ======= ======= > Kernel Alloc Once 8K 2 > MALLOC 19.2M 9 > MALLOC guard page 16K 4 > STACK GUARD 4K 2 > Stack 16.0M 2 > __DATA 4244K 47 > __LINKEDIT 216.9M 5 > __TEXT 20.4M 45 > __UNICODE 564K 2 > shared memory 8K 3 > =========== ======= ======= > TOTAL 277.1M 111 > > Model: MacBookPro15,1, BootROM 220.240.2.0.0 (iBridge: 16.16.3133.0.0,0), 6 processors, Intel Core i7, 2.2 GHz, 16 GB, SMC > Graphics: Intel UHD Graphics 630, Intel UHD Graphics 630, Built-In > Graphics: Radeon Pro 555X, Radeon Pro 555X, PCIe > Memory Module: BANK 0/ChannelA-DIMM0, 8 GB, DDR4, 2400 MHz, SK Hynix, - > Memory Module: BANK 2/ChannelB-DIMM0, 8 GB, DDR4, 2400 MHz, SK Hynix, - > AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x7BF), wl0: Sep 18 2018 16:24:57 version 9.130.86.7.32.6.21 FWID 01-83a3fe91 > Bluetooth: Version 6.0.10f1, 3 services, 27 devices, 1 incoming serial ports > Network Service: Wi-Fi, AirPort, en0 > USB Device: USB 3.1 Bus > USB Device: iBridge Bus > USB Device: iBridge DFR brightness > USB Device: iBridge Display > USB Device: Apple Internal Keyboard / Trackpad > USB Device: Headset > USB Device: iBridge ALS > USB Device: iBridge FaceTime HD Camera (Built-in) > USB Device: iBridge > Thunderbolt Bus: MacBook Pro, Apple Inc., 34.6 > Thunderbolt Bus: MacBook Pro, Apple Inc., 34.6 ---------- messages: 336892 nosy: kellena priority: normal severity: normal status: open title: Python quit unexpectedly error type: crash versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 28 23:52:36 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 01 Mar 2019 04:52:36 +0000 Subject: [issue36072] str.translate() behaves differently for ASCII-only and other strings In-Reply-To: <1550813669.37.0.821443537849.issue36072@roundup.psfhosted.org> Message-ID: <1551415956.99.0.118618592994.issue36072@roundup.psfhosted.org> Terry J. Reedy added the comment: I agree. The fact the CPython attempts to optimize all_ascii.translate(table) is a CPython implementation detail, not a language feature. ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, terry.reedy resolution: -> not a bug stage: -> resolved status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________